Re: OPNQRYF on a SQL created file

[CRPence <CRPbottle@xxxxxxxxx>]

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