Specify Target Environment for HE › Dynamic Link Features and Considerations

Dynamic Link Features and Considerations

Using dynamic linking can reduce total memory and CPU resources that are required by a TP monitor to process a load module. Dynamic linking common routines eliminate the need to link all of the load modules that use it. Applications that are generated for DB2 require a bind or rebind.

The key features and requirements are:

• Only procedure steps, action blocks, and screens can dynamically link.
• Each dynamic linked module must be a fully resolved module.

  If this fully resolved module is a DLL, the Referential Integrity triggers and statically called action blocks in 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, the Referential Integrity triggers and action blocks that are called statically within a procedure step, screen, or action block must be compiled as NODLL and with the applicable CA Gen runtimes must be linked into the dynamic linked 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 that is 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 that are marked for Compatibility cannot dynamically call modules that are built with a release before AllFusion Gen 7.6.
• Enhanced Map Block Mode applications containing screens that are marked for Compatibility cannot dynamically call screen managers that are built with a release before AllFusion Gen 7.6.
• Modules that are 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 that is called dynamically. For more information about defining CICS programs, see CICS documentation.

The decision to dynamically link CA Gen modules, as opposed to generating one executable load module with a static link, is based on the following factors:

• Compatibility—CA Gen creates DLLs except for those modules marked for Compatibility. The Compatibility option uses specific CA Gen runtime to enable DLLs to issue a dynamic program call to non-DLL load modules. This requires that the module issuing the dynamic program call be regenerated and reinstalled.
• CA Gen allows modules that are marked for Compatibility to be rebuilt in such a way that they are able to use CA Gen runtime DLLs. This requires that the modules marked for Compatibility be reinstalled and, if necessary, regenerated.

  RI triggers and action blocks, including EABs, statically linked into Compatibility modules must be built using the NODLL compiler option. When these RI triggers and action blocks are also used in CA Gen applications that are built as DLLs, they must be compiled using the DLL option.

  Selecting the option Process modules that are marked for Compatibility causes the RI triggers and the statically linked action blocks to be generated and precompiled once but compiled twice – once as NODLL and again as DLL.

• DLLs—The CA Gen runtimes are DLLs. These DLL runtimes are no longer included in generated modules, except for a few that are statically linked with the CA Gen Batch, Online, or Server Managers. This applies to static and dynamic linked CA Gen modules.
• Size—A dynamic linked module must be fully resolved and include components that it calls using a static call. This includes some CA Gen runtimes and Referential Integrity triggers. When more than one dynamic linked modules use the same RI modules, these RI modules are included in each dynamic linked module. Most of the CA Gen runtimes are no longer included in each of the DLL applications that are built by CA Gen so they do not increase the size of these modules.
• Volatility—When a static linked module is changed, the calling module containing the statically linked module must be relinked. Linking a frequently changed module dynamically eliminates the requirement to link every load module that calls it.
• Shared modules—Action blocks that are widely reused within an application environment are good candidates for dynamic linking. Linking a shared module dynamically decreases the amount of storage that is required during execution.
• Frequency of use—Dynamic linking is considered for load modules that are invoked infrequently. Dynamic linking modules that are called infrequently would decrease the size of the base load module. Examples of modules that are called infrequently are exception handling routines and processing options that are rarely selected by the user.