Hi John,

It sounds like what you want is CLASSES=POLICY, although I'll grant you (do
I get credit for a PUN???) one can't determine that very well from the
documentation for the GRANT AUTHORITY command.

When you specify CLASSES=POLICY, you specify a list of policy domains the
admin id can control.  That admin can do stuff ONLY for the nodes in the
specified domain(s):   lock/unlock, register, associate, change passwords
(not sure what else).  It doesn't let that admin do any stuff on the server
end, like checkin/checkout, manage storage pools, or mess with admin
schedules, or even create new domains; you need SYSTEM for that.

We use CLASSES=POLICY, for example, to distribute some of the admin work.
The people at the HELP DESK have POLICY authority over the desktop client
TSM DOMAIN so they can help users with registration and passwords, but they
don't have any authority over the production servers, which are all in a
different TSM domain.

The only problem we found, is that CLASSES=POLICY doesn't give them the
authority to CANCEL sessions for those clients, which is a pain.

I can't remember where I found this documented, but there you go.  I think
you may have to work backwards, by looking up specific commands (register
node, for example) and checking to see what privilege class is required.

Hope that helps...

Wanda