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



Carel,

thanks for the reply.  see inline

>Rick,

>First of all, you do not need to map the fields to join those files
>Secondly, doing it this way you are not capable of using fields from the
>SELCOPY file, as they are not in the defined FORMAT.

I want the output to look just like the format for FILE1.  I don't need the
data from the other file (COPYSEL) - I want my RPG program to think that it
is reading FILE1 only.

i'm only using COPYSEL to select the proper records from FILE1.  I'm using
mapping because both files have fields named the same and the opnqryf
doesn't know from which file's fields to get the data (to output to the
FORMAT file).

>In OPNQRYF the first file listed is the file from which joining starts and
>should be used in a programme.

This is the way I would normally do it.  But I wanted to see if the query
would run faster by switching the order of the file names.  I was hoping
that if I specified "OPNID()" on the opnqryf, that this would be the name
it used and all shared overrides would remain in effect and my program
would read the proper stuff.

>This can be overridden by using a dummy PF
>on the FORMAT keyword. In this dummy PF you list all the fields
>required  within the query/programme.
>As you are not allowed to create new objects you cannot use that dummy PF
>on that keyword.

>And without permission to change the programme you have to use the first
>version of your query; otherwise you have to define SELCOPY in the
F-specs.

this is what I'm trying to avoid.  I wrote the program and can change it -
I want the program to think it's just reading the original file.  I don't
want to have to create a dummy file.

>I assume you all know this, but nevertheless.

all but the "primary file" rule.  I thought I could get away with it using
opnid.

>You may try to look at the OPTIMIZE keyword, but with that many records it
>may not be helpfull.

>If possible, create the dummy PF.

I will instead try to convince my keepers to let me build a logical file
and then life will be good.

>Regards,
>Carel Teijgeler.

Thanks for the hand, Carel.

Rick

>OVRDBF    FILE(FILE1) TOFILE(MYLIB/FILE1) SHARE(*YES)
>OVRDBF     FILE(SELCOPY) TOFILE(QTEMP/SELCOPY) SHARE(*YES)
>
>OPNQRYF    FILE((MYLIB/FILE1) (QTEMP/SELCOPY)) +
>              FORMAT(MYLIB/FILE1 *ONLY) +
>              KEYFLD((*MAPFLD/F1FLD1) (*MAPFLD/F1FLD2)) +
>              JFLD((*MAPFLD/F1FLD1 *MAPFLD/F2FLD1 *EQ)  +
>                   (*MAPFLD/F1FLD2 *MAPFLD/F2FLD2 *EQ)) +
>              MAPFLD((F1FLD1    'FILE1/FLD1    ')  +
>                     (F1FLD2    'FILE1/FLD2    ')  +
>                     (F2FLD1    'SELCOPY/FLD1  ')  +
>                     (F2FLD2    'SELCOPY/FLD2  '))  +
>              OPNID(FILE1)



As an Amazon Associate we earn from qualifying purchases.

This thread ...


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.