I think another handy addition to either mov data or reclamation would
be to move all the active files to a set of tapes, separate from the
inactive files.  It that was done every so often it would reduce the
number of tapes needed to restore a node.  I've had some people try to
get me to schedule full backups to accomplish this, but I've been able
to refuse so far.

Anyone else agree?

> -----Original Message-----
> From: Bruce Elrick [SMTP:belrick AT HOME DOT COM]
> Sent: Thursday, July 16, 1998 7:14 PM
> To:   ADSM-L AT VM.MARIST DOT EDU
> Subject:      Re: Useful 'move data' options
>
> I hope you didn't think I had any say over the matter!  Other than to
> get people on ADSM-L to do "me too"'s to the point that maybe
> development would consider it.
>
> An open request to Cyndie Behrens...could this be added to the
> official
> list of requested features?
>
> Could someone intimate with the internals of ADSM comment of the
> feasability of my suggestion?
>
> Cheers...
> Bruce
>
> Steffan Rhoads wrote:
> >
> > After some thinking and subsequently meeting a new customer with a
> large ADSM
> > installation (2 sites, 2 UNIX ADSM servers each with middlin DLT
> libraries, @40
> > servers/clients each site) and seeing the mess they have these
> options would be
> > LIFESAVERS!  Were going to have to create all new policy domains,
> storage pools
> > and schedules: you can imagine the processing time that's going to
> be spent and
> > how usefull these additional MOVE DATA options would be.
> >
> > How soon?
> >
> > Bruce Elrick wrote:
> >
> > > Would anyone find the following options to the 'move data' command
> > > useful?
> > >
> > > type
> > >    all - all data on volume, default
> > >    backup - backup data
> > >    archive - archive data
> > >    spacemanaged - space managed data
> > >    - allow pairs of the above three types
> > >
> > > node
> > >    - specify a list of nodes whose data is to be moved
> > >
> > > filespace
> > >    - specify a list of filespaces whose data is to be moved - may
> > > require
> > >    the node option specified
> > >
> > > Since migration from sequential storage pools to sequential
> storage
> > > pools
> > > already moves collocation clusters, the implementation of the
> latter two
> > >
> > > options should be trivial.  The implementation of the first option
> might
> > > be
> > > more difficult but would be immensely valuable.  I've seen a
> number of
> > > situations where backup, archive, and space managed data are mixed
> in
> > > a storage pool (bad idea from a data integrity point of view) and
> there
> > > is
> > > currently no way to separate the data.
> > >
> > > Anyone agree on this?
> > >
> > > Cheers...
> > > Bruce
> >
> > --
> > Steffan Rhoads
> > Lead Technical Consultant
> > Think Enterprise Solutions
> > 10 Holland
> > Irvine, California  92618-2504
> > srhoads AT westernmicro DOT com