Why messaging exists
IBM MQ lets one program put a message on a queue and carry on, while another program picks it up when it is ready. Neither has to be running at the same moment, and MQ makes sure the message is neither lost nor delivered twice.
The problem MQ solves
Imagine a mobile banking app that needs to tell the mainframe about a payment. If the app called the mainframe program directly and waited, every slowdown or restart on the mainframe would freeze the app. With messaging, the app puts a message on a queue manager's queue and gets an acknowledgement. The mainframe program reads it when it is ready.
What a message is
A message has two parts: a message descriptor (the MQMD), which holds control information such as the message ID, correlation ID, priority, persistence and where replies should go, and the application data, which MQ does not look inside. The data might be a fixed COBOL record, JSON or XML: that is agreed between the two applications.
Assured delivery
| Setting | What happens | Typical use |
|---|---|---|
| Persistent | MQ logs the message, so it survives a queue manager restart | Payments, orders, anything that must not be lost |
| Non-persistent | Kept in memory; faster, but lost if the queue manager stops | Enquiries that can simply be asked again |
Persistent messages put inside a unit of work are delivered once and once only: the message either arrives and the receiver's database update commits, or both are backed out together.
Two messaging styles
- Point-to-point: a sender puts to a named queue and one receiving application gets each message. This is the most common pattern in mainframe shops.
- Publish/subscribe: a publisher sends to a topic, and every subscriber to that topic receives a copy. Useful when several systems want the same event, such as an address change.
Common mistakes
A queue is a hand-off point, not a store. Messages are meant to be consumed. If a queue keeps growing, something downstream is wrong.
Non-persistent messages are lost if the queue manager restarts. Anything financial or hard to recreate should be persistent and processed under syncpoint.
MQ moves bytes. Both sides must agree the layout, code page and encoding. Many 'MQ problems' are really data-format problems.
What you will see at work
- Integration teams design the message formats; mainframe developers write the COBOL that puts and gets them.
- Production support watches queue depths: a queue that only grows means the reader has stopped.
- Asking 'is it persistent, and is it under syncpoint?' is one of the first questions in any MQ design review.
Key terms
Check your understanding.
Take this lesson's quiz and save your progress. Free.