| Author |
Message
|
| gidish |
 Posted: Sun Dec 23, 2007 7:00 am Post subject: IMS transaction down |
 |
|
Novice
Joined: 18 Jul 2007
Posts: 18
|
Hi.
i have a problen with the following scenario:
a message arrives at a QM on the MF, to an OTMA queue,
but the intended transaction is currently down.
so the message arrives at the queue, but then goes to the DLQ, with reason code 326 (IMS sence code 26)
is there a way to retry putting the message on the OTMA queue until the transaction goes back up , with a reasonable retry interval, without writing code ??
in other words:
can i retry putting the message every 1 minute, without writing code ??
help ???
thank's ,
gidi. |
|
| Back to top |
|
 |
| LuisFer |
| Posted: Mon Dec 24, 2007 2:30 am Post subject: Re: IMS transaction down |
|
|
Partisan
Joined: 17 Aug 2002
Posts: 302
|
| gidish wrote: |
Hi.
i have a problen with the following scenario:
a message arrives at a QM on the MF, to an OTMA queue,
but the intended transaction is currently down.
so the message arrives at the queue, but then goes to the DLQ, with reason code 326 (IMS sence code 26)
is there a way to retry putting the message on the OTMA queue until the transaction goes back up , with a reasonable retry interval, without writing code ??
in other words:
can i retry putting the message every 1 minute, without writing code ??
help ???
thank's ,
gidi. |
326 - Tran/Lterm Stopped
| Quote: |
can i retry putting the message every 1 minute, without writing code ??
. |
I don't know if CSQUDLQH utility can do this one ( i think that is not able to do it)
Regards |
|
| Back to top |
|
|
| gidish |
| Posted: Mon Dec 24, 2007 4:02 am Post subject: |
|
|
Novice
Joined: 18 Jul 2007
Posts: 18
|
hi.
actually i already tried DLQH, and it should be able to do it , but there is a problem:
it tries to put the message back to the destination queue, and succeeds , but then OTMA returns the message to the DLQ with the same reason code (cause the transaction is still down).
now what happens is that there is a very intensive loop that consumes the hole storage space and crushes MQ.
i think it's cause the DLQH thinks it's a new message (not the same one from before) and the retry interval is irrelevant here.
is there another way ? |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Mon Dec 24, 2007 8:57 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
Create a different initq and run the trigger monitor for the transaction only if the IMS transaction is running... 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| gidish |
| Posted: Tue Dec 25, 2007 4:54 am Post subject: |
|
|
Novice
Joined: 18 Jul 2007
Posts: 18
|
hi.
i didn't quite understand you..
i am not corrently using a trigger monitor,
i'm using OTMA.. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Tue Dec 25, 2007 5:04 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| gidish wrote: |
hi.
i didn't quite understand you..
i am not corrently using a trigger monitor,
i'm using OTMA.. |
And OTMA is not acting like a trigger monitor??
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| gidish |
| Posted: Tue Dec 25, 2007 9:52 pm Post subject: |
|
|
Novice
Joined: 18 Jul 2007
Posts: 18
|
in a way , it does, but how can i do this:
| Quote: |
| run the trigger monitor for the transaction only if the IMS transaction is running |
?
and, even if i could, would it be wise to shut down OTMA for the hole environment if only one of the transactions is down ?
it would meen (as far as i understand) that IMS will be unreachable for any transaction.
 |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Wed Dec 26, 2007 5:48 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| fjb_saper wrote: |
| Create a different initq and run the trigger monitor for the transaction only if the IMS transaction is running... |
Is it not possible to run multiple instances of the trigger monitor (OTMA) in your environment?? 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| LuisFer |
| Posted: Wed Dec 26, 2007 6:29 am Post subject: |
|
|
Partisan
Joined: 17 Aug 2002
Posts: 302
|
The OTMA is the IMS side of MQ-IMS brigde (and Other as IMS CONNECT).
It is not a trigger Monitor.
I think that is not possible to reenq the Tx without write code or customized CSQUDLQH.
A solution should can be put the GET disabled of the OTMA queue during the STOP interval, the message stay on queue towards ENABLED the GET when Tx is started newly.
This is a problem if the OTMA queue is shared with other IMS Tx (the most normal situation) and Request/Reply message.
Regards
Last edited by LuisFer on Wed Dec 26, 2007 6:37 am; edited 2 times in total |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Wed Dec 26, 2007 9:58 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| LuisFer wrote: |
The OTMA is the IMS side of MQ-IMS brigde (and Other as IMS CONNECT).
It is not a trigger Monitor.
I think that is not possible to reenq the Tx without write code or customized CSQUDLQH.
A solution should can be put the GET disabled of the OTMA queue during the STOP interval, the message stay on queue towards ENABLED the GET when Tx is started newly.
This is a problem if the OTMA queue is shared with other IMS Tx (the most normal situation) and Request/Reply message.
Regards |
Luis, if the OTMA does not act as a trigger monitor, does it act as a consumer?
The question stands. If it is possible to isolate that transaction on it's own queue, is it possible to run 2 (or multiple)instances of OTMA concurrently (on different queues)?
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Wed Dec 26, 2007 1:13 pm Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
We have the same (annoying) problem here. Messages come into the TCODE via the green screens and via the OTMA bridge. If the TCODE is abending or temporarily stopped (thru no fault of the MQ message coming in via OTMA), the OTMA puts the message to the DLQ.
When we find a message in the z/OS DLQs with a Reason Code of 326 I don't even bother checking the OTMA Sense code. I replay the message and 9 out of 10 times it works because the TCODE is running again.
For known down times of the TCODES we GET Inhibit the Bridge queues. Incoming MQ transactions q up in the MQ q. Once IMS is fully up we get enable the MQ queues and the OTMA instantly sucks them out of the MQ queue and into the IMS queue.
I was looking at using the Dead Letter Handler to automatically replay messages for the sporadic problems during the day, but the problem is the Reason Code in the DLH is going to be the same for a lot of various reasons that prevents the OTMA from successfully deleivering the message (like TCODE unknown). So my Dead Letter Handler would just spin on those messages retrying them over and over.
So far this is just a minor problem that happens once every few days. To bad the OTMA Bridge didn't put more spefic reason codes in the DLH. Hmmmm, me thinks this is an enhancement request.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Wed Dec 26, 2007 1:15 pm Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
| fjb_saper wrote: |
Luis, if the OTMA does not act as a trigger monitor, does it act as a consumer?
|
Yes, that's a better way to view it. The OTMA Bridge MQ queues are open for input all day long by the OTMA. As soon as message hits its consumed. There is no triggering or polling happening.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| LuisFer |
| Posted: Wed Dec 26, 2007 10:33 pm Post subject: |
|
|
Partisan
Joined: 17 Aug 2002
Posts: 302
|
| Quote: |
Luis, if the OTMA does not act as a trigger monitor, does it act as a consumer?
|
Yes, OTMA opens the queue(s) (on exclusive GET mode) to pass the message to the IMS queue. The message is prefixed with a special MQ Header (IIH). From this header OTMA generates the necesary to convert the MQ message to a IMS tx.
The difference between the MQ bridge and the trigger is the need for a BMP in the middle shooting the Tx, while the OTMA is inside of the IMS Control Region.
There is also a notable difference in performance basically because the IMS trigger Monitor OPEN / CLOSE the Queue in every message (TX).
| Quote: |
The question stands. If it is possible to isolate that transaction on it's own queue, is it possible to run 2 (or multiple)instances of OTMA concurrently (on different queues)? |
Yes its possible isolate the Tx on 1 OTMA MQQueue.
OTMA is unique per IMS control region. It's possible to have one or a lot Queues to pass messages to one IMS (by 1 OTMA).
We have 4 IMS (4 OTMAs), one in every LPAR, and 4 (or 40, or 400) OTMA MQQueues (one per OTMA-IMS) and only 1 Alias Cluster Queue (in every QMgr -we have 8 zQMgrs -) targeted to one IMS for all IMS TX Aplications
If this IMS is down (or degradated) we change de TargetQ to another OTMAQueue pointing to the second (or thirth, or fourth) IMS whith a simple "adhoc" program (wonderful XCF) in less 3 seconds.
Five years , a lot of IPLs , some IMS downs, unavailability 0%.
Sorry for my english, hope this help you |
|
| Back to top |
|
|
| gidish |
| Posted: Thu Dec 27, 2007 5:31 am Post subject: |
|
|
Novice
Joined: 18 Jul 2007
Posts: 18
|
hi all !
first of all , thank you all for the responses. 
luis:
is it posible to inhibit the GET on the MQqueue if aTRANSACTION is down , istead of "if the IMS is down" ?
another thing:
is there any chance that you can send me or post here a sample of the code that outomaticly inhibits GET when IMS is down ?
thank's
gidi. |
|
| Back to top |
|
|
| LuisFer |
| Posted: Thu Dec 27, 2007 6:46 am Post subject: |
|
|
Partisan
Joined: 17 Aug 2002
Posts: 302
|
| Quote: |
is it posible to inhibit the GET on the MQqueue if aTRANSACTION is down , istead of "if the IMS is down" ?
|
Yes, but you need to know the state of the Tx. How?, send the IMS command /dis tran <TxName> (by a MQ OTMA Message for example)
| Quote: |
is there any chance that you can send me or post here a sample of the code that outomaticly inhibits GET when IMS is down ?
|
Inhibit Get when IMS is down is not necessary (There is not IMS, there is not OTMA reading the MQQueue) , we change the targetQ from AliasQ to other IMS-OTMA-MQQueue.
Give me some days and i shall copy a C code here. Our code is PL/I.
My best wishes to all happy Xmas and new year to all MQers.
Feliz Navidad y prospero año nuevo a todos con mis mejores deseos |
|
| Back to top |
|
|
|
|
