| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
| Can two Qmgrs have same QMID? |
« View previous topic :: View next topic » |
| Author |
Message
|
| bruce2359 |
 Posted: Mon Jul 28, 2008 7:02 am Post subject: |
 |
|
Poobah
Joined: 05 Jan 2008
Posts: 9472
Location: US: west coast, almost. Otherwise, enroute.
|
| Quote: |
| ...industry best practice is to always use unique queue manager names. Its common to include the environment type and a sequence number in the name, eg. BOBTEST1, BOBQA1, BOBPROD1. |
Of course; but it's just a best practice, not carved in stone. One view of application promotion is to make it transparent to both the application programmer (not changing MQCONN qmgrname), AND the sysadmin. But it's a choice.
| Quote: |
| Applications should obtain qmgr name and queue names from configuration info somewhere (file, registry, factory etc), so that promotion of app programs from one environment to another will work transparently. |
But if you (or your client) can't or don't want to, then what?
| Quote: |
| Your reasoning does not hold any water. |
Hmmm.
| Quote: |
| The MQ object definition files that are promoted from one environment to the next should only contain queue objects. There should be no channel objects, as the connames will be different in each environment (unless you have also made the mistake of using the same host names for dev, qa & prod!) |
As with most technical things, this takes understanding the product, the environment, and planning. These were apparently missing here.
_________________
I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live. |
|
| Back to top |
|
 |
| sami.stormrage |
| Posted: Mon Jul 28, 2008 1:32 pm Post subject: |
|
|
Disciple
Joined: 25 Jun 2008
Posts: 186
Location: Bangalore/Singapore
|
| Quote: |
Of course; but it's just a best practice, not carved in stone. One view of application promotion is to make it transparent to both the application programmer (not changing MQCONN qmgrname), AND the sysadmin. But it's a choice.
|
Offcourse they are like carvings on a Stone, U would be doomed one day and find that it was the mistake of not following the Best practises that were recommended.
One instance is I could remember is that an app team used the same Q for TEST, QA and Prod aswell. So if u do not keep ur environments seperate. One new comer might test an app to credit some money to an accont and it may one day be found that someone changed the seetings to PROD and the that money has be dubiously credited to some account.. This was a real thing that happend in Amex environment! 
_________________
*forgetting everything  * |
|
| Back to top |
|
|
| kevinf2349 |
| Posted: Mon Jul 28, 2008 5:49 pm Post subject: |
|
|
Grand Master
Joined: 28 Feb 2003
Posts: 1311
Location: USA
|
...then they need to fire their security personel!
SOX wil eat them alive for allowing developers access to a production environment.
We use the same queue names, but the queue manager names are passed as parameters or config files.
Only users are allowed access to Production, queue managers and queues.
Then you have made your SOX auditors happy, and kept your CIO from a prison cell....oh, one side effect of same queue name? No code changes between all environments  |
|
| Back to top |
|
|
| gbaddeley |
| Posted: Mon Jul 28, 2008 7:49 pm Post subject: |
|
|
Jedi Knight
Joined: 25 Mar 2003
Posts: 2538
Location: Melbourne, Australia
|
| kevinf2349 wrote: |
| ...oh, one side effect of same queue name? No code changes between all environments |
MQ object names (queues, channels, queue managers) should NEVER be put in code. They should always be passed as parameters to the code, from a config file, command line, environment variables, etc.
Queue names should be different for dev, test, prod environments, to mitigate the possibility of accidentally connecting apps to the wrong environment, or accidentally connecting MQ clusters across environments. The difference in name need only be subtle. eg. BOB.DEV.ORDERS.INPUT, BOB.PRD.ORDERS.INPUT.
| Quote: |
| But if you (or your client) can't or don't want to, then what? |
They you have to make the best of the bad situation and be extremely careful what you do with each environment. I would start making medium to long term plans to change the setup, even if it takes years.
_________________
Glenn |
|
| Back to top |
|
|
| gbaddeley |
| Posted: Mon Jul 28, 2008 11:22 pm Post subject: |
|
|
Jedi Knight
Joined: 25 Mar 2003
Posts: 2538
Location: Melbourne, Australia
|
|
| Back to top |
|
|
|
|
|
|
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
|
|
|
|
