z/OS Dynamic Linking

A program call to a routine that resides in the same load module is known as static linking; a program call to a routine that resides in a separate executable is known as dynamic linking. CA Gen generates a COBOL CALL literal statement (CALL 'module') when calling routines that are statically linked and when calling routines that are dynamically linked..

Dynamic linking is implemented by CA Gen using a z/OS specific packaging option that indicates how a routine is built. The way in which the routine is built determines how it will be called. The specific dynamically link packaging property associated with each procedure step, screen, or action block (including external action blocks) identifies how that component is resolved during the installation of the CA Gen load module in which it is packaged.

The designation of the dynamically link packaging option for a procedure step, screen, or action block can be set to Default. In this case, the dynamically link packaging option is derived from the dynamically link packaging option established in the business system owning the CA Gen load module in which the given procedure step, screen, or action block is defined.

The following values can be explicitly set for each individual procedure step, screen, or action block (or if set to Default, the value is derived from their respective Dynamically Link packaging option obtained from the default value established in the Business System):

No-the routine is statically linked into the application.
Yes-the routine is resolved as the target of a dynamic program call and as such is considered to be dynamically linked at runtime. During the installation of the load module, those components that have their associated dynamically link packaging property set, or derived, to Yes are built so they reside in their own separately loadable executables. These application routines reside in DLLs.
Compatibility-the routine is resolved as the target of a dynamic program call and as such is considered to be dynamically linked at runtime. A routine designated as Compatibility will reside in a non-DLL executable.

A dynamic program call to a routine that resides in a DLL is invoked directly by the generated COBOL CALL statement. A dynamic program call to a routine that resides in a non-DLL module is indirectly invoked by CA Gen z/OS runtime.

Note: Every module that makes a dynamic program call to a routine marked for Compatibility must be regenerated and reinstalled to incorporate the call to the runtime routine that handles the indirect call processing.

For a module that was built before AllFusion Gen 7, identifying it for Compatibility allows that module to be dynamically called by a CA Gen routine that resides in a DLL.

It is possible to migrate procedure steps, screens, or action block routines that were built before AllFusion Gen 7 and must continue to reside in a non-DLL executable. CA Gen allows a module that is explicitly set to, or defaulted to, Compatibility to be built as a non-DLL executable. These migrated non-DLL executables use the same CA Gen z/OS runtime as those application routines that reside in DLLs.

The CA Gen Toolset, CSE, and Host Encyclopedia each provide an option that indicates whether modules marked for Compatibility should, or should not, be processed (generated and/or installed).

If the intent is to use routines created with a release of CA Gen before Release 7, then Process modules marked for Compatibility should not be set when generating and/or installing a load module that contains the item marked for Compatibility.
If the intent is to create a current version of the non-DLL routine, then Process modules marked for Compatibility should be set when generating, and installing a load module that contains the item marked for Compatibility. Selecting the Process modules marked for Compatibility check box causes the RI Trigger modules and all Action Blocks statically called by the module marked for Compatibility to be compiled twice-once using the compiler option NODLL and again using the compiler option DLL. If the Action Blocks are External Action Blocks, these must also be compiled with the NODLL option to be included in the Compatibility load module.
Note: For more information about Process modules marked for Compatibility option, see Process modules marked for Compatibility.

The Compatibility option is intended to enable a phased migration of an existing application. It allows routines that have been migrated and reside in DLLs to interoperate with routines that reside in non-DLL executables. The non-DLL executables can themselves be migrated and built using the current release of CA Gen or they can remain as is, having been built with a release of CA Gen before the Release 7.

Note: It is possible that feature enhancements offered in future releases of CA Gen may require that any routine making use of the feature be built such that it resides in a DLL.