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.
In general:
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.
If problems persist, empty wsplugin6.conf, restart the broker, and redeploy the message flows.
db2set DB2_RR_TO_RS=YES_OVERRIDE_RI
Restart the DB2 database manager for this change to take effect.
Notices |
Trademarks |
Downloads |
Library |
Support |
Feedback
![]() ![]() |
au16534_ |