Joseph,

Thank you for the logical commentary.  I agree with you that capabilities
should be based on duties, not necessarily title.

In the case here, this person can perform ANY of his functions without PM or
SM capability.  Several may take him a little longer, but it's work he only
has to perform once a month or so.  I can't justify giving him SM capability
on our production box just for this.  In fact, I've offered to help.

Boy, I could just see the auditors' faces now if I explained why I gave SM
cap to this person. . . for a function performed monthly.  Yikes!

Thanks again sir!  Your contributions to the list are appreciated my me, and
I would imagine many others.   :-)

Regards,

Bob Sorenson

-----Original Message-----
From: Joseph Rosenblatt [mailto:[log in to unmask]]
Sent: Monday, June 05, 2000 9:41 AM
To: Bob Sorenson; [log in to unmask]
Subject: RE: [HP3000-L] SM Capability Issue


With apologies to the Bauhaus, Capabilities follow Function.

It is my opinion that only those functions that need a capability should
have the capability. This should be function, not user, related. The title
of the user does not necessarily describe their function. If your "senior
programmer" now has system management functions then he/she needs SM
capability. If not then he/she should not have SM capability. It is all a
matter of function. (If the user's function now includes a need to use some
of the SM capability's functionality the user must be taught how to be an SM
user. To allow the user SM  and let them destroy systems because they are
uneducated is irresponsible.)

We had a programming manager that moved to a different , non IS, department.
I took away their colon prompt access and gave them the same menus that the
person they replaced had had. The argument they used to get colon access
again was basically, "Don't you trust me anymore?" My answer was that your
current function does not require these capabilities. If they could justify
the need  they could have the capabilities.

I firmly believe that "trust" is not an issue. By that I mean trusting a
person is not a reason to allow them capabilities. (I only wish that I could
take away capabilities based on my lack of trust but that's a different
topic.) The operative word here is not "Trust" but "Audibility." Can I audit
your actions? If yes, I can trust you. If no, how can I justify your
capabilities to an auditor? In general auditors don't like security
loopholes and every person with SM capability is a security loophole.

Need for a capability can not be based on, "It may help me perform some
amorphous duty in some amorphous situation at some unknown time." Having SM
capability should not be misconstrued as "Having arrived." It is not the key
to the executive washroom. It is a tool to be used by those that know how
and need to use it. Misuse of SM and the oft forgotten PM capabilities can
have far reaching effects on your system.

Joseph Rosenblatt
-----Original Message-----
From:   HP-3000 Systems Discussion [mailto:[log in to unmask]] On Behalf
Of Bob Sorenson
Sent:   Friday, June 02, 2000 3:49 PM
To:     [log in to unmask]
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]