How storage class memory works with IBM MQ for z/OS
An overview of the use of storage class memory (SCM) with IBM® MQ for z/OS® shared queues.
A structure is configured to use SCM by specifying both the SCMALGORITHM and SCMMAXSIZE keywords in the coupling facility resource manager (CFRM) policy, containing the definition of that structure.
Note that after these keywords are specified, and the CFRM policy is applied, the structure must be rebuilt, or deallocated so that they can take effect.
Because the input/output speed of SCM is slower than that of real storage, the CF uses an algorithm that is tailored to the expected use of the structure in order to reduce the impact of writing to, or reading from, SCM.
The algorithm is configured by the SCMALGORITHM keyword in the CFRM policy for the structure, using the KEYPRIORITY1 value. Note that you should use the KEYPRIORITY1 value only with list structures used by IBM MQ shared queues.
The KEYPRIORITY1 algorithm works by assuming that most applications will get messages from a shared queue in priority order; that is, when an application gets a message, it gets the oldest message with the highest priority.
When a structure starts to fill past the system-defined threshold of 90%, the CF starts asynchronously migrating messages that are least likely to be got next. These are messages with lower priorities that were more recently put on the queue.
This asynchronous migration of messages from the structure into SCM is known as "pre-staging".
Pre-staging reduces the performance cost of using SCM because it reduces the chance of an application being blocked during the occurrence of synchronous input/output to SCM.
In addition to pre-staging, the KEYPRIORITY1 algorithm also asynchronously brings back messages from SCM and into the structure when sufficient free space is available. For the KEYPRIORITY1 algorithm, this means that when the structure is less than or equal to 70% full.
The act of bringing messages from SCM into the structure is known as "pre-fetching".
Pre-fetching reduces the likelihood of an application trying to get a message that has been pre-staged to SCM and having to wait while the CF synchronously brings back the message into the structure.
The CF uses various data structures to track its use of SCM. These data structures reside in the real storage that is allocated to the CF and, as a result, reduce the amount of real storage that can be used by structures. The storage used by these data structures is known as "augmented space".
When a structure is configured with SCM, a small amount of real storage is allocated from the CF to the structure known as fixed augmented space. This is allocated even if the structure never actually uses any SCM. As data from the structure is stored into SCM, extra dynamic augmented space will be allocated from the spare real storage in the CF.
When the data is removed from SCM, the dynamic augmented space is returned to the CF. Augmented space, either fixed or dynamic, is never taken from the real storage that is allocated to a structure.
In addition to augmented storage, when a structure is configured to use SCM, the amount of control storage used by that structure increases. This means that a list structure configured with SCM can contain fewer entries and elements than a structure of the same size without SCM being configured.
To understand the impact of SCM on new or existing structures, use the CFSizer tool.
A final important point to note is that after data is moved from the structure into SCM, and dynamic augmented space has been used, the structure cannot be altered either manually or automatically.
That is, the amount of storage allocated to the structure cannot be increased or decreased, the entry-to-element ratio that is used by the structure cannot be changed, and so on. To make the structure alterable again, the structure must not have any data stored in SCM and must not be making use of dynamic augmented storage.