Well, I am definitely getting more than I asked for with the quality of
answers in this thread! Thanks Paul.
The problem with these great explanations is that they answer my
doubts, teach me things I didn't know and... raise more questions!
I am on WMQ 5.3.1, so let me understand the options I have if the
channel is connected to a qmgr that is not the destination (RQMNAME)
qmgr:
1) Define a qmgr alias in all the 'other' qmgrs in the QSG.
2) Route the message to the destination qmgr using IGQ.
3) Route the message to the destination qmgr using a 'conventional'
channel (yes, I know it sounds stupid, I am just trying to understand
my options).
Is this correct?
TIA.
By the way, "IGQ double-hop avoidance" sounds
really fancy...
Heinz
Paul S Dennis wrote:
Heinz,
In response to your question:
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?
The answer is it depends!! What
version
of MQ are you using on z/OS? If you are at V5.3.1 then if the RQMNAME
is
set to a specific queue manager it would have to be delivered to that
qmgr
first before it will be put onto the shared queue (even if the shared
channel
was coming into a different qmgr in the qsg). This obviously is a bit
of
an availability issue if that qmgr isn't available. In V6.0 a feature
was
added that will enable the message to be placed directly onto the
shared
queue, even if the shared channel is connected to a different queue
manager.
You need to enable this functionality though, as it is not the default
behaviour. Have a look at the SQQMNAME qmgr attribute. This defaults to
USE, which basically says to use the qmgr name when resolving the open
of a shared queue. If you set the value to IGNORE then if you have a
message
that comes in over a shared channel where the RQMNAME is another qmgr
in
the qsg, and the RNAME is a shared queue, then the open will resolve to
directly opening the shared queue. This feature is not limited to just
channels, there are circumstances with locally connected applications
using
shared queues that would benefit, paricularly in a request/reply model
where the reply queue is shared.
In the development group here this
new
feature was affectionately called "IGQ double-hop avoidance".
Thanks
Paul
Paul Dennis
WebSphere MQ for z/OS Development
IBM Hursley
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
No virus found in this incoming message.
Checked by AVG Free Edition.
Version: 7.1.409 / Virus Database: 268.13.32/523 - Release Date: 07-Nov-06
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
|
