Serialization of input in an integration server on z/OS
To allow concurrent processing within a message flow, while still serializing messages between message flows in separate integration servers, the scope of the serialization token is restricted within a single integration server.

This example demonstrates that the serialization token is restricted
within a single integration server running on an integration node::
- Two MQInput nodes in separate message flows (in this
case
MyFlowA
andMyFlowB
) are running within the same integration serverMyGroupA
. Both MQInput nodes concurrently get messages from the shared input queue even though they are using the same serialization token. - If serialization is required within a single message flow, the message flow attribute
additional instances
must be set to zero which is the default setting. However, if greater throughput is required and serialization of input within the flow is not important, you can setadditional instances
to a value greater than zero. - The use of the
serialization token
attribute on the MQInput node does not serialize input between message flows operating within the same integration server. However, setting the attribute has no adverse affect on the processing within that integration server - In this way it is possible to maximize throughput in a message flow on one integration node while still serializing input between integration nodes. This is useful where the requirement is to have one or more integration nodes acting as an immediate standby, should the currently active integration node need to be stopped for servicing, or fail unexpectedly.