How are destination object attributes resolved for aliases, remote queues and cluster queues?

When name resolution is performed on behalf of an application API call, attributes affecting the use of the object are resolved from a combination of the originally named object, the path (see Queue name resolution), and the resolved target object. In a queue manager cluster, the named object in question is the clustered object (queue or topic) definition. This is a subset of the object attributes shared between queue managers and visible through. for example, DISPLAY QCLUSTER.

Where an attribute can be defined on the named object opened by the application, this takes precedence. For example, all DEF**** attributes (default persistence, priority, and asynchronous put response) can be configured on alias and remote queue definitions. These take effect when the alias or remote queue is opened by an application, rather than any resolved destination queue or transmission queue.

Attributes designed to restrict or limit application interaction with a target object cannot typically be defined on the named object (remote queue definition or alias). For example, MAXMSGL and MAXDEPTH cannot be set on a remote queue definition or alias, and are not passed between members of a queue manager cluster. These attributes are therefore taken from the resolved queue (for example the local queue, appropriate transmission queue, or SYSTEM.CLUSTER.TRANSMIT.QUEUE). On arrival at a remote queue manager, a second constraint might be applied on delivery to the target queue, which could result in a message being placed on a dead letter queue, or the channel being forced to stop.

Note that a special case of attribute resolution is PUT and GET enablement. For both of these attributes, any instance of DISABLED in the queue path results in an overall resolved attribute of DISABLED.

Parent topic: Queue name resolution