Re: Update on "big file upgrade" approach - long

Hi Michael,

That's pretty good -- using SQL to back into OPNQRYF.  But since you
apparently wrote a utility to create the "gap" file, why not have it
generate the SQL INSERT INTO in a source member and use RUNSQLSTM? [Sorry
for the digression, but it's always fascinating to try and understand
someone else's thought processes. <grin>]

Of course, that brings up the question of performance again...

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 10:43 AM
Subject: Re: Update on "big file upgrade" approach - long


> Peter,
>
> If I were to try to do this with SQL it would look like this:
>
> insert into TESTLIB2/NEWFILE (select a.*, '' newalpha1, 0 new alpha 2, ...
> from TESTLIB1/ORIGFILE a)
>
> but I'd have to list ALL of the new fields with the default value
> (represented by the ellipsis above).  I tried to think of a way to do this
> with a "structure" for the new fields, rather than having to list them
> individually.  I can now write a quick utility to build the PF for the new
> fields only (using FFD information from both files), create the gap file
in
> QTEMP, and I'm off to the races!
>
> There may be a way to do that via SQL also, but I couldn't locate it!  If
> there is an SQL way that can use a structure, I'd love to know what it is.
> Perhaps the same subquery with 2 select * statements, one for the original
> file and one for the "gap" file, but I was able to generate this OPNQRYF
> version very quickly.