Emergency storage - basic configuration

How you set up a basic scenario for emergency storage on IBM® MQ.

About this task

SMDS and message offloading can be used in conjunction with SCM to reduce the likelihood of an MQRC_STORAGE_MEDIUM_FULL reason code being returned to an IBM MQ application during an extended outage.

For example, your enterprise has an application that puts messages onto the queue and an application that gets messages from the queue. During normal running, you expect the queue depth to be close to zero, but a business requirement indicates that the system be able to tolerate a two-hour outage of the application that gets the messages.

This means that the shared queue being used must be able to contain two hours of messages from the putting application. Currently you achieve this by using the default offload rules, and SMDS.

You expect the rate of messages being sent to the shared queue to double in the short to medium term. Although your requirement that the system be able to tolerate a two-hour outage still exists, not enough real storage is available in the CF to double the size of the structure. Because the CF containing the application structure resides on a zEC12 machine, you have the capability of associating sufficient SCM with the structure to store enough messages, so that a two-hour outage can be tolerated

This initial scenario uses a:

• Queue sharing group, IBM1, that contains a single queue manager, CSQ3. In addition to the administration structure, the queue sharing group defined a single application structure, SCEN1.
• Coupling facility (CF) CF01, in which the SCEN1 application structure is stored as the IBM1SCEN1 structure. This structure has a maximum size of 1 GB.
• Single shared queue, SCEN1.Q that the application structure uses.

This configuration is illustrated in Figure 1.

Furthermore, assume that queue manager CSQ3 is already the only member of queue sharing group IBM1.

You must add the definition for structure IBM1SCEN1 to the coupling facility resource manager (CFRM) policy. For simplicity, the structure is defined so that it can be created in only a single coupling facility, CF01, by specifying PREFLIST(CF01).

Attention: To allow for high availability in your production system, you should include at least two CFs in the PREFLIST for any structures that are used by IBM MQ.

1. Refresh the CFRM policy by using the following command:

   
   SETXCF START,POLICY,TYPE=CFRM,POLNAME=IBM1SCEN1
   

   Sample CFRM policy for structure IBM1SCEN1:

   
   STRUCTURE
   NAME(IBM1SCEN1)
   SIZE(1024M)
   INITSIZE(512M)
   ALLOWAUTOALT(YES)
   FULLTHRESHOLD(85)
   PREFLIST(CF01)
   ALLOWREALLOCATE(YES)
   DUPLEX(DISABLED)
   ENFORCEORDER(NO)
   

2. Verify that the structure has been created correctly, by using the following command:

   
   D XCF,STR,STRNAME=IBM1SCEN1
   

   At this point, your structure has not been allocated, shown by the STATUS line, to the queue sharing group.

3. Configure IBM MQ to make use of the structure defined in the CFRM policy.
   1. Use the DEFINE CFSTRUCT command, with the structure name of SCEN1 to create an IBM MQ CFSTRUCT object:

      
      DEFINE CFSTRUCT(SCEN1)
      CFCONLOS(TOLERATE)
      CFLEVEL(5)
      DESCR('Structure for SCM scenario 1')
      RECOVER(NO)
      RECAUTO(YES)
      OFFLOAD(DB2)
      OFFLD1SZ(64K) OFFLD1TH(70)
      OFFLD2SZ(64K) OFFLD2TH(80)
      OFFLD3SZ(64K) OFFLD3TH(90)
      

      .
   2. Validate the structure, using the DISPLAY CFSTRUCT command.
   3. Define the SCEN1.Q shared queue, to use the SCEN1 structure, using the following MQSC command:

      
      DEFINE QLOCAL(SCEN1.Q) QSGDISP(SHARED) CFSTRUCT(SCEN1) MAXDEPTH(999999999)
      

4. Use IBM MQ Explorer to put a single message to the queue SCEN1.Q and take the message off again.
5. Issue the following command to check that the structure is now allocated:

   
   D XCF,STR,STRNAME=IBM1SCEN1
   

   Check in the output from the command, that the STATUS line shows ALLOCATED.