Typical IMS™ programs use a message-driven structure like that in the figure below:
In this example, the IMS controller starts the transaction program when the message queue associated with the program contains a message. Another program might have put the message on the queue, or the controller might have read input from the terminal. The program takes the message off the queue, does any required database I/O, and adds messages to output queues to continue processing. The output queue can represent the input terminal, another terminal or printer, or a queue associated with another transaction. The program then loops back to the beginning and processes the next message on its input queue.
Typical PL/I or COBOL programs must continue the cycle until the message queue is empty because multiple terminals run the same transaction concurrently. However, EGL programs automatically loop to read the next message in the queue. You do not need to define message queue control functions directly. You can define programs for IMS just as you define programs for CICS®, that use a synchronous logic structure instead of a message-driven structure. With the synchronous model, you only need to consider the processing that must occur for a single user at a single terminal. This simplifies both the design and the definition of the program.
IMS requires you to commit all database changes and to release all database locks and positions when waiting for user input. In EGL, this means creating a segmented program (or a single-segment program). When you define the program, remember that EGL performs a commit with each converse I/O statement. You must understand how segmentation works to develop programs for IMS; see Segmentation in text applications.
Related concepts
DL/I database support
Segmentation in text applications
Related reference
add
converse
get
Related tasks