| Author |
Message
|
| alma |
 Posted: Wed Jan 26, 2011 11:01 am Post subject: Remote Broker Toolkit v7 Connection to v6 2085 |
 |
|
Apprentice
Joined: 26 Jan 2011
Posts: 36
|
Hi Everyone,
Can I make a remote connection from a v7 Message Broker Toolkit to a v6 Message Broker?
When I try to connect it gives me this message:
| Quote: |
A broker has not been defined on queue manager 'TESTBROKERQM' (MQ reason code 2085 while trying to open a queue)
Check that,
1. The broker is running.
2. The TCP/IP port of the queue manager is active if it is remote. |
And can I deploy a v7 bar file to a v6 broker?
Thank you in advance. |
|
| Back to top |
|
 |
| lancelotlinc |
| Posted: Wed Jan 26, 2011 11:06 am Post subject: |
|
|
Jedi Knight
Joined: 22 Mar 2010
Posts: 4941
Location: Bloomington, IL USA
|
The short answer is no to both.
The long answer is, if you only use nodes that did not change between 6 and 7, you could possibly deploy a v7 bar to a v6 runtime. But its not wise and not supported.
_________________
http://leanpub.com/IIB_Tips_and_Tricks
Save $20: Coupon Code: MQSERIES_READER |
|
| Back to top |
|
|
| mqjeff |
| Posted: Wed Jan 26, 2011 11:08 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
|
| Back to top |
|
|
| Vitor |
| Posted: Wed Jan 26, 2011 11:09 am Post subject: Re: Remote Broker Toolkit v7 Connection to v6 2085 |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| alma wrote: |
| Can I make a remote connection from a v7 Message Broker Toolkit to a v6 Message Broker? |
No.
As it says here:
| Quote: |
| The WebSphere Message Broker Explorer and the WebSphere Message Broker Toolkit work only with brokers that you have migrated to, or created in, Version 7.0. If you try to connect to brokers at an earlier version, the connection attempt fails. |
 
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| Vitor |
| Posted: Wed Jan 26, 2011 11:14 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| lancelotlinc wrote: |
| if you only use nodes that did not change between 6 and 7, you could possibly deploy a v7 bar to a v6 runtime. But its not wise and not supported. |
It's not a "unsupported but possibly usable" method. From the same link:
| Quote: |
| You cannot deploy resources that you have created in the WebSphere Message Broker Toolkit Version 7.0 to brokers that are at Version 6.1 or Version 6.0 |
AFAIK the bar file's got a different manifest in v7.
There's also no reason to try it. If you've got coexistence, keep a v6 Toolkit around until migration's finished.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Wed Jan 26, 2011 11:44 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| Vitor wrote: |
It's not a "unsupported but possibly usable" method. From the same link:
| Quote: |
| You cannot deploy resources that you have created in the WebSphere Message Broker Toolkit Version 7.0 to brokers that are at Version 6.1 or Version 6.0 |
|
Errm.
Having just *tried* it.
But it's certainly rolling the dice. |
|
| Back to top |
|
|
| alma |
| Posted: Wed Jan 26, 2011 11:54 am Post subject: |
|
|
Apprentice
Joined: 26 Jan 2011
Posts: 36
|
| I'm sad but thank you very much for your answers. |
|
| Back to top |
|
|
| Vitor |
| Posted: Wed Jan 26, 2011 11:58 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| mqjeff wrote: |
Errm.
Having just *tried* it. |
Doesn't when I try it..... 
....I feel excluded! 
Mind you, the v7 here is a bit experimental. They decided to go to WMQv7 AND WMBv7 AND Windows 7 AND Windows 64 bit in a single jump. So our v7 machine's a bit of a prototype.
And switch the whole company to Active Directory. 
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Wed Jan 26, 2011 12:02 pm Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
Lemme try with a brand new flow, not one that has possibly been migrated from v6. |
|
| Back to top |
|
|
| smdavies99 |
| Posted: Wed Jan 26, 2011 12:25 pm Post subject: |
|
|
Jedi Council
Joined: 10 Feb 2003
Posts: 6076
Location: Somewhere over the Rainbow this side of Never-never land.
|
| Vitor wrote: |
And switch the whole company to Active Directory. |
Well, I hope you have a good supply of headache pills available. At one site we had an AD security profile literally wreck our local dev brokers. They were there. They were running. Couild we connect? Could we heck.
Three hours later and 20 registry hacks and multiple reboots later we sorted out the errant rules and got them reversed.
Good Luck.
_________________
WMQ User since 1999
MQSI/WBI/WMB/'Thingy' User since 2002
Linux user since 1995
Every time you reinvent the wheel the more square it gets (anon). If in doubt think and investigate before you ask silly questions. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Wed Jan 26, 2011 12:33 pm Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| mqjeff wrote: |
Lemme try with a brand new flow, not one that has possibly been migrated from v6. |
Yarh, so MQinput->MQoutput deploys just fine.
Anything else, maybe not. |
|
| Back to top |
|
|
| Vitor |
| Posted: Wed Jan 26, 2011 1:20 pm Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| smdavies99 wrote: |
| Well, I hope you have a good supply of headache pills available. At one site we had an AD security profile literally wreck our local dev brokers. They were there. They were running. Couild we connect? |
The operations people are already out of headache pills, and taking some of the other kind. After the problem you describe above, we now have a group policy enforcing the servers taking Windows Updates at 3am, and rebooting at the end of the update process. This in turn causes MSCS to failover the Websphere stack and then have some kind of psychotic episode when the original server reboots.
Under normal circumstances, we have 3 clusters for Dev, Test & UAT with 2 broker/queue manager pairs in each enivornment. One morning all 6 brokers and queue managers had been failed over on a single, rather stressed server.
I think the fun is just starting. 
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| smdavies99 |
| Posted: Wed Jan 26, 2011 2:05 pm Post subject: |
|
|
Jedi Council
Joined: 10 Feb 2003
Posts: 6076
Location: Somewhere over the Rainbow this side of Never-never land.
|
| Quote: |
Eenforcing the servers taking Windows Updates at 3am
|
And this is for Servers?
Wow. They are truly demented.
If this is not an argument NOT to use Windows in a production environment, I really don't know what is.
At my current site we use Solaris. Even the Dev Server has an O/S uptime approaching 180days. This will be rebooted next week when the O/S and WMQ and Broker get patched. Soap Node APAR Applied Yippeee.
Seriously Vitor, your Windows Admins really need to understand that a Windows Server is not a Desktop that can be rebooted without implication especially to the business.
_________________
WMQ User since 1999
MQSI/WBI/WMB/'Thingy' User since 2002
Linux user since 1995
Every time you reinvent the wheel the more square it gets (anon). If in doubt think and investigate before you ask silly questions. |
|
| Back to top |
|
|
| Vitor |
| Posted: Thu Jan 27, 2011 3:26 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| smdavies99 wrote: |
| Seriously Vitor, your Windows Admins really need to understand that a Windows Server is not a Desktop that can be rebooted without implication especially to the business. |
The operations people have explained that. Repeatedly and quite hard. The problem (or one of them) is that the "group policy" (this is not really my area) for the service users enforced the taking of the update & the AD people couldn't figure out why or how to stop it.
I keep as clear as I can. Enough problems of my own without these.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| lancelotlinc |
| Posted: Thu Jan 27, 2011 11:47 am Post subject: |
|
|
Jedi Knight
Joined: 22 Mar 2010
Posts: 4941
Location: Bloomington, IL USA
|
| mqjeff wrote: |
| mqjeff wrote: |
Lemme try with a brand new flow, not one that has possibly been migrated from v6. |
Yarh, so MQinput->MQoutput deploys just fine.
Anything else, maybe not. |
BAR = JAR. JAR = ZIP. Therefore, BAR = ZIP. Thus, mqsideploy can deploy any bar file to any version.
The limitation here is that in the runtime, some of the behaviours on some of the nodes change between versions. Therefore, the xml that defines the nodes inside the BAR file may not match up with some of the runtime differences between the versions.
The simpler nodes that did not change between six and seven should work just fine. The more complex nodes would not.
You may also have to FTP the file to the destination server manually and use the version-specific mqsideploy command.
The only action (AFAIK) that mqsideploy does in relation to pushing a bar file is mqsideploy explodes the contents of the bar/jar/zip onto disk and registers the contents with the EG.
_________________
http://leanpub.com/IIB_Tips_and_Tricks
Save $20: Coupon Code: MQSERIES_READER |
|
| Back to top |
|
|
|
|
