Sending IMS commands from CICS

For terminals that are defined statically, the Resource Access Control Facility (RACF®) (or an equivalent product) is used for authorization. For terminals that are defined dynamically using ETO, this authorization is validated using RACF.

However, permitting a CICS® application to issue IMS commands through the ISC session introduces IMS dependencies into the CICS application program. The consequences of this decision should be weighed before this facility is used.

A CICS application program can issue IMS commands by using the SEND/RECEIVE application program interface.

Exception: A CICS application program cannot issue the IMS commands /DISPLAY, /RDISPLAY, /FORMAT, and /TEST.

The IMS command verb is embedded in the message. It cannot be specified in the PROCESS parameter of the BUILD ATTACH command.

/DISPLAY, /RDISPLAY, and /FORMAT can be sent using START/RETRIEVE or SEND/RECEIVE. These commands differ from other IMS commands in that replies to these commands are queued by IMS rather than being immediately processed.

If these commands are issued with SEND (without LAST), IMS returns an LUSTATUS NO-OP as the reply to force end-bracket. IMS replies to these commands by sending the reply ATTACH BB/EB. CICS must use RECEIVE to obtain the reply. If a command is issued with SEND LAST, the reply message, when it is returned, is processed by a CICS transaction whose name has been previously specified in the RPROCESS field of the BUILD ATTACH.

If a command is issued using START/RETRIEVE, the reply is returned with both the ATTACH and SCHEDULER FM headers.

You can use the /TEST command for testing communication protocols and editing facilities on an ISC session when IMS is a back end to a CICS front end. Test mode requires the SEND/RECEIVE application program interface to be used.