Module 5: IMS DC Online

IMS- DC Online

IMS DC (Data Communications), also called IMS TM (Transaction Manager), is the online half of IMS. It lets thousands of terminal users send transactions concurrently: it receives input messages, queues them, schedules Message Processing Programs (MPPs), and routes replies back. This module follows one transaction from terminal to database and back.

IMS DC components

Control region: the heart of IMS DC; manages message queues, schedules regions and handles system services.
Message queues: every input message waits on an input queue until an MPP is scheduled; replies wait on output queues for delivery to terminals.
MPP regions: address spaces where Message Processing Programs run, one transaction at a time per program instance.
Terminals: classically 3270 screens, today also TCP/IP clients and web front-ends. Screens are formatted by MFS (Message Format Service).
Transaction codes: each message starts with a transaction code (e.g. PAYINQ) that tells IMS DC which MPP program to schedule.

The life of one transaction

User types a transaction code plus data on the terminal and presses Enter.
IMS DC places the input message on the queue for that transaction code.
The control region schedules an MPP in an MPP region and gives it the message.
The MPP issues GU to its IO-PCB to read the message, processes it with DL/I calls against IMS DB, and ISRTs a reply message.
The MPP issues GU again for the next message. When the queue is empty (status QC), it ends with GOBACK and IMS frees the region.
IMS DC delivers the reply message to the originating terminal.

The IO-PCB: an MPP's window to the queues

Every MPP's PSB starts with a special PCB of TYPE=TP: the IO-PCB. It is how the program talks to the message queues instead of a database.
GU to the IO-PCB reads the next input message. Status QC means the queue is empty - time to GOBACK.
ISRT to the IO-PCB sends a reply back to the originating terminal.
ISRT to an alternate PCB routes a message to a different transaction code or logical terminal.
The IO-PCB mask carries the terminal name, date/time, input message name and MOD name - useful for logging.

LINKAGE SECTION.
01 IO-PCB-MASK.
05 LTERM-NAME PIC X(8).
05 FILLER PIC X(2).
05 IO-STATUS PIC X(2).
05 MSG-DATE-TIME PIC X(8).
05 IN-MSG-NAME PIC X(8).
05 MOD-NAME PIC X(8).
05 DEST-FEEDBACK PIC X(8).

Example: MPP program flow (student inquiry)

The user enters "STUINQ S1001". The MPP reads the message, builds a qualified SSA from the typed student id, GU's the STUDENT segment, and replies with the name or a not-found message.

IDENTIFICATION DIVISION.
PROGRAM-ID. STUINQ.
DATA DIVISION.
WORKING-STORAGE SECTION.
01 GU-FUNC PIC X(4) VALUE 'GU '.
01 ISRT-FUNC PIC X(4) VALUE 'ISRT'.
01 MSG-AREA PIC X(256).
01 REPLY-AREA PIC X(256).
01 SSA-QUALIFIED PIC X(40).
01 STUDENT-IO-AREA.
05 STUDID PIC X(10).
05 STUDNAME PIC X(30).
LINKAGE SECTION.
01 IO-PCB-MASK.
05 LTERM-NAME PIC X(8).
05 FILLER PIC X(2).
05 IO-STATUS PIC X(2).
05 MSG-DATE-TIME PIC X(8).
05 IN-MSG-NAME PIC X(8).
05 MOD-NAME PIC X(8).
05 DEST-FEEDBACK PIC X(8).
01 DB-PCB-MASK.
05 DBD-NAME PIC X(8).
05 SEGMENT-LEVEL PIC X(2).
05 DB-STATUS PIC X(2).
05 PROC-OPTIONS PIC X(4).
05 FILLER PIC X(4).
05 SEGMENT-NAME PIC X(8).
05 KEY-LENGTH PIC S9(5) COMP.
05 SEGS-FOUND PIC S9(5) COMP.
05 KEY-FEEDBACK PIC X(32).
PROCEDURE DIVISION USING IO-PCB-MASK, DB-PCB-MASK.
MAIN-PARA.
PERFORM GET-INPUT-MESSAGE
PERFORM UNTIL IO-STATUS = 'QC'
PERFORM PROCESS-TRANSACTION
PERFORM GET-INPUT-MESSAGE
END-PERFORM
GOBACK.
GET-INPUT-MESSAGE.
CALL 'CBLTDLI' USING GU-FUNC, IO-PCB-MASK, MSG-AREA.
PROCESS-TRANSACTION.
* Message layout: bytes 1-6 tran code, 8-17 student id
MOVE MSG-AREA(8:10) TO STUDID
STRING 'STUDENT(STUDID = ' STUDID ')'
DELIMITED BY SIZE INTO SSA-QUALIFIED
END-STRING
CALL 'CBLTDLI' USING GU-FUNC, DB-PCB-MASK,
STUDENT-IO-AREA, SSA-QUALIFIED.
IF DB-STATUS = ' '
STRING 'NAME: ' STUDNAME DELIMITED BY SIZE
INTO REPLY-AREA
END-STRING
ELSE
MOVE 'STUDENT NOT FOUND' TO REPLY-AREA
END-IF
CALL 'CBLTDLI' USING ISRT-FUNC,
IO-PCB-MASK, REPLY-AREA.

Note the two separate status fields: IO-STATUS for the message queue, DB-STATUS for the database. Never mix them.
Each pass through the loop is one transaction and one commit: IMS commits database changes when the message completes.
An MPP must end with GOBACK, never STOP RUN, so IMS can reuse the region.

Conversational vs non-conversational transactions

Non-conversational (the default): each message is independent. The program above is non-conversational.
Conversational: a multi-step dialog (screen 1, screen 2, ...) keeps state in the SPA (Scratch Pad Area) across messages until the conversation ends.
Use conversational only when the dialog truly needs kept state; it holds resources longer and complicates restart.

MFS: Message Format Service

MFS maps between the 3270 screen layout the user sees and the message layout the MPP reads (MOD for output, MID for input, DIF for device format).
The application program only ever sees the plain message fields; MFS handles cursor positions, attributes and screen painting.
A wrong MOD name in the IO-PCB or a missing MFS format gives garbled screens - check the format generation first.

Backward

Forward

Let's understand Mainframe