×
The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.
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?
midrange.com
