Long-time MQ listserver participant and colleague Peter Potkay recently posted the following info about amqiclen which he received from a PMR. My most recent developerWorks article talked about how the culture within the WMQ community tends to perpetuate established best practices even when they become out of date. This may be an example of that phenomenom at work. It remains to be seen whether the advice offered is valid for most people and then if the community will embrace a change to our long-held best practices regarding IPC cleanup and WebSphere MQ. Here then is the portion of Peter’s post that came from the PMR:
amqiclen runs as part of MQ install (the ‘i’ in the 4th character of thename). This process attempts to check that no process is currently accessing mqm owned ipc resurces, and if that is determined to be the case then it deletes those resources. The reason for amqiclen is that the layout of the control blocks in shared memory may changed from release to release and rather than each release have to understand the layout of all provious releases we explicitly delete these resources during install.
Queue manager restart takes similar action, if it detects that no active processes are accessing queue manager related IPC resources thenit deletes those resources. When queue manager restart finds that thereARE processes still accessing the IPC resources then it prints the process id of one such process in the AMQ8041 message (amqiclen is unable to do this as it can’t depend upon the layout of the control blocks in shared memory).
In rare circumstances (typically a severe user error, or an APARable condition) then MQ L3 might advise the customer to run amqiclen at a time other than install, but customers should not be choosing (or needing) to run this program themselves.
There’s a bit of historical hearsay related to manual removal of mqm owned resources. In early releases of MQ (prior to MQ 5.2) then the queue manager wasn’t 100% reliable in identifying whether IPC resources related to a previous queue manager instance were still being accessed (problems due to PID reuse) and some customers implemented ipcrm scripts to try to overcome these problems. The queue manager has now been able to reliably detect whether mqm owned IPC resources are still being accessed by an active process for a number of releases and manually removing mqm owned IPC resources is the cause of a number of instances of queue manager corruption (for no good purpose).