BCL statement validation

A BCL statement includes the following requirements:
  • Each statement contains one or more 80-byte records
  • For each record only columns 1-71 are examined, columns 73-80 are ignored
Each BCL statement is logically divided into fields. The BCL processor validates statements in your script and returns error messages if it encounters problems in the statement syntax. These messages and guidance for correcting the problems they indicate are listed in Remote build messages.

Identifier field

The identifier field indicates that a statement is a BCL statement, rather than data. The identifier field consists of the following:
  • Columns 1 and 2 of all BCL statements, except the delimiter statement, contain //
  • Columns 1 and 2 of the delimiter statement contain /*
  • Columns 1, 2, and 3 of a BCL comment statement contain //*

Name field (label, ddname, or stepname)

The name field identifies a particular statement so that other statements and the system can refer to it. For BCL statements, code the name as follows:
  • The name must begin in column 3.
  • The name contains 1 through 8 alphanumeric or national ($, #, @) characters.
  • The first character must be an alphabetic or national ($, #, @) character.
  • The name must be followed by at least one blank.
  • The name must not be JOBLIB.
  • Step names should be unique within a BCL script.

Operation field (VARS, EXEC, CALL, DD, @IF, @ELSE, or @ENDIF)

The operation field specifies the type of statement. Code the operation field as follows:
  • The operation follows the name field
  • The operation must be preceded and followed by at least one blank

Parameter or operand field

The parameter field, also referred to as the operand field, contains parameters separated by commas. Code the parameter field as follows:
  • The parameter field follows the operation field
  • The parameter field must be preceded by at least one blank
  • Keyword parameters may be specified in any order

Parameter keywords

The BCL processor also validates high-level and some low-level parameter keywords. The following parameter keywords that are validated. Any other keywords are invalid and will cause an error message to be issued.
  • For DD, the high-level parameter keywords include SYSOUT, DUMMY, DISP, RCCEXT, UNIT, DCB, SPACE, DSN, DSNAME, DSORG, and VOL=SER.
  • For DD, the low-level parameter keywords include the following:
    • For DISP, low-level parameter keywords for ‘status' include SHR, OLD, NEW, and MOD.
    • For DISP, low-level parameter keywords for ‘normal_disp' include DELETE, KEEP, PASS, CATLG, and UNCATLG.
    • For DISP, low-level parameter keywords for ‘abnormal_termination_disp' include DELETE, KEEP, CATLG, and UNCATLG.
    • For DCB, low-level parameter keywords include LRECL, BLKSIZE, and RECFM.
    • For RECFM, low-level parameter keywords should be in {{F|V}[B][S] | U}[A |M] format.
    • For DSORG, low-level parameter keywords include PO and PS.
    • For SPACE, the alloc_unit field includes only TRK, CYL and numbers of bytes.
  • For EXEC, the parameter keywords include PGM, COND, PROC, and PARM. If the BCL processor encounters the REGION or TIME keywords, it will issue a warning message, ignore these keywords, and continue processing the statement.
  • For COND, the comparison operators are EQ, NE, LE, GE, LT, or GT.
  • For @IF, valid values for ‘condition' include EQ and NE.
  • For CALL, the parameter keywords include MEMBER, COND, and WAIT.

Comment field

The comment field contains any information you deem helpful. Code the comment field as follows:
  • The comment field follows the parameter field
  • The comment field must be preceded by at least one blank

    You can code comments after the parameter field even if you continue the parameter field on a subsequent statement.

For information about continuing a comment field, see Continuing a comment field.
Note: To enable the comment field continuation feature, use the -strict option. For details about this option, see Editing the RCCRUNM or RCCRUNU member.