Designing your messages

 

You create a message when you use an MQI call to put the message on a queue. As input to the call, you supply some control information in a message descriptor (MQMD) and the data that you want to send to another program. But at the design stage, we need to consider the following questions, because they affect the way that you create your messages:

What type of message should I use?

Are you designing a simple application in which we can send a message, then take no further action? Or are you asking for a reply to a question? If you are asking a question, you might include in the message descriptor the name of the queue on which you want to receive the reply.

Do you want your request and reply messages to be synchronous? This implies that you set a timeout period for the reply to answer your request, and if you do not receive the reply within that period, it is treated as an error.

Or would you prefer to work asynchronously, so that your processes do not have to depend upon the occurrence of specific events, such as common timing signals?

Another consideration is whether you have all your messages inside a unit of work.

Should I assign different priorities to some of the messages that I create?

We can assign a priority value to each message, and define the queue so that it maintains its messages in order of their priority. If you do this, when another program retrieves a message from the queue, it always gets the message with the highest priority. If the queue does not maintain its messages in priority order, a program that retrieves messages from the queue will retrieve them in the order in which they were added to the queue.

Programs can also select a message using the identifier that the queue manager assigned when the message was put on the queue. Alternatively, we can generate your own identifiers for each of your messages.

Will my messages be discarded when the queue manager restarts?

The queue manager preserves all persistent messages, recovering them when necessary from the WebSphere MQ log files, when it is restarted. Nonpersistent messages and temporary dynamic queues are not preserved. Any messages that you do not want discarded must be defined as persistent when they are created. When writing an application for WebSphere MQ for Windows or WebSphere MQ on UNIX systems, make sure that you know how your system has been set up in respect of log file allocation to reduce the risk of designing an application that will run to the log file limits.

Because messages on shared queues (only available on WebSphere MQ for z/OS) are held in the Coupling Facility (CF), nonpersistent messages are preserved across restarts of a queue manager as long as the CF remains available. If the CF fails, nonpersistent messages are lost.

Do I want to give information about myself to the recipient of my messages?

Usually, the queue manager sets the user ID, but suitably authorized applications can also set this field, so that we can include your own user ID and other information that the receiving program can use for accounting or security purposes.

 

Parent topic:

Overview of application design

fg10420_