Managing auxiliary storage

Use System Managed Storage (SMS) to manage log stream data sets.

Managing log data sets

You can specify the SMS characteristics of log data sets in a number of ways, depending on your installation.

Using automatic class selection (ACS) routines
You can use installation-written automatic class selection (ACS) routines to assign log data sets to SMS classes.
Using the LOGR policy
When you define or update a log stream definition in the LOGR policy, you can assign the SMS storage class, data class, and management class for both the DASD log data sets and staging data sets.
  • Use LS_DATACLAS to specify the SMS data class to be used for log stream data set allocation.
  • Use LS_STORCLAS to specify the SMS storage class to be used for log stream data set allocation.
  • Use LS_SIZE to specify the size, in 4 KB blocks, of the log stream DASD data sets. Specify a size so that each data set can contain multiple offloads of the primary storage: this capability is particularly important if all the data is offloaded for a log stream, as in the case of user journals and forward recovery logs. The MVS™ system logger issues message IXG256I is you specify less than 64 KB.

    If you omit the size parameter, the size is taken from the ALLOCxx member of PARMLIB. The default is 2 tracks, which leads to a high number of new data set allocations. Specify a size that is large enough to avoid a high frequency of new data set allocations; aim for a new data set to be allocated less frequently than once an hour.

SHAREOPTIONS(3,3)
Always define logger data sets with SHAREOPTIONS(3,3), whether the system is a part of a multiple-member sysplex or a monoplex. The common symptom of not having SHAREOPTIONS(3,3) is return code 84A or 403 from the logger.

For more information about managing log data sets, see z/OS MVS Setting Up a Sysplex.

Managing the system log

CICS® manages the system log by deleting records, for completed units of work, during activity keypoint processing (log-tail deletion). With an appropriately sized log stream, the system log data remains in primary storage, thus avoiding data spilling to DASD.

Note that:
  • The CICS system log must be used only for short-lived data required for recovery purposes. For example, do not write audit trail user records to the system log.
  • Allow CICS to manage the size of the system log.

However, if historically you have used the system log for such things as audit trails, you might want to preserve system log data beyond the time it is typically deleted by CICS. You can use the RETPD MVS parameter to preserve system log data. Define DFHLOG and DFHSHUNT to MVS with AUTODELETE(NO) and RETPD(dddd). The default values are AUTODELETE(NO) and RETPD(0). By specifying AUTODELETE(NO), CICS, rather than MVS, retains control of the log-tail trimming process; dddd is the number of days for which data is to be retained. In this way, the MVS logger physically deletes an entire log data set when all of the data in the data set has been marked for deletion by the CICS log-tail trimming process and is older than the retention period specified for the log stream.

You can view log data that has been marked for deletion by CICS, but not yet physically deleted by MVS, with the DFHJUP utility program or the VIEW=ALL option of the MVS IXGBRWSE macro.

Managing general logs

The number of data sets per log stream recognized by the MVS logger is several million. Therefore, in general, do not be concerned about the limit being reached. You can cause redundant data to be deleted from log streams automatically, after a specified period. To arrange deletion for general log streams, define the logs to MVS with AUTODELETE(YES) and RETPD(dddd), where dddd is the number of days for which data is to be retained. This definition causes the MVS system logger to delete an entire log data set when all the data in it is older than the retention period (RETPD) specified for the log stream.