Privileges and system efficiency

[Mike Jenkins_3]

If all of the programmers on a VMS system have full system privileges, what will happen to the processing speed of the system? The system I am currently using has approx 150 users, mostly programmers & developers. All of them have full system privileges. How will this affect the programs they create? How can the speed of the system be made better?

[Martin P.J. Zinser]

A user having full privs or not does not influence the speed of the system directly.

Having said that, there are certainly corollary considerations to this.

E.g. if just about anybody is allowed to change system parameters any systematic approach to system management and tuning is severly impacted. Also developers with full privs on the development system tend to write code that expect similar rights on the production system (although they might not really be needed with some care and consideration).

Generally I suggest to reduce the privs given to general users if possible. You should make sure otoh that qualified personal is around to fulfill justified requests (after all also time of a developer has to be paid ;-)

As for speed increases, the general rules apply, first collect some statistics on how the system performs, then determine the bottleneck (like e.g. I/O, CPU, Network, application(!)), resolve the bottleneck, start over at the beginning :->

[Hein van den Heuvel]

Give that man 10 points for the funniest question in this forum to date!

This particular efficiency problem is possibly best solved with a baseball bat!
Or a 2-by-4 'behavioural correction tool'

There is no direct correlation between privileges and performance.
There is a relation between peoples actions and performance and this can indirectly be influenced by privilleges.
For example, if some of your programmers endulge in a process priority slugfest (because they can with those privs) then the 'nice' programmers might experience poor performance.
Ditto if some see fit to disproportionally raise thier working sets.

I would prefer to call this a people problem, not a privilege problem.

> How can the speed of the system be made better?

Easy: Buy more memory!
Need more speed still? Buy more CPUs and more memory!


Grins,
Hein.

[John Gillings]

Mike,

True story... many years ago at a long defunct company, on of the users several rungs up the management tree was given privileges because he couldn't see why people "below him" should have "privilege" if he couldn't. He discovered process priorities, and, since he was FAR more important than anyone else, he would routinely increase his priority to absurd levels (27 was his favourite).

The effect was disasterous. As you probably know, processes running above priority 16 are considered real time, and therefore do not have automatic working set adjustment. So, when this manager ran anything, he was stuck inside his tiny default working set, which would cause the system to page thrash very badly, effectively stopping the system for everyone else while his job ran. It didn't seem to matter how often we explained that maintaining a priority of 4 would actually IMPROVE performance over raising it to 27, he persisted.

Our solution was some hackery that made his process *appear* to be at priority 27 when it was really 2, since his performance at 2 was actually better than at 27, he didn't know the difference :-)

The lesson is that although granting privileges does not, in itself, affect performance, what users do with those privileges can have a profound effect. The best strategy is to grant privileges only when it can be shown to be absolutely necessary. In many cases an application that seems to require privileges can be easily changed so privilege is unnecessary. This will be better for all in the long run.

Even when privileges are necessary, it's not a good idea to have them enabled by default, or while doing day-to-day operations. They should only be enabled when required and disabled at other times. Leaving privileges enabled can lead to accidents (for example, DELETE *.*;* in the wrong directory - don't laugh, it happens more often than you think!), and can mask application design flaws or oversights. Discovering these only when doing acceptance testing in target users non-privileged accounts can be very expensive!

The best quality software is produced by developers with no privileges on slow systems with limited disk space and memory. Think about it...

[Willem Grooters]

John,

Your last lines contain the best statement I've seen in years. I'll put that on my site.

Willem

[Willem Grooters]

Hein,

>> How can the speed of the system be made better?

>Easy: Buy more memory!
>Need more speed still? Buy more CPUs and more memory!

Was true in VAX days, is now on Alpha and will be on Itanium, I guess. One addition: buy the RIGHT memory. Otherwise you may loose performance....

As a (senior) developer, I know you normally don't need extra privileges. If you do need them, your software will (and will require special attention in installation!).
My basics: Keep privileges to the bare minimum and only raise them where explicilty (and proven) required, and only then when he (or she) has shown to be diciplined enough to get them. Grant these NOT by default, do NOT allow them to change them in LOGIN.COM.
Do NOT grant tprivileges based on the status of the requestor (do you grant all privileges to your CEO? I don't).

Willem

[Antoniov.]

Hi Mike,
why your developer have full privileges?
Some year ago, I worked in software house where developers said they need full privileges to work then they used their priv to manipulate the system (same as John).
Today I'm owner of a micro software factory and we work ALL using minimal privileges (NETMBX, TMPMBX plus WORLD and PHY_IO). I'm using CC, MACRO32 and COBOL compiler: no problem, no operative limitations.
This feature avoid I can go on effective environment because I can't access it.
When I have to read effective data I have a special user, in same group of final user.
Also, system password ik known by all developers, so they (and me) can login at system privileges if need.
This is best and most safety way to work.

Bye
Antoniov

[Ian Miller.]

all usesrs should start with normal priv then for each extra priv they should ask for it by name and with justification. I've found most developers don't know the names of VMS priveleges never mind what they are for. The difficult bit can be getting management backing for this. The developers say we need to have all privs or the project will slip and the proj mgr jumps up and down until they get them.