LOWOFFLOAD and HIGHOFFLOAD parameters on log stream definition

Data from a log stream can be offloaded to DASD data sets when the log stream use (in the coupling facility or the staging data set) reaches its HIGHOFFLOAD limit. The amount of data offloaded is determined by using the LOWOFFLOAD limit.

The HIGHOFFLOAD limit is specified when the log stream is defined.

This information is relevant if you are using log streams that use coupling facility structures. However, much of the guidance also applies to DASD-only log streams.

For more information about DASD-only log streams, see DASD-only logging.

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:

When the HIGHOFFLOAD threshold is reached in the staging data set. If the size of the staging data set is proportionally smaller than the log stream, the HIGHOFFLOAD threshold is reached on the staging data set before it is reached on the log stream data set.
When the list entry area of the log stream reaches 90% of its capacity.

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.

HIGHOFFLOAD and LOWOFFLOAD are parameters for use in the IXCMIAPU program that you run to define log stream models and explicitly named individual log streams. For more information, see Administrative data utility in z/OS MVS Setting Up a Sysplex.

SMF88 records and RMF provide a range of statistical information that helps you in the tuning of these parameters.

The primary system log

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 can use these settings:

Set HIGHOFFLOAD to 80.
Minimize the amount of log data produced between activity keypoints by specifying a low value on the AKPFREQ parameter, for example, a value of 4000.
Ensure that the value of LOWOFFLOAD is greater than the space required for the sum of:
1. The system log data generated during one complete activity keypoint interval
2. The system log data generated (between sync points) by your longest-running transaction.
Use one of the following formulas to calculate a value for LOWOFFLOAD:
```
LOWOFFLOAD = ((trandur * 90) / (akpintvl + trandur)) + 10
[where RETPD=0 is specified]
```
or
```
LOWOFFLOAD = (trandur * 90) / (akpintvl + trandur)
[where RETPD=dddd is specified]
```
where:
- akpintvl is the interval between activity keypoints. It varies according to workload and its calculation is based on peak workload activity, as follows:
```
 akpintvl = AKPFREQ / ((N1 * R1) + (N2 * R2*) + (Nn * Rn))
```
  where:
  - N1, N2 ... Nn is the transaction rate for each transaction (trans/sec)
  - R1, R2 ... Rn is the number of log records written by each transaction
- trandur is the execution time (between sync points) of the longest-running transaction that runs as part of the normal workload.
  If this duration is longer than the akpintvl value, you can either:
  - Increase the value of AKPFREQ, thus increasing the value of akpintvl (providing this does not result in an unacceptably large coupling facility structure size).
  - Change the application logic to cause more frequent sync points.
  - Calculate a structure size based on a shorter transaction duration, and accept that DASD offloading occurs when the long-running transaction is used.
  A good empirical range for the DFHLOG LOWOFFLOAD parameter value is between 40% and 60%. A value that is too low can result in physical offloading of log data from primary to auxiliary storage after the MVS Logger offload process has completed physical deletion of any unwanted log data during offload processing. Conversely, too high a value might 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 do not lie within the range of 40% to 60%, it might be that your workload has unusual values for trandur or akpintvl.
  
  Review log stream definition values (such as LOWOFFLOAD) after analysis of information such as statistics from MVS logger SMF 88 records.

General logs

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 might only need a small structure and offload the data rapidly to DASD. If so, default HIGHOFFLOAD to 80 and LOWOFFLOAD to 0.