|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
 |
|
MQ CICS Bridge CKBP bottleneck |
« View previous topic :: View next topic » |
Author |
Message
|
loudcfla |
Posted: Tue Dec 16, 2008 6:11 am Post subject: MQ CICS Bridge CKBP bottleneck |
|
|
Acolyte
Joined: 05 May 2002 Posts: 58
|
Hello All,
We are running CICS/TS 2.3, z/os 1.9 and MQ Version 6 with the maintenance from z/os 1.9. recently I have had a number of short on storage occurences in our CICS/MQ region. I noticed that there are a flood of CKBP transactions in the region at the time and prior to the outage, these messages are prevelant in the syslog. Can anyone tell me what is wrong? I never had any trouble with the bridge until z/os 1.9.
+CSQC762I CKBP 0010572 Queue name SYSTEM.CICSP5.BRIDGE.QUEUE.ALT
+CSQC710E CKBP 0010569 MQGET failed, MQCC=2 MQRC=2033
+CSQC760I CKBP 0010569 MsgId=414D512053554E50524F442020202020493F3A14203
77E74 |
|
Back to top |
|
 |
fjb_saper |
Posted: Tue Dec 16, 2008 10:49 am Post subject: Re: MQ CICS Bridge CKBP bottleneck |
|
|
 Grand High Poobah
Joined: 18 Nov 2003 Posts: 20756 Location: LI,NY
|
loudcfla wrote: |
Hello All,
We are running CICS/TS 2.3, z/os 1.9 and MQ Version 6 with the maintenance from z/os 1.9. recently I have had a number of short on storage occurences in our CICS/MQ region. I noticed that there are a flood of CKBP transactions in the region at the time and prior to the outage, these messages are prevelant in the syslog. Can anyone tell me what is wrong? I never had any trouble with the bridge until z/os 1.9.
+CSQC762I CKBP 0010572 Queue name SYSTEM.CICSP5.BRIDGE.QUEUE.ALT
+CSQC710E CKBP 0010569 MQGET failed, MQCC=2 MQRC=2033
+CSQC760I CKBP 0010569 MsgId=414D512053554E50524F442020202020493F3A14203
77E74 |
Do you have stuff that is triggered "every" with no throttling of the corresponding CICS resource?
Note:MQRC=2033 this is normal. No message available for selection criteria...
 _________________ MQ & Broker admin |
|
Back to top |
|
 |
loudcfla |
Posted: Tue Dec 16, 2008 11:08 am Post subject: MQ CICS Bridge CKBP bottleneck |
|
|
Acolyte
Joined: 05 May 2002 Posts: 58
|
No I have trigger type first and CKBP is set in a transaction class.
When this situation happens, CKBP's just start coming out of nowhere and overwhelm the system. So i stop the channels not to let anything else through, purge all the tasks in the region and then start the channels again and we're good, until the next time it happens.
Could there be something in MQ version 6 that in rare occasions causes a CKBP loop? |
|
Back to top |
|
 |
fjb_saper |
Posted: Tue Dec 16, 2008 12:04 pm Post subject: Re: MQ CICS Bridge CKBP bottleneck |
|
|
 Grand High Poobah
Joined: 18 Nov 2003 Posts: 20756 Location: LI,NY
|
loudcfla wrote: |
No I have trigger type first and CKBP is set in a transaction class.
When this situation happens, CKBP's just start coming out of nowhere and overwhelm the system. So i stop the channels not to let anything else through, purge all the tasks in the region and then start the channels again and we're good, until the next time it happens.
Could there be something in MQ version 6 that in rare occasions causes a CKBP loop? |
I wouldn't be looking at a CKBP throttling but at throttling the stuff CKBP triggers. So if you have 100 transactions of the same type waiting to be processed by CKBP how many of those do you allow in parallel?
My understanding is that CKBP acts as your trigger monitor here.
Have fun  _________________ MQ & Broker admin |
|
Back to top |
|
 |
KathyB |
Posted: Mon Dec 22, 2008 8:23 am Post subject: |
|
|
Apprentice
Joined: 02 Feb 2004 Posts: 30
|
I ran into this very same problem.
In searching the IBM database, I found that this message occurs for MQ CICS bridge applications when there is a delay in processing a large number of messages.
The way that MQSeries is designed to process messages put on the CICS DPL bridge queue is that when a message is selected and submitted for processing by the bridge monitor program, the message receives a mark that causes it to become hidden from the view of the bridge monitor program as it continually monitors and browses the CICS DPL bridge queue.
If two internal time out intervals go by (default time interval is 5 seconds), and the message has not been processed, the mark is removed and the message becomes available again for selection and processing.
Because of the high volume of bridge transactions that were waiting to start and a processing backlog that took longer than 10 seconds to clear up, the messages were marked for processing again and a second start transaction was generated. By the time the second task ran, the message had already been processed by the first transaction and deleted from the CICS DPL bridge queue causing the second transaction to generate the 2033 empty queue return code message.
According to IBM, MQSeries is working as designed and IBM does not consider this an error.
What you need to do is alter the MARKBINT attribute of the queue manager. This is not a documented attribute and the default value of this attribute is 5 seconds, not long enough when there is a high volume of messages and potentially slow processing.
Run the following command substituting your values:
cpfRECOVER qmgr(QM_ssid)
What you will see at offset +0320 is hex value 0001388 which translates to 5,000 milliseconds or 5 seconds.
You can alter this value with the following:
cpf ALTER QMGR MARKBINT(300000) - this alters the value to 5 minutes. |
|
Back to top |
|
 |
KathyB |
Posted: Mon Dec 22, 2008 8:38 am Post subject: |
|
|
Apprentice
Joined: 02 Feb 2004 Posts: 30
|
I forgot to mention that I also upped the response time on my CHIN task to 60 seconds. The default is 30 seconds.
Add:
COMMAND RESPTIME(60) to your CSQINPX DD |
|
Back to top |
|
 |
loudcfla |
Posted: Mon Dec 22, 2008 9:10 am Post subject: |
|
|
Acolyte
Joined: 05 May 2002 Posts: 58
|
This is perfect, thank you so much KathyB, I think this is exactly my situation. |
|
Back to top |
|
 |
KathyB |
Posted: Mon Dec 22, 2008 12:01 pm Post subject: |
|
|
Apprentice
Joined: 02 Feb 2004 Posts: 30
|
FYI. The APAR for this is PK38581 |
|
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
|
|
|
|