| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| CICS 3270 Bridge reply message not available |
« View previous topic :: View next topic » |
| Author |
Message
|
| Jeffrey Orris |
 Posted: Thu Jul 24, 2003 11:15 am Post subject: CICS 3270 Bridge reply message not available |
 |
|
Newbie
Joined: 24 Jul 2003
Posts: 2
Location: Harrisburg, PA
|
I'm writing a COBOL z/OS batch program which puts a message to a CICS bridge queue and attempts to get the reply message from the reply queue. But the MQGET is failing with a reason code of QRC_NO_MSG_AVAILABLE.
I've made sure that MQGMO-WAITINTERVAL is long enough (60000 ms). I also can browse the reply message in the queue with another utility (supportpac MA10) while the MQGET is waiting.
My match options are set to match on MSGID only (and I don't change the id returned in MQMD-MSGID by the PUT to the bridge queue).
If I copy the MQMD-MSGID from the PUT to a separate job that contains only the GET logic, the reply message is successfully retrieved.
It appears that, since the batch job is considered one unit of work, the message is not available for GET until the batch job completes. I tried issuing an MQCMIT just before opening the reply queue, but the reply message is still unavailable. I also unsuccessfully tried specifying NO_SYNCPOINT in my PUT and GET message options.
My guess is that CICS is putting the reply message with a syncpoint using the UOW id of the batch job, and nothing can GET the message until that job completes (including the job itself).
Any ideas or suggestions? |
|
| Back to top |
|
 |
| Jeffrey Orris |
| Posted: Thu Jul 24, 2003 1:36 pm Post subject: CICS 3270 Bridge reply message not available |
|
|
Newbie
Joined: 24 Jul 2003
Posts: 2
Location: Harrisburg, PA
|
Problem solved!
I confirmed that both the MSGID and CORRELID in the reply message are identical to the MSGID returned from the PUT of the request message (even without specifying MQRO-PASS-MSG-ID). I moved the MSGID to CORRELID and changed my match options to MQMO-MATCH-CORREL-ID, and the reply was gotten successfully. I also tried letting the match options default to MQMO-MATCH-MSG-ID + MQMO-MATCH-CORREL-ID, and the reply was gotten successfully.
But here's the real puzzler. I changed my match options back to MQMO-MATCH-MSG-ID only, and the reply was gotten successfully. So the whole key was moving MSGID to CORRELID. CORRELID had been populated with MQCI-NEW-SESSION from the initial PUT. The GET appears to want to match on both MSGID and CORRELID -- even if it's told to match on MSGID only. This is probably a defect, but it's easy enough for me to populate CORRELID. |
|
| 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
|
|
|
|
