| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
| Trigger Interval with Shared Queue |
« View previous topic :: View next topic » |
| Author |
Message
|
| CharlieChen |
 Posted: Wed Nov 14, 2012 12:25 am Post subject: Trigger Interval with Shared Queue |
 |
|
Novice
Joined: 24 Jun 2012
Posts: 15
|
We have 2 queue managers. All the application queues are defined as shared queues.
The trigger type is first. The init queue is defined in the queue manager (not in shared queue). The reason is we want both the CICS to process the message. If we define the init queue as shared queue, then only 1 CICS will process the application queue at any one time since only 1 trigger message is generated when the First message arrives.
We set the trigger interval to 300000 ms (5 min).
With the above set up, what would happen if both the triggered transaction in both CICS are running and the queue is continuously having messages. If one of the CICS transaction failed, would the trigger interval be able to trigger start it now that there is another transaction on another CICS processing the queue.
Thanks very much. |
|
| Back to top |
|
 |
| bruce2359 |
| Posted: Wed Nov 14, 2012 4:43 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9405
Location: US: west coast, almost. Otherwise, enroute.
|
Have you tried this? What were the results?
_________________
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 |
|
|
| bob_buxton |
| Posted: Wed Nov 14, 2012 9:14 am Post subject: |
|
|
Master
Joined: 23 Aug 2001
Posts: 266
Location: England
|
If an application has the queue open then no more trigger messages will be generated for the queue if another instance fails. The setting of trigger interval is irrelevant
_________________
Bob Buxton
Ex-Websphere MQ Development |
|
| Back to top |
|
|
| CharlieChen |
| Posted: Thu Nov 15, 2012 6:06 pm Post subject: |
|
|
Novice
Joined: 24 Jun 2012
Posts: 15
|
Hi Bruce & Bob, currently, our load is not high enough to have the queue continuously populated (the front-end is another system which we have no control over). So we can't test this scenario at the moment.
Look like once the triggered transaction abends, the load will be running only on one CICS. Is there any other way I can retrigger the transaction ? I really appreciate any suggestion or ideas that we can use... thanks very much in advance... thanks. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Thu Nov 15, 2012 9:28 pm Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9405
Location: US: west coast, almost. Otherwise, enroute.
|
Configure each cics to use its own initq; and Replicate the inbound message so that each cics processes its own instance pf the request message.
Replicating messages has been discussed here using a TOPIC.
_________________
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 |
|
|
| bruce2359 |
| Posted: Thu Nov 15, 2012 9:29 pm Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9405
Location: US: west coast, almost. Otherwise, enroute.
|
Moved to mainframe cics forum.
_________________
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 |
|
|
| bruce2359 |
| Posted: Fri Nov 16, 2012 7:01 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9405
Location: US: west coast, almost. Otherwise, enroute.
|
In parallel sysplex you want the initq shared so that if one instance of cics fails to complete the transaction, the remaining cics can attempt to do so.
_________________
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 |
|
|
| CharlieChen |
| Posted: Sun Nov 18, 2012 5:57 pm Post subject: |
|
|
Novice
Joined: 24 Jun 2012
Posts: 15
|
Hi Bruce
If we the initq is shared, what I understood is that only 1 trigger message is generated. This would mean, if my understanding is correct, that only 1 CICS runs at any one time. So even if we set up 2 CICS for workload balancing, only 1 is running. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Sun Nov 18, 2012 7:47 pm Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9405
Location: US: west coast, almost. Otherwise, enroute.
|
| CharlieChen wrote: |
Hi Bruce
If we the initq is shared, what I understood is that only 1 trigger message is generated. This would mean, if my understanding is correct, that only 1 CICS runs at any one time. So even if we set up 2 CICS for workload balancing, only 1 is running. |
Running CICS in Parallel Sysples presumes multiple CICSs doing the same workload. This presumes no application affinity issues.
The trigger monitor consumes a trigger message, and starts the CICS transaction/app in a UofW. If the UofW fails, the trigger message is backed out; and is once again visible to other instances of the trigger monitor.
Having a shared initq allows multiple CICSs to process work from the same triggered queue concurrently; and, more importantly, should that work fail in one instance of CICS, another instance of CICS can attempt to process it.
_________________
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 |
|
|
| bruce2359 |
| Posted: Mon Nov 19, 2012 7:06 am Post subject: Re: Trigger Interval with Shared Queue |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9405
Location: US: west coast, almost. Otherwise, enroute.
|
| CharlieChen wrote: |
Hi Bruce
If we the initq is shared, what I understood is that only 1 trigger message is generated. |
Yes, only one trigger message is generated; but one is all that is necessary.
| CharlieChen wrote: |
| The reason is we want both the CICS to process the message. |
Do you really want the same message to be processed by two CICSs? Or do you mean that you want the message processed successfully once, even if the first CICS fails to process the message?
Do you really want two CICSs to process the same message? I've seen this in very large (read: massive), replicated parallel sysplex implementations. In these, the inbound transaction is replicated (by some front-end process), and both traverse two physically separated parallel syspleses. The results of whichever transaction completes first is returned to the user.
This configuration ensures that if one of the sysplexes fails, the other will continue processing.
I suspect that your OP is not this type of implementation. Rather, I suspect that you are concerned that one CICS (or z/OS) image might fail to complete the work, and leave the message unprocessed. Is this correct?
If so, this is the design and purpose of shared queues and parallel sysplex.
_________________
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 |
|
|
| CharlieChen |
| Posted: Wed Dec 05, 2012 7:50 pm Post subject: |
|
|
Novice
Joined: 24 Jun 2012
Posts: 15
|
Hi Bruce
Sorry to reply so late. Was on leave.
Yes, you are right. We only want 1 CICS to process the message. I have miscommunicated in my previous appends.
I have 2 issues:
1. whether to use shared initq or non-shared initq
2. I have CICSes. Assuming that I'm able to trigger the transaction on both the CICSes to start, if one of the trigger transaction abends while the shared queue is not empty, how can I get the transaction to run as the queue is not empty
Let's address issue 1 first:
Initially, I thought I read that when using share application queue and shared initq, only 1 trigger message is generated. If I have 2 CICSes serving 1 shared application queue using Trigger First, then only 1 trigger message is generated. Only 1 CICS will be triggered. The other CICS will not have the chance to process the *subsequent* messages coming in (until the next Trigger First happens). So at anyone time, only 1 CICS will be processing the messages and there is no workload sharing between the 2 CICSes.
I re-read the manual again (http://publib.boulder.ibm.com/infocenter/wmqv7/v7r0/index.jsp).... for shared application queue and shared initq queue... it says: "For trigger type FIRST or DEPTH, one trigger message is generated by each queue manager that has the named initiation queue open for input." It seems to say that if I have 2 CICSes opening the initq, then I will get 2 trigger message, one for each QM. But I don't understand this. The trigger monitor on the 2 CICSes will be opening the same shared initq. While 2 message are generated, how can it ensure that the trigger message are being consumed by the trigger monitor on both the 2 CICSes instead of the same CICS (double triggering for one CICS and zero trigger for the other) ?
The manual also says ... for shared application queue and non-shared initq, it says: "For trigger type FIRST or DEPTH, a trigger message triggers an instance of the application on every queue manager that is running a trigger monitor and that does not already have the application queue open for input. One trigger message is generated for every queue manager; ...." How is it different from the share initq case ?
Thanks very much... |
|
| Back to top |
|
|
| CharlieChen |
| Posted: Wed Dec 05, 2012 10:13 pm Post subject: |
|
|
Novice
Joined: 24 Jun 2012
Posts: 15
|
Hi Bob !
| bob_buxton wrote: |
| If an application has the queue open then no more trigger messages will be generated for the queue if another instance fails. The setting of trigger interval is irrelevant |
First, please refer to http://publib.boulder.ibm.com/infocenter/wmqv7/v7r0/index.jsp, it says: "MQINQ - When you use the MQINQ call to display information about a shared queue, the values of the number of MQOPEN calls that have the queue open for input and output relate only to the queue manager that issued the call. No information is produced about other queue managers in the queue-sharing group that have the queue open."
Let say I have 2 queue managers and CICS:
- MQA and CICSA
- MQB and CICSB
If the trigger transaction on CICSB abends and the trigger interval is reached:
- From MQA's perspective, it will see that the number of MQOPEN calls not zero
- From MQB's perspective, it will see that the number of MQOPEN calls is zero
Would MQB then trigger another transaction since queue is not empty but the trigger interval is reached ?
Thanks !!! |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Thu Dec 06, 2012 6:07 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9405
Location: US: west coast, almost. Otherwise, enroute.
|
| CharlieChen wrote: |
2. I have CICSes. Assuming that I'm able to trigger the transaction on both the CICSes to start, if one of the trigger transaction abends while the shared queue is not empty, how can I get the transaction to run as the queue is not empty |
You won't get multiple CICSs to start the same exact transaction.
Do you want to produce two of the exact same paychecks? Two of the same inventory updates? I repeat: you don't want two (or more) CICSs to process the same transaction at the same time. You only want one CICS transaction to successfully complete. If one attempt fails, you want another attempt to take place. Yes?
Trigger messages are MQGET in a UofW, the same UofW in which the triggered application is launched - the same UofW in which the CICS app consumes the application message.
Only one trigger monitor will successfully MQGET the trigger message. If this trigger message is the only one in the initq, the other trigger monitors will get a 2033. Therefore, only CICS transaction will process the application message.
If that instance of the CICS transaction fails, the entire UofW is MQBACKed out, and another trigger monitor will now be able to MQGET the trigger message and start the transaction.
Click on this URL, and it takes you to the InfoCenter home page - no useful information there. Please click on a URL you post to see if it takes the reader to anything useful.
_________________
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 |
|
|
| bruce2359 |
| Posted: Thu Dec 06, 2012 6:37 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9405
Location: US: west coast, almost. Otherwise, enroute.
|
Continuing:
The value of parallel sysplex, and a shared queue, is that one or more CICSs have the opportunity to process messages. Should one or more CICSs (or MVSs or LPARs) fail, the remaining CICSs can continue to process messages.
Without much participation of WLM, the fastest and most-available CICS image will consume more messages. If all of the participating LPARs are identically provisioned, then the workload will likely be evenly shared.
I seem to recall a redbook on CICS in a parallel sysplex. Search google for it.
_________________
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 |
|
|
| CharlieChen |
| Posted: Thu Dec 06, 2012 7:57 pm Post subject: |
|
|
Novice
Joined: 24 Jun 2012
Posts: 15
|
Hi Bruce
I think we are looking at different issues. I don't want the same message to be process by both CICSA and CICSB at the same time. Once CICSA gets the message in a UOW, it is unavailable to CICSB unless CICSA backs out the message. I totally agree with you.
For a Trigger First setup, our program will wakeup and GET WAIT with a timer (eg 60 secs). We want to trigger the transaction in CICSA and CICSB. One of the CICSes will get it, eg CICSA. CICSB will GET WAIT for the subsequent message to come in. Both CICSA and CICSB will continue to process incoming message until there are no more incoming messages for the next 60 secs (then 2033). Then the whole process repeats when there is a Trigger First.
For a Trigger First setup that only triggers CICSA, then when CICSA process the message, CICSB will be dormant. CICSA continues to run until there are no messages on queue within 60secs. When the next Trigger First happens, then either CICSA or CICSB will run. So at any one time, only 1 CICS will run.
We are not setting up CICSA/CICSB in a hotbackup fashion. We want them to both concurrently process the incoming workload (yes, agree. Not the same message).
The question is: If I only trigger one of the CICSes, then how do I do workload sharing between CICSA and CICSB ?
For the URL, it's this manual:
- MQSeries Version 7.0
- Application Programming Guide
- Writing a WebSphere MQ application
- Using and writing applications on WebSphere MQ for z/OS
- Application programming with shared queues
- Topic: Migrating your existing applications to use shared queues
Thanks again... |
|
| Back to top |
|
|
|
|
|
  |
Goto page 1, 2 Next |
Page 1 of 2 |
|
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
|
|
|
|
