After some attempts to cater for NULL values I have figured out that
UDDS is fundamentally in conflict with NULL values.
UDDS requires a program described Display file, and ANY program
described file makes the RPG compiler create the program with ALWNULL(*NO).
Further, Full Free Form RPG does not allow Program described files so
UDDS has effectively gone the way of the Dodo.
The only possible way out of the dilemma is to have a separate program
that does the file updates calling the C Ropen/Rwrite etc functions.
I think I will try the split out into a separate program.
However the question remains how the UDDS display program sets fields
to null, I think field/exit will clear a field to null, but most
probably it will be too messy if not impossible.
Possibly separate modules some with ALWNULL(*USRCTL) some with
ALWNULL(*NO) but I suspect this will cause the CRTPGM to fail,
I could replace the UDDS code with DSM but the point of this exercise
was to demonstrate UDDS.
I have a program that uses DSM here.
It will be a major rewrite to convert to DSM and probably not worth the
effort, given the power of SQL, so I may do this only as a spare time
job, if ever.
On 8/12/2018 9:18 AM, Buck Calabro wrote:
On 12/7/2018 5:06 PM, Frank Kolmann wrote:
Looks like my utility will never work on NULL capable fields.
Perhaps I can read the mapping error *DIAG messages and infer that the
-- snip from the RPG Manual ---
Database Null Value Support
Note: For a program-described file, a null value in the record always
causes a data mapping error, regardless of the value specified on the
---- end snip ----
columns are NULL. The question is whether the rest of the columns will
get populated or not.
Your updates make it better!