Re: Interesting question and debate on ddl tables withdatefieldsthatwill not always have a value

DeLong, Eric wrote:

...
One major difference between most languages that support null and RPG is
that you cannot easily propagate null fields within your code.
Internally defined variables do not come with null flags, though you can
define them manually... To pass a null field to a procedure? Well, I
suppose you could pass two parms for each one you pass now....
Regardless, you are correct that there is a concept of null support for
RPG, but it exists only in the DB interface, and nowhere else... If all
fields supported a null attribute, then the situation would not be so
bad.

There have been a couple of small improvements in RPG's null support.

V5R2: If a file has null-capable fields, an externally-described data structure will have null-capable subfields. Also a data structure defined with LIKEREC or LIKEDS if the parent has null-capable fields.

This support was added along with the result-DS support for I/O to externally-described files. But it also gives a kludgy way of getting additional null-capable fields in a program.

V5R4: OPTIONS(*NULLIND) passes the null flags along with the variable, so the called procedure has access to the actual null flags.