| Author |
Message
|
| Testo |
 Posted: Tue Oct 26, 2004 6:39 am Post subject: XML parsing error in zOS and not in Win XP |
 |
|
Centurion
Joined: 26 Feb 2003
Posts: 120
Location: Italy - Milan
|
I'm experiencing a strange behavior of the WMQI 2.1 CSD4
I've developed some flows in the Win XP environment and the MQInput node is set to accept "XML domain" messages.
After many tests in the last weeks, we have now deployed the flows in zOS but the flow is not able to parse anymore the XML message.
I'm sure it is well formed because I put the same one from RFHUtil to both Win XP and zOS and it has a different behavior....
Any similar experience?
Is XML parsing different on zOS?
Thanks in advance for any help
Andrea Tedone
IBM IT Specialist |
|
| Back to top |
|
 |
| EddieA |
| Posted: Tue Oct 26, 2004 7:37 am Post subject: |
|
|
Jedi
Joined: 28 Jun 2001
Posts: 2453
Location: Los Angeles
|
| Quote: |
| I put the same one from RFHUtil to both Win XP and zOS and it has a different behavior |
Did you make sure that the CCSID and Encoding were correctly set, so that the zOS could convert correctly to EBCDIC.
Cheers,
_________________
Eddie Atherton
IBM Certified Solution Developer - WebSphere Message Broker V6.1
IBM Certified Solution Developer - WebSphere Message Broker V7.0 |
|
| Back to top |
|
|
| Testo |
| Posted: Tue Oct 26, 2004 8:36 am Post subject: Yep |
|
|
Centurion
Joined: 26 Feb 2003
Posts: 120
Location: Italy - Milan
|
Eddie,
in theory, according to this topic http://www.mqseries.net/phpBB2/viewtopic.php?t=15800&highlight=ccsid , it should not matter the message CCSID and ENCODING because the MQInput node, when parsing the message according to the XML domain, should perform the conversion internally in a transparent manner.
In any case, I tried also to put the message forcing the CCSID to 500 (the on e for zOS) but I get the following exception (parsed with a subflow that generates an XML message with all the details from the ExceptionList plus my original XML message where < and > are sustituted with < and >):
| Code: |
<Error>
<MessageSource>
<QueueManager>BRKSVIL</QueueManager>
<Queue>UTQ.KONDOR.INPUT</Queue>
</MessageSource>
<Detail>
<ExceptionType>ParserException</ExceptionType>
<ErrorNumber>5004</ErrorNumber>
<SeverityLevel>3</SeverityLevel>
<ErrorSource>FINT_KPLUS_CICS.DEALS Input</ErrorSource> <DiagnosticMessage>Caught exception and rethrowing. XML Parsing Errors have occurred. An error has been reported by the BIPXML4C component.. </DiagnosticMessage>
<CauseOfError>22. 1. 1. Invalid document structure. XML.</CauseOfError>
<MessageState>
<msg>
<Header.Origin>BPL</Header.Origin>
<Header.SourceApplication>KONDOR</Header.SourceApplication>
<Header.SourceDate>2004-10-26 11:29:47.000</Header.SourceDate>
<Header.SourceID>SpotDeals£1</Header.SourceID>
<Header.Product>FXSPOT</Header.Product>
<Header.Operation>INS</Header.Operation>
<Header.Responsible/>
<Header.AuditLevel>1</Header.AuditLevel>
<Header.VisibilityLevel>0</Header.VisibilityLevel>
<Header.ComponentName>EXPKONDOR</Header.ComponentName>
<Header.ComponentDate>2004-10-26 11:29:47.694</Header.ComponentDate>
<Header.StepNum>1</Header.StepNum>
<Header.Status>0</Header.Status>
<Header.ErrorString/>
<Header.CleanupDate/>
<Header.NumOfLegs>1</Header.NumOfLegs>
<Header.Description/>
<Header.Destination/>
<Header.TargetApplication>WMQI</Header.TargetApplication>
<Header.TargetID/>
<Header.ChainedMsg>N</Header.ChainedMsg>
</msg>
</MessageState>
</Detail>
<TimeStamp>2004-10-26 15:27:53.293</TimeStamp>
</Error>
|
Any other potential issue?
Thanks
Andrea |
|
| Back to top |
|
|
| EddieA |
| Posted: Tue Oct 26, 2004 8:56 am Post subject: |
|
|
Jedi
Joined: 28 Jun 2001
Posts: 2453
Location: Los Angeles
|
| Quote: |
| it should not matter the message CCSID and ENCODING because the MQInput node, when parsing the message according to the XML domain, should perform the conversion internally in a transparent manner. |
It does. With the Broker, there are two ways the message can be converted. Either, you select Convert on the Input node, in which case MQSeries does the conversion according to it's rules. This only works if you have either a character message declared as MQSTR, or you build a conversion exit.
The second method, is to leave the Convert option unchecked, and then the Broker will convert the message, according to the Domain/Message selected. This is very useful for CWF messages that contain fields other than characters.
However, in both cases, the CCSID and Encoding still have to match the message, or else how is MQSeries or the Broker going to know if it has to convert or not.
Cheers,
_________________
Eddie Atherton
IBM Certified Solution Developer - WebSphere Message Broker V6.1
IBM Certified Solution Developer - WebSphere Message Broker V7.0 |
|
| Back to top |
|
|
| Testo |
| Posted: Tue Oct 26, 2004 9:31 am Post subject: Thanks |
|
|
Centurion
Joined: 26 Feb 2003
Posts: 120
Location: Italy - Milan
|
Thank you Eddie for your rich reply... I'll work on it tonight (GMT+1 over here!)
Cheers,
Andrea |
|
| Back to top |
|
|
| dilse |
| Posted: Tue Oct 26, 2004 12:26 pm Post subject: |
|
|
Master
Joined: 24 Jun 2004
Posts: 270
|
Testo,
If you dont find any problem with the CCSID, you might want to check for special characters in your XML that do not comply with your Encoding scheme.
Best of luck..
_________________
DilSe..
Take life as it comes.. |
|
| Back to top |
|
|
| Testo |
| Posted: Tue Oct 26, 2004 12:47 pm Post subject: Solved! |
|
|
Centurion
Joined: 26 Feb 2003
Posts: 120
Location: Italy - Milan
|
We got it!
For those who are interested here is the story.
First tests were performed sending messages to zOS via a C++ adapter on Sun Solaris; in this situation there was an error and the error messages (formatted through an ErrorManager subflow producing a result like the sample above) where not readable on the failure queue because they were written in ASCII instead of EBCDIC.
Then, suspecting a problem with CCSID, we sent the same messages from RFHUTIL setting the CCSID at 500 but leaving the input message in ASCII! In this manner, the broker on zOS received ASCII messages with the wrong CCSID (that refers to EBCDIC) causing the XML parsing error cited in the title.
All this mess has been caused by the ErrorManager subflow that, attached to the catch node of the input queue, wrongly uses the original InputRoot.MQMD.CodedCharSetId to prepare the message in the failure queue.
In summary, the non-readable messages in the failure queue were indicating the 'proper' error (that I'm going to investigate tomorrow); on the other hand, performing further tests manually from RFHUTIL caused a big misunderstanding....
At the end of the story, I have just modified the ErrorManager subflow and I've prepared it for the zOS env, forcing the error message to have Encoding=785 and CCSID=500, so it will be readable.
One question for the experts over there: is it possible to retreive, from a compute node, the CCSID associated to the QManager where the broker is running? In this manner I could specify the correct CCSID dinamically and the ErrorManager subflow would become 'platform independent'....
Cheers
Andrea |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Tue Oct 26, 2004 1:39 pm Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
The problem seems to be with the tool/application/process you were using to read the Failure Queue.
It should have done a Get with Convert before presenting the data to you.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
|
|
