× 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.



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

As an Amazon Associate we earn from qualifying purchases.

This thread ...

Replies:

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

This mailing list archive is Copyright 1997-2024 by midrange.com 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].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.