| Author |
Message
|
| Priya |
 Posted: Wed Mar 27, 2002 9:33 am Post subject: |
 |
|
Apprentice
Joined: 20 Mar 2002
Posts: 26
|
When the application puts the message from the MQClient on AIX in the queue on the Mainframe, if I select the report options and the Reply to Q(RTQ) and Reply to the Qmanager as the same in which I put the message.
1) how the application is informed about the report messages?
2) I am not going to get any message from the queue where I put the message. So Should I specify the RTQ as the queue, which I am using to get the message or the queue I am using to put the message?
3) Is that possible, my application can send any exception report to indicate that the message that it has received cannot be processed for some application specific reason? How? Should I assign any message id of the request message to the report message?
please help me out....
Thanks |
|
| Back to top |
|
 |
| mqonnet |
| Posted: Wed Mar 27, 2002 9:44 am Post subject: |
|
|
Grand Master
Joined: 18 Feb 2002
Posts: 1114
Location: Boston, Ma, Usa.
|
I would suggest you to take some time out and read through the books and manuals such as "Application programming guide" and "Application programming reference". Because all the questions and doubts you have posted so far are very basic and all of them are well explained in these books. In some cases even with examples.
Cheers.
Kumar
_________________
IBM Certified WebSphere MQ V5.3 Developer
IBM Certified WebSphere MQ V5.3 Solution Designer
IBM Certified WebSphere MQ V5.3 System Administrator |
|
| Back to top |
|
|
| Priya |
| Posted: Thu Mar 28, 2002 6:51 am Post subject: |
|
|
Apprentice
Joined: 20 Mar 2002
Posts: 26
|
I am very new to MQSeries. I have read the books already. As I do not have a practical experience. I am finding the following difficulties…
I have a InputQ and OutputQ in remote machine. I have to get the request from the InputQueue, Process it and send the Reply to the output Q from my machine using MQClient.
1)If the request message specifies the Report Option COA and COD QMgr will send the reports to the RTQ. So In my side I do not need to do anything. When sending the reply back I want to set the report options COA and COD. So the Qmgr on the remote machine puts the COA and COD in the InputQ(RTQ). While I am getting the message from the InputQ if the message type is request I will take it for processing. If it is a report and feedback says MQFB_COA or MQFB_COD then should I handle this in my program. Should my program analyse that this is a confirmation of which message or COD or COA is not generated for messages. Should my program check for each message COD and COA is generated or not? How it works normally?
any help is appreciated...
Thanks for your help in advance
[ This Message was edited by: Priya on 2002-03-28 07:40 ] |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Thu Mar 28, 2002 10:50 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7716
|
OK, I'm gonna give this a shot, but I think the reason you haven't seen more answers is cause it's kinda hard to understand your scenario.
From the way I understand your needs, this is what I would do.
On the Mainframe Qeueu Manager (QM1), define RequestQ1, ReplyQ1.
The client app (AppC) on AIX will connect to QM1, and put a request message onto RequestQ1. This request message will have it's COA and COD options set, and ReplytoQueue will be set to ReplyQ1. You can either leave ReplytoQueueManager blank (QM1 will fill it's own name in for you) or code QM1 yourself. AppC saves the MessageID of this request for later use.
QM1 will send a COA to ReplyQ1. This COA will have a CorrelID that is the MessageID of the request. The mainframe app (AppM) will pick up the message (QM1 will send a COD to ReplyQ2 (CorrelID is MessageID of request) and then AppM will send a reply message to ReplyQ1 (again CorrelID is MessageID of request).
AppC on the client side is watching ReplyQ1. It can immediatly go to ReplyQ1 and wait for all 3 messages (COA,COD,Reply) from a particular request, but this may be no good. What happens if the mainframe is down for a couple hours in the middle of the night? Better I think is for AppC to drop its request messages and then end or wait on ReplyQ1 for a few seconds and then end. Trigger ReplyQ1 to start up AppC whenever a message lands there.
Whenever AppC is triggered by MQ, it knows to go to ReplyQ1 and process any and all messages on the queue. As it picks up each message, it knows what kind it is (COA,COD,The real Reply) and handles appropriatly (maybe AppC has a database of outstanding messages it is waiting for, and at the end of the day if there are still any entries in the DB, you know you are missing stuff. Perhaps if the COA and COD made it for Request #123456789, but not the reply, you can say the mainframe got the message but didn't do it's job (Abend???)).
I hope this helps. Please post again if you have more questions.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| StefanSievert |
| Posted: Thu Mar 28, 2002 11:20 am Post subject: |
|
|
Partisan
Joined: 28 Oct 2001
Posts: 333
Location: San Francisco
|
Peter's reply says it all. I just want to add one thing:
You say you are connecting an AIX MQClient to the mainframe queue manager and process the messages right there.
In this scenario a COA report might not give you any information that you don't already have, because your MQRC=0 from the client's MQPUT is telling the same story, if the MF QMgr you connect to is the final destination of your message.
So why asking for a COA in the first place?
The COD tells you that the queue manager has delivered the message to an application that issued an MQGET. It's up to you what you do with this information in your program. There's simply no unique answer to your question. You could use the MQFB_COD report message to inform the end-user (if there is one), that something is processing the request; you could use it to measure the time it takes until the reply message comes back, or whatever. It's really up to you. If you don't need any of this, simply turn it of (MQRO_NONE).
Report messages ALWAYS got to the ReplyToQmgr/ReplyToQueue specified in the request message, so your client application will have to check (after the MQGET) for mqmd.MsgType = MQMT_REPORT and than do whatever you want to do with report messages. The server application should specify MQMT_REPLY on its reply, so it will be processed correctly.
Cheers,
Stefan
_________________
Stefan Sievert
IBM Certified * MQSeries
[ This Message was edited by: StefanSievert on 2002-03-28 11:24 ] |
|
| Back to top |
|
|
| mrlinux |
| Posted: Thu Mar 28, 2002 11:39 am Post subject: |
|
|
Grand Master
Joined: 14 Feb 2002
Posts: 1261
Location: Detroit,MI USA
|
Also one other thing if you are using MQSeries on the Mainframe as a Bridge to
IMS, then it doesnt support COA and COD.
_________________
Jeff
IBM Certified Developer MQSeries
IBM Certified Specialist MQSeries
IBM Certified Solutions Expert MQSeries |
|
| Back to top |
|
|
| StefanSievert |
| Posted: Thu Mar 28, 2002 1:22 pm Post subject: |
|
|
Partisan
Joined: 28 Oct 2001
Posts: 333
Location: San Francisco
|
Good catch, Jeff. However, it's only the COD options that are not supported if the target queue is an XCF queue (ie. IMS bridge queue).
COA's are generated by the message channel agent who lives outside of IMS.
Just do be a bit smartassy, hope you don't mind!
 Stefan
_________________
Stefan Sievert
IBM Certified * WebSphere MQ |
|
| Back to top |
|
|
| Priya |
| Posted: Thu Mar 28, 2002 2:17 pm Post subject: |
|
|
Apprentice
Joined: 20 Mar 2002
Posts: 26
|
| Thank you every one for your replies |
|
| Back to top |
|
|
| mrlinux |
| Posted: Fri Mar 29, 2002 4:24 am Post subject: |
|
|
Grand Master
Joined: 14 Feb 2002
Posts: 1261
Location: Detroit,MI USA
|
Stefan Sievert,
Well I have tested this is our enviorment and I have not been able to get either COA or COD from our IMS Bridge Queues
IBM OS/390 MQ v5.2 to Micorsoft NT 4.0sp6a MQ v5.2
_________________
Jeff
IBM Certified Developer MQSeries
IBM Certified Specialist MQSeries
[ This Message was edited by: mrlinux on 2002-03-29 04:25 ] |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Fri Mar 29, 2002 5:11 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7716
|
For what it's worth, I did see in the Application Prog. Reference manual under Report options in the MQMD section that CODs are not supported on XCF queues. The manual is silent on the issue in the COA section, so I assume it must be supported there???
Stefan,
1.) Do you have to do anything special to get a COA from a Bridge queue?
2.) How did you know XCF = Bridge queue? I can't find any documentation.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| mrlinux |
| Posted: Fri Mar 29, 2002 5:27 am Post subject: |
|
|
Grand Master
Joined: 14 Feb 2002
Posts: 1261
Location: Detroit,MI USA
|
Well the only info I have is that the storage class attribute of Queue Definition gives away that it is XCF (Cross Coupling Facility) Queue. Iam not sure if that is the info your are looking for
_________________
Jeff
IBM Certified Developer MQSeries
IBM Certified Specialist MQSeries
IBM Certified Solutions Expert MQSeries |
|
| Back to top |
|
|
| StefanSievert |
| Posted: Fri Mar 29, 2002 11:48 am Post subject: |
|
|
Partisan
Joined: 28 Oct 2001
Posts: 333
Location: San Francisco
|
Peter,
| Quote: |
On 2002-03-29 05:11, PeterPotkay wrote:
Stefan,
1.) Do you have to do anything special to get a COA from a Bridge queue?
2.) How did you know XCF = Bridge queue? I can't find any documentation.
|
ad 1) I will always trust the practical experiment over the documentation, so I will not question Jeff's statement that it obviously doesn't work. However, I recall having tried to get both reports while using a IMS bridge queue and only got the COA, not the COD. After reading the docs, I learned why. 
ad 2) as Jeff said, bridge queues are defined with the XCFGROUP and XCFMEMBER attributes in the corresponding storage class. That's why I (and other people as well) often refer to them as XCF queue. And it's much shorter to say than IMS Bridge queue. It might be ambigious now that shared queues (utilizing the CF) are available.
Happy Easter,
Stefan
_________________
Stefan Sievert
IBM Certified * MQSeries
[ This Message was edited by: StefanSievert on 2002-03-29 13:15 ] |
|
| Back to top |
|
|
|
|
