<% if Request("name") = "" then %> Introduction

MQSeries, with its multiplatform capabilities provides the key link between all the elements of our system, enabling us to reuse business logic. Its versatility is unparalleled.

Connect any commercial systems in business today.
Ignore network disruptions - important data is always delivered.
Use less time, skills and resources to become an e-business.
Exploit rich support from MQSeries business partners.

Features

• MQSeries is EuroReady and Year 2000 ready.

• Heterogeneous any-to-any connectivity from desktop to mainframe (over 35 platforms supported)

• A comprehensive family of [APIs] designed to make coding for any messaging task straightforward.

• Allows business to integrate disparate islands of automation

• Time independent communication

• Assured one-time delivery

• IBM MQSeries has 65% market share (Wintergreen Research, 1999) and is used by over 7000 customers, including 70 of the Fortune 100 and two thirds of the world's leading banks.

• More than 350 of IBM's top 500 customers use MQSeries

• One major US organization uses MQSeries to transmit over 250 million messages per day.

• There are more than 2000 Certified MQSeries Specialists working for more than 650 different companies worldwide.

Operating Systems

MQSeries runs on AIX, OpenVMS VAX, HP-UX, OS/2, OS/390, OS/400, Solaris, Tandem NSK, VSE/ESA, Windows 2000, Windows 3.x, Windows 95 & Windows 98 and Windows NT.

<% elseif Request("name") = "Info" then %> More Info

The basics of MQSeries Messaging contents :
- Application programs and messaging
- Queue managers
- How applications identify themselves to queue managers
- Opening a queue
- Putting and getting messages
- Messaging using more than one queue manager

Application programs and messaging
The IBM MQSeries range of products provides application programming services that enable application programs to communicate with each other using messages and queues. This form of communication is referred to as commercial messaging. It provides assured, once-only delivery of messages. Using MQSeries means that you can separate application programs, so that the program sending a message can continue processing without having to wait for a reply from the receiver. If the receiver, or the communication channel to it, is temporarily unavailable, the message can be forwarded at a later time. MQSeries also provides mechanisms for providing acknowledgements of messages received.
The programs that comprise an MQSeries application can be running on different computers, on different operating systems, and at different locations. The applications are written using a common programming interface known as the Message Queue Interface (MQI), so that applications developed on one platform can be transferred to another.

Queue managers
In MQSeries, queues are managed by a component called a queue manager. The queue manager provides messaging services for the applications and processes the MQI calls they issue. The queue manager ensures that messages are put on the correct queue or that they are routed to another queue manager.
Before applications can send any messages, you must create a queue manager and some queues. MQSeries for Windows provides the utilities to help you do this and to create any other MQSeries objects that you need for your applications.

How applications identify themselves to queue managers
Any MQSeries application must make a successful connection to a queue manager before it can make any other MQI calls. When the application successfully makes the connection, the queue manager returns a connection handle. This is an identifier that the application must specify each time it issues an MQI call. An application can connect to only one queue manager at a time (known as its local queue manager), so only one connection handle is valid (for that particular application) at a time. When the application has connected to a queue manager, all the MQI calls it issues are processed by that queue manager until it issues another MQI call to disconnect from that queue manager.

Opening a queue
Before your application can use a queue for messaging, it must open the queue. If you are putting a message on a queue, your application must open the queue for putting. Similarly, if you are getting a message from a queue, your application must open the queue for getting. You can specify that a queue is opened for both getting and putting, if required. The queue manager returns an object handle if the open request is successful. The application specifies this handle, together with the connection handle, when it issues a put or a get call. This ensures that the request is carried out on the correct queue.

Putting and getting messages
When the open request is confirmed, your application can put a message on the queue. To do this, it uses another MQI call on which you have to specify a number of parameters and data structures. These define all the information about the message you are putting, including the message type, its destination, which options are set, and so on. The message data (that is, the application-specific contents of the message your application is sending) is defined in a buffer, which you specify in the MQI call. When the queue manager processes the call, it adds a message descriptor, which contains information that is needed to ensure the message can be delivered properly. The message descriptor is in a format defined by MQSeries; the message data is defined by your application (this is what you put into the message data buffer in your application code).
The program that gets the messages from the queue must first open the queue for getting messages. It must then issue another MQI call to get the message from the queue. On this call, you have to specify which message you want to get.

Messaging using more than one queue manager
This arrangement is not typical for a real messaging application because both programs are running on the same computer, and connected to the same queue manager. In a commercial application, the putting and getting programs would probably be on different computers, and so connected to different queue managers.

<% end if %>