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 there is
a communication error 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 Message Brokers Toolkit's
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 and 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 puts your updated message to the queue.
You do not know which header elements have any effect in 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 have any effect.
Explanation: These fields have no effect 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
drop-down menu after they have been deleted.
Explanation: Deleted enqueue files are not removed from
the drop-down menu. Selecting these files has no effect.
The ESQL transform of an XML message gives unexpected results
Scenario: You have created an XML message that looks like
this:
<?xml version ="1.0" standalone="no"?><!DOCTYPE doc
[<!ELEMENT doc (#PCDATA)*>]><doc><I1>100</I1></doc>
You
apply the ESQL transform:
SET OutputRoot.XML.doc.I1 = 112233;
This
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,
like this:
SET OutputRoot.XML.(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 of 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.
Note that 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: Any 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 any XML compliant application 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 £. This causes a problem
with the WebSphere Message
Broker CSD04 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 XMLTransformation
node on z/OS
Scenario: When using the XMLTransformation 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 XMLTransformation node input message must
come in as ASCII for the transform to work correctly. The XMLTransformation
node does not work with XML or XSL data in EBCDIC code. Java assumes a conversion
from EBCDIC 1047. WebSphere Message Broker then converts
to EBCDIC 500, because the CCSID is set to 500. EBCDIC 1047 and EBCDIC 500
are very 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 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.XML.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.XML.(XML.Element)abc = InputBody;
or:
SET OutputRoot.XML.(XML.tag)abc = InputBody;
A message is propagated to the failure terminal of a Timeout Control
node
Scenario: The Timeout Control node receives a message with
invalid, corrupt or missing timeout information. The message is propagated
to the failure terminal of the Timeout Control 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 Timeout Control 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 Timeout Control 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 any of the error conditions listed above
and rectify them.
Message processing fails within a Timeout Notification node
Scenario: A message is propagated to the failure or catch
terminal of a Timeout Notification node.
Explanation: If there is an error in the processing of a
timeout within the Time Notification node, an exception list is generated
and a message is propagated to the failure terminal. This is done under the
same transaction, if one is being used. If the failure terminal is not wired,
propagation does not occur.
If an error happens downstream of
the Timeout Notification 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 wired, or the
propagation along the catch node fails, the processing of that timeout is
rolled back.
Solution: Ensure that the failure and catch terminals of
your Timeout Notification node are wired 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.
An MRM XML message exhibits unexpected behavior
Scenario: Your message flow is processing a message that
you have modelled 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: There are two possible reasons for this:
Explanation 1: The XML physical format settings for a message set
contain a property called Root Tag Name. This 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 XML 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 modelled in all your message definitions.
Explanation 2: In order to remain backwards compatible, the broker
recognizes the format XML and invokes the XML 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 XML 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, usually 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.BIPv600
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 retry. 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 (Xerces) parser has failed to parse
the message.
Solution: Modify the attribute names so that they are not
identical. This is a know problem with the Xerces parser.
You encounter problems when messages contain EBCDIC New Line characters
Scenario: If your bit stream input message contains EBCDIC
New Line (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. This is because there is no corresponding
code point for the New Line character in the ASCII code page.
Solution: You can overcome the problem in these
cases:
On a system where the queue manager uses an ASCII codeset, you can 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 desired 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 any of the error conditions
listed above and rectify 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.
Parts has a value-only element and this element is not the first or last
child of Parts.
Parts has children that are not value-only elements or Part children.
Parts 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 any of
the error conditions listed above and rectify them.
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 RFH2 header and not in the MIME message body.
Solution: To solve this problem, the Content-Type value
needs to be copied from the RFH2 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
and 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 bitstream 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 bitstream
CREATE LASTCHILD OF OutputMessage DOMAIN('MIME') PARSE(body);
end;
A message flow can take
in the JMS message in the BLOB domain and then invoke the procedure above
from a Compute node. The procedure can be called 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 RFH2 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 RFH2 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:
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 to 819 for queue managers that host WebSphere Message Broker components.