Queue WebSphere (Queue Manager , Diffrerent types of queue )

Messages WebSphere MQ Message Descriptor (MQMD): Identifies the message and contains additional control information, such as the type of message and the priority that is assigned to the message by the sending application. Message properties: An optional set of user-definable elements that describes the message without being part of the payload. Applications that receive messages can choose whether to inspect these properties. Message data: Contains the application data. The structure of the data is defined by the application programs that use it; WebSphere MQ is largely unconcerned with its format or content. Message descriptor (MQMD) The MsgType describes the high-level purpose of the message. The most frequently used values in this field are datagram, request, reply, and report. A datagram is set by the sending application when it is not expecting any response from the receiving application. MsgID (message ID) and CorrelID (correlation ID) are used to identify a specific request or reply message. The programmer can set a value in one or both fields or have WebSphere MQ automatically create a unique ID. These fields are 24 bytes long and are not treated as characters that can be converted between code pages, such as ASCII to EBCDIC. A normal pattern for application programs is that the message ID that is generated by WebSphere MQ when a message is put to a queue is used to identify responses sent back to the designated reply queue. The program that receives the request message copies the incoming message ID into the correlation ID of the reply message. This allows the originating program (the one that gets the reply) to instruct the queue manager to return a specific message in the reply queue instead of just getting the first message from the queue. It is particularly important when multiple applications are reading messages from the same queue. The Persistence flag selects whether the message must be treated as persistent, and therefore recoverable in a system failure, or whether the message is non-persistent and can be discarded when an error occurs. A programmer can explicitly set persistence to be on or off, or allow the value to be controlled by a system administrator. Queues can hold a combination of persistent and non-persistent messages Messages have a Priority that is set as a value between 1 and 10. An administrator can define that messages are retrieved in priority order, rather than true first in first out (FIFO) sequencing. the PutTime and PutDate Messages might have Expiry time. When sending a request message, the responding application must be told where to send the reply. This is usually done by providing the ReplyToQ and ReplyToQMgr names in the initial request. The Format field describes the message data. It is often set to MQSTR (to denote text data) or NONE (to denote binary data), but there are other possible values. In some cases, the body of the message is itself made up of additional WebSphere MQ-defined structures and the format field tells WebSphere MQ what to do with that data. User-defined formats can also be used. The format setting causes data conversion to take place when it is needed. For example, it causes WebSphere MQ to convert text data between ASCII and EBCDIC code pages (the CodedCharSetId field) when the sending and receiving applications are on different systems using those character sets information about the sending application (program name and path) and the platform on which it is running are set in the PutApplType and PutApplName fields Each time a message is backed out, the BackoutCount is increased. An application can check this counter and act on it, for example, send the message to a different queue where the reason for the backout is analyzed by an administrator. Messages can be sent as part of a related group. The receiving application can then wait until all messages from the group have arrived before starting its processing. Message grouping also guarantees that the order in which the messages are sent is preserved. The GroupId and MsgSeqNumber fields in the MQMD define this processing. Message properties The most important objects from this set are queues, channels, topics, and the queue manager itself. Queue manager It is the queue manager that manages the storage of data and the recovery after a failure. The queue manager coordinates all the applications updating messages on queues, and deals with the isolation and locking that are required to maintain consistency. The queue manager maintains statistics and status information for reporting, as needed. qUEUE LOCAL queue = p;ace where message are physically store Alias Queue = pointer to a local queue remote queue = A remote queue is another type of pointer. A remote queue definition describes a queue on another queue manager. When an application opens a remote queue, the queue manager to which the application is connected ensures that messages are tagged and stored locally in preparation for sending to another queue manager. Applications cannot read messages from remote queues Model queue - Used by application to dynamically create a real queue . Use to create a unique for reply messages deleted when application end . Dynamic queue - queues are created by the process of opening a model queue. They are real local queues, but they cannot be explicitly created through administration interfaces. There are two subtypes of dynamic queue: A temporary dynamic queue (TDQ) is automatically deleted when the application that caused it to be created ends. A permanent dynamic queue (PDQ) survives the creating application and can be reused by another application Special queue Transmission queue local queue with the USAGE(XMITQ) attribute configured. It is a staging point for messages that are destined for a remote queue manager. Typically, there is one transmission queue for each remote queue manager to which the local queue manager might connect directly. If the destination is unavailable, messages build up on the transmission queue until the connection can be successfully completed. Transmission queues are transparent to the application. When an application opens a remote queue, the queue manager internally creates a reference to the relevant transmission queue and messages are put there Initiation queue An initiation queue is a local queue to which the queue manager writes a trigger message when certain conditions are met on another local queue. For example, this is done when a message is put into an empty message queue or in a transmission queue. Such a trigger message is transparent to the programmer, but it is a powerful mechanism to cause applications or channels to start executing only when there is work to be processed. For more information about how this process works, see 3.5, “Triggering” on page 39 A dead-letter queue (DLQ) is usually defined when a queue manager is created. It is used for situations when a queue manager cannot deliver a message across a channel. Here are some examples: The destination queue is full. The destination queue does not exist. Message puts have been inhibited on the destination queue. The sender is not authorized to use the destination queue. The message is too large When these conditions are met, the messages are written to the DLQ. A queue manager has at most one DLQ. Messages are only sent to the DLQ after they have successfully been put to a local transmission queue first. If an application putting a message receives an error that indicates the output queue is full, the message is not put to a DLQ. The message is never accepted by the queue manager for processing. Events queue The queue manager generates event messages when certain things happen. For example, events can occur when a queue is nearly full or when an application is not authorized to open a queue. These event messages are written to one of the predefined event queues and can then be processed by management tools. All event queues have similar names that indicate the type of event that is held there. SYSTEM.ADMIN.QMGR.EVENT or SYSTEM.ADMIN.CHANNEL.EVENT are examples of queue manager event queues