A literal is a self-defining constant that can be referred to in
a program. A literal can belong to any of the RPG IV data types.
Character 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).
Hexadecimal Literals
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.
Numeric Literals
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
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
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
For example, Z'2014-12-03-11.41.52' has 6 fractional seconds,
equivalent to Z'2014-12-03-11.41.52.000000',
Z'2014-12-03-11.41.52.123' has three fractional seconds,
equivalent to Z'2014-12-03-11.41.52.123000',
Z'2014-12-03-11.41.52.1234567' has seven fractional seconds,
and Z'2014-12-03-11.41.52.123456789012' has twelve fractional seconds.
Graphic Literals
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
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.
UCS-2 literals are assumed to be in the default UCS-2 CCSID of
the module.