How storage classes work
- You define a storage class, using the DEFINE STGCLASS command, specifying a page set identifier (PSID).
- When you define a queue, you specify the storage class in the STGCLASS attribute.
In the following example, the local queue QE5 is mapped to page set 21 through storage class ARC2.
DEFINE STGCLASS(ARC2) PSID(21) DEFINE QLOCAL(QE5) STGCLASS(ARC2)
This means that messages that are put on the queue QE5 are stored on page set 21 (if they stay on the queue long enough to be written to DASD).
More than one queue can use the same storage class, and we can define as many storage classes as you like. For example, we can extend the previous example to include more storage class and queue definitions, as follows:
DEFINE STGCLASS(ARC1) PSID(05) DEFINE STGCLASS(ARC2) PSID(21) DEFINE STGCLASS(MAXI) PSID(05) DEFINE QLOCAL(QE1) STGCLASS(ARC1) ... DEFINE QLOCAL(QE2) STGCLASS(ARC1) ... DEFINE QLOCAL(QE3) STGCLASS(MAXI) ... DEFINE QLOCAL(QE4) STGCLASS(ARC2) ... DEFINE QLOCAL(QE5) STGCLASS(ARC2) ...
In Figure 8, both storage classes ARC1 and MAXI are associated with page set 05. Therefore, the queues QE1, QE2, and QE3 are mapped to page set 05. Similarly, storage class ARC2 associates queues QE4 and QE5 with page set 21.
If you define a queue without specifying a storage class, WebSphere MQ uses a default storage class.
If a message is put on a queue that names a nonexistent storage class, the application receives an error. You must alter the queue definition to give it an existing storage class name, or create the storage class named by the queue.
We can change a storage class only when:
- All queues that use this storage class are empty, and have no uncommitted activity.
- All queues that use this storage class are closed.
|
|