Syntax rules and recommendations

This section lists rules and recommendations governing syntax. It does not provide information regarding specific details, e.g. as to the maximum length of an operand name. Such detailed information can be found in the descriptions of the ADD statements, which are used to enter the syntax of commands and statements in a syntax file.

In the following, the words “should” and “may” are used for recommendations; the word “must” denotes rules which must be complied with. The recommendations for commands also apply to statements.

• The name of a command, statement or operand, as well as an operand value of the type KEYWORD, may be made up of several subnames, connected together by hyphens. All subnames should be based on natural language. When two things are the same, the same subname should be used for them.

  During input, the subnames may be abbreviated as desired and/or omitted entirely from right to left, provided SDF can unambiguously identify the full name on the basis of the abbreviation.

• The name of a command should begin with a verb. The subname following the verb should indicate the object that is processed by the command. The ALIAS-NAME must be different from NAME or STANDARD-NAME. If the possibility of a command name colliding with the name of a new command supplied by Fujitsu Siemens Computers as part of a future version of the program is to be absolutely ruled out, the subname “X” can be used as the beginning of the command name.

• Each function should be dealt with by a separate command, taking care that the function is not too complex. There should be complementary commands for complementary functions.

• Each operand must have a name.
  During input, an operand may be specified either as a positional operand or as a keyword operand.

• Optional operands must have a default value.

• Operands that are relevant only when another operand has a certain specific value should be attached to that value in a structure. A structure consists of one or more operands, enclosed in parentheses. It is attached to the value of a higher-ranking operand.

• Operands logically belonging together should be placed together in a structure. It may make sense to construct a higher-ranking operand expressly for the purpose of introducing the structure.

• Structures should not be nested to more than five levels.
  =>>No more than five levels of nesting are allowed for structures.

• The name of an operand within a structure need be unique only within that structure. Nevertheless, it is expedient during input if the name is unambiguous for all commands and statements. The structure can then be implicitly selected by specifying the operand.

• An operand value must be defined as one of the following data types:

  <alphanumeric-name>
  <cat-id>
  <composed-name>
  <c-string>
  <date>
  <device>
  <fixed>
  <filename>
  <integer>
  <long-integer>
  KEYWORD
  <name>
  <partial-filename>
  <posix-pathname>
  <posix-filename>
  <product-version>
  <structured-name>
  <time>
  <vsn>
  <x-string>
  <x-text>

  For some of these data types the possible operand value can be defined more precisely by means of additional specifications, e.g. by specifying a minimum and a maximum length (see ADD-VALUE). The data types <command-rest>, KEYWORD-NUMBER, <label> and <text> are reserved for Fujitsu Software Development.

• With the exception of keywords, the input alternatives defined for an operand must be of different data types. These data types must be syntactically disjunct, unless overlapping of data types has been permitted by means of the statement ADD-OPERAND...VALUE-OVERLAPPING. Otherwise, for example, simultaneous definition of a value of the type NAME and of an alternative value of the type STRUCTURED-NAME for an operand is not possible (see section “Mutually exclusive data types” on  "Mutually exclusive data types" in the appendix).

  VALUE-OVERLAPPING=*YES should only be used by SDF-A experts, and

  even then only if the problem cannot be solved in any other way.

• A keyword must be prefixed by an asterisk when necessary to make it distinguishable from other input alternatives (see ADD-VALUE TYPE=*KEYWORD(STAR=*MANDATORY)).

• It is possible to specify that a list of values can be entered for one operand. During input these values must be separated from one another by commas and enclosed in parentheses.

• The coexistence of operand values of data type KEYWORD and operand values of a data type with wildcards leads to special situations. A list of 6 possible cases and the results of the SDF syntax analysis for different inputs are given below:

  1. ADD-OPERAND NAME=OP1,VALUE-OVERLAPPING=*YES
     ADD-VALUE TYPE=*KEYWORD(STAR=*OPTIONAL),VALUE='ALL'
     ADD-VALUE TYPE=*FILENAME(WILDCARD=*YES)

  2. ADD-OPERAND NAME=OP1,VALUE-OVERLAPPING=*YES
     ADD-VALUE TYPE=*FILENAME(WILDCARD=*YES)
     ADD-VALUE TYPE=*KEYWORD(STAR=*OPTIONAL),VALUE='ALL'

  3. ADD-OPERAND NAME=OP1,VALUE-OVERLAPPING=*NO
     ADD-VALUE TYPE=*KEYWORD(STAR=*MANDATORY),VALUE='ALL'
     ADD-VALUE TYPE=*FILENAME(WILDCARD=*YES)

  4. ADD-OPERAND NAME=OP1,VALUE-OVERLAPPING=*NO
     ADD-VALUE TYPE=*FILENAME(WILDCARD=*YES)
     ADD-VALUE TYPE=*KEYWORD(STAR=*MANDATORY),VALUE='ALL'

  5. ADD-OPERAND NAME=OP1,VALUE-OVERLAPPING=*YES
     ADD-VALUE TYPE=*FILENAME(WILDCARD=*YES)

  6. ADD-OPERAND NAME=OP1,VALUE-OVERLAPPING=*NO
     ADD-VALUE TYPE=*KEYWORD(STAR=*MANDATORY),VALUE='V4.1'
     ADD-VALUE TYPE=*FILENAME(WILDCARD=*YES)

  During syntax analysis, SDF V4.1 treats the inputs as the following data types:

  Input of:	Case number
  	1	2	3	4	5	6
  A	keyword	filename	filename	filename	filename	filename
  *A	keyword	keyword	keyword	keyword	error	error
  **A	filename	filename	filename	filename	filename	filename
  *A/	filename	filename	filename	filename	filename	filename
  *	filename	filename	filename	filename	filename	filename
  *B	error	error	error	error	error	error
  *V4.1	error	error	error	error	error	keyword
  *V4.	filename	filename	filename	filename	filename	filename
  **V4.1	filename	filename	filename	filename	filename	filename