IMS facilities available to ISC

Distributed transaction processing

When supporting distributed transaction processing, IMS can be either the front-end or back-end processor. A front-end subsystem originates communications traffic (transactions, commands, or message switches) that are to be processed by the back-end subsystem. A message is typically the result of data entered at a terminal. However, the message can also result from processing that occurred in an application within the front-end subsystem. The back-end subsystem processes input messages from another subsystem.

In the most typical configuration, IMS is the back-end system and processes IMS transactions that another subsystem enters.

In addition, the Front-End Switch exit routine provides special support for front-end or back-end system utilization when ISC VTAM® is used. ISC TCP/IP does not support the Front-End Switch exit routine.

Sometimes, transactions entered into an IMS front end are sent with an ISC message switch to the other subsystem. In this case, the terminal operator or MFS provides the message routing information. The transaction can also be sent as alternate program communication block (PCB) output, in which a user-written application program or MFS format definition provides the routing information.

The fact that IMS is a queued subsystem is a key factor in determining the ISC functions that it supports, particularly when IMS acts as a front-end processor. Messages created by a terminal operator or an application in a front end IMS are queued for transmission to the receiving subsystem and sent asynchronously with respect to the terminal or application that sent the message. A terminal attached to an IMS front-end is not held in response mode during the receiving (back-end) subsystem's processing, unless it uses both ISC VTAM and the Front-End Switch exit routine (DFSFEBJ0).

Distributed services

IMS supports distributed services by providing remote access to an IMS message queue. Although IMS does not support distributed DL/I calls, a DL/I database in one subsystem can be updated by another subsystem; this action requires the sending subsystem to invoke an updating application in the receiving subsystem.

IMS transaction types

If you are using ISC with TCP/IP, some limitations can apply to the ISC support for the transaction types in the preceding list. For more information, see Functions available to an ISC TCP/IP session.

IMS execution modes

If you are using ISC with TCP/IP, only non-response or non-conversational mode is supported. For more information, see Functions available to an ISC TCP/IP session.

IMS editing facilities

These editors can be selected on a message-by-message basis.

ISC message integrity

Message integrity is provided to prevent loss or duplication of input or output messages between IMS and another half session during session restart.

Message integrity and recovery are increased by log write-ahead (LWA). This facility is invoked during system definition by an option on the TRANSACT macro. LWA ensures that sync point information is written to the log (and thus available to IMS restart procedures) before IMS acknowledges the message. More information on message integrity can be found in the Resynchronizing sessions and Sync point and response requirements topics.

ISC security

IMS security facilities control access to IMS resources by another subsystem. Before implementing ISC security in IMS, examine the data protection facilities of the subsystems and associated operating system components. Some important ISC-environment security factors are described there.

Terminal operator verification and authorization are provided by the subsystem controlling that terminal connection.

Both IMS terminal and password security can be defined for static ISC terminals by using resource access control facility (RACF®). If password security is defined, a password must be provided with the input message.