What is Webpshere MQ?

IBM WebSphere MQ is a family of network communication software products launched by IBM in March 1992. It was previously known as MQSeries, a trademark that IBM rebranded in 2002 to join the suite of WebSphere products. WebSphere MQ is IBM's Message Oriented Middleware offering. It allows independent and potentially non-concurrent applications on a distributed system to communicate with each other. MQ is available on a large number of platforms (both IBM and non-IBM), including z/OS (mainframe), OS/400 (IBM System i or AS/400), Transaction Processing Facility, UNIX (AIX, HP-UX, Solaris), HP NonStop, OpenVMS, Linux, and Microsoft Windows.

Message-oriented middleware
Main article: Message-oriented middleware

A member of the WebSphere family from IBM, WebSphere MQ (formerly MQSeries) is the most popular[1] system for messaging across multiple platforms, including Windows, Linux, IBM mainframe and midrange, and Unix. WebSphere MQ is often referred to as "MQ" or "MQSeries".

There are two parts to message queuing:

* Messages are collections of binary or character (for instance ASCII or EBCDIC) data that have some meaning to a participating program. As in other communications protocols, storage, routing, and delivery information is added to the message before transmission and stripped from the message prior to delivery to the receiving application.
* Message queues are objects that store messages in an application.

A queue Manager, although not strictly required for message-oriented middleware, is a Websphere MQ prerequisite and system service that provides a logical container for the message queue and is responsible for transferring data to other queue managers via message channels.

There are several advantages to this technology:

* Messages do not depend on pure packet-based transmissions, such as TCP/IP. This allows the sending and receiving ends to be decoupled and potentially operate asynchronously.
* Messages will be delivered once and once only, irrespective of errors and network problems.

[edit] APIs

There are many ways to access WebSphere MQ's facilities. Some of the APIs supported by IBM are:

* IBM Message Queue Interface for C, COBOL, PL/I, and Java
* JMS for Java
* Perl interface (developed and contributed by Morgan Stanley), available from CPAN.[2]
* Windows PowerShell[3]
* XMS for C/C++ and .NET[4]

There are many other APIs (unsupported by IBM).

[edit] Awards

In 2004, WebSphere MQ won the British Royal Academy of Engineering's MacRobert Award for technological and engineering innovation.[5]

[edit] Features

WebSphere MQ provides assured one-time delivery of messages across a wide variety of platforms. The product emphasizes reliability and robustness of message traffic, and ensures that a message should never be lost if MQ is appropriately configured.

It needs to be remembered that a message in the context of MQ has no implication other than a gathering of data. MQ is very generalized and can be used as a robust substitute for many forms of intercommunication. For example, it can be used to implement reliable delivery of large files as a substitute for FTP.

MQ provides application designers a mechanism to achieve non-time-dependent architecture. Messages can be sent from one application to another, regardless of whether the applications are running at the same time. If a message receiver application is not running when a sender sends it a message, the queue manager will hold the message until the receiver asks for it. Ordering of all messages is preserved, by default this is in FIFO order of receipt at the local queue within priority of the message.

It provides a means for transforming data between different architectures and protocols, such as Big Endian to Little Endian, or EBCDIC to ASCII. This is accomplished through the use of message data "exits". Exits are compiled applications which run on the queue manager host, and are executed by the WebSphere MQ software at the time data transformation is needed.

WebSphere MQ allows receipt of messages to "trigger" other applications to run, and thus provides the framework for a message driven architecture.

It implements the JMS standard API, and also has its own proprietary API, known as the Message Queuing Interface.

Unlike email, MQ itself is responsible for determining the destination of messages by the definition of queues, so processing of sent messages can be moved to a different application at a different destination. MQ provides a robust routing architecture, allowing messages to be routed via alternative paths around a network of MQ managers. MQ can be implemented as a cluster, where multiple MQ implementations share the processing of messages to allow higher performance and load balancing.
Posted by karthick at 8:29 PM 0 comments
Labels: IBM Websphere MQ
Websphere MQ Clustering
Clustering Up

Main purpose : workload balancing.

* SC34-6061 : Queue Manager Clusters. [MQ-Clustering.pdf]
* SC34-6061 : Queue Manager Clusters. Online url (v 5.3)
* SC34-6589 : Queue Manager Clusters. url (v 6.0) [T42:\mq\books\]

Distributed queing is when you group queue managers in a cluster : the queue managers can make the queues that they host available to every other queue manager in the cluster. Any queue manager can send a message to any other queue manager in the same cluster without explicit channel definitions, remote-queue definitions, or transmission queues for each destination. Every queue manager in a cluster has a single transmission queue from which it can transmit messages to any other queue manager in the cluster.

Each queue manager in a cluster needs to define only:

* one cluster-receiver channel on which to receive messages
* one cluster-sender channel with which it introduces itself and learns about the cluster
* which own queues it wants to make available to the cluster

As with distributed queuing, an application uses the MQPUT() call to put a message on a cluster queue at any queue manager. An application uses the MQGET() call to retrieve messages from a cluster queue on the local queue manager.
You can only GET from a local cluster queue, but you can PUT to any queue in a cluster. If you open a queue to use the MQGET command, the queue manager will only use the local queue.

Each queue manager has a definition for the receiving end of a channel called TO.qmgr on which it can receive messages. This is a cluster-receiver channel. A cluster-receiver channel is similar to a receiver channel used in distributed queuing, but in addition to carrying messages this channel can also carry information about the cluster.

Each queue manager also has a definition for the sending end of a channel, which connects to the cluster-receiver channel of one of the Full Repository (FR) queue managers. This is a cluster-sender channel. A cluster-sender channel is similar to a sender channel used in distributed queuing, but in addition to carrying messages this channel can also carry information about the cluster.

Once both the cluster-receiver end and the cluster-sender end of a channel have been defined, the channel starts automatically.

In any cluster you need to nominate two queue managers to hold full repositories.

The clusters use the publish/subscribe model for internal messaging (and will Subscribe to only 2 FR)

Queue Manager Repository is kept in SYSTEM.CLUSTER.REPOSITORY.QUEUE queue
Cluster information is carried to repositories (whether full or partial) on a local queue called SYSTEM.CLUSTER.COMMAND.QUEUE.

Few Q&A ;

* how many FR ? 2
* DISCINT=0 ? no
* 2 qmgrs just to be FR ? yes, on a separate server

Good intro : Getting started with queue manager clusters.

Interesting summary :

#1 Regardless of how many FRs you have, each FR should have a manual CLUSSNDR defined to every other FR.

#2 If every FR has a CLUSSNDR to every other FR, each FR will know about every cluster attribute on every QM in the cluster.

#3 A PR will only ever publish info to 2 FRs. A PR will only ever subscribe to 2 FRs. Period. It doesn't matter how many manual CLUSSNDRs you define on that PR. A PR will only ever send its info (publish) to 2 FRs and will only get updates (subscribe) from 2 FRs.

#4 You should only define one CLUSSNDR to one FR from a PR.

#5 If 2 FRs go down in your cluster, your cluster will be able to send messages just fine. But any changes to cluster definitions become a problem. Any PRs that used both of these down FRs will still function for messaging, but they will not be made aware of any changes in the cluster because both of it's FRs are N/A.

#6 If two of your FRs are down, and you still have other FRs, you could go to your PRs and delete the CLUSSNDR to the down FR, define a CLUSSNDR to an available FR and issue REFRESH CLUSTER(*) REPOS(YES). This would cause your PR to register with an available FR and thus pick up cluster changes.

#7 In a properly designed system the liklihood of 2 FRs being down is next to zero, so the need for more than 2 FRs is next to zero. And even if both FRs are down it doesn't mean your cluster will come to a screeching halt.

Just use 2 FRs.

Problem : stuck message(s) @ Xmit Q(s)!