Re: Remote queue pointing to a QSG

[Heinz Klein]

Dave. You may not have answered my questions specifically, but your explanation is a great lesson in 'distributed' QSG that covers many of my doubts - great text. To the side issue, our messages are all persistent (financial transactions...) so the QSG's overhead is not so high. Now to the specific questions, please clarify one point of your explanation: I was assuming, from the beginning, that the sender channel (Win >> z/OS) would point to the QSG and enjoy all the benefits provided by this approach - which includes being connected to any qmgr in the group. In other words, assuming my RQMNAME still point to a specific qmgr, I can never count on the sender channel being connected to this qmgr. Given these conditions, are you saying that the other qmgrs (or the receiver channels on these qmgrs) in the group will have, without further intervention (alias or other object defintions), the ability to figure out that a message directed to another qmgr in the group should be placed into the shared queue with the same name as the queue referenced in the transmission header? Thanks again for the help. Heinz Dave Corbett wrote: Heinz, Shared queues in a z/OS environment are a great concept and I use them extensively - but there is a MIPS cost, especially if you are currently using non-persistent messaging. The issue is that messages almost become persistent when they exist in shared queues (they survive QMGR restarts, but not coupling facility list structure failures). If you had already been using persistent messages, the increase in MIPS usage is not as noticeable. With that being said, I think you should change the RQMNAME to point to the QSG, but it is not absolutely necessary to make it work. If you redefine the resolved local queue to be a shared queue (i.e. the queue specified in the RNAME parameter of the remote queue def), as long as the RQMNAME points to a QMGR that is part of that QSG, the message will be placed in the shared queue. However, I would suggest that you change the RQMNAME to be the QSG name so that you are consistent with shared architecture implementations. I have found that when you try to use shared queues, it is best to not mix shared concepts with non-shared concepts. So, you should also have your sender channel connect to the QSG instead of to a specific QMGR in a QSG. For example, If you leave everything alone, and just change the RNAME on the remote queue def to point to a shared queue, and your channel is connected to a QMGR in that QSG, then everything will work fine. But then you are not taking full advantage of the high availability of a QSG. The sender channel itself should point to the QSG which would then use sysplex distributor logic to route the connection to a QMGR in the QSG based on the health of the LPARs involved. Therefore, if the LPAR (or the QMGR on that LPAR) that is currently hosting the channel connection goes down, the channel retry will reconnect you to another QMGR in that QSG and you will at most just notice a blip while the reconnection occurs. I probably did not answer your specific questions, but spouted off anyway.. (-: Thanks, David Corbett IBM Certified System Administrator -- WebSphere MQ V6.0 IBM Certified Solution Designer -- WebSphere MQ V6.0 List Archive - Manage Your List Settings - Unsubscribe Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com