IMS Transaction Flow


The general flow of an input message is from a terminal or user to the MPP, and the general flow of the output reply message is from the MPP to the terminal or user. This flow is illustrated in Figure 12-3 on page 174. This figure describes a general flow of the message through the system, not a complete detailed description.

Figure 12-3. The IMS Control Region, Its Control, and Data (Message) Flow


A further description of Figure 12-3 follows:

  1. The input data from the terminal is read by the data communication modules. After editing by MFS, if appropriate, and verifying that the user is allowed to execute this transaction, this input data is put in the IMS message queue. The messages in the queue are sequenced by destination, which could be either transaction code (TRAN) or logical terminal (LTERM). For input messages, this destination is TRAN.

  2. The scheduling modules determine which MPR is available to process this transaction, based on a number of system and user-specified considerations, and then retrieves the message from the IMS message queues, and starts the processing of a transaction in the MPR.

  3. Upon request from an MPR, the DL/I modules pass a message or database segment to or from the MPR.

    Note:

    In z/OS, the DL/I modules, control blocks, and pools reside in the common storage area (CSA or ECSA) and the control region is not used for most database processing. The exception is Fast Path DEDB processing.


  4. After the MPP has finished processing, the message output from the MPP is also put into the IMS message queues, in this case, queued against the logical terminal (LTERM).

  5. The communication modules retrieve the message from the message queues, and send it to the output terminal. MFS is used to edit the screen and printer output (if appropriate).

  6. All changes to the message queues and the databases are recorded on the logs. In addition, checkpoints for system (emergency) restart and statistical information are logged.

    Notes:

    1. The physical logging modules run as a separate task and use z/OS ESTAE for maximum integrity.

    2. The checkpoint identification and log data set information are recorded in the restart and RECON data sets.


  7. Program isolation (PI) locking assures database integrity when two or more MPPs update the same database. The system also backs out database changes made by failing programs by maintaining a short-term, dynamic log of the old database element images. IRLM is an optional replacement for PI locking. IRLM is required, however, if IMS is participating in data sharing.

Related Reading: For more information about IMS TM transaction flow, see Chapter 13, "How IMS TM Processes Input," on page 195.



Introduction to IMS. Your Complete Guide to IBM's Information Management System
An Introduction to IMS: Your Complete Guide to IBMs Information Management System
ISBN: 0131856715
EAN: 2147483647
Year: 2003
Pages: 226

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net