Using the Model Setting › Creating a Model › Create a Test Syntax Model › Guidelines for Writing Models

Guidelines for Writing Models

When writing models, follow these guidelines:

• The file type must be MODEL.
• Where possible, arrange the formats in the model by privilege class. Classes A through Z, class ALL, then class ANY. If a format applies to multiple classes, use the lowest value class in the format (A is the lowest class, B is greater than A, and so on).
• For performance purposes, list the most specific formats first in a class group. An operand that has a single constant value is more specific than one that is a variable. Variables have transposition routines. A single constant value is more specific than constants in mutually exclusive list.

  Weigh the previous two guidelines against the complexity of any command. For example, the IBM SET and QUERY commands are so complex, it is much easier to code the model as documented.

• If you can issue the command with no operands and it has a default operand, that format must be the last one.
• Only use transposition routines when you want to control differing values of an operand position or to differentiate between two similar formats.
• Some of the transposition routines are very specific, and may only apply to a specific CPU. For example, to qualify an operand in the USER transposition routine, the user ID must exist in the VM directory. Therefore, you must thoroughly understand the qualifications of a transposition routine before using it.
• Where possible, use the generic ANY or REST transposition routines. The limitation of the ANY transposition routine is that you cannot effectively control different variable values through rules. You can only use the REST transposition routine on the last operand in a format.

  Where practical, all of the distributed models let you write rules to give you the most control over a command. We coded them using specific transposition routines. Where appropriate, you can change models to meet your needs and improve the performance of command limiting.

• If the operand value contains characters other than alphanumeric or an asterisk (*), enclose the value in single quote marks.
• Once a command matches the CLASS criteria and matches the first operand in a format, the command continues to be validated against the format until CA ACF2 for z/ VM finds a NOMATCH=NEXTFORMAT condition.
• All OPERAND clauses coded in the FORMAT area are required unless you code them with the OPTIONAL operand or with a default value.
• Some CP commands accept more operands than are documented and, in many cases, the command processors ignore them. Set an appropriate SYNERR option to deal with them or code an operand clause to soak up the extra operands. For example, OPERAND JUNK,140,TRAN=REST.
• CA ACF2 for z/ VM command limiting is not aware of all of the finer points of a command; it can only deal with commands in a general fashion. When you execute a command with a bad syntax, command limiting can only tell which operand was bad, but not why. In these cases, set a systemwide SYNERR option, put it on the rule, or set it for the individual having problems.