Well -- yes and no. I want to know why I can't do a 'cancel process n force=yes' (or 'immediate') and get the process to stop NOW, not after 10 hours of trying to write a 1 GB file to a bad tape. If TSM can clean up after a shutdown while the copy is in process, it can bloody well clean up after a force termination of the process.
I have done the 'halt' on the TSM server before to get around not being able to kill a process immediately. I'll do it again, if the circumstances require it, unless I get a cleaner way of killing a process NOW and not at some indefinite period in the future. Tom Kauffman NIBCO, Inc -----Original Message----- From: Stapleton, Mark [mailto:[EMAIL PROTECTED] Sent: Thursday, March 13, 2003 2:04 PM To: [EMAIL PROTECTED] Subject: Re: Canceling a Reclamation FAST >Steve Harris wrote: >>updating the drive mid transaction to online=no does it for me. From: Paul Ripke [mailto:[EMAIL PROTECTED] >Sneaky! Since TSM *has* to be able to cope with this scenario >gracefully, it does surprise me somewhat that there isn't a >"cleaner" way of doing this - something like "cancel process >123 immediate=y". As I've said before, there's a good reason why many processes can't stop on a dime. Example: You're running space reclamation. The server is finished copying a 1GB file from one tape volume to another. The pointer in the TSM database to the old copy gets updated, but you *stop* the process before the pointer for the new copy gets written. Oops. There's a reason for rollback, and for finishing a process. Sometimes you've got wait; that's the price you pay for db integrity. -- Mark Stapleton ([EMAIL PROTECTED])
