Literals

The following are the rules for specifying a character literal:

• Any combination of characters can be used in a character literal. This includes DBCS characters. DBCS characters must be enclosed by shift-out and shift-in characters and must be an even number of bytes. Embedded blanks are valid.
• A character literal with no characters between the apostrophes is allowed. See Figure 1 for examples.
• Character literals must be enclosed in apostrophes (’).
• An apostrophe required as part of a literal is represented by two apostrophes. For example, the literal O’CLOCK is coded as ‘O’’CLOCK’.
• Character literals are compatible only with character data.
• Indicator literals are one byte character literals which contain either '1' (on) or '0' (off).

The following are the rules for specifying a hexadecimal literal:

• Hexadecimal literals take the form:

  X'x1x2...xn'

  where X'x1x2...xn' can only contain the characters A-F, a-f, and 0-9.
• The literal coded between the apostrophes must be of even length.
• Each pair of characters defines a single byte.
• Hexadecimal literals are allowed anywhere that character literals are supported except as factor 2 of ENDSR and as edit words.
• Except when used in the bit operations BITON, BITOFF, and TESTB, a hexadecimal literal has the same meaning as the corresponding character literal. For the bit operations, factor 2 may contain a hexadecimal literal representing 1 byte. The rules and meaning are the same for hexadecimal literals as for character fields.
• If the hexadecimal literal contains the hexadecimal value for a single quote, it does not have to be specified twice, unlike character literals. For example, the literal A'B is specified as 'A''B' but the hexadecimal version is X'C17DC2' not X'C17D7DC2'.
• Normally, hexadecimal literals are compatible only with character data. However, a hexadecimal literal that contains 16 or fewer hexadecimal digits can be treated as an unsigned numeric value when it is used in a numeric expression or when a numeric variable is initialized using the INZ keyword.

The following are the rules for specifying a numeric literal:

• A numeric literal consists of any combination of the digits 0 through 9. A decimal point or a sign can be included.
• The sign (+ or -), if present, must be the leftmost character. An unsigned literal is treated as a positive number.
• Blanks cannot appear in a numeric literal.
• Numeric literals are not enclosed in apostrophes (’).
• Numeric literals are used in the same way as a numeric field, except that values cannot be assigned to numeric literals.
• The decimal separator may be either a comma or a period

Numeric literals of the float format are specified differently. Float literals take the form:

     <mantissa>E<exponent>

Where

     <mantissa> is a literal as described above with 1 to 16 digits
     <exponent> is a literal with no decimal places, with a value
                between -308 and +308

• Float literals do not have to be normalized. That is, the mantissa does not have to be written with exactly one digit to the left of the decimal point. (The decimal point does not even have to be specified.)
• Lower case e may be used instead of E.
• Either a period ('.') or a comma (',') may be used as the decimal point.
• Float literals are allowed anywhere that numeric constants are allowed except in operations that do not allow float data type. For example, float literals are not allowed in places where a numeric literal with zero decimal positions is expected, such as an array index.
• Float literals follow the same continuation rules as for regular numeric literals. The literal may be split at any point within the literal.

The following lists some examples of valid float literals:

    1E1                = 10
    1.2e-1             = .12
    -1234.9E0          = -1234.9
    12e12              = 12000000000000
    +67,89E+0003       = 67890  (the comma is the decimal point)

The following lists some examples of invalid float literals:

    1.234E                          <--- no exponent
    1.2e-                           <--- no exponent
    -1234.9E+309                    <--- exponent too big
    12E-2345                        <--- exponent too small
    1.797693134862316e308           <--- value too big
    179.7693134862316E306           <--- value too big
    0.0000000001E-308               <--- value too small

Date literals take the form D'xx-xx-xx' where:

• D indicates that the literal is of type date
• xx-xx-xx is a valid date in the format specified on the control specification (separator included)
• xx-xx-xx is enclosed by apostrophes

Time literals take the form T'xx:xx:xx' where:

• T indicates that the literal is of type time
• xx:xx:xx is a valid time in the format specified on the control specification (separator included)
• xx:xx:xx is enclosed by apostrophes

Timestamp literals have the form Z'yyyy-mm-dd-hh.mm.ss', optionally followed by a period followed by zero to twelve fractional seconds, Z'yyyy-mm-dd-hh.mm.ss.frac', where:

• Z indicates that the literal is of type timestamp
• yyyy-mm-dd is a valid date (year-month-day)
• hh.mm.ss is a valid time (hours.minutes.seconds)
• frac is between zero and twelve digits representing fractional seconds
• Fractional seconds are optional and if fewer than 6 fractional seconds are specified, the timestamp literal will be padded with additional zeros so that it has 6 fractional seconds.

Graphic literals take the form G'oK1K2i' where:

• G indicates that the literal is of type graphic
• o is a shift-out character
• K1K2 is an even number of bytes (possibly zero) and does not contain a shift-out or shift-in character
• i is a shift-in character
• oK1K2i is enclosed by apostrophes

UCS-2 literals take the form U'Xxxx...Yyyy' where:

• U indicates that the literal is of type UCS-2.
• Each UCS-2 literal requires four bytes per UCS-2 character in the literal. Each four bytes of the literal represents one double-byte UCS-2 character.
• UCS-2 literals are compatible only with UCS-2 data.