The Gen z/OS Dynamic Program Call Compatibility feature and its datasets

Products

• Gen
• Gen - Host Encyclopedia

Issue/Introduction

This article describes the function of the Gen z/OS Dynamic Program Call Compatibility feature and its datasets.
See documentation references for "Process Modules Marked for Compatibility" e.g. under  Host Encyclopedia Construction > Generation Options Panel in HE

Environment

Gen 8.6 Host Construction

Resolution

This is how the Compatibility datasets are normally used.  Gen will normally compile static Action Blocks and RI Triggers twice.  The DLL version of these modules go in the normal NCAL dataset; the NODLL version of these modules go in the Compatibility NCAL dataset.

 

CMP modules are built as NODLLs, but not all NODLLs are CMP modules.

 

For example, if Action Block B is marked as a Statically called module (i.e., the Dynamic Link property is set to or defaults to No), then Gen will compile Action Block B twice - once as a DLL and once as a NODLL.  The DLL version of Action Block B will be put in the normal Internal NCAL dataset and the NODLL version of Action Block B will be put in the Compatibility NCAL dataset.  So even though Action Block B is not marked as a CMP module, Gen will build a NODLL version of it (in case it ever gets called from a NODLL module).

 

If Action Block B is called from Action Block A and Action Block A is built as a DLL module, then Gen will statically link the DLL version of Action Block B into Action Block A at link edit time.  If, on the other hand, Action Block A is built as a NODLL module, then Gen will statically link the NODLL version of Action Block B into Action Block A at link edit time.

 

And all of this special logic (i.e., compiling statically called modules/triggers twice, etc.) only happens if the "Process modules marked for Compatibility" option is selected at Installation time.

 

This is done because the statically called Action Block or RI Trigger might be called from a DLL module or a NODLL module.  If it is called from a NODLL module, then Gen will pick it up from the Compatibility NCAL dataset at link time.  If it is called from a DLL module, then Gen pick it up from the normal NCAL dataset at link time.

 

By definition, a CMP module is a dynamically called module.  So if all modules are set as CMP modules, then there are no Statically called modules and nothing will be put in the Compatibility NCAL dataset.  Everything will be put in the normal Internal NCAL dataset.

So in summary the only modules that should normally be in the Compatibility NCAL dataset are the NODLL versions of statically called modules.
These modules are put in this dataset in case they are ever called from a CMP or other NODLL module, so that they can be linked into that CMP or other NODLL module at link edit time.

Additional Information

Using the Sample Model as an example, everything is set to Static (i.e., the Dynamic Link property set to No).  When first building everything, all built modules went into the normal Internal NCAL dataset and the normal RI NCAL dataset.  This was because the "Process modules marked for Compatibility" option was not selected at Installation time.

Going back and building everything again and selecting the "Process modules marked for Compatibility" option at Installation time, then all Action Blocks went into both the normal Internal NCAL dataset and the Compatibility NCAL dataset.  All RI Triggers went into both the normal RI NCAL dataset and the RI Compatibility NCAL dataset.