A message group is made up of (select all that apply):

Distribution list CALL MQOPEN…

2. A message group is made up of (select all that apply):

a. One or more physical messages. b. One or more logical messages.

c. Only one logical message but several physical messages. d. All of the above.

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.

3-26 WebSphere MQ Technical Introduction © Copyright IBM Corp. 2011

Instructor notes:

Purpose — Details —

Additional information — Transition statement —

Uempty

Figure 3-12. Checkpoint answers WM101 / VM1011.0

Notes:

1. Messages are recovered when a queue manager is restarted if they are: a. Saved by the operator.

b. Persistent.

c. High-priority messages.

d. Retrieved using Msgld and Correlld. Answer: b.

2. Select all that apply. A message group is made up of: a. One or more physical messages.

b. One or more logical messages.

c. Only one logical message but several physical messages. d. All of the above.

Answer: a, b.

Checkpoint answers

1. Messages are recovered when a queue manager is restarted if they

are:

a. Saved by the operator. b. Persistent.

c. High-priority messages.

d. Retrieved using Msgld and Correlld.

Answer: b.

2. A message group is made up of (select all that apply):

a. One or more physical messages. b. One or more logical messages.

c. Only one logical message but several physical messages. d. All of the above.

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.

3-28 WebSphere MQ Technical Introduction © Copyright IBM Corp. 2011

Instructor notes:

Purpose — Details —

Additional information — Transition statement —

Uempty

_{Unit 4. Intercommunication}

Estimated time

00:30

What this unit is about

This unit describes the function of interconnected systems using IBM WebSphere MQ.

What you should be able to do

After completing this unit, you should be able to:

• Describe message channels and message channel agents • Explain the function of a transmission queue

• Define how a channel is triggered • Describe queue manager clusters

How you will check your progress

• Checkpoint questions

References

www.ibm.com/software/integration/wmq/library

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.

4-2 WebSphere MQ Technical Introduction © Copyright IBM Corp. 2011

Figure 4-1. Unit objectives WM101 / VM1011.0

Notes:

Unit objectives

After completing this unit, you should be able to:

• Describe message channels and message channel agents

• Explain the function of a transmission queue

• Define how a channel is triggered

Uempty

Instructor notes:

Purpose —

Details —

Additional information — Transition statement —

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.

4-4 WebSphere MQ Technical Introduction © Copyright IBM Corp. 2011

Figure 4-2. The message channel WM101 / VM1011.0

Notes:

The figure is a review of the structure of a simple network connection.

An application issues an MQPUT call. As a result, a message is placed on the transmission queue. A message channel agent (MCA) is started, which reads the message from the queue, and sends it to a partner MCA. The partner MCA places the message on the destination queue. At some point, the target application issues an MQGET call and reads the message from the queue.

Sending a message requires:

• A delivery mechanism across the link

• A connection mechanism between the systems

• A protocol between the sending MCA and the receiving MCA

The physical link can be anything the system supports such as token ring, and ATM. The connection mechanism can be SNA LU6.2, TCP/IP NetBIOS, DECnet, or SPX. Not all of these connection mechanisms are supported on all platforms. The WebSphere MQ

The message channel

MCA Transmission queue MCA Destination queue Channel Physical link Application 1 MQPUT Application 2 MQGET Queue manager QM1 Queue manager QM2

Uempty Intercommunications manual discusses the networking setup requirements of various

WebSphere MQ environments.

The message channel protocol between the message channel agents is the common thread that allows the MCAs on the various platforms to communicate.

A transmission queue is an ordinary local queue with the Usage attribute set to MQUS_TRANSMISSION instead of MQUS_NORMAL.

Only a queue manager (not an application) should put a message directly on a

transmission queue, and only an MCA should get a message from a transmission queue. The reason for this process is that a message on a transmission queue must have a special header called the transmission queue header. The queue manager provides the header when it puts the message on the transmission queue. The header also

accompanies the message when it is sent across a message channel. The receiving MCA removes the header before putting the message on the destination queue. Normally, an application program does not need to be aware of this header.

To reach a destination queue on a remote queue manager, the local queue manager needs to know which transmission queue to put the message on. Each queue manager contains common software known as the moving service component, which allows a queue manager to communicate with other queue managers.

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.

4-6 WebSphere MQ Technical Introduction © Copyright IBM Corp. 2011

Instructor notes:

Purpose — Take a moment to walk them through the process of putting a message. Details — Point out that the WebSphere MQ channel message flow is unidirectional. If two-way message flow is wanted, at least two channels need to be defined. You look at the various MCA types in a moment.

It is important to remind students that the application program that performs an MQPUT call may specify a queue name when it does so. The MQPUT does not know where the

ultimate destination queue is. The queue manager handles the actual resolution of the name and delivery of the message.

The figure illustrates the following concepts: • A (network) connection.

The nature of the connection depends on the network protocol being used. For SNA LU6.2, a connection is a conversation on an LU-LU session, and the two message channel agents are the transaction programs (TPs) participating in the conversation. For TCP/IP, a connection is simply a TCP/IP connection that the message channel agents use.

• A message channel is the means by which messages are transmitted from a

transmission queue at one queue manager to a destination queue at an adjacent queue manager. Specifically, a message channel consists of a message channel agent at the sending end, a network connection, and a message channel agent at the receiving end. • A channel definition.

Each end of a message channel has its own definition.

When an application wants to put a message on a remote queue, how does the queue manager know which transmission queue to use? The most common approach is to provide a transmission queue with the same name as the remote queue manager. On the transmission queue, the message is accompanied by the transmission queue header, structure MQXQH, which contains:

• The remote queue name.

• The remote queue manager name.

• The message descriptor structure MQMD.

Uempty

Figure 4-3. Types of channels WM101 / VM1011.0

Notes:

There is a pair of MCAs for each message channel: a sending MCA, and a receiving MCA. A sending MCA is one that sends messages over a network connection to a receiving MCA at the other end.

When defining a channel at one end of the channel, a sending MCA may be defined as a SENDER or a SERVER, and a receiving MCA as a RECEIVER or a REQUESTER. The last set of channels listed serves a specific purpose. These channels support the connection between a WebSphere MQ server (SVRCONN) and the WebSphere MQ client (CLNTCONN).

In the figure, an arrow with a dotted line indicates a control flow at channel initiation. In particular, the first such arrow for each pair of MCAs represents the control flow that makes initial contact for the channel. The solid line arrows indicate the direction of flow of the messages once the channel has started.

A RECEIVER or a server connection (SVRCONN) cannot start a channel; the other types can do so.

Types of channels

Transmission queue Destination queue Transmission queue Transmission queue Transmission queue Destination queue Destination queue Destination queue SENDER SERVER SENDER SERVER RECEIVER RECEIVER REQUESTER REQUESTER Control flow Message flow Key

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.

4-8 WebSphere MQ Technical Introduction © Copyright IBM Corp. 2011

Generally, every channel must be defined at both ends of the channel, and the name of the channel must be the same at both ends.

When a channel is being defined, each end must be allocated a channel type as part of its definition. There are six channel types to choose from:

• Sender • Receiver • Requester • Server

• Server connection (SVRCONN) • Client connection (CLNTCONN)

The channel types at both ends of a channel must be compatible with one another, and the graphic depicts the compatible combinations. The compatible combinations of channel types are:

Sender-receiver

Sender-receiver is the most frequently used combination.

Requester-server

Requester-server can be used when the end of the channel that sends the messages is not able to start the channel. It can be running unattended and unable to issue the appropriate command.

This combination can also be used when the physical network connection between two nodes is not permanent. A notebook computer, which can be connected to a server machine, might be one example. In this case, the most appropriate combination might be one that allows the notebook, when it is connected, to start a channel and then receive messages from the server machine.

Requester-sender (callback)

In this combination, the requester starts the channel but the sender closes it

immediately. The sender then restarts the channel according to its channel definition. This feature is known as callback. For example, It can provide additional security when the request to start a channel is coming from an untrusted environment.

Server (fully defined) — receiver or requester

A fully defined server is one whose channel definition has the attributes needed to start a channel; in particular, the LU name, the TCP host name, or the IP address. This combination is essentially the same as the sender-receiver combination in terms of function.

Client connection - server connection (not shown the figure)

This combination is reserved for use only in the MQI client environment. The client initiates the connection when the MQCONN is issued. Data about the MQI calls flow in both directions. The connection is terminated when the MQDISC is issued.

Uempty

Instructor notes:

Purpose — Introduce the message channel types.

Details — The main criteria for selecting the channel type at each end of a channel are: • Only a sender, a requester, and a fully defined server are able to start a channel. • Only a sender and a server are able to get messages from a transmission queue and

send them to the other end of the channel.

• Only a requester and a receiver are able to receive messages from the other end of the channel and put them on their respective destination queues.

• An SVRCONN is only started when the MQCONN is issued at the client side. This rule applies only to the MQI client environment, and is not shown on the diagram.

The attributes of the channel definition at one end of a channel depend on the channel type at that end. For example, only those channel types that are able to start a channel need the attributes to be able to perform this task. There are some sample channel definitions later that illustrate this fact.

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.

4-10 WebSphere MQ Technical Introduction © Copyright IBM Corp. 2011

Figure 4-4. Starting a channel WM101 / VM1011.0

Notes:

Channels can be started in several ways on most queue managers:

• An operator can start most channels using a command-line command or an interface. • The transmission queue can be defined as a triggered queue, and the channel can be

started when messages arrive that satisfy the triggering conditions.

• Certain channel types can be started remotely from the network.

In the figure, the channel initiator is a special version of a trigger monitor used to start channels. The process used to start channels based on triggering is the same as starting other applications.

Starting and stopping a RECEIVER or an SVRCONN does not start or stop the flow of data; it merely enables or disables the channel to be started from the other side.

Queue manager QM2 Queue manager QM1

Starting a channel

MQPUT… Sender Channel initiator

Operator command: START QM1_QM2

Receiver Queue QM2.Q1 (remote queue) Queue QM2 SYSTEM.CHANNEL.INITQ (initq) Queue QM2.Q1 (local) Physical link

Uempty

Instructor notes:

Purpose — Describe starting a channel.

Details — With communications between queue managers, it is common practice to trigger the channel when data is placed in its transmission queue. This practice allows channels to be automatically shut down during periods of inactivity, resulting in a more efficient use of system resources.

The client channel is started when the application issues the MQCONN. This process implies that a listener is active on the server and that an SVRCONN has been defined. There are various ways of starting a channel, including:

• From a command line or panel application • An application program

• By a message appearing in a transmission queue which causes a trigger event, which in turn causes the message channel agent at the sending end to be started

• Remotely from the network

Transition statement — Just as a channel can be started in several ways, it can be stopped using various alternatives.

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.

Figure 4-5. Stopping a channel WM101 / VM1011.0

Notes:

Usually, channels between queue managers run for long periods. They are started and service a particular transmission queue. However, it is not always best to leave a channel running forever. There is a disconnect value associated with the channel. It allows for normal quiescing of a channel that is active but without work for a specified period. It is possible to manually stop channels by command as well.

Channels can also stop during error conditions. Because WebSphere MQ provides assured message delivery, messages you want to keep are not lost.

Stopping a channel

Queue manager QM1 MCA Transmission queue MQGET MCA Destination queue Channel Physical link MQPUT Queue manager QM2

Uempty

Instructor notes:

Purpose — Discuss ways channels are stopped.

Details — The ways channels are stopped, and the various states they may be in, are a point requiring much more time than is allocated here. It is covered nicely in the

WebSphere MQ Intercommunication manual, and the WebSphere MQ System Administration courses cover them in more detail.

As a start, it is practical to remind students that there is a default disconnect interval associated with channels, and most people use that value to start.

Be careful with issuing a STOP CHANNEL command. It disables triggering of the channel if on the sender side. On the receiver side, it causes the channel to be impossible to start, even if a START CHANNEL is issued from the sender side.

Additional information — If you have a receiver or SVRCONN channel definition, there might be many channel instances using that single definition. The STOP CHANNEL options allow you to target independent instances, and not stop all of the identically named channels. The STOP can be targeted at either the partner machine (CONNAME) or the partner queue manager (QMNAME)

Transitional Statement — Examine remote queues and how they allow application flexibility.

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.

Figure 4-6. Remote queues WM101 / VM101q1.0

Notes:

Although it may be transparent to the sending application, the queue manager needs to know where to route messages. When a program wants to send a message to a queue on another system, the application can name the queue and the queue manager to be used. This information allows the sending queue manager to complete the necessary addressing information in the WebSphere MQ transmission queue header (MQXQH). The message is then placed on a transmission queue, either one with the same name as the remote queue manager or, if it is defined, as the default transmission queue of the local queue manager. However, specifying the queue manager name at the application code level is generally not the best solution, except in the case of sending replies.

Usually, a program simply opens a queue without specifying a queue manager. This method is an indication to the local queue manager that the queue named by the

application is one that is found among its own definitions (not necessarily a local queue). One of the types of definitions that the queue manager checks is the QREMOTE definition. If the queue named by the application is a QREMOTE definition, the queue manager can use the information from that definition to complete the addressing information in the

Remote queues

Queue manager QM1 Channel Physical link Queue manager QM2 QM2 (transmit queue) Queue Q2 (QREMOTE pointing to Q3) Queue Q3 Application 1 MQPUT (Q2)

Application does not need to specify queue manager name to MQPUT, even if not connected to that queue manager

Uempty MQXQH. The QREMOTE also allows for the specification of a transmission queue to be

used. The queue manager can then place the message on a named transmission queue, allowing for greater flexibility. You explore the use of these alternatives as you proceed.

Note

An application may MQPUT to a remote queue, but it cannot issue an MQGET call to a remote queue.

For example, you can send a letter from any mailbox (queue manager). You have to be local to the mailbox (queue manager) to retrieve the letter. However, WebSphere MQ zSeries has the capability for multiple queue managers to share a single local queue from an MQGET perspective.

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.

Instructor notes:

Purpose — Describe the QREMOTE definition and its use by the queue manager.

Details — In this example, a program can explicitly open Q3 at QM2 for output. The queue manager uses that information to build the transmission header (MQXQH), and looks for a transmission queue with the same name as the remote queue manager. It is possible there may be a defined queue manager alias that allows that name to be resolved. In addition, if all else fails, the queue manager may have a default transmission queue. If so, any

messages that cannot be delivered to a specific transmission queue, based on the definitions and the MQOPEN statement, are placed on that queue.

Additional information — Default transmission queues are useful, but can be troublesome if definitions are not carefully controlled. It is feasible that your payroll information could be sent to a system (and end up on its dead letter queue) that does access to that information. Defaults are not used much.

Transition statement — So far, you have described an environment where a queue manager sends all the information it has across one channel. Review it in detail.

In document WM1011-VM1011INST (Page 175-200)