Using DL/I calls in an OTMA environment

CHNG

If a CHNG call is issued from an OTMA submitted transaction, the destination is assumed to be the same OTMA client (the tpipe name is set by the CHNG call). This behavior can be altered by the OTMA Prerouting and Destination Resolution exit routines.

An IMS application program that issues a CHNG call to an alternate PCB (specifying an options list) does not cause IMS to call the OTMA Prerouting and Destination Resolution exit routines to determine the destination. However, an IMS application program that issues a CHNG call to an alternate PCB (specifying an APPC descriptor) does cause IMS to call the OTMA exit routines to determine the destination.

The application program can still issue ISRT calls to the I/O PCB to send data to an OTMA destination.

OTMA application programs can use CHNG and ISRT calls for APPC destinations.

INQY (null)

An INQY call issued for an OTMA destination returns the following information: the transaction pipe name, the client z/OS® cross-system coupling facility member name, the user ID, the group name, and the synchronization levels.

ICAL

IMS application programs issue the ICAL call to send synchronous callout requests to a data or service provider that is external to the IMS installation. OTMA routes callout requests initiated by the ICAL call to a hold-queue capable OTMA client and routes the reply back to the waiting IMS application program. OTMA provides the ability to specify a timeout value in the OTMA destination descriptor for synchronous callout requests, which can be overridden by the a timeout value specified in the ICAL call.

The ICAL call can also be used to issue a synchronous program switch request. If the OTMA destination descriptor is configured with TYPE=IMSTRAN, OTMA switches control to another IMS application and waits for a response to send to the waiting IMS application program.

If the OTMA message prefix for a transaction from an OTMA client contains distributed network security credentials, the security credentials can be passed from IMS in synchronous callout requests that are initiated by the ICAL call. The distributed network security credentials are passed from IMS via the ICAL call only if the RESUME TPIPE call is defined with the following field specifications in the IMS request message (IRM) prefix. If the following field specifications are not defined, IMS removes the distributed network security credentials from the security-data section of the OTMA message prefix in the synchronous callout request.

IRM_ARCH

X'05' (IRM_ARCH5)

IRM_F6

X'80' (IRM_F6_NWSE)

PURG

An IMS application program that issues a PURG call causes IMS to call the OTMA Prerouting and the Destination Resolution exit routines to determine the destination.

SETO

An IMS application program that issues a SETO call does not cause IMS to call the OTMA Prerouting and the Destination Resolution exit routines to determine the destination.

Existing IMS application programs that issue SETO calls might not run as expected because a return code is returned to the program if it is processing an OTMA-originated transaction. APPC/IMS application programs that issue SETO calls might need modification if they require implicit OTMA support.

One way to make these application programs work is to use an INQY call before issuing the SETO call. The application program can use the output from the INQY call to determine if a transaction originated from an OTMA client, and not issue the SETO call.

For those DL/I calls that cause IMS to call one of the OTMA exit routines, IMS only calls the exit routines if the destination has not yet been set (for example, by another DL/I call).

To initiate protected conversations (such as accessing multiple resource managers' resources under one unit of recovery in an z/OS Resource Recovery Services environment), the client-adapter code (OTMA user) must acquire and own a private context and provide the context ID in the state-data section of the message prefix.

Definition:  A context is a z/OS entity under which resource managers perform work; a private context is required in this environment.

During message traffic between IMS and the client, if the context-ID field in the message header is non-zero, protected conversation processing occurs.