Browse Prior Art Database

CICS/VM Utilization of SFS for Logging Interval Control Information

IP.com Disclosure Number: IPCOM000101339D
Original Publication Date: 1990-Aug-01
Included in the Prior Art Database: 2005-Mar-16
Document File: 5 page(s) / 219K

Publishing Venue

IBM

Related People

Renshaw, DS: AUTHOR

Abstract

Disclosed is a programming technique that permits efficient use and re-use of the CMS SFS (Shared File System) sequential disk file space for holding variable-length data and control block images to allow fast and complete restart of the CICS/VM IC environment after failure.

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

CICS/VM Utilization of SFS for Logging Interval Control Information

       Disclosed is a programming technique that permits
efficient use and re-use of the CMS SFS (Shared File System)
sequential disk file space for holding variable-length data and
control block images to allow fast and complete restart of the
CICS/VM IC environment after failure.

      Log file records are shortened, limiting disk-space wastage
when logging short control books and data.  Log file size is
minimized by allowing re-use of all freed records, and interval
control is divorced from the effects of application-induced failure
of the CMS environment by separating the committing of IC data from
the rest of the application owned resources.  Disk file I/O is also
minimized by allowing updates to be made to the log using a single
read followed by a single write for all operations, and file I/O is
further reduced by increasing the likelihood of SFS buffer hits by
re-using the last freed record.

      Background: Within CICS/VM Release 2 transactions may be
started by other transactions through the "command" level application
programming interface (API).  These "started" tasks may be scheduled
to run immediately or at a specific time of day or after an interval
of time.  The CICS/VM environment within the user's CMS virtual
machine exists only while a CICS transaction is being processed, and
thus if transactions are requested to start at some point in the
future, a record must be kept of the start request to permit CICS/VM
to execute the application as close to the required time as the
user's work patterns permit.  Each start request may optionally
specify a variable-length piece of data which is to be passed to the
transaction, on request, once it is executing.  This variable length
data must also be recorded so as to be available at some future time
when the transaction starts.  Each start request within the CICS/VM
system is represented by one or more control blocks, a Start Request
Element (SRE), and if the request has associated data, a Retrieve
Data Element (RDE).  These control blocks contain all the information
required by CICS/VM to schedule and execute the started task.  In
addition, the data passed by the application on the start request is
held.

      The Problem: The start data including the control blocks and
the application-supplied data must be held for potentially long
periods of time and must survive a failure of the CMS environment and
subsequent re-IPL of CMS due to the volatile nature of the CMS
environment and the fact that CICS/VM is only a part of it and thus
cannot control or prevent damage to it.  That requirement means that
the data must be stored in some form of disk file which can be
committed under the control of CICS/VM and allow recovery of the data
after a failure of CMS.  The traditional CMS file system, as accessed
via the FSWRITE and FSREAD interfaces, suffers from a severe problem
in that changes to files...