Log manager data records

Use this topic as a reference for format of log manager data records.

The format of the log manager statistics record is described in assembler macro thlqual.SCSQMACS(CSQDQJST).

In the statistics, these counts are important:

1. The total number of log write requests:

   N logwrite = QJSTWRW + QJSTWRNW + QJSTWRF
   

2. The total number of log read requests:

   N logread = QJSTRBUF + QJSTRACT + QJSTRARH
   

The problem symptoms that can be examined using log manager statistics are described in the following table.

Symptom 1 QJSTWTB is nonzero. Reason Tasks are being suspended while the in-storage buffer is being written to the active log. There might be problems writing to the active log. The OUTBUFF parameter within CSQ6LOGP is too small. Action Investigate the problems writing to the active log. Increase the value of the OUTBUFF parameter within CSQ6LOGP.

Symptom 2 The ratio: QJSTWTL/N logread is greater than 1%. Reason Log reads were initiated that had to read from an archive log, but IBM MQ could not allocate a data set because MAXRTU data sets were already allocated. Action Increase MAXRTU.

Symptom 3 The ratio: QJSTRARH/N logread is larger than normal. Reason Most log read requests should come from the output buffer or the active log. To satisfy requests for back out, unit-of-recovery records are read from the in-storage buffer, the active log, and the archived logs. A long-running unit of recovery, extending over a period of many minutes, might have log records spread across many different logs. This degrades performance because extra work has to be done to recover the log records. Action Change the application to reduce the length of a unit of recovery. Also, consider increasing the size of the active log to reduce the possibility of a single unit of recovery being spread out over more than one log. Other pointers The ratio N logread /N logwrite gives an indication of how much work has to be backed out.

Symptom 4 QJSTLLCP is more than 10 an hour. Reason On a busy system, you would expect to see typically 10 checkpoints an hour. If the QJSTLLCP value is larger than this, it indicates a problem in the setup of the queue manager. The most likely reason for this is that the LOGLOAD parameter in CSQ6SYSP is too small. The other event that causes a checkpoint is when an active log fills up and switches to the next active log data set. If your logs are too small, this can cause frequent checkpoints. QJSTLLCP is a count of the total number of checkpoints. Action Increase the LOGLOAD parameter, or increase the size of our log data sets as required.

Symptom 5 QJSTCmpFail > 0 or QJSTCmpComp not much less than QJSTCmpUncmp Reason The queue manager is unable to significantly compress log records. QJSTCmpFail is the number of times the queue manager was unable to achieve any reduction in record length. We should compare the number to QJSTCmpReq (number of compression requests) to see if the number of failures is significant. QJSTCmpComp is the total of compressed bytes written to the log and QJSTCmpUncmp is the total bytes before compression. Neither total contains bytes written for log records that were not eligible for compression. If the numbers are similar then compression has achieved little benefit. Action Turn off log compression. Issue the SET LOG COMPLOG(NONE) command. See the SET LOG command for details.

Note: In the first set of statistics produced after system startup, there might be significant log activity due to the resolution of in-flight units of recovery. Parent topic: Interpreting IBM MQ for z/OS performance statistics