Not only that, but if I recall correctly the only files that'll get rebound
are the ones that get touched by the client as either a still active file
(along with it's inactives) or a 'just' deleted file, one that was
previously active but as of this incremental has been deleted and becomes
inactive.

I seem to recall a discussion once that files that have been inactive for
awhile won't get touched during the rebinding process because there's no
active file getting scanned and no deleted file to be marked inactive (that
process is already done).  So I *think* files that were deleted more than 1
day ago won't get rebound to the new mgmt class.

I'm not certain of this, if someone can affirm or tell me otherwise that'd
be appreciated...

regards,

Paul

----- Original Message -----
From: "Dwight Cook" <cookde AT US.IBM DOT COM>
To: <ADSM-L AT VM.MARIST DOT EDU>
Sent: Friday, March 12, 2004 3:08 PM
Subject: Re: Strange inventory expiration problem







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
                      <mccambly@ALLSTRE        To:
ADSM-L AT VM.MARIST DOT EDU
                      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.