Rational Developer for System z

Physical formats for messages

Each message file describes both the logical structure of your messages and the physical formats that describe the precise appearance of your message bit stream during transmission. In the MRM domain physical format information must be provided, because it tells the parser exactly how to parse the message bit stream.

Overview of physical formats

You can think of a message as a packet of data that is sent from one place to another. The sender and receiver of the message will have agreed the structure of the message and what each field in the message means. This is the platform and protocol independent logical structure.

The sender and receiver will have also agreed on the physical representation of the message, how the data is physically laid out on the wire. For example, if you define a message that conveys information about a debit of an individual's bank account, it can be represented in different physical forms (examples are XML, or a fixed structure such as a COBOL copy book). The meaning and data is the same in both cases: only the physical layout has changed.

In the MRM domain, you can model a variety of different physical representations using named physical formats.
  • Use the Custom Wire Format (CWF) physical format to model fixed format messages from existing applications written in C, COBOL, PL/I, and other languages. This support includes the ability to create a message model directly from a C header file or COBOL copy book.
  • Use the XML Wire Format (XML) physical format to model XML messages, including those that exploit XML namespaces. This support includes the ability to create a message model directly from an XML DTD or XML Schema file.
  • Use the Tagged Delimited String Format (TDS) physical format to model formatted text messages, perhaps with field content identified by tags or separated by specific delimiters or both. This support is rich enough to model industry standards such as SWIFT, EDIFACT and X12.
  • Use the DBCS format when importing host terminal artifacts that contain the double-byte G field, or G or N data types, and you need to specify the NSymbol attribute in the message definition editor.
  • Use the BMS Terminal format to annotate additional BMS properties that will be required for the 3270 Link Bridge.
  • Use the Terminal format to describe the physical characteristics of a 3270 Terminal.
  • Use the CICSAdapter model for overriding message properties prior to generating runtime code (see How do I override the default name given to a generated copy book file?).

Different physical representations

The following example shows how a very simple logical message can have different physical representations.

The logical model defines the structure and order of the message. In the following example, the three fields are simple integers, and C follows B, which follows A:
int   A;
int   B;
int   C;
  • A typical Custom Wire Format representation for this logical message would be 12 bytes of data, with each of A, B and C occupying 4 bytes. Alternatively, perhaps A is 4 bytes long, but B and C are only 2 bytes long. You supply the precise physical information for each field in the message as CWF properties.
  • A typical XML representation of this model is as follows:

    <Msg><A><xxxxxxxx></A><B><xxxxxxxx></B><C>xxxxxxxx</C></Msg>

    where xxxxxxxx is the value of the integer represented as a string (XML deals only with strings).

    An alternative representation might be:

    <Msg> A = "xxxxxxxx" B="xxxxxxxx" C="xxxxxxxx"</Msg>

    where the values of the integers are stored as XML attributes rather than XML elements. You supply the precise XML rendering for each field in the message as XML properties.

  • TDS allows several different representations to be modeled. Each integer could be preceded by a tag to identify it and a delimiter to terminate it, as follows:

    {A_tag:xxxxxxxx;B_tag:xxxxxxxx;C_tag:xxxxxxxx}

    An alternative might rely on the data being ordered so only the terminating delimiter needs to be specified, as follows:

    [xxxxxxxx;xxxxxxxx;xxxxxxxx]

    You supply the precise identification regime as TDS properties.

This shows that the logical model is unchanged. It is constant, regardless of the physical representation that you choose to model on top of it, using the physical format support provided by the MRM domain. The MRM parser is able to transform the message from the input physical representation to any number of output representations, based on the wire format layers that you have defined.

Creating physical formats

Once you have created your message set, you can create physical formats. You do this using the Message Set Editor. When you next save the messageSet.sfmset file, any new physical formats are added to all the objects in all the message files in that message set.

The next time you edit an object in a message file, you will see the physical formats in the properties hierarchy pane of the Properties tab. If you click a physical format for an object, you will be presented with a property sheet where you can enter the information for that physical format for that object.

Note that not all objects have properties in all physical formats. For example:
  • CWF properties only apply to local elements and attributes, and element and attribute references.
  • Complex types and groups only have TDS properties.
  • Messages only have XML properties.

This is due to the different nature of each physical format, and these differences are explained in more detail in the section for each physical format.

There is no limit to the number of physical formats you can create in a given message set. However there are some recommendations that apply if you want to mix physical formats of different kinds in the same message set.

For further information, see Message sets. Physical formats can be deleted if no longer required.


Terms of use | Feedback

This information center is powered by Eclipse technology. (http://www.eclipse.org)