Sorry then, I (mis)remembered from the old discussion that it was not possible yet to code a dirid on the BACKUP statement in the DMSPARMS file. It is obviously much better to use this official solution.
At the other hand, my SCIF is not zapping VMDBKs, it uses WAKEUP to intercept the responses of .FIND DMSxxx; CP DISPLAY and CP STORE. And before sending the STORE, it verifies the altered storage to be something expected. 2009/6/23 Rob van der Heij <[email protected]>: > On Tue, Jun 23, 2009 at 12:17 PM, Kris Buelens<[email protected]> wrote: >> To avoid the problem of the target for the backup being RELEASEd (due >> to restart of the backup SFS), you can use the SFSDOT commands >> (explained in sample document on MAINT 193 or 3B2): > > So why would you? What would be the reason to use an accessed > directory over a the apparently architectured solution to specify the > SFS directory in the control file? Is there a performance benefit or > other? > > Would it not be wise to use the (audited and controlled) SFS > administrator commands rather than "cheat" by exploiting the CP > privilege class of another server? Plus the issues we raised about > tools that zap VMDBKs. > I'm sure VM Development had a reason not to enable that interface by > default (or even with a sensible parameter in the DMSPARMS). > > PS Simply the fact that one spent many hours on creating some local > tooling does not count as a reason to use it. After all, exploiting > locally written tools without a good reason is typically more > expensive than just throwing them away ;-) > http://despair.com/perseverance.html > > Rob > -- Kris Buelens, IBM Belgium, VM customer support
