Consider the following WMQI message flow. The flow takes a message from an input queue, passes it through a compute node and then on out to an output node. The failure terminals of the compute and output nodes are wired to throw nodes to throw execption.

Now, imagine that the OUT queue is put disabled. This means that an error will occur.
In the first scenario, the compute node contains the following ESQL:
SET OutputRoot = InputRoot;
-- Enter SQL below this line. SQL above this line might be regenerated, causing
any modifications to be lost.
In this scenario, node Throw2 is driven and the message unwinds back to the Input node.
Next, consider the following, alternate ESQL:
SET OutputRoot = InputRoot;
-- Enter SQL below this line. SQL above this line might be regenerated, causing
any modifications to be lost.
propagate;
return false;
In this case, the node Throw2 is driven as before but this time, node
Throw1 is also driven.
This seems odd. It would initially be assumed that the ESQL "propagate" with a return of false following it would be equivalent to coming to the end of the node's ESQL itself. Apparently this is not the case.
It appears that the semantics of the "propagate" statement appears to be the following:
Propagate the message trees through the "out"
terminal
Wait for the response
If an exception was retrieved then
Do
Pass Control to the "fail" terminal
Wait for response
If an Exception is returned then
Rethrow the exception
Done
End Statement
Last Updated: 08/21/2002