MQ

This is part of a series of small blog posts which will cover some of the smaller, perhaps less likely to be noticed, features of IBM MQ. Read other posts in this series.

I asked Pete Siddall during his "Ask Me Anything" event, what his favourite little feature of IBM MQ was, and his answer was EXCLINT. So let's learn a little about that little gem of a feature today.

On z/OS when running queue managers in a sysplex, they can be part of a co-operating group called a Queue Sharing Group (QSG), and then within that group of queue managers you can have a Shared Queue, that is a queue which uses the coupling facility as the storage medium, instead of the usual pagesets. Queues of this sort can be accessed by many queue managers, those that are members of the QSG in fact.

When running such a system, an important part of your restart and recovery procedure should be to take backups of the data in the coupling facility, and this can be done through MQ by using a command, BACKUP CFSTRUCT. In general a backup of your storage medium, whether the coupling facility or the page sets, should be done so that, in the event of that storage medium failing, you can recover your persistent messages without the need to replay all your queue manager logs back to the day the queue manager was created! With a backup, the logs only need to be replayed from the point of the backup, back to the present. This theory doesn't change for shared queues, it's just a different storage medium that needs to be backed up.

On the BACKUP CFSTRUCT command is a parameter called EXCLINT, or Exclude Interval. This is a way for you to dictate to the backup process that some newer, more recent messages are just simply not worth backing up. It's not that they are worthless messages, not at all. It's for some very good reasons that reduce the size of your backup without unduly affecting your restart time required after recovering from the backup.

By having an Exclude Interval, the backup process will avoid backing up messages that will not stay on the queue for very long. So if you have well behaved queues, that is, they are being processed in a timely manner, they do not take up space in the backup because it is likely that they will be processed very soon after the backup is taken. If a failure occurs they can still be recovered from the queue manager logs without having to replay back very far because they were a recently put message.

You get an Exclude Interval of 30 seconds (the minimum value allowed) by default, so you get some benefit from this even if don't deliberately use it.

Let's finish with Pete describing EXCLINT in his own words.

So inside BACKUP CFSTRUCT command is the EXCLINT parameter which says "don't bother backing up messages which arrived in the last n seconds". This means a couple of things, if shared queues stay empty, because they're good queues being drained as fast as messages arrived, there is minimal footprint in the backup for them, and more subtly, internally we realise that just by going back a little bit further on the log we can find data for the incoming message, so not bother to write it out again as part of the structure backup.