In the event this has not been suggested here's something that
might help:

Issue a file equation containing all the attributes of your KSAM/XL
file except with the new larger EOF, for example:

:file newfoo,new;ksamxl;key=(b,1,10);disc=5000;rec=-80,16,f,ascii

Then FCOPY to the new file backreferencing this file equation:

:fcopy from=foo;to=*newfoo

KSAM/XL files are attached to XM (transaction manager) however they are
not initially so using this method avoids the XM overhead for the initial load.
It's a bit like Image AUTODEFER and with the same consequence if you do
not retain the data to reload the file in the event of a crash.

This particular problem may not be due to either FCOPY or 6.5 but
rather to the construction of the KSAM/XL file itself.

- Is the file larger now than when last copied in an acceptable time? It would
need to be substantially larger to account for the 5 min. to 3 hour slowdown!

- Does the file allow duplicates? If so that could account for some but again
it would need to be a substantial number of duplicates. Using random duplicate
or 'RDUP' could ease things a bit provided applications would allow that.

Either way, if this rather profound slowdown persists I'd recommend reporting it
to HP Support.

I have not found record of nor been told of any problems in FCOPY or KSAM/XL
on 6.5 so reporting this and getting help will benefit everyone even if it turns out
to be something simple!

I hope this helps some.

Bill Cadier,
HP/CSY