System definition summary

SFIMS from the previous example can be defined to NYIMS as shown in the following example.

TYPE     UNITYPE=LUTYPE6
TERMINAL NAME=SFIMS
     COMPT1=(SINGLE1, DPM-B1, IGNORE)
     COMPT2=(SINGLE2, DPM-B2, IGNORE)
     SESSION=4
VTAMPOOL
SUBPOOL NAME=SF1
   NAME SF1LT1, COMPT=1
SUBPOOL NAME=SF2
   NAME SF2LT1, COMPT=2
SUBPOOL NAME=SF3
   NAME SF3LT1, COMPT=2
SUBPOOL NAME=SF4
   NAME SF4LT1, COMPT=2

This definition does not correspond exactly to the figure in Statically defining an ISC node to IMS. In that figure, the SUBPOOL SF1 contains multiple LTERMs (to indicate that multiple LTERMs can be assigned to a SUBPOOL). Based on SINGLE1, SINGLE2, MULT1, and MULT2, the definition can now be simplified to show just one LTERM being defined per SUBPOOL.

The first SUBPOOL, SF1, has LTERM SF1LT1 defined with COMPT=SINGLE1. For asynchronous output from NYIMS to SFIMS, LTERM SF1LT1 is used as the destination LTERM for all:
  • Alternate PCB output from application programs in NYIMS that generates asynchronous transactions in SFIMS
  • Message switches originated by a terminal connected to NYIMS
  • Replies to nonresponse transactions received by NYIMS from SFIMS

The characteristics of SINGLE1 (BB/message/EB) should allow one parallel session to handle all asynchronous input and output between NYIMS and SFIMS.

Three SUBPOOLS (SF2, SF3, SF4) have been defined with single LTERMs, each defined with a COMPT defined as SINGLE2. These three SUBPOOLS (sessions) can be used to send response mode transactions to SFIMS. Because of the nature of response mode transactions (session tied up from transaction origination until receipt of reply), three parallel sessions are defined to allow the user to minimize response mode bottlenecks between NYIMS and SFIMS.

In most IMS ISC definitions, the assignment of one LTERM to each SUBPOOL is sufficient to handle the communications traffic between the two nodes.

Not shown, but certainly to be considered, is the possibility of defining a fifth SUBPOOL within NYIMS to handle incoming SINGLE1 traffic from SFIMS. By design then, NYIMS could receive all SINGLE1 input from SFIMS on the session defined by the fifth SUBPOOL and send all SINGLE1 output on the session defined by the first SUBPOOL (SF1). This plan would result in minimal contention for asynchronous output between the two systems.