X-no-Archive:yes
SM is not a door prize. With some work, most of what needs to be done can be
done some other way, with some thought, planning, and work, whereas the
security implications of non-system managers having SM are unpleasant. One
can create not a few back doors and other vulnerabilities. We had someone
create an IMAGE db in a user account as manager.sys. That was an annoyance.

I assume you are using Ops for system support (shades of another thread on
what an operator is, does, and should be paid). I cannot imagine why upper
management needs SM, or why a programmer should (shades of a recent thread
on queues and their moral implications). That sounds like an ego thing.

Find out what these users feel they need, and find other solutions. Ask the
list about particulars; I'm sure you will get several good answers about
ways to accomplish tasks without SM. I have tried to get in the habit of
avoiding signing on as manager.sys, to be better appreciate these
distinctions.

A Q&D list of things that normally require SM:
-  Copy files between accounts with normal security (easy to work around)
-  Compare files between accounts with normal security (easy to work around)
-  Setup and admin new accounts (developers can plan ahead and then request
what they need, and have to work closely with the system manager to resolve
any issues)
-  Reset expired account passwords (monitor account password expiration and
plan accordingly)
-  Reporting on disc space utilization on a volume set outside the logon
account (so just log on to an account on that volume set).
-  Maintain system UDCs (stage and have the system manager migrate with a
standard job stream)

Greg Stigers
http://www.cgiusa.com