A communication error is issued when you use the enqueue facility
Scenario: You use the enqueue or dequeue tools to
put a message on a queue, but an error message is issued indicating
that a communication error has occurred with the queue manager name.
Explanation: The WebSphere® MQ queue
manager has not started.
Solution: Restart the WebSphere MQ queue manager.
The enqueue facility is not picking up changes made to a message
Scenario: You are using the IBM® Integration Toolkit message enqueue facility
to put messages to WebSphere MQ queues.
You have updated a message and want to put the message to the queue,
but your changes do not seem to have been picked up.
Solution:
Close, then reopen your enqueue file.
Select the message that you want to put to the queue.
Save and close the enqueue file.
Select the menu next to the Put a message
to a queue icon.
Click Put message.
Click the enqueue file in the menu.
Click Finish.
This action puts your updated message to the queue.
You do not know which header elements affect enqueue
Scenario: When using the Enqueue editor, the accounting
token, correlation ID, group ID, and message ID in the message header
do not seem to affect behavior.
Explanation: These fields do not affect behavior
because they are not serialized properly.
Enqueue message files are still listed after they have been
deleted
Scenario: Enqueue message files are still listed
in the menu after they have been deleted.
Explanation: Deleted enqueue files are not removed
from the menu. Nothing happens if you selecting these files.
The ESQL transform of an XML message gives unexpected results
Scenario: You have created an XML message that looks
like the following content:
<?xml version ="1.0" standalone="no"?><!DOCTYPE doc
[<!ELEMENT doc (#PCDATA)*>]><doc><I1>100</I1></doc>
You
apply the ESQL transform:
SET OutputRoot.XMLNS.doc.I1 = 112233;
This
transform generates the XML message (after serialization):
<?xml version ="1.0" standalone="no"?><!DOCTYPE doc
[<!ELEMENT doc (#PCDATA)*>]<I1>112233<I1>><doc><I1>100</I1></doc>
The new value for I1 has been put inside
the DOCTYPE, and has not replaced the value of 100,
as you expected.
Explanation: The XML in your message contains two doc elements:
The doctype element
The xmlElement that represents the body of the
message
The parser has found the first instance
of an element called doc and has created a child I1 with
the value 112233.
Solution: To assign a new value to the element I1 within
the message body element doc, explicitly identify
the second doc element, in the following way:
SET OutputRoot.XMLNS.(XML.tag)doc.I1 = 112233;
An XML message loses carriage return characters
Scenario: You are parsing an input XML message that
contains carriage return or line feed characters, or you are writing
an output XML message that contains carriage return line feed characters
in an XML element. However, some or all the carriage return characters
are not present in the output message.
Explanation: This behavior is correct, as described
by the XML specification, and occurs in the XML, XMLNS, or XMLNSC
domains.
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.
Solution: XML-compliant data must not rely on the
presence of carriage return line feed characters because in XML, the
line feed character is only a line feed character and XML-compliant
applications or data must be aware that the parser normalizes any
carriage return line feed characters.
The broker is unable to parse an XML message
Scenario: You receive a large XML file and wrap
it in a SOAP envelope to be passed to a .NET web service. The broker
is unable to parse the XML message
Explanation: The message that you receive is defined
as UTF-8 but it contains UTF-16 characters, such as £. The presence
of these characters causes a problem with the parser: the broker is
unable to parse the XML message because it contains an invalid character.
Solution: Force the coded character set ID (CCSID)
to 1208 instead of the default 437.
Unexpected characters are displayed when using the XSLTransform node on z/OS
Scenario: When using the XSLTransform node on z/OS®, all the uppercase Os that are
in an XML file on the incoming message are changed to underscore characters.
Explanation: The XSLTransform node input message
must come in as ASCII for the transform to work correctly. The XSLTransform node does not
work with XML or XSL data in EBCDIC code. Java™ assumes a conversion from EBCDIC 1047. IBM Integration Bus then converts to EBCDIC 500,
because the CCSID is set to 500. EBCDIC 1047 and EBCDIC 500 are similar.
Only uppercase O, J, and Z are
different. (J and Z are also converted incorrectly.) The conversions
leave a string that is unreadable because it is really in ASCII. However,
it does convert the O from an EBCDIC 1047 character
to an EBCDIC 500 character.
Solution: Change your program either to do a string
assignment without any conversions, or specify that the string is
in ASCII ISO-8859-1 (CCSID 819).
Error message BIP5004 is issued by the XMLNS
parser
Scenario: Error message BIP5004 is
issued, indicating that the XMLNS parser has encountered a problem
with an input XML message.
Explanation: This message is issued for a number
of reasons. Some of the more commonly occurring scenarios when this
message is issued are:
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.
Solution:
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.
Error message BIP5378 is issued by the MRM
parser
Scenario: Error message BIP5378 is
issued, which reports a problem with a missing mandatory repeating
element in an MRM message.
Explanation: This message indicates that a mandatory
repeating element is not present in the message. In previous
releases, this condition was reported by error message BIP5374 which
now reports only when a mandatory repeating element exists in the
message but has the incorrect number of instances.
If you have programmed
automated error checking routines, review and change these routines
if appropriate.
Solution: Check your message definition
to ensure that the element must be mandatory, and repeating. The error
message tells you the elements that occur before and after the expected
location of the missing element. If the definition is correct, the
message has not been created correctly by the sending application,
which must be amended.
Error message BIP5005 is issued by the Compute node
Scenario: You send a simple XML message into a simple
message flow. The message is:
<doc><I1>100</I1></doc>
The Compute node in the message
flow contains the following ESQL:
SET OutputRoot.XMLNS.abc = InputBody;
You
expect the following output message to be created:
<abc><doc><I1>100</I1></doc></abc>
The Compute node
generates error message BIP5005 and does not implement
the ESQL.
Explanation: You are assigning an element of one
type (root) to an element of another type (xmlElement).
The parser does not do this implicit cast for you.
Solution: You can do the cast yourself in the ESQL
to achieve the result that you want, using either of the following
two casts:
SET OutputRoot.XMLNS.(XML.Element)abc = InputBody;
or:
SET OutputRoot.XMLNS.(XML.tag)abc = InputBody;
A message is propagated to the Failure terminal of a TimeoutControl node
Scenario: The TimeoutControl node receives
a message with invalid, corrupt, or missing timeout information. The
message is propagated to the Failure terminal of the TimeoutControl node and an
exception list is generated.
Explanation: The following error conditions can
cause propagation to the Failure terminal:
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.
Solution: Check for one or more of the error conditions
listed here, and correct them.
Message processing fails within a TimeoutNotification node
Scenario: A message is propagated to the Failure
or Catch terminal of a TimeoutNotification node.
Explanation: If the processing of a timeout generates
an error within the TimeoutNotification node, an
exception list is generated and a message is propagated to the Failure
terminal. This action is done under the same transaction, if one is
being used. If the Failure terminal is not connected, propagation
does not occur.
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.
Solution: Ensure that the Failure and Catch terminals
of your TimeoutNotification node
have been connected correctly.
An MRM CWF message is propagated to the Failure terminal
Scenario: Your MRM CWF message is propagated to
a Failure terminal, and generates error messages BIP5285, BIP5125,
and BIP5181 or messages BIP5285, BIP5125,
and BIP5288.
Explanation: These errors report an inconsistency
between the length of the message being processed, and the length
of the message that is defined in the message model.
Solution: Ensure that the length of the message
as defined in the CWF layer is accurate. Check and correct the definition.
Problems with XML attributes
XML tags are written where XML attributes
are expected, and vice versa.
Explanation: The XML domains and the XML Wire Format
in the MRM domain have their own representation of XML attributes.
XML domains rely on setting a field type of XML.Attribute
in the message tree, because they have no model to parse against.
For the XML Wire Format in the MRM domain, the message model
indicates whether an element is an attribute or a tag, therefore the
message tree does not need to reflect whether a field is an attribute
or a tag.
Therefore, if fields are copied out of the XMLNS or
MRM domains, the fact that fields are attributes is lost. This loss
happens if they are copied out to each other, or to another message
tree, such as the environment tree.
This problem typically
appears in the following situations:
Scenario 1: You are writing an XML message in the
MRM domain, and XML tags are being written instead of XML attributes.
Solution 1: Check that your message tree has the
same structure and sequence as the message model. If the message tree
does not match the message model, the field is written as self-defining,
and consequently the XML Render property is not used.
Switch on message validation. Validation shows where the message
tree and message definition do not match.
Alternatively, take a user debug trace of the message flow; BIP5493W messages
indicate which fields are being written as self-defining. Use this
information to ensure that the message tree matches the model. When
you have corrected any discrepancies, attributes are correctly written.
Scenario 2: An MRM message has been copied to an
XMLNS domain, and the XML attributes are now written as tags.
Solution 2: Take one of these actions:
Serialize the XML message in the MRM domain, for example using
the ESQL ASBITSTREAM function, then use the ESQL CREATE PARSE clause
to reparse the message using the required XML domain.
When copying fields between the MRM domain and XMLNS, copy
attribute fields individually, and specifically specify XML.Attribute
on the target XML field.
Scenario 3: An XML message has been copied to another
message tree, such as Environment. When the message is copied back
to the XML message tree, XML attributes are now seen as XML tags.
Solution 3: Serialize the XML message, for example
using the ESQL ASBITSTREAM function, then use the ESQL CREATE PARSE
clause to reparse the XML message into the required target message
tree. See CREATE statement for an example.
Scenario 4: A portion of a non-XML message tree
has been detached and attached to an XML tree, and XML tags are now
written as XML attributes.
Solution 4: Do not detach and attach portions of
message trees that are owned by different parsers. Instead, use a
tree copy.
Scenario 5: An XML tag is copied to an XML attribute
and the XML attribute is not written in the output message.
Solution 5: When referencing the source XML tag,
use the ESQL FIELDVALUE function to copy the specific field value
to the target XML attribute field.
An MRM XML message exhibits unexpected behavior
Scenario: Your message flow is processing a message
that you have modeled in the MRM. The message tree has not been created
as you expected, the output XML message does not have the expected
contents, or the message contents are not being validated. No error
message has been issued.
Explanation: Two reasons might cause this problem:
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 broker 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 broker 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 broker 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 broker 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.
The MRM parser has failed to parse a message because two attributes
have the same name
Scenario: Two attributes in different name spaces
have identical names. Error message BIP5117 is issued.
Explanation: The MRM parser has failed to parse
the message.
Solution: Modify the attribute names so that they
are not identical. This problem is a known limitation with the parser.
You encounter problems when messages contain EBCDIC newline
characters
Scenario: If your bit stream input message contains
EBCDIC newline (NL) characters, problems might arise if your message
flow changes the target CCSID to an ASCII CCSID. For example, during
conversion from CCSID 1047 (EBCDIC used for z/OS Open Edition) to CCSID 437 (US
PC ASCII), an NL character is translated from hex '15' to hex '7F',
which is an undefined character. The error occurs because no corresponding
code point for the newline character exists in the ASCII code page.
Solution: You can overcome the problem in these
cases:
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 parser produces a runtime error while parsing a message
Scenario: A MIME message is received by a message
flow and produces a runtime error when the message is parsed.
Explanation: The following errors can cause the
MIME parser to reject a message:
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.
Solution: Check the MIME message for one or more
of the error conditions listed here, and correct them.
Runtime errors are issued when you write a MIME message from
the logical message tree
Scenario: You are writing a MIME logical message
tree as a bit stream and the parser generates a runtime error.
Explanation: The following errors can cause the
MIME parser to reject a logical message tree:
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.
Solution: Check the MIME logical message tree for
one or more of the error conditions listed here, and correct them.
Output message has an empty message body
Scenario: You have unexpectedly encountered an empty
message body, or the ASBITSTREAM function has produced a zero length
BLOB.
Explanation: This error can happen for the following
reasons:
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:
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.
Solution: Depending on the reason for the empty
message body or zero length BLOB, ensure that:
When you create a message tree folder in a user-defined node,
associate an owning parser with it. Use code similar or equivalent
to:
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:
Output message has an invalid message body indicated by error
message BIP5005, BIP5016, or BIP5017
Scenario: You have unexpectedly encountered a multi-root
message body or a message without any root.
Explanation: This error can occur when you have
created an XML message tree folder with multiple roots or no root
at all by:
Using a user-defined node
Using an MQGet node
Using ESQL
Solution: Ensure that the final output message tree
has one, and only one, XML root node.
Error message BIP5651 is issued when receiving
a SOAP with Attachments message from a WebSphere Application Server client
Scenario: When a WebSphere Application Server client sends a SOAP with
Attachments message to the broker over JMS, error message BIP5651 is
issued stating that no valid Content-Type header has been found.
Explanation: When a WebSphere Application Server client sends a SOAP with
Attachments message to the broker over JMS, the MIME Content-Type
value appears in the MQRFH2 header and not in the MIME message body.
Solution: To solve this problem, the Content-Type
value needs to be copied from the MQRFH2 header to the beginning of
the message as a MIME header before the message is parsed. The following
ESQL adds the Content-Type value to the beginning of the WebSphere Application Server message, then invokes the
MIME parser on the result.
create procedure parseWAS_JMS(IN InputMessage reference,IN OutputMessage reference)
/***********************************************************************
* convert a WAS/JMS message to the correct format for the MIME parser
***********************************************************************/
begin
-- get the data as a BLOB
declare body BLOB InputMessage.BLOB.BLOB;
-- get the Content-Type value from the RFH2 header. Content-Type is the only
-- header which is critical for the MIME parser, but the same approach can be
-- used for any MIME headers which have been stored under the RFH2 header.
declare contentType char InputMessage.MQRFH2.usr.contentType;
-- add the contentType to the bit stream as part of an RFC822 header block
set body = cast(('Content-Type: '||contentType) as blob ccsid 819)||x'0d0a0d0a'||body;
-- invoke MIME parser on the modified bit stream
CREATE LASTCHILD OF OutputMessage DOMAIN('MIME') PARSE(body);
end;
A message flow can
take in the JMS message in the BLOB domain, and call the procedure
shown here from a Compute node.
The procedure can be called by using the following ESQL from a Compute node:
CALL CopyMessageHeaders(); -- standard procedure to copy headers
CALL parseWAS_JMS(InputRoot, OutputRoot); -- parse the ‘body' as MIME
WebSphere Application Server produces an error
when receiving a SOAP with Attachments message
Scenario: When sending a SOAP with Attachments message
to a WebSphere Application Server client using JMS,
an error is generated stating that the bit stream contains unexpected
characters.
Solution: When the broker sends a SOAP with Attachments
message to WebSphere Application Server over JMS,
the MIME Content-Type value must appear in the MQRFH2 header and not
in the body of the message. The following procedure removes any MIME
style headers from the front of the message bit stream and adds the
Content-Type value to the MQRFH2 header. The supplied boundary value
allows you to locate the start of the multipart MIME content.
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
Before calling this procedure, the message flow needs to be able to obtain
the value of the boundary. This value might be available only within
a Content-type header. The following procedure allows you to extract
the Boundary value:
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;
A Compute node
can invoke these procedures for sending a MIME message using the following
ESQL:
java_lang_StackOverflowError on AIX when processing a message flow
that contains Java nodes and
uses Java 5
Scenario: You get an abend on AIX® when processing a message flow that contains Java nodes and uses Java 5. The abend
file shows that there was an abend which indicates a segmentation
fault, but a check of the stderr file shows a
stack overflow in the JVM:
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)
Explanation:Java 5 has a parameter to
adjust the stack size for Java threads.
The default operating system stack size for Java 5 is only 256 KB. In
certain message flows (for example, flows that contain Java user-defined nodes or XMLT nodes) this
size might not be sufficient, and so you see a stack overflow error
in the stderr file. Use the JVM option -Xmso to
adjust the operating system stack for Java. You can display information about the stack by using the following
command:
export MQSIJVERBOSE=-verbose:stack,sizes
This
command creates in the stderr file on startup
an entry that has the folllowing content, or similar:
-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.
Solution:
Issue the following command to set the operating system stack
size for Java to 2 MB:
export IBM_JAVA_OPTIONS=-Xmso2m
Restart the broker.
Problems when using code page translation on HP-UX
Scenario: You experience code page translation problems
on HP-UX.
Solution: Check the WebSphere MQ queue
manager attribute CodedCharSetID. The default
value for this attribute is 1051. Change this value to 819 for queue
managers that host IBM Integration Bus components.