Example 3. IMS-to-other-subsystem message switch routing
The function to be accomplished with the example shown in the following figure is the same as that in Example 1. However, the backend subsystem is either CICS® or a user-written subsystem.
The description of the activities taking place in IMS for this example parallels that in Example
1. The other
subsystem is of interest and is described below.
- Assume the other subsystem is CICS.
Remember, from Example 1, the data stream sent from IMS looks like this:
FMH: DPN=ISCE,PRN=,RDPN=,RPRN=T | Data...
The data is formatted in a way that ISCE expects to receive it. The IMS terminal operator who is entering the transaction should understand what that format is.
- CICS must have a user-written
transaction defined with transaction code
ISCE
, because the DPN represents a transaction code to CICS. CICS, after receiving the data stream described in item 1, invokes a transaction namedISCE
, which must be specifically written for the ISC environment. This transaction examines the FMH values supplied and must use the RETRIEVE interface to obtain the user data and processTRANX
.Because CICS supports transaction codes having a maximum of 4 characters, ISC edit has been given the alias
ISCE
. - The output from the transaction in CICS must
look like the output that
IMSB
sent back toIMSA
in Example 1. That is:FMH: DPN=ISCE,PRN=T,RDPN=,RPRN | Data...
The CICS transaction
ISCE
actually gives CICS the format to use to build the output FMH (in contrast to Example 1, wherein IMS ISC support builds the FMH). In this example, the CICS transaction must supply DPN=ISCE
and PRN=T
to CICS to enable the proper FMH to be built. - When IMS receives this output data stream from CICS, all activities parallel those in Example 1.
A user can implement the functions of this example in a user-written subsystem by understanding the previous explanation of CICS functions and relating it to the functions implemented in the system.