| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
| One transaction slows down the other |
« View previous topic :: View next topic » |
| Author |
Message
|
| bruce2359 |
 Posted: Fri Oct 30, 2009 3:54 pm Post subject: |
 |
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
Short of asking for help, can you do any problem-determination on this? Can you can turn on WMQ monitoring at the channel ends? At the queues - at both ends?
Can you use the IBM-supplied MQ traceroute command to get a sense of message flow?
Without some actual evidence, other than perceived slowdown, there's not much we can offer - other than guesses.
_________________
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 |
|
 |
| jsp_ejb |
| Posted: Fri Oct 30, 2009 6:39 pm Post subject: |
|
|
Novice
Joined: 27 Jun 2004
Posts: 21
Location: Chicago
|
Well, we tried everything. Everything in MQ seems normal. We can not identify the reason for the slowdown.
Meantime, we are working with IBM support (CICS+MQ). I just want to see if anybody had similar situation before. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Fri Oct 30, 2009 9:03 pm Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
| Quote: |
| Well, we tried everything. |
What did you try?
_________________
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: Sat Oct 31, 2009 6:44 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
| Quote: |
| A wakes up in a fixed time interval and loop for 500 times. |
Is it program C that wakes up in a fixed time interval? How is this wake up accomplished?
So far, you have described symptoms of what could be a resource contention issue, a lack of resources issue, a bad application coding issue, or something else. At one time or another, we have all had these.
MVS has a variety of native performance monitoring and problem-determination tools, like SMF and RMF data, component traces. IBM-Tivoli Omegamon and 3rd party products have similar capabilities.
You, or someone with problem-determination skills, needs to get involved and do some preliminary p-d.
_________________
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 |
|
|
| jsp_ejb |
| Posted: Sat Oct 31, 2009 9:52 am Post subject: |
|
|
Novice
Joined: 27 Jun 2004
Posts: 21
Location: Chicago
|
We have done SMF, Omegamon (for mq, cics, db2) and APA etc. All queues, channels were all monitored and all kinds of cics traces were also taken. Nobody has found any clue yet.
Transaction A does MQGet with syncpoint first, then call program C ( MQPut and MQGet with different queues, both with no-syncpoint). Then A commits. Is it possible this is the cause? Can you do another MQGet(no-syncpoint) on different queue before committing the first MQGet(with sync-point)? |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Sat Oct 31, 2009 11:25 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
An application commits/backouts all resources get/put within syncpoint.
| Quote: |
| A wakes up in a fixed time interval and loop for 500 times. |
Please answer the question asked: Is it program C that wakes up in a fixed time interval?
Exactly how does A wake up? How is this accomplished in a fixed time interval? Did someone write a timer using an ECB? Is this done with GET with WAITINTERVAL?
The more specific you can be, the more likely we can understand the real problem, and suggest a remedy.
_________________
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.
Last edited by bruce2359 on Sat Oct 31, 2009 12:22 pm; edited 1 time in total |
|
| Back to top |
|
|
| zpat |
| Posted: Sat Oct 31, 2009 11:33 am Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
Location: UK
|
| Make sure to use a CICS WAIT and not a z/OS WAIT (STIMER) if you have to code a delay (usually not a good idea anyway). |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Sat Oct 31, 2009 12:21 pm Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
| Quote: |
| Make sure to use a CICS WAIT... |
Of your choices for waiting, why not use theWMQ for z/OS WMQ GET with WAIT that offers an ECB-type interrupt?
_________________
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 |
|
|
| jsp_ejb |
| Posted: Sat Oct 31, 2009 7:19 pm Post subject: |
|
|
Novice
Joined: 27 Jun 2004
Posts: 21
Location: Chicago
|
A does not have any WAIT built in. (no ZOS wait, no CICS wait, no MQ get wait). A is started by another control program. Then, A enters the loop of processing 500 messages. After A finishes 500 messages (or processed all messages in the queue), A exits. The controller starts next run of A after 1 min.
Without calling program C, A runs perfectly (has been there for 10+ years) |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Sat Oct 31, 2009 9:10 pm Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
| Quote: |
| been there for 10+ years |
When exactly did this application begin to misbehave? In 10+ years something must have changed?
Does this application run continuously - 24x7?
What has changed (or what is new) around the time the application began to misbehave?
Application program(s) changed? (if the developers say no, have they ever lied to you in the past?)
WMQ version/release changed?
WMQ object definiti8ons changed?
_________________
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 |
|
|
| jsp_ejb |
| Posted: Sun Nov 01, 2009 8:05 pm Post subject: |
|
|
Novice
Joined: 27 Jun 2004
Posts: 21
Location: Chicago
|
| The change is Program C. If A does not call C, everything works as expected. Program C is also called by Transaction B. If B is running, A slows down. B is not impacted. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Sun Nov 01, 2009 9:54 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| jsp_ejb wrote: |
| The change is Program C. If A does not call C, everything works as expected. Program C is also called by Transaction B. If B is running, A slows down. B is not impacted. |
Sounds more and more to me like a resource problem in your design...
Whatever triggers B calls enough instances of C to keep C busy at the max concurrent threshold you set. No more resources for C to get triggered from A. Consequently A slows down...
Would it be possible to have C only triggered from a Queue? A and B would just place a message into the queue to trigger C... With FIFO you'd guarantee that A is not slowed down more than B... Although if C is your bottleneck you might want to review the number of concurrent max instances....
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Mon Nov 02, 2009 6:24 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
| Quote: |
| The change is Program C. |
Exactly what has changed in program C? What application code changes were made to C?
If only one thing changed, and it workded before, but not after, I'd look at the changes.
_________________
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 |
|
|
| jsp_ejb |
| Posted: Mon Nov 02, 2009 7:54 am Post subject: |
|
|
Novice
Joined: 27 Jun 2004
Posts: 21
Location: Chicago
|
Program C is completely new. We know we should focus on the program. But, Program C is also called by Transaction B. If B is running, A slows down. B is not impacted. This led us to believe there are differences in A and B.
C is only a program (called by A and B through CICS PERFORM), not a seperate transaction. What would be the "max concurrent threshold"? The only concurrent threshold in C is the two MQ operations. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Mon Nov 02, 2009 12:01 pm Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
| Quote: |
| C is only a program (called by A and B through CICS PERFORM), |
Huh?
Please paste the EXEC CICS code that calls program C.
_________________
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 |
|
|
|
|
|
|
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
|
|
|
|
