In <1994Feb1.214245.22751 AT draper DOT com>, SPGJAF%UCBCMSA.bitnet AT 
yalevm.ycc.yale DOT edu
 (Joseph A. Faracchio {510} 642-7638 {w}) writes:
>OK OK OK !
>
>Dean:  I don't want to gang up on you but ...
>
>Richard, Paul et al are right.  Virus protection is not the point.
>
>Pick  ANY DUMP REASON a user might WANT (or badly need) to restore their
>workstation to a certain point in time , AFTER the fact.
>
>AND as many users I have each one can come up with a (unique) dump reason!! :-)
>
>And further more I told the instructor in the ADSM class that he was missing
>the point when he talked about critical/mission data.
>
>IF my user has to send x hours reinstalling all his software because of a
>hard disk crash then that data is 'mission critical' because that user has
>better things to do!     (Provided I can deliver x/n restore time instead
>where n = 2 or much greater!
>                                    cheers .. joe.f.
     I replied yesterday to this to ets AT maine.maine DOT edu.  I thought it
would go to the discussion list and if it did, I apologize for
repeating myself.  But since I saw no replies, I think it didn't.

    As ADSM is now constructed, I doubt there will ever be a
completely satisfactory point-in-time feature.  But you can simulate
it today.  Setup another server at another tcp port number.  Set the
versions retained to a low number.  When a user wants a point in time,
he can change his dsm.opt or ADSM preferences (Mac) to point to the
other server, and take a backup to it.  To save space the admin can
direct it to tape immediately.  The line command clients can be
started with a -tcpport=nnnn parameter so changing the dsm.opt isn't
always necessary, and the mac system 7 ADSM has a drag and start
feature for alternate preferences files.

    Sure this takes more mainframe disks and tapes but it provides the
service.

Bill Colwell
C. S. Draper Lab
Email: BColwell AT draper DOT com
Voice: 617-258-1550