Re: Cobol .DAT backup solution
- From: "Richard" <riplin@xxxxxxxxxxxx>
- Date: 14 Sep 2006 12:01:32 -0700
William M. Klein wrote:
A) have a separate "backup" job that runs when you want it to (say once a day)
This program should LOCK the file so that no one else can update it (but could -
possibly - read it).
But it cannot obtain an exclusive (file) lock if any other process has
the file open in shared mode. It may be that the running programs don't
close the file frequently enough to ever let an exclusive lock mode
open the file.
It is necessary to have a global 'update flag' - a file that contains
switches that every program must check before doing anything that would
lead to a file update. To be safe it must also set its own switch in
the file before it starts an update and sets it off again after
completing. The backup program must wait until all the switches are off
to ensure that no more change to the file will occur.
With a reasonable system I would use a file with a control record that
must be checked before any update can be done. Each process would have
its own record that it would lock before checking the switch until it
completed updating or quit because the backup switch was on.
If a process crashed or otherwise disappeared I would expect the OS to
clear the lock, but my experience is that Windows won't do this
This does require a system that is designed from the start to cater for
in flight backups, it is difficult to re-engineer to add it afterwards.
Same with avoiding deadlocks. A few simple rules and you will never
get a deadlock, no rules and it is a monster to add avoidance later.
- Prev by Date: Re: Cobol .DAT backup solution
- Next by Date: Re: OT - in serach of Hardware recommendation
- Previous by thread: Re: Cobol .DAT backup solution
- Next by thread: Re: Cobol .DAT backup solution