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


Structures and log streams

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

You can put multiple log streams in one list structure, thereby facilitating the management of structures.

Recommendation: Put the same kinds of log streams in the same structure.

Consider the following guidelines for structures and log streams:
  • All data sets used by the same job should use the same log stream to reduce the number of log streams written to at a sync point.
  • Consider sharing a forward recovery log stream between data sets that have similar security requirements and a similar backup frequency.
  • Avoid mixing data sets that have a high number of updates with data sets with a low number of updates to avoid reading excessive amounts of log data when recovering a low update data set.
  • Do not place all your high-update data sets in one log stream as this might exceed the throughput that a single log stream can provide.

For example, in a cloned CICS® environment, all the primary system logs of the application owning regions have the same attributes, so they can be put in the same structures. In contrast, the primary system log of an application owning region and the primary system log of a TOR have completely different characteristics, so they should not be put in the same structure.

Recommendation: For DFSMStvs log streams, do not put the primary system log and the secondary system log in the same structure. You can put all primary system logs in the same structures. Similarly, you can put all secondary system logs in the same structures.

For RRS log streams, the main UR state log, the delayed UR state log, and the archive log can be put in one structure. The resource-manager data log and the restart log should be put in another structure.

Go to the previous page Go to the next page




Copyright IBM Corporation 1990, 2014