Buffers and buffer pools for IBM MQ for z/OS

IBM MQ for z/OS® uses buffers and buffer pools to temporarily cache data. Use this topic to further understand how buffers are organized, and used.

For efficiency, IBM MQ uses a form of caching whereby messages (and object definitions) are stored temporarily in buffers before being stored in page sets on DASD. Short-lived messages, that is, messages that are retrieved from a queue shortly after they are received, might only ever be stored in the buffers. This caching activity is controlled by a buffer manager, which is a component of IBM MQ.

The buffers are organized into buffer pools. We can define up to 16 buffer pools (0 through 15) for each queue manager.

If OPMODE is set to OPMODE=(NEWFUNC, 800), we can define up to 100 buffer pools (0 through 99) for each queue manager.

You are recommended to use the minimal number of buffer pools consistent with the object and message type segregation outlined in Figure 1, and any data isolation requirements our application might have. Each buffer is 4 KB long. Buffer pools use 31 bit storage by default, in this mode, the maximum number of buffers is determined by the amount of 31 bit storage available in the queue manager address space; do not use more than about 70% for buffers. Alternatively, buffer pool storage allocation can be made from 64 bit storage (use the LOCATION attribute of the DEFINE BUFFPOOL command). Using LOCATION(ABOVE) so that 64 bit storage is used has two benefits. Firstly, there is much more 64 bit storage available so buffer pools can be much bigger, and secondly, 31 bit storage is made available for use by other functions. Typically, the more buffers we have, the more efficient the buffering and the better the performance of IBM MQ.

Figure 1 shows the relationship between messages, buffers, buffer pools, and page sets. A buffer pool is associated with one or more page sets; each page set is associated with a single buffer pool.

We can dynamically issue commands to modify buffer pool size, and location, using the ALTER BUFFPOOL command. Pagesets can be dynamically added by using the DEFINE PSID command, or deleted by using the DELETE PSID command.

If a buffer pool is too small, IBM MQ issues message CSQP020E. We can then dynamically add more buffers to the affected buffer pool (note that you may have to remove buffers from other buffer pools to do this).

You specify the number of buffers in a pool with the DEFINE BUFFPOOL command, and we can dynamically resize buffer pools with the ALTER BUFFPOOL command. You determine the current number of buffers in a pool dynamically by displaying a page set that uses the buffer pool, using the DISPLAY USAGE command.

For performance reasons, do not put messages and object definitions in the same buffer pool. Use one buffer pool (say number zero) exclusively for page set zero, where the object definitions are kept. Similarly, keep short-lived messages and long-lived messages in different buffer pools and therefore on different page sets, and in different queues.

The DEFINE BUFFPOOL command cannot be used after restart to create a new buffer pool. Instead, if a DEFINE PSID command uses the DSN keyword, it can explicitly identify a buffer pool that is not currently defined. That new buffer pool will then be created.