Re: How to know a program was compiled with ALWNULL(*YES)

On 01-Apr-2015 15:25 -0500, Charles Wilt wrote:

Saw the subject question on stack overflow..
<http://stackoverflow.com/q/29399592/2933177?sem=2 >

I don't see that information returned in the Retrieve Module
Information (QBNRMODI) API; which would be the logical place for it.

I suspect it's not available anywhere. But thought I'd throw this out
here to the experts.. cough Barb cough. :)

I seem to recall a past discussion concluding the information was not available from a retrieve feature for the program or binder details. Presumably the concern is ALWNULL(*USRCTL); i.e. there is no special value of *YES.? If the specification was made in an H-spec, and the debug view exists, then as I recall the H-spec is visible; the H-spec is better anyway, because then there is no forgetting to specify the compile option on the CRTRPGMOD or CRTBNDRPG command.

Not sure why knowing really matters much; the program can be compiled with the desired setting. If the issue is that the setting seems not to hold [after a re-compile], per receipt of errors caused by Null values despite coding an Allowance for NULL values, then just investigate that issue. For example, if the program uses Program Described instead of the External Record Format definition, then IIRC the NULL processing specifications are ignored by the RPG, and an alternate solution is required.

One probably simple way to test if the program was *not* compiled to allow nulls for reading a file, is to override the file that the program uses, to an alternate copy of the file that has NULL values in a row that is a row [best to be the first row] the program will read. If the error msg CPF5035 rc19 results [as a precursor to the error msg CPF5029 that is diagnosed by a RNX1299], then the program was not compiled with either of AlwNull(*InputOnly).

However that attribute as established on the compile would be made available in the objects they impact; i.e. manifest in the UFCB that the RPG generates for the open, and in the ODP effected for the Open, as both would necessarily reflect the Allow Null (ALWNULL) option setting. Given the lack of doc on those and how finding them is not entirely conspicuous to everyone, the easiest thing to do might be to open the file.member with sharing, having used a pared-down version of the program to declare the file as UsrOpn and perform only the open, after which the program about which the attribute-setting should be determined should attempt to perform the second\shared open. If the allow-NULL values processing option from the first open is incompatible with the allow-NULL values processing option established for the second open, then an error msg CPF417A "Handling null capable fields is not valid for open..." will be the effect. In this manner, the value of that setting can be safely inferred. Just ensure the second open is actually a shared open; the override scoping, perhaps per ACTGRP specifications, or something else might have prevented the sharing.