I've seen a lot of responses to thisone which is actually very ineresting discusion topic. Most of responses concentrate on 1) resource usage on the server running multiple QMgrs 2) 20char limit to the channel names 3) It desn't have any sense to run multiple QMgrs on the same server because whatever happens to that server happens to all the QMgrs
Now, I'd like to through in couple considerations. Let's say that your company provides services to multiple external clients and you want to separate these clients by SSL. 3) What happens if your single QMgr goes down? The answer is that this event affects all of your customers. You can argue that you don't have a single QMgr but multiple may be even clustered QMgrs and your MQ client apps can switch over from that failed QMgr to the other. But the point is that ALL of your customers will be affected. What if one of your customers' message traffic requirements just increased 10 times and you don't want it to have any effect on others. What you want to do is to segregate this customer to the separate server(s). If you have a seperate QMgrs you can do it instantaniously: just feed your saveqmgr scripts and auth scripts into the newly created QMgr and you are good to go. So from the operational point of view it makes a lot of sense to have separate QMgrs attached to a particular interface. Interface can mean a group of apps, external client, etc. 2)That's true, so it makes sense to keep your QMgr name limited to 9chars 1) This is really not a concern in this century especially on distributed side 0) It does make a lot of sense to create orgonomic names that are very convinient to your QM admins. When your admin wakes up in the middle of the night yuou don'yt want him to change smth on the production system oppose to UAT or QA one. For QMgr name you can have smth like PDCUSQMzN z - is either "gateway" or "service" QMgr in clustered env N - number CUS - your interface or customer name Thanks, --- Armand ten Dam <[EMAIL PROTECTED]> wrote: > Hi all, > For an integration project I have been asked to > adopt an MQ naming standard > that reflects a very unusual approach in MQ-based > integration. I have never > seen this approach before and have serious concerns > in adopting any of it. > > Key in the design is the use of separate queue > managers for each application > pair. E.g. if an application interfaces with eight > different distributed > applications this would result in eight separate > queue managers on a single > system. > > Some examples: > Queue manager: > QMPROD.SOURCECOMPANY.SOURCEAPP.TARGETCOMPANY.TARGETAPP.SYSTEMNAME > Channel: > CHPROD.SOURCECOMPANY.SOURCEAPP.TO.TARGETCOMPANY.TARGETAPP > Transmission queue: > TXPROD.SOURCECOMPANY.SOURCEAPP.TO.TARGETCOMPANY.TARGETAPP > ... > > Obviously this does not reflect best-practice, > seriously impacts > scalability, makes support of the MQ infrastructure > difficult etc. > > As it looks like it will be a bit of a political > discussion to get this out > of the way, > I am looking to gather as much 'neutral' feedback to > back me up. I would > appreciate it if some of you could shed some more > light on the implications > of the above approach. > > Any insights much appreciated, > Thanks, > Armand > > _________________________________________________________________ > Hot chart ringtones and polyphonics. Go to > http://ninemsn.com.au/share/redir/adTrack.asp?mode=click&clientID=174&referral=Hotmail_taglines_plain&URL=http://ninemsn.com.au/mobilemania/default.asp > > Instructions for managing your mailing list > subscription are provided in > the Listserv General Users Guide available at > http://www.lsoft.com > Archive: http://vm.akh-wien.ac.at/MQSeries.archive ===== Vitaliy Ilyin ---------------------------------------------------------------- Principal Middleware Architect IBM Certified Solutions Expert - WMQ (MQSeries v5.3) & WMQI (WebSphereMQ Integrator) IBM Certified Specialist - WMQ (MQSeries v5.3) & WMQI (WebSphereMQ Integrator) IBM Certified Developer - WMQI (MQSeries v5.2) 781-363-3474 http://www.ICnowledge.com __________________________________ Do you Yahoo!? SBC Yahoo! DSL - Now only $29.95 per month! http://sbc.yahoo.com Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive
