| Andrew,
This same error occured in SNO also. I cannot reproduce it here.
I have looked through the linker, rdb and sql manuals. We have have
also checked the notes files.
It seems that there may was a bug fixed in the linker with VMS 5.5
which now picks up multiple psect sections. The fix reported was to
link with NOSHR,LCL.
As I cannot reproduce the error, I cannot test the fix. But I believe
what you have to do is to create the follow .OPT file and link it into
the image:
TPAS$LIBRARY:TPAS_OPT.OPT
psect_attr=sql$request_aab,NOSHR,LCL
LINK your_program,TPAS$LIBRARY:TPAS_LOGIC/LIB, -
SYS$LIBRARY:SQL$USER/LIB, -
TPAS$LIBRARY:TPAS_OPT/OPT
As I said, I am not sure if this works. Please let me know.
regards,
Lois
|
| <<< NOMAHS::DISK$NOMAHS1:[NOTES$LIBRARY]RDB_50.NOTE;1 >>>
-< DEC Rdb - Digital's Strategic Relational Database - on Alpha AXP >-
================================================================================
Note 1507.0 %LINK-W-MULPSC after upgrade to Rdb 4.2/vms 5.5-2. 4 replies
HTSC19::SIMONLAU 24 lines 1-SEP-1993 22:48
--------------------------------------------------------------------------------
Hi,
Customer was getting no erros linking his code under Rdb/VMS v3.1 on
VMS v5.4. He then upgrade to Rdb/VMS v4.2 and vMS v5.5-2 and now gets
the following error when linking :
$ LINK /EXE=TESIMAG:TEF41B TESOBJ:TEF41B,SYS$INPUT/OPT
TESOBJ:TESAPPERR, -
CONOBJ:CNE10M, CNVDATE
%LINK-W-MULPSC, conflicting attributes for psect RDB$TRANSACTION_HANDLE
in module RDB$RDBVMSINIT file SYS$COMMON:[SYSLIB]STARLET.OLB;3
Is it the linking problem in VMS V5.5-2 ? Or ........ ??
If yes, what should be done in Rdb to prevent this ?
Your input would be helpful and highly appreciated.
Thanks a lot.
Simon
================================================================================
Note 1507.1 %LINK-W-MULPSC after upgrade to Rdb 4.2/vms 5.5-2. 1 of 4
CSC32::M_HOEPNER "A Closed Mouth Gathers No Feet" 62 lines 2-SEP-1993 09:44
--------------------------------------------------------------------------------
Is this his issue?
Rdb/VMS: %LINK-W-MULPSC Errors Linking On VMS 5.5 And Later
Copyright (c) Digital Equipment Corporation, 1993, All Rights Reserved.
Unpublished Rights Reserved Under The Copyright Laws Of The United States.
"Without the express written consent of Digital Equipment Corporation, no part
of this information may be copied, downloaded, stored in retrieval systems,
further transmitted or otherwise reproduced, stored, disseminated, in any form
to any party who is not covered under an appropriate, duly executed,
Digital Service Agreement."
LAYERED PRODUCT: VAX Rdb/VMS
OP/SYS: VMS
SOURCE: Digital Customer Support Center
SUBJECT:
Changes in VMS V5.5 Linker may cause LINK-W-MULPSC errors with
3GL (i.e., COBOL, FORTRAN, PASCAL, VAX C...) and Rdb programs.
The description of this error is:
MULPSC, conflicting attributes for psect 'psect-name' in module
'module-name' file 'filename'
Facility: LINK, Linker Utility
Explanation: The attributes for a psect were found to
be different in subsequent modules of the link.
User Action: Correct the source so that all instances
of the same psect have the same attributes.
DESCRIPTION:
Prior to VMS 5.5, if two shareable images had the same psect name and
the psect attributes were noshr, the Linker would ignore this and produce
a usable image file.
This incorrect behavior is fixed in VMS 5.5 and is described in section
3.17.1 and 3.17.2 of the VMS 5.5 Release Notes. In VMS 5.5, the problem
is fixed such that if two psects have the same name, whether or not noshr
is specified, the Linker will generate MULPSC error messages.
The RDB pre-compiler creates shareable psects with the same names and
some 3GL compilers, when creating psects for a common block, assigns the
shr attribute by default, defining them as global. Using a psect_attribute
statement in an options file to change to noshr, you will be able to
link without getting the warning messages.
Add this to the link options file:
PSECT_ATTR=psect_name,NOSHR,LCL
================================================================================
Note 1507.2 %LINK-W-MULPSC after upgrade to Rdb 4.2/vms 5.5-2. 2 of 4
ODIXIE::SHARMA 7 lines 3-SEP-1993 11:20
--------------------------------------------------------------------------------
Simon,
Since you upgraded from V3.1 to V4.1 RDB$TRANSACTION_HANDLE became
4 to 8 bytes, hence the error. Instead of using a PSECT linker option,
the other option may be to re-compile all code under V4.2 and this
problem may not occur.
.Tushar.
================================================================================
Note 1507.3 %LINK-W-MULPSC after upgrade to Rdb 4.2/vms 5.5-2. 3 of 4
SIOG::BARRETT 20 lines 30-NOV-1993 07:23
-< Is this a VMS 5.5 problem only? >-
--------------------------------------------------------------------------------
I have a customer who also reported getting warning messages when
linking (link-w-mulpsc, conflicting attributes for psect RDB$VARIABLE1
in module RDB$DATES file LIBRARY.OLB).
I advised him to add the PSECT_ATTR=psect_name,NOSHR,LCL line to his
link options file and the warning messages went away.
My question is this. According to 1507.*, the warning messages were
caused by an upgrade to VMS 5.5, but my customer has been using VMS 5.5
for a considerable period with no problems. The change to the
environment in this case was an upgrade to RDB 4.2 from 4.0, when he
tried to link a mixture of modules precompiled under 4.0 and 4.2.
Was there a change between the RDB versions that caused the problem in this
case? Should all modules precompiled under 4.0 be precompiled under
4.2?
Thanks,
Ann.
================================================================================
Note 1507.4 %LINK-W-MULPSC after upgrade to Rdb 4.2/vms 5.5-2. 4 of 4
KERNEL::PULLEY "The frost-free retriever." 13 lines 7-FEB-1994 12:19
--------------------------------------------------------------------------------
Hi Ann,
Not sure if this is too late but.
I believe all the modules will need linking under v4.2.
There was a difference between v4.0-0 & v4.0a which requires things to
be recompiled/linked.
If this isn't the problem in this case, it would at least be something
to get out the way.
(The recompile & link is mentioned in v4.1 release notes).
Cheers,
Steve.
|
|
Hi Lois,
We have tried your idea of fixing the linking warning messges by
including the following and warning messsages are gone.
TPAS$LIBRARY:TPAS_OPT.OPT
psect_attr=sql$request_aab,NOSHR,LCL
LINK your_program,TPAS$LIBRARY:TPAS_LOGIC/LIB, -
SYS$LIBRARY:SQL$USER/LIB, -
TPAS$LIBRARY:TPAS_OPT/OPT
The warning messages we used to get are now gone. But when we executed
the program, we are still getting the same TPAS fatal errors as
before:
%APPIX-F-GETAREATO, TO Subsidiary Billing Code Area not on Corp. Table
The bill-to code we used is 0002495 and 0002495 is indeed in the TPAS
table. Why?
We have three local applications to modify to call TPAS software
modules. Two of local applications are exclusively COBOL application.
The third application used a combination of C, SQL, RDB and COBOL to
call TPAS. It is this application that we have troubles to get it run
properly. We even tried to run the application with and without RDB.
Everytime the application executed SQL commands, we have the fatal
errors. When running without the SQL commands, the program behave
normally and produce no fatal errors.
My other questions are:
1. What versions of VMS and RDB you used to compile and link your TPAS
programs ?
2. Based on the suggestions by you and other people who have similar
problem like we have, it seems that they're suggesting that all modules
should be re-compiled and linked under V4.2. In other words, if TPAS
modules or library use RDB V4.0 to compile and link to produce the
TPAS object library, and we used RDB V4.1-1 here, then we have may
have a problem.
We use VMS V5.5-2 and RDB V4.1-1 here to compile and link with TPAS-II.
Looking forward to hearing from you soon.
Regards,
Andy
|
| Andy,
I am glad the TPAS_OPT/OPT worked for the link warnings.
Now, when you send in the Billing/Shipping data are the Type Codes set
correctly.
TPAS_SHIP_BILL_FROM = "974"
TPAS_SHIP_BILL_FROM_TYPE_CD = "S" or TPAS$BILL_FROM_TYPE_CD = "S"
TPAS_SHIP_BILL_TO = "0002495"
TPAS_SHIP_BILL_TO_TYPE_CD = "B" or TPAS$BILL_TO_TYPE_CD = "B"
In your C application, do you utilize the TPAS$SEPARATE_OPEN, integrating
the TPAS_OPEN_DB_SQL.SQLMOD into the 'declares' of the other RDB databases
of your application ? RDB does not like multiple declares and that may be
giving you the problem.
> 1. What versions of VMS and RDB you used to compile and link your TPAS
> programs ?
Our development and production environment currently has:
VMS 5.5-2 RDB/SQL 4.0-2
> 2. Based on the suggestions by you and other people who have similar
> problem like we have, it seems that they're suggesting that all modules
> should be re-compiled and linked under V4.2. In other words, if TPAS
> modules or library use RDB V4.0 to compile and link to produce the
> TPAS object library, and we used RDB V4.1-1 here, then we have may
> have a problem.
There are sites running on various version of RDB/SQL. The range
from V 3 to V 5 RDB. There are some known bugs in V4.2 (see note
38.*).
We have just completed the PASE testing and are waiting
for the other IM&T organizations sharing our clusters to complete
their testing. At that point our clusters will be scheduled to
upgrade to VMS V6.1, RDB V6, COBOL V5.1, and ACMS V3.3.
We will be completely by-passing RDBV4.2 and V5.* of RDB.
Regards,
Lois
|