WebSphere MQ Solution Designer certification exam 996 prep, Part 3

WebSphere MQ Solution Designer certificationexam 996 prep, Part 3: Distributed queuemanagementSkill Level: Intermediate

Willy Farrell ([email protected])Senior Software EngineerIBM

24 Oct 2006

Prepare for the IBM Certification Test 996, WebSphere MQ Solution Designer. Thistutorial addresses various aspects of distributed queue management, includingconfiguration, application data conversion, and WebSphere MQ clients. It alsodiscusses handling exceptions and security issues. It is the third tutorial in a series offive tutorials on WebSphere MQ Solution Designer.

Section 1. Before you start

About this series

WebSphere® MQ Version 6.0 connects applications in a consistent, reliable, andeasy-to-manage way, providing a trustworthy foundation for cross department,enterprise wide integration. Providing reliable once-and-only-once delivery ofimportant messages and transactions, WebSphere MQ handles the complexities ofcommunication protocols and dynamically distributes messaging workload acrossavailable resources. This series of five tutorials helps you prepare to take the IBMcertification Test 996, IBM WebSphere MQ V6.0, Solution Design. This certificationtargets intermediate level designers who understand the concepts of asynchronousmessaging and can plan, architect, and design solutions based on WebSphere MQ.

Distributed queue management© Copyright IBM Corporation 1994, 2008. All rights reserved. Page 1 of 40

mailto:[email protected]

http://www.ibm.com/legal/copytrade.shtml

About this tutorial

This tutorial is the third in the series designed to help you prepare for the IBMCertification Test 996, WebSphere MQ V6.0, Solution Design. This tutorialaddresses distributed queue management in WebSphere MQ. After you completethis tutorial, continue with the fourth tutorial, which covers the MQI major calls.

Objectives

After completing this tutorial, you will be familiar with:

• Configuring WebSphere MQ for distributed queuing.

• WebSphere MQ clients.

• WebSphere MQ clusters.

• Scalability and performance issues.

• Application data conversion.

• Remote administration.

• Handling exceptions.

• Security features of WebSphere MQ.

• WebSphere MQ Family SupportPacs.

Prerequisites

This tutorial is written for developers and architects with intermediate experience inapplication and solution design and implementation. It assumes intermediateknowledge and skills in the following:

• Transaction management and database products

• Systems management

• Basic programming concepts

• Data communications and networking

• Information technology security concepts

System requirements

developerWorks® ibm.com/developerWorks

Distributed queue managementPage 2 of 40 © Copyright IBM Corporation 1994, 2008. All rights reserved.


The examples in this tutorial were developed with WebSphere MQ V6.0 forWindows® and Rational® Application Developer v6.0 for Windows.

The system requirements for the products used in the tutorial can be found throughthe following links:

• WebSphere MQ

• Rational Application Developer

Section 2. Configuration for distributed queuing

This section explains how to configure WebSphere MQ to enable one queuemanager to exchange messages with another.

Queue definitions for distributed queuing

The location of a remote queue can be made transparent to an application bycreating a local definition of a remote queue using the MQSC command DEFINEQREMOTE. This definition includes the name of the queue on the remote queuemanager, and the name of the remote queue manager.

The sending end of each message channel to be used for transmitting messagesbetween queue managers must also define a transmission queue. The transmissionqueue is defined in the same way as a local queue, except that the DEFINEQLOCAL command should contain the parameter USAGE(XMITQ) to indicate itspurpose.

Message channel combinations

A message channel agent (MCA) is a program that's instrumental in movingmessages from one queue manager to another. A pair of MCAs act together to forma message channel.

A channel definition provides the parameters controlling the way an MCA operates.Every message channel has two definitions -- one at each end of the channel. Thename of the channel must be the same in both definitions.

Each end of a channel has a type, and the definition of a channel at one endspecifies the type of channel at that end. The four possible types are:

ibm.com/developerWorks developerWorks®


http://www.ibm.com/developerworks/downloads/ws/wmq/?S_TACT=105AGX19&S_CMP=wescert996


http://www.ibm.com/developerworks/downloads/r/rad/?S_TACT=105AGX19&S_CMP=wescert996

http://www-306.ibm.com/software/awdtools/developer/application/sysreq/index.html


• Sender

• Receiver

• Server

• Requester

A sender or server gets messages from a transmission queue and sends them overthe network. A receiver or requester receives messages from the network and putsthem on their respective destination queues.

The definition of a channel at one end must specify a type that is compatible with thetype specified in the definition on the other end. The compatible combinations ofchannel types were described in Part 1 of this series.

Attributes of a message channel

A message channel is defined using the MQSC command DEFINE CHANNEL. Itssynonym is DEF CHL. Some of the parameters for this command are:

Parameter Definition

(channel-name) Name of the channel. The rules for naming achannel are the same as those for naming aqueue, except that the name of the channel islimited to 20 characters.

CHLTYPE The channel type. Allowed values are SDR,RCVR, SVR, and RQSTR.

TRPTYPE The transport type. This names thecommunications protocol used by the channel.

CONNAME The connection name. Is required for SDR orRQSTR channels, but optional for SVR channels.The value of this parameter depends on thecommunications protocol being used. TheWebSphere MQ Script (MQSC) CommandReference and the WebSphere MQIntercommunication manual contain full details onhow to code this parameter (see Resources).

XMITQ The name of the transmission queue. Requiredfor SDR and SVR channels.

Let's look at an example. Suppose you want to have two queue managers, one inAustin and one in Raleigh, that you need to configure to both send and receivemessages from each other. On the Austin queue manager, the definitions neededlook like this:




DEF CHL('Austin_Raleigh') +CHLTYPE(SDR) +TRPTYPE(TCP) +CONNAME('9.84.100.1(1414)') +XMITQ('Raleigh')

DEF QL('Raleigh') USAGE(XMITQ)

DEF CHL('Raleigh_Austin') +CHLTYPE(RCVR) +TRPTYPE(TCP)

In the CONNNAME parameter, you have given the TCP/IP address. You could havealso given a host name that could be resolved under DNS. Note the value 1414 inparentheses. This is the port number. 1414 is the default port number used byWebSphere MQ for TCP/IP communications, so it's not really necessary to include.

On the Raleigh queue manager, you then need definitions to match the channeldefinitions on the Austin queue manager, like this:

DEF CHL('Raleigh_Austin') +CHLTYPE(SDR) +TRPTYPE(TCP) +CONNAME('9.20.31.5(1414)') +XMITQ('Austin')

DEF QL('Austin') USAGE(XMITQ)

DEF CHL('Austin_Raleigh') +CHLTYPE(RCVR) +TRPTYPE(TCP)

Choosing a transmission queue

In determining a transmission queue to use when sending a message to a remotequeue manager, the following rules, in order, are applied:

1. Use the transmission queue named explicitly in a local definition of aremote queue.

2. Use the transmission queue with the same name as the remote queuemanager.

3. Use the default transmission queue

A default transmission queue is useful in a larger network. If the destination queuemanager is not known at the local queue manager, the basic strategy is to send it toa queue manager that does know about it.




An error is reported if the queue manager cannot find a transmission queue byapplying the above rules.

Queue manager alias

The DEFINE QREMOTE command with a blank remote queue name is used to definea queue manager alias.

By using default transmission queues and queue manager aliases, a message canbe delivered through successive queue managers in a larger network. Given anetwork of queue managers as shown in Figure 1, the following definitions willenable a message originating at queue manager QMC to be delivered to queuemanager QMF.

• On QMC, create a transmission queue named QMA and make it thedefault transmission queue.

• On QMA, create a transmission queue named QMB and define QMF as aqueue manager alias specifying QMB as the transmission queue to use.

• On QMB, create a transmission queue named QMF.

Figure 1. Queue manager network using queue aliases

Separating message flows

A queue manager alias can also be used to separate message flows between twoqueue managers. Consider two queue managers, as shown in Figure 2 below.

Figure 2. Queue managers configured for separate message flows




Now examine the definitions provided on QM1.

DEF QR(QR.SERV) +RNAME(QL.SERV) +RQMNAME(QM2) +XMITQ(QM2A)

DEF QR(QR.REPLY/A) +RN(QL.REPLY) +RQMNAME(QM1A)

DEF QR(QM1A) +RQMNAME(QM1)

Normal message traffic between the two queue managers pass through thetransmission queues QM1 and QM2. However, you have provided separate flows forthe communication between Program X and Program Y.

Program X puts a request message on queue QR.SERV. QR.SERV is a localdefinition of a remote queue, which specifies QL.SERV as the remote queue nameand QM2A as the transmission queue to be used. The message is therefore sent onthe channel serving transmission queue QM2A, not on the "normal" channel thatserves transmission queue QM2.

In the message, Program X specifies the reply-to-queue as QR.REPLY/A, which isresolved by using a reply-to queue alias to reply-to queue QL.REPLY on reply-toqueue manager QM1A.

Program Y gets request messages from QL.SERV, potentially from several clientprograms. Each request includes in its message descriptor the name of the reply-toqueue and reply-to queue manager. Program Y specifies these names in the objectdescriptor when opening the queue on which to put the reply message.

There is no local definition of a remote queue on queue manager QM2 that explicitlyidentifies a transmission queue. As a result, a reply message is put on thetransmission queue whose name is the same as that of the reply-to queue manager,which is QM1A in our example. Thus the reply message is sent on the channelserving transmission queue QM1A, not on the normal channel that serves




transmission queue QM1.

On queue manager QM1, there is also a queue manager alias definition thatspecifies QM1A as an alias of QM1. When a reply message arrives at QM1addressed to QM1A, the queue manager resolves the queue manager alias and themessage is put on queue QL.REPLY for Program X to get.

Configuring TCP/IP for WebSphere MQ

Configuring TCP/IP for WebSphere MQ varies according to the platform on whichWebSphere MQ is installed. On Unix systems, the inet daemon is used as a listenerfor messages, and must be configured to listen on the WebSphere MQ default port,1414. On Windows, the control command runmqlsr is used. See the WebSphereMQ Intercommunication manual for details.

Starting a message channel

To start a message channel, the MQSC command START CHANNEL is used,providing the name of the channel to be started. There is also a PING CHANNELcommand to test a message channel configuration.

In addition to the MQSC command, there is a control command runmqchl to start achannel. It takes a -c parameter to name the channel to be started.

Channel initiator

The MQSC command START CHANNEL and the control command runmqchl do notcontain retry logic for starting a channel. If retry logic is required, as in the case ofdifficulty starting a channel, or especially for restarting a channel after an error hasoccurred, then you should use a channel initiator. The MQSC command for startinga channel initiator is START CHINIT. The control command is runmqchi.

Channel states

You can determine the state of channel by using the MQSC command DISPLAYCHSTATUS. A channel can be in any one of the following states:INITIALISING

A channel initiator is attempting to start the channel.

STARTINGA channel waits in this state if there is no active slot available. If there is anactive slot immediately available, it remains in this state a very short time. The




number of active slots is defined by the MAXCHL attribute of a queue manager.

BINDINGEstablishing a communications connection and performing the initial dataexchange.

REQUESTINGA requester is waiting for callback from a sender.

RUNNINGTransferring messages, or waiting for messages to arrive on the transmissionqueue.

PAUSEDWaiting for the message-retry interval to complete before attempting to put amessage on its destination queue.

STOPPINGAn error has occurred, the STOP CHANNEL command has been issued, or thedisconnect interval has expired.

RETYRINGWaiting until it is time for the channel initiator to make the next attempt to startthe channel.

STOPPEDThe channel is disabled and needs manual intervention to start it again.

INACTIVEAn inactive channel is one that has never been started or has disconnectednormally.

Section 3. WebSphere MQ clients

In this section you'll examine WebSphere MQ clients in more detail.

Review

A WebSphere MQ client can be installed on a system on which no queue manageris running. The client enables an application running on the same system as the




WebSphere MQ client to connect to a queue manager that is running on anothersystem, and to issue MQI calls to that queue manager. Such an application is calleda WebSphere MQ client application, and the queue manager is called a serverqueue manager. Figure 3 shows this configuration.

Figure 3. Link between a client and server

A WebSphere MQ client application and a server queue manager communicate witheach other using an MQI channel. An MQI channel starts when the client applicationissues an MQCONN or MQCONNX call, and ends when the client application issuesan MQDISC call.

A fast, reliable, synchronous communications connection is required for WebSphereMQ client processing to be effective.

When an application is running as a WebSphere MQ client, an MQI call acts like aremote procedure call to the server queue manager on another system. Most of thecode that is executed in servicing an MQI call resides on the server system. This canmean that some delay may be involved in servicing an MQI call if there is acommunication failure. Any failure is reported to the application with a reason code.

The input parameters of an MQI call are sent by the client connection over thenetwork to the server connection that is running on the server system. The serverconnection acts as a surrogate for the client application, and issues the MQI call tothe server queue manager on behalf of the application. When the call has beenexecuted, the server connection sends the output parameters of the call over thenetwork to the client connection, which passes them on to the application.

Although the full range of MQI calls and options are available to an applicationrunning as a WebSphere MQ client, there may be restrictions relating to systemresources, such as memory constraints, in certain environments.




Syncpoint control

A WebSphere MQ client application can participate in a local unit of work involvingthe resources of the queue manager it is connected to. To do this, it uses theMQCMIT and MQBACK calls in the normal way.

A standard WebSphere MQ client application cannot, however, participate in aglobal unit of work. Such an application may issue calls to another resourcemanager or syncpoint coordinator, on the same system as the application or onanother system, and may participate in a unit of work associated with that resourcemanager or syncpoint coordinator. At the same time, it may also be participating in alocal unit of work involving the resources of the queue manager to which it isconnected. In this case, the two units of work are completely independent of eachother.

WebSphere MQ does provide an extended transaction client that enablesapplications that connect to a remote queue manager to include WebSphere MQactions within global units of work. In these circumstances, WebSphere MQ cannotact as the transaction manager for the global unit of work, because only a queuemanager can coordinate global units of work within WebSphere MQ. However,WebSphere MQ can act as a resource manager within that global unit of work.

While standard WebSphere MQ clients are provided free of charge, the extendedtransaction client is provided under different terms of licensing and pricing fromstandard WebSphere MQ clients.

Installation

Some WebSphere MQ clients are supplied on the distribution media for aWebSphere MQ server installation. Others are provided as SupportPacs. See theQuick Beginnings guide and the WebSphere MQ Clients manual for details for yourplatform (see Resources).

WebSphere MQ server licenses are not required for machines that have only astandard WebSphere MQ client installation.

Defining an MQI channel

As with a message channel, an MQI channel requires a definition at both ends of thechannel, and each end of an MQI channel has a type. The CLNTCONN type is usedfor the end of the MQI channel on the client system, and the SVRCONN type is usedfor the end of the MQI channel on the server system.




Remember, however, that an MQI channel is bidirectional in terms of flow ofinformation (the input parameters of an MQI call flow in one direction, and the outputparameters in the reverse direction). You do not need to define two channels, onefor each direction.

There is no direct operational involvement required for an MQI channel. It is startedsimply by a client application issuing an MQCONN or MQCONNX call, and it isstopped by the client application issuing an MQDISC call.

Configuring an MQI channel

There are two ways of configuring an MQI channel. In the first way, you define aserver connection on the server. Then, on the client system, you set the environmentvariable MQSERVER. The value given to this variable isChannelName/TransportType/ConnectionName. For example:

SET MQSERVER=QMC1.SVR/TCP/9.20.4.56

is used on a Windows system to connect using the SVRCONN channel namedQMC1.SVR, using TCP/IP, to a server at the given IP address.

There can be multiple instances of an MQI channel defined in this way. Severalclients can have the same value for the MQSERVER environment variable, andwould thus be using the same SVRCONN channel defined on a server to issue MQIcalls.

The second way is to define both the server connection and the client connection onthe server system. The client connection is stored in the client channel definitiontable on the server system. The file name of this table is AMQCLCHL.TAB. Thistable must be accessible to the client system. It can reside on a file server, or it canbe copied to the client system.

On the client system, the environment variables MQCHLLIB and MQCHLTAB arethen set in order to specify the location and name of the client connection definitiontable. For example:

SET MQCHLLIB="C:\Program Files\IBM\WebSphere MQ"SET MQCHLTAB=AMQCLCHL.TAB

is used on a Windows system to indicate the location and name of the client channeldefinition table.

There can be multiple instances of an MQI channel. Several clients can use thesame SVRCONN channel defined on a server to issue MQI calls.




Auto-definition of channels

There is a way for a channel to be defined automatically. Only RCVR andSVRCONN channels can be defined in this way.

The function is invoked if there is an incoming request to start a message channel orMQI channel, but no channel definition exists for the specific channel. The attributeChannelAutoDef of the queue manager object must also be set toMQCHAD_ENABLED. The corresponding parameter of the ALTER QMGRcommand is CHAD(ENABLED).

The definition is created using the relevant system object as a model:SYSTEM.AUTO.RECEIVER for RCVR channels, and SYSTEM.AUTO.SVRCONNfor SVRCONN channels. The name of the channel is that provided by the incomingrequest.

Once a channel definition has been created in this way and stored, the definitionmay be used subsequently as though it had always existed.

Section 4. WebSphere MQ clusters

This section explores WebSphere MQ clusters and how they are defined andadministered.

What is a cluster?

A cluster is a collection of queue managers that may be on different platforms, butthat typically serve a common application. Every queue manager can make thequeues that they host available to every other queue manager in the cluster. Clusterspecific objects remove the need for channel definitions and transmission queues foreach destination queue manager.

The queue managers in a cluster will often take on the role of a client or a server.The servers will host the queues that are available to the members of the cluster,also running applications that process these messages and generate responses.The clients put messages to the servers' queues and may receive back responsemessages.

Queue managers in a cluster will normally communicate directly with each other,although typically, many of the client systems will never have a need to




communicate with other client systems.

Cluster support objects

There are several WebSphere MQ objects that are specific to clusters.

Cluster repositoryA collection of information about the queue managers that are members of acluster, including the queue manager names, their channels, the queues theyhost, and other information.The information in a repository is exchanged with other repositories through aqueue called SYSTEM.CLUSTER.COMMAND.QUEUE and stored on a queuewith the fixed name of SYSTEM.CLUSTER.REPOSITORY.QUEUE.Repositories may be full or partial (more on this later), and each cluster queuemanager must have at least one connection to another queue manager thatcontains a full repository.

Cluster-sender channel (TYPE(CLUSSDR)A channel definition on which a cluster queue manager can send messages toanother queue manager in the cluster that holds a full repository. This channelis used to notify the repository of any changes of the queue manager's status,such as the addition or removal of a queue.

Cluster-receiver channel (TYPE(CLUSRCVR))A channel definition on which a cluster queue manager can receive messagesfrom within the cluster. Through the definition of this object, a queue manageris advertised to the other queue managers in the cluster, thus enabling them toauto-define their appropriate CLUSSDR channels for this queue manager. Youneed at least one cluster-receiver channel for each cluster queue manager.

Cluster-transmission queueUsed to put all the messages from the queue manager to any other queuemanager in the cluster. This queue is namedSYSTEM.CLUSTER.TRANSMIT.QUEUE and must exist in each cluster queuemanager.

Cluster queueA queue that is hosted by a cluster queue manager and made available toother queue managers in the cluster. The local queue is either preexisting orcreated on the local queue manager. To play a role in the cluster, the localqueue definition specifies the cluster name. The other queue managers in thecluster can see this queue and can put messages to it without the use of aremote queue definition. The cluster queue can be advertised in more than onecluster.




More about repositories

As noted, each cluster queue manager has to have a local queue calledSYSTEM.CLUSTER.REPOSITORY.QUEUE where all cluster related information isstored. At least one (but preferably two or more, for availability reasons) clusterqueue manager has to hold full repositories. This means that it has a complete set ofinformation about every queue manager in the cluster.

Repository queue managers, sometimes simply called repositories, must be fullyinterconnected with each other and positioned in the network to give a high level ofavailability.

Normal queue managers build up and maintain a partial repository that containsinformation only about those queue managers and queues that are of interest to it.This information may be updated and extended during operation through inquiries ofa full repository.

Setting up a cluster

Assume you have previously created a queue manager named QM1 that did notparticipate in a cluster. Let's take a look at the commands and definitions required toset up that queue manager in a cluster named EDUC.

To make QM1 a repository in the cluster EDUC, use the command:

ALTER QMGR REPOS(EDUC)

Each queue manager in a cluster must have a cluster-receiver channel, which isdefined as follows:

DEFINE CHANNEL(TO.QM1) +CHLTYPE(CLUSRCVR) +CONNAME(...) +CLUSTER(EDUC)

A connection to the existing full repository in this cluster (assume it's called QM4) isdefined as a cluster-sender channel, as shown below.

DEFINE CHANNEL(TO.QM4) +CHLTYPE(CLUSSDR) +CONNAME(...) +CLUSTER(EDUC)




To define a local queue that participates in the cluster (can be accessed from otherqueue managers in the cluster without a local definition of a remote queue), thecommand is:

DEFINE QLOCAL(QUEUE1) +CLUSTER(EDUC)

A cluster-receiver channel can be defined without specifying the queue manager'snetwork address. When no CONNAME is defined, and TCP/IP is used, WebSphereMQ generates CONNAME, assuming the default port and using the current IPaddress of the system. This facility is useful when the systems in the cluster useDynamic Host Configuration Protocol (DHCP).

A cluster-sender channel can be defined without specifying the name of therepository queue manager. When the name conventions used for channels in thecluster include the name of the queue manager, a CLUSSDR definition can use+QNAME+ in place of the queue manager name, and WebSphere MQ will substitutethe correct queue manager name in place of +QNAME+.

Workload balancing

Cluster support allows more than one queue manager to host an occurrence of thesame queue. Thus, two or more queue managers can be clones of each other,capable of running the same applications and having local definitions of the samequeues. This could be configured to increase the capacity available to processmessages or to introduce an ability to failover work from one server to another,improving the availability of the service.

When used to spread the workload between queue managers, the applications mustbe capable of parallel processing of messages.

A built-in workload management algorithm determines the remote queue manager ifthere are multiple choices, based on availability and channel priorities. A localoccurrence always takes precedence. You may supply your own cluster workloadexit to replace the built-in algorithm.

The cluster workload exit (built-in or user supplied) is called either when a clusterqueue is opened by an MQOPEN or MQPUT1 call, or when a message is put to aqueue using MQPUT.

The queue attribute DEFBIND determines whether or not rerouting will be performedwhile a queue is opened. A value of OPEN indicates that the destination queue isselected at MQOPEN time, and will not be changed until MQCLOSE. A value ofNOTFIXED indicates that the cluster workload exit will be called on MQPUT if the




target queue manager is unavailable.

You should ensure that all queues participating in workload balancing have thesame priority, default persistence, and DEFBIND values.

Cluster-related queue manager attributes

The following queue manager attributes are specific to queue managers participatingin a cluster.

REPOS(ClusterName)Indicates that this queue manager participates in the named cluster as a fullrepository.

REPOSNL(NamelistName)Indicates that this queue manager participates in all of the clusters included inthe NameList as a full repository.

CLWDATA(Data to be passed to the workload exit)A 32-character data string that will be passed to the workload exit.

CLWEXIT(User provided cluster workload exit name)The name of a user provided workload exit to replace the built-in exit.

CLWLLEN(integer)The maximum number of bytes of message data that can be passed to theworkload exit.

CLWLUSEQ(Indicator for use of cluster queues)Specifies the behavior of an MQPUT operation when the target queue has alocal instance and at least one remote cluster instance. LOCAL indicates thelocal queue is the only target for MQPUTs. ANY indicates the queue managertreats the local queue as another instance of the cluster queue for the purposesof workload distribution. A queue has an attribute with the same name, whichcan be used to override the queue manager's behavior.

Cluster commands

The following MQSC commands are specific to a cluster environment.

Command Definition

SUSPEND QMGR Removes a queue manager from a clustertemporarily, which means the workloadmanagement exit will not route any messages tothis queue manager. All information about a




suspended queue manager and its objects ispreserved in the repositories, but the queuemanager is marked as suspended. This functionmay be used if a queue manager has to be takendown for maintenance.

RESUME QMGR Reinstates a suspended queue manager.

REFRESH CLUSTER Discards all locally held information about acluster, thus enforcing a cold start of this queuemanager in the cluster. Should not be used forregular operation.

RESET CLUSTER Can only be issued by a repository queuemanager, and forces a named queue manageroff the cluster in the way that all other queuemanagers in the cluster are informed that thisqueue manager is no longer part of the cluster.

DISPLAY CLUSQMGR Returns cluster information about queuemanagers in a cluster, which is stored inSYSTEM.CLUSTER.REPOSITORY.QUEUE.

Section 5. Scalability and performance

WebSphere MQ is inherently designed to provide high-performance messagingbetween applications using the facilities provided by the underlying operating systemand hardware. In this section, you'll look at some typical WebSphere MQarchitectures that use WebSphere MQ distributed queuing features to enhancescalability and performance.

Single queue manager architecture

The simplest configurations consist of one queue manager running on a server. Theapplications providing service using a queue or queues reside on the same systemas the queue manager, and the applications requesting service reside on thatsystem or on other systems.

Application-to-application

This architecture is simple and easy to set up. All applications, requesters, andproviders reside on the same system as the queue manager. Even though this isn'ttruly distributed queuing, the asynchronous nature of the messaging servicesprovided by WebSphere MQ gives some workload flexibility to the applicationsproviding service. The performance of this architecture is dependent on the




underlying platform.

Client-to-application

Adding WebSphere MQ clients to the architecture removes the requestingapplications to separate systems, and increases the scalability and performance ofthe architecture. Figure 4 depicts this architecture.

Figure 4. WebSphere MQ clients

Distributed queue managers

By adding queue managers on additional systems, additional performance andscalability can be achieved. With this architecture, requesting applications do nothave to reside on the same system as the queue manager that owns the queueused by the providing applications, nor do clients have to connect to the queuemanager that owns the queue used by providing applications. However, therequesting applications themselves do not have to be changed; they still putmessages on a queue requesting service, but now the service might be provided byan application residing on another system.

Hub and spoke

Adding additional queue managers on additional systems might mean that




communication channels must be configured between all queue managers in theinfrastructure. The large number of channels can become burdensome from amaintenance point of view, including the need to define additional channels whenadditional applications are deployed.

This problem can be overcome by deploying a hub and spoke architecture. In thisconfiguration, hub systems host the applications that provide the services. The hubsystem can also host other resources required by the applications, such as adatabase. Queue managers that act as hosts for requesting applications, eitherresiding on the same system as the queue manager or as WebSphere MQ clients,are called the spokes of a hub and spoke architecture.

Hub and spoke architecture not only decreases the number of channels that need tobe defined, but also provides the flexibility to configure the applications andinfrastructure for increased scalability and performance. Figure 5 shows a hub andspoke architecture.

Figure 5. Hub and spoke architecture




Queue manager clusters

The most flexible approach is to join queue managers together in a queue managercluster. This allows multiple instances of the same service to be hosted throughmultiple queue managers. The requests of applications requiring service areworkload balanced across all available queue managers that host that service.Figure 6 shows a queue manager cluster.

Figure 6. Queue manager cluster




Section 6. Data conversion

This section discusses converting data in messages passed between systems thatuse different representations for character or numeric data.

Data representation

When messages are being routed through a heterogeneous network of queuemanagers, there is a requirement to handle different data representations. Some




characters might require translation from one character set to another. Somenumeric fields may require transformation, such as byte reversal for integers.

A message descriptor accompanies every message, and is delivered to thereceiving application along with the application data. The message descriptor isalways converted to the representation of the destination system. When a messagechannel is started between two queue managers, the two MCAs determine whatconversion is required and decide which of them will do it.

The conversion of the application data in a message, on the other hand, requiresmore attention.

Application data conversion fields in the message descriptor

There are three fields in the message descriptor that are concerned with applicationdata conversion:

Field Function

Encoding Specifies the representation of the numericdata in the message.

CodedCharSetId Specifies the representation of the characterdata in the message.

Format Specifies the nature of the data in themessage.

Requesting application data conversion

An application can request application data conversion on the MQGET call.Conversion only occurs if the representation of the stored message and therepresentation requested on the MQGET call are different. This approach can becalled "receiver makes good," meaning that the application data in a message needonly be converted once, even if a message has to pass through several queuemanagers.

You can also request the sending end of a message channel to perform conversion.This always converts a message to the representation of the queue manager at theremote end of the channel. If the sending end of the channel fails to convert amessage, the message is written to the dead letter queue at the sending end.

A message consisting entirely of characters can be converted by a built-inconversion routine. It can also be converted by a built-in conversion routine if themessage consists of a structure defined within WebSphere MQ. If neither of theseconditions exist, the conversion must be performed by a data conversion exit.




Data conversion exit

A data conversion exit is a user written program that performs data conversion forapplication data that WebSphere MQ cannot convert with its built-in routines. Towrite a data conversion exit:

1. Create a name for the message format of your application data.

2. Create a structure to represent the message.

3. Use a supplied utility to create code fragments for the data conversionexit.

4. Copy a supplied skeleton source file and rename it to the name of yourmessage format.

5. Copy the code fragments supplied by the utility into your source file, andwrite any specialized code needed for the conversion.

6. Compile the program and place it into the appropriate directory in yourWebSphere MQ installation.

The details for writing a data conversion exit for each platform are documented inthe WebSphere MQ Application Programming Guide (see Resources).

Detecting whether application data conversion is required is independent of any dataconversion exit. If conversion is required and the message format is one that can behandled by one of the built-in conversion routines, no data conversion exit isneeded.

If a data conversion exit is needed, it will be invoked. The exit returns whether or notthe conversion was successful. If so, the converted data returned by the exit isdelivered to the application. If not successful, the unconverted data is returned to theapplication, along with the completion code and reason.

Recommendations for applications

Application developers should adhere to the following recommendations to ensureproper data conversion.

• Put every message with the following values in the Encoding andCodedCharSetId fields of the message descriptor:

• MQENC_NATIVE for native encoding




• MQCCSI_Q_MGR for the same CCSID as the queue manager

• Put every message with a format name in the Format field of themessage descriptor. For example:

• MQFMT_STRING for a message consisting entirely of characters.

• Use the MQGMO_CONVERT option on the MQGET call. Check what isdelivered by the MQGET call; the message might not have beenconverted.

Successful conversion depends on the sender of a message correctly setting theEncoding, CodedCharSetId, and Format fields in the message descriptor.Application programmers should get in the habit of doing this, even if the destinationof the message does not require conversion, because it might in the future.

Section 7. Remote administration

Next we'll look at ways to administer queue managers remotely. The discussion hereincludes instrumentation events and dead letter queues, which, while not specificallyconcerning remote administration, are included for completeness of administrationissues.

Command server

All queue managers have a command queue that is a system queue,SYSTEM.ADMIN.COMMAND.QUEUE, designed to support remote administrationfrom a "single point of control." The message format for these commands is theProgrammable Command Format (PCF). Messages can be sent to a remotecommand queue.

A queue manager provides a command server to process the messages on thecommand queue. The control command strmqcsv starts the command server,which must be running for a queue manager to be enabled for remoteadministration.

Administration utilities that support PCF commands include WebSphere MQSupportPacs, third party vendor products, and the runmqsc command in indirectmode.

The WebSphere MQ Administration Interface (MQAI) is provided as a programming




interface for sending and receiving PCF commands.

Indirect mode

Up to now, you have used runmqsc in direct mode. In direct mode, runmqscconnects to the target queue manager, issues MQSC commands, and produces areport of the results.

There is also an indirect mode of using runmqsc, in which MQSC commands aresent to a command queue instead and the command server sends replies that areused to format a report.

In indirect mode, an MQSC command is encapsulated with an Escape PCFcommand. An Escape PCF command contains MQSC commands in the messagetext.

In indirect mode, runmqsc reads MQSC commands, sends them within EscapePCF commands to the command queue of a target queue manager (which can beremote), waits for the replies, and writes a report based on the replies received.

WebSphere MQ Explorer

As indicated in Part 1, WebSphere MQ Explorer provides a graphical user interfacefor administering WebSphere MQ. WebSphere MQ Explorer is available for bothWindows and Linux platforms. However, though it only runs on those platforms, itcan be used to administer WebSphere MQ on any platform. This is one of the bestoptions for "single point of control" remote administration.

Instrumentation events

An instrumentation event is a logical combination of conditions that is detected bythe queue manager. When an instrumentation event occurs, the queue managerputs an event message on an event queue. The format of an event message isbased on that of a PCF command. Each category of instrumentation event has itsown event queue. The table below shows the four categories of instrumentationevents, the corresponding event queue, and examples of each.

Instrumentation event categories and examplesCategory Event queue Example

Queue manager SYSTEM.ADMIN.QMGR.EVENTWhen an attempt is made toput a message on a queuefor which put requests aredisabled.When an attempt is made to




open a queue without therequired authority.

Performance SYSTEM.ADMIN.PERFM.EVENTWhen the depth of a queuehas reached a predefinedthreshold.When a queue is full.

Channel SYSTEM.ADMIN.CHANNEL.EVENTWhen a channel starts.When a channel stops.When application dataconversion fails at thesending end of a messagechannel.

Configuration SYSTEM.ADMIN.CONFIG.EVENTWhen an object is created.When an object is deleted.When a namelist is created.

An application to read event messages is not provided by WebSphere MQ, but thereis a SupportPac that provides this function.

Dead letter queue

The dead letter queue is used by the queue manager to store messages that it hashad a problem or problems delivering.

When a problem relating to a message is detected asynchronously, an exceptionreport is generated if one has been requested, and the report is sent to the specifiedreply-to queue. The Feedback field in the message descriptor of the reportmessage indicates the reason for the report. The original message is put on thedead letter queue.

If a message cannot be delivered at the receiving end of a message channel, it isput on the dead letter queue, if one is defined.

If CONVERT(YES) is specified in the channel definition at the sending end of amessage channel and a message cannot be converted, the message is put on thedead letter queue at the sending end.

A channel is stopped if a dead letter queue is not available when it is required. Forthis reason, it is recommended that a dead letter queue be defined for every queuemanager.

Dead letter queue handler

A dead letter queue handler provides an automated way of handling messages on




the dead letter queue. The dead letter queue handler is invoked using therunmqdlq control command. It can have a queue name and a queue managername as parameters; otherwise, it assumes the dead letter queue of the defaultqueue manager.

The dead letter queue handler is driven by a rules table that is read from thestandard input device. There must be at least one rule in the table. A rule can matchthe destination queue name, the message type, the contents of the Feedback field,and so forth. The action of a rule may indicate that the dead letter queue handlershould try again to put a message on its destination queue, or forward it to anotherqueue, or discard it, or simply leave it on the dead letter queue.

Even if you are not using a dead letter queue handler, a dead letter queue shouldnot be allowed to fill up (reach its maximum depth).

Section 8. Security

Access control

The primary security component provided by WebSphere MQ is access control. Thisallows WebSphere MQ to control which users are granted what types of access towhich WebSphere MQ resources. The resources that may be controlled in this wayare: the queue manager, queues, namelists, and processes.

WebSphere MQ supplies an Object Authority Manager (OAM) as an authorizationservice. The OAM provides a full set of access control facilities for WebSphere MQ,including both the access control checking and commands to set, change, andinquire on WebSphere MQ access control information. The OAM can be replaced bya user or vendor supplied component that conforms to the proper interface.

WebSphere MQ captures the user identifier associated with an application atMQCONN. This user identifier is used for access control checks. It is possible for asuitably authorized user to use an alternate user identifier instead of the logged onuserid. When WebSphere MQ checks to see if a user is permitted to access aparticular resource, it is the name specified in the MQI call that is used for the check.

In the case of an alias or remote queue definition, it is still the name of the queuespecified in the MQI call, and not the resolved-to name, that is used for the accesscheck. Thus, a user needs access to the named resource and not the resolved-toresource. It is possible to grant no access to a local queue and only grant access toan alias queue that resolves to it. Also, this points out that the ability to define




queues should be limited to privileged users. Otherwise, normal access control couldbe bypassed simply by creating an alias queue.

Security management

There are three control commands that provide control of the security environmentfor WebSphere MQ: setmqaut, dspmqaut, and dmpmqaut. These programsrequire a connection to the authorization service, and so may only be used when thetarget queue manager is active and the OAM is enabled. All of the responses tothese commands are displayed on the standard output device.

Commands Usage

setmqaut Used to grant or revoke OAM authorities forWebSphere MQ objects of a particular queuemanager with a particular type and a particularname. The name parameter can contain awildcard asterisk (*) to allow a group of names tobe specified.After making changes using setmqaut for arunning queue manager, it is important to issue aREFRESH SECURITY MQSC command againstthat queue manager to refresh the authorityinformation cache.

dspmqaut Used to display the authorities that are resolvedagainst a particular user identifier or groupidentifier for a particular object.

dmpmqaut Has a purpose similar to the dspmqautcommand, but provides significantly more details.dmpmqaut is especially useful if attempting toidentify why a particular user identifier is beinggranted the authorities shown by the dspmqautcommand, for example, because of groupmemberships.

The WebSphere MQ System Administration Guide has more information on thesecommands (see Resources).

Access for WebSphere MQ control commands

WebSphere MQ control commands have restricted access, depending on theplatform. Typically, a defined group for WebSphere MQ administrators or systemadministrators are the only ones allowed access to these commands.




Authority checking in the MQI

Authority checking is performed when an application issues an MQCONN,MQCONNX, MQOPEN, or MQPUT1 call. Typically, checking is not done when anMQCLOSE is issued, but there is an exception. When an MQCLOSE call is issuedto delete a permanent dynamic queue using an object handle other than the onereturned by the MQOPEN call that created the queue, a check is made to ensure theapplication has permission.

If an application is not authorized to access a WebSphere MQ object for a requestedoperation, the reason code MQRC_NOT_AUTHORIZED is returned by the MQI call.

The queue manager generates audit records when there is an attempt to access aresource for which permission has not been granted. These records are written asmessages to the SYSTEM.ADMIN.QMGR.EVENT queue.

Security and distributed queuing

When defining the receiving end of a message channel, there is an option that letsyou specify which user identifier is to be used for checking the authority of thereceiving MCA to open a destination queue in order to put a message on it. You canchoose one of the following:

• Default user identifier

• The receiving MCA's default user identifier is used. This user identifiercan be changed by a security exit, or by setting the MCAUSERparameter in the channel definition at the receiving end of themessage channel.

• Context user identifier

• The user identifier in the context of the message is used.

Transmission queues should normally be used only by the queue manager, and arenot typically accessed directly by applications. However, if there are special systemsprograms that do put messages directly on a transmission queue, they should begranted the permissions required.

Message context

Message context allows for the application that retrieves a message to find out aboutthe originator of the message. The retrieving application could use this information tocheck that the sending application has the correct level of authority, or to keep an




audit trail of all the messages it has worked with.

Context fields

There are two types of context, identity and origin, that are held in a set of fields inthe message descriptor. An application can request the queue manager to set thecontext fields of a message by using the put message optionMQPMO_DEFAULT_CONTEXT on an MQPUT or MQPUT1 call. This is the defaultaction if no context option is specified.

Identity contextIncludes the following fields:

• UserIdentifier - The user that originated the message.

• AccountingToken - The queue manager treats the information in thisfield as binary information, not character information. The value of thisfield is dependent on the platform.

• ApplIdentityData - Application data relating to identity.

Origin contextIncludes the following fields:

• PutApplType - Type of the application that put the message.

• PutApplName - Name of the application that put the message.

• PutDate - Date when the message was put.

• PutTime - Time when the message was put.

• ApplOriginData - Application data relating to the origin.

An application may elect to put a message with no context by specifying the putmessage option MQPMO_NO_CONTEXT. In this case, the queue manager clearsall the context fields. Specifically, it sets the field PutApplType toMQAT_NO_CONTEXT so that the receiving application can test for this value.

Passing context

When a queue manager generates a report, it sets the identity context to the sameas that of the original message. When an application generates a reply or a report, itis generally a good idea to follow the same convention.

To forward a message or send a reply with the same identity context, an applicationneeds to do the following:




• Open the input queue with the option save all context.

• Open the output queue with the option pass identity context or pass allcontext.

• Get a message from the input queue.

• Put the message, or the reply, on the output queue with the option passidentity context or pass all context.

If the original message has no context, the application may forward it with the optionno context.

Alternate user authority

Alternate user authority allows an application to open a queue, or any otherWebSphere MQ object, by providing the queue manager with a user identity otherthan the one it is currently running under. The queue manager uses this alternateuser identifier to check whether it is authorized to open the queue.

Typically, this option is used by a server application that is doing work on behalf ofother applications. The server application obtains the alternate user identifier fromthe context of the message it is currently processing.

Channel exit programs

Channel exit programs provide an opportunity for additional, customized securitymeasures on message channels and MQI channels. Channel exits, however, requireadditional setup and are not part of the "out of the box" security provided byWebSphere MQ. See the channel exit discussion in Part 1 for more details.

Be aware that no channel exit programs can be called on the client side of an MQIchannel if the MQSERVER environment variable is used to define the clientconnection. If the client connection definition table is used on the client, messageand message-retry exits are not applicable because the MQI channel is used to flowthe input and output parameters of MQI calls, not messages.

Security Sockets Layer (SSL)

Secure Sockets Layer (SSL) is an industry-standard protocol for securecommunications involving encryption, authentication, and integrity of data. SSL issupported in both client/server and queue manager/queue manager channels,including clusters. There are many flexible capabilities built-in to SSL, including theability to select from whom to accept communications based on their



http://www-128.ibm.com/developerworks/edu/wes-dw-wes-cert9961.html?S_TACT=105AGX19&S_CMP=wescert996


fully-authenticated identity. This will preclude, in most installations, the need to setup channel exits for security purposes.

SSL is widely accepted in the Internet community, and has been subjected tosignificant testing. Its encryption techniques prevent eavesdropping oncommunications, the digital signatures it provides prevent tampering with data beingcommunicated, and digital certificates provide strong authentication.

The SSL handshake

Setting up communication using SSL is known as the "SSL handshake," as follows.

1. The SSL client sends a "client hello" message that lists cryptographicinformation such as SSL version and, in the client's order of preference,the cipher suites supported by the client. The message also contains arandom byte string that is used in subsequent computations.The SSL protocol allows for the "client hello" to include the datacompression methods supported by the client, but SSL implementationsdo not usually include this provision.

2. The SSL server responds with a "server hello" message that contains thecipher suite chosen by the server from the list provided by the SSL client,the session ID, and another random byte string.The SSL server also sends its digital certificate. If the server requires adigital certificate for the client authentication, the server sends a clientcertificate request that includes a list of the types of certificates supportedand the distinguished names of acceptable certification authorities (CAs).

3. The SSL client verifies the digital signature on the SSL server's digitalcertificate, and checks that the cipher suite chosen by the server isacceptable.

4. The SSL client sends the random byte string that enables both the clientand server to compute the secret key to be used for encryptingsubsequent message data. The random byte string itself is encrypted withthe server's public key.

5. If the SSL server sent a client certificate request, the SSL client sends arandom byte string encrypted with the client's private key, together withthe client's digital certificate, or a no digital certificate alert.This alert is only a warning, but with some implementations thehandshake fails if client authentication is mandatory.




6. The SSL server verifies the signature on the client certificate.

7. The SSL client sends the SSL server a "finished" message, encryptedwith the secret key, indicating that the client part of the handshake iscomplete.

8. The SSL server sends the SSL client a "finished" message, encryptedwith the secret key, indicating the server part of the handshake iscomplete.

9. For the duration of the SSL session, the SSL server and the SSL clientcan now exchange messages that are symmetrically encrypted with theshared secret key.

Queue manager attributes for SSL

The following attributes on the queue manager definition provide informationconcerning the use of SSL by the queue manager.

Attributes Definition

SSLKEYR The name of the SSL key repository.

SSLCRLNL The name for the namelist of authenticationinformation objects.

SSLCRYP The name of the parameter string requiredto configure the cryptographic hardwarepresent on the system.

SSLTASKS The number of server subtasks to use forprocessing SSL calls.

Queue manager authentication object

Queue manager authentication objects contain the definitions required to performcertificate revocation lists (CRL) checking using LDAP servers. You can alter, define,delete, or display these objects with the commands ALTER AUTHINFO, DEFINEAUTHINFO, DELETE AUTHINFO, and DISPLAY AUTHINFO.

Channel attributes for SSL

The following attributes on the channel definition provide information concerning theuse of SSL on the channel.




Attributes Definition

SSLCIPH Specifies the encryption strength andfunction (CipherSpec). This attribute mustmatch at both ends of the channel.

SSLPEER Specifies the distinguished names (uniqueidentifiers) of allowed partners.

SSLCAUTH Defines whether WebSphere MQ requiresand validates a certificate from the SSLclient.

Section 9. WebSphere MQ SupportPacs

Overview

The WebSphere MQ SupportPacs library consists of material that complements thefamily of WebSphere MQ products marketed by IBM. Each SupportPac supplies aparticular function or service that can be used with one or more of the WebSphereMQ products. Many SupportPacs are freely available for download, while othershave to be purchased as fee based services from IBM.

The SupportPacs are grouped into the following categories:Category 1 - Fee-based services

SupportPacs in this category provide material to be used by IBM SystemsSpecialists as the basis for fee earning services contracts with customers. Theyare advertised in the SupportPacs library but their content is only available toIBM personnel.Customers interested in obtaining services based on the material shouldcontact their IBM representative.

Category 2 - FreewareSupportPacs in this category are provided free to all users of WebSphere MQproducts. They typically provide material covering areas such as:

• Background education on WebSphere MQ products.

• Sample utilities to assist in the development of WebSphere MQ basedapplications.

• Sample utilities to assist in the operation and management of WebSphereMQ based systems.




This material is provided as-is, and the license agreement under which theseSupportPacs are made available does not provide for warranty or defectcorrection.

Category 3 - Product ExtensionsProduct Extensions are provided free to all users of WebSphere MQ products.They are supplied under the standard terms and conditions provided by theIBM International Program License Agreement (IPLA), and thus provide forwarranty or defect correction. Their quality and support are the same as theWebSphere MQ products they are used with.

Category 4 - Third party contributionsThese SupportPacs are provided by third parties, and are provided andlicensed in the same way as Category 2 SupportPacs.

Let's take a look at a couple of examples of SupportPacs available for WebSphereMQ.

MO01: Event and dead letter queue monitor

This SupportPac contains three utilities: an event queue monitor, a dead letterqueue monitor, and a program to remove expired messages.

The event queue monitor waits on an event queue and alerts the user when anevent message has arrived on the queue. It writes the contents of the message tothe standard output device in a readable form. The source code is a useful exampleof how to parse event messages whose format is based on that of PCF commands.

The dead letter queue monitor waits on the dead letter queue and alerts the userwhen a message has arrived on the queue. It writes the dead letter header to thestandard output device in a readable form. The source code is a useful example ofhow to write a dead letter queue handler.

The expired message remover browses every message that exists within a queuemanager so that any message whose expiration time has elapsed is removed. Thisis useful for keeping queue storage under control. The source code is a goodexample of how to obtain information from the command server.

MS03: WebSphere MQ - Save Queue Manager objectdefinitions using PCFs




This SupportPac interrogates the attributes of all the objects defined to a queuemanager (either local or remote) and saves them to a file. The format of this file issuitable for use with runmqsc. It is therefore possible to use this SupportPac to savethe definitions of objects known to a queue manager and subsequently recreate thatqueue manager.

Section 10. Considerations for WebSphere MQ for z/OS

Most of the information provided in this tutorial applies to most platforms on whichWebSphere MQ is available. However, WebSphere MQ for z/OS does have somedifferences that should be noted. This section addresses some of the importantdifferences, but definitely not all of them. Only by using WebSphere MQ for z/OSand WebSphere MQ on other platforms, and by studying the WebSphere MQ forz/OS documentation, can you expect to understand all the differences between theplatforms.

Documentation

There is no Quick Beginnings guide for WebSphere MQ for z/OS. Instead, use thez/OS: Concepts and Planning Guide and z/OS: System Setup Guide for planningand implementation information (see Resources).

WebSphere MQ for z/OS has its own System Administration Guide, and also has aProblem Determination Guide.

Queue indexes

WebSphere MQ for z/OS has the ability to create indexes on the GROUPID,MSGID, MSGTOKEN, and CORRELID fields of messages in a queue to increasethe speed of MQGET operations using those fields. This ability is not available onother platforms.

Publish/subscribe

WebSphere MQ for z/OS does not provide a publish/subscribe broker.

Distribution lists




WebSphere MQ for z/OS does not support distribution lists.

Logging and recovery

Considerations for logging and recovery are different on WebSphere MQ for z/OSthan on other platforms. The z/OS: Concepts and Planning Guide covers theseconsiderations in detail.

An important point, though, is that WebSphere MQ for z/OS can create a point ofrecovery in two different ways:

• Full backup

• The queue manager is stopped, and recovery is possible from thebacked up data and the logs from the point of the full backup on.

• Fuzzy backup

• The backup is performed while the queue manager is running. If theassociated logs are damaged or lost, a fuzzy backup cannot be usedfor recovery.

WebSphere MQ Explorer

While WebSphere MQ Explorer can remotely administer WebSphere MQ on allplatforms, including z/OS, it can only administer WebSphere MQ for z/OS V6.0queue managers. Earlier versions of WebSphere MQ for z/OS cannot beadministered with WebSphere MQ Explorer.

Queue sharing groups

WebSphere MQ for z/OS provides for the creation of queue sharing groups.Members of queue sharing groups are queue managers in the same sysplex createdwhen z/OS systems are joined together. Every queue manager in a queue sharinggroup can access all of the messages on all of the shared queues in the group.Shared queues can also participate as cluster queues.

Object authority

Authority checks on WebSphere MQ for z/OS objects are performed externally toWebSphere MQ by the Resource Access Control Facility (RACF). The checks areperformed under the same circumstances as they would be using OAM.




Section 11. Summary

This tutorial addressed various aspects of distributed queue management, includingconfiguration, application data conversion, and WebSphere MQ clients. It alsodiscussed handling exceptions and security issues. Completing the five tutorials inthis series can help you gain the knowledge you need to prepare for Test 996, IBMWebSphere MQ V6.0, Solution Design, but nothing can replace the experience andknowledge that is obtained from using the product and studying the documentation.

I hope you have found this tutorial helpful, and wish you luck as you prepare for yourcertification test.




Resources

Learn

• WebSphere MQ Solution Designer certification prep series: Take this series offive tutorials to help prepare for the IBM certification Test 996, WebSphere MQV6.0, Solution Design.

• Get certified as an IBM Certified Solution Designer - WebSphere MQ V6.0.Check out the objectives, sample assessment tests, and training resources fortest 996, IBM Certified Solution Designer - WebSphere MQ V6.0.

• Read the IBM Redbook™ WebSphere MQ V6 Fundamentals to gain a broadtechnical introduction to WebSphere MQ.

• Use the WebSphere MQ library for detailed documentation on WebSphere MQ.

• Stay current with developerWorks technical events and webcasts.

Get products and technologies

• Download a free trial version of WebSphere MQ V6.0.

• Download a free trial version of Rational Application Developer V6.0.

• Build your next development project with IBM trial software, available fordownload directly from developerWorks.

Discuss

• Participate in the discussion forum for this content.

• Participate in developerWorks blogs and get involved in the developerWorkscommunity.

About the author

Willy FarrellWilly Farrell is a Senior Software Engineer in the IBM Developer Skills Program. Aspart of the developerWorks team, he provides relevant technical information andinsight to developers on the latest e-business and industry trends and technologiesthrough Web content, articles, speaking engagements, and consulting to faculty atIBM Academic Initiative member universities. He has been programming computersfor a living since 1981, began using Java in 1996, and joined IBM in 1998. You canreach Willy at [email protected].



http://www.ibm.com/developerworks/offers/lp/wescert/wes-cert996.html?S_TACT=105AGX19&S_CMP=wescert996

http://www-03.ibm.com/certify/certs/mqsdmv6.shtml?S_TACT=105AGX19&S_CMP=wescert996

http://www.redbooks.ibm.com/abstracts/sg247128.html?Open

http://www-306.ibm.com/software/integration/wmq/library/library6x.html

http://www.ibm.com/developerworks/offers/techbriefings/?S_TACT=105AGX19&S_CMP=wescert996


http://www.ibm.com/developerworks/downloads/r/rad/?S_TACT=105AGX19&S_CMP=wescert996

http://www.ibm.com/developerworks/downloads/?S_TACT=105AGX19&S_CMP=wescert996

http://www.ibm.com/developerworks/forums/dw_forum.jsp?forum=280&cat=9

http://www.ibm.com/developerworks/blogs/

http://www-304.ibm.com/jct09002c/university/scholars/

mailto:[email protected]


Documents

WebSphere MQ Solution Designer certification exam 996 prep, Part 3