Re: Strange problem with an _Rreadk()

[CRPence <CRPbottle@xxxxxxxxx>]

  Hmmm... composed this last night, but forgot to send... I copied 
part of this message into a newer response for the new insight for 
ODP sharing per SHARE() attribute of the member.  Posting anyhow FWiW.

  CHGPF or CHGLF?  And even if the file is created with *MAX1TB; 
i.e. never changed [per my not trusting "has ever been" at face 
value :-)]?

 Since the problem recreates on a client site but is unable to be 
reproduced by\at the sfw provider, very possibly there is something 
specific to the customer system(s); their files [attributes, dbf 
networks], commands, environment, et al.  Without the exception 
details from a spooled joblog, "failing like this" is pretty 
nebulous, such that I can only barely guess.  Neither open nor getky 
cares what access path size the file.mbr has.

  Is it possible the customer had changed any of their command 
parameter defaults for the CHGxF command, to have something other 
than *SAME.  Doing so has often been a source of problems, as well 
as a reason for an issue being seemingly unreproducible?  Or perhaps 
they were forced to specify some other parameter(s) to enable the 
change of ACCPTHSIZ() to be allowed; e.g. LANGID\SRTSEQ?  I suggest 
reviewing for any non-*SAME values in the non-specified parameters 
presented by the requests to:

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

  Compare DSPFD and DSPDBR output for the files on the customer 
system and the /same files/ on the test systems where the problem 
does not reproduce; reviewing for differences beyond just the access 
path size.

Regards, Chuck

James H. H. Lampert wrote:
> This is happening at a customer site, and we can't duplicate it 
> on any of our boxes.
>
> It seems that we have a call to _Rreadk() that works fine if the 
> file is created with ACCPTHSIZ(*MAX4GB), but it crashes the
> program -- only on the customer's box -- if the ACCPTHSIZ is (or
> has ever been) *MAX1TB. Even if it's changed back to *MAX4GB.
>
> (I don't know exactly what exception is being thrown, but I 
> should know soon; the user said he'd email me the joblog.)
>
> And everything works just fine on our V4R4, V4R5, V5R2, and V6R1 
> boxes.
>
> And likewise, our QuestView terminal-based product works just 
> fine on the customer box (it uses the same record-level access 
> entry points used by OPM RPG, but calls them from MI).
>
> Has anybody ever heard of _Rreadk failing like this?