Here is something that I think would be easy to implement When you do a MQTrace, would it not be nice to have an index of Process name, PID and TID so you can easily match the .trc file to the correct process?
________________________________ Hatcher Jeter ________________________________ CONFIDENTIALITY NOTICE: This e-mail message, including any attachments, is for the sole use of the intended recipient (s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message ________________________________ -----Original Message----- From: MQSeries List [mailto:[EMAIL PROTECTED] On Behalf Of Potkay, Peter M (ISD, IT) Sent: Thursday, February 14, 2008 9:34 AM To: [email protected] Subject: Re: Wish List for the next version of MQ T-Rob, But that calls for putting and getting apps to be Pub Sub aware. RFH2 headers....<shudder>. I'm wishing for a way to be able to duplicate point to point messages at the MQ Admin level with no changes to the apps. Peter Potkay -----Original Message----- From: MQSeries List [mailto:[EMAIL PROTECTED] On Behalf Of T-Rob Sent: Wednesday, February 13, 2008 5:34 PM To: [email protected] Subject: Re: Wish List for the next version of MQ I think WMQ calls that a durable subscription. :-) -- T.Rob MQSeries List <[email protected]> wrote on 02/13/2008 04:58:42 PM: > Hi Peter, > > For those of us who have been forced to gain familiarity with other > Messaging Oriented Middleware (MOM) products, this 'feature request' is a > very close match for a capability implemented in Tibco EMS. EMS calls it a > bridge. It allows messages (optionally selected via SQL92 syntax operating > on the message header and properties, but not the body) to be copied from a > queue or topic onto any number of other queues or topics. Because it is > embedded in the messaging provider, it happens without security > intervention, and without knowledge of the sending application. Different > targets can select different subsets of messages via the selectors. > > The sender puts the message to the initial destination. Security is > checked, and control returns if the put is successful. After a successful > put, the messaging provider does it's best effort at following the bridge > specification. If something fails (queue full, queue name unknown or > whatever) this gets reported on an error log, but otherwise ignored. > > It is fairly simple to implement a small broker in MQ to achieve the same > thing. You have an application which puts a message to a queue. The > destination application(s) do not read that queue directly, but read from a > separate queue. In the middle, a program reads the message from the source > queue, and writes it to as many destinations as are configured. > Configuration can be via a properties file, a database entry, a Namelist or > whatever. In the past I have seen this done with a namelist which has the > same name as the source queue. Each destination queue is then named in the > namelist. The broker program can be long running, triggered on first, or > triggered and the long running, depending on requirements. > > For production migration, you can continue to use the same technique, or > you can change the initial local queue which the broker reads into a qalias > pointing to the single destination queue, meaning that your applications > don't change, but you get better performance because you avoid the message > copy overhead. > > If you want to get smarter again, you could implement some sort of content > based routing in the broker. > > Regards, > > Neil C. > ________________________________________________________________________ ____________________________________ > > Neil Casey| Lead Technical Specialist - Systems Management Group | Atlas > Technology Services | nabCapital? | A division of National Australia Bank > Limited > Office: +61 3 8641 1068 | Mobile: 0438 573 152 | Fax: +61 3 8641 4699 | > Email: [EMAIL PROTECTED]| Location: Level 24, 500 Bourke Street, > Melbourne > Intranet Portal: > http://intranet.global.thenational. > com/Units/Services/Technology/ATLAS/AppSer/SysMan/Pages/default.aspx > > > > > "Potkay, Peter M > (ISD, IT)" > <[EMAIL PROTECTED] To > HARTFORD.COM> [email protected] > Sent by: MQSeries cc > List > <[EMAIL PROTECTED] Subject > V.MEDUNIWIEN.AC.A Re: Wish List for the next version > T> of MQ > > > 02/14/2008 02:16 > AM > > > Please respond to > MQSeries List > <[EMAIL PROTECTED] > V.MEDUNIWIEN.AC.A > T> > > > > > > > Its surprising how many times this question gets asked on mqseries.net. > Almost weekly. I have the same "problem" here too every once in a while. > How do I copy every message that gets put into QueueA into QueueB. > Basically the user wants one MQPUT to go to 2 or more queues. This is > almost always done in the development environments, usually to provide a > logging type service so Developer A can prove to Developer B what they > sent. But sometimes you really do need to send one message to 2 or more > queues. > > The first answer of course is to use a Distribution List or to do > multiple MQPUT1s. But there are a couple of drawbacks to this. First, it > presumes you want this multiple put behavior to propagate into > production (assuming no code changes) which in my experience is rarely > the case. Second its not easy to add or remove queues to the list > without code changes as you want to modify this behavior within an > environment. > > I wish there was a way for an MQ Admin to be able to replicate MQ > messages using the base product. I don't want to fiddle with exits. > Maybe a "Multi" Alias queue. The MQ Admin can then alter the q def to > aim at however many other queues he needs to. The only tricky thing here > is how would the scenario where one underlying MQOPEN / MQPUT worked but > one of them failed. Somehow the app would need to be notified of that. A > single MQRC no longer suffices. Er, my idea is fizzling as I type it. > But maybe there is way to solve this. > > > Peter Potkay > > > -----Original Message----- > From: MQSeries List [mailto:[EMAIL PROTECTED] On > Behalf Of Meekin, Paul > Sent: Wednesday, February 13, 2008 3:33 AM > To: [email protected] > Subject: Re: Wish List for the next version of MQ > > (Sorry - thought I'd sent this earlier - still, better late than never!) > > That reminds me of another one: > > - An API to allow Channel Exits to put messages to the AMQERR01.LOG > file. > > Cheers, > Paul > > > -----Original Message----- > From: MQSeries List [mailto:[EMAIL PROTECTED] Behalf > Of T-Rob > Sent: 08 February 2008 16:17 > To: [email protected] > Subject: Re: Wish List for the next version of MQ > > > One more to add to this list... > > How about adding a comment field to endmqm? The comment would then be > recorded into the log files. > > endmqm -i MYQMGR -c "Applying maintenance - FP 6.0.2.3" > endmqm -i MYQMGR -c "Testing HA Failover" > endmqm -i MYQMGR -c "Shutting down for decommission - DO NOT RESTART!!!" > > Then if someone looked in the log files this comment would be toward the > end. Shutdown scripts would embed a similar comment "QMgr shut down by > the system". There would be a new AMQ????? message code that > essentially said "user supplied message". > > This one's so easy can we maybe get it in the next fix pack? > > -- T.Rob > > To unsubscribe, write to [EMAIL PROTECTED] and, in the > message body (not the subject), write: SIGNOFF MQSERIES Instructions for > managing your mailing list subscription are provided in the Listserv > General Users Guide available at http://www.lsoft.com > Archive: http://listserv.meduniwien.ac.at/archives/mqser-l.html > > To unsubscribe, write to [EMAIL PROTECTED] and, in the > message body (not the subject), write: SIGNOFF MQSERIES Instructions for > managing your mailing list subscription are provided in the Listserv > General Users Guide available at http://www.lsoft.com > Archive: http://listserv.meduniwien.ac.at/archives/mqser-l.html > > > ************************************************************************ * > This communication, including attachments, is > for the exclusive use of addressee and may contain proprietary, > confidential and/or privileged information. If you are not the intended > recipient, any use, copying, disclosure, dissemination or distribution is > strictly prohibited. If you are not the intended recipient, please notify > the sender immediately by return e-mail, delete this communication and > destroy all copies. > ************************************************************************ * > > To unsubscribe, write to [EMAIL PROTECTED] and, > in the message body (not the subject), write: SIGNOFF MQSERIES > Instructions for managing your mailing list subscription are provided in > the Listserv General Users Guide available at http://www.lsoft.com > Archive: http://listserv.meduniwien.ac.at/archives/mqser-l.html > > > National Australia Bank Ltd - ABN 12 004 044 937 > This email may contain confidential information. If you are not the intended > recipient, please immediately notify us at [EMAIL PROTECTED] or > by replying to > the sender, and then destroy all copies of this email. Except where this email > indicates otherwise, views expressed in this email are those of the > sender and not > of National Australia Bank Ltd. Advice in this email does not take > account of your > objectives, financial situation, or needs. It is important for you > to consider these > matters and, if the e-mail refers to a product(s), you should read > the relevant > Product Disclosure Statement(s)/other disclosure document(s) before making any > decisions. If you do not want email marketing from us in future, > forward this email > with "unsubscribe" in the subject line to [EMAIL PROTECTED] > in order to > stop marketing emails from this sender. National Australia Bank Ltd does not > represent that this email is free of errors, viruses or interference. To unsubscribe, write to [EMAIL PROTECTED] and, in the message body (not the subject), write: SIGNOFF MQSERIES Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://listserv.meduniwien.ac.at/archives/mqser-l.html To unsubscribe, write to [EMAIL PROTECTED] and, in the message body (not the subject), write: SIGNOFF MQSERIES Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://listserv.meduniwien.ac.at/archives/mqser-l.html To unsubscribe, write to [EMAIL PROTECTED] and, in the message body (not the subject), write: SIGNOFF MQSERIES Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://listserv.meduniwien.ac.at/archives/mqser-l.html
