|
Hi Michael,
What gave you the idea for the OPNQRYF approach? That's certainly an
interesting result.
Peter Dow
Dow Software Services, Inc.
909 793-9050 voice
909 522-3214 cellular
909 793-4480 fax
----- Original Message -----
From: <Mlpolutta@aol.com>
Sent: Thursday, November 14, 2002 6:50 AM
Subject: Update on "big file upgrade" approach - long
pgm
OPNQRYF FILE((TESTLIB1/ORIGFILE) (GAPFILE)) +
FORMAT(QTEMP/JOINFILE) JFLD((1/KEY1 +
2/KEY1) (1/KEY2 2/KEY2) (1/KEY3 +
2/KEY3) (1/KEY4 2/KEY4)) +
JDFTVAL(*YES) OPNID(JOINOPEN) +
SEQONLY(*YES 108)
OVRDBF FILE(NEWFILE) SEQONLY(*YES 108)
CPYFRMQRYF FROMOPNID(JOINOPEN) +
TOFILE(TESTLIB2/NEWFILE) MBROPT(*REPLACE)
return
endpgm
I created a "gap" file which is an _empty_ PF containing the key fields and
the "new" fields only. (In other words, just the fields added to the
ORIGFILE format.) Joined on the keys, selecting JDFTVAL(*YES) to get every
record in the original file. Then simply CPYFRMQRYF from the join to an
actual PF in the new format.
While I can't really explain why this is so much faster, or why the parallel
stuff didn't give the return I wanted, I'm thrilled with the result.
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2025 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.