Peter Reading between the lines
"Specifying MQCI_NONE as the correlation identifier has the same effect as not specifying MQMO_MATCH_CORREL_ID, that is, any correlation identifier will match. " 1. Specifying MQCI_NONE as the correlation identifier will have different effects depending upon what you specify in Match Options MQMO_MATCH_CORREL_ID=> It will match any CORR ID MQMO_NONE==> Doesn't matter what if its MQCI_NONE cos its will be ignored 2. Not specifying MQMO_MATCH_CORREL_ID option means any value in that field will be ignored (including MQCI_NONE). --Arun ================ Here is a quote from the programming reference manual in the section where it talks about the CorrelID. Read between the lines on this! "Specifying MQCI_NONE as the correlation identifier has the same effect as not specifying MQMO_MATCH_CORREL_ID, that is, any correlation identifier will match. " So what effect do you get when you do specify something?!? You match! All the MQ classes I ever took and all the advice I ever got was ALWAYS init your messageid field and CorrelID field before the get, unless you plan on matching on the value that is in those fields. Actually, I did find a situation where these options were required, and that is when we were developing our VB MQ wrapper using ActiveX. For some reason, when using VB/ActiveX, we could not match unless we used these options. Every other language, it has been my experience that those options were not needed. -----Original Message----- From: Jeff Orris [mailto:[EMAIL PROTECTED] Sent: Friday, July 25, 2003 8:20 AM To: [EMAIL PROTECTED] Subject: Re: GET 3270 Bridge Reply If that's the case, then what is the purpose of MATCHOPTIONS? The Application Programming Reference states, "Fields for which the corresponding match option is not specified are ignored when selecting the message to be returned." Regarding MQMO_MATCH_MSG_ID, it states "If this option is not specified, the MsgId field in the MsgDesc parameter is ignored, and any message identifier will match." Regarding MQMO_MATCH_CORREL_ID, it states "If this option is not specified, the CorrelId field in the MsgDesc parameter is ignored, and any correlation identifier will match." "Potkay, Peter M (PLC, IT)" To: [EMAIL PROTECTED] <[EMAIL PROTECTED] cc: RTFORD.COM> Subject: Re: GET 3270 Bridge Reply Sent by: MQSeries List <[EMAIL PROTECTED] AC.AT> 07/24/03 10:08 PM Please respond to MQSeries List If you populate the message id with the original message id and CorrelID field with MQCI-NEW-SESSION prior to the get, then MQ will only return messages that have BOTH the original message id in the message id of the reply AND a correl id of MQCI-NEW-SESSION. Since none of your reply messages have a correl id with a value of MQCI-NEW-SESSION, your get fails. Note that MQCI-NEW-SESSION has a value of X'414D51214E45575F53455353' X'494F4E5F434F5252454C4944' , which is not the same as MQCI_NONE, which has a value of X'00...00' (24 nulls). If all you want to match on is the message id, then what you want to populate the correl id field with prior to issuing the get is MQCI_NONE. This will tell MQ to ignore any correl id values in the reply messages. You don't really need to specify the MATCH options. If your message id has anything other than MQMI_NONE, than MQ will attempt to match on that value, whether you have the match option for message id specified or not. If your correl id has anything other than MQCI_NONE, than MQ will attempt to match on that value, whether you have the match option for correl id specified or not. And if you have both fields populated with anything other than MQ*I_NONE, then both fields will be used for matching, regardless of whether you have the message id /correl id matching options set or not. -----Original Message----- From: Jeff Orris [mailto:[EMAIL PROTECTED] Sent: Thursday, July 24, 2003 5:31 PM To: [EMAIL PROTECTED] Subject: Re: GET 3270 Bridge Reply 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. Thanks Dennis -- and to everyone else who contributed. Jeff "Miller, Dennis" <[EMAIL PROTECTED] To: [EMAIL PROTECTED] COM> cc: Sent by: Subject: Re: GET 3270 Bridge Reply MQSeries List <[EMAIL PROTECTED] en.AC.AT> 07/24/03 03:09 PM Please respond to MQSeries List You are correct, the batch program must commit the request message before it does an MQGET to wait for the reply. However, since you can see the reply message with your browse utility, that doesn't sound like the problem. If you want to use match on MSGID, then you should specify MD.RO_PASS_MSG_ID, otherwise the bridge will generate a unique msgid for the response. Alternatively, you could use the more conventional approach which is MD.RO_COPY_MSGID_TO_CORELID in which case you match on CORELID after seeding it with the MSGID returned from the MQPUT. regards, Dennis > -----Original Message----- > From: Jeff Orris [SMTP:[EMAIL PROTECTED] > Sent: Thursday, July 24, 2003 7:33 AM > To: [EMAIL PROTECTED] > Subject: GET 3270 Bridge Reply > > 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 MQRC_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). > > I'm guessing 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. > > Any ideas or suggestions? > > Jeff Orris > > > > > This message contains privileged and confidential information intended for the > above addressees only. If you receive this message in error please delete or destroy > this message and any accompanying documentation after contacting the sender. The > sender of this message will fully cooperate in the civil and criminal prosecution of > any individual engaging in the unauthorized use of this message. > > Instructions for managing your mailing list subscription are provided in > the Listserv General Users Guide available at http://www.lsoft.com > Archive: http://vm.akh-wien.ac.at/MQSeries.archive Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive This message contains privileged and confidential information intended for the above addressees only. If you receive this message in error please delete or destroy this message and any accompanying documentation after contacting the sender. The sender of this message will fully cooperate in the civil and criminal prosecution of any individual engaging in the unauthorized use of this message. Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive This communication, including attachments, is for the exclusive use of addressee and may contain proprietary, confidential or privileged information. If you are not the intended recipient, any use, copying, disclosure, dissemination or distribution is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by return email and delete this communication and destroy all copies. Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive This message contains privileged and confidential information intended for the above addressees only. If you receive this message in error please delete or destroy this message and any accompanying documentation after contacting the sender. The sender of this message will fully cooperate in the civil and criminal prosecution of any individual engaging in the unauthorized use of this message. Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive
