Rational Developer for System z

Message sets

A message set is a container for grouping messages and associated message resources (elements, types, groups).

A message set is represented by a messageSet.sfmset file. The message set file is shown in the Navigator view under a project resource that contains message definitions.

The primary editor for modifying a message set is the flow message set editor (see Flow message set editor).

In the following example, you can see a representation of a message set named NCDPLS.Messages that contains a message set file (messageSet.sfmset) and two message files (input_NCDPLS.sfmxsd and ncdpl_rd.sfmxsd). The NCDPLS.Messages subproject is a project resource that stores the message set and associated message files. The subproject corresponds to a message set project.

Figure 1. NCDDPLS.Messages
NCDPLS.Messages
   Schema
      input_NCDPLS.sfmxsd
      messageSet.sfmset
      ncdpl_rd.sfmxsd
   .project

The service flow project tools create a message set automatically when the interface definition subproject, nonterminal applications subproject, terminal applications subproject, or outbound Web services subproject is created.

A message set contains two key properties:

Message set resources

Resources within a message set are created as files, and are displayed in the Navigator view:

Message set identification

There is a generated string of 13 characters that uniquely identifies the message set.

Message set recommendations

You can have as many message files as you want within one message set. But you are recommended to limit your message sets to a few related message files that share the same physical formats. There are several reasons for this:
  • Generation of a message dictionary and other representations is quicker.
  • Generated documentation is more manageable.
  • Physical formats apply to all objects within the message set.

    So for example, if you have an XML message and an unrelated CWF message in the same message set, then both XML and CWF physical format properties will be present for all objects. But the XML properties are of no interest to the CWF message and so will take default values in that message. (Similarly, the CWF properties are not of interest to the XML message.) This can result in unwanted task list warnings.

  • Recursion is only permitted for the XML physical format, not for CWF and TDS.

    So if you are modeling XML messages that have a recursive structure, you must ensure that recursive XML messages do not share a message set with non-XML physical formats.


Feedback