|
|
|
CA Datacom uses the Log Area (LXX) to allow data to be cached while ensuring the integrity of the data. As updates are made to the database, the LXX is updated with each change that is made. The updates themselves are not necessarily written to the database at the time they are made because CA Datacom uses a pipeline feature to reduce I/O and improve the efficiency of the updates to the database files. Pipelining keeps changes in storage until they can be written to the database in a group, thereby decreasing I/O to the database files and increasing access speed.
In the event of a system failure or CA Datacom MUF outage, the LXX is used to fill in the gaps that may have existed due to this caching. This occurs on startup of CA Datacom if the MUF was not shutdown normally. Database recovery is therefore automatic after an outage if the DASD files are intact and no restore process is necessary. If the database DASD is lost, however, a restore process and forward recovery is needed.
Logged records are kept in the LXX until the database changes are committed to the database DASD, after which completed records can be spilled (removed) from the LXX and written to the RXX. Spilling frees space in the LXX, allowing new log records to then be added. Records spilled to the RXX (typically tapes) can be used to restore a database through the forward recovery process.
Specifications for how the LXX is used by the MUF at your site are determined by the MUF startup options related to logging, which include those shown in the following sample.
Note: The values noted here are illustrative samples only and therefore should be reviewed for relevance to your environment.
MESSAGE CRIT,DB00308 Specifies how log messages get treated on console
LOGPEND 100 Number of log blocks to hold records in memory
LOGPOOL 2 Number of log buffers for rollback
LOGRCV NO Specifies availability of A DEDICATED RXX TAPE DRIVE
LOGSPILL 75,90,25,30,20 Log % full msg, % force checkpoint,
% force spill, % last request to FXX,
% active tasks to FXX
These parameters, the size of the LXX, and other conditions described in the CA Datacom/DB Database and System Administration Guide, determine when spilling of the LXX is needed.
If a program abends or cancels, updates are backed out up to the last checkpoint. Processing stops until the MUF processes the log records. After the backout is complete, the MUF starts processing the transactions that have queued. When a checkpoint is issued or the job completes normally, all uncheckpointed transactions are checkpointed and marked as eligible to be spilled. A CICS transaction boundary is considered a checkpoint.
With the MUF startup option LOGRCV specified as NO, log records are not automatically spilled.
| Copyright © 2012 CA. All rights reserved. | Tell Technical Publications how we can improve this information |