If you work with IBM MQ long enough, you’ll see this movie: an application team says “we sent it,” a downstream team says “we never got it,” and MQ lands in the hot seat. It’s not bad faith—just the reality of complex, distributed systems. But the back-and-forth burns time, frays trust, and doesn’t get anyone closer to the truth.

That’s exactly why I’m excited about an upcoming session we’re hosting: “Proving It Wasn’t MQ’s Fault.” It’s a practical walk-through of how to figure out what actually happen

ed when messages appear to go missing—starting from the application side, checking the right MQ artifacts, and using a simple sanity test you can run yourself before you call in reinforcements. 

Why these two presenters We’ve got Jason Easterly, Senior Automation Technical Sales Manager at IBM and Peter D’Agosta, Chief Product Manager at Avada Software leading the session. If you know them, you already see why that’s good news. If not, here’s what I value about this pairing: Jason brings the “start with application evidence” mindset and a gift for explaining MQ concepts without turning them into a lecture. He’s been in the trenches on the app side and the MQ side, which means his guidance plays well with both audiences—developers and administrators. Peter brings decades of “show me the receipts” discipline. He’s excellent at translating symptoms into the specific MQ things you should inspect next—and at illustrating how small environmental changes (OS/Unix patching, firewall/port rules, mainframe hops) can masquerade as MQ problems. Put simply: Jason will help you ask the right first questions, and Peter will help you check the right evidence.

What you’ll take away

This is an educational session, not a pitch. Come for practical steps you can apply the same day:

• • A clear starting point on the application side, so you don’t jump straight into the queue manager out of habit.

  • A short list of MQ artifacts that matter most when messages “disappear,” plus how to read them.

  • A DIY round-trip sanity check you can run to confirm delivery—or quickly prove where things went off the rails.

  • A realistic view of non-MQ causes (network/firewall/ports, mainframe hops, platform changes) and how to collaborate with those teams using evidence instead of assumptions.

Join us

If getting to the truth faster (and with less drama) sounds good, grab a seat. The session is concise, pragmatic, and built around real-world scenarios. Register now (details on the event page), and bring your questions—we’ll leave time to take live questions.