ADSM-L

Re: Restore improvements (was "none")

1995-10-23 13:33:15
Subject: Re: Restore improvements (was "none")
From: Andy Raibeck <raibeck AT CONNIX DOT COM>
Date: Mon, 23 Oct 1995 17:33:15 +0000
Bill Colwell writes:

...
> Messages are not enough if one is left with lots of manual work to
> do to complete the restore.  Please design with BIG servers in mind!
>
> Consider a restore of 100k files which is 99.8% effective.  It leaves
> 200 files to be fixed up in some way.  I suggest the following -
>
> 1). Add an option '-FailuresFile=<filespec>'.  Write the failures there
> in a syntax which can redrive the restore process.

This is a good idea. If IBM opts to do something like this, the syntax
should take into account which versions were originally selected for
restore. In other words, don't assume that it was just the most recent
version.

> 2). After the first restore phase, redrive the restore using the
failuresfile
> as input.
> 3). Files which still fail should be stored in a 2nd failuresfile with a
name
> derived from the first. At this point the restore stops and the user must
> take over.  If all that is needed is to kick a user or 2 off the server,
then
> the administrator can again redrive the failures with
> 'dsmc -retryfile=<filespec>'.
>
> Editorial comment:  I have been an MVS systems programmer for 20+ years.
I
> seen the growing pains of MVS and also HSM which I have administered for
15
> years.  Now I am watching the growing pains of ADSM.  The ADSM developers
> could make ADSM support large systems better and sooner if they had a
> conference with their HSM neighbors about the steps they have been thru
> to support large systems.

The HSM neighbors can also take a cue from ADSM. In many respects, ADSM
is what HSM *should* have been. (Of course, I'm sure if IBM were to re-
write HSM from the ground up, it would look a lot more like ADSM.)


Andy Raibeck
Connecticut Mutual
203-987-3521
<Prev in Thread] Current Thread [Next in Thread>