ADSM-L

Re: Canceling a Reclamation FAST

2003-03-13 15:37:14
Subject: Re: Canceling a Reclamation FAST
From: "Kauffman, Tom" <KauffmanT AT NIBCO DOT COM>
To: ADSM-L AT VM.MARIST DOT EDU
Date: Thu, 13 Mar 2003 15:04:03 -0500
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:stapleto AT BERBEE DOT COM]
Sent: Thursday, March 13, 2003 2:04 PM
To: ADSM-L AT VM.MARIST DOT EDU
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:stixpjr AT BIGPOND.NET DOT AU]
>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 (mark.stapleton AT berbee DOT com)