This section assumes you are using log streams that use coupling facility structures. However, much of it applies also to DASD-only log streams. This is clarified in Tuning for DASD-only logging.
Offloading to DASD data sets of data from a log stream may occur when usage of the log stream (either in the coupling facility or the staging data set) reaches its HIGHOFFLOAD limit, specified when the log stream is defined. For a system log, all records that have been marked for deletion are physically deleted; if, after this has been done, the LOWOFFLOAD limit has not been reached, the oldest active records are offloaded to DASD until LOWOFFLOAD is reached. For a general log, the oldest data is offloaded to DASD until the LOWOFFLOAD limit is reached.
There are also situations where offloading of data from the log stream data set occurs although the HIGHOFFLOAD threshold (and LOWOFFLOAD threshold in some circumstances) of the log stream has not been reached. These are:
In these situations, the amount of data offloaded from the log stream is determined as follows:
(Current utilization or HIGHOFFLOAD, whichever is the greater) - LOWOFFLOAD
This is the percentage of the log stream data set that is offloaded.
Due to the different requirements that you will have for data on the system log, and data on general logs, different recommendations apply in each case.
When an activity keypoint happens, CICS® deletes the "tail" of the primary system log, DFHLOG. This means that data for completed units of work older than the previous activity keypoint is deleted. Data for each incomplete unit of work older than the previous activity keypoint is moved onto the secondary system log, DFHSHUNT, provided that the UOW has done no logging in the current activity keypoint interval.
To minimize the frequency of DASD offloading, try to ensure that system log data produced during the current activity keypoint interval, plus data not deleted at the previous activity keypoint, is always in the coupling facility structure. To avoid offloading this data to DASD, you are recommended to:
LOWOFFLOAD = ((trandur * 90) / (akpintvl + trandur)) + 10
[where RETPD=0 is specified]
or
LOWOFFLOAD = (trandur * 90) / (akpintvl + trandur)
[where RETPD=dddd is specified]
where:
akpintvl = AKPFREQ / ((N1 * R1) + (N2 * R2*) + (Nn * Rn))
where:
If this duration is longer than akpintvl value, you can either:
DFHLSCU recommends a value of 40% for DFHLOG's LOWOFFLOAD parameter. In practice, a good empirical range for this value is between 40% and 60%. Too low a value may result in physical offloading of log data from primary to secondary storage once the MVS™ Logger offload process has completed physical deletion of any unwanted log data during offload processing.
Conversely, too high a value may mean that subsequent offload processing occurs more frequently, as less space is freed up from primary storage during an offload operation.
If the results of the calculation from the formula given above do not lie within the range of 40% to 60%, it may be that your workload has atypical values for trandur or akpintvl.
It should be noted that log stream definition values (such as LOWOFFLOAD) should be reviewed after analysis of information such as statistics from MVS logger SMF 88 records.
The recommendations for forward recovery logs and user journals are different to those for the system log. There is no requirement here to retain logged data in the coupling facility structure. Rather, due to the typical use of such data, you may only need a small structure and offload the data rapidly to DASD. If this is the case, allow HIGHOFFLOAD and LOWOFFLOAD to default (to 80 and 0 respectively).
HIGHOFFLOAD and LOWOFFLOAD are parameters for use in the IXCMIAPU program which you would run to define log stream models and explicitly named individual log streams. For more information, see the System/390® MVS Setting up a Sysplex manual.
SMF88 records and RMF™ provide a range of statistical information that helps you in the tuning of these parameters.