Integration


This is an IBM Automation portal for Integration products. To view all of your ideas submitted to IBM, create and manage groups of Ideas, or create an idea explicitly set to be either visible by all (public) or visible only to you and IBM (private), use the IBM Unified Ideas Portal (https://ideas.ibm.com).


Shape the future of IBM!

We invite you to shape the future of IBM, including product roadmaps, by submitting ideas that matter to you the most. Here's how it works:

Search existing ideas

Start by searching and reviewing ideas and requests to enhance a product or service. Take a look at ideas others have posted, and add a comment, vote, or subscribe to updates on them if they matter to you. If you can't find what you are looking for,

Post your ideas

  1. Post an idea.

  2. Get feedback from the IBM team and other customers to refine your idea.

  3. Follow the idea through the IBM Ideas process.


Specific links you will want to bookmark for future use

Welcome to the IBM Ideas Portal (https://www.ibm.com/ideas) - Use this site to find out additional information and details about the IBM Ideas process and statuses.

IBM Unified Ideas Portal (https://ideas.ibm.com) - Use this site to view all of your ideas, create new ideas for any IBM product, or search for ideas across all of IBM.

ideasibm@us.ibm.com - Use this email to suggest enhancements to the Ideas process or request help from IBM for submitting your Ideas.


Add a new idea Subscribe
Status Not under consideration
Workspace MQ, MQ Advanced & MQ Appliance
Created by Guest
Created on Nov 25, 2025

RELATED IDEAS

Eliminate the manual BACKMIG command requirement for compatibility with older MQ versions.

Starting with MQ 9.3, IBM introduced the BACKMIG command to convert MQ datasets to a format compatible with older versions (MQ backout). Without using BACKMIG, the Queue Manager may encounter issues when starting on a lower version. Therefore, it is necessary to issue the BACKMIG command when planning to start the MQ Queue Manager with a lower MQ version.

As we plan to upgrade to a new MQ version, there is a possibility that we may need to back out the MQ version if any issues arise. As part of the backout process, we issue the BACKMIG command when all other tasks are down, repoint the MQ libraries to the lower MQ version, and perform an IPL to start MQ with the lower version.

For every MQ backout, the MQ team needs to back out all other dependent tasks, unmanage every MSTR, issue the BACKMIG command, and then manage automation. For QSG Queue Managers, we also need to start the corresponding DB2 before issuing BACKMIG and stop the same DB2 after issuing BACKMIG. If there are additional mandatory tasks for the MQ upgrade as part of the new MQ migration, this will require involvement from multiple teams across all environments.

Altogether, this increases the time required due to dependencies and the need to issue the BACKMIG command for each queue manager on every sysplex, compared to previous MQ backout migrations. Therefore, we need assistance in obtaining the old backout method or, at the very least, in removing the need to manually issue the BACKMIG command to convert MQ datasets to a format compatible with older versions.

Idea priority Urgent
  • Guest
    Jan 7, 2026

    Thank you for the clarification regarding the BACKMIG command and the rationale behind its introduction.

    However, at JPMC, all MQ tasks are controlled and managed by automation. Starting and stopping MQ MSTR/CHIN tasks are handled by automated processes, and during these operations, we cannot issue any commands. To issue the BACKMIG command, we need to remove the queue manager from automation and execute the command manually. Prior to MQ V9.3, we did not need to issue any manual commands, and all MQ backouts were completed automatically and efficiently.

    With this change, we are now spending a significant amount of time manually issuing commands for all queue managers during MQ backout. The DB2 team, Mainframe Operations team, Mainframe MQ team, Software team, CICS team, WAS team, and other teams, along with the application team, must wait on calls to validate after MQ backout. This process is taking considerably more time compared to the previous approach and is impacting application availability.

    Regarding the Db2 stop/start during MQ migration, when we issue BACKMIG for a QSG queue manager, the DB2 task must be active; otherwise, the queue manager encounters issues during backout. We are following this procedure based on guidance from the IBM MQ PMR team.

    Reply
  • Admin
    Matthew Leming
    Dec 8, 2025

    The BACKMIG command was introduced to reduce the cost of having to apply migration and coexistence PTFs across all queue managers in a QSG before migrating forwards to a given LTS release. Having to apply these PTFs, and recycle queue managers etc, was a burden on MQ ops teams, and were expensive and slow for us to create. We have no plan to go back to the old approach.

    You shouldn't need to stop/start Db2 around an MQ migration, so its worth understanding why that is part of your current process.


    Reply

By clicking the "Post Comment" or "Submit Idea" button, you are agreeing to the IBM Ideas Portal Terms of Use.
Do not place IBM confidential, company confidential, or personal information into any field.