This topic contains sections marked as revised for this release
This topic contains advice for dealing with some common problems that can arise when running message flows.
This error causes the message to be directed to the failure terminal.
BIP2211: (Invalid configuration message containing attribute value [attribute value]
which is not valid for target attribute [target attribute name],
object [object name]; valid values are [valid values])
You might have connected the MQInput node failure terminal to a successive node instead of the out terminal. The out terminal is the middle terminal of the three. Messages directed to an unconnected out terminal are discarded.
If the failure terminal of the MQInput node has been connected (for example, to an MQOutput node), these messages do not appear.
Connecting a node to a failure terminal of any node indicates that you have designed the message flow to deal with all error processing. If you connect a failure terminal to an MQOutput node, your message flow ignores any errors that occur.
This action produces a user trace entry from only the nodes that the message visits.
On distributed systems, you can retrieve the trace entries using the mqsireadlog command, format them using the mqsiformatlog command, and view the formatted records to check the path of the message through the message flow.
For z/OS,
edit and submit the BIPJLOG job in COMPONENTPDS to execute the mqsireadlog and mqsiformatlog commands to process traces.
Resend your message into the message flow. Debug-level trace produces much more detail about why the message is taking a particular route, and you can then determine the reasons for the actions taken by the message flow.
Do not forget to turn tracing off when you have solved the problem, otherwise performance will be adversely affected.
SQL0954C Not enough storage is available in the application heap to process the statement.
On z/OS,
an SQLSTATE of HY014 might be returned with an SQL code of -99999, indicating
that the DataFlowEngine process has reached the DB2 z/OS process limit of 254 prepared SQL statement
handles.
For performance reasons, after the statement is prepared, the statement and handle are saved in a cache to reduce the number of calls to the SQLPrepare function. If the statement is already in the cache, the statement handle is returned so that it can be re-executed with newly bound parameters.
The statement string is used to perform the cache lookup. By using hardcoded SQL strings that differ slightly for each message, the statement is not found in the cache, and an SQLPrepare function is always performed (and a new ODBC cursor is opened). When using PASSTHRU statements, use parameter markers so that the same SQL prepared statement can be used for each message processed, with the parameters being bound at runtime. This approach is more efficient in terms of database resources and, for statements that are executed repeatedly, it is faster.
However, it is not always possible to use parameter markers, or you might want to dynamically build the SQL statement strings at runtime. This potentially leads to many unique SQL statements being cached. The cache itself does not grow that large because these statements themselves are generally not big, but many small memory allocations can lead to memory fragmentation.
Some example procedures to help you set up destination lists are provided in Populating Destination in the LocalEnvironment tree. You can use these procedures unchanged, or modify them for your own requirements.
If problems persist, empty wsplugin6.conf, restart the broker, and redeploy the message flows.
BIP5347 is usually issued during step 1. This problem can appear to be intermittent; if you restart the execution group, the message is sometimes processed correctly.
BIP5347 usually occurs on AIX, where it is caused by the default limitation of ten shared memory connections to DB2®.
BIP5347 might also be caused by the presence of a datetime value constraint in the message set, which causes the error each time the message set is deployed.
SQL1224N A database agent could not be started to service a request, or was terminated as a result of a database system shutdown or a force command.See the solution for this problem in DB2 error message SQL1224N is issued when you connect to DB2.
Unable to parse datetime internally, 9, 2001-12-17T09:30:47.0Z, yyyy-MM-dd’T’HH:mm:ss.SZZZThis error occurs because the MRM element in question has a datetime value that is not compatible with the datetime format string, so the dictionary is rejected. To solve this problem, ensure that the datetime value is compatible with the datetime format string.
BIP2130: Error converting a character string to or from codepage [code page value]
where [code page value] is either -1 or -2. You have
not, however, specified a code page of either -1 or -2 in your message tree.
You have, however, used one of the WebSphere MQ constants
MQCCSI_EMBEDDED or MQCCSI_INHERIT.SET OutputRoot.MQRFH2.(MQRFH2.Field)CodedCharSetId = MQCCSI_INHERIT;with
SET OutputRoot.MQRFH2.(MQRFH2.Field)CodedCharSetId = InputRoot.MQMD.CodedCharSetId;where the MQMD folder is the header preceding the MQRFH2 header.
db2set DB2_RR_TO_RS=YES_OVERRIDE_RI
Restart the DB2 database manager for this change to take effect.