CA Gen generates different COBOL code when calling a routine that is statically linked within an executable as opposed to when calling a routine that resides in a separate executable. For calls to routines that are statically linked within an executable, CA Gen generates a COBOL CALL literal statement. For calls to routines that reside in an executable separate from the calling executable, CA Gen generates a COBOL CALL identifier statement that references a variable. The variable contains the name of the routine that is to be dynamically invoked. A program call to a routine that resides in a separate executable is known as dynamic linking.
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):
The routine is statically linked into the application.
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.
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).
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. 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.
|
Copyright © 2013 CA.
All rights reserved.
|
|