Implicitly Linking to Server Libraries

Initiating Implicit Linkage

Library linkage typically occurs when the client process first uses an object imported through a particular client library. For example, suppose a client process has import declarations for three procedures, PROC1, PROC2, and PROC3, which all come from client library LIB1. Note that the order in which these imports are declared might not be the same as the order in which they are invoked. Thus, PROC1 might be declared first, but the client process might invoke PROC3 first. In this case, the linkage of client library LIB1 to a server library is implicitly requested by the attempt to invoke PROC3.

Allowing or Preventing Implicit Linkages

The AUTOLINK library attribute determines whether such implicit linkage attempts are allowed. If AUTOLINK is FALSE, the linkage fails and the client process incurs a fatal error. If AUTOLINK is TRUE (which is the default for client libraries), then the system proceeds with an attempt to link the client library to the server library.

Missing Server Library

If the requested server library program cannot be found, the client process becomes suspended at this point. If the LIBACCESS value is BYTITLE, then a “NO LIBRARY” message is displayed as the RSVP message. If the LIBACCESS value is BYFUNCTION, and the FUNCTIONNAME library attribute requests a function name that does not exist, the RSVP message is “FUNCTION <function name> IS NOT DEFINED, SL, FA, OR DS.”

Missing Object in Library

If the requested server library program is found, the system links the client library to an existing instance of the server library or initiates a new instance as discussed under Implicitly Initiating a Server Library later in this section. The system then determines if the requested object is exported by the server library. If the requested object is not available, the system returns one of the errors discussed under Matching Client and Server Library Objects later in this section.

Missing Objects and Indirect or Dynamic Provision

If the requested object is provided indirectly or dynamically, then linkage can succeed even if the object is not available for use. This behavior is possible because indirect and dynamic linkage involve one or more intermediate libraries— aside from the library that ultimately provides the object. The requested object might be exported by an intermediate library, and still not be available from the library that is ultimately supposed to provide the object.

For example, suppose client library CL1 imports procedure PROC1 from server library SL1. Server library SL1 provides PROC1 indirectly by importing it from server library SL2. Now suppose that server library SL2 is unable to freeze or does not export a procedure called PROC1. In this case, the system successfully links CL1 to SL1. However, an error occurs if CL1 attempts to invoke PROC1. CL1 could prevent this error by using the ISVALID function before invoking PROC1; refer to Matching Client and Server Library Objects later in this section.