SMS manages suites. A suite is a collection of families, and a family is a collection of tasks and possibly other families. Tasks may have events, meters, labels etc. When it does not matter which one of the terms suite, family or task is in question, the generic term node refers to any of them.
By default, suites are independent of each other. If necessary, suites can have cross-suite dependencies. These are best avoided, since ideally a suite is a self-contained unit and SMS can be configured not to allow them.
There is a analogy between a suite definition and the UNIX filesystem hierarchy.
| Suite | Filesystem |
|---|---|
| Family | Directory |
| Task | File (executable) |
| Event | Signal (not part of the filesystem) |
| Meter | Numerical signal (not part of the filesystem) |
| Label | Text signal (not part of the filesystem) |
| Dependency | Soft link (can span filesystems) |
Normally a suite is defined using a file, but users wishing to try a simple configuration can type a definition directly into CDP. Suite definitions are best stored a suite per file. Suite definition files can use complex IOI-control statements and they may include other files.
A suite definition is normally placed in a definition file. Typically the name for the file is suitename.def, but any name may be used.
There are four sections to this. The first section explains how to define new nodes. The second explains how to define dependencies. And the third section explains the use of attributes. And the fourth explains the importance of different variables.
Notice, most of these command silently ignore extra parameters. A few new play commands was added as from SMS V4.3, and repeat is modified, and tries does not exist anymore. In SMS V4.4 more commands were added.
Once a new node is defined, eg using task-command the following attribute- and dependency-commands modify that node. The definition can be terminated, and it's parents definition continued, by a end-node commands (eg endsuite) or by an implisite end-node command (by starting another node). In practice the endfamily is the only one which is needed.
It is good practice to list all the attributes for families and suites before any tasks are defined. This makes the reading of the suite-definition file easier.