Loading DLLs
When you load a DLL for the first time, either implicitly or by an explicit dllload() or dlopen(), writable static is initialized. If the DLL is written in C++ and contains static objects, then their constructors are run.
You can load DLLs from a UNIX file system as well as from conventional data sets. The following list specifies the order of a search for unambiguous and ambiguous file names.
- Unambiguous file names
- If the file has an unambiguous z/OS® UNIX file system name (it starts with a ./ or contains a /), the file is searched for only in the UNIX file system.
- If the file has an unambiguous MVS™ name, and starts with two slashes (//), the file is only searched for in MVS.
- Ambiguous file names
For ambiguous cases, the settings for POSIX are checked.
- When specifying the POSIX(ON) runtime option, the runtime library
attempts to load the DLL as follows:
- An attempt is made to load the DLL from the UNIX file system. This is done using the system service BPX1LOD. For more information on this service, see z/OS UNIX System Services Programming: Assembler Callable Services Reference.
If the environment variable LIBPATH is set, each directory listed will be searched for the DLL. See Using environment variables for information on LIBPATH. Otherwise the current directory will be searched for the DLL. Note that a search for the DLL in the UNIX file system is case-sensitive.
- If the DLL is found and contains an external link name of eight characters or less, the uppercase external link name is used to attempt a LOAD from the caller's MVS load library search order. If the DLL is not found or the external link name is more than eight characters, then the load fails.
- If the DLL is found and its sticky bit is on, any suffix is stripped off. Next, the name is converted to uppercase, and the base DLL name is used to attempt a LOAD from the caller's MVS load library search order. If the DLL is not found or the base DLL name is more than eight characters, the version of the DLL in the UNIX file system is loaded.
- If the DLL is found and does not fall into one of the previous two cases, a load from the UNIX file system is attempted.
- If the DLL could not be loaded from the UNIX file system, an attempt is made to load the DLL from the caller's MVS load library search order. This is done by calling the LOAD service with the
DLL name, which must be eight characters or less (it will be converted
to uppercase). LOAD searches for it in the following sequence:
- Runtime library services (if active)
- Job Pack Area (JPA)
- TASKLIB
- STEPLIB or JOBLIB. If both are allocated, the system searches STEPLIB and ignores JOBLIB.
- LPA
- Libraries in the linklist
For more information, see z/OS MVS Initialization and Tuning Guide.
- An attempt is made to load the DLL from the UNIX file system. This is done using the system service BPX1LOD. For more information on this service, see z/OS UNIX System Services Programming: Assembler Callable Services Reference.
- When specifying the POSIX(ON) runtime option, the runtime library
attempts to load the DLL as follows:
- When POSIX(OFF) is specified the sequence is reversed.
- An attempt to load the DLL is made from the caller's MVS load library search order.
- If the DLL could not be loaded from the caller's MVS load library then an attempt is made to load the DLL from the UNIX file system.
Recommendation: All DLLs used by an application should be referred to by unique names, whether ambiguous or not. Using multiple names for the same DLL (eg. aliases or symlinks) may result in a decrease in DLL load performance. The use of UNIX file system symbolic links by themselves will not degrade performance, as long as the application refers to the DLL solely through the symbolic link name. To help ensure this, when building an application with implicit DLL references always use the same side deck for each DLL. Also, make sure that explicit DLL references with dllload() or dlopen() specify the same DLL name (case matters for UNIX file system loads).
Changing the search order for DLLs while the application is running (eg. changing LIBPATH) may result in errors if ambiguous file names are used.