Read these notes to help you to migrate message sets to WebSphere® Message Broker Version 6.0.
If you are using the Message Brokers Toolkit Version 5.1, replace all references in this topic to "Version 5.0" with "Version 5.1".
To migrate message sets from Version 2.1 to Version 6.0, use the mqsimigratemsgsets command to convert your Version 2.1 message set export files (.mrp) into Version 6.0 message set projects. Before you run the command, refer to the Migrating Message Sets from Version 2.1 topic, which provides detailed notes on its operation.
For guidance about changes to the behavior of parsers, and for general migration information, see the following sections:
To migrate message sets from Version 5.0 to Version 6.0, no migration commands are necessary. Message Brokers Toolkit Version 6.0 can read the content of a Version 5.0 message set project and automatically converts it to Version 6.0 format when you modify and save it for the first time.
For guidance about changes to the behavior of parsers, and for general migration information, see the following sections:
<!ELEMENT e0 (e1|e2)+ >In the output message, the element declaration has changed:
<!ELEMENT e0 (e1|e2)+>The new behavior is consistent with the way that the XML physical format processes white space in all other XML constructs.
A specific example of this condition is where your message contains an embedded message and you are using either the Message Key or Message Identity technique to identify the embedded message. If the element that is providing the message key or message identity value fails to be matched with the model, the parser does not know whether to interpret its value as a message key or message identity.
Prior to Version 6.0, the parser attempts to make sense of all out-of-order Tagged Delimited groups, with a consequent reduction in performance. In Version 6.0, if this behavior is a problem, consider modeling the unordered content of the group as an embedded child group with Composition set to UnorderedSet.
A complex element or group can be identified from the bit stream if it provides a group indicator, a tag, or a data pattern, or if its child members provide a group indicator, tag, or data pattern.
Despite its name, under some circumstances members of a Tagged Delimited group do not need to provide a tag; specifically, if the member is an embedded message or is a complex element or group.
In Version 5.0, if the CWF property Repeat Count is not set and Min Occurs is not equal to Max Occurs, the number of repeats is taken to be one. In Version 6.0, the number of repeats is taken to be Max Occurs. A warning cannot be generated for this situation. Such a message model is not created by the COBOL or C importers, therefore it can occur only if you have created a CWF message model using the Version 5.0 message editor.
Continue to use TDS Message Key if the message set will ever be deployed to a Version 5.0 or Version 2.1 broker, because these brokers do not support the Message Identity technique of embedded message identification.