Browse Prior Art Database

Recovery Algorithms for CICS Based Message Processing Programs

IP.com Disclosure Number: IPCOM000105002D
Original Publication Date: 1993-Jun-01
Included in the Prior Art Database: 2005-Mar-19
Document File: 4 page(s) / 135K

Publishing Venue

IBM

Related People

Petty, C: AUTHOR

Abstract

This article discusses a message processing enabling software which executes in the CICS evironment, utilizing a message queueing product. The software provides high integrity/recoverablility, including different levels of recovery capability, based on the criticality and value of the request.

This text was extracted from an ASCII text file.
This is the abbreviated version, containing approximately 39% of the total text.

Recovery Algorithms for CICS Based Message Processing Programs

      This article discusses a message processing enabling software
which executes in the CICS evironment, utilizing a message queueing
product.  The software provides high integrity/recoverablility,
including different levels of recovery capability, based on the
criticality and value of the request.

      In a message based request processing environment, messages are
passed between message driven processes, each process performing some
element of the work necessary to satisfy the initial request.  One of
the processes, the Complex Request Manager (CRM) functions as the
manager of the overall request execution.  The software discussed in
this article supports the CRM.  This component will accept the
original input request messages and drive any required activities.
This primarily consists of invoking the services of other message
driven server processes, coordinating the message based events
necessary to insure consistency between all the participating servers
and detecting any inconsistencies to insure reliability requires
recovery schemes which takes advantage of the CICS unit of recovery
syncronization facilities for the CRM process itself and coordinate
that unit of recovery, with the sending and receiving of messages
to/from subordinate servers.

There are five recovery modes defined in this system:

1.    Non-recoverable Mode: This type of request will, upon failure,
    be purged from the system, and no reply sent, or recovery action
    taken.  All messages associated with request that are later found
    on queues, will be discarded or sent to the Unexpected Message
    Queue.

    This type of request may not use either of the 'confirmed'
    message exchange protocols, nor can it invoke other servers using
    them.  If a database update is done, the update MAY occur, but a
    reply will not be sent to the requestor.

2.    Restartable Mode: These requests will be restarted upon a
    failure, until processing is completed.  The completion may be a
    reply saying that the request was retried X-times and will not be
    retried.  (Note that at least the the user received output.)  At
    the point of non-restartablity, (i.e., after final reply sent and
    sync'd), processing is complete: if there remaining work, a
    failure requires restart from the point of the final reply
    syncronization, not from the top.  This type of request may not
    use either of the 'confirmed' message exchange protocols, nor can
    it invoke other servers using them.  If a request running in this
    mode is cancelled, the process will send a reply indicating
    'request purged', syncpoint, and terminate.

3.  Request Level Recoverable Mode: Request level recovery provides
    for coordinating the recovery unit as per the message exchange
    dialog(s), with the recovery unit for any other resourc...