The PC term is now PUREST!!! (hahahahahaha)
From: Rick Tsujimoto <[EMAIL PROTECTED]>
Reply-To: MQSeries List <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Subject: Re: Questionable MQ infrastructure design
Date: Tue, 15 Jul 2003 12:17:14 -0400
tsk tsk tsk...just like a techie
Robert Broderick
<[EMAIL PROTECTED] To:
[EMAIL PROTECTED]
OTMAIL.COM> cc:
Sent by: MQSeries Subject: Re: Questionable
MQ infrastructure design
List
<[EMAIL PROTECTED]
.AC.AT>
07/15/2003 12:00
PM
Please respond to
MQSeries List
Aliases!!!!!! Yuck....What a deplorable thing!!!!!!!!!!!!!!!!!!!!!!
>From: Rick Tsujimoto <[EMAIL PROTECTED]>
>Reply-To: MQSeries List <[EMAIL PROTECTED]>
>To: [EMAIL PROTECTED]
>Subject: Re: Questionable MQ infrastructure design
>Date: Tue, 15 Jul 2003 09:24:24 -0400
>
>Isn't that why we have QALIASes? One for the programmers, and one for
us.
>
>
>
>
> Robert Broderick
> <[EMAIL PROTECTED] To:
>[EMAIL PROTECTED]
> OTMAIL.COM> cc:
> Sent by: MQSeries Subject: Re:
Questionable
>MQ infrastructure design
> List
> <[EMAIL PROTECTED]
> .AC.AT>
>
>
> 07/15/2003 07:09
> AM
> Please respond to
> MQSeries List
>
>
>
>
>
>Try to debug a service oriented at 3:00AM when all you got is a queue
name
>to go on and your critical financial start-of-day application is getting
a
>bad data enima and your application SME has had enough of his/her crappy
>job
>and busted the batteries out of their beeper.
>
>I understand that in this age of OVER doing things and making everything
>nicey nice and looking like we all got degrees from MIT. BUT...what often
>is
>best is the KISS method.
>
>I have been in these situations and what people take for granted when
>naming
>"BUSINESS OBJECT" sort of eludes the actual person who is harpooned with
>the
>process of figuring out what the problem. And also from experience it
isn't
>the MSTER of names that will take the heat for the application /
>infrasturcture not working.
>
>We do a better job if we design and NAME system that are a little less
>abstract and a lot more realistic. I know that sometimes this is not
>possible but......................................................:-)
>
> bee-oh-dubble-bee-dubble-egh
>
>
> >From: "Kelly, Steve" <[EMAIL PROTECTED]>
> >Reply-To: MQSeries List <[EMAIL PROTECTED]>
> >To: [EMAIL PROTECTED]
> >Subject: Re: Questionable MQ infrastructure design
> >Date: Mon, 14 Jul 2003 17:26:01 -0400
> >
> >Interesting. Agree with channel names but queue names ? In a
> >service-oriented architecture don't you want your queue names to
identify
> >the shared service they drive. So, for example,
UPDATE.NAME.AND.ADDRESS,
> >CREDIT.MY.ACCOUNT etc. When we are all trying to maximise re-use do we
> >really care who the sending application is? Yes, you'll want to know if
> >something goes wrong, but do you need it in the queue name ?
> >
> >Steve.
> >
> >-----Original Message-----
> >From: Robert Broderick [mailto:[EMAIL PROTECTED]
> >Sent: 14 July 2003 12:15
> >To: [EMAIL PROTECTED]
> >Subject: Re: Questionable MQ infrastructure design
> >
> >
> >The Queue name I push when we a developing infrastructure is
> >SendingApp.ReceivingApp.AnythingYouWant
> >
> >Channels are generic-ly Sender.Receiver with variations considered for
> >multiple QMGRS on the same box and testing cyclye (eg SandBox, Dev,
SIT,
> >UAT, QA, Prod, DR)
> >
> >
>bobbee
> >
> >
> > >From: [EMAIL PROTECTED]
> > >Reply-To: MQSeries List <[EMAIL PROTECTED]>
> > >To: [EMAIL PROTECTED]
> > >Subject: Re: Questionable MQ infrastructure design
> > >Date: Sun, 13 Jul 2003 18:01:36 +1000
> > >
> > >Hi,
> > >
> > >We have a similar name scheme for channels except much shorter....
> >SRC_DST
> > >and optionallyPROD_SRC_DST, not by application though.
> > >
> > >For queues,we normally use a qualifier on the end of the queue
>name/type
> > >for
> > >the type of data i.e.
> > >
> > >ie app_type.pgp (PGP encrypted data)
> > >app_type_subtype.xml
> > >
> > >etc
> > >
> > >Same goes for Transmission queues and initiation queues
> > >
> > >app_process.initq
> > >app_process.txq
> > >
> > >I think you can see the pattern..
> > >
> > >
> > >Sid
> > >
> > >
> > >
> > >-----Original Message-----
> > >From: Armand ten Dam [mailto:[EMAIL PROTECTED]
> > >Sent: Thursday, 10 July 2003 10:58 AM
> > >To: [EMAIL PROTECTED]
> > >Subject: Questionable MQ infrastructure design
> > >
> > >
> > >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&referr
>
> >
>
>al=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
> > >
> > >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
> >
> >_________________________________________________________________
> >Add photos to your e-mail with MSN 8. Get 2 months FREE*.
> >http://join.msn.com/?page=features/featuredemail
> >
> >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
> >
> >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
>
>_________________________________________________________________
>Help STOP SPAM with the new MSN 8 and get 2 months FREE*
>http://join.msn.com/?page=features/junkmail
>
>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
>
>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
_________________________________________________________________
Help STOP SPAM with the new MSN 8 and get 2 months FREE*
http://join.msn.com/?page=features/junkmail
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
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
_________________________________________________________________
Help STOP SPAM with the new MSN 8 and get 2 months FREE*
http://join.msn.com/?page=features/junkmail
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
