Dynamic Loading

Enhanced Definition

Dynamic loading in the z/OS environment refers to the process of loading an executable program module, subroutine, or data into memory during the execution of another program, rather than at the initial program load or link-edit time. This allows programs to access and execute code that was not explicitly linked with them, providing flexibility and efficient resource utilization. In the z/OS environment, **Dynamic Loading** refers to the process where an executable program module (a load module or program object) is loaded into virtual storage *during* the execution of another program, rather than being linked at compile or link-edit time. This allows programs to access and execute routines or data structures that were not part of their initial static binding, promoting modularity and flexibility.

Key Characteristics

- Runtime Resolution: The specific module to be loaded is determined and loaded into memory only when it is needed by the executing program.
- Memory Efficiency: Only required modules are loaded, reducing the overall memory footprint compared to static linking where all potential modules are loaded upfront.
- Flexibility: Allows a program to conditionally load different versions of a module or entirely different modules based on runtime conditions, user input, or configuration settings.
- System Services: Typically involves z/OS system services, often invoked via LOAD and DELETE (or RELEASE) macros in assembler, or language-specific constructs (e.g., CALL with a variable program name in COBOL, or dlopen/dlsym in C/C++).
- Search Order: z/OS searches for dynamically loaded modules in a predefined order, including JOBLIB, STEPLIB, LINKLIB (or LNKLST), and APF-authorized libraries, depending on the context.
- Reusability: Loaded modules can often be shared among multiple concurrently executing programs or tasks, especially if they are reentrant.

Use Cases

- Conditional Subroutine Execution: A COBOL program might dynamically load and call a specific calculation routine based on a transaction type or customer segment, rather than linking all possible routines.
- CICS Program Management: CICS heavily relies on dynamic loading to bring application programs into its address space as transactions are initiated, optimizing memory usage and allowing for easy program updates without stopping CICS.
- Exit Routines and Plug-ins: System utilities or applications can be designed to dynamically load user-written exit routines or plug-in modules to extend their functionality without modifying the core application.
- Language Environment (LE) Services: LE runtime libraries and services are often dynamically loaded as needed by COBOL, PL/I, C/C++, and Fortran programs.
- Version Control and Maintenance: Allows for updating specific program modules (e.g., a business rule engine) without requiring the recompilation and relink of the entire application, simplifying maintenance and deployment.

Related Concepts

Dynamic loading is often contrasted with static loading, where all necessary program modules are resolved and bound together into a single executable load module during the link-edit process. It leverages Program Management facilities within z/OS to locate and load modules from Program Libraries (PDS or PDSE datasets), which are typically defined in STEPLIB, JOBLIB, or LNKLST concatenations. In CICS, dynamic loading is a fundamental mechanism for managing application programs and ensuring efficient resource sharing across transactions. The CALL statement in COBOL, when used with a variable program name, is a common high -level language construct that triggers dynamic loading.

Best Practices:

Manage Library Concatenations: Carefully define STEPLIB or JOBLIB to ensure that the correct versions of dynamically loaded modules are found and that the search order is efficient. Avoid excessively long concatenations.
Error Handling: Implement robust error handling for LOAD failures (e.g., module not found, insufficient memory) to prevent program abends.
Authorization: If dynamically loading modules that require special privileges (e.g., APF-authorized libraries), ensure the calling program and the loaded module meet the necessary security requirements.
Performance Considerations: While flexible, dynamic loading incurs I/O overhead. For frequently called, small, or critical routines, static linking might offer better performance.
Memory Management: Use DELETE or RELEASE (or equivalent language constructs) to free the memory occupied by dynamically loaded modules when they are no longer needed, especially for modules loaded into the user's private storage.
Reentrancy: Design dynamically loaded modules to be reentrant if they are expected to be shared by multiple concurrent tasks or programs, to ensure data integrity and efficient memory usage.