Sorry my mistake.  In all cases I was increasing the file flimit from 120,000 to
210,000. Sorry I was typing the information from my notes.   Each test was done
from the same file restored from tape.  You may think they are the same, I
personally have found a big difference in time on how long each one worked.

Abraham Z.

"Emerson, Tom # El Monte" wrote:

> to 'paraphrase in english' your solutions, it seems like 2, 3, & 4 are the
> same:
>
> 2: copy the data to a temporary location using COPY
>    empty the original KSAM file
>    increase the flimit of the "empty" ksam file
>    FCOPY the data back
>
> 3: copy the data to a temp location, using FCOPY & ;NOUSERLABLES
>    empty the original KSAM file
>    increase the size of the "empty" ksam file
>    FCOPY the data back
>
> 4: copy the data to a temp location using COPY
>    physically REBUILD the KSAM file (with the new limit)
>    FCOPY the data back
>
> The only actual difference I see [which I suspect is a typo] is that for
> solution #4, the limit specified was 210,000 records, not 120,000 records.
> OTOH, having a larger flimit initially might make for a more efficient
> loading of records during the final FCOPY.  Also, were all three tests done
> by restoring the "exact same" starting KSAM file, or was this a series of
> tests performed one after another?  The reason I ask, which might not seem
> obvious at first, is because doing these tests in the order specified would
> "taint" the data -- here's how:
>
> test 2: initial COPY copies the records "as is" in the source file (i.e.,
> MR/nobuf type copy).  if the "chronological" order of records in the file is
> quite different than the "key" order, then it is quite likely there is
> significant internal fragmentation, so putting back values would take a
> significant amount of time.  In addition, "deleted" records would have been
> copied into the temporary file, but discarded during the FCOPY process
> (dunno -- this last is a bit of a stretch)
>
> test 3: the initial FCOPY would read the file in KEY order, and if done
> shortly after the previous test, depending on record sizes & system load, a
> significant portion of the file (or key area(s)) might still be "in memory".
> Also, unless the "nouserlables" keyword overrides this, only 'active'
> records would be copied, thus the 10 second time doesn't sound farfetched...
> Now, when copying BACK to the KSAM file, the records (which are only the
> active ones) are being copied back in not only in "key" order, but the
> "chronological" order would match as well, hence the 1-hour time instead of
> 3.
>
> test 4: the initial COPY would again copy "as is", but because of test 3, we
> now know that the file is in chronological AND key order AND does not
> contain "deleted" records.  Building a target KSAM file, from scratch, and
> twice again larger than needed would support a 20-minute reload time
>
> Just some thoughts & observations...
>
> Tom
>
> > -----Original Message-----
> > From: Ziggy [mailto:[log in to unmask]]
> > Here is the results of my FCOPY
> > problems/question:
> > I  did find a acceptable, solution #4.
> >
> > -----------------------------------
> > Solution 2:  my second try
> > :COPY PRHIST,PRHISTB    (About 5 seconds)
> > :FILE PRHIST,OLD;SAVE
> > :PURGE *PRHIST                  (Under 5 seconds)
> > :RESET !PRHIST
> > :MPEX
> > %ALTFILE PRHIST;FLIMIT=120000  (About 5 seconds)
> > %EXIT
> > :FCOPY FROM=PRHISTB;TO=PRHIST   (Just over 3 hours)
> > -----------------------------------
> > Solution 3   from HP response  I think her name was Susan.
> > Sorry if this is not
> > the
> >                                                  correct person.
> > BUILD PRHISTB;REC=-274,,F,ASCII;DISC=130000  (Under 2 seconds)
> > FCOPY FROM=PRHIST;to=PRHISTB;NOUSERLABLES (about 10 seconds)
> > :FILE PRHIST,OLD;SAVE
> > :PURGE *PRHIST                  (Under 5 seconds)
> > :RESET !PRHIST
> > :MPEX
> > %ALTFILE PRHIST;FLIMIT=120000  (About 5 seconds)
> > %EXIT
> > :FCOPY FROM=PRHISTB;TO=PRHIST   (Just under 1 hour)
> > -----------------------------------
> > Solution 4   from Bill Cadier
> > :COPY PRHIST,PRHISTB    (About 5 seconds)
> > :PURGE PRHIST                  (Under 1 seconds)
> > :FILE RHIST,NEW;KSAMXL;KEY=(key info ....); &
> > :   REC=-274,,F,ASCII;DISC=210000
> > :fcopy from=PRHISTB;to=*PRHIST     (Just under 20 minutes
> > -----------------------------------
> >
> >
> > Abraham Zwygart
> >