Re: Handling null-capable fields with program-described file--reading externally described using program defined layout

Responses in-line.

Peter Dow (ML) wrote:
> Um, my service provider? Would that be IBM?

Probably. Defect support under an existing contract, that is dependent on specific [existing] maintenance arrangements. For paid non-defect or other by-contract support, that is available from IBM regardless of maintenance.

FWiW: I [was taught to] say "Service Provider" because the poster of a message may not have any direct access to the actual service provider -- meaning: they may need to go to their internal support who knows how to open a problem with _the service provider_. The contracted service provider may not be IBM. Of course a third party support would need to redirect to IBM to resolve concerns with the IBM software, by opening a PMR [Problem Management Record] with IBM Support. To say to someone "Open a PMR with IBM" is mostly worthless to anyone but the person in charge of the support contract with the service provider -- and for reference to IBM nomenclature "PMR", still confusing, unless the support contract is actually with IBM.

> If I understand what you're saying, it's the RPG compiler that is
> not passing the ALWNULL() request to the LIC database code when
> it's opening a program-described file. Barbara, if you're listening,
> is this what's going on?

Effectively. More specifically, if interested....

FWiW: The RPG communicates its request with the OS Database which passes the request to the LIC Database.
FWiW: I believe that in the given scenario, the RPG run-time [be it a compiled option or run-time] is not requesting of the DB2 for i5/OS RLA [Row Level Access] Open method, to effect /treat NULL values as Default/. For lack of that request by the RPG open, the DB2 for i5/OS RLA Open does not generate a null byte map into which the LIC DB can map the NULL values.

I infer that since both the DCLF ALWNULL(*YES) and DSPPFM use that same feature of the DB2 [to treat NULL as default], yet neither of those functions have the same problem. And since apparently an externally described file referenced by an RPG program declared as External does not have the same problem. Thus it seems intuitive to place the blame on the internal definition of the file by the RPG program for preventing the open from being performed with the option to /treat NULL values as Defaults/. I did not research for any specific documentation, but the help text seems a bit cloudy given the failing scenario.

Regards, Chuck