|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
 |
|
MQ latest version |
« View previous topic :: View next topic » |
Author |
Message
|
regonda |
Posted: Tue Apr 20, 2010 6:27 am Post subject: MQ latest version |
|
|
 Apprentice
Joined: 08 Apr 2008 Posts: 43
|
I have a doubt regarding the MQ latest version, request you to please clarify me the below...
Our MQ is at version 6 now and the source system which sends XML files to our HUB is on mainframes server at MQ version 6.0.
Now they want to upgrade their MQ version to 7, so please let me know if there is any impact/ issues if we still continue with our MQ version 6.0...
do we also need upgrade our queue manager which communicates with that source system server to MQ version 7.0..
Please help me.. |
|
Back to top |
|
 |
exerk |
Posted: Tue Apr 20, 2010 6:38 am Post subject: Re: MQ latest version |
|
|
 Jedi Council
Joined: 02 Nov 2006 Posts: 6339
|
regonda wrote: |
I have a doubt regarding the MQ latest version, request you to please clarify me the below... |
The your first recourse is to the documentation, or your IBM representative...
regonda wrote: |
...Now they want to upgrade their MQ version to 7, so please let me know if there is any impact/ issues if we still continue with our MQ version 6.0... |
See above comment...with the additional caveat that with each version introduced more 'bells and whistles' are added, so there may be attributes/enhancements within the later version that the previous version is unaware of...
regonda wrote: |
...do we also need upgrade our queue manager which communicates with that source system server to MQ version 7.0... |
Does logic suggest that every user of WMQ would have their world grind to a halt just because someone to which they are connected upgraded?  _________________ It's puzzling, I don't think I've ever seen anything quite like this before...and it's hard to soar like an eagle when you're surrounded by turkeys. |
|
Back to top |
|
 |
JosephGramig |
Posted: Thu Apr 22, 2010 4:37 am Post subject: |
|
|
 Grand Master
Joined: 09 Feb 2006 Posts: 1244 Location: Gold Coast of Florida, USA
|
Well, "Best Practice" is to upgrade your "Full Repositories" first.
Consider bringing all your OS and software levels to the prerequisites of WMQ V7.0 even if you are not upgrading MQ.
Last, WMQ V6.0 reaches "End Of Support" (EOS) September 2011.
Last last, consider changing all local, remote and alias queues to DEFBIND(NOTFIXED), as the behavior changes from V6 to V7 and you might be surprised. Anyway, if an application needed "bind on open", it should have specified that on the open options. |
|
Back to top |
|
 |
zpat |
Posted: Thu Apr 22, 2010 5:12 am Post subject: |
|
|
 Jedi Council
Joined: 19 May 2001 Posts: 5866 Location: UK
|
WMQ 6 and 7 will interoperate, both at QM and client level.
It would be an impossible job for large installations to upgrade everything at once! |
|
Back to top |
|
 |
John89011 |
Posted: Fri Apr 23, 2010 3:12 pm Post subject: |
|
|
Voyager
Joined: 15 Apr 2009 Posts: 94
|
JosephGramig wrote: |
Last last, consider changing all local, remote and alias queues to DEFBIND(NOTFIXED), as the behavior changes from V6 to V7 and you might be surprised. Anyway, if an application needed "bind on open", it should have specified that on the open options. |
Just curious... why change QLs, QRs and QAs to DEFBIND(NOTFIXED)? How did the behavior change from V6 to V7?
Thanks! |
|
Back to top |
|
 |
JosephGramig |
Posted: Mon Apr 26, 2010 4:52 am Post subject: |
|
|
 Grand Master
Joined: 09 Feb 2006 Posts: 1244 Location: Gold Coast of Florida, USA
|
Oddly enough, there was an interpretation difference in how alias queues should work with respect to clustering.
In V6, if the alias queue was not advertised (aka in the cluster), the DEFBIND setting of the target queue was respected rather than the DEFBIND of the alias queue.
IMHO, I expected any and all attributes of the alias queue to override that of the target queue. There is an environment variable you can set to get that behavior in V6 (indicating that others agreed with me even before I knew this).
In V7, the behavior of the alias queue attributes overriding the target queue does happen by default. You could set the environment variable to get the V6 behavior but I would not do that unless you wish to cause great confusion.
So, I stopped and thought about it... Really, almost all programs want DEFBIND(NOTFIXED) and in the rare case they do need DEFBIND(OPEN), then they should specify that on the open call.
Which begs the question, "Why isn't DEFBIND(NOTFIXED) the default?"
You could even argue that was the behavior before clustering was even introduced (just as easily as the opposite). |
|
Back to top |
|
 |
|
|
 |
|
Page 1 of 1 |
|
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum
|
|
|
|