| Author |
Message
|
| WBI_user |
 Posted: Wed May 11, 2011 5:29 pm Post subject: Getting QTIME using a CICS program |
 |
|
Partisan
Joined: 07 Aug 2001
Posts: 386
|
| We are using MQ V7 on ZOS. We want to monitor the QTIME of a queue so that we can start additional CICS transaction automatically to handle messages on the Queue if QTIME is high. The Q is a shared Q (if that may make any doifferent). This is a new topic for us. We have looked at MQAI but it is not available on Z/OS. I think we can write a program to put a PCF message on the command queue and look at the reply. Is that the right way and the only way to do it in Z/OS ? Any other suggestion? |
|
| Back to top |
|
 |
| bruce2359 |
| Posted: Wed May 11, 2011 5:56 pm Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
A simple method of ensuring that additional instances of the consuming app (or transaction) is launched is to set TRIGTYPE(EVERY) on the request queue.
z/OS software and z/hardware is more than sufficiently robust (as compared to midrange) to easily handle the workload. A shared queue offers the opportunity for a message to be propagated into the CF, so that other z/OS instances, and instances of the consuming CICS app can consume messages quickly.
You can monitor qtime with any of the usual monitoring apps - like Omegamon; and have it take action.
Exactly what issue/problem are you experiencing now?
_________________
I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live. |
|
| Back to top |
|
|
| WBI_user |
| Posted: Wed May 11, 2011 7:11 pm Post subject: |
|
|
Partisan
Joined: 07 Aug 2001
Posts: 386
|
| Hi bruce2359, thanks for the quick response. We cannot use trigger every because the message inside the queue are coming from different branch offices and some times has sequence dependencies. For example a reverse transaction from the same branch can only be handled after the original transaction is doine. All messges from the same branch office contains the same CorrelId. So what we are doing now is trigger start a 'dispatcher transaction' (DX01) which reads the message and start a business transaction (BXC1) for each different Correl_Id it encounters. BX will read all messages from the queue that contains the Correl_Id passed by DX. This way we can cleanup message from each branch office using one transaction (BXC1). But we worry that if DX01 died for whatever reason, everything will stop working. If we see Qtime is high, we know that DX01 is probably in trouble or not running. If we start DX01 by trigger on every, we will have too many copy of DX01 running and message sequence within a branch office cannot be maintained. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Wed May 11, 2011 8:09 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| WBI_user wrote: |
| Hi bruce2359, thanks for the quick response. We cannot use trigger every because the message inside the queue are coming from different branch offices and some times has sequence dependencies. For example a reverse transaction from the same branch can only be handled after the original transaction is doine. All messges from the same branch office contains the same CorrelId. So what we are doing now is trigger start a 'dispatcher transaction' (DX01) which reads the message and start a business transaction (BXC1) for each different Correl_Id it encounters. BX will read all messages from the queue that contains the Correl_Id passed by DX. This way we can cleanup message from each branch office using one transaction (BXC1). But we worry that if DX01 died for whatever reason, everything will stop working. If we see Qtime is high, we know that DX01 is probably in trouble or not running. If we start DX01 by trigger on every, we will have too many copy of DX01 running and message sequence within a branch office cannot be maintained. |
Bad design. Unless you keep an independent log (DB) of the CorrelId's being processed and check against that log for each CorrelId you process, i.e. browse until you hit a CorrelId that is not yet being processed, you run into the possibility of multiple threads processing the same correlId or even different sides of the sysplex processing the same correlId.
If you ABSOLUTELY need messages processed in a sequence, keep a table of the current correlId, sequence # in that correlId, and processing status, post the messages as they arrive to the DB, key by correlId, sequence # and start a process that updates the status of the correlId/sequence to in process and starts the processing.
Then start from the DB until you are done with messages from that correlId, or you have a sequence jump. Update the status in batches (same UOW / retry recovery points) and save the last processed sequence with a timestamp. When stopping update sequence # status and timestamp. If the process ever dies all you may need to do is manually update the status to not processing.
Make sure to retrieve the unprocessed messages in their correlId sequence order.
Make sure to have a cleanup process to remove processed messages from the DB.
You'd also want to generate a report with non processing keys over a certain "age" with missing sequence numbers... and processes that have an old timestamp but still show processing status: potentially dead...
If you add the processId into the status table you could even check for defunct processes and reset the status as well as write a report...
Have fun 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Wed May 11, 2011 9:09 pm Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
Search here for well-behaved applications.
_________________
I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live. |
|
| Back to top |
|
|
| WBI_user |
| Posted: Wed May 11, 2011 10:48 pm Post subject: |
|
|
Partisan
Joined: 07 Aug 2001
Posts: 386
|
| Sorry, I forgot to mention that we use a DB2 table to store status flags, if a BXC1 is already started for a Correl_Id, it will not start anoither copy. So this will result in one BXC1 processing all message from one branch office in one CICS region and another BXC1 processing messages from another branch office in another region and so on. It was a design pushed down to us. I think the status table can prevent duplication. We have thought of using one queue for each branch office in which case, we can trigger start BXC1 to process all message and then terminate and wait for the next trigger. But some one just do not like the idea of having too many queues (can be over a thousands + branch offices) and some of them may not have messages for a few hours and some of them may be 100s per second. |
|
| Back to top |
|
|
| WBI_user |
| Posted: Wed May 11, 2011 10:54 pm Post subject: |
|
|
Partisan
Joined: 07 Aug 2001
Posts: 386
|
| one more point is throughput rquirement. I agreed that storing all message in DB and start processing from DB may be a cleaner way. But we feel that MQ is faster especially with messages in share queue which can be used by all CICS regions |
|
| Back to top |
|
|
| Mr Butcher |
| Posted: Wed May 11, 2011 11:07 pm Post subject: |
|
|
Padawan
Joined: 23 May 2005
Posts: 1716
|
how do you trigger dx01? first? if that is true then if dx01 dies on a non empty queue it should get re-triggered automatically by MQ if it made it till the mqopen. if it died before the mqopen, you can use trigint to make mq re-trigger it anyway. however, the best way is to monitor the qdepth, not the transaction, as it may be running but not processing messages.
_________________
Regards, Butcher |
|
| Back to top |
|
|
| WBI_user |
| Posted: Wed May 11, 2011 11:22 pm Post subject: |
|
|
Partisan
Joined: 07 Aug 2001
Posts: 386
|
| DX01 is now triggered (First). Again using a flag in the DB2 table , we only allow 1 DX01 to run. Since the Queue is shared Q. We have 2 LPARS and CKTI running in CICS on each LPAR. With trigger on first DX01 may get trigger started on both LPAR. But which ever start first will uopdate the DB2 flag. The other one will terminate when it see the flag is already on. This way we have 1 DX01 running to avoid duplication and we also have some assurrance that a copy of DX01 will be started even one of the LPAR is sick. |
|
| Back to top |
|
|
| Mr Butcher |
| Posted: Thu May 12, 2011 3:09 am Post subject: |
|
|
Padawan
Joined: 23 May 2005
Posts: 1716
|
Its quite some time i had my hands on this, but IIRC there was a difference in the number of trigger messages generated with shared or non shared initiation queues (or the trigger type) ?!? in one setup a trigger message was created for every mq in the qsg, in one setup only one trigger message was created so one mq wins and only 1 transaction is be started. but i cant remember the exact settings....
_________________
Regards, Butcher |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Thu May 12, 2011 5:29 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
| Mr Butcher wrote: |
| Its quite some time i had my hands on this, but IIRC there was a difference in the number of trigger messages generated with shared or non shared initiation queues (or the trigger type) ?!? in one setup a trigger message was created for every mq in the qsg, in one setup only one trigger message was created so one mq wins and only 1 transaction is be started. but i cant remember the exact settings.... |
When a message arrives at a shared queue, triggers fire in all interested qmgrs. The first (usually fastest) instance of the triggered application mqgets message.
_________________
I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live. |
|
| Back to top |
|
|
| Mr Butcher |
| Posted: Thu May 12, 2011 6:17 am Post subject: |
|
|
Padawan
Joined: 23 May 2005
Posts: 1716
|
IMHO if the initq was shared too, only 1 trigger message was generated. but as i said before, not sure. have to review that. i am sure i wrote it down somewhere. but it was in a former live.....
_________________
Regards, Butcher |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Thu May 12, 2011 6:38 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
| Mr Butcher wrote: |
| IMHO if the initq was shared too, only 1 trigger message was generated. but as i said before, not sure. have to review that. i am sure i wrote it down somewhere. but it was in a former live..... |
Yep. Trigger monitors on all interested qmgrs will see the trigger message. The first one to consume the trigger msg will start the consuming app.
_________________
I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live. |
|
| Back to top |
|
|
| WBI_user |
| Posted: Thu May 12, 2011 5:15 pm Post subject: |
|
|
Partisan
Joined: 07 Aug 2001
Posts: 386
|
In red book sg246864 p.231, that's what it says
Note: For TRIGTYPE=FIRST, the choice of a shared or non-shared initiation
queue is not important. In both cases, a trigger message will be generated for each instance of CKTI.
So If I have a CKTI running on CICS region from 2 LPARS, they both will start DX01 if they bith healthy. One if them will terminate if the other one sets the DB2 flag first. If one of the LPAR (Qmgr oir CICS) is sick, at least the other one will have a DX01 running.
In order to ensure that I have DX01 running, I need to monitor it. We prefer not to use external tools like Omegamon to do it because it involve the other teams for automation and it may not be fast enough to restart DX01. That's why we like to get the Qtime from within CICS and act accordingly. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Thu May 12, 2011 5:59 pm Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
| WBI_user wrote: |
In order to ensure that I have DX01 running, I need to monitor it. |
I'm a bit confused...
Is your intent to always have one instance of CICS txn DX01 running in each CICS LPAR?
Is the lack of an instance of DX01 sufficient to restart it? If so, I don't believe that you really need to look at qtime. What if DX01 is running, but qtime is increasing (for any number of reasons)? What then?
| WBI_user wrote: |
We prefer not to use external tools like Omegamon to do it because it involve the other teams for automation and it may not be fast enough to restart DX01. That's why we like to get the Qtime from within CICS and act accordingly. |
My point: you (or someone with CICS skills) could write a CICS app can scan CICS's task list, and if no DX01 is present, it can EXEC CICS START one.
_________________
I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live. |
|
| Back to top |
|
|
|
|
