Need help with OpenVMS Linker warnings

[Phil VanKley]

Hello,

I'm wrestling with some linker warnings.  I'm running VMS 8.3-1H1 and Oracle Rdb 7.2-400.  I am linking a COBOL application.  The link statement is below.  All of the subroutine objects, including the one referenced in the warnings (RDB$GET_RES_PHASE) is in the MCT$LIB:OBJLIB.OLB object library that is referenced in the link command.

$ link/executable=MCT$EXE:   mct$obj:PROCESS_RES_APPROVE.OBJ,      sql$user/lib,
   mct$lib:objlib.olb/lib
%ILINK-W-NUDFSYMS, 2 undefined symbols:
%ILINK-I-UDFSYM,        SQL$INIT_HANDLER_5
%ILINK-I-UDFSYM,        SQL$RUNTIME_HANDLER
%ILINK-I-UDFSYM,        VMH$FIXEDQ_UR (Weak Reference)
%ILINK-I-UDFSYM,        VMH$FIXEDQ_UW (Weak Reference)
%ILINK-I-UDFSYM,        VMHDEB$TRACE_FREE_VM (Weak Reference)
%ILINK-I-UDFSYM,        VMHDEB$TRACE_FREE_VMLIST (Weak Reference)
%ILINK-I-UDFSYM,        VMHDEB$TRACE_GET_VM (Weak Reference)
%ILINK-I-UDFSYM,        VMHDEB$TRACE_RET_VMH (Weak Reference)
%ILINK-I-UDFSYM,        VMHDEB$TRACK_FREE_VM (Weak Reference)
%ILINK-I-UDFSYM,        VMHDEB$TRACK_GET_VM (Weak Reference)
%ILINK-W-USEUNDEF, undefined symbol SQL$RUNTIME_HANDLER referenced
        section: $LINKER UNWINFO$
        offset: %X0000000000000088
        module: RDB$GET_RES_PHASE
        file: USER1:[MCT_DEV.LIB]OBJLIB.OLB;1
%ILINK-W-USEUNDEF, undefined symbol SQL$INIT_HANDLER_5 referenced
        section: SQL$MACRO_CODE
        offset: %X0000000000001070  slot: 2
        module: RDB$GET_RES_PHASE
        file: USER1:[MCT_DEV.LIB]OBJLIB.OLB;1

Now, I can get a successful link if I create an options file and link as follows:

PROCESS_RES_APPROVE.OPT:

MCT$LIB:OBJLIB/INCLUDE=(GET_RES_PHASE,RDB$GET_RES_PHASE)
SQL$USER/LIBRARY
MCT$LIB:OBJLIB/LIBRARY

$ LINK/EXE=MCT$EXE:  MCT$OBJ:PROCESS_RES_APPROVE, MCT$LIB:PROCESS_RES_APPROVE/OPT

Can anyone explain why the options file works where I explicitly specify this particular object in an INCLUDE specification when the objects for the included routines are in the object library referenced by the MCT$LIB:OBJLIB/LIBRARY reference in the original link command at the top of this post?

Ideally, I'd like to get the link to work, if possible, without an options file as this is an automated build system utilizing MMS and this particular executable link is the only one exhibiting this issue.

Thanks!

Phil Van Kley

Maricopa County Treasurer's Office

Phoenix, AZ

----------------------------------------------------------------------------------------------------------------------------------------------------------------------

P.S. This thread has been moved from OpenVMS>General to Languages and Scripting board- Forum Moderator

[Hoff · Accepted solution]

The linker options file is a common portion of a link command and quite commonly used, and the /INCLUDE references here bring in the rest of the dependencies that then resolve the rest of the Rdb-related symbols and routines; it's the reference that pulls in the rest of the Rdb SQL environment.

(I don't recognize the RDB$GET_RES_PHASE symbol; the usual /INCLUDE I've created and used has had different Rdb-related symbols referenced.)

As for some background on this issue, please see the Oracle Rdb Guide to SQL Programming (that's V7) documentation for your Rdb version, among other available resources. And see information such as the following quote from the help text for SQL70:

>>>

When users link programs, they must somehow specify the SQL
interface user library SQL$USER.OLB. If you define the logical
name LNK$LIBRARY as the user library, you save users from having
to explicitly specify that library each time they link their
embedded SQL programs.

To define LNK$LIBRARY, issue this command:

$ DEFINE/SYSTEM/EXECUTIVE/NOLOG LNK$LIBRARY SQL$USER

To make sure LNK$LIBRARY is defined each time the system starts
up, add the previous command to the SYS$STARTUP:RMONSTART.COM
command file.

You must also check to see that the system logical name
LNK$LIBRARY is not already being used. Your site or other
products may have already defined the LNK$LIBRARY logical
name. If so, you should add a numeric suffix to the LNK$LIBRARY
definition you create and to the definition in RMONSTART.COM.
See the Oracle Rdb7 Installation and Configuration Guide for more
information about adding a suffix.

If you do not define LNK$LIBRARY to specify the SQL user library,
users must explicitly name it when they link programs with
embedded SQL statements. For example:

$ LINK my_prog, SQL$USER/LIBRARY

See the OpenVMS documentation set for more information about the
LINK command.

<<<

I tried quoting that text, but the forum software didn't allow it.

And FWIW, the linker options file is also how identification strings, shareable image match values and the rest of the settings are incorporated into the executable and shareable images that are getting created by the linker commands.  It's quite commonly encountered.

If I get a chance, I'll look up one of the example linker commands around, but the Rdb manuals do have the references to this stuff.

[Phil VanKley]

Thanks for the quick response!  Note that I do have the SQL$USER library referenced in the original link command that results in the warnings.

We do links with Rdb-contained routines all the time.  For some reason, this is the only executable out of the other hundreds we have that has this issue.

[Phil VanKley]

I did try defining the LNK$LIBRARY as specified in the documentation reference (DEFINE/SYSTEM/EXEC LNK$LIBRARY SQL$USER).  After doing this, my original link command was successful with no warnings.  Obviously, it is doing more with this logical name than the explicit reference to SQL$USER/LIB I have on the link command line.  I don't understand enough about how the linker works, though, to know why.

I will look deeper into my Rdb documentation concerning this as you suggested.  Thanks again so much!

Phil

[Hoff]

FWIW, I usually use LNK$LIBRARY (possibly with the LNK$LIBRARY_sequence-number definitions, when working with a number of libraries) via DEFINE /NOLOG or DEFINE /JOB /NOLOG either at login or at the top of the DECset MMS, mmk or gmake, when I'm using that approach.  (And when I'm spending more time tussling with the make tools.)  Defining these logical name settings system-wide can (will) cause problems when using multi-version Rdb.  (If you are running multi-version Rdb, then there are set-up tools that establish a pile of definitions in the user's job context for you.)  And when working with logical names, these make tools create subprocesses so DEFINE [/PROCESS] works when invoked at the top level, but the setting won't be maintained and won't propagate when invoked within a subprocess.

[Phil VanKley]

Good point on the rdb multiversion.  I am not running multi-version now but may down the road.  I'll look at implementing the process or job define approach in our build procedures.  Thanks so much for your assistance on this!

Phil

[Hoff]

>Only a sissy uses LNK$LIBRARY. (It's too easy to leave it defined, and mess up future link jobs.)

Ayup.  But that's also the OpenVMS way, what with examples including the LNK$LIBRARY* definitions, the DECC$* settings, ALPHA$LIBRARY and IA64$LIBRARY, the JAVA$* settings, the GNV logical names and environment settings and login files, and a whole host of similar context-specific and non-volatile settings that are around on VMS.  This is unfortunate; that none of this ever got rolled into an architected management interface.

[H.Becker]

>>> Obviously, it is doing more with this logical name than the explicit reference to SQL$USER/LIB I have on the link command line.  I don't understand enough about how the linker works, though, to know why.

Just look at HELP LINK /USERLIBRARY: The OLBs pointed to by LNK$LIBRARY are searched after all specified input files have been processed. You then specified SQL$USER once as an input file on the command line and a second time with this logical. The second search/processing of the OLB resolved the undefined symbols.

And yes, it is the same as if you had the same library a second time on the command line.