| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| Missing CRLF |
« View previous topic :: View next topic » |
| Author |
Message
|
| ghoose |
 Posted: Wed Feb 26, 2003 2:54 pm Post subject: Missing CRLF |
 |
|
Novice
Joined: 23 Apr 2002
Posts: 16
|
Hi..
Backend Mainframe is sending an XML and hub is processing the same.
it is recieving 754 bytes and after it is processed in compute node it is giving out 750 bytes. 4 bytes are missing. and the missng bytes are x0D chars.
compute node code is as given
SET OutputRoot = InputRoot;
SET OutputRoot.MQMD.CodedCharSetId = 819;
SET OutputRoot.MQMD.Encoding = 273;
SET OutputRoot.MQMD.Format = MQFMT_STRING;
incoming CCSID is 500.
any thoughts on the same?
Thanks
ghoose |
|
| Back to top |
|
 |
| jfluitsm |
| Posted: Thu Feb 27, 2003 5:02 am Post subject: |
|
|
Disciple
Joined: 24 Feb 2002
Posts: 160
Location: The Netherlands
|
What version are you using?
To me this looks like normal behaviour for XML. Tabs, spaces and line feeds are ignored, so the following 2 xml's are identical.
<Msg>
<Data>aaaa</Data>
</Msg>
<Msg><Data>aaaa</Data></Msg>
I tried this under 2.1 with CSD04, but the linefeeds and spaces were kept in the output, no mather whether the message was parsed by the broker (Trace-node) or not.
As you don't change anything in the message, try changing the Message Domain in the MQInput node to BLOB so that the XML-parser isn't used.
_________________
Jan Fluitsma
IBM Certified Solution Designer WebSphere MQ V6
IBM Certified Solution Developer WebSphere Message Broker V6 |
|
| Back to top |
|
|
| ghoose |
| Posted: Thu Feb 27, 2003 3:55 pm Post subject: |
|
|
Novice
Joined: 23 Apr 2002
Posts: 16
|
I got some soln frm IBM site. here it is...
Solution
MQSI uses the Xerces XML parser which follows section 2.11 of the XML
specification which states that CR/LF combinations should be normalised
into a single LF.
Therefore, the behavior observed by the customer is the correct
behavior, and it should also be noted that carriage returns cannot
be preserved in CDATA sections either.
The interpretation that text/bytes within CDATA would not be changed
is incorrect. In section 2.7 of the XML specification, the following
is stated :
'CDATA sections may occur anywhere character data may occur; they
are used to escape blocks of text containing characters which
would otherwise be recognized as markup.'
So from the above description, CDATA tags are used to preserve text
that could be regarded as markup. In section 2.7 of the XML
specification, the term markup is defined as :
'The definition of markup is start tags, end tags, empty element
tags, entity references, character references, comments, CDATA
section delimiters, document type declarations, processing
instructions, XML declarations, text declarations and white space.'
As can be seen from the definition above, carriage return characters
do not fall into the category of 'markup' and therefore should not
be preserved within CDATA.
As previously stated, the Xerces parser that is incorporated into
the MQSI product is following the XML specification as produced by
the w3 standards body when removing carriage return characters.
The reason the XML specification removes these characters is that
an XML compliant application should not need the presence of these
characters. If the XML output is being processed by a word processor
or display software for example, then this application should process
line feed characters as being carriage returns and line feed
characters. As stated in Section 2.11 of the XML specification, 'To
simplify the tasks of applications, the characters passed to an
application by the XML processor must be as if the XML processor
normalized all line breaks in external parsed entities on input,
before parsing, by translating the two character sequence 0D0A and
any 0D that is not followed by a 0A to a single 0A character'
Therefore any XML compliant application should not expect the
presence of carriage return characters in the data. If the customer
is requiring an XML message to be written out that has carriage
returns preserved in the data, then this suggests that the receiving
XML application is not as per the XML specification.
To re-insert the carriage returns it should be possible to convert
the message into the BLOB domain and then search for the line feed
bytes and replace them and insert the carriage return bytes.
This can be done before the message is written out to the queue,
by putting a ResetContentDecriptor followed by a compute node before
the MQOutput Node. The ResetContentDescriptor should be set to change
the message to the BLOB domain. Then the compute node should have
ESQL similar to the following :
DECLARE I INTEGER;
SET I = 1;
WHILE I < CARDINALITY(InputRoot.*[]) DO
SET OutputRoot.*[I] = InputRoot.*[I];
SET I=I+1;
END WHILE;
DECLARE inputData BLOB;
DECLARE outputData BLOB;
DECLARE find BLOB;
DECLARE replace BLOB;
DECLARE pos INTEGER;
SET inputData = InputRoot."BLOB"."BLOB";
SET outputData = x'';
-- find hex value (in your case, LF)
SET find = x'';
-- replace with hex value (in your case, LF and CR)
SET replace = x'';
SET pos = POSITION(find IN inputData);
WHILE (pos <> 0 AND inputData IS NOT NULL) DO
SET outputData = outputData ||
SUBSTRING(inputData FROM 1 FOR (pos-1)) ||
replace;
SET inputData = SUBSTRING(inputData FROM pos+LENGTH(find));
SET pos = POSITION(find IN inputData);
END WHILE;
SET OutputRoot."BLOB"."BLOB" = outputData || inputData;
Please note, that this ESQL is not complete, the user needs to
change the SET find = x''; and SET replace = x''; specifying
the hex representations of the Carriage return and line feed
characters.
Possible alternative workaround:
Unfortunately we do not have an alternative direct workaround that
can be used in this situation. From a general implementation point
of view, XML entity references can be used in an XML message for
characters that could be processed by the parser. An entity reference
represents a piece of text that would be recognized as a parseable
character, and then the true characters are substituted in after the
parse has completed. There are some predefined entities such as
&, < and > which represent ampersand, the less than symbol
and greater than symbol. It is possible for the user to define their
own entity references to represent certain character strings, and
it is possible to define character entity references that represent
certain hex strings. This type of representation is part of the XML
technologies and is not specific to the MQSI/WMQI product.
Unfortunately if legacy applications are being used then it usually
is not possible to make these changes because it involves these
applications creating and specifying these entity references.
If the customer is looking for an alternative method of preserving
these within the WMQI product then we do not have any alternative
workarounds other than the ESQL post-processing suggested. The only
other high-level suggestion we could offer is to perform the
post-processing using a TDS->TDS mapping instead of the ESQL
method. The bitstream that is currently being generated just contains
the 0A characters. If the customer defines a small messageset and
parses this bitstream using 0A as a delimiter, then this could
be used to produce a tree of repeating strings. If this same message
definition had a second TDS layer defined, but the delimiter was
defined as 0D0A in this, then a changing of the messageFormat
properties field would cause a new bitstream to be generated
containing 0D0A where the 0A's once were.
It should be noted that this is only a high level suggestion and
has not been attempted. |
|
| Back to top |
|
|
|
|
|
| |
|
Page 1 of 1 |
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
|
|
