RE: OPNQRYF on a SQL created file

Hi Chuck,

Both the old and new version of the PF/Table are not keyed.
Here's the Override and OpnQryF that was being used.

OVRDBF FILE(SUMMARYP) SHARE(*YES)
OPNQRYF FILE((SUMMARYP)) QRYSLT('SUMTYP *EQ "4"') +
KEYFLD((PRDLVL) (SVCLVL) (BSLVL))

The quick fix, for better or worse (better for getting the fix done now, and future understanding; worse for lack of knowing what the specific issue was), we created a logical to do what the OPNQRYF was doing and changed the program to use the logical.

Thanks again for all the input.

-Kurt

-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of CRPence
Sent: Tuesday, April 20, 2010 2:14 PM
To: midrange-l@xxxxxxxxxxxx
Subject: Re: OPNQRYF on a SQL created file

Kurt Anderson wrote:

<<SNIP>> The program we're having an issue with is being set
aside while we implement everything else for a file change. I'll
take a look at it again in a bit and see what's going on. The
only thing we noticed is that the OPNQRYF didn't seem to be doing
its job, which was to provide sorting. Again, some old program
where nothing really changed, so I was trying to identify what
did change (how the file was created, and size of amount fields)
so I was doing a quick grasp at straws.

The default for OPNQRYF is KEYFLD(*NONE), but for a keyed PF the
Open Query File request is often coded with KEYFLD(*FILE). The DDS
defined database physical file likely had K-specs to define keys.
Unless the CREATE TABLE as replacement included a CONSTRAINT of type
PRIMARY or UNIQUE [or effected similarly by ADDPFCST or ALTER TABLE
ADD CONSTRAINT], the new file will not have any key fields. In that
case the read activity from the shared ODP will be via arrival
sequence access path order [given a *HEX sort sequence]; i.e.
unsorted records from the shared ODP. Likely, the OPNQRYF will need
to change, to code an appropriate KEYFLD() specification that would
match what the original DDS-PF had coded.

Regards, Chuck