a tip for the loopback testing. I do this all the time to prove the MQ network is up. I don't bother telling the other side to create a remote queue def.
Instead, I send a message to a bogus queue name on their QM, and I set the report options to discard (so no message goes to their DLQ), plus Exception with full data (so I get a report message back, proving the round trip) and COA with full data (just in case they made a queue called "zjn4n329r2on0bfiowbu1"). I set the reply to info appropriatly. In this fashion, I can test without them even knowing, and I don't have to rely on the other side for setting up any queues (other than the transmit queue back to me). -----Original Message----- From: Wyatt, T. Rob [mailto:[EMAIL PROTECTED] Sent: Friday, March 12, 2004 9:02 AM To: [EMAIL PROTECTED] Subject: Re: RCVR versus RQSTR channels Michael, We don't get a lot of Production Support calls. We did when the group was first formed (in fact that's why the group was formed) but over the years we've tuned the WMQ network quite well and trained the developers on the use of WMQ to the point that we have very few problems and they are usually not actual MQ problems but application or administrative problems. So it's not like we have anything better to do when the call comes in! Production support is our number one priority and if a WMQ interface is down for whatever reason at least one of our analysts is on the problem until service is restored, working in shifts 24x7 if necessary. In addition to using RQSTR channels, we also insist our business partners set up QRemotes so we can send loopback messages over the channels to test them. This gives us limited visibility to check the health of their WMQ network. If the outage touches WMQ at all, we are in for the duration so we have a very strong incentive to minimize the outage time. By extending our infrastructure and visibility into the edges or first layer of the 3rd party MQ network, we are in an excellent position to perform early diagnostics while the help desk and or second tier at the third party are still getting pulled into the call. We would be foolish to have these capabilities and not use them when it's our customers and our money that are at risk. -- T.Rob -----Original Message----- From: Michael Dag [mailto:[EMAIL PROTECTED] Sent: Friday, March 12, 2004 12:41 AM To: [EMAIL PROTECTED] Subject: Re: RCVR versus RQSTR channels Rob, good points! but then you are doing the pre-Problem detirmination for your 'business' user who is expecting something and working from taget to source. I always tell my 'business' user if they did not get what they expected to call their 'business' user supplier (aka the sender party) and track the message from the source to the target. 99% of the cases it's a situation like 1) and 2) you described only this time it's the companies 'business' user calling their own helpdesk or support group and he/she often is known to that group. AND most importantly keeps my support group free of unneccessary calls as often they can't do anything but just 'narrowing' down the problem and passing on the call... Michael 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 This communication, including attachments, is for the exclusive use of addressee and may contain proprietary, confidential 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 email and delete this communication and destroy all copies. 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
