Re: Cobol .DAT backup solution



In article <1158644808.505058.260260@xxxxxxxxxxxxxxxxxxxxxxxxxxxx>,
cobol_rasurop <infodynamics_ph@xxxxxxxxx> wrote:

Frank Swarbrick wrote:
Essentially, we do pretty much what one of your examples was. We have
databases (DL/I) and we have sequential maintenance (transaction) files. If
our database was to crash and burn during the day we could restore to
beginning of day and re-apply the maintenance files to recover up to that
point in time. This doesn't allow 24-hour online uptime, exactly, though.

That's more like it...

Aside from having a mirror image (OS-based backup option) data drives.
I prefer OS-based or third party software backups to be my secondary
option, it is because I do not know "exactly" what I have got inside my
data after recovery.

I do not know how "exactly" (quotes original) differs from the usual use
of the term... you have your data, what prevents you from know what they
are?


Creating an application-based backup auditing program is a better gain.

What constitutes 'a better gain' is, in the Business World, quite often a
result of the assumptions used to judge the data. 'That which makes the
person with responsibility for signing the checks which pay for the system
smile' has been said to be the One True Measure of a Well-Functioning
System.

In your case it seems as though this kind of constant backup (restore with
zero transaction loss) is an afterthought to system design; what might
constitute the 'best gain' could be to determine the worst-case scenario
with the current system (complete failure of the most profitable/highest
transaction departments during peak business hours requiring hardware
replacement, reconfiguring and resynchronisation before full restore) and
see how the projected cost of such a failure compares with the cost of
replacing the current system with one that is designed with the security
you now see as desireable.

DD

.