Re: Write a record at a specific RRN

WRT CPYF: you need COMPRESS(*NO) as well to ensure you maintain RRN's. If
you drop FMTOPT, FROMRCD(1) COMPRESS(*NO) copies blocks of records at a
time, so performance is better.

CPYF FROMFILE(SRCFILE) TOFILE(DSTFILE) FROMRCD(1) FMTOPT(*MAP *DROP)
COMPRESS(*NO)

On Fri, Aug 13, 2021 at 5:28 AM D*B <dieter.bender@xxxxxxxxxxxx> wrote:

<Paul>
Maybe I should provide a bit more background on the reason for this
question
(and the overriding system value) one.

The problem is that we need to change the structure (ie. this can be
anything from extending, adding, dropping, renaming, complex conversions,
... of fields) of a huge (> 100 million records) table while operating in
a
24/7 environment.

Fact is that we even have multiple tables like that (that need to go in
one
time) so the magnitude is even factor x. This means that we can't end all
jobs, change the layout of the tables (this will take many hours), promote
the software and continue to work as it is downtime that should be avoided.

The idea (which is not mine) is therefore to replicate the existing
database
table to a shadow version until everything is in sync (without any impact
on
the source tables), find a downtime spot, move the tables in the
production
environment, promote the software and continue working. This method should
limit the downtime to minutes instead of many hours.

While there are some tools that offers this... they have certain
limitations
so I was looking if I could write a next-gen version of them. The recent
questions are related to one technique I have in mind but there are others
as well (all with pro and contra's).

The goal is also to find a solution that works with all current
capabilities
a database has (unique keys, constraints, identity columns, null values,
...).
</Paul>

First of all, I agree with your scenario of replication before switch over
to minimize downtime. Fastest would be to replicate all data to another
lib,
shutdown, reach synchpoint, rename original lib, rename shadow, restart.
As an additional point of redesign, I would add a complete view layer,
none
of the redeigned tables should be accessed directly by your applications
(maybe some DDS logicals could be needed, (maybe some programms could need
a
change ???)
To fullfill all referential constraints the synch process has to be based
on
journal to have the same sequence of changes for the shadow. It could bes
started from a savepoint, synchronized by journal entries (using
APYJRNCHG),
after this an apply process brings the shadow in synch to the running
production. The apply process of the journal images would have to do the
translation from old to new and it couldn't be one generic process for all
tables (maybe the modules could be generated, or some of these). I don't
see
any needs to preserve the same RRNs, maybe the sequence is important,
beacuse some programms are working FIFO or LIFO or whatever (but even this
would be possible - did you testthe snippet from my last posting?).

D*B


--
This is the RPG programming on IBM i (RPG400-L) mailing list
To post a message email: RPG400-L@xxxxxxxxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: https://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxxxxxxxx
Before posting, please take a moment to review the archives
at https://archive.midrange.com/rpg400-l.

Please contact support@xxxxxxxxxxxxxxxxxxxx for any subscription related
questions.

Help support midrange.com by shopping at amazon.com with our affiliate
link: https://amazon.midrange.com