| Author |
Message
|
| eniomarques |
 Posted: Thu Aug 20, 2015 2:53 pm Post subject: Message not being read properly by mainframe application |
 |
|
Novice
Joined: 25 May 2015
Posts: 24
Location: Brazil
|
Hello everyone!
Could you please help me with the scenario below?
We have a new Java application who sends messages to a z/OS QM (v7.0.1) cluster queue, connecting thru an AIX QM (v7.5).
The problem is that the message content in the mainframe only starts after 72 bytes of data/dots, like MQSTR=...................TestMessage
But, while testing with MQMon, I was able to put a message that was read normally by the mainframe.
This seems to be a problem in the way that the message is being sent, as the channels configuration are the same (comparing the MQMon and the App Channel).
I've done a trace of both messages, and that blank part of the message descriptor from the application message is bothering me
Application:
[img]http://i.imgur.com/ByqnvXf.jpg?1[/img]
MQMon:
[img]http://i.imgur.com/hPtOtOT.jpg?1[/img]
Thanks in advance! |
|
| Back to top |
|
 |
| bruce2359 |
| Posted: Thu Aug 20, 2015 4:13 pm Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
Dots are not blanks on z/OS. What utility did you use to display the message on z/OS? Display both hex and character, and post here.
_________________
I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live. |
|
| Back to top |
|
|
| eniomarques |
| Posted: Fri Aug 21, 2015 8:48 am Post subject: |
|
|
Novice
Joined: 25 May 2015
Posts: 24
Location: Brazil
|
| bruce2359 wrote: |
| Dots are not blanks on z/OS. What utility did you use to display the message on z/OS? Display both hex and character, and post here. |
Hello Bruce!
The mainframe team is using a mainframe debugger, called Xpediter(IBM tool).
This is what they are getting on their side. The message actually starts in the "THI" part:
...........@MQSTR .....(....<..........S@I.(..................THI
000400010007DDEED444000044524443344522225E7C2400000000000000FFFFECC
00080031004C4823900000001D1023C01146000042C90D9D000100000008FFFF389 |
|
| Back to top |
|
|
| mqjeff |
| Posted: Fri Aug 21, 2015 8:53 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
Those dots are ascii representations of non-printable characters - because the fields they represent in the MQ header are binary, not text.
It sounds like the mainframe program is unable to process an MQRFH header, and the Java program is sending one.
_________________
chmod -R ugo-wx / |
|
| Back to top |
|
|
| eniomarques |
| Posted: Fri Aug 21, 2015 10:18 am Post subject: |
|
|
Novice
Joined: 25 May 2015
Posts: 24
Location: Brazil
|
| mqjeff wrote: |
Those dots are ascii representations of non-printable characters - because the fields they represent in the MQ header are binary, not text.
It sounds like the mainframe program is unable to process an MQRFH header, and the Java program is sending one. |
The developers are saying that they are not using MQRFH. I asked them to send a message to a local queue instead of sending it to the mainframe, this is what I got:
MQOPEN - '2B3.TESTQUEUE'
MQGET of message number 1, CompCode:0 Reason:0
****Message descriptor****
StrucId : 'MD ' Version : 2
Report : 0 MsgType : 8
Expiry : -1 Feedback : 0
Encoding : 273 CodedCharSetId : 819
Format : 'MQSTR '
Priority : 0 Persistence : 0
MsgId : X'414D512042434C30314144562020202054E27CC9204E531D'
CorrelId : X'000000000000000000000000000000000000000000000000'
BackoutCount : 0
ReplyToQ : ' '
ReplyToQMgr : 'BCL01ADV '
** Identity Context
UserIdentifier : 'mqm '
AccountingToken :
X'0000000000000000000000000000000000000000000000000000000000000000'
ApplIdentityData : ' '
** Origin Context
PutApplType : '28'
PutApplName : 'WebSphere MQ Client for Java'
PutDate : '20150821' PutTime : '18141304'
ApplOriginData : ' '
GroupId : X'414D512042434C30314144562020202054E27CC9204E531E'
MsgSeqNumber : '1'
Offset : '0'
MsgFlags : '8'
OriginalLength : '-1'
**** Message ****
length - 44 of 44 bytes
00000000: 5448 4953 2049 5320 4120 5445 5354 204D 'THIS IS A TEST M'
00000010: 4553 5341 4745 2E20 2050 4C45 4153 4520 'ESSAGE. PLEASE '
00000020: 4947 4E4F 5245 2054 4849 5321 'IGNORE THIS! '
They said they are not specifying a RFH, unless its default. |
|
| Back to top |
|
|
| eniomarques |
| Posted: Fri Aug 21, 2015 11:03 am Post subject: |
|
|
Novice
Joined: 25 May 2015
Posts: 24
Location: Brazil
|
| I've asked the developers to disable all message flags, and looks like it was the problem. They are not even sending the message type now. The mainframe app doesn't work in a request/response model. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Fri Aug 21, 2015 11:03 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
Yeah...
They sent a test message. They didn't send the same message that they send to the mainframe.
Have them send *that*. At least, have them write it to a local queue instead of the mainframe queue - or a different queue on the mainframe.
_________________
chmod -R ugo-wx / |
|
| Back to top |
|
|
| Vitor |
| Posted: Fri Aug 21, 2015 11:09 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| eniomarques wrote: |
| They said they are not specifying a RFH, unless its default. |
It is. The RFH is where WMQ keeps the JMS specific attributes their JMS application includes with the message.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Sat Aug 22, 2015 8:57 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
Don't know what you are complaining about. If you look at the buffer your message is there. The rest are structures passed with every message like MQMD and GMO... Use the MF MQ application to read the messages.
The messages are in format MQFMT_STRING. Make sure the application uses the MQGMO_CONVERT option.
Have fun 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| eniomarques |
| Posted: Sat Aug 22, 2015 9:03 am Post subject: |
|
|
Novice
Joined: 25 May 2015
Posts: 24
Location: Brazil
|
Thanks everyone for all the replies!
The MF application was not able to understand the MQRFH/MQMF_MSG_IN_GROUP. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Sat Aug 22, 2015 9:06 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
Be more specific.
Not able to understand:... The option was not specified when it should have been? Did not use all messages in group? ??
Can you enlighten the readers for future reference?
Thanks in advance.
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Sat Aug 22, 2015 9:11 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
| fjb_saper wrote: |
Be more specific.
Not able to understand:... The option was not specified when it should have been? Did not use all messages in group? ??
Can you enlighten the readers for future reference?
Thanks in advance. |
In other words: what was the solution?
_________________
I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live. |
|
| Back to top |
|
|
| eniomarques |
| Posted: Sun Aug 23, 2015 8:56 am Post subject: |
|
|
Novice
Joined: 25 May 2015
Posts: 24
Location: Brazil
|
| Sorry I couldn't give a better explanation, but I'm not sure why the developers are using the MQMF_MSG_IN_GROUP in the request, and why the mainframe is not able to read it. I asked for more details, but as the problem is "solved", I got no replies from them. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Sun Aug 23, 2015 11:29 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
| eniomarques wrote: |
| I'm not sure why the developers are using the MQMF_MSG_IN_GROUP in the request, and why the mainframe is not able to read it. |
In order for apps to use message groups, both the requesting and replying application must be modified to include different MQMD, MQPMO and MQGMO structures - along with supporting code, like _MSG_IN_GROUP.
Message Groups create an affinity between individual messages - such as a transaction that requires five message to comprise the transaction.
A guess: someone modified the requesting app, but not the replying app.
Details here: https://www-01.ibm.com/support/knowledgecenter/SSFKSJ_8.0.0/com.ibm.mq.dev.doc/q023060_.htm
_________________
I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live. |
|
| Back to top |
|
|
| eniomarques |
| Posted: Mon Aug 24, 2015 6:42 am Post subject: |
|
|
Novice
Joined: 25 May 2015
Posts: 24
Location: Brazil
|
I just got a PMR response with the full cause:
| Quote: |
The trace of channel TO.MQS0.SPRCL1SY in trace file AMQ6553642.0.FMT
supplied on 18th Aug shows the cause of the issue at the sending end.
When MsgFlags is set to MQMF_MSG_IN_GROUP it causes the msg on the xmitq
to be prepended by an MQMDE header, as can be seen in the trace at line
29765ff. If the getting app passes an MD v1 into MQGET then the msg
returned to the app will also be prepended by this header.
.
These are not 'garbage' chars, but a properly formed WMQ header and msg;
please see manual topic q097790 and sub-topics for a full description.
.
The solution that the customer has adopted is valid, that if the msg is
not part of a group to omit MQMF_MSG_IN_GROUP from MsgFlags. The good
practice is that this setting of MsgFlags should only be used when the
msg being put is part of a group, and not otherwise.
Additionally, MsgFlags in the last msg in the group should also contain
MQMF_LAST_MSG_IN_GROUP.
.
Note that an alternative solution would be for the getting app to pass
a v2 MD into MQGET; this would cause the MQMDE fields to be included in
the v2 MD passed back to the app. |
thanks! |
|
| Back to top |
|
|
|
|
