Designing CICS-to-IMS ISC applications

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.

Data formats

Messages transmitted between CICS and IMS can have either of the following data formats:

Figure 74. Basic IMS message queuing
 The picture shows two IMS regions, a control region and a message-processing region. The control region has several sessions to client applications or terminals, and a number of message queues. Requests from the client applications and terminals are received by the control region and appended to input message queues, according to their transaction codes. When a request reaches the head of an input queue, it is passed to the appropriate application on the message-processing region. Eventually, the response from the message-processing region is passed back to the control region, where it is appended to an output queue. When it reaches the head of the queue, it is sent to the appropriate client application or terminal.

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.

Variable-length variable-blocked

In VLVB format, a message can contain multiple records. Each record is prefixed by a two-byte length field, as shown here.

 The picture shows a message in VLVB format. It consists of multiple records. Each record consists of a 2-byte length field, followed by a data section.

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.

Chain of RUs

In this format, which is the most common CICS format, a message is transmitted as multiple SNA RUs, as shown here.

 The picture shows a message consisting of multiple SNA RUs.

In CICS, the I/O area contains a complete message.

Forms of intersystem communication with IMS

There are three forms of CICS-to-IMS communication that must be considered:

  1. Asynchronous processing using CICS START and RETRIEVE commands
  2. Asynchronous processing using CICS SEND LAST and RECEIVE commands
  3. Distributed transaction processing (that is, synchronous processing) using CICS SEND and RECEIVE commands.

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.

Related concepts
CICS-to-IMS applications--asynchronous processing
CICS-to-IMS applications--DTP
Related tasks
Defining CICS-to-IMS LUTYPE6.1 links
[[ Contents Previous Page | Next Page Index ]]