Statically defining an ISC node to IMS

A subsystem that is statically defined at system definition to IMS as an ISC node appears to IMS to be a terminal and to an IMS application program to be one or more logical terminals (LTERMs). Thus, an ISC node is defined using those system definition macros applicable to defining other VTAM® terminals.

The following table shows the macro statements that define an ISC node.
Table 1. Macro statements for defining an ISC node
Macro statement Use
COMM macro Names the IMS subsystem to VTAM; names the ISC edit process and defines the receive-any (RECANY) buffer size.
TYPE macro Identifies the unit type as an ISC node (UNITYPE=LUTYPE6).
TERMINAL macro Identifies the other ISC node to IMS. Also provides sizes for the output and Fast Path buffers, limits for the input segment size, and processing options. Defines the number of sessions possible between two ISC nodes. Describes component characteristics.
VTAMPOOL macro Begins the definition of the ISC LTERM users (subpools) used with parallel sessions.
SUBPOOL macro Defines a set of LTERMs within the VTAMPOOL.
NAME macro Names the LTERMs associated with a given terminal for a single session or a given user (subpool) for parallel sessions.

This topic more fully describes the macros that are key to defining an ISC session between two systems and some of the implications of selecting certain system definition options instead of others.

The following figure shows two IMS systems, NYIMS in a New York data center and SFIMS in a San Francisco data center. NYIMS and SFIMS are each defined to the other as an ISC node. The following paragraphs details the way in which these IMS systems would be defined during IMS system definition. For ease of understanding, this description focuses on defining the IMS SFIMS to the IMS NYIMS. A similar system definition would be required to define IMS NYIMS to IMS SFIMS. Only those parameters of interest on the COMM, TERMINAL, and NAME macro statements are described.

Figure 1. Two IMS systems defined to each other as ISC nodes
SFIMS has four subpools: NY1 to NY4. Four parallel sessions link the subpools in SFIMS to four subpools in NYIMS, SF1 to SF4. Subpool SF1 in NYIMS links to LTERMs SFLT1 through SFLTn.

The parameter APPLID=NYIMS on the NYIMS system definition COMM macro makes that subsystem known by the node name NYIMS to VTAM, to itself, and to any other subsystems that need to access it. A similar system definition must occur for the San Francisco IMS SFIMS.

NAME=nodename on the TERMINAL macro statement of the NYIMS system definition is coded to show the node name of the SFIMS system (NAME=SFIMS). If SFIMS is an XRF complex, the node name should be the USERVAR or MNPS ACB associated with the SFIMS system.

The SESSION= keyword is related to parallel sessions rather than to a single session. (The SESSION= keyword applies to statically defined terminals only. It does not apply to the ETO environment.) SESSION= specifies the maximum number of parallel sessions that are allowed from NYIMS to SFIMS. It is possible to code one parallel session. A single session and one parallel session are not the same.

By coding SESSION= as greater than one, the NYIMS might maintain multiple concurrent sessions with SFIMS, up to the number specified by the SESSION= parameter. In the figure above, four paths are drawn between the two IMS systems. Each path represents a parallel session. To allow four parallel sessions in the NYIMS, code SESSION=4.

A major advantage of parallel session support is the ability to dynamically allocate LTERMs to that session based on the IMS /OPNDST command parameters.

Each parallel session is required to be identified to NYIMS using the SUBPOOL macro statement. In the example, to allow four concurrently active parallel sessions, four users (subpools) must be defined as follows in the NYIMS system definition: 
VTAMPOOL
    SUBPOOL   NAME=SF1
    SUBPOOL   NAME=SF2
    SUBPOOL   NAME=SF3
    SUBPOOL   NAME=SF4

The VTAMPOOL macro statement begins the definition of the ISC subpools and must be coded if parallel sessions are to be used. The VTAMPOOL macro statement has no operands.

In Figure 1 SFLT1, SFLT2, SFLT3,...SFLTn represent LTERM names that have been defined to the first SUBPOOL, SF1. The definition of LTERMs within a given subpool is accomplished by coding the NAME macro. Defining multiple LTERMs to a subpool provides several advantages. The first is that an LTERM or LTERMs defined to a given subpool can be reassigned (using the /ASSIGN command) to any other subpool. This capability gives flexibility in the operation of an ISC network.

The second advantage is with the COMPTn= keyword on the TERMINAL macro statement. This keyword can be used to define or assign certain characteristics to a given LTERM. COMPT= and ICOMPT= are the keywords on the NAME macro statement and are used to associate a component (COMPTn) with an LTERM.

The definition of SFIMS to NYIMS now looks like the following code:

TYPE     UNITYPE=LUTYPE6
TERMINAL NAME=SFIMS
         SESSION=4
 
VTAMPOOL
    SUBPOOL NAME=SF1
        NAME SF1LT1
        NAME SF1LT2
        ⋮
        NAME SF1LTN
    SUBPOOL NAME=SF2
        ⋮
    SUBPOOL NAME=SF3
        ⋮
    SUBPOOL NAME=SF4
        ⋮