MQ Page Sets

[stevepalmer]

What can cause a page set to file and can it recover by itself....?

 

[kevinf2349]

Lots of messages on the queue will fill a pageset up.

If you are on MVS (or any flavour of it ie z/OS), then you can pretty easily increase the size of the pageset that is giving the error. This will require a recycle of the queue manager. Of course the recycle may in itself be good enough if the messages are non-persistant. We have just had a pageset fill up and to make matters worse the system command queue was in that pageset so the queue manager wouldn't respond to any commands.....yuck! Good luck

 

[stevepalmer]

Can only messages fill up the pagesets or can monitors or recovery processes fill them us too? Ex. Candle Monitor for MQ....

 

[kevinf2349]

I wouldn't expect any monitors to fill up the Pagesets....at least if they do they wouldn't be running in my shop for long. We don't have any monitors except those written in house and they only put a very light load on the queue mainly relying on command responses. I would strongly suspect a user written program in looping or that something is not expiring messages and not doing destructive gets. Process definitions do occupy pageset space but my understanding that that was in pageset00. Which pageset is full?

 

[stevepalmer]

Pageset 1 has been growing and became full last month causing MQ to just stop accepting messages. You can imagine the issues after that. So, non-destrustive reads or persistent messages from prgms is what we should hunt for?

 

[kevinf2349]

That and non-expiry messages. You may want to write a little program to do a zero length GET (non-destructive) from a queue. Expired messages do not get deleted until the queue gets read next, if something is just putting to the queue and nothing ever reads from it the messages will not be deleted by the qmgr.

 

[kevinf2349]

You should be able to tell what storageclass resides in PAGESET 01 by displaying the storage classes. Then you can list the queues that reside in that storageclass and that should narrow your search down. At our shop pageset one is a SYSTEM storagegroup, but that isn't to say that someone hasn't defined a user queue in that class.

 

[stevepalmer]

I'll check that.
Does ti make sense that Pageset 1 would fill up (with unexpired messages and MQ would just stop working, untill it was recycled?

 

[kevinf2349]

It really depends on which Queues are in that Pageset. If (as I suspect) the SYSTEM.COMMAND.INPUT queue is in there, then the QMgr may well appear to stop communicating (especially with things like the REXX interface, Monitors etc.). To really discover what went on, you may have to resort to checking the logs (systems logs and MQ logs) or even the SMF records...if you are cutting them.

 

[stevepalmer]

What is the best way to read what's inside Pageset1 to determine if expiration is set properly or if these's other waste in there?

 

[kevinf2349]

The easiest way is probably to is:

DISPLAY STGCLASS(*) PSID(01)

Then you can do a display of the queues in the STGCLASS

DISPLAY Q(*) STGCLASS(storage class name) ALL