z/OS DFSMStvs Planning and Operating Guide
Previous topic | Next topic | Contents | Contact z/OS | Library | PDF


Allocating system log streams

z/OS DFSMStvs Planning and Operating Guide
SC23-6877-00

Each DFSMStvs instance requires its own pair of system logs: a primary (undo) log and a secondary (shunt) log. The system logs are used for recovery purposes. For example, they are used during backout and DFSMStvs restart. They are not meant to be used for any other purpose or by any other instance of DFSMStvs except in the case of peer recovery. Peer recovery is the process of completing the work that was left in an incomplete state by another instance of DFSMStvs when the system on which the instance was running failed. You can find more information about peer recovery in Diagnosing and recovering from DFSMStvs problems. DFSMStvs connects to its system logs automatically during initialization.

You must define the log streams for the DFSMStvs undo log and shunt log to the system logger before accessing a recoverable VSAM data set in DFSMStvs mode.

For each log stream that is in use, DFSMStvs needs two buffers. Each buffer can be a maximum block size of 64 KB for the log stream, and approximately 600 bytes of state data, all of which are above the 16 MB line. The SMSVSAM server address space contains the buffers.

A log stream is a sequence of data blocks, with each log stream identified by its own log stream identifier, which is called the log stream name. The DFSMStvs system logs, log of logs, and forward recovery logs map to specific MVS™ log streams. Each log stream is a sequence of blocks of user data, which the system logger internally partitions over three different types of storage:
Primary storage
This is a structure within a coupling facility that holds the most recent records written to the log stream. Log data written to the coupling facility is also copied to either a data space or a staging data set.
Secondary storage
When the primary storage structure for a log stream becomes full, the older records automatically spill into secondary storage. The secondary storage structure consists of data sets that are managed by the storage management subsystem. Each log stream, identified by its log stream name, is written to its own log data sets.
Tertiary storage
The tertiary storage is specified in your hierarchical storage manager (HSM) policy. Tertiary storage is used to migrate older records to some form of archive storage. This can be either DASD data sets or tape volumes. HSM manages this log data migration option.

The system logger provides access to these logs. DFSMStvs has access to the log stream data during recovery operations, when it can browse the data, read forward and backward, or read any block directly. Figure 1, Figure 1, and Figure 1 show you how you can define log streams for DFSMStvs to use. In these examples, each of the log streams has its own structure; your log streams can share structures.

Recommendations:
  • Specify DIAG(YES) for the DFSMStvs system logs. This parameter indicates that special logger-diagnostic system activity is allowed for this log stream. This is especially useful when certain system logger errors occur, such as an X'804' type condition, which indicates that some data might have been lost.
  • Log stream and log stream staging data sets are single extent VSAM linear data sets that require SHAREOPTIONS(3,3). The default is SHAREOPTIONS(1,3).

    Recommendation: Explicitly specify the SHAREOPTIONS values.

Go to the previous page Go to the next page




Copyright IBM Corporation 1990, 2014