Re: Strange problem with an _Rreadk()

Effectively the same reasoning, I would assume, that someone would change the command default of CHGxF to 'ACCPTHSIZ(*MAX1TB)' or even blindly just issuing a CHGxF ACCPTHSIZ(*MAX1TB) against all *MAX4GB access paths with their "understanding" that performing that change will somehow improve the system for performance, throughput, or whatever. In the case of defaults for CHGPF or CHGLF, thinking that rather than by explicit change, to effect the change only when some /other/ change was being requested. Unfortunately, the real problem lies in just how little one actually knows and understands. :-)

After /correcting/ their command default(s), they might also want to query the output file from a request to DSPFD *ALLUSR/*ALL *MBR FILEATR(*PF *LF) OUTPUT(*OUTFILE) [best to pre-create the outfile, then change it to have SIZE(*NOMAX)] to evaluate which of those files having at least one member with SHARE(*YES) [i.e. WHERE MBRSHR='Y'] should possibly revert to SHARE(*NO), in order to reestablish /Share=No/ as the default, except for those members referenced by applications which benefit from ODP sharing. Even then, possibly such applications should only do so by OVRDBF to effect SHARE(*YES), versus establishing the sharing as the default for open of the member itself.

As alluded in my prior message(s)... Since apparently the failing code has a requirement to not share, in order to function properly, then even after "correction" to the file members to again have SHARE(*NO), an override with SHARE(*YES) can still break the file I\O processing. I would suggest investigating if there is some open feedback which indicates the open was a shared open versus a full open, and change the code to stop processing after an open completed with sharing; e.g. ¿¿ perhaps if file_open_count > 1 ??

Regards, Chuck

James H. H. Lampert wrote:

CRPence wrote:

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]

I just got the word back from the customer: yes, indeed, for reasons I can't possibly imagine, they changed the default on
CHGPF to SHARE(*YES).

"We are Pakleds. Our ship is the Mondor. It is broken. Can you
make it go?"