| Author |
Message
|
| bvasanth |
 Posted: Tue Aug 24, 2004 6:30 am Post subject: CICS Conversation Task using MQ-CICS Bridge |
 |
|
Apprentice
Joined: 03 May 2004
Posts: 27
Location: Chennai, India
|
I am writing a java client to execute a CICS conversation transaction using MQ-CICS bridge.
(This conversation program uses SEND TEXT and RECEIVE instructions)
while starting the conversation transaction, I specify the following in MQCIH
| Code: |
//specific fields mentioned below
msg.correlationId = MQC.MQCI_NEW_SESSION;
msg.messageId = MQC.MQMI_NONE;
msg.writeInt(273) //for MQCUOWC_ONLY in UOW field
msg.writeInt(1); //1-ConversationTask; Whether task can be conversational |
I look for reply queue with correlId. The above message is sucessfully getting exexuted, and CICS application sends a reply message with SEND TEXT vector along with RECEIVE request.
Now, I build new message as follows to send back reply as RECEIVE vector.
| Code: |
msg.correlationId = <<msg id of previous reply msg>>;
msg.messageId = MQC.MQMI_NONE;
msg.writeInt(65536) //for MQCUOWC_CONTINUE in UOW field
msg.writeInt(1); //1-ConversationTask; Whether task can be conversational |
Now I look for reply queue with correlId. But I am not getting any reply message.
Is that something I am missing here like GMO/PMO options, or else? |
|
| Back to top |
|
 |
| EddieA |
| Posted: Tue Aug 24, 2004 10:47 am Post subject: |
|
|
Jedi
Joined: 28 Jun 2001
Posts: 2453
Location: Los Angeles
|
On the 2nd, and subsequent messages, aren't you supposed to maintain the MessageID you got when you sent the intial message: msg.messageId = <msg id of previous msg>;
You have: msg.messageId = MQC.MQMI_NONE; which will generate a new ID.
Cheers,
_________________
Eddie Atherton
IBM Certified Solution Developer - WebSphere Message Broker V6.1
IBM Certified Solution Developer - WebSphere Message Broker V7.0 |
|
| Back to top |
|
|
| bvasanth |
| Posted: Tue Aug 24, 2004 7:12 pm Post subject: |
|
|
Apprentice
Joined: 03 May 2004
Posts: 27
Location: Chennai, India
|
Hi,
The IBM manual "MQSeries Application Programming Guide" chapter 16 page 258 Fig 17 provides a diagrams that shows msg id being set to correl id of subsequent messages of conversation task.
Can you check that documentation and let me know what is missing?
Thanks |
|
| Back to top |
|
|
| bob_buxton |
| Posted: Wed Aug 25, 2004 5:02 am Post subject: |
|
|
Master
Joined: 23 Aug 2001
Posts: 266
Location: England
|
| EddieA wrote: |
On the 2nd, and subsequent messages, aren't you supposed to maintain the MessageID you got when you sent the intial message: msg.messageId = <msg id of previous msg>;
You have: msg.messageId = MQC.MQMI_NONE; which will generate a new ID.
Cheers, |
No, all messages should have a unique message id. It is the correlid that must be the message id of the first message.
Are you seeing any error messages on the CICS job log?
Is the second message being removed from the Queue?
What is the message type of the 1st reply? It should be MQMT_REQUEST if the transaction is expecting more input.
_________________
Bob Buxton
Ex-Websphere MQ Development |
|
| Back to top |
|
|
| bvasanth |
| Posted: Wed Aug 25, 2004 5:54 am Post subject: |
|
|
Apprentice
Joined: 03 May 2004
Posts: 27
Location: Chennai, India
|
1) The 1st reply message of this convesation has message type as MQMT_REQUEST (VALUE 1), and all pseudo-conversation has MQMT_REPLY (value 2).
2) For the first request message of conversational task, I set UOW value in CIH as 273 (MQCUOWC_ONLY), and After getting 1st reply, I build next request message with msg id of reply into correl id of new request, and set the UOW value to 65536 (MQCUOWC_CONTINUE). Now I get some reply from CICS bridge. That 2nd reply has Return code of 8 (MQCRC_BRIDGE_TIMEOUT), comp code of 2 and reason code 2033. |
|
| Back to top |
|
|
| bob_buxton |
| Posted: Wed Aug 25, 2004 6:24 am Post subject: |
|
|
Master
Joined: 23 Aug 2001
Posts: 266
Location: England
|
Did your resolve the problem with setting Correlid that you reported in another post?
The time out reply implies that the bridge did not find a message with the expected correlid within the wait time. Presumably your wait time in MQCIH.GetWaitInterval is long enough (it is in milliseconds)? The time difference between the two replies will show how long it actually waited.
_________________
Bob Buxton
Ex-Websphere MQ Development |
|
| Back to top |
|
|
| bvasanth |
| Posted: Wed Aug 25, 2004 6:35 am Post subject: |
|
|
Apprentice
Joined: 03 May 2004
Posts: 27
Location: Chennai, India
|
You are God man...
I overlooked the getwaitinterval time. It was set to 0 due to previous pseudo-conversation tasks...Now I had set it to some higher value..Conversation is working excellent.... 
Thanks a lot Bob. I owe many thanks. |
|
| Back to top |
|
|
| bvasanth |
| Posted: Thu Aug 26, 2004 7:20 am Post subject: |
|
|
Apprentice
Joined: 03 May 2004
Posts: 27
Location: Chennai, India
|
Bob Buxton,
I have doubt on setting getWaitInterval on CIH for conversational task. My CICS application shows a first page of report using SEND TEXT, and waits of user response like enter key. If user presses enter key, it shows next page, then again waits for key press.
I do not have any idea of how many pages report may have.
For the first request of this transaction, I set a specific getwaitinterval on CIH. WHen report has less pages it works fine. But when report pages goes up, it fails after few pages with MQ 2033 reason code (becos I set my gmo wait time as 15 secs). If I increases waittime in CIH, it works fine for bigger reports, but fails for report with smaller pages (i,e smaller conversation).
How do I calculate waittime for CIH, and what is it exact meaning?
Basically for lengthy conversation, it requires bigger timeinterval. For shorty one, it requires less waitinterval in CIH. But I have no way to tell whether conversation will take longer or shorter
Thanks |
|
| Back to top |
|
|
| bob_buxton |
| Posted: Thu Aug 26, 2004 7:50 am Post subject: |
|
|
Master
Joined: 23 Aug 2001
Posts: 266
Location: England
|
I don't understand! How is it failing when you have a large getwait time.
The GetWaitInterval is the maximum time the bridge will wait for the next input message, if a message arrives within that time it will be processed as soon as it arrives.
It should be independent of the length of the conversation.
When you start the transaction it should respond with a message containing the first screen of ouput. Your application should then send a message correponding to the Enter key press to get the next screen out as the next reply. This would continue until the contact admin indicates
end of output.
The wait interval applies between the transaction sending a page of output and receiving the next enter
_________________
Bob Buxton
Ex-Websphere MQ Development |
|
| Back to top |
|
|
| bvasanth |
| Posted: Thu Aug 26, 2004 7:59 am Post subject: |
|
|
Apprentice
Joined: 03 May 2004
Posts: 27
Location: Chennai, India
|
| Should I set waitinterval in subsequent reply messages from java client or only in first message from client. |
|
| Back to top |
|
|
| bob_buxton |
| Posted: Thu Aug 26, 2004 9:08 am Post subject: |
|
|
Master
Joined: 23 Aug 2001
Posts: 266
Location: England
|
In every message
_________________
Bob Buxton
Ex-Websphere MQ Development |
|
| Back to top |
|
|
| bvasanth |
| Posted: Fri Aug 27, 2004 4:36 am Post subject: |
|
|
Apprentice
Joined: 03 May 2004
Posts: 27
Location: Chennai, India
|
I found out the problem (I think so)
Our client has configure qMGR as Queue Sharing group. So while getting queue manager, we do not specify any manager name. We are automatically allocated with one of two queue managers (queue names are same in both managers). So everytime I put a conversational message, I may get different manager, and hence bridge could not find appropriate message with original manager name as in first request. Hence it fails randomly.. When I keep the same queue manager for entire conversation, it works fine.
SO, I would like to know how MQ-CICS bridge looks for response (like queue manager, corrlid, queue name or any other parameter) from client during conversation. |
|
| Back to top |
|
|
|
|
