NTAC:3NS-20 We are currently running MQ V7.1 (z/OS 2.2) and plan to migrate to V9 early next year. A couple of weeks ago we had an issue where a application 'audit queue' residing in pageset 01, along with the dynamic command queues, filled up the pageset due to an application error. This caused us to not be able to use the MQ ISPF interface or run batch jobs containing MQ commands. We could still issue commands via SDSF, and our response was to empty out and move this audit queue to pageset 02. We then found over 1400 orphaned dynamic command queues, 120+ with commands queued in them. We cleared the command queues manually and deleted them and the issue was resolved. IBM put some recommendations into the PMR around pageset guidelines, and we are looking to redo our pagesets to something that protects us against issues like this. We currently have 6 pagesets. Issue #1 is to move local queues out of pageset 01 so that the dynamic command queues don't get impacted by an application error again. We will be doing this. We have created two new pagesets (06 and 07) with the intention of isolating the audit queue into one and moving another audit queue that was discovered into the other, however, the application team made a change to stop using the audit queue so for now this is not an emergency. IBM recommended that we change the program that writes to these audit queues to use a database instead of MQ for them. I've passed that recommendation on.
Does anyone have any suggestions for the layout of MQ pagesets? How many is too many? Why is it too many? Do other folks isolate application queues into their own pagesets, or are they intermingled by type, function or some other way? Thanks in advance! Jim ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
