| Author |
Message
|
| rexian |
 Posted: Wed Nov 28, 2007 3:32 pm Post subject: MQ Message body is null while reading from an MDB |
 |
|
Newbie
Joined: 28 Nov 2007
Posts: 7
|
I have an unusual (and most likely silly) problem in which I can't retrieve the body of a message sent by a mainframe program in an MDB. When the message is received, Websphere 6.1 passes it to the MDB as a TextMessage, but getText returns null.
The same message, when retrieved from a stand alone program using MQ API, it can read the message.
Here is the stand alone code that works:
| Code: |
...
int openOption = MQC.MQOO_INPUT_AS_Q_DEF;
queue = mqQueueManager.accessQueue(qName, openOption,null,null,null);
MQGetMessageOptions getMessageOptions = new MQGetMessageOptions(); // Set get message options
getMessageOptions.options = MQC.MQGMO_NO_WAIT + MQC.MQGMO_FAIL_IF_QUIESCING + MQC.MQGMO_CONVERT;
getMessageOptions.waitInterval = MQC.MQWI_UNLIMITED;
queue.get(message, getMessageOptions);
//String mesg = message.readLine();
System.out.println( "Get message sucessful : " + message.getMessageLength());
byte[] b = new byte[message.getMessageLength()];
message.readFully(b);
System.out.println(new String(b));
|
The output is :
| Code: |
Get message sucessful : 368
RFH @$#@$#p*&%@$@ MQSTR #%$#%$#%$#$^%$^%$ MQPSCommand Publish MQPSPubOpts CorrelAsId MQPSStreamName QL.NCCCICNDSUPDATES.STRM MQPSTopic "NC/DHHS/CCI/CNDS/PERS/CNDS/CHG " MQPSStringData "0101DHRCCI 0000{0000{HHEARTBT 01CNDS DUMMY HEARTBEAT MESSAGE "
|
And here is the code that doesn't work:
| Code: |
public void onMessage(Message message) {
System.out.println("Received a msg : " + message.getClass());
try {
Enumeration props = message.getPropertyNames();
while(props.hasMoreElements()) {
Object header = props.nextElement();
System.out.println("Received header : " + header + " :: Value : " + message.getObjectProperty((String)header));
}
System.out.println("Received a msg : " + message.getJMSType());
System.out.println("Received a msg : " + message.getJMSMessageID());
System.out.println("Received a msg : " + new Date(message.getJMSTimestamp()));
if(message instanceof TextMessage) {
System.out.println("Received Txt msg : " + ((TextMessage)message).getText());
} else {
byte[] bytes = new byte[(int)((BytesMessage)message).getBodyLength()];
((BytesMessage)message).readBytes(bytes);;
System.out.println("Received bin msg : " + new String(bytes));
}
} catch (JMSException ex) {
ex.printStackTrace();
}
}
|
And the output:
| Code: |
[11/28/07 16:55:15:681 EST] 00000021 SystemOut O Received a msg : class com.ibm.jms.JMSTextMessage
[11/28/07 16:55:15:681 EST] 00000021 SystemOut O Received header : JMS_IBM_PutDate :: Value : 20071128
[11/28/07 16:55:15:681 EST] 00000021 SystemOut O Received header : JMSXAppID :: Value : NCMPS01.TEST
[11/28/07 16:55:15:681 EST] 00000021 SystemOut O Received header : JMS_IBM_Format :: Value : MQSTR
[11/28/07 16:55:15:681 EST] 00000021 SystemOut O Received header : JMS_IBM_PutApplType :: Value : 26
[11/28/07 16:55:15:696 EST] 00000021 SystemOut O Received header : JMS_IBM_MsgType :: Value : 8
[11/28/07 16:55:15:696 EST] 00000021 SystemOut O Received header : JMSXUserID :: Value : TS54P03
[11/28/07 16:55:15:696 EST] 00000021 SystemOut O Received header : JMS_IBM_PutTime :: Value : 21551228
[11/28/07 16:55:15:696 EST] 00000021 SystemOut O Received header : JMSXDeliveryCount :: Value : 1
[11/28/07 16:55:15:696 EST] 00000021 SystemOut O Received a msg : null
[11/28/07 16:55:15:696 EST] 00000021 SystemOut O Received a msg : ID:414d51204e434d505330312e544553544736c7d3202f6e8f
[11/28/07 16:55:15:696 EST] 00000021 SystemOut O Received a msg : Wed Nov 28 16:55:12 EST 2007
[11/28/07 16:55:15:696 EST] 00000021 SystemOut O Received Txt msg : null
|
Am I missing something in my JMS connection factory configuration? Any hint/suggestion is greatly appreciated. |
|
| Back to top |
|
 |
| bower5932 |
| Posted: Wed Nov 28, 2007 7:40 pm Post subject: |
|
|
Jedi Knight
Joined: 27 Aug 2001
Posts: 3023
Location: Dallas, TX, USA
|
| Can we see amqsbcg output of the message? |
|
| Back to top |
|
|
| rexian |
| Posted: Thu Nov 29, 2007 6:36 am Post subject: |
|
|
Newbie
Joined: 28 Nov 2007
Posts: 7
|
| bower5932 wrote: |
| Can we see amqsbcg output of the message? |
Thanks for the reply bower5932. Here is the output of amqsbcg.java.
| Code: |
GET of message number 1
****Message descriptor****
StrucId : 'MD ' Version : 2
Report : 0 MsgType : 8
Expiry : -1 Feedback : 0
Encoding : 785 CodedCharSetId : 500
Format : 'MQHRF '
Priority : 5 Persistence : 1
MsgId : X'414D51204E434D505330312E544553544736C7D3202F6EDB'
CorrelId : X'414D51580000000000000000000000000000000000000000'
BackoutCount : 0
ReplyToQ : ' '
ReplyToQMgr : 'NCMPS01.TEST '
** Identity Context
UserIdentifier : 'TS54P03 '
Accounting Token :
X'10C4C8D9C3D5C4F5F4C3D6F7FFC1C4C9E7000000000000000000000000000000'
ApplIdentityData : ' '
** Origin Context
PutApplType : '26'
PutApplName : 'NCMPS01.TEST '
PutDate : '20071128' PutTime : '22551258'
ApplOriginData : ' '
GroupId : X'000000000000000000000000000000000000000000000000'
MsgSeqNumber : '1'
Offset : '0'
MsgFlags : '0'
OriginalLength : '-1'
**** Message ****
length - 368 bytes
00000000: D9C6 C840 0000 0001 0000 0170 0000 0311 'ÙÆÈ@.......p....'
00000010: 0000 0000 D4D8 E2E3 D940 4040 0000 0000 '....ÔØâãÙ@@@....'
00000020: 40D4 D8D7 E2C3 9694 9481 9584 4040 D7A4 '@ÔØ×âÃ......@@פ'
00000030: 8293 89A2 8840 40D4 D8D7 E2D7 A482 D697 '...¢.@@ÔØ×âפ.Ö.'
00000040: A3A2 4040 C396 9999 8593 C1A2 C984 4040 '£¢@@Ã.....Á¢É.@@'
00000050: D4D8 D7E2 E2A3 9985 8194 D581 9485 4040 'ÔØ×ââ£....Õ...@@'
00000060: D8D3 4BD5 C3C3 C3C9 C3D5 C4E2 E4D7 C4C1 'ØÓKÕÃÃÃÉÃÕÄâä×ÄÁ'
00000070: E3C5 E24B E2E3 D9D4 4040 4040 4040 4040 'ãÅâKâãÙÔ@@@@@@@@'
00000080: 4040 4040 4040 4040 4040 4040 4040 40D4 '@@@@@@@@@@@@@@@Ô'
00000090: D8D7 E2E3 9697 8983 407F D5C3 61C4 C8C8 'Ø×âã....@.ÕÃaÄÈÈ'
000000A0: E261 C3C3 C961 C3D5 C4E2 61D7 C5D9 E261 'âaÃÃÉaÃÕÄâa×ÅÙâa'
000000B0: C3D5 C4E2 61C3 C8C7 407F 40D4 D8D7 E2E2 'ÃÕÄâaÃÈÇ@.@ÔØ×ââ'
000000C0: A399 8995 87C4 81A3 8140 7FF0 F1F0 F1C4 '£....Ä.£.@.ðñðñÄ'
000000D0: C8D9 C3C3 C940 4040 4040 4040 4040 4040 'ÈÙÃÃÉ@@@@@@@@@@@'
000000E0: 4040 4040 4040 4040 4040 4040 4040 4040 '@@@@@@@@@@@@@@@@'
000000F0: 4040 4040 4040 4040 4040 4040 4040 4040 '@@@@@@@@@@@@@@@@'
00000100: 4040 4040 4040 4040 4040 4040 4040 4040 '@@@@@@@@@@@@@@@@'
00000110: 4040 4040 4040 4040 4040 4040 4040 4040 '@@@@@@@@@@@@@@@@'
00000120: 4040 4040 40F0 F0F0 F0C0 F0F0 F0F0 C0C8 '@@@@@ððððÀððððÀÈ'
00000130: C8C5 C1D9 E3C2 E340 F0F1 C3D5 C4E2 4040 'ÈÅÁÙãÂã@ðñÃÕÄâ@@'
00000140: 4040 40C4 E4D4 D4E8 40C8 C5C1 D9E3 C2C5 '@@@ÄäÔÔè@ÈÅÁÙãÂÅ'
00000150: C1E3 40D4 C5E2 E2C1 C7C5 4040 4040 4040 'Áã@ÔÅââÁÇÅ@@@@@@'
00000160: 4040 4040 4040 4040 4040 4040 4040 407F '@@@@@@@@@@@@@@@.'
|
I forgot to mention in my first post that the MDB receives the complete message when we use a standalone program to send a JMS message. It's only the mainframe message receiving that's not working. Only thing I see is that the message from mainframe has "PutApplType = 26" and the message from stand alone program has "PutApplType = 28".
Thanks. |
|
| Back to top |
|
|
| JLRowe |
| Posted: Thu Nov 29, 2007 8:14 am Post subject: |
|
|
Yatiri
Joined: 25 May 2002
Posts: 664
Location: South East London
|
Your mainframe code cannot be constructing the message properly, there must be something wrong with the MQRFH2 header.
Carefully compare the mainframe message with the generated message, turn on channel conversion so you see the amqsbcg in the right code page. |
|
| Back to top |
|
|
| rexian |
| Posted: Thu Nov 29, 2007 11:27 am Post subject: |
|
|
Newbie
Joined: 28 Nov 2007
Posts: 7
|
Thanks JLRowe. When we first encountered this issue, we thought the problem is at the Mainframe's end as we could receive JMS messages sent by other JMS clients. The mainframe team then did some analysis and found no issue as they could browse the queue and view the messages properly.
They suggested that we write another program using MQ API to see if that works. And it did. That's the first snippet in my first post. This standalone program can receive the data properly even when we run it on Windows and the message is being sent by a Cobol screen on Mainframe. But the MDB doesn't get the body, just the headers. So I am thinking I probably messed up the Connection Factory configuration? Could that be the cause?  |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Thu Nov 29, 2007 12:15 pm Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
Can you put a message from the MF to Queue A (that chokes your MDB), the same mesage from another non-MF app to Queue B (that works in your MDB), then post the amqsbcg output for both Queue A and B. Something is different between the 2 messages.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| EddieA |
| Posted: Thu Nov 29, 2007 1:39 pm Post subject: |
|
|
Jedi
Joined: 28 Jun 2001
Posts: 2453
Location: Los Angeles
|
Ooohhh, that's an RFH1. I haven't seen one of those for a long while.
But I digress. The RFH header hasn't been built correctly. The CCSID field doesn't have a value in it.
Cheers,
_________________
Eddie Atherton
IBM Certified Solution Developer - WebSphere Message Broker V6.1
IBM Certified Solution Developer - WebSphere Message Broker V7.0 |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Thu Nov 29, 2007 1:45 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
If you do not absolutely need the RFH header have the MF not put it. You do not need to have an RFH header to read the message with an MDB.
If you do have the MF send an RFH header then there is a good chance that something is wrong with it...
Can you still read the message if you use a stand alone JMS application??
Enjoy 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| rexian |
| Posted: Thu Nov 29, 2007 3:10 pm Post subject: |
|
|
Newbie
Joined: 28 Nov 2007
Posts: 7
|
| PeterPotkay wrote: |
| Can you put a message from the MF to Queue A (that chokes your MDB), the same mesage from another non-MF app to Queue B (that works in your MDB), then post the amqsbcg output for both Queue A and B. Something is different between the 2 messages. |
Peter, I am not sure of the exact string MF is sending. Following is the string the stand alone program receives from MF
| Code: |
| 0101DHRCCI 0000{0000{HHEARTBT 01CNDS DUMMY HEARTBEAT MESSAGE |
I used the above string to create an MQ message from another stand alone program and here are the outputs -
From MF (the message looks like binary or garbage) :
| Code: |
****Message descriptor****
StrucId : 'MD ' Version : 2
Report : 0 MsgType : 8
Expiry : -1 Feedback : 0
Encoding : 785 CodedCharSetId : 500
Format : 'MQHRF '
Priority : 5 Persistence : 1
MsgId : X'414D51204E434D505330312E544553544736C7D32032883E'
CorrelId : X'414D51580000000000000000000000000000000000000000'
BackoutCount : 0
ReplyToQ : ' '
ReplyToQMgr : 'NCMPS01.TEST '
** Identity Context
UserIdentifier : 'TS54P03 '
Accounting Token :
X'10C4C8D9C3D5C4F5F4C3D6F7FFC1C4C9E7000000000000000000000000000000'
ApplIdentityData : ' '
** Origin Context
PutApplType : '26'
PutApplName : 'NCMPS01.TEST '
PutDate : '20071129' PutTime : '22545114'
ApplOriginData : ' '
GroupId : X'000000000000000000000000000000000000000000000000'
MsgSeqNumber : '1'
Offset : '0'
MsgFlags : '0'
OriginalLength : '-1'
**** Message ****
length - 368 bytes
00000000: D9C6 C840 0000 0001 0000 0170 0000 0311 'ÙÆÈ@.......p....'
00000010: 0000 0000 D4D8 E2E3 D940 4040 0000 0000 '....ÔØâãÙ@@@....'
00000020: 40D4 D8D7 E2C3 9694 9481 9584 4040 D7A4 '@ÔØ×âÃ......@@פ'
00000030: 8293 89A2 8840 40D4 D8D7 E2D7 A482 D697 '...¢.@@ÔØ×âפ.Ö.'
00000040: A3A2 4040 C396 9999 8593 C1A2 C984 4040 '£¢@@Ã.....Á¢É.@@'
00000050: D4D8 D7E2 E2A3 9985 8194 D581 9485 4040 'ÔØ×ââ£....Õ...@@'
00000060: D8D3 4BD5 C3C3 C3C9 C3D5 C4E2 E4D7 C4C1 'ØÓKÕÃÃÃÉÃÕÄâä×ÄÁ'
00000070: E3C5 E24B E2E3 D9D4 4040 4040 4040 4040 'ãÅâKâãÙÔ@@@@@@@@'
00000080: 4040 4040 4040 4040 4040 4040 4040 40D4 '@@@@@@@@@@@@@@@Ô'
00000090: D8D7 E2E3 9697 8983 407F D5C3 61C4 C8C8 'Ø×âã....@.ÕÃaÄÈÈ'
000000A0: E261 C3C3 C961 C3D5 C4E2 61D7 C5D9 E261 'âaÃÃÉaÃÕÄâa×ÅÙâa'
000000B0: C3D5 C4E2 61C3 C8C7 407F 40D4 D8D7 E2E2 'ÃÕÄâaÃÈÇ@.@ÔØ×ââ'
000000C0: A399 8995 87C4 81A3 8140 7FF0 F1F0 F1C4 '£....Ä.£.@.ðñðñÄ'
000000D0: C8D9 C3C3 C940 4040 4040 4040 4040 4040 'ÈÙÃÃÉ@@@@@@@@@@@'
000000E0: 4040 4040 4040 4040 4040 4040 4040 4040 '@@@@@@@@@@@@@@@@'
000000F0: 4040 4040 4040 4040 4040 4040 4040 4040 '@@@@@@@@@@@@@@@@'
00000100: 4040 4040 4040 4040 4040 4040 4040 4040 '@@@@@@@@@@@@@@@@'
00000110: 4040 4040 4040 4040 4040 4040 4040 4040 '@@@@@@@@@@@@@@@@'
00000120: 4040 4040 40F0 F0F0 F0C0 F0F0 F0F0 C0C8 '@@@@@ððððÀððððÀÈ'
00000130: C8C5 C1D9 E3C2 E340 F0F1 C3D5 C4E2 4040 'ÈÅÁÙãÂã@ðñÃÕÄâ@@'
00000140: 4040 40C4 E4D4 D4E8 40C8 C5C1 D9E3 C2C5 '@@@ÄäÔÔè@ÈÅÁÙãÂÅ'
00000150: C1E3 40D4 C5E2 E2C1 C7C5 4040 4040 4040 'Áã@ÔÅââÁÇÅ@@@@@@'
00000160: 4040 4040 4040 4040 4040 4040 4040 407F '@@@@@@@@@@@@@@@.'
|
And from standalone:
| Code: |
GET of message number 68
****Message descriptor****
StrucId : 'MD ' Version : 2
Report : 0 MsgType : 8
Expiry : -1 Feedback : 0
Encoding : 273 CodedCharSetId : 819
Format : ' '
Priority : 0 Persistence : 0
MsgId : X'C3E2D840D4D8E6F14040404040404040C1929822C769150E'
CorrelId : X'000000000000000000000000000000000000000000000000'
BackoutCount : 0
ReplyToQ : ' '
ReplyToQMgr : 'MQW1 '
** Identity Context
UserIdentifier : 'MQW1CHN '
Accounting Token :
X'1A0FD4D8E6F1C3C8C9D5F1F9C1F9F3C3F3F00019A93C30000000000000000000'
ApplIdentityData : ' '
** Origin Context
PutApplType : '28'
PutApplName : 'WebSphere MQ Client for Java'
PutDate : '20071129' PutTime : '22562883'
ApplOriginData : ' '
GroupId : X'000000000000000000000000000000000000000000000000'
MsgSeqNumber : '1'
Offset : '0'
MsgFlags : '0'
OriginalLength : '-1'
**** Message ****
length - 164 bytes
00000000: 3031 3031 4448 5243 4349 2020 2020 2020 '0101DHRCCI '
00000010: 2020 2020 2020 2020 2020 2020 2020 2020 ' '
00000020: 2020 2020 2020 2020 2020 2020 2020 2020 ' '
00000030: 2020 2020 2020 2020 2020 2020 2020 2020 ' '
00000040: 2020 2020 2020 2020 2020 2020 2020 2020 ' '
00000050: 2020 2020 2020 2020 2020 3030 3030 7B30 ' 0000{0'
00000060: 3030 307B 4848 4541 5254 4254 2030 3143 '000{HHEARTBT 01C'
00000070: 4E44 5320 2020 2020 4455 4D4D 5920 4845 'NDS DUMMY HE'
00000080: 4152 5442 4541 5420 4D45 5353 4147 4520 'ARTBEAT MESSAGE '
00000090: 2020 2020 2020 2020 2020 2020 2020 2020 ' '
000000A0: 2020 2020 ' '
|
Thanks. |
|
| Back to top |
|
|
| rexian |
| Posted: Thu Nov 29, 2007 3:24 pm Post subject: |
|
|
Newbie
Joined: 28 Nov 2007
Posts: 7
|
| EddieA wrote: |
Ooohhh, that's an RFH1. I haven't seen one of those for a long while.
But I digress. The RFH header hasn't been built correctly. The CCSID field doesn't have a value in it.
Cheers,
|
Eddie, which header is CCSID? I can't see it in the message sent by the stand alone program, or is it an MF term that I am not aware of 
| fjb_saper wrote: |
If you do not absolutely need the RFH header have the MF not put it. You do not need to have an RFH header to read the message with an MDB.
If you do have the MF send an RFH header then there is a good chance that something is wrong with it...
Can you still read the message if you use a stand alone JMS application??
Enjoy |
I am not sure why they need the RFH header, but there are other Cobol programs reading these messages, so I guess they might need it. What puzzles me is that I can read the message perfectly from the stand alone program using MQ API. And so, the MF team thinks there is no issue at their end  |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Thu Nov 29, 2007 4:16 pm Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
rexian, those messages are different. Look at the headers. The one that works going into your MDB does not have a format associated with it. If you are comparing apples to apples, both of your test messages, one from the MF app and one from the stand alone app should look identical to prove anything.
You said the MF one looks like garbage. That's because the data is EBCIDIC. JLRowe had a good idea in sending that MF message over a SNDR/RCVR channel first that has convert turned on. That way both of your test messages will have the same CCSID and it will make comparing them easier.
So far I suspect that the MF app is not formatting a proper RFH header causing the MDB to yak. When your non MDB app reads a message from the MF with the supposed RFH header, it doesn't care about a properly formatted RFH header so that MQGET works. And when you change the putter to your standalone non-MF app and the MDB is OK with that it looks like its because you don't build an RFH header at all, from the samples you posted.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| EddieA |
| Posted: Fri Nov 30, 2007 9:21 am Post subject: |
|
|
Jedi
Joined: 28 Jun 2001
Posts: 2453
Location: Los Angeles
|
| rexian wrote: |
| Eddie, which header is CCSID? I can't see it in the message sent by the stand alone program, or is it an MF term that I am not aware of |
It's not a header, it's a field in the RFH header. The layout is described in the APG.
Cheers,
_________________
Eddie Atherton
IBM Certified Solution Developer - WebSphere Message Broker V6.1
IBM Certified Solution Developer - WebSphere Message Broker V7.0 |
|
| Back to top |
|
|
| rexian |
| Posted: Fri Nov 30, 2007 11:38 am Post subject: |
|
|
Newbie
Joined: 28 Nov 2007
Posts: 7
|
| PeterPotkay wrote: |
| rexian, those messages are different. Look at the headers. The one that works going into your MDB does not have a format associated with it. If you are comparing apples to apples, both of your test messages, one from the MF app and one from the stand alone app should look identical to prove anything. |
Peter, I am forming the exact same message as MainFrame in the stand alone code as far as text data is concerned. The header could be different, but in the stand alone Java code all I am setting are the necessary parameters like channel and manager information and let the API build the header.
| PeterPotkay wrote: |
| You said the MF one looks like garbage. That's because the data is EBCIDIC. JLRowe had a good idea in sending that MF message over a SNDR/RCVR channel first that has convert turned on. That way both of your test messages will have the same CCSID and it will make comparing them easier. |
Could you provide a link, I am not sure I know how to do this. Is it something we can do in the amqsbcg.java program?
If MF message is garbage because of EBCDIC encoding, shouldn't we still receive those characters when we do readBytes in the MDB? The MDB receives null.
| PeterPotkay wrote: |
| So far I suspect that the MF app is not formatting a proper RFH header causing the MDB to yak. When your non MDB app reads a message from the MF with the supposed RFH header, it doesn't care about a properly formatted RFH header so that MQGET works. And when you change the putter to your standalone non-MF app and the MDB is OK with that it looks like its because you don't build an RFH header at all, from the samples you posted. |
Yes, we don't build RFH (or any header) when we send the message from a Java program. Just whatever header the MQ API builds on its own. Another odd things is that the MDB receives the message from MF as TextMessage but from the stand alone, it's BytesMessage.
Thanks. |
|
| Back to top |
|
|
| rexian |
| Posted: Fri Nov 30, 2007 11:47 am Post subject: |
|
|
Newbie
Joined: 28 Nov 2007
Posts: 7
|
| EddieA wrote: |
| rexian wrote: |
| Eddie, which header is CCSID? I can't see it in the message sent by the stand alone program, or is it an MF term that I am not aware of |
It's not a header, it's a field in the RFH header. The layout is described in the APG.
Cheers, |
Yes, I realized it after re-reading my mesg
Any suggestion do you have that I could share with the MF team to build the header properly. Thanks.
I also have the screenshot of the MQ Connection Factory configuration in the Websphere console and can post it here in case you would like to have a look. |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Fri Nov 30, 2007 12:01 pm Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
| rexian wrote: |
| PeterPotkay wrote: |
| rexian, those messages are different. Look at the headers. The one that works going into your MDB does not have a format associated with it. If you are comparing apples to apples, both of your test messages, one from the MF app and one from the stand alone app should look identical to prove anything. |
Peter, I am forming the exact same message as MainFrame in the stand alone code as far as text data is concerned. The header could be different, but in the stand alone Java code all I am setting are the necessary parameters like channel and manager information and let the API build the header.
|
That's why the messages are different. (apples and oranges) The data is just one part of the message. The header is the other. I bet you if your standalone app created a message whose buffer AND header looked like the mainframe one the MDB would give you the same results. If the header says there is supposed to be an RFH header and there isn't a proper one, then an app that relies on that (an MDB) will have problems.
Regarding the channel conversion your MQ Admin will know exactly what that it is. Its a property on the SNDR channel changed by an MQ admin tool or via a runmqsc command issued to the QM directly. You MQ Admin will (hopefully) push back on turning on channel conversion, but if you explain why you need it and only temporarily, you should be OK.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
|
|
