| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| Problem with SYTEM.COMMAND.REPLY.MODEL queue |
« View previous topic :: View next topic » |
| Author |
Message
|
| mqrules |
 Posted: Wed Feb 08, 2006 10:42 am Post subject: Problem with SYTEM.COMMAND.REPLY.MODEL queue |
 |
|
Centurion
Joined: 01 Jun 2005
Posts: 100
Location: US
|
Hi all,
Z/OS MQ 5.3.
I have 2 qmgrs MQA1 and MQA2. they are not clustered. There are sdr-rcvr channels between them. Transmission queues are Persistent. As there are a lot of orphaned qmgr.CSQOREXX.* permanent reply queues on both qmgrs, I modified the SYSTEM.COMMAND.REPLY.MODEL from PERM to TEMP dynamic. After this change I could not get to MQA2 via MQA1 and vice versa in CSQOREXX (by putting an "*" in the 'Action Queue Manger " filed. Reply messages from the commands went to the DLQ with the reason being that Persistent messages could not be put on Temp Dynamic queue. I figured the utility program inherits the persistence of the xmit queue (which is persistent).
I tried to do some testing in the test environment. I was expecting that if I changed the Default persistence to non-persistent, I will be OK. However, I don't have 2 qmgrs in the test environent that are not clustered. So, here is the environmnet I did the testing:
QMB1 and QMB2 are in a cluster. They also have the point-to-point channels:
On QMB1: SDR channel : QMB1.QMB2
xMIT Q: QMB2 (Default persistence is Persistent)
On QMB2: SDR channel : QMB2.QMB1
xMIT Q: QMB1 (Default persistence is Persistent)
SCTQs are also Persistent.
In this scenario, I expected the manually defined channels to be used (as opposed ot the cluster ones).I modified the SYSTEM.COMMAND.REPLY.MODEL from PERM to TEMP dynamic on both qmgrs. This change had no impact, in that, in CSQOREXX I can get to one qmgr from the other (by putting an "*" the "Action queue manager" field of the panel). How come? I expected the reply messages to go to the DLQ? I think I am missing something. Any ideas would be much appreciated.
TIA
mr |
|
| Back to top |
|
 |
| HubertKleinmanns |
| Posted: Wed Feb 08, 2006 10:55 am Post subject: |
|
|
Shaman
Joined: 24 Feb 2004
Posts: 732
Location: Germany
|
What you use is Request / Reply. In such cases the reply messages are addressed to a QMgr somewhere in the network. In a MQ cluster environment a QMgr "knows" about other cluster QMgrs because of the cluster mechanism. So MQ decides, which way to go, to reach the target QMgr.
For example you could create a remote queue without having a manually defined XmitQ and MQ will put the message to the cluster XmitQ.
Does this answer your question?
_________________
Regards
Hubert |
|
| Back to top |
|
|
| mqrules |
| Posted: Wed Feb 08, 2006 11:06 am Post subject: |
|
|
Centurion
Joined: 01 Jun 2005
Posts: 100
Location: US
|
Hubert,
This is in the mainframe CSQOREXX panels where you admin the objects. Forinstance you connect to MQB1 and specify Target qmgr = MQB1, and Action Qmgr = *. Becasue there are channels in between MQB1 and MQB2, when I want to say display qlocals I specify Obejct Type= Qlocal, Obejct Name= *, and I get all the qlocals for both MQB1 and MQB2.
MR |
|
| Back to top |
|
|
| HubertKleinmanns |
| Posted: Wed Feb 08, 2006 11:31 am Post subject: |
|
|
Shaman
Joined: 24 Feb 2004
Posts: 732
Location: Germany
|
MR,
the CSQOREXX panels first create a dynamic queue. Then the panels set up a command message and add the dynamic queue into the ReplyToQmgr field of the MQMD. This command message has to be send to the target QMgr and put to the queue SYSTEM.COMMAND.INPUT. A command server (or however it's named on z/OS) has to read this message, to execute the command and put the output to the reply queue (the dynamic queue above). This answer is a reply message and though it's addressed first to the origin QMgr (where you run your ISPF panel). MQ finds a way (cluster channel), because both QMgrs are member of the same cluster. When the message arrives on the origin QMgr, it is put to the dynamic queue created above.
You have a timeout, which is set in your CSQOREXX panel, which defines, how long the panel waits for the reply message. If this timeout exceeds before the answer arrives, the reply queue will be deleted (when it is temporary dynamic) and the request is put to the DLQ. If the queue is permanent dynamic, the queue will stay alive and the requests are put to this queue - but nobody is interessted to read these messages.
_________________
Regards
Hubert |
|
| Back to top |
|
|
|
|
|
| |
|
Page 1 of 1 |
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
|
|
