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