Does your z/OS queue manager have enough active log space? And how to fix it!

Does your z/OS queue manager have enough active log space? And how to fix it!

gwydiontudur |Apr 27 2017 Updated

I recently saw a queue manager at a customer site that was filling the active logs every 30 minutes at peak time, and only had 3 active logs defined. This means that they only had 90 minutes before their MQ workload would stop if they had a problem with archiving. Common causes of problems with archiving are running out of disk space or being unable to write to tapes.

Background

MQ writes data to the log whenever it processes persistent messages or transactions. It writes the data to active log data sets. When each active log data set fills up the data is offloaded to an archive log data set, which frees up the active log data set so that it can be used again. This process is called archiving.
If all the active log data sets become full, for example because there is a problem with archiving, the queue manager won't be able to process any more persistent messages or transactions. So your important workload will grind to a halt.
As a guideline, your z/OS queue manager should have enough active log space to run for 12-24 hours. This will give you time to fix any problems with archiving and avoid an outage caused by the active logs filling up.

What you need to do

So how do you go about adding more active log space if you need to do so?

Generally, we recommend making your active logs bigger, rather than just adding more data sets. This means that the queue manager will not need to take checkpoints when it switches active logs as often, which is good for performance. You may need to both make your active logs bigger and add more in order to have enough space.

1. Check that there is enough space available for the larger, and more, active logs, and enough space for the archive logs, as these will become bigger too.
2. Check the SMS rules for allocating the active logs. For performance reasons, consider striping the active logs across four volumes.
3. Define the new active logs slightly under 3 or 4GB. You can define active logs up to 4GB in size at MQ V8 and later; 3GB for earlier versions of MQ. With four stripes you'll need to specify a value of either smaller than 3/4GB (1092 cylinders) or smaller than 4/4GB (1456 cylinders) for IDCAMS DEFINE.
4. Format the new log data sets using the CSQJUFMT utility.
5. Add the new logs to the queue manager dynamically using the DEFINE LOG command.
6. Change the queue manager archive parameters so the archive log space parameters (PRIQTY and SECQTY parameters of CSQ6ARVP) match new active log size.
7. Recompile the queue manager parameters (ZPARMs).
8. Issue the ARCHIVE LOG command to cause the queue manager to switch active log data set until one of the new active logs is being used.
9. Check the size of the new active log that is in use by subtracting STARTRBA from ENDRBA in message CSQJ001I. This will give you the size of the active log in bytes, and should be what you were expecting.
10. Shut down the queue manager cleanly.
11. Check that the old active logs are no longer needed by printing the contents of the BSDS with the CSQJU004 utility. The old active logs should all the marked as RESUABLE.
12. Remove the old active logs from the BSDS using the DELETE function of the CSQJU003 utility.
13. Restart the queue manager.
14. Monitor the first few times logs are archived to make sure is works successfully.
15. After a period of a few days, delete the old active logs that are no longer used.

Thanks to Colin Paice for providing the inspiration for this blog!