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
