hard to say...
I'll speculate though...
now, after doing all the voodoo, did you push an incremental from each node
you desired to increase the retention of ???
there is the internal table "Expiring.Objects" and I ~think~ that as your
client runs its normal incremental and you see all of those "expiring
blah..." that is putting entries into the "Expiring.Objects" internal table
to assist in the expiration process....
Backups prior to your environment modifications might have placed entries
into that table that are being processed during expiration.
Maybe if you rerun incrementals from all those nodes, it will properly
rebind all the files and cure that problem.
this is a LOT of guess work by me... don't have any logic manuals for TSM
available.
I would start by forcing the clients to connect to the tsm server and
perform fresh incremental processing to get the new management class
characteristics picked up and applied...
just a thought
Dwight E. Cook
Systems Management Integration Professional, Advanced
Integrated Storage Management
TSM Administration
(918) 925-8045
Scott McCambly
<[EMAIL PROTECTED] To: [EMAIL PROTECTED]
AM.NET> cc:
Sent by: "ADSM: Subject: Strange inventory expiration
problem
Dist Stor
Manager"
<[EMAIL PROTECTED]
.EDU>
03/12/2004 01:27
PM
Please respond to
"ADSM: Dist Stor
Manager"
Here's a good one for a Friday afternoon....
We've had a requirement to temporarily suspend expiration of objects on
selected client nodes.
We copied the active policy set for the domain containing these nodes
and set all backup and archive copy group parameters to NOLIMIT, and
activated this new policy set. I have verified that I see these new
values from the client side (q mgmt -detail).
The strange part is that now when we run expiration processing in
verbose mode, as the processing hits the filespaces for these nodes, it
is still reporting statistics of many hundreds of backup objects being
deleted. How is this possible?!? We of course only let expiration
processing run for a minute before canceling it again. A few sample
"query backup -inactive" on one of the nodes that was listed in the log
messages of expiration processing seem to show all the versions there as
expected.
I then tried to turn on tracing to see what files were being deleted,
but the trace messages generated by IMEXP and IMDEL only show the object
ID, and I assume once deleted that you couldn't retrieve the file name
from the database anyway.
Can anyone please explain this behavior, or possibly point me to more
trace flags that might help show what files are being deleted?
Thanks
Scott.
<<inline: graycol.gif>>
<<inline: ecblank.gif>>
<<inline: pic19149.gif>>
