Re: Strange problem with an _Rreadk()

[CRPence <CRPbottle@xxxxxxxxx>]

  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?"