IMS messages and their scheduling

An IMS message can be one of four types of data communication for which IMS controls processing: transactions, messages sent to LTERMs, IMS Commands, and DFSAPPC.

Transactions
Transactions are input messages that are destined for processing by application programs. Transactions are identified by a one- to eight-character transaction code. Transactions can be entered at terminals or generated by application programs. In a multiple-systems environment, a transaction can originate in a remote IMS, or in another subsystem (like Db2 for z/OS®).
Messages sent to LTERMs
Messages that are sent to LTERMs are identified by LTERM names. These messages can be either of the following types:
  • Output messages sent from application programs to communicate with a logical terminal. They usually acknowledge or give results of work, and are sent to the originating terminal. Application programs can also send output to logical terminals other than the one that originated the input message.
  • Input messages whose destination is a logical terminal. This message type is known as a terminal-to-terminal message switch. The text of the message becomes the output message to the destination LTERM.
IMS commands
IMS commands are entered by terminal users who request that IMS display or alter the status of one or more IMS resources. Most commands originate from the master terminal operator (MTO), but other terminals, as well as application programs, can also enter them.
DFSAPPC
DFSAPPC is an IMS service that is used for exchanging messages between LU 6.2 devices, or between any combination of LU 6.2 and non-LU 6.2 devices. Messages are delivered by allocating a new conversation with the designated LU 6.2 destination device. If the allocated conversation fails, the output is stored for future delivery. Messages are held on the IMS message queue until they can be successfully delivered.

Message queuing

In IMS systems that do not used shared queues, all input and output messages are queued in IMS-controlled virtual storage. Most command output is queued in virtual storage. Application programs handle messages serially if SERIAL=YES is specified on the TRANSACT macro.

If virtual storage is exceeded, messages are saved on direct-access storage. In this way, messages can be received as input or saved for output, although the resources that are necessary to process them might not be immediately available.

The maximum number of concurrent terminal I/O requests and the amount of virtual storage to hold the messages are specified during IMS system definition. Both variables can be altered when IMS is started.

In a shared queues environment, input and output messages are queued to a queue structure in a coupling facility. The shared queues environment is documented in IMS Version 15.4 System Administration.

Message segments

When a terminal is used to enter data into the IMS online system, the input can consist of either single segments or multiple segments. A sequence of several segments might be required to specify a message that can be interpreted by an application program. The device operation determines the end-of-segment.

For input, detection of the end-of-message condition by IMS indicates that a complete message has been received.

When the first end-of-segment condition is detected, IMS examines the beginning of the segment to find a destination. If a destination is declared to be a single-segment message, the end-of-segment signals the end-of-message.

After editing, the first (or only) segment of a message has the following structure: 
   LL       ZZ      DEST-CODE     b        MMMM
2 bytes  2 bytes  1 to 8 bytes  1 byte   message text
These parameters are explained in the following table.
Table 1. Message segment format
Message segment part Bytes Explanation
LL 2 Total length of segment including LL and ZZ parts
ZZ 2 Reserved halfword
DEST-CODE 1 to 8 Destination code (usually a transaction code)
MMMM Varies Message text

Each input message is uniquely identified by its destination code. The destination is normally a transaction code, but it can also be an IMS command or LTERM for message switching.

Invalid destinations

Even when the destination code meets normal resource naming conventions, the input destination can be incorrect:
  • If ETO is not active, destinations that cannot be identified in IMS are considered invalid, and the input message is rejected.
  • If ETO is active, IMS assumes these destinations are LTERM names and creates dynamic user structures. If the destination is invalid, a dead-letter queue is created. Several commands are provided, including the /DISPLAY command, for the MTO to process the dead-letter queues.

Transaction codes

The transaction code has optional attributes that affect the processing program's scheduling eligibility by the IMS control program.

Application programs are defined in separate but related macro instructions. The application program that is designated to process a particular transaction code is considered by IMS to be another transaction attribute. An application program might process several transaction codes, but a transaction code can be associated with only one program.

Message scheduling

Definition: Message scheduling is the process by which a completely received input transaction is united with its associated application program for processing.

Some of the factors that affect the message scheduling process are:
  • The variable attributes associated with the transaction code
  • The number and relative importance of other transaction codes
  • The number of received messages that are not yet processed
  • The intent of associated application programs toward the data to be processed
  • The amount of currently available space in control-block storage pools and buffers
In addition, each of the following activities affect the message scheduling process:
  • Selecting system definition options
  • Designing and using databases
  • Specifying buffer sizes
  • Declaring and selecting transaction code priorities

By properly combining these activities, you can manipulate the sequence in which messages are processed and enhance system performance.

CPI-C transactions

IMS resources are made available to the CPI Communications driven application program when the application program issues the APSB (Allocate_PSB) call. The CPI Communications driven application program can use the SAA Resource Recovery Commit (SRRCMIT) and Backout (SRRBACK) calls to initiate an IMS synchronization point or backout. CPI Communications driven application programs should use the SAA Resource Recovery calls to initiate an IMS sync point prior to program termination.

Definition: A synchronization point (also referred to as a sync point throughout this manual) is an occurrence within a program or subsystem wherein resources are committed and a reference point is established for subsequent restart, if necessary.

Recommendation: Define CPI transactions with a different message class from that used for non-CPI transactions.