| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
| CICS bridge not processing messages after migrating to MQ V6 |
View previous topic :: View next topic |
| Author |
Message
|
| seanb |
 Posted: Sun Feb 04, 2007 1:40 am Post subject: CICS bridge not processing messages after migrating to MQ V6 |
 |
|
Apprentice
Joined: 02 Aug 2003
Posts: 39
|
Hello,
We have recently migrated from MQ V5.3.1 to MQ V6 on the mainframe. Since doing so the CICS bridge has stopped processing the messages on the CICS bridge queue.
The problem is as follows. We put a message to the CICS bridge queue. This queue is defined as a GROUP queue, the index type is set to NONE and it is configured to trigger (first) the CKBR transaction. In V5.3.1 CKBR is started and the message is processed successfully. After migrating to V6 CKBR is started, the messages remain on the queue (until they expire) and no transaction is started.
When CKBR is stopped the following messages appear in the CICS JESMSGLG:
CSQC713I CKBR 0003584 Bridge terminated normally
CSQC762I CKBR 0003584 Queue name xxx
CSQC736I CKBP 0003616 Bridge quiesced before task started
CSQC760I CKBP 0003616 MsgId=C3E2D840D9D4F2C44040404040404040C01B1A40F6E34320
The following is the output from the starting of the bridge monitor:
CSQC700I CKBR 0003658 IBM WebSphere MQ for z/OS V6 - CICS bridge
CSQC766I CKBR 0003658 Bridge queue not defined with INDXTYPE(CORRELID)
CSQC702I CKBR 0003658 Monitor initialization complete
CSQC703I CKBR 0003658 Auth=IDENTIFY, WaitInterval=20000, Q=xxx
CSQC783I CKBR 0003658 Msg=BOTH, PassTktA=DCICA101
We are using CICS TS 3.1 and have recently applied the latest MQ maintenance. We run in a CICSPLEX, MQ queue sharing environment.
I have tried everything I can think of all to no avail. Can anyone offer any suggestions?
_________________
Regards,
Sean |
|
| Back to top |
|
 |
| bob_buxton |
| Posted: Sun Feb 04, 2007 2:35 am Post subject: |
|
|
Master
Joined: 23 Aug 2001
Posts: 266
Location: England
|
I cant think of any reason for the behaviour you are seeing.
You are probably best opening a problem with the IBM support centre.
The queue index type would not cause the symptoms.
_________________
Bob Buxton
Ex-Websphere MQ Development |
|
| Back to top |
|
|
| seanb |
| Posted: Sun Feb 04, 2007 3:43 am Post subject: |
|
|
Apprentice
Joined: 02 Aug 2003
Posts: 39
|
I'm about to do that now (after I spend some time with the CICS team to make sure it isn't caused by something silly I/we've done here).
I must be a jinx as it seems everytime I make a MQ change the bridge stops working for a while.
Thanks.
_________________
Regards,
Sean |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Sun Feb 04, 2007 6:34 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20768
Location: LI,NY
|
| seanb wrote: |
I'm about to do that now (after I spend some time with the CICS team to make sure it isn't caused by something silly I/we've done here).
I must be a jinx as it seems everytime I make a MQ change the bridge stops working for a while.
Thanks. |
I guess you did check the obvious like Initq and trigger monitor running on initq?
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| seanb |
| Posted: Sun Feb 04, 2007 6:48 am Post subject: |
|
|
Apprentice
Joined: 02 Aug 2003
Posts: 39
|
| Yes, I checked the obvious. The bridge monitor is triggered ok and is running. What it doesn't do is start the targeted CICS transaction or get the messages from the queue. I backed out the V6 changes on one of the QM and it runs ok but on the V6 QM it just sits there. Both QM are configured identically. |
|
| Back to top |
|
|
| bob_buxton |
| Posted: Sun Feb 04, 2007 12:21 pm Post subject: |
|
|
Master
Joined: 23 Aug 2001
Posts: 266
Location: England
|
| seanb wrote: |
| Yes, I checked the obvious. The bridge monitor is triggered ok and is running. What it doesn't do is start the targeted CICS transaction or get the messages from the queue. I backed out the V6 changes on one of the QM and it runs ok but on the V6 QM it just sits there. Both QM are configured identically. |
From the messages you have shown the bridge monitor (CKBR) is starting the bridge transactions (CKBP) but for some reason the CKBP transction is failing to get the message off the bridge queue and is sitting in MQGET until you Get Disabled the queue.
This is strange since the get of the first message uses MQGMO_NO_WAIT.
_________________
Bob Buxton
Ex-Websphere MQ Development |
|
| Back to top |
|
|
| seanb |
| Posted: Mon Feb 05, 2007 3:52 am Post subject: |
|
|
Apprentice
Joined: 02 Aug 2003
Posts: 39
|
The CICS trace suggests this is what is happening. We have run a CICS trace using MQ 5.3.1 and MQ 6.
We can clearly see the target transaction start in the V531 trace.
When we look at the V6 trace the CKBR/CKBP process appears to be in an effective loop with CKBP transaction repeatedly being started, doing some processing (CSQCGMGH, CSQCGETW with NO WAIT, CSQCDIN, CSQCDCOT, CSQCGMGI, CSQCGMGD), not executing the target transaction and then starting all over again. We have four occurrences of the start before we stopped the trace and the CSQCGETW appears on every second one.
From the trace it does appear as though CKBP gets the message (CSQCGMI has what appears a MSGID and CSQCGMGD has what appears the message) but then nothing. I can continue to browse the message and the backout count doesn’t go up which suggests to me the message has been browsed but not yet got?!
I know you probably can’t do much with it but I have attached part of the CICS trace showing what I mean.
I will raise a PMR.
>>>Part of the CICS trace
13055 QR AP E160 EXEC ENTRY START 'CKBP' AT X'2C5F80AC',0 AT X'2CA08F68','TM ....RIBL.MQA.QL.CICS.BRID =002967
13055 QR XM 0401 XMLD ENTRY LOCATE_AND_LOCK_TRANDEF CKBP =002968
13055 QR DD 0301 DDLO ENTRY LOCATE 29500040,2A510324,TXD,CKBP =002969
13055 QR DD 0302 DDLO EXIT LOCATE/OK 2A78C710 , D7000000 =002970
13055 QR XM 0402 XMLD EXIT LOCATE_AND_LOCK_TRANDEF/OK 2A78D510 , 000000E7 =002971
13055 QR SM 0C01 SMMG ENTRY GETMAIN EIIC TEM,534,YES,00,TEMPSTG =002972
13055 QR SM 0C02 SMMG EXIT GETMAIN/OK 001DC008 =002973
13055 QR US 0301 USAD ENTRY VALIDATE_USERID 8,DDYNECEX =002974
13055 QR DD 0401 DDBR ENTRY START_BROWSE 29500FB0,2A510EE8,USD1 =002975
13055 QR SM 0301 SMGF ENTRY GETMAIN 124,YES,00,BRWS_VAL,CICS =002976
13055 QR SM 0302 SMGF EXIT GETMAIN/OK 2C5F84A8 =002977
13055 QR LM 0003 LMLM ENTRY LOCK 2938CC48,SHARED =002978
13055 QR LM 0004 LMLM EXIT LOCK/OK =002979
13055 QR LM 0003 LMLM ENTRY UNLOCK 2938CC48,SHARED =002980
13055 QR LM 0004 LMLM EXIT UNLOCK/OK =002981
13055 QR DD 0402 DDBR EXIT START_BROWSE/OK 2C5F84A8 =002982
13055 QR DD 0401 DDBR ENTRY GET_NEXT_ENTRY 2A510EE8 , 35D16C80 , 00000028,29500FB0,2C5F84A8,USD1 =002983
13055 QR LM 0003 LMLM ENTRY LOCK 2938CC48,SHARED =002984
13055 QR LM 0004 LMLM EXIT LOCK/OK =002985
13055 QR LM 0003 LMLM ENTRY UNLOCK 2938CC48,SHARED =002986
13055 QR LM 0004 LMLM EXIT UNLOCK/OK =002987
13055 QR DD 0402 DDBR EXIT GET_NEXT_ENTRY/OK 2A510EE8 , 00000028 , 00000028,29528280 , A8A2B20E,DDYNECEX =002988
13055 QR DD 0401 DDBR ENTRY END_BROWSE 29500FB0,2C5F84A8,USD1 =002989
13055 QR LM 0003 LMLM ENTRY LOCK 2938CC48,SHARED =002990
13055 QR LM 0004 LMLM EXIT LOCK/OK =002991
13055 QR LM 0003 LMLM ENTRY UNLOCK 2938CC48,SHARED =002992
13055 QR LM 0004 LMLM EXIT UNLOCK/OK =002993
13055 QR SM 0301 SMGF ENTRY FREEMAIN 2C5F84A8,BRWS_VAL,CICS =002994
13055 QR SM 0302 SMGF EXIT FREEMAIN/OK =002995
13055 QR DD 0402 DDBR EXIT END_BROWSE/OK =002996
13055 QR US 0302 USAD EXIT VALIDATE_USERID/OK =002997
13055 QR XS 0701 XSRC ENTRY CHECK_SURROGATE_USER START,8,DDYNECEX =002998
13055 QR XS 0709 XSRC EVENT CHECK DDYNECEX.DFHSTART CHECK_RESOURCE_ACCESS,35D55570 , 00000002,SURROGAT =002999
13055 QR XS 070A XSRC EVENT CHECK-COMPLETE DDYNECEX.DFHSTART DCIC CHECK_RESOURCE_ACCESS,OK,0,0,0,0 =003000
13055 QR XS 0702 XSRC EXIT CHECK_SURROGATE_USER/OK =003001
13055 QR AP 00F3 ICP ENTRY PUT HEADER CKBP 7003,0000000C ....,00000000 ....,CKBP =003002
13055 QR TS 0301 TSPT ENTRY PUT DF0038B3,001DC014 , 00000530,2A99A9F0 , 000000CC,YES,YES,NO =003003
13055 QR TS 0C01 TSMB ENTRY MATCH DF0038B3 =003004
13055 QR TS 0C02 TSMB EXIT MATCH/OK YES =003005
13055 QR TS 0901 TSAM ENTRY WRITE_AUX_DATA 001DC014 , 00000530,DF0038B3,C01C6AC869A21B02,1,1,YES,YES,NO =003006
13055 QR TS 0902 TSAM EXIT WRITE_AUX_DATA/OK 28,00000028 =003007
13055 QR TS 0302 TSPT EXIT PUT/OK C01C6AC869A1C102,YES =003008
13055 QR AP 00F3 ICP EXIT NORMAL 0005,00000000 ....,00000000 .... =003009
13055 QR SM 0D01 SMMF ENTRY FREEMAIN EIIC TEM,001DC008,TEMPSTG =003010
13055 QR SM 0D02 SMMF EXIT FREEMAIN/OK CICS24 storage at 001DC008 =003011
13055 QR AP E161 EXEC EXIT START 'CKBP' AT X'2C5F80AC',0 AT X'2CA08F68','TM ....RIBL.MQA.QL.CICS.BRID =003012
13055 QR AP 2520 ERM ENTRY C-APPLICATION-CALL-TO-TRUE(MQM ) =003013
13055 QR AP D500 UEH EVENT LINK-TO-USER-EXIT-PROGRAM CMRKCPX5 AT EXIT POINT XRMIIN =003014
13055 QR AP D501 UEH EVENT RETURN-FROM-USER-EXIT-PROGRAM CMRKCPX5 WITH RETURN CODE 0 =003015
13055 QR AP E160 EXEC ENTRY ENTER 193 AT X'2954DB00','....' AT X'2CA0BC10',4 AT X'2CA0BE80','CSQCGMGH' =003016
13055 QR AP 00C1 USER EVENT APPLICATION-PROGRAM-ENTRY CSQCGMGH .... =003017
13055 QR AP E161 EXEC EXIT ENTER 193 AT X'2954DB00','....' AT X'2CA0BC10',4 AT X'2CA0BE80','CSQCGMGH' =003018
13055 QR DS 0004 DSSR ENTRY WAIT_MVS MQSeries,2B9B1D28,NO,TASKSWCH =003019
13055 QR DS 0005 DSSR EXIT WAIT_MVS/OK =003020
--------------------------
The second and each even iteration of each loop contains the following extra bit.
13055 QR AP E160 EXEC ENTRY ENTER 193 AT X'2954DB00','....' AT X'2CA0BB9C',4 AT X'2CA0BE80','CSQCGETW' =003090
13055 QR AP 00C1 USER EVENT APPLICATION-PROGRAM-ENTRY CSQCGETW .... =003091
13055 QR AP E161 EXEC EXIT ENTER 193 AT X'2954DB00','....' AT X'2CA0BB9C',4 AT X'2CA0BE80','CSQCGETW' =003092
13055 QR DS 0004 DSSR ENTRY WAIT_MVS MQSeries,2B9B1D24,NO,GETWAIT =003093
13055 QR DS 0005 DSSR EXIT WAIT_MVS/OK *=004079
13055 QR DS 0004 DSSR ENTRY WAIT_MVS MQSeries,2B9B1D28,NO,TASKSWCH =004080
13055 QR DS 0005 DSSR EXIT WAIT_MVS/OK =004081
--------------------------
13055 QR AP E160 EXEC ENTRY ENTER 193 AT X'2954DB00','...q....DATACONV................................. =003021
13055 QR AP 00C1 USER EVENT APPLICATION-PROGRAM-ENTRY CSQCDCIN ...q....DATACONV........................................ =003022
13055 QR AP E161 EXEC EXIT ENTER 193 AT X'2954DB00','...q....DATACONV................................. =003023
13055 QR AP E160 EXEC ENTRY ENTER 193 AT X'2954DB00','...q....-RETURN-................................. =003024
13055 QR AP 00C1 USER EVENT APPLICATION-PROGRAM-ENTRY CSQCDCOT ...q....-RETURN-........................................ =003025
13055 QR AP E161 EXEC EXIT ENTER 193 AT X'2954DB00','...q....-RETURN-................................. =003026
13055 QR AP E160 EXEC ENTRY ENTER 193 AT X'2954DB00',FROM('CSQ RM2D º..H!....(..+..¬.....|+¬.|.. =003027
13055 QR AP 00C1 USER EVENT APPLICATION-PROGRAM-ENTRY CSQCGMGI CSQ RM2D º..H!....(..+..¬.....|+¬.|...<.. =003028
13055 QR AP E161 EXEC EXIT ENTER 193 AT X'2954DB00',FROM('CSQ RM2D º..H!....(..+..¬.....|+¬.|.. =003029
13055 QR AP E160 EXEC ENTRY ENTER 193 AT X'2954DB00','WIH ...............uMQCICS .... ' AT X'2D =003030
13055 QR AP 00C1 USER EVENT APPLICATION-PROGRAM-ENTRY CSQCGMGD WIH ...............uMQCICS .... =003031
13055 QR AP E161 EXEC EXIT ENTER 193 AT X'2954DB00','WIH ...............uMQCICS .... ' AT X'2D =003032
13055 QR AP D500 UEH EVENT LINK-TO-USER-EXIT-PROGRAM CMRKCPX5 AT EXIT POINT XRMIOUT =003033
13055 QR AP D501 UEH EVENT RETURN-FROM-USER-EXIT-PROGRAM CMRKCPX5 WITH RETURN CODE 0 =003034
13055 QR AP 2521 ERM EXIT C-APPLICATION-CALL-TO-TRUE(MQM ) =003035 |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Mon Feb 05, 2007 4:22 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20768
Location: LI,NY
|
| bob_buxton wrote: |
| seanb wrote: |
| Yes, I checked the obvious. The bridge monitor is triggered ok and is running. What it doesn't do is start the targeted CICS transaction or get the messages from the queue. I backed out the V6 changes on one of the QM and it runs ok but on the V6 QM it just sits there. Both QM are configured identically. |
From the messages you have shown the bridge monitor (CKBR) is starting the bridge transactions (CKBP) but for some reason the CKBP transction is failing to get the message off the bridge queue and is sitting in MQGET until you Get Disabled the queue.
This is strange since the get of the first message uses MQGMO_NO_WAIT. |
You might be running into one of the strange and rare occurrences where the queue gets triggered before the message is fully available.
This is why the manual suggests to use a get with wait to remove the message from the triggered queue. The wait interval is to allow for which ever process puts the message there to do the commit / rollback.
The triggered program should process messages on the queue until a 2033 (or no more messages on queue) is received regardless of the triggering mode (first | every).
Anyway if the get no wait does not work as described in the manuals it is PMR time...
Enjoy 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| kevinf2349 |
| Posted: Mon Feb 05, 2007 6:03 am Post subject: |
|
|
Grand Master
Joined: 28 Feb 2003
Posts: 1311
Location: USA
|
| Not sure it should make any difference but are you sure you have the V6 libraries in the CICS JCL? |
|
| Back to top |
|
|
| seanb |
| Posted: Mon Feb 05, 2007 6:19 am Post subject: |
|
|
Apprentice
Joined: 02 Aug 2003
Posts: 39
|
Yes, we have double checked that. Also, the monitor writes a CICS message when it starts suggesting it has picked up the correct libraries/modules.
CSQC700I CKBR 0003658 IBM WebSphere MQ for z/OS V6 - CICS bridge |
|
| Back to top |
|
|
| kevinf2349 |
| Posted: Mon Feb 05, 2007 6:24 am Post subject: |
|
|
Grand Master
Joined: 28 Feb 2003
Posts: 1311
Location: USA
|
Looks like it is time to raise an APAR. 
If you would can you keep us posted on the results....we are planning our upgrade to V6 in the next few weeks and we use the CICS bridge pretty extensively.  |
|
| Back to top |
|
|
| seanb |
| Posted: Sat Feb 10, 2007 12:25 am Post subject: |
|
|
Apprentice
Joined: 02 Aug 2003
Posts: 39
|
An update. I have just noticed the following in the SYSLOG. I only checked the CICSLOG and MQLOG before . We are investigating now.
CSQI043E *2D CSQIWSCL WLM IWMQINS request for process 236
START.CKBR failed, rc=0000000C reason=101F0C1A
CSQI043E *2D CSQIWSCL WLM IWMQINS request for process 237
START.CKBR failed, rc=0000000C reason=101F0C1A |
|
| Back to top |
|
|
| bob_buxton |
| Posted: Sat Feb 10, 2007 3:10 pm Post subject: |
|
|
Master
Joined: 23 Aug 2001
Posts: 266
Location: England
|
From those message and your trace data it would appear that you have a Workload Manager MQWIH header on the front of your messages.
I have never dealt with the MQ WLM interfaces but I am pretty sure you dont want to use WLM with the CICS bridge 
_________________
Bob Buxton
Ex-Websphere MQ Development |
|
| Back to top |
|
|
| seanb |
| Posted: Sun Feb 11, 2007 5:40 am Post subject: |
|
|
Apprentice
Joined: 02 Aug 2003
Posts: 39
|
Now that is interesting! I don't know much about our programs here but I did a quick check and they don't add it. I have noticed the MQWIH is not present when running with V5.3.1 but it is present when running for V6. Is MQ adding it if it sees a MQCIH?
Here are the messages using the same program against the different version queue managers; we haven't made any program changes to these modules. I'll have a closer look, recompile the program and check actual message being put from the program and see whether it's the same as the one hitting the queue.
Message from V5.3.1
CIH © Í
PASSWORD XXXX '
}XXXXXXXXXXXXXXXXXXXXX
Message from V6
WIH .......Ì.......uMQCICS ....
........{..Ñ.z\~ CIH .......©........
......................Í................................. PASS
WORD XXXX ' ....
...............}XXXXXXXXXXXXXXXXXXXXXXXXXXX
_________________
Regards,
Sean |
|
| Back to top |
|
|
| bob_buxton |
| Posted: Wed Feb 14, 2007 5:28 am Post subject: |
|
|
Master
Joined: 23 Aug 2001
Posts: 266
Location: England
|
Does your bridge queue (or any alias) have index type MSGTOKEN?
One change in version 6 was to automatically generate an MQWIH for queues with index type MSGTOKEN. Only work load managed queues should have this index type
_________________
Bob Buxton
Ex-Websphere MQ Development |
|
| 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
|
|
|
|
