Implementing External Action Blocks › Construction › Compile the External Action Block › Dynamic Link Options

Dynamic Link Options

CA Gen components that can be linked into a load module include procedure steps, screens, action blocks (including External Action Blocks), referential integrity triggers, and some CA Gen runtimes. Most of the CA Gen runtimes are now built as DLLs, so they are no longer included in each of the CA Gen load modules.

Note: The term Load Module is used in the Packaging process as a generic way to refer to the set of application code that is contained in a fully resolved executable application. Starting with AllFusion Gen 7, z/OS applications are built as fully resolved executables residing in DLLs, except for those application components marked for Compatibility. Components marked for Compatibility are built as z/OS non-DLL load modules. Before AllFusion Gen 7, z/OS executables reside in z/OS load modules.

CA Gen's dynamic link feature lets selected generated components be linked dynamically when used at runtime rather than being statically linked into the load module when the load module is built. The use of the dynamic link feature has the potential to reduce total memory and CPU resources required by a TP monitor to process a load module. Dynamic linking common routines eliminates the need to link all of the load modules that use it but applications generated for DB2 require a bind or rebind.

The key features and requirements are:

• Only procedure steps, action blocks, and screens can be linked dynamically.
• Each dynamic linked module must be a fully resolved module.
• If this fully resolved module is a DLL, this means Referential Integrity triggers, other action blocks statically linked with a procedure step, screen, or action block must be compiled as DLL and with the applicable CA Gen runtimes must be linked into each dynamic linked DLL.
• If this fully resolved module is a module marked for Compatibility, this means Referential Integrity triggers, other action blocks statically linked with a procedure step, screen, or action block must be compiled as NODLL and with the applicable CA Gen runtimes must be linked into the Compatibility load module.
• The dynamically link packaging property of individual procedure steps, screens, and action blocks can be set to Default. Default indicates that the value of the dynamically link property for that component is determined by the corresponding default setting, which is established at the business system level.
• Marking a module for Compatibility causes its calling module to be generated and installed so that it processes the call using a module provided as part of the CA Gen runtime. The runtime code performs the dynamic program call to the non-DLL load module. In the cases where a module marked for Compatibility issues a dynamic program call to another non-DLL dynamic load module, only the module issuing the first dynamic program call to a Compatibility module requires generation and installation.
• Applications that run under TSOAE and contain modules marked for Compatibility cannot dynamically call modules built with a release prior to AllFusion Gen 7.6.
• Enhanced Map Block Mode applications containing screens marked for Compatibility cannot dynamically call screen managers built with a release before AllFusion Gen 7.6.
• Modules marked for Compatibility must follow standard OS or LE linkage conventions and must operate in the same AMODE as the caller. These modules must be non-DLL and must be stand-alone, fully resolved programs, eligible for a dynamic, OS style call.
• The ability to call a procedure step, action block, or screen dynamically allows application changes to become effective without having to link every load module using these modules. However, changes made to a module that uses DB2 SQL requires that the DB2 plan corresponding to the load module containing that module be rebound.
• In CICS, a PPT entry is required for each module called dynamically. For more information about defining CICS programs, see CICS documentation.