CF structures

This might affect Task 9 in Customizing your queue managers.

WebSphere MQ local queue objects defined with QSGDISP(SHARED) have their messages stored on a Coupling Facility (CF) list structure so that they can be accessed by any other queue managers within the queue-sharing group. The Coupling Facility list structure is defined to z/OS by the CFRM policy. V5.3 introduced a WebSphere MQ object called a CF structure that describes capabilities through the CFLEVEL and RECOVER attributes. The MQSC commands DEFINE CFSTRUCT, ALTER CFSTRUCT, DELETE CFSTRUCT, and DISPLAY CFSTRUCT have been added for these objects.

As with the CFSTRUCT attribute of queues, the name is specified without the initial four-character queue-sharing group name that forms the name used by z/OS; all WebSphere MQ messages now use the short form of the name.

In MQSeries for OS/390 V5.2, CF structure objects were implicitly created and deleted. When the first queue naming a CF structure was defined, a CF structure object with that name was implicitly created. Similarly, when the last queue naming a CF structure was deleted, the CF structure object was deleted. These CF structure operations happened invisibly to the user. Such CF structure objects have CFLEVEL(1).

CF structure objects defined with CFLEVEL(2) (on a V5.3.1 queue manager) are for compatibility between V5.2 and V5.3.1 queue managers. They can be used by V5.2 queue managers, and they can be used and manipulated by V5.3.1 queue managers.

CF structure objects defined with CFLEVEL(3) are only usable by Version 5.3.1 queue managers. New function is supported for queues defined on a CFLEVEL(3) CF structure.

Once all queue managers in the queue-sharing group are at V5.3.1 level, we can migrate a CF structure from CFLEVEL(2) to CFLEVEL(3) using the DEFINE REPLACE or ALTER CFSTRUCT commands.

The RECOVER attribute of a CF structure specifies whether messages in the structure can be recovered if the structure fails.

There are very strict conditions that apply before a CF structure can be altered. For these conditions and all the command details see the WebSphere MQ Script (MQSC) Command Reference.

 

CFLEVEL(3) functions

Queues defined on a CFLEVEL(3) CF structure can have the new INDXTYPE(GROUPID) attribute.

Persistent messages can be stored on a queue defined on a CF structure with CFLEVEL(3) and the RECOVER(YES) attribute. The MQSC commands BACKUP CFSTRUCT and RECOVER CFSTRUCT are provided to support recovery. Ensure that regular backups of such structures are taken.

To use the RECOVER CFSTRUCT command, all the active and archive log data sets, and bootstrap data sets of each queue manager in a queue-sharing group must be accessible to each other. You must ensure that your security setup allows this, and use Access Method Services to change the SHAREOPTIONS of these data sets to be (2 3), for example:

ALTER '++hlq++.logcopy.ds01.data' SHAREOPTIONS (2 3)

For CF structure objects with CFLEVEL(3) only, in the unlikely event of the failure of a coupling facility structure, a V5.3.1 queue manager remains active. Any in-flight units of work are backed out, but units of work that have progressed beyond commit are disconnected from the applications (which can terminate normally) and are be completed when the CF structure becomes available. However, MQSeries for OS/390 V5.2 queue managers will terminate abnormally.

 

Recommendations

It is recommended that as soon as a V5.3.1 queue manager is started in a mixed version queue-sharing group, you alter your CF structure objects to be CFLEVEL(2). This stops them being implicitly deleted by a V5.2 queue manager in the queue-sharing group.

Once all queue managers in the queue-sharing group have been migrated to V5.3.1, alter all CF structure objects to have CFLEVEL(3). This gives greater resilience in the unlikely event of a Coupling Facility structure failure, as V5.3.1 queue managers can tolerate the failure of a CFLEVEL(3) CF structure.