Since you're in MPEX anyway, why not firts purge or rename (depending on
your disc space and your faith in your tape :-) the database? I'd try
renaming or purging just the root file first since this will fail if
anything is open. If renaming or purging the root fails then stop the job
and kick the users out! If it succeeds, then you can purge or rename the
rest of the base and then proceed with the restore.

> -----Original Message-----
> From: Leonard S. Berkowitz [SMTP:[log in to unmask]]
> Sent: Thursday, June 22, 2000 7:53 AM
> To:   [log in to unmask]
> Subject:      Looking to bullet-proof a data base restore
>
> Yesterday, in trying to restore a data base to a development machine,
> three
> datasets could not be restored because they were being accessed. The
> restore job
> checks at the outset to make sure that the data base is quiet (MPEX: LISTF
> db,ACCESS), but apparently some user or job opened the data base after
> RoadRunner was already executing (this restore job takes 3 hours or so).
>
> Can someone suggest a strategy to keep people out, other than waiting
> until the
> nightly window? If I change the file-access matrix for the group where the
> data
> base resides, will MANAGER.SYS (normal logon for the restore job) or a
> user with
> AM, OP still be able to restore the data base? I assume so, but I need
> confirmation of this approach or the suggestion of an alternate strategy.
>
> Thanks.
> ===================
> Leonard S. Berkowitz
> Perot Health Care Systems
> (Harvard Pilgrim Health Care account)
> voice: 617-509-1212
> fax:   617-509-3737
> pager: 781-226-2431