Request composition rules: Difference between revisions

From m204wiki
Jump to navigation Jump to search
mNo edit summary
No edit summary
 
(7 intermediate revisions by 2 users not shown)
Line 1: Line 1:
===Statement labels===
__TOC__
<p>This chapter summarizes the rules for composing compilable User Language requests. The rules for specifying statement labels in User Language statements are summarized below.          </p>
 
<p>&nbsp;</p>
 
This page summarizes the rules for composing compilable User Language requests.
 
==Statement labels==
<p>
The rules for specifying statement labels in User Language statements are summarized below.          </p>
<ul>
<ul>
<li>A statement label must begin with a letter (A-Z, a-z) which can be followed by one or more occurrences of a letter (A-Z, a-z), digit (0-9), period (.), or underscore (_). The label can be a maximum of 254 characters in length.</li>
<li>A statement label must begin with a letter (A-Z, a-z) which can be followed by one or more occurrences of a letter (A-Z, a-z), digit (0-9), period (.), or underscore (_). The label can be a maximum of 254 characters in length.</li>
Line 8: Line 15:
<li>Within a request, statement labels should be unique. If not, <var class="product">Model&nbsp;204</var> displays the message:</li>
<li>Within a request, statement labels should be unique. If not, <var class="product">Model&nbsp;204</var> displays the message:</li>
</ul>
</ul>
<p class="code">M204.0223: STATEMENT LABEL MULTIPLY DEFINED  
<p class="code">M204.0223: STATEMENT LABEL MULTIPLY DEFINED
</p>
</p>
<p>This is a warning message only; the request can still be run. </p>
<p>
====Statements that must be labeled====
This is a warning message only; the request can still be run. </p>
<p>Any statement can be labeled, but some statements must be labeled. </p>
<p>In particular, a statement must be labeled if:</p>
===Statements that must be labeled===
<p>
Any statement can be labeled, but some statements must be labeled. </p>
<p>
In particular, a statement must be labeled if:</p>
<ul>
<ul>
<li>It immediately follows a STORE RECORD or a FIND statement and an END STORE or END FIND statement is not being used to end the statement.  In this case, the statement label indicates the end of the preceding statement.    </li>
<li>It immediately follows a STORE RECORD or a FIND statement and an END STORE or END FIND statement is not being used to end the statement.  In this case, the statement label indicates the end of the preceding statement.    </li>
</li>
<li>It is referred to by later statements. In most requests, COUNT, FIND, FOR EACH OCCURRENCE, FOR EACH VALUE, NOTE, and SUBROUTINE, are referred to later and should therefore be labeled. </li>
<li>It is referred to by later statements. In most requests, COUNT, FIND, FOR EACH OCCURRENCE, FOR EACH VALUE, NOTE, and SUBROUTINE, are referred to later and should therefore be labeled. </li>
</li>
</ul>
</ul>
====Unlabeled statements====
<p>The retrieval conditions of a FIND statement, the conditions of an IF statement and ELSEIF clause, and the fields of a STORE RECORD statement must not be labeled, even if they begin new lines. </p>
===Unlabeled statements===
<p>If a statement is not labeled, it is assigned a default level of nesting. The default level is the same as the level of the previous statement. If there is no previous statement, the default is the first level. If the previous statement starts a loop or a THEN clause, or is a SUBROUTINE statement, the default level is one greater than the level of the previous statement.      </p>
<p>
====Label references====
The retrieval conditions of a FIND statement, the conditions of an IF statement and ELSEIF clause, and the fields of a STORE RECORD statement must not be labeled, even if they begin new lines. </p>
<p>Labels allow statements to refer to other User Language statements. The label reference must be coded exactly as the label, including upper- and lowercase lettering. However, the label reference must omit the colon.         </p>
<p>
===Statement block ends===
If a statement is not labeled, it is assigned a default level of nesting. The default level is the same as the level of the previous statement. If there is no previous statement, the default is the first level. If the previous statement starts a loop or a THEN clause, or is a SUBROUTINE statement, the default level is one greater than the level of the previous statement.      </p>
====Beginning a block====
<p>The FIND (except for FIND ALL VALUES), FOR, IF, ON, REPEAT, STORE, and SUBROUTINE statements begin blocks in User Language and therefore must be explicitly ended. </p>
===Label references===
====Ending a block statement====
<p>
<p>You can end a block statement in the following ways:</p>
Labels allow statements to refer to other User Language statements. The label reference must be coded exactly as the label, including upper- and lowercase lettering. However, the label reference must omit the colon.   </p>
==Statement block ends==
===Beginning a block===
<p>
The FIND (except for FIND ALL VALUES), FOR, IF, ON, REPEAT, STORE, and SUBROUTINE statements begin blocks in User Language and therefore must be explicitly ended. </p>
===Ending a block statement===
<p>
You can end a block statement in the following ways:</p>
<ul>
<ul>
<li>The appropriate block end statement (END {statement type} [label]) can be used to end any block.  </li>
<li>The appropriate block end statement (END {statement type} [label]) can be used to end any block.  </li>
</li>
 
<li>A label can be used to end blocks of multiline conditions (blocks begun by the FIND and STORE statements). A label cannot be used to end blocks of nested statements (blocks begun by the FOR, IF, ON, REPEAT, or SUBROUTINE statements).</li>
<li>A label can be used to end blocks of multiline conditions (blocks begun by the FIND and STORE statements). A label cannot be used to end blocks of nested statements (blocks begun by the FOR, IF, ON, REPEAT, or SUBROUTINE statements).</li>
</li>
 
<li>The END BLOCK statement can be used to end any block except for blocks of multiline conditions (blocks begun by the FIND and STORE statements). </li>
<li>The END BLOCK statement can be used to end any block except for blocks of multiline conditions (blocks begun by the FIND and STORE statements). </li>
</li>
 
<li>END, END MORE, END NORUN,  and END USE can be used to end any block, because these forms the END statement terminate the request, thereby ending all statements within the request.    </li>
<li>END, END MORE, END NORUN,  and END USE can be used to end any block, because these forms the END statement terminate the request, thereby ending all statements within the request.    </li>
</li>
</ul>
</ul>
===Statement format===
<p>The rules for constructing User Language statements are summarized below:      </p>
==Statement format==
====Begin statements on a new line====
<p>
<p>Each statement must begin on a new line unless it follows a THEN, ELSE, or ELSEIF clause.</p>
The rules for constructing User Language statements are summarized below:      </p>
====Statement continuation====
<b>Use of hyphens</b>
===Start each statement on a new logical line===
<p>You can continue statements onto another line by using a hyphen after the last character on the line to be continued, or by using any nonblank character in the column specified by the INCCC parameter (discussed in the Rocket <var class="product">Model&nbsp;204</var> Terminal User's Guide).    </p>
<p>
<b>Use of parentheses</b>
Each statement must begin on a new logical line unless it follows a <var>Then</var>, <var>Else</var>, or <var>ElseIf</var> clause.</p>
<p>You can continue statements using parentheses, although Rocket Software recommends that you use parentheses only to change the order of precedence in retrieval statements or with FR WHERE statements. See:</p>
 
<p>Note that, starting with version 7.5 (or earlier versions, using the Sirius Mods), a semicolon can be used to start a new logical line.  The following physical line has three logical lines:
</p>
 
<p class="code">if %flag then loop end; end if ;* You might like this style for very short If blocks
</p>
===Statement continuation===
====Use of hyphens====
<p>
You can continue statements onto another line by using a hyphen after the last character on the line to be continued, or by using any nonblank character in the column specified by the INCCC parameter (discussed in the
<var class="book">Rocket Model 204 Terminal User's Guide</var>).    </p>
====Use of parentheses====
<p>
You can continue statements using parentheses, although Rocket Software recommends that you use parentheses only to change the order of precedence in retrieval statements or with FR WHERE statements. See:</p>
<ul>
<ul>
<li>[[Record retrievals#Interpretation of Boolean operators in retrievals|Interpretation of Boolean operators in retrievals]] for a discussion of line continuation in FIND statements</li>
<li>[[Record retrievals#Interpretation of Boolean operators in retrievals|Interpretation of Boolean operators in retrievals]] for a discussion of line continuation in FIND statements</li>
</li>
 
<li>[[Record Loops#Specify retrieval criteria on one logical line|Specify retrieval criteria on one logical line]] in FR WHERE statements.</li>
<li>[[Record loops#Specify retrieval criteria on one logical line|Specify retrieval criteria on one logical line]] in FR WHERE statements.</li>
</li>
</ul>
</ul>
<b>Avoid blank lines between continued lines</b>
<p>You should not use blank lines between continued lines. The following example illustrates two problems that occur if you use blank lines between continued lines (for example, if you wanted to double space your code).</p>
====Avoid blank lines between continued lines====
<p>
You should not use blank lines between continued lines. The following example illustrates two problems that occur if you use blank lines between continued lines (for example, if you wanted to double space your code).</p>
<p class="code">B
<p class="code">B
%A = 'AAA-
%A = 'AAA-
 
BBB'
BBB'
PRINT %A
PRINT %A
IF $SETG('A','B') OR -
IF $SETG('A','B') OR -
 
   $SETG('B','C') THEN
   $SETG('B','C') THEN
   PRINT 'ERROR'
   PRINT 'ERROR'
END  
END
</p>
</p>
<p>First, when you print %A, you will get "AAA;BBB"; <var class="product">Model&nbsp;204</var> inserts a semicolon to represent the blank line. The second problem is that the second $SETG statement will be rejected with an "INVALID STATEMENT" message. To correct both problems, simply add a hyphen to each blank line following the continued line. </p>
<p>
<p>The following example illustrates proper coding:</p>
First, when you print %A, you will get "AAA;BBB"; <var class="product">Model&nbsp;204</var> inserts a semicolon to represent the blank line. The second problem is that the second $SETG statement will be rejected with an "INVALID STATEMENT" message. To correct both problems, simply add a hyphen to each blank line following the continued line. </p>
<p>
The following example illustrates proper coding:</p>
<p class="code">B
<p class="code">B
%A = 'AAA-
%A = 'AAA-
Line 79: Line 117:
   $SETG('B','C') THEN
   $SETG('B','C') THEN
   PRINT 'ERROR'
   PRINT 'ERROR'
END  
END
</p>
</p>
<b>Compatibility issues</b>
<p>In <var class="product">Model&nbsp;204</var> releases prior to Version 2.1, the compiler accepted certain types of invalid expressions, but returned unpredictable results. The following is an example of an invalid expression:</p>
====Compatibility issues====
<p>
In <var class="product">Model&nbsp;204</var> releases prior to Version 2.1, the compiler accepted certain types of invalid expressions, but returned unpredictable results. The following is an example of an invalid expression:</p>
<p class="code">IF %X = %Y *
<p class="code">IF %X = %Y *
   %Z THEN  
   %Z THEN
</p>
</p>
<p>Note that the first line (IF %X . . .) needs a continuation hyphen.</p>
<p>
<p>Invalid expressions are recognized as syntax errors and produce the following message:</p>
Note that the first line (IF %X . . .) needs a continuation hyphen.</p>
<p class="code">M204.0298: INVALID OPTION: cccc
<p>
Invalid expressions are recognized as syntax errors and produce the following message:</p>
<p class="code">M204.0298: INVALID OPTION: cccc
</p>
</p>
<p>where cccc is the program text that was in error. </p>
<p>
<p>Also, the following example code lacks continuation hyphen following an "AND" or an "OR" within a conditional IF statement.</p>
where cccc is the program text that was in error. </p>
<p>
Also, the following example code lacks continuation hyphen following an "AND" or an "OR" within a conditional IF statement.</p>
<p class="code">IF FIELD1 = A AND
<p class="code">IF FIELD1 = A AND
   FIELD2 = B AND
   FIELD2 = B AND
Line 97: Line 141:
     DO X
     DO X
</p>
</p>
<p>The above example results in a compiler error. The proper syntax for the above statement is:</p>
<p>
The above example results in a compiler error. The proper syntax for the above statement is:</p>
<p class="code">IF FIELD1 = A AND -
<p class="code">IF FIELD1 = A AND -
   FIELD2 = B AND -
   FIELD2 = B AND -
Line 103: Line 148:
     DO X
     DO X
</p>
</p>
====Line length====
<p>An input line, together with its continuation lines, constitute one logical line. Lines continued with a nonblank character in column INCCC cannot exceed LIBUFF characters. Lines continued with a hyphen before the end of a terminal line have no length limit.  </p>
===Line length===
====Blanks between words====
<p>
<p>At least one blank must separate words in a statement. Extra blanks are optional. </p>
An input line, together with its continuation lines, constitute one logical line. Lines continued with a nonblank character in column INCCC cannot exceed LIBUFF characters. Lines continued with a hyphen before the end of a terminal line have no length limit.  </p>
====Where lines can begin====
<p>Typing can begin anywhere on the terminal line. </p>
===Blanks between words===
====Logical lines====
<p>
<p>Most statements are entered as one logical line. </p>
At least one blank must separate words in a statement. Extra blanks are optional. </p>
<p>The following statements might require the use of multiple logical lines:</p>
===Where lines can begin===
<p>
Typing can begin anywhere on the terminal line. </p>
===Logical lines===
<p>
Most statements are entered as one logical line. </p>
<p>
The following statements might require the use of multiple logical lines:</p>
<ul>
<ul>
<li>FIND</li>
<li>FIND
<p>The first retrieval condition for a FIND statement can appear on the same line as the FIND clause. Other retrieval conditions which start a new line are preceded implicitly by a logical AND.</p>
<p>
The first retrieval condition for a FIND statement can appear on the same line as the FIND clause. Other retrieval conditions which start a new line are preceded implicitly by a logical AND.</p>
</li>
</li>
<li>IF and ELSEIF</li>
 
<p>The conditional expression in an IF statement or ELSEIF clause can begin on the same line as IF or ELSEIF on the next line. Each new line in the expression is preceded implicitly by a logical AND. THEN can appear on the same line as the expression or on the next line. </p>
<li>IF and ELSEIF
</li>
<p>
<li>STORE RECORD</li>
The conditional expression in an IF statement or ELSEIF clause can begin on the same line as IF or ELSEIF on the next line. Each new line in the expression is preceded implicitly by a logical AND. THEN can appear on the same line as the expression or on the next line. </p>
<p>Each fieldname = value pair of a record to be stored must be entered on a new line.</p>
</li>
</li>
<li>STORE RECORD
<p>
Each fieldname = value pair of a record to be stored must be entered on a new line.</p></li>
</ul>
</ul>
<p>The number of input lines used by FIND, IF, ELSEIF or STORE RECORD is unlimited.  </p>
<p>
====Use of semicolon to perform a carriage return====
The number of input lines used by FIND, IF, ELSEIF or STORE RECORD is unlimited.  </p>
<b>Description</b>
<p>The semicolon (;) normally performs a carriage return within a request. For example:</p>
===Use of semicolon to perform a carriage return===
<p class="code">BEGIN;PRINT.INFO: FIND AND PRINT COUNT;END  
====Description====
<p>
The semicolon (;) normally performs a carriage return within a request. For example:</p>
<p class="code">BEGIN;PRINT.INFO: FIND AND PRINT COUNT;END
</p>
</p>
<b>Do not use a semicolon after the INCLUDE statement</b>
<p>A semicolon should not be used after the INCLUDE statement because INCLUDE takes the next physical line from the specified procedure. For example, the procedure GREET consists of a single line:</p>
====Do not use a semicolon after the INCLUDE statement====
<p>
A semicolon should not be used after the INCLUDE statement because INCLUDE takes the next physical line from the specified procedure. For example, the procedure GREET consists of a single line:</p>
<p class="code">PRINT 'HELLO'
<p class="code">PRINT 'HELLO'
</p>
</p>
<p>Therefore, the following request:</p>
<p>
Therefore, the following request:</p>
<p class="code">BEGIN
<p class="code">BEGIN
INCLUDE GREET
INCLUDE GREET
END  
END
</p>
</p>
<p>causes <var class="product">Model&nbsp;204</var> to read the PRINT statement from procedure GREET immediately after the INCLUDE. If the same request is entered with semicolons:</p>
<p>
<p class="code">BEGIN;INCLUDE GREET;END  
causes <var class="product">Model&nbsp;204</var> to read the PRINT statement from procedure GREET immediately after the INCLUDE. If the same request is entered with semicolons:</p>
<p class="code">BEGIN;INCLUDE GREET;END
</p>
</p>
<p><var class="product">Model&nbsp;204</var> reads the INCLUDE statement and does what is necessary to read the next physical line from the GREET procedure. <var class="product">Model&nbsp;204</var> then looks for the next logical line, which comes from the current physical line, and sees the END statement. This terminates a request which does nothing. The command handler reads the next physical line from the GREET procedure, getting PRINT 'HELLO'. PRINT is flagged as an invalid command.  </p>
<p>
<b>The LINEND parameter</b>
<var class="product">Model&nbsp;204</var> reads the INCLUDE statement and does what is necessary to read the next physical line from the GREET procedure. <var class="product">Model&nbsp;204</var> then looks for the next logical line, which comes from the current physical line, and sees the END statement. This terminates a request which does nothing. The command handler reads the next physical line from the GREET procedure, getting PRINT 'HELLO'. PRINT is flagged as an invalid command.  </p>
<p>The LINEND parameter sets the logical line-end character to something other than a semicolon. If the LINEND parameter is set to a non-printable character, you cannot stack multiple logical lines on a single physical line. LINEND should never be set to X'00'. The Rocket <var class="product">Model&nbsp;204</var> Editing Guide discusses the effects of the LINEND parameter on the editing and including of a procedure.    </p>
===Field names and values===
====The LINEND parameter====
====Rules for field names====
<p>
<p>The rules for specifying field names in the User Language statements are summarized below.  </p>
The LINEND parameter sets the logical line-end character to something other than a semicolon. If the LINEND parameter is set to a non-printable character, you cannot stack multiple logical lines on a single physical line. LINEND should never be set to X'00'.
The
<var class="book">Rocket Model 204 Editing Guide</var>
discusses the effects of the LINEND parameter on the editing and including of a procedure.    </p>
==Field names and values==
===Rules for field names===
<p>
The rules for specifying field names in the User Language statements are summarized below.  </p>
<ol>
<ol>
<li>Any word or character, including space, can be used as part of a field name except the correction characters @ and #. The choice of symbols to signify correction characters is parameter controlled and can be changed. If you chooses different symbols, the restriction regarding the use of @ and # in field names then applies to the new symbols instead. (See the Rocket <var class="product">Model&nbsp;204</var> Parameter and Command Reference Manual.) </li>
<li>Any word or character, including space, can be used as part of a field name except the correction characters @ and #. The choice of symbols to signify correction characters is parameter controlled and can be changed. If you chooses different symbols, the restriction regarding the use of @ and # in field names then applies to the new symbols instead.
<li>If any reserved word or character is embedded in a field name, the word or character must be part of a quoted string (see the discussion on field attributes in [[Field Attributes#Field Attributes|Field Attributes]]).</li>
(See the [[List of Model 204 parameters]].) </li>
 
<li>If any reserved word or character is embedded in a field name, the word or character must be part of a quoted string (see the discussion on field attributes in [[Field attributes]]).</li>
<li>Field names that contain a colon followed by a space (for example, COLOR: CAR) cannot be distinguished from labels when used as the first word on a line. Any field name containing this combination either should be renamed or must be enclosed in single quotes at the beginning of a line.</li>
<li>Field names that contain a colon followed by a space (for example, COLOR: CAR) cannot be distinguished from labels when used as the first word on a line. Any field name containing this combination either should be renamed or must be enclosed in single quotes at the beginning of a line.</li>
<li>When more than one consecutive space appears in a field name, the extra spaces are ignored.</li>
<li>When more than one consecutive space appears in a field name, the extra spaces are ignored.</li>
<li>A field name can be subscripted by including a parenthesized expression after the name. This facilitates references to multiply occurring fields (see [[Operations on Multiply Occurring Fields#Operations on Multiply Occurring Fields|Operations on Multiply Occurring Fields]]).</li>
<li>A field name can be subscripted by including a parenthesized expression after the name. This facilitates references to multiply occurring fields (see [[Processing multiply occurring fields and field groups]]).</li>
<li>To refer to a fieldname indirectly, specify it with the format %%name (see the discussion in [[Using variables and values in computation#Field name variables|Field name variables]]). Field name variables also can be subscripted. </li>
<li>To refer to a fieldname indirectly, specify it with the format %%name (see the discussion in [[Using variables and values in computation#Field name variables|Field name variables]]). Field name variables also can be subscripted. </li>
</ol>
</ol>
<b>Examples</b>
<p>Some examples of legal field names are:</p>
====Examples====
<p>
Some examples of legal field names are:</p>
<p class="code">AGENT
<p class="code">AGENT
ANNUAL_INTEREST
ANNUAL_INTEREST
'TOTAL USE'  
'TOTAL USE'
</p>
</p>
<p>Some examples of illegal field names are:</p>
<p>
Some examples of illegal field names are:</p>
<table>
<table>
<tr class="head">
<tr class="head">
Line 184: Line 268:
</tr>
</tr>
</table>
</table>
====Rules for field values====
<p>The rules governing the formation of field values are the same as rules 1, 2, and 4 for field names (see the preceding discussion). </p>
===Rules for field values===
<p>In addition, values cannot contain more than 255 characters. </p>
<p>
====Use of quotes with field values====
The rules governing the formation of field values are the same as rules 1, 2, and 4 for field names (see the preceding discussion). </p>
<p>Although single quotes are required to enclose a text field value when the value contains reserved words or characters or when used in expressions, it is good practice to enclose the text in quotes, even if it contains no reserved words or characters. To store the field:    </p>
<p>
<p class="code">PARENTS = MARY AND JOHN SMITH  
In addition, values cannot contain more than 255 characters. </p>
===Use of quotes with field values===
<p>
Although single quotes are required to enclose a text field value when the value contains reserved words or characters or when used in expressions, it is good practice to enclose the text in quotes, even if it contains no reserved words or characters. To store the field:    </p>
<p class="code">PARENTS = MARY AND JOHN SMITH
</p>
</p>
<p>the value portion of the pair must be quoted because AND is a reserved word. Used with a STORE RECORD statement, the field should look like this:</p>
<p>
<p class="code">PARENTS = 'MARY AND JOHN SMITH'  
the value portion of the pair must be quoted because AND is a reserved word. Used with a STORE RECORD statement, the field should look like this:</p>
<p class="code">PARENTS = 'MARY AND JOHN SMITH'
</p>
</p>
<p>For more information about the use of quotation marks, refer to [[#Quotation marks|Quotation marks]].  </p>
<p>
===Quotation marks===
For more information about the use of quotation marks, refer to [[#Quotation marks|Quotation marks]].  </p>
<p>You can direct <var class="product">Model&nbsp;204</var> to display arbitrary text information by means of the single quote symbol. </p>
====Uses for quotation marks====
==Quotation marks==
<p>User Language statement employ quotation marks as follows:</p>
<p>
You can direct <var class="product">Model&nbsp;204</var> to display arbitrary text information by means of the single quote symbol. </p>
===Uses for quotation marks===
<p>
User Language statement employ quotation marks as follows:</p>
<ul>
<ul>
<li>Following a PRINT statement, any characters enclosed in single quotes are printed literally when the statement is executed. </li>
<li>Following a PRINT statement, any characters enclosed in single quotes are printed literally when the statement is executed. </li>
<li>Within a request, quotation marks can be used to provide titles for output or display messages to the end user.
</li>
</li>
<li>Within a request, quotation marks can be used to provide titles for output or display messages to the end user. </li>
 
</li>
<li>Quoted material can be included in a list with other things to be printed (see PRINT statement).</li>
<li>Quoted material can be included in a list with other things to be printed (see PRINT statement).</li>
</li>
 
<li>Quoted material can be used in expressions.</li>
<li>Quoted material can be used in expressions.</li>
</li>
 
<li>Quoted material can be saved by the NOTE statement for later use in a request.    </li>
<li>Quoted material can be saved by the NOTE statement for later use in a request.    </li>
</li>
 
<li>Single quotes also are used when a reserved word or symbol is to be interpreted in other than its standard system sense. Thus when reserved words or symbols are used in the formation of field names or values, the entire string must be enclosed in quotation marks.</li>
<li>Single quotes also are used when a reserved word or symbol is to be interpreted in other than its standard system sense. Thus when reserved words or symbols are used in the formation of field names or values, the entire string must be enclosed in quotation marks.</li>
</li>
</ul>
</ul>
====Rules for using quotation marks====
<p><var class="product">Model&nbsp;204</var> handles quotation marks as follows:    </p>
===Rules for using quotation marks===
<p>
<var class="product">Model&nbsp;204</var> handles quotation marks as follows:    </p>
<ol>
<ol>
<li>A pair of single quotation marks, for example 'TEXT', delineates a quoted string.</li>
<li>A pair of single quotation marks, for example 'TEXT', delineates a quoted string.</li>
<li>Quoted strings are stored and utilized with quote marks dropped. Thus <var>PARENTS = 'MARY AND JOHN SMITH'</var> is stored as <var>PARENTS = MARY</var><var> </var><var>AND JOHN SMITH</var>, and the statement <var>PRINT PARENTS</var> results in the output <var>MARY AND JOHN SMITH</var>.</li>
<li>Quoted strings are stored and utilized with quote marks dropped. Thus <var>PARENTS = 'MARY AND JOHN SMITH'</var> is stored as <var>PARENTS = MARY</var><var> </var><var>AND JOHN SMITH</var>, and the statement <var>PRINT PARENTS</var> results in the output <var>MARY AND JOHN SMITH</var>.</li>
<li>A pair of consecutive quotation marks inside of a quoted string is replaced by a single quotation mark when the string is stored or printed. For example, <var>PRINT </var><var>'FATHER"S NAME'</var> results in the output <var>FATHER'S NAME</var> and <var>PRINT "AND"</var> yields <var>'AND'</var>.</li>
<li>A pair of consecutive quotation marks inside of a quoted string is replaced by a single quotation mark when the string is stored or printed. For example, <var>PRINT </var><var>'FATHER"S NAME'</var> results in the output <var>FATHER'S NAME</var> and <var>PRINT "AND"</var> yields <var>'AND'</var>.</li>
<li>A pair of consecutive quotation marks that is not included in a quoted string converts to a character string of zero length, called a null string.  </li>
<li>A pair of consecutive quotation marks that is not included in a quoted string converts to a character string of zero length, called a null string.  </li>
<li>Only pairs of quotation marks are used. </li>
<li>Only pairs of quotation marks are used. </li>
</ol>
</ol>
<b>Example</b>
<p>The following examples illustrate different ways of referring to a TITLE field with the value, WHY JOHNNY CAN'T READ:</p>
====Example====
<p>
The following examples illustrate different ways of referring to a TITLE field with the value, WHY JOHNNY CAN'T READ:</p>
<p class="code">TITLE = 'WHY JOHNNY CAN"T READ'
<p class="code">TITLE = 'WHY JOHNNY CAN"T READ'
TITLE = WHY JOHNNY 'CAN"T' READ
TITLE = WHY JOHNNY 'CAN"T' READ
TITLE = WHY JOHNNY CANT""T READ  
TITLE = WHY JOHNNY CANT""T READ
</p>
</p>
====Quotation marks designating a null string====
<p>In a FIND statement, the pair:</p>
===Quotation marks designating a null string===
<p class="code">BIRTHPLACE = ''  
<p>
In a FIND statement, the pair:</p>
<p class="code">BIRTHPLACE = ''
</p>
</p>
<p>is the same as:</p>
<p>
<p class="code">BIRTHPLACE =  
is the same as:</p>
<p class="code">BIRTHPLACE =
</p>
</p>
<p>The retrieved records will contain the field BIRTHPLACE and its value will be null. If the field is printed, it will result in a blank line of output.  </p>
<p>
====Quoting a reserved word====
The retrieved records will contain the field BIRTHPLACE and its value will be null. If the field is printed, it will result in a blank line of output.  </p>
<p>To store the field, A OR B = VALUE, one of the following must be used because OR and VALUE are reserved words:    </p>
===Quoting a reserved word===
<p>
To store the field, A OR B = VALUE, one of the following must be used because OR and VALUE are reserved words:    </p>
<p class="code">A 'OR B' = 'VALUE'
<p class="code">A 'OR B' = 'VALUE'
A 'OR' B = 'VALUE'  
A 'OR' B = 'VALUE'
</p>
</p>
<p>A field name beginning with a quotation mark looks like quoted text to a PRINT statement. Thus the forms 'A OR B' and 'A OR' B should not be used.</p>
<p>
<p>After <var class="product">Model&nbsp;204</var> encounters a closing quote, it does not recognize a reserved word again until a delimiter such as a space or an operator is encountered. In the following string:</p>
A field name beginning with a quotation mark looks like quoted text to a PRINT statement. Thus the forms 'A OR B' and 'A OR' B should not be used.</p>
<p class="code">'TESTDATA'AND  
<p>
After <var class="product">Model&nbsp;204</var> encounters a closing quote, it does not recognize a reserved word again until a delimiter such as a space or an operator is encountered. In the following string:</p>
<p class="code">'TESTDATA'AND
</p>
</p>
<p><var class="product">Model&nbsp;204</var> regards the AND not as a reserved word but as part of the string (TESTDATAAND). The quotes do not actually have to surround the string.     </p>
<p>
<var class="product">Model&nbsp;204</var> regards the AND not as a reserved word but as part of the string (TESTDATAAND). The quotes do not actually have to surround the string.   </p>
 
[[Category:SOUL]]
[[Category:SOUL]]

Latest revision as of 14:42, 13 January 2019

 

This page summarizes the rules for composing compilable User Language requests.

Statement labels

The rules for specifying statement labels in User Language statements are summarized below.

  • A statement label must begin with a letter (A-Z, a-z) which can be followed by one or more occurrences of a letter (A-Z, a-z), digit (0-9), period (.), or underscore (_). The label can be a maximum of 254 characters in length.
  • A statement label should not be a User Language keyword. Model 204 interprets a statement label which is a keyword as the keyword itself, not as a statement label, if that keyword makes syntactic sense where the statement label is referenced.
  • The label must be the first word on a line, must end with a colon, and must be followed by a space.
  • A label can start in any column up to but not including column INCCC.
  • Within a request, statement labels should be unique. If not, Model 204 displays the message:

M204.0223: STATEMENT LABEL MULTIPLY DEFINED

This is a warning message only; the request can still be run.

Statements that must be labeled

Any statement can be labeled, but some statements must be labeled.

In particular, a statement must be labeled if:

  • It immediately follows a STORE RECORD or a FIND statement and an END STORE or END FIND statement is not being used to end the statement. In this case, the statement label indicates the end of the preceding statement.
  • It is referred to by later statements. In most requests, COUNT, FIND, FOR EACH OCCURRENCE, FOR EACH VALUE, NOTE, and SUBROUTINE, are referred to later and should therefore be labeled.

Unlabeled statements

The retrieval conditions of a FIND statement, the conditions of an IF statement and ELSEIF clause, and the fields of a STORE RECORD statement must not be labeled, even if they begin new lines.

If a statement is not labeled, it is assigned a default level of nesting. The default level is the same as the level of the previous statement. If there is no previous statement, the default is the first level. If the previous statement starts a loop or a THEN clause, or is a SUBROUTINE statement, the default level is one greater than the level of the previous statement.

Label references

Labels allow statements to refer to other User Language statements. The label reference must be coded exactly as the label, including upper- and lowercase lettering. However, the label reference must omit the colon.

Statement block ends

Beginning a block

The FIND (except for FIND ALL VALUES), FOR, IF, ON, REPEAT, STORE, and SUBROUTINE statements begin blocks in User Language and therefore must be explicitly ended.

Ending a block statement

You can end a block statement in the following ways:

  • The appropriate block end statement (END {statement type} [label]) can be used to end any block.
  • A label can be used to end blocks of multiline conditions (blocks begun by the FIND and STORE statements). A label cannot be used to end blocks of nested statements (blocks begun by the FOR, IF, ON, REPEAT, or SUBROUTINE statements).
  • The END BLOCK statement can be used to end any block except for blocks of multiline conditions (blocks begun by the FIND and STORE statements).
  • END, END MORE, END NORUN, and END USE can be used to end any block, because these forms the END statement terminate the request, thereby ending all statements within the request.

Statement format

The rules for constructing User Language statements are summarized below:

Start each statement on a new logical line

Each statement must begin on a new logical line unless it follows a Then, Else, or ElseIf clause.

Note that, starting with version 7.5 (or earlier versions, using the Sirius Mods), a semicolon can be used to start a new logical line. The following physical line has three logical lines:

if %flag then loop end; end if ;* You might like this style for very short If blocks

Statement continuation

Use of hyphens

You can continue statements onto another line by using a hyphen after the last character on the line to be continued, or by using any nonblank character in the column specified by the INCCC parameter (discussed in the Rocket Model 204 Terminal User's Guide).

Use of parentheses

You can continue statements using parentheses, although Rocket Software recommends that you use parentheses only to change the order of precedence in retrieval statements or with FR WHERE statements. See:

Avoid blank lines between continued lines

You should not use blank lines between continued lines. The following example illustrates two problems that occur if you use blank lines between continued lines (for example, if you wanted to double space your code).

B %A = 'AAA- BBB' PRINT %A IF $SETG('A','B') OR - $SETG('B','C') THEN PRINT 'ERROR' END

First, when you print %A, you will get "AAA;BBB"; Model 204 inserts a semicolon to represent the blank line. The second problem is that the second $SETG statement will be rejected with an "INVALID STATEMENT" message. To correct both problems, simply add a hyphen to each blank line following the continued line.

The following example illustrates proper coding:

B %A = 'AAA- - BBB' PRINT %A IF $SETG('A','B') OR - - $SETG('B','C') THEN PRINT 'ERROR' END

Compatibility issues

In Model 204 releases prior to Version 2.1, the compiler accepted certain types of invalid expressions, but returned unpredictable results. The following is an example of an invalid expression:

IF %X = %Y * %Z THEN

Note that the first line (IF %X . . .) needs a continuation hyphen.

Invalid expressions are recognized as syntax errors and produce the following message:

M204.0298: INVALID OPTION: cccc

where cccc is the program text that was in error.

Also, the following example code lacks continuation hyphen following an "AND" or an "OR" within a conditional IF statement.

IF FIELD1 = A AND FIELD2 = B AND FIELD3 = C THEN DO X

The above example results in a compiler error. The proper syntax for the above statement is:

IF FIELD1 = A AND - FIELD2 = B AND - FIELD3 = C THEN DO X

Line length

An input line, together with its continuation lines, constitute one logical line. Lines continued with a nonblank character in column INCCC cannot exceed LIBUFF characters. Lines continued with a hyphen before the end of a terminal line have no length limit.

Blanks between words

At least one blank must separate words in a statement. Extra blanks are optional.

Where lines can begin

Typing can begin anywhere on the terminal line.

Logical lines

Most statements are entered as one logical line.

The following statements might require the use of multiple logical lines:

  • FIND

    The first retrieval condition for a FIND statement can appear on the same line as the FIND clause. Other retrieval conditions which start a new line are preceded implicitly by a logical AND.

  • IF and ELSEIF

    The conditional expression in an IF statement or ELSEIF clause can begin on the same line as IF or ELSEIF on the next line. Each new line in the expression is preceded implicitly by a logical AND. THEN can appear on the same line as the expression or on the next line.

  • STORE RECORD

    Each fieldname = value pair of a record to be stored must be entered on a new line.

The number of input lines used by FIND, IF, ELSEIF or STORE RECORD is unlimited.

Use of semicolon to perform a carriage return

Description

The semicolon (;) normally performs a carriage return within a request. For example:

BEGIN;PRINT.INFO: FIND AND PRINT COUNT;END

Do not use a semicolon after the INCLUDE statement

A semicolon should not be used after the INCLUDE statement because INCLUDE takes the next physical line from the specified procedure. For example, the procedure GREET consists of a single line:

PRINT 'HELLO'

Therefore, the following request:

BEGIN INCLUDE GREET END

causes Model 204 to read the PRINT statement from procedure GREET immediately after the INCLUDE. If the same request is entered with semicolons:

BEGIN;INCLUDE GREET;END

Model 204 reads the INCLUDE statement and does what is necessary to read the next physical line from the GREET procedure. Model 204 then looks for the next logical line, which comes from the current physical line, and sees the END statement. This terminates a request which does nothing. The command handler reads the next physical line from the GREET procedure, getting PRINT 'HELLO'. PRINT is flagged as an invalid command.

The LINEND parameter

The LINEND parameter sets the logical line-end character to something other than a semicolon. If the LINEND parameter is set to a non-printable character, you cannot stack multiple logical lines on a single physical line. LINEND should never be set to X'00'. The Rocket Model 204 Editing Guide discusses the effects of the LINEND parameter on the editing and including of a procedure.

Field names and values

Rules for field names

The rules for specifying field names in the User Language statements are summarized below.

  1. Any word or character, including space, can be used as part of a field name except the correction characters @ and #. The choice of symbols to signify correction characters is parameter controlled and can be changed. If you chooses different symbols, the restriction regarding the use of @ and # in field names then applies to the new symbols instead. (See the List of Model 204 parameters.)
  2. If any reserved word or character is embedded in a field name, the word or character must be part of a quoted string (see the discussion on field attributes in Field attributes).
  3. Field names that contain a colon followed by a space (for example, COLOR: CAR) cannot be distinguished from labels when used as the first word on a line. Any field name containing this combination either should be renamed or must be enclosed in single quotes at the beginning of a line.
  4. When more than one consecutive space appears in a field name, the extra spaces are ignored.
  5. A field name can be subscripted by including a parenthesized expression after the name. This facilitates references to multiply occurring fields (see Processing multiply occurring fields and field groups).
  6. To refer to a fieldname indirectly, specify it with the format %%name (see the discussion in Field name variables). Field name variables also can be subscripted.

Examples

Some examples of legal field names are:

AGENT ANNUAL_INTEREST 'TOTAL USE'

Some examples of illegal field names are:

Unacceptable How to correct...
YEAR TO DATE Year-to-date
USE COUNT 'Use count'
STRING@ Use another character, not @, or change the correction character
AND "AND"

Rules for field values

The rules governing the formation of field values are the same as rules 1, 2, and 4 for field names (see the preceding discussion).

In addition, values cannot contain more than 255 characters.

Use of quotes with field values

Although single quotes are required to enclose a text field value when the value contains reserved words or characters or when used in expressions, it is good practice to enclose the text in quotes, even if it contains no reserved words or characters. To store the field:

PARENTS = MARY AND JOHN SMITH

the value portion of the pair must be quoted because AND is a reserved word. Used with a STORE RECORD statement, the field should look like this:

PARENTS = 'MARY AND JOHN SMITH'

For more information about the use of quotation marks, refer to Quotation marks.

Quotation marks

You can direct Model 204 to display arbitrary text information by means of the single quote symbol.

Uses for quotation marks

User Language statement employ quotation marks as follows:

  • Following a PRINT statement, any characters enclosed in single quotes are printed literally when the statement is executed.
  • Within a request, quotation marks can be used to provide titles for output or display messages to the end user.
  • Quoted material can be included in a list with other things to be printed (see PRINT statement).
  • Quoted material can be used in expressions.
  • Quoted material can be saved by the NOTE statement for later use in a request.
  • Single quotes also are used when a reserved word or symbol is to be interpreted in other than its standard system sense. Thus when reserved words or symbols are used in the formation of field names or values, the entire string must be enclosed in quotation marks.

Rules for using quotation marks

Model 204 handles quotation marks as follows:

  1. A pair of single quotation marks, for example 'TEXT', delineates a quoted string.
  2. Quoted strings are stored and utilized with quote marks dropped. Thus PARENTS = 'MARY AND JOHN SMITH' is stored as PARENTS = MARY AND JOHN SMITH, and the statement PRINT PARENTS results in the output MARY AND JOHN SMITH.
  3. A pair of consecutive quotation marks inside of a quoted string is replaced by a single quotation mark when the string is stored or printed. For example, PRINT 'FATHER"S NAME' results in the output FATHER'S NAME and PRINT "AND" yields 'AND'.
  4. A pair of consecutive quotation marks that is not included in a quoted string converts to a character string of zero length, called a null string.
  5. Only pairs of quotation marks are used.

Example

The following examples illustrate different ways of referring to a TITLE field with the value, WHY JOHNNY CAN'T READ:

TITLE = 'WHY JOHNNY CAN"T READ' TITLE = WHY JOHNNY 'CAN"T' READ TITLE = WHY JOHNNY CANT""T READ

Quotation marks designating a null string

In a FIND statement, the pair:

BIRTHPLACE =

is the same as:

BIRTHPLACE =

The retrieved records will contain the field BIRTHPLACE and its value will be null. If the field is printed, it will result in a blank line of output.

Quoting a reserved word

To store the field, A OR B = VALUE, one of the following must be used because OR and VALUE are reserved words:

A 'OR B' = 'VALUE' A 'OR' B = 'VALUE'

A field name beginning with a quotation mark looks like quoted text to a PRINT statement. Thus the forms 'A OR B' and 'A OR' B should not be used.

After Model 204 encounters a closing quote, it does not recognize a reserved word again until a delimiter such as a space or an operator is encountered. In the following string:

'TESTDATA'AND

Model 204 regards the AND not as a reserved word but as part of the string (TESTDATAAND). The quotes do not actually have to surround the string.