Browse Prior Art Database

Communication Path Management a Coordinated Application Doing Multi-Tasking Operation and a Recovery

IP.com Disclosure Number: IPCOM000099126D
Original Publication Date: 1990-Jan-01
Included in the Prior Art Database: 2005-Mar-14
Document File: 4 page(s) / 159K

Publishing Venue

IBM

Related People

Barnes, CC: AUTHOR [+2]

Abstract

The process of writing Recovery Processor log for a synchpoint (a commit or backout of work in is a logically grouped piece of work, referred to this article as a synchronization transaction. A natural of the current state of the art would make this a logical unit of work. This would necessitate the of a path from an Application Processor to a Processor for the entire duration of a transaction. This is a disadvantage for Processors that support concurrent multiple that may wish to do concurrent syncpoints.

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

Communication Path Management a Coordinated Application Doing Multi-Tasking Operation and a Recovery

       The process of writing Recovery Processor log for a
synchpoint (a commit or backout of work in is a logically grouped
piece of work, referred to this article as a synchronization
transaction.  A natural of the current state of the art would make
this a logical unit of work.  This would necessitate the of a path
from an Application Processor to a Processor for the entire duration
of a transaction.  This is a disadvantage for Processors that support
concurrent multiple that may wish to do concurrent syncpoints.

      This article describes a technique which eliminates the of
dedicating a path between an Application and a Recovery Processor for
the entire duration a synchronization transaction.  Between subsets
of the other processes within an application processor use the path
for Recovery Processor log requests.  In the technique eliminates the
performance drawback an application processor being limited to one
path to a Processor.

      Fig. 1 illustrates a synchronization transaction.  The
transaction is made up of the three log requests shown.  The
synchronization transaction can processed as a series of logical
units of work, each of one log request.  A unique userid is with the
buffered log entries of a transaction.  A unique synchronization id
is associated with the buffered entries of a transaction.  This
synchronization id will be returned to the Application Processor the
first synchronization transaction log request. subsequent
synchronization transaction log request will accompanied by this
transaction id.  This new interface allow the Log Manager to identify
the proper buffered to be updated as a result of the request.

      The Path Manager, recognizing a Recovery Processor log must
determine if an inactive path to the Recovery currently exists.

      If one is found, the Path Manager can send the request that
path.  If one is not found, the Path Manager must a new path to the
Recovery Processor and send the on that path.  It is expected that a
high water mark be reached after which there will generally be an
path to the Recovery Processor virtual machine.

      Fig. 2 shows the structure of an active path that is used to
send a synchronization transaction log  The Application Processor (1)
is identified by the USERA (2).  The Application has running in it, a
multi-tasking application. application is supported by a Synchpoint
Manager and a Manager.  The Path Manager has a path (3) connected the
Application Processor to the Recovery Processor. Recovery Processor
contains a path control block (4) is used to maintain the state of
the path.  The P...