| Author |
Message
|
| prabuk |
 Posted: Wed Apr 21, 2004 8:23 am Post subject: Message is lost when receiving from Mainframe - SOLVED |
 |
|
Novice
Joined: 14 Mar 2003
Posts: 19
Location: JerseyCity, NJ
|
We have a strange problem. My application require to communicate with mainframe system. With NONJMS switch on my side and MQSTR format setting on mainframe side, we could send and receive messages asynchronusly. MQ API automatically converts data from ASCII to EBCDIC and vice-versa. There is no problem with that.
Then we wanted to test synchrounus communication -
1. JMS client app sends a request to mainframe
2. Mainframe side, my customer has setup trigger and they receive the message and they could read and he constructs the response message and sends it back with original msg id as the new msg's correl id.
3. On our side (JMS app), after sending the request, app is waiting to receive message with corrrel id with request msg's msgid. It actually receives the message and the message also comes as text message. But the text message is blank. But on mainframe side, MQ admin saw it on the transmit queue that the message content is there with the sample data.
What could be the reason? Where the message data is missing. my customer modified the same program to just send a message on trigger without reading the request, then I could get the complete data. Only if he reads the request, when he sends the message, I'm not seeing the message data. I don't have experience in Maianframe/Cobol MQ.
Thanks for your help.
I have a JMS application (client) which sends a request to
Last edited by prabuk on Wed Apr 21, 2004 12:07 pm; edited 1 time in total |
|
| Back to top |
|
 |
| jefflowrey |
| Posted: Wed Apr 21, 2004 8:39 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
Have you manually verified that the reply message being sent by the mainframe is correct?
Have you verified that your JMS code can read a properly formatted reply message?
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| prabuk |
| Posted: Wed Apr 21, 2004 8:55 am Post subject: |
|
|
Novice
Joined: 14 Mar 2003
Posts: 19
Location: JerseyCity, NJ
|
| Quote: |
Have you manually verified that the reply message being sent by the mainframe is correct?
|
Yes, our mq admin examined the message. When he costructs the message asynchronusly, then the mq admin can view and see the message in the mq. But when he replies for my message, (actually he just reads and he consutructs a new message not even taking the corel id) I get blank text message. MQ admin couldn't read this message, I think it is in EBCDIC format. Here is where I suspect, really when we are getting the message from mainframe and there is no channel convertion done, and the message is on solaris side mq, the message should be in EBCDIC format right?
| Quote: |
Have you verified that your JMS code can read a properly formatted reply message?
|
Actually it is not a formated message. In fact, he constructs the same message as he sends asynchonusly, which I could read. |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Wed Apr 21, 2004 9:15 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
| prabuk wrote: |
Actually it is not a formated message. In fact, he constructs the same message as he sends asynchonusly, which I could read. |
If you can read it with the same code one way, and not the other, then it's not the same message.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| prabuk |
| Posted: Wed Apr 21, 2004 9:21 am Post subject: |
|
|
Novice
Joined: 14 Mar 2003
Posts: 19
Location: JerseyCity, NJ
|
jefflowrey
Sorry i didn't explain it properly.
| Quote: |
Have you verified that your JMS code can read a properly formatted reply message? |
As I explained before I could read the message when he sends in asynchronus mode. My customer is sending the same message synchronusly after reading my request message. There is no pre-foramting required.
Thanks |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Wed Apr 21, 2004 9:27 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
| prabuk wrote: |
| My customer is sending the same message synchronusly after reading my request message. |
No, they aren't. If the same piece of code can read one message, but it can't read another message, then the two messages AREN'T the same message.
| prabuk wrote: |
| There is no pre-foramting required. |
I meant that have you separately verified that your code can actually process messages, regardless of the source of the message?
I'm not talking about any particular data-level formatting.
I should probably have used the word "constructed" instead of "formatted".
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| mqonnet |
| Posted: Wed Apr 21, 2004 10:32 am Post subject: |
|
|
Grand Master
Joined: 18 Feb 2002
Posts: 1114
Location: Boston, Ma, Usa.
|
Add a few more pointers to what jeff mentioned.
"MQ admin saw it on the transmit queue that the message content is there with the sample data."
-Does this mean you stopped the sdr channel on the remote end and physically saw the messages on xmitq. Because unless you do that you cannot ever view messages on xmitq. Because they are pulled off immediately by the mca, unless of course your xmitq is overloaded under stressful conditions.
"Have you manually verified that the reply message being sent by the mainframe is correct?
Yes, our mq admin examined the message. When he costructs the message asynchronusly, then the mq admin can view and see the message in the mq. But when he replies for my message, (actually he just reads and he consutructs a new message not even taking the corel id) I get blank text message. "
-As jeff asked you, earlier you said you verified this on Xmitq of the sdr and later you say you verified it by seeing the message. Not sure what that means. Does that mean you were debugging the app? Or does it mean your app is writing the message to the output terminal?
"On our side (JMS app), after sending the request, app is waiting to receive message with corrrel id with request msg's msgid. It actually receives the message and the message also comes as text message. But the text message is blank."
-Try using the same triggered app on the remote end to put to a local queue and run amqsbcg to see if the message data is being retrieved locally at least. Because, channels, conversion etc would come into picture only after the message is successfully put with the message data. Assuming that there is some conversion problem, even then you would usually expect either of the 2, 1) message is retrieved but is non-readable because it wasnt converted. 2) message is converted and is readable. I cant think of any reason why the actual message data would be lost.
MQ does NOT touch the messae data at any time. It just carries around depending upon your design.
Lastly, check the reply app to see if the buffer before put actually has appropriate message data.
Cheers
Kumar |
|
| Back to top |
|
|
| prabuk |
| Posted: Wed Apr 21, 2004 11:10 am Post subject: |
|
|
Novice
Joined: 14 Mar 2003
Posts: 19
Location: JerseyCity, NJ
|
| Quote: |
-Does this mean you stopped the sdr channel on the remote end and physically saw the messages on xmitq. Because unless you do that you cannot ever view messages on xmitq. Because they are pulled off immediately by the mca, unless of course your xmitq is overloaded under stressful conditions.
"Have you manually verified that the reply message being sent by the mainframe is correct? |
That's right, our mainframe MQ admin stoped the channel and checked in the xmit q. I didn't check, but our MQ admin checked and tells me that he is seeing the message.
| Quote: |
| -As jeff asked you, earlier you said you verified this on Xmitq of the sdr and later you say you verified it by seeing the message. Not sure what that means. Does that mean you were debugging the app? Or does it mean your app is writing the message to the output terminal? |
Let me calrify before that let me tell you that we are discussing here about two scenarios -
A. Mainframe App directly constructing a message
B. Mainframe App reads our request and constructs a new reply message
MQ adminstrator on solaris side, checked the local queue on solaris side. the message was readable (ASCII) if the mainframe app has constructed a new message without reading our request, we could say asynchronus mode (scnario A).
But if mainframe app reads our request (scenario B) and constructs a reply message (i agree with Jeff that it is a separate message, I'm not having any doubt about it), then solaris mq admin tells us that the message on the queue is not in readable format (means EBCDIC)?
First of all my basic question is, when a mainframe app sends a message and there is no channel data convertion setup, if that is the case, mq on soliris side should be in EBCDIC format right?
The message will be converted to ASCII only when receiving app issues jms receive api call. Is n't it. Please clarify me.
| Quote: |
| 1) message is retrieved but is non-readable because it wasnt converted. 2) message is converted and is readable. |
As for as the my JMS app is concerned, it is just the same code.
| Quote: |
msg = cliQReceiver.receive(10000);
if (msg == null) {
System.out.println("No reply message retrieved");
replyString = replyString + "No Message Received from the queue::";
} else {
if (msg instanceof BytesMessage) {
replyString = replyString + "Received Bytes Message from the Queue: Message Received [" + ((BytesMessage)msg).toString()+ "]::";
}
else if (msg instanceof TextMessage) {
replyString = replyString + "Received Text Message from the Queue: Message Received [" + ((TextMessage)msg).getText() + "]::";
}
else
{
replyString = replyString + "Invalid message not a Bytes Or Text Message";
}
}
|
For scenario A - It goes into the TextMessage if condition nd prints the text message.
For scenario B - It goes into the TextMessage if condition and prints the text messge as blank.
Thanks |
|
| Back to top |
|
|
| prabuk |
| Posted: Wed Apr 21, 2004 11:14 am Post subject: |
|
|
Novice
Joined: 14 Mar 2003
Posts: 19
Location: JerseyCity, NJ
|
My customer has given his COBOL code, let me know if there is any problem with the code...
Thanks
| Quote: |
S300-000-PROCESS-INQUIRY SECTION.
IF WH-HMO-COMPCODE = MQCC-OK
PERFORM S820-000-GET-MSG
IF WH-HMI-COMPCODE = MQCC-OK
* PERFORM S450-000-PROCESS-IN270
PERFORM S830-000-PUT-MSG
ELSE
* CHECK FOR END OF QUE
MOVE 'Y' TO WK-000-QUE-SW
END-IF
ELSE
* ERROR OCCURED ON LAST WRITE TO QUE 271.
MOVE 'Y' TO WK-000-QUE-SW
END-IF.
S820-000-GET-MSG SECTION.
S820-010-START.
COMPUTE MQGMO-OPTIONS = MQGMO-WAIT +
MQGMO-SYNCPOINT +
MQGMO-ACCEPT-TRUNCATED-MSG +
MQGMO-FAIL-IF-QUIESCING.
*
MOVE MQMI-NONE TO MQMD-MSGID.
MOVE MQCI-NONE TO MQMD-CORRELID.
*
MOVE LENGTH OF WK-HEALTH-MATCH-RECORD
TO WH-HMI-BUFFLEN.
*
CALL 'MQGET' USING WH-HMI-HCONN
WH-HMI-HOBJ
MQMD
MQGMO
WH-HMI-BUFFLEN
WK-HEALTH-MATCH-RECORD
WH-HMI-DATALEN
WH-HMI-COMPCODE
WH-HMI-REASON.
. . . . . . . . . . . . . . . . . . . . .
*
IF WH-HMI-COMPCODE = MQCC-OK
MOVE MQMD-CORRELID TO WH-CORRELID
MOVE MQMD-MSGID TO WH-MSGID
EXEC CICS SYNCPOINT
RESP (WH-000-CICS-RESP)
END-EXEC
IF WH-000-CICS-RESP NOT EQUAL DFHRESP (NORMAL)
MOVE WK-C05-ABORT-MSG-CODE (+13)
TO W1490011-SYSTEM-MSG-CODE
MOVE 'S450'
TO W1490011-PGM-PARAGRAPH
MOVE DFHEIBLK
TO W1490011-PGM-MSG-TEXT
PERFORM S999-000-ABEND
END-IF
ELSE
* CHECK FOR END OF QUE AND DONT LOG MESSAGE.
IF WH-HMI-REASON = MQRC-NO-MSG-AVAILABLE
MOVE 'Y' TO WK-000-QUE-SW
GO TO S820-999-EXIT
ELSE
MOVE 'MQ GET MESSAGE FAILED'
TO W1490011-PGM-MSG-TEXT
MOVE WK-C04-ERROR-MSG-CODE (+24)
TO W1490011-SYSTEM-MSG-CODE
PERFORM S998-000-CALL-MESSENGER
MOVE 'Y' TO WK-000-QUE-SW
GO TO S820-999-EXIT
END-IF
END-IF.
*
*
S820-999-EXIT.
EXIT.
/
*
S830-000-PUT-MSG SECTION.
S830-010-START.
*
*
MOVE MQFMT-STRING TO MQMD-FORMAT.
MOVE WH-MSGID TO MQMD-CORRELID.
*
COMPUTE MQPMO-OPTIONS = MQPMO-SYNCPOINT +
MQPMO-FAIL-IF-QUIESCING.
*
*
MOVE 150
TO WH-HMO-BUFFLEN.
*
*
CALL 'MQPUT' USING WH-HMO-HCONN
WH-HMO-HOBJ
MQMD
MQPMO
WH-HMO-BUFFLEN
WK-OUTPUT-HEALTH-MATCH-RECORD
WH-HMO-COMPCODE
. . . . . . . . . . . . . . . . . . . . .
WH-HMO-REASON.
*
IF WH-HMO-COMPCODE = MQCC-OK
EXEC CICS SYNCPOINT
RESP (WH-000-CICS-RESP)
END-EXEC
IF WH-000-CICS-RESP NOT EQUAL DFHRESP (NORMAL)
MOVE WK-C05-ABORT-MSG-CODE (+13)
TO W1490011-SYSTEM-MSG-CODE
MOVE 'S830'
TO W1490011-PGM-PARAGRAPH
MOVE DFHEIBLK
TO W1490011-PGM-MSG-TEXT
PERFORM S999-000-ABEND
END-IF
ELSE
MOVE 'MQ PUT MESSAGE FAILED'
TO W1490011-PGM-MSG-TEXT
MOVE WK-C04-ERROR-MSG-CODE (+23)
TO W1490011-SYSTEM-MSG-CODE
. . . . . . . . . . . . . . . . . . . . .
PERFORM S998-000-CALL-MESSENGER
MOVE 'Y' TO WK-000-QUE-SW
GO TO S830-999-EXIT
END-IF.
*
S830-999-EXIT.
EXIT. |
|
|
| Back to top |
|
|
| prabuk |
| Posted: Wed Apr 21, 2004 11:27 am Post subject: |
|
|
Novice
Joined: 14 Mar 2003
Posts: 19
Location: JerseyCity, NJ
|
Probably I found the problem, my customer is using the same MQMD data area to get and put. So whatever he gets interms of MQMD in GET he tries to send as part of PUT. Probably this is what corrupts the data. Anyway, he is tring to create new MQMD for PUT. Will let you know if that solves the problem.
Thanks |
|
| Back to top |
|
|
| prabuk |
| Posted: Wed Apr 21, 2004 12:06 pm Post subject: Message is lost when receiving from Mainframe - SOLVED |
|
|
Novice
Joined: 14 Mar 2003
Posts: 19
Location: JerseyCity, NJ
|
Yes the problem was because of the MQMD. Not it is working fine.
Thanks for your responses... |
|
| Back to top |
|
|
|
|
