User Controlled Support for Null-Capable Fields and Key Fields

When an externally described file contains null-capable fields and the ALWNULL(*USRCTL) keyword is specified on a control specification, you can do the following:
You are responsible for ensuring that fields containing null values are used correctly within the program. For example, if you use a null-capable field as factor 2 of a MOVE operation, you should first check if it is null before you do the MOVE, otherwise you may corrupt your result field value. You should also be careful when outputting a null-capable field to a file that does not have the field defined as null-capable, for example a WORKSTN or PRINTER file, or a program-described file.
Note: The value of the null indicator for a null-capable field is only considered for these operations: input, output and file-positioning. Here are some examples of operations where the the null indicator is not taken into consideration:
  • DSPLY of a null-capable field shows the contents of the field even if the null indicator is on.
  • If you move a null-capable field to another null-capable field, and the factor 2 field has the null indicator on, the the result field will get the data from the factor 2 field. The corresponding null indicator for the result field will not be set on.
  • Comparison operations, including SORTA and LOOKUP, with null capable fields do not consider the null indicators.

A field is considered null-capable if it is null-capable in any externally described database record and is not defined as a constant in the program.

When a field is considered null-capable in an RPG program, a null indicator is associated with the field. Note the following:

Null indicators are initialized to zeros during program initialization and thus null-capable fields do not contain null values when the program starts execution.