Developing filePro apps for developers

[Brian K. White]

----- Original Message ----- 
From: "Fairlight" <fairlite at fairlite.com>
To: <filepro-list at lists.celestial.com>
Sent: Saturday, June 16, 2007 5:51 AM
Subject: Re: Developing filePro apps for developers


> I also didn't see any mention of it specifically, but I would -hope- that
> your period of quiescence is in effect for the -entire- update procedure,
> not just the restructure work.  If you had processing in one place firing
> off processing in another place and there were interdependencies of
> action between the two and one processing table was updated but another
> was deferred till later in the update stream, then any actions taken in
> the interim could leave the customer with unintended data desyncs.

Thats just a detail among many.
Yes the procedure is a logical lock-out of the possibility of code running 
while the system is in an inconsistent state.
And the system is now defined as the whole set of systems because we do now 
have some things that transact from box to box.

so:
on all boxes, before doing any restructuring on the first or any box, do the 
following in this order:
1) create /etc/nologin. now no new users can log in. use a message that 
warns other root users what is going on.
2) shut down apache and cron, now no new cron jobs or cgi scripts can start. 
edi files may be received by ftp still, but cron is not running so they will 
just sit there harmlessly.
3) do 1 & 2 on all boxes to allow some time for already existing processes 
to die naturally on boxes while you are going around beginning the lockdown 
on the others.
4) back around to the first box, kill off any filepro-related processes or 
processes that might start a filepro process. This just means kill all 
clerks, reports, menus, start-scripts and login shells. I have a script to 
do that easier than it sounds. do this on all boxes.

At this point no filepro processs will start on any box except by deliberate 
interactive root user.
Nor will one of those rsync broadcasts go out by itself, but even if it did 
they don't touch maps or indexes or keys or datas, so, they actually 
shouldn't hurt even if they did.

5) Do your restructuring on all boxes.

6) Then restart the halted services and remove nologin on all boxes.
You don't reactivate any box untill all have been restructured.

It's possible to automate all of that but it will take a lot of care before 
that script or system of cooperating scripts and network services is solid 
enough to risk using for real.

Brian K. White    brian at aljex.com    http://www.myspace.com/KEYofR
+++++[>+++[>+++++>+++++++<<-]<-]>>+.>.+++++.+++++++.-.[>+<---]>++.
filePro  BBx    Linux  SCO  FreeBSD    #callahans  Satriani  Filk!