Properties of trigger messages
The following topics describe some other properties of trigger messages.
- Persistence and priority of trigger messages
- Queue manager restart and trigger messages
- Trigger messages and changes to object attributes
- Format 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.
This has the following fields, which the queue manager fills when it creates the trigger message, using information in the object definitions of the application queue and of the process associated with that queue:
- 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 IBM MQ product except IBM 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 in ProcessName.
- 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 in ProcessName. When we use trigger monitor CKTI or CSQQTRMN supplied by IBM MQ for z/OS, the ApplId 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 in ProcessName. The IBM 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 in ProcessName. 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.