|
Even with the above, the programs calling those top level procedures have to jump through hoops to either OMIT or no OMIT the param.
Hmmm... you aren't simply passing the whole record back to the caller and letting it manipulate the fields, make them null, etc, are you? If so, I wonder where the benefit is? Does it save you anything over simply chaining to the file in the routine that needs it?
I would think that you'd be writing something more like a business model. Something that corresponds directly to what your programs will need to do -- rather than just mimicking what the database routines do.
If you do code it as a business model, does the caller still need to set a field is NULL? Often times, fields are set to null when the initial record is written, and then the fields are "filled in later." In that case, you wouldn't really need to communicate that information back, would you? Just write the initial record with null set, and turn null off whenever the field is updated.
But if you do need to communicate it, I'd typically use a special value (blanks, or -1, or zero, or 999999 depending on what the field is) and just set the %NullInd immediately before writing the record.
I agree that null support right now is one of those ever-present "half-finished" functions in RPG. In every release there's always stuff where it seems like they started it, but never finished it. Null support is definitely one of those things!
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.
midrange.com
