Browse Prior Art Database

Safe, Self-Serializing Method for Creating a Sequential File

IP.com Disclosure Number: IPCOM000043558D
Original Publication Date: 1984-Sep-01
Included in the Prior Art Database: 2005-Feb-05
Document File: 3 page(s) / 16K

Publishing Venue

IBM

Related People

Obermarck, RL: AUTHOR

Abstract

This invention relates to the use of an IBM System/370 store clock command (STCK) to totally order data outputs from concurrently executing processes in a logical buffer instead of ordering them by way of a lock. Locks increase delay and immobilize all processes queued against a resource in the event of lock failure. The clock is assumed to be automatically incremented between two consecutive events. The method of this invention allows processes to add logical records to a single sequential file. The method is safe, in that none of the processes adding records requires resources which are critical to the file itself. The method is self-serializing, in that it provides for each writer a token which relates the logical record's ordering in the file, without the use of Locks or Latches.

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 47% of the total text.

Page 1 of 3

Safe, Self-Serializing Method for Creating a Sequential File

This invention relates to the use of an IBM System/370 store clock command (STCK) to totally order data outputs from concurrently executing processes in a logical buffer instead of ordering them by way of a lock. Locks increase delay and immobilize all processes queued against a resource in the event of lock failure. The clock is assumed to be automatically incremented between two consecutive events. The method of this invention allows processes to add logical records to a single sequential file. The method is safe, in that none of the processes adding records requires resources which are critical to the file itself. The method is self-serializing, in that it provides for each writer a token which relates the logical record's ordering in the file, without the use of Locks or Latches. High-end On-line data base and data communications (DB/DC) systems record recovery information in one or more journal (or log) data sets. These journal data sets are usually written sequentially. The introduction of more powerful multiprocessors gives the potential for the high-end DB/DC systems to allow many more independent processes to run concurrently. Since each of the processes require write-access to the journal, a serious bottleneck can occur if the writing must be serialized. This serialization, coupled with the possibility that the process which "owns" the journal serialization mechanism can fail. This can affect availability. In this regard, the journal would not be available for other processes until the functional recovery procedures for the failed process had (a) determined that the failing process did indeed own the latch, (b) performed appropriate clean-up within the journal buffer (e.g., completing the write of the logical record), and (c) released ownership of the latch. Significantly, other processes cannot write logical records into the journal during this period, and the whole system could appear to be locked up. The inventive method solves both the serialization bottleneck and the availability problem. It trades an extra data movement and extra main storage for the increase in concurrency and availability. The manner in which the method interacts with the actual movement of the logical records into the Write Buffers forming a portion of a common journal (log) interface is shown in Fig. 1. WRITE_LOGICAL: PROCEDURE /* It is assumed that the caller has PC'ed to the Journal Interface */ /* Caller's Home Address space has not changed, but the requested */ /* now has the Journal Interface's Address Space as primary, with */ /* the source information for the log record as secondary. */ Calculate size required for logical record Allocate an LRECL_Buffer which satisfies the space requirement (1) Initialize the TIME_STAMP and DONE_FLAG to Zero
(2) Place the Buffer onto the TO_BE_WRITTEN Queue

Move the Data into the Buffer (3) STCK into TIME_STAMP

Move TIME_STAMP to LRECL_TOKEN (t...