To migrate message sets from Version 2.1 to Version 6.0 use the mqsimigratemsgsets command. It is not necessary to use this command when migrating from Version 5.0 to Version 6.0.
Do not modify the message set file manually between export from Version 2.1 and import into WebSphere Message Broker Version 6.0 because this causes errors, indicated by those warning and error messages in the report: BIP0141, BIP0142 to BIP0157, and BIP0163.
Any unreferenced value constraint is discarded with a BIP0158, BIP0159, or BIP0160 warning message.
For each .mrp file encountered, a new message set project is created with a name that is derived from the message set name and level in Version 2.1. The utility does this by adding a suffix to the message set name for all Level values other than 1. This process restores the one-to-one mapping and enables the broker to locate just one message set, given the name.
For example, a Version 2.1 message set with name SWIFT and Level 1, migrates in Version 6.0 to the message set name SWIFT, whereas a Version 2.1 message set with name SWIFT and Level 2 migrates in Version 6.0 to SWIFT_2.
A single message definition .mxsd file is created within the message set with the same name as the message set and in the default (notarget) namespace, unless the -part parameter is present.
In Version 2.1, all elements and compound types are global. In Version 6.0, xsd:elements and xsd:complex types can be global or local. When you migrate a Version 2.1 message set, you will probably find that many elements and compound types that were global in Version 2.1 have been converted into local xsd:elements and xsd:complex types in Version 6.0, according to the rules stated above.
This means that the valid content of a compound type can be any object in the message set, subject to Type composition property rules. Typically in this case, the compound type has not been modelled with any explicit content.
This can cause the mqsimigratemsgsets command to incorrectly make certain elements local rather than global. If you use Open defined and you find that after migration a runtime validation error BIP5372E occurs, when previously it did not, rerun the mqsimigratemsgsets command with the -g parameter.
In Version 2.1, a prefixed identifier was intended to indicate that an element is local. However, it is possible that an element with a prefixed identifier is actually used in more than one compound type, making it global. If this is so, a global xsd:element is created according to the preceding rules. A BIP0195 warning message is also issued, because this is a misuse of prefixed identifiers, and can result in duplicate global xsd:elements being created. For example, A^X and B^X, but both are used more than once, resulting in two global xsd:elements with name X.
If duplicates are created, run the mqsimigratemsgsets command again, specifying the -pl parameter. This forces all referenced elements with prefixed identifiers to be created as local xsd:elements.
Embedded simple types within compound types need special treatment because the schema model is unable to cope with this construct. As embedded simple types are deprecated, replace them by taking advantage of the mixed attribute of the containing xsd:complex type.
Embedded simple types were introduced primarily to model a complex XML element that contained data values that were interspersed between child elements. Each such data value was modelled explicitly by an embedded simple type, which acted as a placeholder for the value and also supplied its simple type.
In XML schema, there is no exact equivalent. The closest is the mixed attribute of xsd:complexType. However, this only states that text can appear before or between child elements. It implies nothing about the location or data type of the text.
To retain this semantic, a schema extension is introduced, called the Embedded Simple Type. This is an unnamed local xsd:element of the appropriate simple type. The type itself is a restriction of the real underlying xsd:simple type, with a special name (commencing ComIbmMrm_Anon).
This situation produces a BIP0161 warning message and needs special treatment because the schema model is unable to cope with this compound construct. Compound elements are deprecated, so replace the use of compound elements with the use of normal elements that reference the global xsd:complexType, as described in 1 below, and take advantage of the mixed attribute.
Such compound types were introduced primarily to model a complex XML element that contained a data value as well as child elements. So an element of such a complex type has both complex content like a normal complex element, but also has a value like a simple element (the MRM base type information).
In XML schema, there is no exact equivalent. The closest is use of the mixed attribute of the xsd:complexType. But this just says that text can appear before and between (or just between) child elements. It implies nothing about the location or data type of the text.
A compound element is created for each element that referenced the compound type. Note that this can be done only if the element was itself a member of another compound type.
The combination of these two things means that meaningful use of such compound types within a message is preserved, because the MRM base type information is lost only when it was never used actively in a message.
The special data types that are created by the situations described in the preceding sections, commencing ComIbmMrm, are defined in an XML schema called .wmq21.mxsd, which is included in each message definition file that is created by the mqsimigratemsgsets command.
MRM type | Schema type |
---|---|
BINARY | xsd:hexBinary |
BOOLEAN | xsd:boolean |
DECIMAL | xsd:decimal |
DATETIME | xsd:dateTime (see the following table) |
FLOAT | xsd:float |
INTEGER | xsd:int |
STRING | xsd:string |
MRM DATETIME Date Template | Schema type |
---|---|
CCYY-MM-DDThh:mm:ss.s | xsd:dateTime |
CCYY-MM-DD | xsd:date |
CCYY-MM | xsd:gYearMonth |
CCYY | xsd:gYear |
--MM-DD | xsd:gMonthDay |
--MM | xsd:gMonth |
---DD | xsd:gDay |
Thh:mm:ss.s | xsd:time |
If the Date Template is not in the preceding list, the DATETIME is mapped to either an xsd:time or an xsd:dateTime with a BIP0175 warning message, depending on whether or not the Date Template had just a time component. However, note that this mapping can cause errors to appear in the task list after the import.
If the element concerned also had Version 2.1 Default Value, Min Inclusive, Max Inclusive, or Enumeration value constraints, the values for these do not match the lexical space for an xsd:time or xsd:dateTime, and so fail validation. These must be corrected manually using the editor.
The same task list error also appears for any Version 2.1 DATETIME type that supplied a Default Value, Min Inclusive, Max Inclusive, or Enumeration constraint where the value was not fully specified. For example, Date Template CCYY-MM, Enumeration 2003 was allowed in Version 2.1 as it was interpreted as 2003-01 at runtime. However, in the new model, the value must match the lexical space of the simple type and so must include the -01.
Notices |
Trademarks |
Downloads |
Library |
Support |
Feedback
![]() ![]() |
ad15750_ |