Peter, Thanks for the tips. I played around with this a little but some of our vendors configure their QMgrs specifically to obfuscate QMgr resolution, especially those who host multiple clients on the same QMgr. Instead of having a QMgr alias or XMitQ with my QMgr name, they put up QRemotes with obscure (to me anyway) names but that specify the XMitQ to get to me. On these servers, basically *nothing* resolves by QMgr name and everything is explicitly resolved by QRemote. Between that and the OAM, I cannot for example bounce messages off their QMgr to hit another of their clients. It's easier for me to specify the additional QRemote than to create a dependency on an object they customarily think of as their own and which may change.
I'd prefer your method if I could use it everywhere. In fact, I think it would make a good Support Pac or contribution to Brandon's Software Repository. In your spare time, of course! :-) -- T.Rob -----Original Message----- From: Potkay, Peter M (PLC, IT) [mailto:[EMAIL PROTECTED] Sent: Friday, March 12, 2004 10:17 AM To: [EMAIL PROTECTED] Subject: Re: RCVR versus RQSTR channels 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). 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
