Previous Topic: Module DefinitionNext Topic: Creating Modules


Module Format

Module format provides significant performance benefits. In all environments, loading a module is more efficient than loading the corresponding VLS object member. Under CICS, the reentrant portion of a program or panel is loaded and released by each CA Ideal transaction that needs it. This allows CICS to optimize the use of CICS storage. CICS keeps modules specified as non-resident (CICS) with a use count of 0 in storage (DSA) only if CICS is not constrained for storage. Since CICS is in control of the whole region or partition (while CA Ideal is not), decisions about when to retain modules and when to swap them out can be made more effectively at the CICS level.

Application program load modules can be linked in 31-bit mode allowing the reentrant and non-updateable modules to reside in CICS extended storage. This decreases I/O to the libraries the modules reside in and the DSA it requires to load them.

Because CICS is managing the storage used for programs and panels, the CA Ideal RUN-STATUS of PRIVATE, SHARED, or RESIDENT is ignored for programs and panels in module format.

In addition, module format provides the following benefits:

The application programs and panels cannot run outside the CA Ideal environment. If attempted, an S0C3 (z/OS) or Execute Exception (VSE) occurs. To execute a module format application, the user must still sign on to CA Ideal and execute a RUN command.

At transaction boundaries, a copy of the updateable portion of a program or panel is saved in extended storage. The original module remains in extended storage (RDSA)

The following sections describe the preceding issues in detail.