我正在将MQ V7.5.0.3迁移到MQ V9.1.0.2。根据文献，这种迁移没有直接的途径。我需要从V7.5迁移到V9.0，然后最终迁移到V9.1
我想通过以下方式快速访问并直接转到V9.1：
dmpmqcfg V7.5对象
删除发出了dmpmqcfg的qmgr 反对
卸载V7.5
安装V9.1和fixpacs
创建新 使用V7.5 dmpmqcfg输出的qmgr（与V7.5实例名称相同）
由于这是到最新级别的临时迁移，因此似乎只是为了进行MQ迁移而进行多个简短的Version安装，这比必要的工作要多得多。
我的问题是：如果我绕过了多版本迁移过程并执行了上面提到的fastpath步骤，最终结果是否与我进行多次迁移相同？
目前，我同时安装了V7.5和V9.1。然后我意识到我需要先进入V9.0，如果可能的话，我想避免使用它。我可以尝试使用dmpmqcfg并在V9.1上使用它创建一个新的QMGR，但是我不确定这是否能回答我的问题。
答案 0 :(得分：0)
您似乎为自己做了更多的工作。另外，有一些dmpmqcfg无法捕获所有setmqaut和chlauth规则的情况。另外，队列中尚未使用的消息又如何呢？
这样做有什么问题？
如果这是在Linux上，那么确实很容易做到。
无需备份消息数据，无需备份配置，最后，无需担心缺少setmqaut和/或chlauth规则。
答案 1 :(得分：0)
如果您选择创建全新的队列管理器而不是迁移现有的队列管理器，那么一天结束时您可能会发现最终属性略有不同。
在许多情况下，IBM MQ对新属性的缺省值使用不同的缺省值，这取决于您是否创建了全新的队列管理器或是否已将其迁移到新级别。
我可以想到IBM MQ V8中的CONNAUTH属性之一。我认为如果您进行迁移（因此请关闭用户ID和密码检查），则将其留为空白；如果您创建全新的队列管理器（请打开用户ID），则将其设置为指向“ SYSTEM.DEFAULT.AUTHINFO.IDPWOS”对象。并且任何远程连接都必须提供密码检查和授权密码。
dmpmqcfg不会捕获这些东西，因为它是您转储的V7.5对象拥有的新属性。