The null mapping occurs because the database is opening an externally described file with at least one null capable field. The database supports effectively three modes from a program perspective:
- Inability to comprehend a NULL value; mapping error on NULL value
- Ability to tolerate reading a default value instead of NULL value
- Ability to comprehend and/or set NULL values on all operations
The first does not create any null map storage in the database run-time record image, so the record is written if the LIC [Licensed Internal Code] database code made no attempt to update the null byte map. If the LIC DB needs to update the null byte map, an exception is thrown suggesting which fields could not be mapped. For the second, either the storage exists initialized as non-null and never updated, or the LIC DB knows never to attempt to update the null byte map.

In the given case the request was to tolerate per ALWNULL(*INPUTONLY). However I believe because the file is internally described [from the perspective of the program; the compile-time file is not _E_ External], the request to tolerate was not passed on to the database open. Thus the scenario is apparently the first mode noted above. So unless and until the database open is told to tolerate the NULL value [for that open], the existence of a database NULL value will cause a mapping error when reading.

I believe the implementation for the CRTRPGMOD ALWNULL() may be working as designed [that the help text /externally described/ alludes to the declaration, not the actual file]. There would seem however, to be little harm in allowing the request to pass to the database even on a program-described declaration. Without that, it seems difficult to write a program to mimic the function of DSPPFM. The only problem would be if the allocation for the byte map were determined at compile time versus run time; I would hope not. Perhaps it is worth pursuing via your service provider, to inquire if the outcome might be a defect.?

Regards, Chuck

As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

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.