The decision to dynamically link CA Gen modules, as opposed to generating one executable load module by means of a static link, should be based on the following factors:
CA Gen creates DLLs with the exception of 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 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 as specified in z/OS Application Migration section in the Release Summary. RI triggers and action blocks, including EABs, statically called by Compatibility modules must be built using the NODLL compiler option. When these RI triggers and action blocks are also be used in CA Gen applications that are built as DLLs, they must be compiled using the DLL option.
Selecting the option Process modules marked for Compatibility causes the RI triggers and the statically called action blocks to be generated and precompiled once but compiled twice-once as NODLL and again as DLL.
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 both static and dynamic linked CA Gen modules.
A dynamic linked module must be fully resolved and include any component 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 built by CA Gen so they do not increase the size of these modules.
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.
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 required during execution.
Dynamic linking may be 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 called infrequently are exception handling routines and processing options that are rarely selected by the user.
|
Copyright © 2013 CA.
All rights reserved.
|
|