| Author |
Message
|
| kramsnilloc |
 Posted: Wed Aug 29, 2007 5:03 am Post subject: Pseudo Synchronous MQ Call on z/OS using COBOL |
 |
|
Newbie
Joined: 23 Aug 2007
Posts: 8
Location: Jacksonville, FL.
|
Good day,
I’m trying to make a call to an Address Service using MQ and COBOL in z/OS. I can’t seem to get back the response message that correlates to my request. When I attempt to use CORRELID the reason code is 2033 - MQRC_NO_MSG_AVAILABLE. If I don’t set the CORRELID I get the next available message in the queue.
Currently my testing is using a test stub in batch (TSO), but when implemented the call will originate out of an IMS MPP program.
There is an ESB (Sonic) sitting between MQ on z/OS and the service on a windows server. In this POC, the ESB is simply returning the request in the response queue.
Is there some trick to doing this, or is it not possible in the environment I’m in?
I done various searches on the subject, and have tried several things to no avail (as you can see from the commented out code).
I connect to the q-mgr, open the response queue, open the request queue, put the request and then attempt to get the response.
The MQ functions that I’m calling are the CSQB versions; CSQBPUT and CSQBGET rather than the MQPUT and MQGET as this is what is available.
| Code: |
Put options and setup are as follows;
COMPUTE MQPMO-OPTIONS = MQPMO-NO-SYNCPOINT +
MQPMO-FAIL-IF-QUIESCING.
MOVE WS-RESPONSE-Q TO MQMD-REPLYTOQ.
* MOVE '123456789012345678901234' TO MQMD-CORRELID.
* MOVE MQ-CORRELID TO MQMD-CORRELID.
* MOVE MQCI-NONE TO MQMD-CORRELID.
MOVE MQMI-NONE TO MQMD-MSGID.
MOVE MQFMT-STRING TO MQMD-FORMAT.
MOVE MQMT-REQUEST TO MQMD-MSGTYPE.
GET options are as follows;
MOVE WS-QUEUE-MGR TO MQOD-OBJECTQMGRNAME.
MOVE WS-RESPONSE-Q TO MQOD-OBJECTNAME.
MOVE MQOT-Q TO MQOD-OBJECTTYPE.
MOVE MQFMT-STRING TO MQMD-FORMAT.
MOVE MQMI-NONE TO MQMD-MSGID.
* MOVE '123456789012345678901234' TO MQMD-CORRELID.
* MOVE MQCI-NONE TO MQMD-CORRELID.
* MOVE MQ-CORRELID TO MQMD-CORRELID.
MOVE MQENC-NATIVE TO MQMD-ENCODING.
MOVE MQCCSI-Q-MGR TO MQMD-CODEDCHARSETID.
*
COMPUTE MQGMO-OPTIONS = MQGMO-WAIT +
MQGMO-CONVERT +
MQGMO-ACCEPT-TRUNCATED-MSG +
MQGMO-NO-SYNCPOINT +
MQGMO-FAIL-IF-QUIESCING.
* Wait up to 30 seconds.
MOVE MQ-WAIT-TIME TO MQGMO-WAITINTERVAL.
|
Please let me know if there is any other information I should provide. Any insight would be greatly appreciated.
Thanks,
Mark |
|
| Back to top |
|
 |
| Vitor |
| Posted: Wed Aug 29, 2007 5:09 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
Moving aside from the code for a moment, if you're getting a message back if you don't search for a specific correlation id then what's the correlation id of the message you get? The almost too obvious explaination is that the responding application isn't setting it and hence you get a 2033 when you wait for a matching message to arrive.
Returning to the code for 1 important point: both the message id and the correlation id are byte arrays not strings. Do not treat them as strings, do not assign them as strings, in an ideal world don't assign them at all. There are multiple discussions on the board about why treating the ids as strings is a long & bumpy road to pain & misery.
Don't do it.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| kramsnilloc |
| Posted: Wed Aug 29, 2007 5:37 am Post subject: |
|
|
Newbie
Joined: 23 Aug 2007
Posts: 8
Location: Jacksonville, FL.
|
Thanks for the response, I'm feeling the 'pain & misery'...
As far as the CORRELID on the message I'm getting back, I think you may be on to something; after returning from the sucessful GET call, I display MQMD-CORRELID and it is blank. I was keeping track of the messages by putting my CORRELID string in a UUID on my XML message in order to track the rq/rs.
If I shouldn't derive my own CORRELID, do I need to specify MQPMO-NEW-CORREL-ID as a put option?
When I use MQPMO-NEW-CORREL-ID as a put option, the PUT returns a 2046 - MQRC_OPTIONS_ERROR |
|
| Back to top |
|
|
| zpat |
| Posted: Wed Aug 29, 2007 5:54 am Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
Location: UK
|
The server application should be turning around your request message's MSGID value as it's reply message CORRELID value.
Since you know (or can get) the the value of your request message MSGID on the MQPUT you can use this as the value to match CORRELID on the MQGET.
However this relies on the other application behaving in the way I have described.
It's best to test a message based application in parts, use RFHUTILC to send test requests and make sure the reply messages look correct on the reply queue before trying to make it all work end to end. |
|
| Back to top |
|
|
| Vitor |
| Posted: Wed Aug 29, 2007 5:56 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
The accepted pattern is you to generate a new msg id on the put, and for the replying application to honour the message type of request by setting the correlation id of the reply to be the message id of the request.
If it's coming back blank then it sounds like this is not happening. If you've got the id in the XML itself then you can't get the specific reply - the get call can't see content.
You might want to consider dynamic reply queues if this is indeed the case.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Wed Aug 29, 2007 7:06 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
| Vitor wrote: |
| You might want to consider dynamic reply queues if this is indeed the case. |
Optomistic to think they will respect the Reply To Queue when they don't respect the Report Options.  If I had to bet, I would say kramsnilloc had to define a remote q def on the replying side hard wired to the reply to queue on the requesting side.
OR, maybe they DO respect the MQMD Report Options, and kramsnilloc needs to set the Pass Correl ID option, although Message ID to Correl ID is usually the best pattern.
MQMD-CORRELID is a Pic X(24) field by the way. Moving "1234.." to it is valid as long as the replying side doesn't try to pull meaning out of it. To them it will look like a bunch of EBCIDIC garbage. But if they just pass it as requested in the Report Options, that works fine. We do that here for 1 app where we put a TCN and time stamp into the Correl ID. Its unique and allows us to track the message as it flys through the system.
(But as suggested letting the QM generate your IDs is the way to go if you want to insure unique IDs)
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| Vitor |
| Posted: Wed Aug 29, 2007 7:14 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| PeterPotkay wrote: |
| MQMD-CORRELID is a Pic X(24) field by the way. |
Granted absolutely it's a PIC X not a PIC A, but a lot of people equate character with PIC X.
What I was driving at was the more general point of not treating it conceptually as a string, because from there it's a brief jump to sticking serial numbers, names and all sorts in there.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| kramsnilloc |
| Posted: Wed Aug 29, 2007 7:44 am Post subject: |
|
|
Newbie
Joined: 23 Aug 2007
Posts: 8
Location: Jacksonville, FL.
|
Again, thanks for the input...
It turns out that nothing special was being done on the server side in regards to maintaining or populating the CORRELID (or the MsgId) when sending the response message back to me. My bad for assuming that is was. That is being taken care of and I hope to retest soon.
Just to be clear, when I was testing, I generated the CORRELID using a combination of a unique reference number, date and time. Besides assigning this value to the CORRELID I was also putting it into a UUID in my XML so I could track the message.
My main reason for generating my own CORRELID was so that I could re-create it it needed, and be able to relate it back to the specific reference number of the request.
We plan on trying the pattern mentioned; MSGID on PUT goes into CORRELID on GET.
Thanks again...
Mark |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Wed Aug 29, 2007 1:53 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
And just to be clear:
Your server application needs to check first if the correlation Id is populated (something else than 00 bytes) and if this is the case the correlation id is a pass through.
If the correlation Id is not populated the messageId should be returned in the correlId field, (standard) or it should honor the set option (msgid to msgid) ?
You have an aggravating factor as you involve as well SonicMQ. You need now to make sure that the SonicMQ can preserve its equivalent of the messageid/correlId and will set it correctly on the response message.
Don't know about Sonic's implementation of the messageId/CorrelationId. Don't know about your implementation of the SonicMQ to IbmMQ bridge...
Worst case scenario:
You might end up having to write 2 additional programs that move the id content to the message and extract the id content from the message and set it back onto the MQHeader, just so that you can implement the regular request / response pattern...
Hope this helps 
_________________
MQ & Broker admin
Last edited by fjb_saper on Wed Aug 29, 2007 1:55 pm; edited 1 time in total |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Wed Aug 29, 2007 1:54 pm Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
Actually, there are report options on the message that should be used to indicate if the MsgId should be passed, or the CorrelID passed, or etc.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| kramsnilloc |
| Posted: Thu Aug 30, 2007 6:58 am Post subject: |
|
|
Newbie
Joined: 23 Aug 2007
Posts: 8
Location: Jacksonville, FL.
|
| fjb_saper wrote: |
Your server application needs to check first if the correlation Id is populated (something else than 00 bytes) and if this is the case the correlation id is a pass through.
If the correlation Id is not populated the messageId should be returned in the correlId field, (standard) or it should honor the set option (msgid to msgid) ?
|
This is exactly how (standard) the ESB code has been modified...and now I'm able to sucessfully get back my correlated response using either MSGID (in CORRELID on GET) or the application derived CORRELID.
If I had posted this several days ago, my head would not be so red for hitting it against the wall.
Thanks for all the responses...now it on to how to create a UUID in COBOL?!?
Mark Collins |
|
| Back to top |
|
|
|
|
