Private and global definitions

 

+

Search Tips   |   Advanced Search

 

When you define an object on WebSphere MQ for z/OS, we can choose whether you want to share that definition with other queue managers (a global definition), or whether the object definition is to be used by one queue manager only (a private definition). This is called the object disposition.

Global definition

If your queue manager belongs to a queue-sharing group, we can choose to share any object definitions you make with the other members of the group. This means that you have to define an object once only, reducing the total number of definitions required for the whole system.

Global object definitions are held in a shared repository (a DB2 shared database), and are available to all the queue managers in the queue-sharing group. These objects have a disposition of GROUP.

Private definition

If you want to create an object definition that is required by one queue manager only, or if your queue manager is not a member of a queue-sharing group, we can create object definitions that are not shared with other members of a queue-sharing group.

Private object definitions are held on page set zero of the defining queue manager. These objects have a disposition of QMGR.

We can create private definitions for all types of WebSphere MQ objects except CF structures (that is, channels, namelists, process definitions, queues, queue managers, storage class definitions, and authentication information objects), and global definitions for all types of objects except queue managers.

WebSphere MQ automatically copies the definition of a group object to page set zero of each queue manager that uses it. We can alter the copy of the definition temporarily if you want, and WebSphere MQ allows you to refresh the page set copies from the repository copy if required. WebSphere MQ always tries to refresh the page set copies from the repository copy on start up (for channel commands, this is done when the channel initiator restarts), or if the group object is changed. This ensures that the page set copies reflect the version on the repository, including any changes that were made when the queue manager was inactive. The copies are refreshed by generating DEFINE REPLACE commands, therefore there are circumstances under which the refresh is not performed, for example:

In these circumstances, the refresh is not performed on that copy, but is performed on the copies on all other queue managers.

If the queue manager is shut down and then restarted stand-alone, any local copies of objects are deleted, unless for example, the queue has associated messages.

There is a third object disposition that applies to local queues only. This allows you to create shared queues. The definition for a shared queue is held on the shared repository and is available to all the queue managers in the queue-sharing group. In addition, the messages on a shared queue are also available to all the queue managers in the queue sharing group. This is described in Shared queues and queue-sharing groups. Shared queues have an object disposition of SHARED.

The following table summarizes the effect of the object disposition options for queue managers started stand-alone, and as a member of a queue-sharing group.

Disposition Stand-alone queue manager Member of a queue-sharing group
QMGR Object definition held on page set zero. Object definition held on page set zero.
GROUP Not allowed. Object definition held in the shared repository. Local copy held on page set zero of each queue manager in the group.
SHARED Not allowed. Queue definition held in the shared repository. Messages available to any queue manager in the group.

 

Manipulating global definitions

If you want to change the definition of an object that is held in the shared repository, we need to specify whether you want to change the version on the repository, or the local copy on page set zero. Use the object disposition as part of the command to do this.