There are many differences between CICS® and IMS™, both in their architecture and in their application and system programming requirements.
The design of CICS-to-IMS ISC applications involves principally CICS application programming and IMS system definition. This difference reflects where the control lies in each of the two systems.
CICS is a direct control system. Data entered at a terminal causes CICS to invoke the appropriate application program to process the incoming data. The data is stored, rather than queued, and the application "owns" the terminal until it completes its processing and terminates. In CICS ISC, the application program is involved with data flow protocols, with syncpointing, and, in general, with most system services.
In contrast, IMS is a queued system. All input and output messages are queued by the IMS control region on behalf of the related application programs and terminals. The queuing of messages and the processing of messages are therefore performed asynchronously. This is illustrated in Figure 74.
As a result of this type of system design, IMS application programs do not have direct control over IMS system resources, nor do they become directly involved in the control of intersystem communication. IMS message switching is handled entirely in the IMS control region; the message processing region is not involved.
Messages transmitted between CICS and IMS can have either of the following data formats:
In normal CICS communication with logical units, chain of RUs is the default data format. In IMS, VLVB is the default. In CICS-to-IMS communication, the format that is being used is specified in the LUTYPE6.1 attach headers that are sent with the initial data.
In VLVB format, a message can contain multiple records. Each record is prefixed by a two-byte length field, as shown here.
In CICS, the I/O area contains a complete message, which can contain one or more records. The blocking of records for output, and the deblocking on input, must be done by your CICS application program.
In this format, which is the most common CICS format, a message is transmitted as multiple SNA RUs, as shown here.
In CICS, the I/O area contains a complete message.
There are three forms of CICS-to-IMS communication that must be considered:
The basic differences between these forms of communication are described in Asynchronous processing and Distributed transaction processing.
In any particular application that involves communication between CICS and IMS, the intersystem communication must be initiated by one or other of the two systems. For example, if a CICS terminal operator initiates a CICS transaction that is designed to obtain data from a remote IMS system, the intersystem communication for the purposes of this application is initiated by CICS.
The system that initiates intersystem communication for any particular application is the front-end system as far as that application is concerned. The other system is called the back-end system.
When CICS is the front end, it supports all three types of intersystem communication listed above. The form of communication that can be used for any particular application depends on the IMS transaction type or on the IMS facility that is being initiated. For information about the forms of communication that IMS supports when it is the back-end system, see the IMS Programming Guide for Remote SNA Systems.
When IMS is the front-end system, it always uses asynchronous processing (corresponding to the CICS START and RETRIEVE interface) to initiate communication with CICS.