The default for WebSphere MQ is circular logging. If you do not specify otherwise, when you create a queue manager it will have circular logging invoked.
Changing the type of logging in the qm.ini after queue manager has been created will not change the way the queue manager handles logging. If you wish to convert from circular to linear or vice versa, you would have to recreate the queue manager specifying the new type of logging at creation time.
Linear logging allows you to recreate lost or damaged data by replaying the contents of the log. This developerWorks article gives a comparison between circular and linear logs to help you evaluate which one might be best for your system: Circular logs vs. linear logs
Note (4/7/2017): For an update on linear logging, see Mark Whitlock's blog post "Logger enhancements for MQ v9.0.2" on MQdev.
Should you choose to use linear logs, this will require that you manage the log files. Otherwise, the log files will grow infinitely and eventually fill your file system. You can archive inactive logs because they are not required for media recovery.
There are some free MQ SupportPacs such as MS0L, M073, and MS62 available to assist with linear log file management and cleanup but these are provided “as-is” and without warranty or support by IBM.
You can determine which logs are no longer needed by monitoring the specific messages reporting the logs required for media and recovery.
Periodically, the queue manager issues a pair of messages to indicate which of the log files are needed:
- Message AMQ7467 gives the name of the oldest log file required to restart the queue manager. This log file and all newer log files must be available during queue manager restart.
- Message AMQ7468 gives the name of the oldest log file needed for media recovery.
Note, the log files required will change as checkpoints and record images are performed and the messages AMQ7468 and AMQ7467 will get updated to reflect the required logs for queue manager restart and media recovery.
Running rcdmqimg (record media image) writes the image of objects to the log for media recovery, thereby freeing up old log files for archival or deletion. But the rcdmqimg command does not run automatically so it must be run manually or from an automatic task you have created.
Often when troubleshooting log problems, I request an output listing of the log file directory (for example, ls -ltR /var/mqm/log). This helps determine the number of logs, when they were written and may give clues as to how fast the logs are being utilized.
You need to keep all log files back to the oldest log file required for media recovery (message AMQ7468) in order to recovery qmgr objects regardless if you archive them or not. You can save space and archive the log files between the log file required for media recovery up through the log file required for restarting the queue manager (message AMQ7467). All log files older than the log file required for Media recovery are not required and can be deleted.
Only log files required for queue manager restart, active log files, are required to be online. Inactive log files can be copied to an archive medium such as tape for disaster recovery, and removed from the log directory. Inactive log files that are not required for media recovery can be considered as superfluous log files. You can delete superfluous log files if they are no longer of interest to your operation.
For more information about MQ Logging, refer to the information center topic on Managing logs.
Related post: Logger enhancements for MQ v9.0.2