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 52 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
Timestamp literals take the form Z'yyyy-mm-dd-hh.mm.ss.mmmmmm' where:
Z indicates that the literal is of type timestamp
yyyy-mm-dd is a valid date (year-month-day)
hh.mm.ss.mmmmmm is a valid time (hours.minutes.seconds.microseconds)
yyyy-mm-dd-hh.mm.ss.mmmmmm is enclosed by apostrophes
Microseconds are optional and if not specified will default to zeros
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.