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