Recognized tokens

GDDM V3R2 Diagnosis

Recognized tokens

GDDM V3R2 Diagnosis
SC33-0870-01

The text patterns that match the lexical tokens used by the syntax are defined below using the operators defined in this list:

&

A & B indicates the character A followed immediately by the character B. For simplicity, this operator is assumed:

Between characters that are not operators.
After the operator ) and before the operator ( except that only one & is assumed between each ) and (.

|

A|B indicates either the character A or the character B.

( )

Parentheses change the relative order of priority of operators.

{ }

Operators enclosed in braces are treated as ordinary characters.

+

One or more occurrences of the immediately preceding character or group of characters if they are enclosed in parentheses.

-

Indicates a range, which may only be defined within:

Uppercase letters A through Z
Lowercase letters a through z
Digits 0 through 9.

Note: Blanks are allowed between the template characters.

Here are some examples of the text patterns that can be described using these operators:


   a+          matches  a  aa  aaaaa
   abc+        matches  abc  abcccccc  abcc
   (abc)+      matches  abc  abcabc  abcabcabc
   (a|b)       matches  a  b

   (a|b)+      matches  a  b  aba
   (a|b)+c     matches  ac  aaaac abac

The patterns that correspond to the allowed lexical tokens and their alternative forms are given in this list (uppercase or lowercase characters can be used):


   Token                Pattern

   +                    {+}
   -                    {-}
   OR                   {|}   |   (OR)
   (*)                  {(*)}
   /                    /
   AND                  {&}   |   (AND)
   EQ                   =     |   (EQ)
   NE                   (=)  |   (NE)
   LT                   <     |   (LT)
   GT                   >     |   (GT)
   LE                   (<=)  |   (=<)   |   (LE)
   GE                   (>=)  |   (=>)   |   (GE)
   (                    {(}
   )                    {)}
                       
   DO                   (DO)
   END                  (END)
   IF                   (IF)
   THEN                 (THEN)
   ELSE                 (ELSE)
   ;                    ;
   ,                    ,
   GR                   (GR)
   FR                   (FR)
   %                    %
   CLEAR                (CLEAR)
   FORCE                (FORCE)
   BINARY_NUMBER        B'(0|1)+'
   DECIMAL_NUMBER       (0-9)+
   HEXADECIMAL_NUMBER   X'(0-9|A-F)+'
   CHARACTER_STRING     '(A-Z|0-9|{(*)}|{+}|_|%|.|$||{|}|:|;|?|,)+'
   VARIABLE_NAME        (A-Z|0-9)+

The pattern matching to find tokens proceeds according to the following rules:

Any character that does not occur in the above table is invalid.
A space is automatically added to the end of each line.
Matching proceeds from a given start position until:
1. An invalid character is reached
2. A space is reached
3. No further match is possible.
The longest match is chosen.
If there are two candidates of equal length, the token that appears higher in the above list is chosen.
After a successful match, the next start position is the next nonblank character.
If there is no match, the next start position is the first nonblank character after the next blank.

Rule 2 means tokens must end at the end of a line.

Rule 3 means that the variable GOTIF is not interpreted as the variable GOT followed by the token IF.

Rule 4 means that <= is not mistaken as < and =, and that FR is not be interpreted as the hexadecimal number F followed by the variable name R.

Rule 5 ensures that THEN is not interpreted as a variable name.

Rule 6 means that tokens that can be distinguished need not be separated by a blank. Thus (1+2) is interpreted as 5 tokens.

Rule 7 means that tokens are not picked out of an invalid string; thus IF is not found in the string xxxxxIFxxx.

Blanks are required to separate tokens that could form a valid single token, otherwise they are ignored.

Note: A consequence of rule 3.b is that blanks cannot appear within a character string. An underscore character within a character string is replaced with a blank after lexical analysis has taken place.

Grammatical constructs that might appear peculiar, for example:

1 fr gr

are considered to be syntactically correct but semantically in error.


   |------------ End of Product-sensitive programming interface ------------|

Notices | Terms of use | Support | Contact z/OS