Operating System - OpenVMS
cancel
Showing results for 
Search instead for 
Did you mean: 

COBOL Link Fails on Integrity

 
SOLVED
Go to solution
Homer Shoemaker
Frequent Advisor

COBOL Link Fails on Integrity

I need a little help figuring out where to go next. Let me explain what I've done so far, and where I need some help.

My Integrity Server (Rx2660 OpenVMS v 8.3) is a new server. I tried to set it up to be like my DS20 v 7.1-2 as far as logicals and symbols defined during startup and login.

These are a development servers.

When I compile and link a certain program on the new system, I get the following link errors:

%ILINK-W-USEUNDEF, undefined symbol PSL$C_USER referenced
section: $PDATA$
offset: %X0000000000000004
module: PRMDSP
file: DMS_DR:[OLB]COBOBJ.OLB;1
%ILINK-W-USEUNDEF, undefined symbol PSL$C_SUPER referenced
section: $PDATA$
offset: %X0000000000000006
module: PRMDSP
file: DMS_DR:[OLB]COBOBJ.OLB;1
%ILINK-W-USEUNDEF, undefined symbol PSL$C_EXEC referenced
section: $PDATA$
offset: %X0000000000000008
module: PRMDSP
file: DMS_DR:[OLB]COBOBJ.OLB;1
%ILINK-W-USEUNDEF, undefined symbol PSL$C_KERNEL referenced
section: $PDATA$
offset: %X000000000000000A
module: PRMDSP
file: DMS_DR:[OLB]COBOBJ.OLB;1

(Among others, but one thing at a time. They're probably related.) The main program links and runs fine on the Alpha.

I have no idea what section $PDATA$ is.

I looked in the module PRMDSP, which compiles just fine and is in the library, looking for uses or definitions of these symbols. Didn't see anything. Did a little googling, and I see that these symbols are related to the system service $create_gpfile. Apparently created by

"The $PSLDEF macro in STARLET.MLB and the file PSLDEF.H in SYS$STARLET_C.TLB define the following symbols and their values for the four access modes:"

And then they list my undefined symbols.

Now I'm starting to get wrapped around the axle. Can anyone point me in right direction?

Is there some system parameter that I should have setup that would have defined these symbols? Or does something work differently on the new platform so that I need to change some code? Or is there something else that I'm missing completely. That's my guess. :0)

Thanks for any help you can offer.





5 REPLIES 5
Homer Shoemaker
Frequent Advisor

Re: COBOL Link Fails on Integrity

Sometimes writing it all down and trying not to look too bad when you ask the question is helpful in solving the problem.

I think I need to install $PSLDEF in my COBOL object library. Does that make sense?

I'll keep plugging away. If you see me going too far afield, jump right in.
John Gillings
Honored Contributor
Solution

Re: COBOL Link Fails on Integrity

Homer,

PSL$ symbols are associated with inner mode data structures and aren't normally visible in the default libraries searched by LINK.

The PSL is the "Processor Status Longword" which is an internal register which keeps track of things like your current and previous modes. In general it's rare that a usermode program would care about modes, and therefore it's not considered necessary for the symbols to be generally available.

COBOL doesn't have the same mechanisms as MACRO32 and C for defining obscure symbols, so the usual trick would be to create an object module with the symbols globalised using MACRO32 and LINKing that with your program:

$ CREATE PSLDEF.MAR
$PSLDEF GLOBAL
.END
$ MACRO PSLDEF
$ LINK yourprogram+PSLDEF+wheverelse

It's possible that a similar module has been added to one of the system standard libraries on your Alpha. I don't think this is a good idea. The evidence of your confusion in moving this code to a new system and finding undefined symbols pretty much proves my point!

If the program is dependent on non-standard symbols, the build procedures should resolve them explicitly, rather than depending on a largely invisible non-standard modification to the global environment.

A crucible of informative mistakes
Hein van den Heuvel
Honored Contributor

Re: COBOL Link Fails on Integrity

Homer,

The Cobol code in question probably uses definitions similar to:

05 PSL$C_KERNEL PIC S9(09) COMP VALUE EXTERNAL PSL$C_KERNEL.

One possible is to just define the values there and then. Some will suggest this is not 'clean', maybe even sloppy, but it is actually perfectly safe and typically more efficient then to make the linker/image activator get involved.
Just replace with:

05 PSL$C_KERNEL PIC S9(09) COMP VALUE 0.

The other values can be gleemed from:

$ libr/extr=$psldef/out=tt: sys$library:starlet.mlb

They are not going to change. Ever. Trust me :-).


The right way to approach this problem is to figure out there they are defined on your Alpha.
To do so just LINK with /MAP/CROSS and search for the symbols. That will lead you to the module.

Create a similar module, in a similar place on the I64 and presto.

John's instructions give you the details.


Good luck!
Hein.

Homer Shoemaker
Frequent Advisor

Re: COBOL Link Fails on Integrity

You both were very helpful. Thank you. I hadn't used the macro compiler before. The possibilites are intriguing.

I am looking forward to attending my first bootcamp. Hope to thank you in person.
Homer Shoemaker
Frequent Advisor

Re: COBOL Link Fails on Integrity

Thanks.