Bob,

In the training manuals I have written to teach new clients the e3000, the
issue of SM capability was always addressed like this:

MANAGER.SYS and MGR.TELESUP are the only two userids on the
system with SM capability.  These userids are both passworded and only
the system manager (and his/her backup) know the passwords, and are
given access to logon as these userids (in Security 3000).

All the functions you list are ones that can be accomplished in some other
way that does not required SM capability for the initiating user, with the
exception of managing accounts and system level UDCs which are the
responsibility of the system manager.

The account structure should, in most cases, be a reasonably stable
structure.  If you are regularly creating and destroying the groups in
your account structure, or worse, accounts in your account structure,
find out why and stop it.  The account structure forms the basis of
security on the e3000 and should not be changed haphazardly.  And,
since accounts are part of volume sets which logically group the
system disk drives whose space we have to monitor and make
available for the official functions required by the powers that be...
enough said.

If your UDCs are changing that frequently, find out what changes are
being made, and evalutate what needs to be in your system level UDCs.
Most UDCs can be replaced with command files in a public group
whose location is in the HPPATH set as part of system login; and the
most volatile portion of the system UDCs, the option LOGON setup
logic, can be segregated placing the SETVAR, SETJCW and FILE
logic in a file which is then XEQ-ed from within the system level UDC.
That process allows maintenance without touching the system level
UDCs.

You've touched a nerve here; but, the short answer is NO ONE GETS
SM CAPABILITY EXCEPT THE SYSTEM MANAGER.  Tell
your programmer to plan his/her work better and NO, he/she cannot
have access to the entire system unless he or she wants to be awakened
at 2:00a the night the system locks because someone screwed with
something they shouldn't have been able to touch anyway.  (Not that
this has EVER happened to me.)

Rs~

Russ Smith, Systems Consultant
Problem Solved, Vacaville, CA
r s m i t h @ c u - h e l p . c o m
h p 3 k - l @ e - 3 0 0 0 . n e t

----- Original Message -----
From: "Bob Sorenson" <[log in to unmask]>
To: <[log in to unmask]>
Sent: Friday, June 02, 2000 12:48 PM
Subject: [HP3000-L] SM Capability Issue


> Hello All!
>
> I would appreciate any comments you might have regarding SM capability.
We
> have five folks who have SM capability on our production box.  Three are
> Ops; two "upper management".  I am being asked to give our Senior
> programmer, who now has the title of  "Manager of Production Support", SM
> capability.
>
> Any IT audits I've gone through have made it clear to me that Ops and
> Programming should be very separate functions.  Operations moves code into
> production.  I've asked for justification, and I was told this person
needs
> it for account maintenance, udc maintenance, and copying files across
> accounts.  Only account maintenance can't be done without SM, and I
contend
> that should be an Operations function.
>
> As with any System Manager, I am ultimately responsible for what happens
on
> the machine and I'm not comfortable giving this out to somebody who is
> bright, but may not understand the ramifications of changes to udcs,
> third-party software accounts, etc.
>
> So, yes or no?  Your reasons why you feel the way you do would be greatly
> appreciated!    :-)
>
> Bob Sorenson
> System Manager
>
> INFOTRUST
> 1615 Lakeside Drive - Ste 200
> Waukegan, IL  60085
> Voice:  847 887-8087
> Fax:    847 887-8001
> [log in to unmask]
>