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 DB2 Stored
IMS BMP Procedure
IMS batch VB program on
OS/390 Batch Windows
C program on
TSO
Windows or Unix
CICS

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

Local Queuing
Distributed Queuing
Distributed Queuing
 Server to Server

Unix or NT Server
Hosting:
Queue Manager OS/390 hosting:
Server sw (WebSphere, Queue Manager
Client PCs UP, IIS, Apache, Web IMS
(no MQ sw at all) server…) DB2
….
Server to Server -
Server application gets it’s data using
MQ. Clients do not use MQ API
Guaranteed Delivery in effect
Server license required
 Client to Server

Unix or NT Server
Hosting:
Queue Manager, OS/390 hosting:
MQ Client support, Queue Manager
Client PCs other server sw IMS
(MQ client sw) 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
Problem…Solution…
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.
Problem…Solution…
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
New BMP, cycles every x minutes
MQ CAD
to 1) Reads all messages from queue into buffer
ECS 2) Sorts on sequence number
3) Processes each in proper order

ECS
Database

ECS *existing ECS MPPs modified to:

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

MQ MQRECV OG_Main_Download

UP Database

MQSEND OF_Main_Upload
Problem…Solution…
A PC user needs to request an overnight report that needs
data from IMS, DB2 and other files.

A VB program puts the report requirements on a queue

which is read by a batch job
Problem…Solution…
Web server needs data from legacy IMS/CICS transaction.

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).
Problem…Solution…
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 populate
reply queues on an NT system, which the VB app will read
to present to the user.
The VB client need not wait for the report to be completed.
It could spawn a separate thread that would monitor the
reply queues and notify the user when the report
was complete.