Resolving problems when using messages

<?xml version ="1.0" standalone="no"?><!DOCTYPE doc
[<!ELEMENT doc (#PCDATA)*>]><doc><I1>100</I1></doc>

SET OutputRoot.XMLNS.doc.I1 = 112233;

<?xml version ="1.0" standalone="no"?><!DOCTYPE doc
[<!ELEMENT doc (#PCDATA)*>]<I1>112233<I1>><doc><I1>100</I1></doc>

• The doctype element
• The xmlElement that represents the body of the message

SET OutputRoot.XMLNS.(XML.tag)doc.I1 = 112233;

In XML, the main line separator characters is a line feed character. Carriage return characters are accepted in an XML document, but an XML parser normalizes any carriage return line feed characters into a single-line feed character. For more information, see the latest XML specification at Extensible Markup Language (XML), in particular, Section 2.11 End of Line Handling.

You cannot work around this problem by embedding your data into a CDATA section; the XML specification states that a CDATA section is intended only to escape blocks of text that contain characters that could be interpreted as markup. In addition, CDATA sections are not protected from the parser.

You cannot use the xml:space attribute to preserve carriage return line feed characters; the XML specification states that normalization of carriage return and line feed characters is done before any other processing is performed.

• You have specified an invalid XML character in the input XML message.
• You have included binary data in your XML message that, when treated as character data, is invalid.
• The message has arrived as part of a WebSphere MQ message and the MQMD.CodedCharSetId does not correctly represent the XML text bit stream.
• You have used characters that are recognized as markup.

• Check that your sending application is sending only valid data. If, however, it is not possible to prevent invalid characters from being included in the XML message, represent it in BLOB domain and use the ESQL REPLACE function to replace or remove the invalid characters. You can then assign the modified bit stream to the required XML parser.

  In accordance with XML specification, a CDATA section can be used only to protect characters that would be interpreted as markup. It cannot be used to protect invalid characters or binary data from the XML parser.

• If the input XML message contains binary data, ensure that the sending application is changed to represent this data as base encoded binary encoded data. If the application cannot be changed, represent the message in the BLOB domain, and extract and replace the binary data before the bit stream is assigned to the required XML parser.
• Check that the incoming XML message is being represented by the correct MQMD.CodedCharSetId.

If you have programmed automated error checking routines, review and change these routines if appropriate.

<doc><I1>100</I1></doc>

SET OutputRoot.XMLNS.abc = InputBody;

<abc><doc><I1>100</I1></doc></abc>

SET OutputRoot.XMLNS.(XML.Element)abc = InputBody;

SET OutputRoot.XMLNS.(XML.tag)abc = InputBody;

• A timeout request has no Action or no Identifier.
• A SET request has an Identifier that matches an existing stored SET request for this TimeoutControl node (identified by the Unique Identifier property) and AllowOverwrite of the original request is set to FALSE.
• A CANCEL request has an Identifier that does not match an existing stored SET request for this TimeoutControl node (identified by the Unique Identifier property).
• A SET request has a Count of 0 or is less than -1.
• The StartDate or StartTime are not in the correct format (or one of the understood keywords).
• The calculated timeout is in the past.
• The Interval is less than 0, or 0 with a Count of -1.

If an error happens downstream of the TimeoutNotification node after a successful propagation (either to the Out or Failure terminal), the message is propagated to the Catch terminal (all under the same transaction). If the Catch terminal is not connected, or the propagation along the Catch flow fails, the processing of that timeout is rolled back.

• Explanation 1: The XML physical format settings for a message set contain a property called Root Tag Name. This property defaults to MRM, in order to remain compatible with previous releases of the product. If you have not deleted the contents of this field, the MRM XMLNS parser expects the root tag for all XML messages to be MRM.

  Solution 1: Clear this field, or set it to the root tag used by all your XML messages. If you provide a value in this field, the root tag does not need to be modeled in all your message definitions.

• Explanation 2: In order to remain backwards compatible, the integration node recognizes the format XML and invokes the XMLNS parser with specific default values. If you have created an XML physical layer for this message with the name XML, the integration node uses your definition. However, if you have not created an XML physical layer with this name, but have specified XMLNS as the format, either in the input node or the MQRFH2 header (when the input bit stream is parsed to a message tree), the integration node accepts the value specified and passes default values to the parser to create the message tree.

  Similarly, if you set XML in the Properties folder for the output message in the Compute node, this value is passed to the parser when it creates the message bit stream from the message tree, typically in the output node.

  The use of these default values by the parser might result in different content, structure, or both, for either message tree or output message. You can find further information about the action taken by the integration node in the user trace log where the following information might be written:

  XMLWorker::initializeParse file:C:\s000\src\cpi\pwf\xml\xmlworker.cpp 
  line:126 message:5409.BIPmsgs   
  No dictionary present have you specified Wire Format 'XML' in error? , 
  UserTrace   BIP5409E: XML Worker: Wire Format 'XML' specified.                                      
                        Default MRM XML settings are being used because wire format 
                        identifier 'XML' was specified and not found. 
                        This can be due to an incorrect setting of the wire format 
                        identifier in a message. 

  Solution 2: If you have incorrectly entered the identifier of the format that you have defined, correct your code and try again. If you do not want the default action to be taken, define a physical layer that produces the required results.

• On a system where the queue manager uses an ASCII code set, make sure that incoming messages do not contain any EBCDIC NL characters by:
  • Specifying that WebSphere MQ performs the conversion at the input node
  • Setting the queue manager attribute to convert NL to Line Feed (LF)
• Where the input bit stream is character data, you can use MRM Tagged/Delimited message sets in a Compute node to replace the NL character with the required output.

• The MIME header is not correctly formatted.
• Either the top-level MIME header block, or a MIME header block for a nested multipart part, does not have a valid Content-Type header.
• The top-level Content-Type has a media type of message.
• The top-level Content-Type has a media type of multipart and no boundary definition.
• A MIME header block is not correctly terminated by a blank line.
• The constituent MIME parts are not correctly separated by boundary lines.
• A boundary parameter value occurs in the content of a MIME part.

• The root of the tree is not called MIME.
• The last child of MIME is not called Parts or Data.
• The Parts element has a value-only element, and this element is not the first or last child of Parts.
• The Parts element has children that are not value-only elements or Part children.
• The Parts element does not have any children called Part.
• The last child of a Data element is not a BLOB.

• You have created a message tree folder in a user-defined node but have not associated it with an owning parser. An owning parser is not associated with the message tree if you have created standard elements by using code similar or equivalent to:

  MbElement createElementAfter(int)
  MbElement createElementAfter(int, String, Object)
  MbElement createElementAsFirstChild(int)
  MbElement createElementAsFirstChild(int, String, Object)
  MbElement createElementAsLastChild(int)
  MbElement createElementAsLastChild(int, String, Object)
  MbElement createElementBefore(int)
  MbElement createElementBefore(int, String, Object)
  
  

• You have used ESQL to create a message tree folder by using ESQL CREATE but without setting an owning parser for it. You might have used code similar or equivalent to:

  CALL CopyMessageHeaders();
     DECLARE outRef REFERENCE TO OutputRoot;
     CREATE LASTCHILD OF outRef AS outRef NAME 'BLOB';
     CREATE LASTCHILD OF outRef NAME 'BLOB' VALUE X'01';

  or the outRef reference variable was passed to an ESQL function or procedure that contained similar CREATE statements. You have not specified an owning parser by using the DOMAIN clause on the CREATE statement.
• An MRM message tree has been constructed, then only part of it has been passed, by specifying a subfolder or field, to the ASBITSTREAM function with the parser mode option set to RootBitStream. This combination is not valid, and results in a zero length BLOB.
• You have copied a message tree, or part of a message tree, to a folder and the owning parser association is not maintained.

• When you create a message tree folder in a user-defined node, associate an owning parser with it. Use code similar or equivalent to:

  createElementAfter(String parserName)
     createElementAsFirstChild(String parserName)
     createElementAsLastChild(String parserName)
     createElementBefore(String parserName)
  

• When you use ESQL CREATE to create a message tree folder, use the DOMAIN clause to associate an owning parser with the message tree, for example:

  CALL CopyMessageHeaders();
     DECLARE outRef REFERENCE TO OutputRoot;
     CREATE LASTCHILD OF outRef AS outRef DOMAIN 'BLOB' NAME 'BLOB';
     CREATE LASTCHILD OF outRef NAME 'BLOB' VALUE X'01';
  

  This code creates a BLOB folder that has the BLOB parser associated with it.
• When copying a message tree, or part of a message tree, ensure that the owning parser association is maintained, by first serializing, then reparsing the message into the appropriate message tree. An example scenario is where you have created a field:

  SET Environment.Variables.myMsg = InputRoot.XMLNS;
  

  Now you must pass it to the ASBITSTREAM function. Unless you use ESQL similar or equivalent to:

  DECLARE xmlMsgBlob BLOB
            ASBITSTREAM(InputRoot.XMLNS, InputRoot.MQMD.Encoding, InputRoot.MQMD.CodedCharSetId);
    CREATE LASTCHILD OF Environment.Variables.myMsg DOMAIN('XMLNS')
           PARSE(xmlMsgBlob,
                 InputRoot.MQMD.Encoding,
                 InputRoot.MQMD.CodedCharSetId);

  the result is a zero length bit stream.

• Using a user-defined node
• Using an MQGet node
• Using ESQL

create procedure writeWAS_JMS(IN OutputTree reference,IN boundary char)
/***************************************************************************
* Serialise a MIME tree as normal, but then strip off any initial headers
* and save the Content-Type value in the RFH2 header as expected by WAS/JMS.
* Note: boundary - must be supplied with the leading hyphen pair
***************************************************************************/
begin
  -- convert MIME subtree to BLOB
  declare body BLOB asbitstream(OutputTree.MIME);

  -- locate first occurrence of boundary and discard any data before this
  declare firstBoundary integer;
  set firstBoundary = position (cast(boundary as blob ccsid 819) in body);
  set body = substring(body from firstBoundary);

  -- save the MIME Content-Type value in the RFH2 header. Any other MIME
  -- headers which need to be preserved in the RFH2 header can be handled
  -- in the same way
  set OutputTree.MQRFH2.usr."contentType" = OutputTree.MIME."Content-Type";

  -- clear the MIME tree and create a new BLOB child for the modified body
  set OutputTree.MIME = null; 
  CREATE LASTCHILD OF OutputTree DOMAIN('BLOB')PARSE(body);
end

create procedure getBoundary(IN ct reference,OUT boundary char)
/*****************************************************************
* return value of the boundary parameter from a Content-Type value
******************************************************************/
begin
  declare boundaryStart  integer;
  declare boundaryEnd    integer;

  set boundaryStart  = position('boundary=' in ct) + 9;
  set boundaryEnd    = position(';' in ct from boundaryStart);	
  if (boundaryStart <> 0) then
    if (boundaryEnd <> 0) then
  	  set boundary  = substring(ct from boundaryStart for boundaryEnd-boundaryStart);
    else
      set boundary  = substring(ct from boundaryStart);
    end if;		
  end if;
end;

SET OutputRoot = InputRoot;

declare boundary char;
CALL getBoundary(OutputRoot.Properties.ContentType, boundary);

CALL writeWAS_JMS(OutputRoot,boundary);

Exception in thread "Thread-15" java/lang/StackOverflowError: operating system stack overflow
        at com/ibm/broker/plugin/MbOutputTerminal._propagate    (Native Method)
        at com/ibm/broker/plugin/MbOutputTerminal.propagate    (MbOutputTerminal.java:103)
        at com/ibm/xsl/mqsi/XMLTransformNode.evaluate    (XMLTransformNode.java:1002)
        at com/ibm/broker/plugin/MbNode.evaluate (MbNode.java:1434)
        at com/ibm/broker/plugin/MbOutputTerminal._propagate   (Native Method)
        at com/ibm/broker/plugin/MbOutputTerminal.propagate   (MbOutputTerminal.java:103)
        at com/ibm/xsl/mqsi/XMLTransformNode.evaluate   (XMLTransformNode.java:1002)
        at com/ibm/broker/plugin/MbNode.evaluate   (MbNode.java:1434)
        at com/ibm/broker/plugin/MbOutputTerminal._propagate   (Native Method)
        at com/ibm/broker/plugin/MbOutputTerminal.propagate   (MbOutputTerminal.java:103)
        at com/ibm/xsl/mqsi/XMLTransformNode.evaluate   (XMLTransformNode.java:1002)
        at com/ibm/broker/plugin/MbNode.evaluate (MbNode.java:1434)

export MQSIJVERBOSE=-verbose:stack,sizes

  -Xmca32K        RAM class segment increment
  -Xmco128K       ROM class segment increment
  -Xmns0K         initial new space size
  -Xmnx0K         maximum new space size
  -Xms125000K     initial memory size
  -Xmos125000K    initial old space size
  -Xmox250000K    maximum old space size
  -Xmx250000K     memory maximum
  -Xmr16K         remembered set size
  -Xlp0K          large page size
                  available large page sizes: 4K 16M
  -Xmso256K       OS thread stack size
  -Xiss2K         java thread stack initial size
  -Xssi16K        java thread stack increment
  -Xss256K        java thread stack maximum size
  -Xscmx16M       shared class cache size

Note: The stack size defaults to 256K.

1. Issue the following command to set the operating system stack size for Java to 2 MB:

   export IBM_JAVA_OPTIONS=-Xmso2m

2. Restart the integration node.