Re: Write a record at a specific RRN

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.