File restructure bastardization

[John Esak]

>
> Hopefully I took all necessary precautions to minimize any risks.  As
> stated earlier, this is the first time I felt the need to handle the
> restructure in this way.  This client runs 24X7X365 excepting the 2.5
> hours per night that everyone is required to log off during their system
> backup.  Thank you again for all the advice & suggestions.
>
> Don Coleman

Boy, I wish I had your "excepting the 2.5 hours per night"!!!  We run truly
24/7/365 and we are constantly struggling with how and when to re-define
maps. It is a very big problem. So far, one I have not come up with any good
answer for yet.  It would be great if all the brain-trusts here could come
up with something do-able in this regard.  On the other hand, I have
developed a processing control system that allows me to insert new
processing directly into the running systems *without* losing even one
keystroke from the many people who are running the program(s) from clerk at
that very second. It took quite a while to implement, but had I not done it
over 3 years ago, we would have had nearly 200+ times that we would have had
to bring people down for enhancements, fixes, and new features. This system
is far to involved to just lay out in a quick message here, so I'm
scheduling it for one of the Addendum CD's, but I sure would like a good
solution to the re-defining maps on files when there is NO time, not even
one minute between times the file is accessed/updated. A kicker, but not
really too important is that the files are physically large in number of
records and size of each record. Any restructuring takes a bit of time even
on our super-fast servers.

(Incidentally, I have been down lots of paths on this already, mostly
involving running in a transactional mode during the restructure... then
posting all the transactions to the modified file. Basically, the systems we
run are not very conducive sort of thing.  Just too damn problematic.)

John