Properties of trigger messages
The following topics describe some other properties of trigger messages.
Persistence and priority of trigger messages
Trigger messages are not persistent because there is no requirement for them to be so.
However, the conditions for generating triggering events do persist, so trigger messages are generated whenever these conditions are met. If a trigger message is lost, the continued existence of the application message on the application queue guarantees that the queue manager generates a trigger message as soon as all the conditions are met.
If a unit of work is rolled back, any trigger messages it generated are always delivered.
Trigger messages take the default priority of the initiation queue.
Queue manager restart and trigger messages
Following the restart of a queue manager, when an initiation queue is next opened for input, a trigger message can be put to this initiation queue if an application queue associated with it has messages on it, and is defined for triggering.
Trigger messages and changes to object attributes
Trigger messages are created according to the values of the trigger attributes in force at the time of the trigger event.
If the trigger message is not made available to a trigger monitor until later (because the message that caused it to be generated was put within a unit of work), any changes to the trigger attributes in the meantime have no effect on the trigger message. In particular, disabling triggering does not prevent a trigger message being made available once it has been created. Also, the application queue might no longer exist at the time that the trigger message is made available.
Format of trigger messages
The format of a trigger message is defined by the MQTM structure.
StrucId
- The structure identifier.
Version
- The version of the structure.
QName
- The name of the application queue on which the trigger event occurred.
When the queue manager creates a trigger message, it fills this field
using the
QName
attribute of the application queue. ProcessName
- The name of the process definition object that is associated with
the application queue. When the queue manager creates a trigger message,
it fills this field using the
ProcessName
attribute of the application queue. TriggerData
- A free-format field for use by the trigger monitor. When the queue
manager creates a trigger message, it fills this field using the
TriggerData
attribute of the application queue. On any WebSphere® MQ product except WebSphere MQ for z/OS®, this field can be used to specify the name of the channel to be triggered. ApplType
- The type of the application that the trigger monitor is to start.
When the queue manager creates a trigger message, it fills this field
using the
ApplType
attribute of the process definition object identified inProcessName
. ApplId
- A character string that identifies the application that the trigger
monitor is to start. When the queue manager creates a trigger message,
it fills this field using the
ApplId
attribute of the process definition object identified inProcessName
. When you use trigger monitor CKTI or CSQQTRMN supplied by WebSphere MQ for z/OS, theApplId
attribute of the process definition object is a CICS® or IMS transaction identifier. EnvData
- A character field containing environment-related data for use
by the trigger monitor. When the queue manager creates a trigger message,
it fills this field using the
EnvData
attribute of the process definition object identified inProcessName
. The WebSphere MQ for z/OS-supplied trigger monitors (CKTI or CSQQTRMN) do not use this field, but other trigger monitors might choose to use it. UserData
- A character field containing user data for use by the trigger
monitor. When the queue manager creates a trigger message, it fills
this field using the
UserData
attribute of the process definition object identified inProcessName
. This field can be used to specify the name of the channel to be triggered.
There is a full description of the trigger message structure in MQTM.