Why are numeric user names allowed but their identifiers not ?

[Wim Van den Wyngaert]

So, user id 123 is accepted but the identifier of the user is refused because it is numeric.
Historical reasons ?

Wim (monitoring the gold price go up)

[Uwe Zessin]

How should the system know if you mean an identifier or a UIC?

123 = [16,1777777] ! a group identifier, from memory

[123,4] - is that:
-- [123,4]
or
-- [16,4]
?

[Robert Gezelter]

Wlm,

I concur with Uwe. How would you differentiate syntactically from [123456] for user 123456 and
UIC [123,456].

I grant you that the equivalence of [ggg,uuu] to [ggguuu] is a convention that goes back to the mapping between RSX-11 (where there were no usernames on directories, only UICs) and VAX/VMS 1.0, but it is a long-standing convention.

I suspect that changing the parsing would be a significant project. Prohibiting the numeric usernames would probably be lower.

- Bob Gezelter, http://www.rlgsc.com

[Uwe Zessin]

Of course, the other way round can be a problem for the user, too:
what do you think when you see: [123,4] ?
- that is [123,4]
- no, it is [16,4]
?

> Why are numeric user names allowed but their identifiers not ?

I'd say that the validation routine for identifiers is better than the one for the usernames ;-)

[John Gillings]

Wim,

Again I resort to the universal parental answer: "BECAUSE!"

Remember that usernames were architected back before V1.0, and resource identifiers retrofitted in V4.0. The two are independent. Although it's useful to keep them synchronized, it's not mandatory.

As others have noted, there are parsing issues if identifiers are allowed to begin with a numeric character. However, because of OpenVMS upward compatibility, it was not possible to retroactively prohibit leading numerics on usernames.

Again, it's something that, in retrospect, could arguably be more sensible it it had been done differently, but it wasn't, so we have to live with the way it is.

[Wim Van den Wyngaert]

I would say that DEC made some stuff too fast and afterwards always had the problem that they couldn't correct the problems because they needed to be compatible. Sad.

I think this one and the "quota exceeded" stuff should have been refused by the test/acceptance team.

Wim

[John Gillings]

Wim,

Hindsight is always 20/20. From 2006 it's easy to criticise a decision made in 1975, based on the available resources and state of the art of the time.

> DEC made some stuff too fast

What surprises me more is how many decisions made back then have turned out the be 100% CORRECT, and shown to scale cleanly on systems with resources far beyond the wildest dreams of the engineers at the time. Remember, early VAXes had 256K of RAM and 50MB disk drives were considered very large. Modern CPUs have *CACHES* larger than the total storage capacity, memory and DISK, of a VAX 780!

Someone had to blaze the trail. If we waited until everything was perfect before executing, the plan we'd never get anywhere. Similarly, if we revisit decisions and try to "correct" them long after the fact, we won't have time or resources left to move forward.


> "quota exceeded" stuff should have been
>refused by the test/acceptance team.

Again, a decision made for what was believed to be a good reason at the time. It was considered more secure (same rationale as the anonymous SS$_NOPRIV), and programmers were expected to know what privileges or quotas they were using anyway. The flaw in the theory is that the programmer may find himself many layers above the "action" and not completely aware of what is happening in intervening layers.

I know you think HP should re-read every code path and "fix" all the places where an anonymous EXQUOTA has been used. A laudable goal, but it's far too risky (introducing bugs! Consider, not only do you need to find the places the condition is raised, but also all the places they might be tested - this is non-trivial), far too expensive (engineering dollars are spread very thinly at the moment), and has far too little return on investement (how many extra OpenVMS licenses will be sold on the promise that $CREPRC might return SS$_EXPAGQUO rather than SS$_EXQUOTA?)

I'd recommend that anyone suffering an EXQUOTA review their quota allocations, considering actual available resources. Far too often processes are constrained by absurdly low quotas. For want of a few cents worth of some resource a whole factory might be stopped.

OpenVMS is far from perfect, it has many features that could have been implemented better, numerous inconsistencies, and even some outright bugs, but to misquote Mr Churchill "OpenVMS is the worst Operating System, except for all those other ones that have been tried from time to time."

[Wim Van den Wyngaert]

John,

15 years ago I used Unix. On Unix (at that time) most of the time you got the message "error". Or not even that (I remember a tar ending without message because the tape was too small. Nice surprice when I tried to install it at the customer site).

Such messages are simply not acceptable and IMO is the result of bad management.

Programmers prefer to write new stuff instead of completing the error handling and making the program customer friendly.

And the "no resource" and "too expensive" are simply no excuse.

Sorry to disagree.

Wim

[John Gillings]

Wim,

Hmmm, just 1 point. Is it worth responding to you?

What do you propose to do about the 30 years worth of programs that might be EXPECTING the documented return status of SS$_EXQUOTA if we suddenly change it to something different?

Some things, once done, are (perhaps unfortunately) stuck in concrete. We just have to accept that's how they are and learn to live with it. This thread has touched on just two. There are many others.

>And the "no resource" and
>"too expensive" are simply no excuse.

In the world where I live, budgets and resources are limited. This is the reality. I'd *like* to drive a Rolls Royce every day, but, unfortunately can't afford it.

[Wim Van den Wyngaert]

John,

In the world where I live I hear "no resources" all the time. This while they have plenty of time for doing other things(especially since the internet is available).

Wim