I’ve been keeping a running blog post of questions and answers from the WebSphere MQ Admin seminar this week in Amsterdam, but the more I researched this topic, the longer the answer became. Eventually, it spilled over into its own post.
It turns out that the behavior and controls have changed from version to version and even across Fix Packs. That means after applying a fix Pack or upgrading to a new version, things might break. For a new QMgr it won’t “break” anything but it might not behave as expected if you set the parameters based on the old version. Here then is the story of the many facets of error log size tuning.
Q: I need to increase the size of my MQ error logs. Where are the error log file sizes specified?
A: The log file sizes can be tuned using the MAXMQERRORLOGSIZE environment variable, the qm.ini file and/or the QMgr attributes in the WebSphere MQ Explorer Extended Attributes panel. If the environment variable is changed, the queue manager and local applications must be restarted to pick up the change. If the ini file is changed, the queue manager (but not the local applications) must be restarted to pick up the change, after which the value will be visible in the WebSphere MQ Explorer Extended Attributes panel. If the size is adjusted using by altering the queue manager attribute in WMQ Explorer, it takes effect immediately and the value is saved to the ini file by the queue manger. Note that there is no equivalent MQSC command for this attribute. It is available as PCF and WMQ Explorer exposes it in the Extended Attributes panel. Other PCF-based tools may or may not expose this attribute.
The features regarding error log size differ slightly by version so here are links and descriptions for each.
As of v5.3, the MQMAXERRORLOGSIZE environment variable allowed for increase of the size of the global error logs and the queue manager’s error logs. The problem with this was that any process for which the environment variable was not set would truncate the error logs to 256k. Additionally, on iSeries you needed to delete the existing files in order to make the change as described here.
As of V6.0, an attribute was placed in the qm.ini file that eliminated the problem of having to put the environment variable everywhere. But the ini file setting only affected the queue manager’s logs and was not available on iSeries. If you wanted to change the global error log sizes, you still needed the environment variable.
As of Fix Pack 126.96.36.199, the the MQMAXERRORLOGSIZE variable was still available on all distributed platforms, including iSeries, but in the first release and the early fix packs of V6.0 MQMAXERRORLOGSIZE affected only the global error logs. If the enviroment variable was used but the qm.ini file did not contain an entry, the queue manager’s log file size remained at 256k. This behavior was changed in Fix Pack 188.8.131.52 so that in the absence of an ini file setting, the environment variable applied to the global and the queue manager error log files. If both the MQMAXERRORLOGSIZE environment variable and the qm.ini’s ErrorLogSize and are set, the qm.ini setting takes precedence for that queue manager’s error logs. The Infocenter page is here. A Technote that further explains all this is here.
As of V7.0, the MQMAXERRORLOGSIZE variable is completely absent from the Infocenter, however it is mentioned in a Technote as being applicable to that version. The qm.ini file setting is documented however, and the Infocenter page describing how to change the qm.ini file or use WMQ Explorer to update the setting is here.
As of V7.1, both the environment variable and the qm.ini file setting are documented. More importantly, the default size of the logs was changed from 256k to 2MB which could eliminate the need for tuning if you had been using a value equal to or smaller than that size. The Infocenter doesn’t specify that this applies to only QMgr logs or only global logs so it applies to both. I haven’t confirmed this yet so if you notice it isn’t acting this way, please let me know. There is a small possibility that the new defaults apply only to QMgr error logs and the Infocenter is wrong.
In the event you have iSeries and would still like to tune the error log sizes above 4MB, the Infocenter page does not mention WebSphere MQ Explorer, nor does it mention any requirement to delete the existing files before changing the setting. However, the Technote mentioned previously is marked as applicable to V7.1 so plan on deleting the error log files if you change this value on V7.1.
On other distributed platforms, the option to use WMQ Explorer is offered and you can choose that or to update the qm.ini file. The Infocenter page for that option is here.
Interestingly, the MQMAXERRORLOGSIZE environment variable is mentioned in the Infocenter for V7.1 as applying only to the queue manager files. The global error log files are not addressed. Googling for “mq errorlogsize 7.1 technote” doesn’t turn up any hits. If the Infocenter had not explicitly specified “queue manager error logs” I would have assumed the variable retained the old behavior of applying to the global error logs as well. If you have a V7.1 setup, I’d be curious what behavior you are seeing with regard to this variable and the global error logs.
As of V7.5, the Infocenter has the same content as for V7.1. However, since this is the version I have on my laptop and can test easily, I tried setting MQMAXERRORLOGSIZE as a global system variable, rebooted and generated massive quantities of global and QMgr-specific errors. In all cases, the logs rotated at 2MB. In instances like this I always assume I’ve got a typo or other PEBCAK error so I’ll try again tomorrow and keep this post updated as I go.
My conclusion from all this is that if error log size is important to you (for example, your QMgr tends to roll them over before you can diagnose an error) then it is worth verifying that your setting is appropriate, especially if you have changed versions or are running a large network with many different versions. Alternatively, you may wish to capture the AMQERR03.LOG files whenever the timestamp changes. In windows you may wish to look at Microsoft’s Process Monitor utility and in Linux the iNotify facility looks like it would do the trick. I’ll look at these at some point when I get a free afternoon and post results, but if you try them before then please let me know how it goes.