Re: Strange problem with an _Rreadk()

James H. H. Lampert wrote:

I just got the joblog this morning.

They're on V5R4M0.

And I'm onto something: I saw two "open options ignored" messages
regarding the file, both of them involving shared open data
paths.

The application opens the file twice, and doesn't use shared
ODPs.

I changed a copy of the file on our V4 box to SHARE(*YES), and
suddenly I could duplicate the problem freely.

Now that I know what the problem is, and given that this is an application that opens user-specified files, what do I do about
it?

Implement as probable circumvention, OVRDBF FileName TOFILE(*FILE) SHARE(*NO) OVRSCOPE(*CALLLVL). I do not know of or if there is an open option via fopen() that can request SHARE(*NO), but there is support in the common data management. Such a specification would ensure that only explicit overrides to SHARE(*YES) could introduce the negative impact of sharing, for code that requires no sharing. An OVRDBF SHARE(*NO) SECURE(*YES) is not very desirable, but could be a heavy-handed method to ensure the SHARE(*NO) is enforced by\for the opener.

The default for members is SHARE(*NO), such that SHARE(*YES) is an exception, for which OVRDBF SHARE(*YES) is expected to activate aside from file.mbr which one would knowingly want the sharing enabled by default and so explicitly asking for SHARE(*YES). So...

Investigate on the client system, the command defaults for CRTPF, CRTLF, ADDPFM, and ADDLFM to see if they default to SHARE(*YES) versus the shipped default of SHARE(*NO). If the sfw creates these "user-specified files" and\or adds members to those files, that code could explicitly specify the SHARE() parameter; of course run-time remains an issue for any changes or overrides, and thus back to the override as circumvention\preventive. Note: the SHARE() parameter on the CRTxF applies only to the specified MBR() on that invocation; i.e. there is no SHARE(*FILE) capability on ADDxFM to inherit the SHARE() setting established in the database *FILE, because no such attribute is stored at the file level. I suggest also to review the command defaults of the CHGxF commands for any non-*SAME values for the non-specified parameters presented by the requests to [CHG* commands should effectively *never* have their defaults changed from *SAME]:

?CHGPF FILE(QTEMP/"NotAFile") SYSTEM(*LCL) SRCFILE(*NONE)
?CHGLF FILE(QTEMP/"NotAFile") SYSTEM(*LCL) FRCRBDAP(*NO)

Regards, Chuck