IBM TechXchange North Texas Integration User Group

IBM TechXchange North Texas Integration User Group

Welcome to the IBM TechXchange North Texas Integration User Group, where IT integration professionals in the North Dallas area can discuss, blog, and share resources related to all aspects of IBM IT integration solutions.

 View Only
Back to discussions
Expand all | Collapse all

Seeing Red During Your MQ Upgrade? Don't Panic-It Might Just Be a Ghost.

  • 1.  Seeing Red During Your MQ Upgrade? Don't Panic-It Might Just Be a Ghost.

    Posted 10 days ago

    Upgrading IBM MQ from version 9.3.0.27 to 9.3.0.30 and running into ominous-looking error messages? You're not alone. Many MQ admins have reported seeing alerts like these during installation:

    Failed to destroy subpools lock for QMgr 'QM_BANCS_CL_UAT': rc=545284457 

    Failed to destroy subpools lock for QMgr 'QM01_BANKING_CL_UAT': rc=545284457

    If you've already braced for a roll-back or support ticket-take a deep breath. These errors, while real, are just harmless echoes of an old, resolved issue. In fact, your queue managers are most likely just fine.

    Let's unpack what's going on.

    🧩 What's Causing These Messages?

    These errors are tied to IBM's handling of subpool lock semaphores-essentially internal synchronization mechanisms used when queue managers operate.

    During the upgrade process, IBM MQ tries to clean up related semaphore files, notably:

    /var/mqm/qmgrs/<QMgr>/subpool.lck

    If that file or its parent directory is already missing, the cleanup routine throws a message like the one above. The system logs a non-zero return code (like rc=545284457), which looks alarming-but is not a sign of failure.

    📜 APAR IT46711: The History

    This issue was formally recognized under APAR IT46711, and a fix was rolled into IBM MQ 9.3.0.25. That fix addressed a specific cause of semaphore cleanup failures-but not all scenarios.

    IBM has since clarified that:

    "The [APAR IT46711] issue doesn't affect either 9.3.0.27 or 9.3.0.30... The message appears when deleting enqueues and subpool lock semaphore sets, but the subpool.lck file or its parent directories do not exist."
    -     IBM Support, DT446490

    So yes: the message still appears. But it doesn't impact your upgrade success or your queue managers' runtime behavior.

    ✅ Should You Be Concerned?

    In short: No. If:

    • The fix pack completes successfully, and
    • Your queue managers start and run normally,

    …then the error is harmless and can be safely ignored.

    The cleanup script is simply trying to delete something that isn't there anymore-and that's okay. It's like checking to lock your door only to realize it was never open.

    🛠 What You Should Do

    • Monitor the upgrade output: Confirm the fix pack installs successfully and no critical errors are reported.
    • Start and verify queue managers: If they start cleanly and function normally, you're in the clear.
    • Avoid knee-jerk support calls: This one's known, documented, and benign.
    • Educate your team: These messages may alarm junior admins or monitoring tools-flag them as expected if you're running upgrades across environments.

    🧠 Takeaway

    That spooky "Failed to destroy subpools lock" error? It's just a ghost from MQ versions past. IBM's already addressed its underlying cause, and the rest is just noise.

    So go ahead-upgrade with confidence. And the next time you see that error, just smile, nod, and move along.

    💬 What's Been Your Experience?

    Where are you with MQ? Already moved to 9.4.3? Have you run into these messages during your own upgrades? Did you dig into them, ignore them, or open a case before discovering it was benign? Share how your team handled it-or if you've seen other oddities during MQ upgrades. Let's compare notes-this could help others avoid unnecessary rabbit holes.



    ------------------------------
    Scott Treggiari
    Avada Software
    ------------------------------


Related Content