Browse Prior Art Database

Testing for Indoubt Units of Work in a Transaction Processing System

IP.com Disclosure Number: IPCOM000117271D
Original Publication Date: 1996-Jan-01
Included in the Prior Art Database: 2005-Mar-31
Document File: 2 page(s) / 119K

Publishing Venue

IBM

Related People

Mitchell, IJ: AUTHOR [+4]

Abstract

The term Unit of Work (UOW) is conventionally used to describe a piece of work performed by a transaction processing system such as CICS* on behalf of a user.

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

Testing for Indoubt Units of Work in a Transaction Processing System

      The term Unit of Work (UOW) is conventionally used to describe
a piece of work performed by a transaction processing system such as
CICS* on behalf of a user.

      A UOW is a sequence of processing actions (database changes,
for example) that must be completed before any of the individual
actions can be regarded as committed.  When a UOW has been committed
the sequence need not be backed out (reversed) if a subsequent error
occurs, be it a failure of the individual transaction (instance of an
user application) or a failure of the whole transaction monitor.  The
end of a UOW is marked by what is called a syncpoint.  A syncpoint
can be issued by either the user application program or by the
transaction monitor at the end of the application.  In the absence of
user syncpoints the whole application executes as a single UOW.

      A UOW can be distributed across multiple CICS systems.  For
example, a CICS application may be written to communicate with
another application in another CICS system within a single UOW, and
both sides update recoverable resources.  When a syncpoint occurs,
the two phase commit protocol coordinates updates on the two CICS
systems.  One CICS will be the syncpoint coordinator, the other will
be a syncpoint subordinate.  At a specific point in the two phase
commit protocol, the CICS system that is the syncpoint subordinate
will go 'indoubt' as to the outcome of the unit of work until it
hears back from the syncpoint coordinator whether to commit or back
out the UOW.  This period is called the 'indoubt window'.

      An indoubt failure occurs if the communication link is lost
between the two CICS systems while in the indoubt window.  Two
courses of action are open to a subordinate CICS system in this
instance:
  o  Case 1
     It can keep the locks on all its recoverable resources it
updated
      in the UOW, and wait for the link to be re-established and
hence
      find out what the outcome of the UOW was.  Or
  o  Case 2
     It can take a heuristic decision (a guess) as to which way the
      UOW went, and go ahead and commit or back out the UOW.  This
      risks being out of sync with the coordinator.

      CICS for MVS/ESA, V5.1 supports both courses of action.  In
Case 1 the UOW is 'shunted'.  CICS provides the user with System
Programming Interface (SPI) commands to inquire upon and manipulate
shunted units of work.  However, in order to test new programs using
this SPI, shunted units of work need to be created.  Creating shunted
units of work is error prone and difficult.

      The indoubt testing tool described here provides a simple easy
way of producing indoubt failures, without the need for multiple CICS
systems and without the need to change application logic or insert
break points in an application or in CICS.

      The tool, referred to herein as CIND,...