MQPMO options (MQLONG)

The Options field controls the operation of MQPUT and MQPUT1 calls.

Scope option. We can specify any or none of the MQPMO options. To specify more than one option, either add the values together (do not add the same constant more than once), or combine the values using the bitwise OR operation (if the programming language supports bit operations). Combinations that are not valid are noted; any other combinations are valid.

The following option controls the scope of the publications sent:

    MQPMO_SCOPE_QMGR
    The publication is sent only to subscribers that have subscribed on this queue manager. The publication is not forwarded to any remote publish/subscribe queue managers that have made a subscription to this queue manager, which overrides any behavior that has been set using the PUBSCOPE topic attribute. Note: If not set, the publication scope is determined by the PUBSCOPE topic attribute.

Publishing options. The following options control the way messages are published to a topic:

    MQPMO_SUPPRESS_REPLYTO

    Any information specified in the ReplyToQ and ReplyToQMgr fields of the MQMD of this publication is not passed on to subscribers. If this option is used with a report option that requires a ReplyToQ, the call fails with MQRC_MISSING_REPLY_TO_Q.

    MQPMO_RETAIN

    The publication being sent is to be retained by the queue manager. This retention allows a subscriber to request a copy of this publication after the time it was published, by using the MQSUBRQ call. It also allows a publication to be sent to applications which make their subscription after the time this publication was made (unless they choose not to be sent it by using the option MQSO_NEW_PUBLICATIONS_ONLY). If an application is sent a publication which was retained, it is indicated by the MQIsRetained message property of that publication.

    Only one publication can be retained at each node of the topic tree. Therefore, if there already is a retained publication for this topic, published by any other application, it is replaced with this publication. It is therefore better to avoid having more than one publisher retaining messages on the same topic.

    When retained publications are requested by a subscriber, the subscription used might contain a wildcard in the topic, in which case a number of retained publications might match (at various nodes in the topic tree) and several publications might be sent to the requesting application. See the description of the MQSUBRQ - Subscription request call for more details.

    For information about how retained publications interact with subscription levels, see Intercepting publications.

    If this option is used and the publication cannot be retained, the message is not published and the call fails with MQRC_PUT_NOT_RETAINED.

    MQPMO_NOT_OWN_SUBS
    Tells the queue manager that the application does not want to send any of its publications to subscriptions it owns. Subscriptions are considered to be owned by the same application if the connection handles are the same.

    MQPMO_WARN_IF_NO_SUBS_MATCHED
    If no subscription matches the publication, return a completion code (CompCode) of MQCC_WARNING and reason code MQRC_NO_SUBS_MATCHED.

    If MQRC_NO_SUBS_MATCHED is returned by the put operation, the publication was not delivered to any subscriptions. However, if the MQPMO_RETAIN option is specified on the put operation, the message is retained and delivered to any subsequently defined matching subscription.

    A subscription on the topic matches the publication if any of the following conditions are met:

    • The message is delivered to the subscription queue
    • The message would have been delivered to the subscription queue but a problem with the queue means that the message cannot be put to the queue, and it was consequently placed on the dead letter queue or discarded.
    • A routing exit is defined that suppresses delivery of the message to the subscription

    A subscription on the topic does not match the publication if any of the following conditions are met:

    • The subscription has a selection string that does not match the publication
    • The subscription specified the MQSO_PUBLICATION_ON_REQUEST option
    • The publication is not delivered because the MQPMO_NOT_OWN_SUBS option was specified on the put operation and the subscription matches the identity of the publisher

Syncpoint options. The following options relate to the participation of the MQPUT or MQPUT1 call within a unit of work:

    MQPMO_SYNCPOINT
    The request is to operate within the normal unit-of-work protocols. The message is not visible outside the unit of work until the unit of work is committed. If the unit of work is backed out, the message is deleted.

    If MQPMO_SYNCPOINT and MQPMO_NO_SYNCPOINT are not specified, the inclusion of the put request in unit-of-work protocols is determined by the environment running the queue manager and not the environment running the application. On z/OS, the put request is within a unit of work. In all other environments, the put request is not within a unit of work.

    Because of these differences, an application that we want to port must not allow this option to default; specify either MQPMO_SYNCPOINT or MQPMO_NO_SYNCPOINT explicitly.

    Do not specify MQPMO_SYNCPOINT with MQPMO_NO_SYNCPOINT.

    MQPMO_NO_SYNCPOINT
    The request is to operate outside the normal unit-of-work protocols. The message is available immediately, and it cannot be deleted by backing out a unit of work.

    If MQPMO_NO_SYNCPOINT and MQPMO_SYNCPOINT are not specified, the inclusion of the put request in unit-of-work protocols is determined by the environment running the queue manager and not the environment running the application. On z/OS, the put request is within a unit of work. In all other environments, the put request is not within a unit of work.

    Because of these differences, an application that we want to port must not allow this option to default; specify either MQPMO_SYNCPOINT or MQPMO_NO_SYNCPOINT explicitly.

    Do not specify MQPMO_NO_SYNCPOINT with MQPMO_SYNCPOINT.

Message-identifier and correlation-identifier options. The following options request the queue manager to generate a new message identifier or correlation identifier:

    MQPMO_NEW_MSG_ID
    The queue manager replaces the contents of the MsgId field in MQMD with a new message identifier. This message identifier is sent with the message, and returned to the application on output from the MQPUT or MQPUT1 call.

    The MQPMO_NEW_MSG_ID option can also be specified when the message is being put to a distribution list; see the description of the MsgId field in the MQPMR structure for details.

    Use this option relieves the application of the need to reset the MsgId field to MQMI_NONE before each MQPUT or MQPUT1 call.

    MQPMO_NEW_CORREL_ID
    The queue manager replaces the contents of the CorrelId field in MQMD with a new correlation identifier. This correlation identifier is sent with the message, and returned to the application on output from the MQPUT or MQPUT1 call.

    The MQPMO_NEW_CORREL_ID option can also be specified when the message is being put to a distribution list; see the description of the CorrelId field in the MQPMR structure for details.

    MQPMO_NEW_CORREL_ID is useful in situations where the application requires a unique correlation identifier.

Group and segment options. The following options relate to the processing of messages in groups and segments of logical messages. Read the definitions that follow to help you to understand the option.Attention: We cannot use segmented or grouped messages with Publish/Subscribe.

    Physical message
    The is the smallest unit of information that can be placed on or removed from a queue; it often corresponds to the information specified or retrieved on a single MQPUT, MQPUT1, or MQGET call. Every physical message has its own message descriptor (MQMD). Generally, physical messages are distinguished by differing values for the message identifier (MsgId field in MQMD), although this is not enforced by the queue manager.

    Logical message
    A logical message is a single unit of application information for non- z/OS platforms only. In the absence of system constraints, a logical message is the same as a physical message. But where logical messages are extremely large, system constraints might make it advisable or necessary to split a logical message into two or more physical messages, called segments.

    A logical message that has been segmented consists of two or more physical messages that have the same non-null group identifier (GroupId field in MQMD), and the same message sequence number (MsgSeqNumber field in MQMD). The segments are distinguished by differing values for the segment offset (Offset field in MQMD), which gives the offset of the data in the physical message from the start of the data in the logical message. Because each segment is a physical message, the segments in a logical message usually have differing message identifiers.

    A logical message that has not been segmented, but for which segmentation has been permitted by the sending application, also has a non-null group identifier, although in this case there is only one physical message with that group identifier if the logical message does not belong to a message group. Logical messages for which segmentation has been inhibited by the sending application have a null group identifier (MQGI_NONE), unless the logical message belongs to a message group.

    Message group
    A message group is a set of one or more logical messages that have the same non-null group identifier. The logical messages in the group are distinguished by differing values for the message sequence number, which is an integer in the range 1 through n, where n is the number of logical messages in the group. If one or more of the logical messages is segmented, there are more than n physical messages in the group.

    MQPMO_LOGICAL_ORDER
    This option tells the queue manager how the application puts messages in groups and segments of logical messages. It can be specified only on the MQPUT call; it is not valid on the MQPUT1 call. If MQPMO_LOGICAL_ORDER is specified, it indicates that the application uses successive MQPUT calls to:
    1. Put the segments in each logical message in the order of increasing segment offset, starting from 0, with no gaps.
    2. Put all the segments in one logical message before putting the segments in the next logical message.
    3. Put the logical messages in each message group in the order of increasing message sequence number, starting from 1, with no gaps. IBM MQ increments the message sequence number automatically.
    4. Put all the logical messages in one message group before putting logical messages in the next message group.

    For detailed information about MQPMO_LOGICAL_ORDER, see Logical and physical ordering

Context options. The following options control the processing of message context:

    MQPMO_NO_CONTEXT
    Both identity and origin context are set to indicate no context. This means that the context fields in MQMD are set to:

    • Blanks for character fields
    • Nulls for byte fields
    • Zeros for numeric fields

    MQPMO_DEFAULT_CONTEXT
    The message is to have default context information associated with it, for both identity and origin. The queue manager sets the context fields in the message descriptor as follows:

    Field in MQMD Value used
    UserIdentifier Determined from the environment if possible; set to blanks otherwise.
    AccountingToken Determined from the environment if possible; set to MQACT_NONE otherwise.
    ApplIdentityData Set to blanks.
    PutApplType Determined from the environment.
    PutApplName Determined from the environment if possible; set to blanks otherwise.
    PutDate Set to the date when message is put.
    PutTime Set to the time when message is put.
    ApplOriginData Set to blanks.
    For more information about message context, see Message context.

    These are the default values and actions if no context options are specified.

    MQPMO_PASS_IDENTITY_CONTEXT
    The message is to have context information associated with it. Identity context is taken from the queue handle specified in the Context field. Origin context information is generated by the queue manager in the same way that it is for MQPMO_DEFAULT_CONTEXT (see the preceding table for values). For more information about message context, see Message context.

    For the MQPUT call, the queue must have been opened with the MQOO_PASS_IDENTITY_CONTEXT option (or an option that implies it). For the MQPUT1 call, the same authorization check is carried out as for the MQOPEN call with the MQOO_PASS_IDENTITY_CONTEXT option.

    MQPMO_PASS_ALL_CONTEXT
    The message is to have context information associated with it. Context is taken from the queue handle specified in the Context field. For more information about message context, see Control context information.

    For the MQPUT call, the queue must have been opened with the MQOO_PASS_ALL_CONTEXT option (or an option that implies it). For the MQPUT1 call, the same authorization check is carried out as for the MQOPEN call with the MQOO_PASS_ALL_CONTEXT option.

    MQPMO_SET_IDENTITY_CONTEXT
    The message is to have context information associated with it. The application specifies the identity context in the MQMD structure. Origin context information is generated by the queue manager in the same way that it is for MQPMO_DEFAULT_CONTEXT (see the preceding table for values). For more information about message context, see Message context.

    For the MQPUT call, the queue must have been opened with the MQOO_SET_IDENTITY_CONTEXT option (or an option that implies it). For the MQPUT1 call, the same authorization check is carried out as for the MQOPEN call with the MQOO_SET_IDENTITY_CONTEXT option.

    MQPMO_SET_ALL_CONTEXT
    The message is to have context information associated with it. The application specifies the identity, origin, and user context in the MQMD structure. For more information about message context, see Message context.

    For the MQPUT call, the queue must have been opened with the MQOO_SET_ALL_CONTEXT option. For the MQPUT1 call, the same authorization check is carried out as for the MQOPEN call with the MQOO_SET_ALL_CONTEXT option.

We can specify only one of the MQPMO_*_CONTEXT context options. If you specify none, MQPMO_DEFAULT_CONTEXT is assumed.

Property options. The following option relates to the properties of the message:

    MQPMO_MD_FOR_OUTPUT_ONLY
    The message descriptor parameter must only be used for output to return the message descriptor of the message that was put. The message descriptor fields associated with the NewMsgHandle, OriginalMsgHandle, or both fields, of the MQPMO structure must be used for input.

    If a valid message handle is not provided then the call fails with reason code MQRC_MD_ERROR.

Put response options. The following options control the response returned to an MQPUT or MQPUT1 call. We can specify only one of these options. If MQPMO_ASYNC_RESPONSE and MQPMO_SYNC_RESPONSE are not specified, MQPMO_RESPONSE_AS_Q_DEF or MQPMO_RESPONSE_AS_TOPIC_DEF is assumed.

    MQPMO_ASYNC_RESPONSE
    The MQPMO_ASYNC_RESPONSE option requests that an MQPUT or MQPUT1 operation is completed without the application waiting for the queue manager to complete the call. Using this option can improve messaging performance, particularly for applications using client bindings. An application can periodically check, using the MQSTAT verb, whether an error has occurred during any previous asynchronous calls.
    With this option, only the following fields are guaranteed to be completed in the MQMD;

    • ApplIdentityData
    • PutApplType
    • PutApplName
    • ApplOriginData

    Additionally, if either or both of MQPMO_NEW_MSG_ID or MQPMO_NEW_CORREL_ID are specified as options, the MsgId and CorrelId returned are also completed. (MQPMO_NEW_MSG_ID can be implicitly specified by specifying a blank MsgId field).

    Only the preceding specified fields are completed. Other information that would normally be returned in the MQMD or MQPMO structure is undefined.
    When requesting asynchronous put response for MQPUT1, the ResolvedQName and ResolvedQMgrName returned in the MQOD structure are undefined.
    When requesting asynchronous put response for MQPUT or MQPUT1, a CompCode and Reason of MQCC_OK and MQRC_NONE does not necessarily mean that the message was successfully put to a queue. When developing an MQI application that uses asynchronous put response and requires confirmation that messages have been put to a queue we must check both CompCode and Reason codes from the put operations and also use MQSTAT to query asynchronous error information.
    Although the success or failure of each individual MQPUT or MQPUT1 call mightnot be returned immediately, the first error that occurred under an asynchronous call can be determined later through a call to MQSTAT.
    If a persistent message under syncpoint fails to be delivered using asynchronous put response, and you attempt to commit the transaction, the commit fails and the transaction is backed out with a completion code of MQCC_FAILED and a reason of MQRC_BACKED_OUT. The application can make a call to MQSTAT to determine the cause of a previous MQPUT or MQPUT1 failure.

    MQPMO_SYNC_RESPONSE
    Specify this put response type ensures that the MQPUT or MQPUT1 operation is always issued synchronously. If the put operation is successful, all fields in the MQMD and MQPMO are completed.
    This option ensures a synchronous response irrespective of the default put response value defined on the queue or topic object.

    MQPMO_RESPONSE_AS_Q_DEF
    If this value is specified for an MQPUT call, the put response type used is taken from the DEFPRESP value specified on the queue when it was first opened by the application.

    • If the queue is a cluster queue, and this value is specified for an MQPUT call, the put response type used is taken from the DEFPRESP attribute defined at the destination queue manager that owns the particular instance of the queue on which the message is placed.

      When there are multiple instances of the cluster queue, and they differ in this attribute, the value from one of them is picked and it cannot be predicted which one will be used. We should therefore set this attribute to the same value on all instances. If this is not the case, error message AMQ9407 is issued to the queue manager logs. See also How are destination object attributes resolved for aliases, remote and cluster queues?

    • If the queue is not a cluster queue, and this value is specified for an MQPUT call, the put response type used is taken from the DEFPRESP attribute defined at the local queue manager, even if the destination queue manager is remote.

    If a client application is connected to a queue manager at a level earlier than Version 7.0, it behaves as if MQPMO_SYNC_RESPONSE was specified.
    If this option is specified for an MQPUT1 call, the value of the DEFPRESP attribute is not known before the request is sent to the server. By default, if the MQPUT1 call is using MQPMO_SYNCPOINT it behaves as for MQPMO_ASYNC_RESPONSE, and if it is using MQPMO_NO_SYNCPOINT it behaves as for MQPMO_SYNC_RESPONSE. However, we can override this default behavior by setting the Put1DefaultAlwaysSync property in the client configuration file, see CHANNELS stanza of the client configuration file.

    MQPMO_RESPONSE_AS_TOPIC_DEF
    MQPMO_RESPONSE_AS_TOPIC_DEF is a synonym for MQPMO_RESPONSE_AS_Q_DEF for use with topic objects.

Other options. The following options control authorization checking, what happens when the queue manager is quiescing, and resolving queue and queue manager names:

    MQPMO_ALTERNATE_USER_AUTHORITY
    MQPMO_ALTERNATE_USER_AUTHORITY indicates that the AlternateUserId field in the ObjDesc parameter of the MQPUT1 call contains a user identifier that is to be used to validate authority to put messages on the queue. The call can succeed only if AlternateUserId is authorized to open the queue with the specified options, regardless of whether the user identifier under which the application is running is authorized to do so. (This does not apply to the context options specified, however, which are always checked against the user identifier under which the application is running.)

    This option is valid only with the MQPUT1 call.

    MQPMO_FAIL_IF_QUIESCING
    This option forces the MQPUT or MQPUT1 call to fail if the queue manager is in the quiescing state.

    On z/OS, this option also forces the MQPUT or MQPUT1 call to fail if the connection (for a CICS or IMS application) is in the quiescing state.

    The call returns completion code MQCC_FAILED with reason code MQRC_Q_MGR_QUIESCING or MQRC_CONNECTION_QUIESCING.

    MQPMO_RESOLVE_LOCAL_Q
    Use this option to fill ResolvedQName in the MQPMO structure with the name of the local queue to which the message is put, and ResolvedQMgrName with the name of the local queue manager that hosts the local queue. For more information about MQPMO_RESOLVE_LOCAL_Q, see topic MQOO_RESOLVE_LOCAL_Q.

    If we are authorized to put to a queue, you have the required authority to specify this flag on the MQPUT call; no special authority is needed.

Default option. For none of the options described, use the following option:

    MQPMO_NONE
    Use this value to indicate that no other options have been specified; all options assume their default values. MQPMO_NONE is defined to aid program documentation; it is not intended that this option be used with any other, but as its value is zero, such use cannot be detected.

MQPMO_NONE is an input field. The initial value of the Options field is MQPMO_NONE.

Parent topic: Fields for MQPMO