Previous Topic: Migrating from Release 7Next Topic: EAB Migration


Migrating from 6.5 and Earlier Releases

When migrating from releases earlier than AllFusion Gen 7 to CA Gen 8.5, evaluate which application components can become DLLs and which must remain as non-DLL load modules.

Note: It is possible that feature enhancements offered in future releases of CA Gen require that routines reside in a DLL to use those features.

Some of the components of applications that can become DLLs need to be regenerated and all the components need to be recompiled and relinked regardless of the application type (block mode or servers) or the type of linkage (static or dynamic program call) used between application components.

The following table describes the actions required:

Application Type

Component Requiring Regeneration

Component Requiring Reinstall (Recompile and Re-link)

RI triggers

None

All components

Batch

Batch Manager

All Components

TSO block mode,

standard map

Dialog Manager

All Components

TSO block mode,

enhanced map

Dialog Manager and Map

All Components

IMS block mode,

standard map

Dialog Manager

All Components

IMS block mode,

enhanced map

Dialog Manager and Map

All Components

CICS block mode,

standard map

Dialog Manager

All Components

CICS block mode,

enhanced map

Dialog Manager and Map

All Components

IMS server

Server Manager

All Components

CICS server

Server Manager

All Components

Components that need to remain as non-DLL load modules must use the CA Gen 8.5 z/OS Dynamic Program Call Compatibility feature.

This feature allows a phased migration of applications built by releases of AllFusion Gen before release 7, that use dynamically called procedure steps, screens, or action blocks (including EABs). The Compatibility setting causes the caller of a module marked for compatibility to always be regenerated and reinstalled, to include a call to the runtime routine that handles the call to the non-DLL load module. The option Process modules marked for Compatibility determines what components are rebuilt as release 8.5 non-DLL load modules. The option Process modules marked for Compatibility can be selected to regenerate and reinstall the components or just to reinstall them. The reinstall is required to enable the non-DLL load modules to use the CA Gen 8.5 DLL runtimes.

RI triggers and action blocks that are statically called by modules marked for Compatibility must be built using the NODLL compiler option. If these RI triggers and action blocks are also used in Gen applications that are built as DLLs they need to be compiled using the DLL option. Selecting the Process modules marked for Compatibility option causes the RI triggers and any action blocks statically called by modules marked for Compatibility to be generated and precompiled once but compiled twice. Separate libraries are provided in the target environment to hold the separate NCAL modules resulting from the two compile steps.

Applications that run under TSOAE and contain modules marked for Compatibility cannot dynamically call modules built with a release before CA Gen 8.5.

Enhanced Map Block Mode applications containing screens marked for Compatibility cannot dynamically call screen managers built with a release before CA Gen 8.5.

Important! Ensure that runtimes from previous releases are not inadvertently picked up from the SYSLIB concatenation through an auto-call. The CA Gen 8.5 load library contains all the required runtimes. Load libraries from previous releases must not be included in the SYSLIB concatenation.

CA Gen 8.5 runtimes and generated code must reside in PDSE libraries. When migrating from previous releases of CA Gen using the Implementation Toolset, ensure that the Business System data sets specified for the NCAL, EXE, IMPL, RI Load Lib and, if used, the Static NCAL, Static RI NCAL or Static External Action Block libraries are allocated as PDSEs before processing the release 7.6 script.