CA Datacom LXX Read I/Os and DBUTLTY SPILL

Products

• Datacom
• DATACOM - AD
• Datacom/DB

Issue/Introduction

CA Datacom LXX Read I/Os and the DBUTLTY SPILL function.

Environment

Release: All releases
Component: CA Datacom/DB

Cause

Typically the majority of LXX Read I/O that occur in a CA-Datacom Multi-User Facility come from two processes.

The first is transaction backout where the LXX must be read in order to undo the logged, but not committed, transactions.

The second is when the LXX is read to select log blocks that will be spilled (copied) to the RXX (Recovery file). The SPILL process is triggered by a batch DBUTLTY job.

Resolution

Even though the batch DBUTLTY job is responsible for attaching the RXX data set and copying the log blocks onto the RXX data set, it is the MUF that performs the read I/O against the LXX (log file).

In releases prior to r11, the MUF locates the log blocks that are available to be spilled and then sequentially passes each available log block to DBUTLTY to be written to the RXX. Once all the available blocks are spilled to the RXX, the MUF updates the LXX control file to make the spilled blocks available for use.

In r11 and above, the MUF allocates an additional work space (memory) large enough to hold multiple log blocks (track size for VSE/ESA or cylinder size for z/OS). It then locates the log blocks available to be spilled.

For VSE/ESA, on tracks where all log blocks are to be spilled, the MUF uses a single (chained) IO to read all of the log blocks and pass them to DBUTLTY for writing to the RXX.

For z/OS, on cylinders where all log blocks are to be spilled, the MUF uses a single (chained) IO to read all of the log blocks and pass them to DBUTLTY for writing to the RXX.
For those tracks/cylinders where only some of the log blocks are to be spilled, the normal block read I/O is performed.