Charles Wilt wrote:
Why can't you just
CPYF FROMFILE(SRCFILE) TOFILE(DSTFILE) FROMRCD(1) FMTOPT(*MAP *DROP)
Paul Nicolay wrote:
Because that requires a lock on the source file... which I can't establish.
I don't think that is correct. Just now I copied our customer master
file, which is basically in continuous use all day by many users, with
the command Charles specified.
Birgitta wrote:
IMHO the only way is to add a column and store the relative
record no of the old file in this additional field
Paul Nicolay wrote:
While I could add such a column to the target table...
it will stay there forever (which I would just like to avoid).
This is why I suggested two passes. The table with the explicit
"source RRN" column would be just the first pass.
Paul Nicolay wrote:
The source file (which has > 100 million records) is
still in use and will be updated continuously.
OK... but then...
Paul Nicolay wrote:
I already had the idea of using a user index to store the mapping,
this would avoid keeping the RRN in sync with the source table
and which I can throw away once finished (ie. this is a temporary
process so there's no issue about reorganizing the source table).
If the "still in use and updated continuously" is a problem, yet it is
also "a temporary process", then... I think you still haven't
described the higher-level situation well enough.
To me, if this is temporary, that implies the source table will stop
being updated at some point. I don't see why you can't simply wait
until that time, and then build the target table using a much more
simple, straightforward, and reliable method.
The only reason I can think of that this wouldn't be feasible is that
there will be some overlap period, where *both* the source and target
tables *must* be actively in use and updated continuously. But then,
if the target table is also being updated continuously, your whole
premise is completely unworkable.
I challenge the fundamental notion that you need to preserve RRN at
all. Some extremely poor decision had to have been made for this to be
a requirement. I think you should explain more about that.
Paul Nicolay wrote:
Sometimes you need to do crazy things and think out
of the box to accomplish great things (or fail ;-)
While that is true, the "sometimes" is probably more accurately
characterized as "once in a great while".
Some overwhelming percentage of the time (maybe 99%, maybe 99.99%) the
"crazy" thing to do is ultimately a bad idea, and the reason no one
has a good solution is that it's really not worth doing.
I am extremely curious to find out more about how your crazy
requirements came about. I am still holding out hope that if you back
up far enough, a much better route will reveal itself.
In other words:
https://xyproblem.info/
John Y.
midrange.com
