Message context

Message context information allows the application that retrieves the message to find out about the originator of the message.

• Check that the sending application has the correct level of authority
• Perform some accounting function so that it can charge the sending application for any work that it has to perform
• Keep an audit trail of all the messages that it has worked with

When we use the MQPUT or MQPUT1 call to put a message on a queue, we can specify that the queue manager is to add some default context information to the message descriptor. Applications that have the appropriate level of authority can add extra context information. For more information about how to specify context information, see Control message context information.

• Confirm on delivery
• Expiry

When these report messages are generated, the user context is checked for +put and +passid authority on the destination of the report. Where the user context has insufficient authority, the report message is placed on the dead-letter queue if one has been defined. Where there is no dead-letter queue, the report message is discarded.

All context information is stored in the context fields of the message descriptor. The type of information falls into identity, origin, and user context information.

Identity context

• The queue manager fills the UserIdentifier field with a name that identifies the user; the way that the queue manager can do this depends on the environment in which the application is running.
• The queue manager fills the AccountingToken field with a token or number that it determined from the application that put the message.
• Applications can use the ApplIdentityData field for any extra information that they want to include about the user (for example, an encrypted password).

A Windows systems security identifier (SID) is stored in the AccountingToken field when a message is created under IBM MQ for Windows. The SID can be used to supplement the UserIdentifier field and to establish the credentials of a user.

For information about how the queue manager fills the UserIdentifier and AccountingToken fields, see the descriptions of these fields in UserIdentifier and AccountingToken.

Applications that pass messages from one queue manager to another should also pass on the identity context information so that other applications know the identity of the originator of the message.

Origin context

• PutApplType defines the type of application that put the message (for example, a CICS transaction).
• PutApplName defines the name of the application that put the message (for example, the name of a job or transaction).
• PutDate defines the date on which the message was put on the queue.
• PutTime defines the time at which the message was put on the queue.
• ApplOriginData defines any extra information that an application wants to include about the origin of the message. For example, it could be set by suitably authorized applications to indicate whether the identity data is trusted.

Origin context information is typically supplied by the queue manager. Greenwich Mean Time (GMT) is used for the PutDate and PutTime fields. See the descriptions of these fields in PutDate and PutTime.

An application with enough authority can provide its own context. This allows accounting information to be preserved when a single user has a different user ID on each of the systems that process a message that they have originated.

IBM MQ objects

This information provides details on IBM MQ objects which include: queue managers, queue sharing groups, queues, administrative topic objects, namelists, process definitions, authentication information objects, channels, storage classes, listeners, and services.

Queue managers define the properties (known as attributes) of these objects. The values of these attributes affect the way in which IBM MQ processes these objects. From the applications, we use the Message Queue Interface (MQI) to control these objects. Objects are identified by an object descriptor (MQOD) when addressed from a program.

When we use IBM MQ commands to define, alter, or delete objects, for example, the queue manager checks that we have the required level of authority to perform these operations. Similarly, when an application uses the MQOPEN call to open an object, the queue manager checks that the application has the required level of authority before it allows access to that object. The checks are made on the name of the object being opened.

Related concepts

• Control message context information

Related reference

• MQOPEN options relating to message context