Considerations for IMS-to-IMS ISC sessions

Coexistence of ISC and MSC VTAM within one IMS subsystem

During IMS system definition, the TERMINAL, the MSPLINK macro statement, a dynamic CREATE MSPLINK command, or an ETO logon descriptor of one IMS subsystem must be defined with the same name as that defined on the COMM (ACB name) macro of the other IMS system.

IMS system definition allows both the dynamic CREATE MSPLINK command (or stage-1 system definition MSPLINK macro) and TERMINAL macros or an ETO logon descriptor to indicate the same remote subsystem name. However, the session qualifier information (the name used on the SUBPOOL macro and the partner-id parameter on the dynamic CREATE MSPLINK command or stage-1 system definition MSPLINK macro) must be unique. This allows MSC and ISC sessions to be defined and simultaneously active between two IMS subsystems. The number of ISC parallel sessions that can be active simultaneously between two IMS subsystems is the smaller of the values defined for the SESSION= parameter of the TERMINAL macro statements of the two IMS subsystems. (The SESSION= parameter is for statically defined terminals only.) The number of MSC parallel sessions that can be active simultaneously between two IMS subsystems is the smaller of the values defined for the SESSION= parameter of the dynamic CREATE MSPLINK commands (or stage-1 system definition MSPLINK macros) of the two IMS subsystems. The total number of MSC and ISC parallel sessions that can be simultaneously active is the sum of these two smaller numbers.

Defining single and parallel sessions

During IMS system definition, the TERMINAL macro statements or the ETO logon descriptors defining the ISC session(s) between the IMS subsystems must be defined identically as either single session or parallel sessions. However, when both subsystems are defined for parallel sessions, the number of concurrently active sessions or number of SUBPOOL macro statements need not be identical.

Without ETO, you can define up to 4,095 parallel sessions. With ETO, the number of ISC parallel sessions is limited primarily by the processor capacity and the amount of virtual storage above and below the line available to the control region.

Ensuring compatible buffer sizes

The VTAM® output buffer size defined on the TERMINAL macro statement or an ETO logon descriptor of one IMS subsystem must be compatible with the receive-any buffer size defined on the COMM macro statement of the other subsystem.

Remote control of IMS through ISC

The IMS ISC message switch support or user-written applications allow a terminal operator within one IMS subsystem to effectively control the operation of another IMS subsystem. The IMS automated operator interface (AOI) facility can also be used to aid in the control of either IMS subsystem.

For statically defined terminals, you can authorize commands or transactions to ISC sessions within the remote IMS subsystem; all terminal operators and application programs within the local IMS subsystem that are authorized to send data on the ISC session can then access the remote subsystem. Therefore, use password security to restrict remote subsystem access to only specific authorized individuals and applications as a master terminal within the IMS subsystem.

You can provide additional security by specifying that all commands on the ISC session be issued between automated operator interfaces in both subsystems or issued to a single automated operator interface in the back-end subsystem.

A logical unit type 6.1 cannot be defined as the IMS master terminal during IMS system definition, nor can it be assigned as a master terminal using the IMS /ASSIGN command.

Restriction on IMS-to-IMS conversation mode

Conversation mode between two IMS subsystems is not supported. This is because conversations between IMS subsystems that are connected using ISC produce unpredictable session protocols and conversational transaction input when only one half session is in conversation mode. Further, the conversation terminates if both half sessions are in conversation mode.

Routing transactions to the back-end IMS

In either case, the default action by the ISC support is to route a resulting transaction reply, in the form of a message switch, back to the originating terminal operator or transaction. Under these conditions, the transactions accessed within the back-end IMS subsystem should generally be defined as recoverable, because the response required for the message switch reply is also recoverable.

Irrecoverable transactions can be accessed, but require the use of MFS DPM-Bn to change the default destination set in the ISC message routing parameters from the LTERM associated with the originating terminal operator to an irrecoverable transaction within the front-end IMS. This avoids the protocol errors that occur when sending irrecoverable reply messages. The destination can be changed by MFS DPM either within the front-end IMS to modify or delete the default RPRN parameter sent on the transaction to the back-end IMS, or within the back-end IMS to modify or delete the wrapped PRN parameter sent on the reply to the front-end IMS. This irrecoverable transaction can then route the reply to the appropriate terminal operator by inserting to a modifiable alternate PCB.

Special support exists for front-end/back-end system utilization provided by the Front-End Switch exit routine.

Sending messages between the subsystems

Communication from an IMS front-end is always asynchronous. Therefore, messages are required to be sent and received with both the ATTACH and SCHEDULER FM headers. The exception to this is that system messages are sent with the ATTACH FM header only.

Protocol restrictions on IMS-to-IMS sessions