At 16:15 24.11.1997 -0500, you wrote:
>Last weekend, we ran a job that increased the size of a NM KSAM file. It
>took 20 hours to run on a 996. I'm sure there were other jobs running at
>the same time, but it seems rather lengthly to me!
...
>Anyone got any ideas on how to shorten the length of time it takes to run
>this job? I thought I read somewhere that you can copy the original file to
>a flat file, build the new file in the temp domain, then copy the original
>records back into it at a substantial gain in speed. I also heard it has
>something to do with the transaction manager only attaching itself to files
>in the permanent domain. Is this true? Or is the real problem in the number
>of keys and records in the file?
...

Pat,

it might make a difference whether you do

  :BUILD newfile;KSAMXL;DISC=...;REC=...;KEY=...
  :FCOPY FROM=oldfile;to=newfile

or else (suspected to be faster and more convenient)

  :FILE newfile;DISC=...
  :FCOPY FROM=oldfile;to=(*newfile);NEW

as I also vaguely recall that it makes a difference whether the file
does exist or is being created in the NEW domain (not TEMP if I recall
correctly). Notice the () in the TO option which creates a KSAM file,
NM if a single argument, CM if a pair or filenames given).

It might even make a difference if you add ;KEY=0 to the FCOPY options
to force FCOPY not to traverse the primary key but go sequential instead.

Last not least, your NM KSAM file shows quite a number of key which do
allow for DUPlicates. I believe this is an area where the CM KSAM has
better algorithms and might sometimes outperform NM KSAM. So you might
want to also consider that option (in case XM protection for the file
is less important than high performance).

Lars (as usual only speaking for lappel, not for grc.hp.com)