MQ Series

Cross Platform
Dominant Messaging sw 70% of
market
Messaging API same on all
platforms
Guaranteed one-time delivery
Two-Phase Commit
Wide EAI industry support

What is it?
MQSeries is a middleware product from IBM that runs on
multiple platforms and enables applications to send messages
to other applications. Basically, the sending application PUTs
a message on a Queue, and the receiving application GETs
the message from the Queue. The sending and receiving
applications do not have to be on the same platform, and do
not have to be executing at the same time.
MQSeries takes care of all the storage, logging and
communications details required to guarantee delivery of the
message to the destination queue. In most cases, it will take
care of translating the data when the source and destination
use different character sets (EBCDIC on MVS vs. ASCII on NT
or Unix). All the applications have to do is know the name of
the Queue and agree on the meaning of the message.

MQ Series API (basic)

Connect to a Queue Manager
Open a queue
Put or get messages
Close a queue
Commit or roll back
Disconnect

Advanced features
Triggering automatically starting
an application to process a
message
IMS & CICS Bridges reusing legacy
transactions without modification
Confirmation of message arrival,
delivery
Grouping of messages
Load balancing

MQ Application
environments
IMS transaction
IMS BMP
IMS batch
OS/390 Batch
TSO
CICS

DB2 Stored
Procedure
VB program on
Windows
C program on
Windows or Unix

Supported languages include VB, C/C++, PL/1 and Cobo

Local Queuing

Distributed Queuing

Distributed Queuing

Server to Server

Client PCs
(no MQ sw at all)

Unix or NT Server
Hosting:
Queue Manager
Server sw (WebSphere,
UP, IIS, Apache, Web
server)

OS/390 hosting:
Queue Manager
IMS
DB2
.

Server to Server Server application gets its data

using MQ. Clients do not use MQ
API
Guaranteed Delivery in effect
Server license required

Client to Server

Client PCs
(MQ client sw)

Unix or NT Server
Hosting:
Queue Manager,
MQ Client support,
other server sw

OS/390 hosting:
Queue Manager
IMS
DB2

Client to Server
Client applications use MQ API
(linked differently)
MQ processing actually occurs on
server within client support
modules
Client licenses free
Guaranteed delivery not supported
over client server link

To what problems is MQ
the solution?
Fast, asynchronous inter-system
notification.
Data propagation
Transferring data from mainframe
systems to PC/Unix systems
Transferring data from PC/Unix
systems to mainframe systems

ProblemSolution
An event in an IMS system requires action by a
midrange system.
Modify the IMS program to PUT a message to
the midrange system. The midrange system can be
configured to start the application whenever a
message arrives.

ProblemSolution
An event in an midrange system requires action by a
mainframe system.
Modify the midrange program to PUT a message to
the mainframe system. The mainframe system can
process the message :
-Immediately
-At set intervals
-On a schedule

CAD - MQ Architecture
MQ

CAD
to
ECS

New BMP, cycles every x minutes

1)
Reads all messages from queue into buffer
2)
Sorts on sequence number
3)
Processes each in proper order

ECS
Database

ECS
to
CAD

MQ

MQRECV

*existing ECS MPPs modified to:

1 add XML formatting to some data
2 MQPUT to UP incoming queue

OG_Main_Download
UP Database

MQSEND

OF_Main_Upload

ProblemSolution

A PC user needs to request an overnight report that ne

data from IMS, DB2 and other files.

A VB program puts the report requirements on a queue

which is read by a batch job

ProblemSolution

Web server needs data from legacy IMS/CICS transactio

Web server puts a message to the MQ-IMS/CICS Bridge

which runs the transaction and returns the results on a
queue (screen-scraping without the 3270).

ProblemSolution
VB app needs data from DB2, SQL Server and IMS

VB client app puts messages on queues on NT and

mainframe systems, triggering programs which popula
reply queues on an NT system, which the VB app will re
to present to the user.
The VB client need not wait for the report to be comple
It could spawn a separate thread that would monitor th
reply queues and notify the user when the report
was complete.