Certain aspects of service orientation are best served using an IBM® WebSphere® MQ cluster. The cluster provides the location independence, run time resolution of names, and concurrency required by SOA applications. For these reasons, adoption of SOA is driving migrations from point-to-point messaging networks to clustered environments. This article looks at how migration, failover, and the scaling of queue managers are affected in an SOA context.
Full text on developerWorks.
Hi Hatcher,
Yes, Fix Packs are cumulative. If you have any version of v7 you can apply v7.0.1.3 over top of it.
Can you upgrade from version 7.0.0.1 driectly to v7.0.1.3, bypassing 7.0.1.0. From the doc I don’t think so
Hi T-Rob,
hope you can change the text.
To answer your questions, yes attributes that should not change or are not mentioned are preserved, the programs generate ALTER or DEFINE commands as required (DEFINE only when an object does not exist already). REPLACE is not used unless you specifically ask for it.
Lastly the MQArchitect Implementation streamliner directly interacts at runtime with WebSphere MQ and even preserves the values of the changed attributes (so you can roll-back any changes!!!) There is also the option generate scripts in advance, but these scripts obviously do not have the capability to preserve previous values, more information can be found on: http://www.mqsystems.com 🙂
Thanks, Michael! I will see if I can have that line deleted. Not sure how that snuck past us. 🙂
When you say your products work from a state point of view, does that mean they preserve all the attributes other than the ones you wish to change? Do they produce ALTER commands or DEFINE/REPLACE and does this happen at run time or can you prepare the scripts in advance?
Hi T-Rob,
great contribution as always!
please update listing 2:
ALTER CHANNEL(QM1.QM2) CHLTYPE(SDR) +
CONNAME(‘host.of.qm2(1414)’)
Remove: PUT(DISABLED) as it is not an attribute of a Channel!
The DEFINE/ALTER interface is not of this time, either for Point-to-Point or the SOA paradigm.
Both MQDocument and MQArchitect work from a “state” point of view, just say “what you want” and they will make the appropriate MQSC commands for you and even execute them if needed!
For more information see: http://www.mqsystems.com