Keith,

I'm not sure what you mean by 'current nodes', but if they
backed up before you last changed management classes, and if there
are files that have never changed, then they are still in the active set
and will still have the surprising mgmtclass.

I am just finishing up a ppt for managers to try once again to
explain tsm and backup policy.  This exercise reminded me that
there is an important policy built in and there is nothing for
us to specify about it and therefore can be invisible, namely
that the active set is not managed.  I know it is invisible to
my managers for sure.

To check, try this select on one of the nodes,

select ll_name, state, backup_date, deactivate_name, class_name
 from backups
  where node_name = 'THE_NODE_NAME'

I expect you will see files in the active state with no deactivate date
and the mystery class.

Bill Colwell
Draper lab

> -----Original Message-----
> From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf
> Of Keith Arbogast
> Sent: Thursday, September 06, 2007 5:30 PM
> To: ADSM-L AT VM.MARIST DOT EDU
> Subject: deleted management class in database
> 
> I ran this query to determine which management classes are being used
> by our clients; select distinct node_name, class_name from backups.
> 
> The query itself may be wrong or wrong for the purpose. However, the
> output contained a surprise. Several current nodes had management
> classes listed with them that are no longer defined, and haven't been
> for some years. That is, they do not appear in the output of 'q mg'.
> 
> Under what other circumstances could management classes be in the
> database, but not in 'q mg' output? The TSM server is at level
> 5.3.1.4 on AIX.
> 
> With my thanks,
> Keith Arbogast
> Indiana University