Overview of the IMS System Definition Process

The IMS system definition process comprises many steps. Some steps occur only for certain types of IMS definitions (see "Types of IMS System Definitions" on page 332). The basic steps involved in IMS system definition are:

1. Modify or tailor IMS-supplied macro statements and procedures (JCL) to define the IMS system that your business requires. These macro statements and procedures are the building blocks for your IMS system (see "IMS System Definition Macros" on page 335).

2. Run the IMS preprocessor to check the macros and procedures for correctness (see Figure 19-1).

   Figure 19-1. Overview of the Preprocessor Stage of the System Definition Process

   

   
   

3. Stage 1 assembly, in which you run the JCL that you modified in step 1 through the z/OS High Level Assembler program to assemble your program into the JCL that is required as input to stage 2 (see "Stage 1 of the IMS System Definition Process" on page 333).

4. Stage 2 assembly, in which you build the IMS executable load modules and, optionally, build MFS default formats and perform updates to IMS.PROCLIB (see "Stage 2 of the IMS System Definition Process" on page 333).

5. JCLIN, which is an SMP/E process that tells SMP/E how to assemble and bind modules (see "JCLIN Processing" on page 334).

6. Use the SMP/E APPLY command to process any maintenance that has not been processed using the SMP/E ACCEPT command (see "SMP/E Maintenance" on page 334).

7. Optionally, perform an IMS Security Maintenance utility generation, which generates a set of secured-resource tables (see "IMS Security Maintenance Utility Generation" on page 334).

Figure 19-2 on page 331 shows an overview of the stage 1 and stage 2 components of the system definition process.

Figure 19-2. Overview of Stage 1 and Stage 2 of the System Definition Process

Types of IMS System Definitions

There are seven different types of IMS system definitions. You use the IMSCTRL macro statement to describe the type of IMS system definition to be performed, the basic IMS control program options, and the z/OS system configuration under which IMS is to execute. The IMSCTRL options that specify the different types of system definitions are described in Table 19-1.

Table 19-1. Types of IMS System Definitions

IMSCTRL Option	When to Use	Description
BATCH	Only to define a batch environment.	Generates modules and procedures that are needed to build a complete batch IMS system.
MSVERIFY	Only appropriate for MSC.	Builds control blocks for the Multiple Systems Verification utility (DFSUMSV0).
MODBLKS	Use when online changes are required to the IMS system, such as changes to programs, transactions, and database definitions.	Generates control block members for resources to be added online (for example, APPLCTN, DATABASE, TRANSACT, and RTCODE macros).
CTLBLKS	Use to rebuild the existing IMS nucleus and to create communications definitions.	Generates modules for all IMS control blocks (for example, TERMINAL and LINE macros). The CTLBLKS type of system definition includes the MODBLKS and MSVERIFY types too.
NUCLEUS	Use when performing major maintenance that affects the contents of the IMS nucleus, or when a new nucleus with a new suffix is required.	Generates an IMS nucleus for the control region. The NUCLEUS type of system definition includes the CTLBLKS type too.
ON-LINE	Use to perform a major update, or during initial system definition. Often required for maintenance.	Builds all the modules and procedures needed for the online IMS environment. The ON-LINE type of system definition includes the NUCLEUS type too.
ALL	Use during a typical initial system definition. Often required for maintenance.	Builds most IMS modules and procedures. Includes BATCH and ON-LINE types too.

After your initial system definition, the ON-LINE, CTLBLKS, and NUCLEUS types of system definition can be used to implement changes. The ON-LINE, CTLBLKS, and NUCLEUS types of system definitions require a cold start of the IMS online system to take effect.

For certain changes to your IMS system, however, you can take advantage of the online change method using the MODBLKS type of system definition. With the MODBLKS type of system definition, the changes are made active during the execution of the online system and do not require a restart operation.

Related Reading: For the details about the different types of system definition, see "Using the Macro Table" in IMS Version 9: Installation Volume 2: System Definition and Tailoring.

Stage 1 of the IMS System Definition Process

Stage 1 of the system definition process uses the z/OS High Level Assembler program and uses the IMS macros as input, as described in "IMS System Definition Macros" on page 335. Other references are to the IMS distribution macro libraries (IMS.ADFSMAC).

The output from stage 1 of the IMS system definition process includes:

• Standard assembler listing output with any appropriate error messages.

• Stage 2 system definition input JCL, which is also used for the JCLIN process.

Depending on what is specified in the IMSGEN macro^[1] for stage 1, stage 2 of the system definition process can be divided up into a single job with multiple steps, or into many jobs with fewer steps.

^[1] You specify the assembler and binder data sets and options, and the system definition output options and features in the IMSGEN macro.

Stage 2 of the IMS System Definition Process

Stage 2 of the system definition process assembles and binds all the modules that are required to build the necessary load modules, depending on what type of system definition is being run.

The steps involved in stage 2 refer to the IMS distribution macro library (IMS.ADFSMAC) at assembly time, and the distribution load library (IMS.ADFSLOAD) at bind time.

The output of stage 2 of the system definition process includes:

• Executable load modules in data sets IMS.SDFSRESL and IMS.MODBLKS.

• IMS options definitions in the data set IMS.OPTIONS.

• Assembled object code for use in later system definition steps in the data set IMS.OBJDSET.

• Optionally, the runtime IMS. PROCLIB data set.

  The PROCLIB= parameter in the IMSGEN stage 1 macro determines whether the IMS.PROCLIB data set is to be populated by this system definition. The IMS.PROCLIB library contains IMS started tasks and JCL procedures, as well as the IMS.PROCLIB members required by IMS and IMS utilities to provide options.

• Optionally, the runtime IMS default MFS screens in data sets IMS.FORMAT, IMS.TFORMAT, and IMS.REFERAL.

  The MFSDFMT= parameter in the IMSGEN stage 1 macro determines whether the default message format screens are built as part of stage 2 of the system definition process.

JCLIN Processing

Because the stage 2 system definition process actually assembles and binds the IMS modules based on the definitions for that particular system and is run outside of SMP/E control, the input JCL for system definition stage 2 must be used as input to the JCLIN process. This input JCL ensures that SMP/E knows how to manage any maintenance that is added to the system following this IMS system definition.

Run the JCLIN process following any IMS system definition, to ensure that SMP/E is always synchronized with the updated IMS.

SMP/E Maintenance

All IMS system definitions use the IMS SMP/E distribution libraries and the IMS stage 1 macros as input. As a result, any SMP/E maintenance (SYSMODs - PTFs, APARs or USERMODs) that processed using the SMP/E APPLY command, but not processed using the SMP/E ACCEPT command, prior to an IMS system definition, might be regressed as a result of that IMS system definition, depending on the type of IMS system definition, and the impact of the SYSMOD.

Recommendation:

Any maintenance that has been processed using the SMP/E APPLY command, but not processed using the SMP/E ACCEPT command, should be processed again (using both commands) following an IMS system definition, unless further investigations have shown specific cases where this is not necessary.

Related Reading: For more information about performing SMP/E maintenance on IMS, see "IMS Service Considerations" in IMS Version 9: Installation Volume 1: Installation Verification.

IMS Security Maintenance Utility Generation

For security beyond that provided by default terminal security, you can use the various security options provided by the Security Maintenance utility (SMU) or by RACF (or equivalent product). You define the RACF security for IMS resources outside of the IMS system definition process.

The SMU is executed offline after the completion of stage 2 of the system definition process. The output of the SMU is a set of secured-resource tables, which are placed in the MATRIX data set. The tables are loaded at system initialization time and, for certain options, work with exit routines and RACF during online execution to provide resource protection.