T.Rob, The move away from using IP address in the channel status record to using the Queue Manger name was for two reasons.
1. Many people have two (or more) Queue Managers on the same machine. Clearly these should be given a different keys from a channel synchronisation point of view. The IP address is therefore not suitable for this. 2.Quite a number of people use DHCP. This means that each time you reboot your machine you're not guaranteed to get the same IP address and so, again, the IP address is not suitable as a long term key. Your last paragraph concerns me though. This change from IP address to Queue Manager name in the sync record took place, I think, in 5.1. Definitely a few releases ago. I was not trying to indicate a change that was coming in the future. Cheers, Paul. Paul G Clarke WebSphere MQ Development IBM Hursley MQSeries List <[EMAIL PROTECTED]> wrote on 28/06/2004 19:31:31: > Paul, > > No, I think you got the point ok but I was labouring under false > assumptions. The QMID provides a key that is reasonably guaranteed to be > unique and I made a leap in assuming IBM would favor it over the QMgr name > where uniqueness is a requirement. The point in your email that struck me > was the statement that "CONNAME may be the machine address or more likely > nowadays the remote Queue Manager name". It just seemed weird that the move > would be away from the IP address/machine name which is more or less > guaranteed to be unique (at least in a TCP/IP network) to the QMgr name > which is unique only by convention. > > I have some clients who do have duplicate QMgr names (not my choice) for > their contingency QMgrs. It shouldn't cause a problem in normal operations > but it will mean that their DR testing will need to include tasks to reset > channel sequence numbers before and after, once they upgrade to the latest > version/CSD. Since I can tell them this is coming, it won't be perceived as > a failure of the upgrade or the DR test. > > -- T.Rob > > -----Original Message----- > From: MQSeries List [mailto:[EMAIL PROTECTED] Behalf Of Paul > Clarke > Sent: Monday, June 28, 2004 12:38 PM > To: [EMAIL PROTECTED] > Subject: Re: FW: MQ Administration query > > > T.Rob, > > I'm not sure what you're getting at here. The Channel Status Saved > information will always show the remote Queue Manager name not the QMID. > The QMID is not as user friendly. > > The QMID was introduced for clustering to allow the cluster to distinguish > between definitions made by two Queue Managers with the same name. This was > really to allow a Queue Manager to be deleted and redefined with the same > name rather than to allow a network to be defined with two (or more) Queue > Managers with the same name. I would always strongly recommend to anyone > using MQ to ensure that their Queue Manager names are unique. > > Did I miss your point ? > Cheers, > P. > > Paul G Clarke > WebSphere MQ Development > IBM Hursley > > > MQSeries List <[EMAIL PROTECTED]> wrote on 28/06/2004 16:46:48: > > > Paul, > > > > Just curious - I thought the direction was to use the QMID rather than > the > > QMgr name. Is this not the case with channel status info as described > > below? > > > > Thanks -- T.Rob > > > > -----Original Message----- > > From: MQSeries List [mailto:[EMAIL PROTECTED] Behalf Of Paul > > Clarke > > Sent: Friday, June 25, 2004 7:38 AM > > To: [EMAIL PROTECTED] > > Subject: Re: FW: MQ Administration query > > > > > > > > > > > > > > Yvette, > > > > I'm afraid my answers to Bharath questions would have been somewhat > > different. > > > > > > > > Scenario 1 : When you repoint your sender chl connectivity to a different > > machine. Currently, the remote Q Mgr is not running. Would a reset on my > > sender chl make an impact in the receiver chl, if do a reset now > (Remember > > the Remote Q Mgr is not running) and bring up the remote Q Mgr later. > > > > > > Answer: If you issue a RESET CHANNEL on a Sender it will have no effect > > until the channel actually starts. When it does, the RESET will happen on > > the receiver after any indoubt transactions are resolved but before any > > messages are transferred. A RESET on the Sender end only should be > > sufficient (it should not be necessary to issue a RESET on a receiver > > unless you're using an old or odd QM). The receiver channel should switch > > to whatever sequence number the sender has been reset to. In an ideal > world > > one would never have to ever issue a RESET on a receiver. > > > > > > Scenario 2: Ideally you would like every sender to possess a > corresponding > > receiver. Now in our scenario, we have 1 receiver in my Q Mgr listening > to > > 3 sender chls from 3 different Q Mgrs. Now how would a reset operation in > > one of the sender chls impact the receiver or other sender chls? Also, > how > > does the Seq numbers become now in all the Q Mgrs. > > > > > > Answer: It is perfectly reasonable and often desirable to have a single > > receiver channel definition receiving messages from many different Queue > > Managers. The sequence number is maintained per remote partner. If you do > a > > DIS CHS(*) SAVED you'll see many entries for the same channel but with > > different CONNAMEs. Note that CONNAME may be the machine address or more > > likely nowadays the remote Queue Manager name. When you're using > 'generic' > > receivers like this issuing a RESET CHANNEL on the receiver is > > non-deterministic because MQ doesn't know which instance of the receiver > > channel you're intending. In fact it's a race. The first receiver channel > > to start with get the new sequence number. This is another reason why we > > recommend you don't issue RESET channel on receivers. However, in this > > environment issuing RESET on the senders is perfectly fine because, as I > > said, we maintain a completely separate record for each Sender/Reciver > > pair. Therefore issuing RESET on one sender/receiver pair should have no > > effect on any other sender/receiver pair. Of course, this is assuming > that > > each sender is running on a Queue Mangager with a different name but then > > no one would be daft enough to define two (or more) different Queue > > Managers in their network with the same Queue Manager name right ? :-) > > > > > > Cheers, > > > > > > P. > > > > Paul G Clarke > > WebSphere MQ Development > > IBM Hursley > > > > > > 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
