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:


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?

This thread ...

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2019 by and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].