Operating System - OpenVMS
cancel
Showing results for 
Search instead for 
Did you mean: 

Why are numeric user names allowed but their identifiers not ?

 
Wim Van den Wyngaert
Honored Contributor

Why are numeric user names allowed but their identifiers not ?

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)
Wim
14 REPLIES
Uwe Zessin
Honored Contributor

Re: Why are numeric user names allowed but their identifiers not ?

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
Honored Contributor

Re: Why are numeric user names allowed but their identifiers not ?

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
Honored Contributor

Re: Why are numeric user names allowed but their identifiers not ?

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
Honored Contributor

Re: Why are numeric user names allowed but their identifiers not ?

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.
A crucible of informative mistakes
Wim Van den Wyngaert
Honored Contributor

Re: Why are numeric user names allowed but their identifiers not ?

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
Wim
John Gillings
Honored Contributor

Re: Why are numeric user names allowed but their identifiers not ?

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."
A crucible of informative mistakes
Wim Van den Wyngaert
Honored Contributor

Re: Why are numeric user names allowed but their identifiers not ?

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
Wim
John Gillings
Honored Contributor

Re: Why are numeric user names allowed but their identifiers not ?

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.
A crucible of informative mistakes
Wim Van den Wyngaert
Honored Contributor

Re: Why are numeric user names allowed but their identifiers not ?

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
Wim
John Gillings
Honored Contributor

Re: Why are numeric user names allowed but their identifiers not ?

Wim,

You didn't answer the question about potentially introducing bugs in existing programs... That factor would prevent a mass source change, even if engineering resources were infinite.

I'd also remind you that the points system is intended to reflect the QUALITY of the responses. Giving 1 point because you "just don't like" the answer is churlish at best. I answered your question completely. Your disagreement with it doesn't make it wrong, and it doesn't devalue it.
A crucible of informative mistakes
Robert Gezelter
Honored Contributor

Re: Why are numeric user names allowed but their identifiers not ?

Wim,

Just my US$ 0.02.

While I understand and sympathize with the desire to refine the OS API continuously, changes to the OS API must be weighed against their disruptive effects.

As an example, consider the ease with which OpenVMS users and developers who used the standard OpenVMS Time of Year value rode out the so-called Y2K crisis, while applications and users who used the commonplace YYMMDD format digested massive changes. The *IX world, with its original time format being a 32 bit word with an epochal date of 1970, is still digesting the realization that their epoch ends in 2038 (and remediating code to the extended time-date format).

OpenVMS is notable in that its core archictectural features were well thought out, and have proven extremely durable. The OpenVMS Time of Year (TOY) quadword is one such example. Some of the features brought over from RSX-11, notably the QIO interface and the ACP/XQP interfaces is another. The almost universal use of RMS for file and record access is yet another.

The QIO interface, with its range of function codes, its request specific, but relatively unspecificied completion indicators (event flags and ASTs) have been particularly useful over the years. The fact that ASTs have a parameter is extraordinarily useful, as I have pointed out in many sessions and seminars on using ASTs (some of the notes are on my www site under presentations at http://www.rlgsc.com/presentations.html ). The existence of ASTPRM, which was absent in the RSX-11 AST interface, is a powerful tool. Contrast this with the UNIX signal facility.

In fact, it would not be unreasonable to say that without the QIO, RMS, and AST architectural elements, technologies such as OpenVMS clustering would likely have been stillborn, at least as we know it.

Underlying architectural concepts and stability are fundamental to an APIs ability to expand functionality, without requiring massive re-writes of existing code bases to conform to the updated interface. How to achieve this has been a focus of many of my presentations to IEEE Computer Society Chapters in North America for the last few years under the society's Distinguished Visitors Program.

The case of the quota exceeded (SS$EXQUOTA_ and no privilege (SS$_NOPRIV) are an example being passed all the way up to the user is, to some extent, more of an example of how vision is not always perfect. For example, a SS$_NOPRIV, at the time of the actual system service call, is often in a far clearer context than when it appears out the end at the user's terminal. It is also a conscious decision to limit the amount of security information disclosed (although, note that MOUNT/SYSTEM tells the user if SYSNAM is not enabled).

SS$_EXQUOTA is similar.

Changing return codes of commonly used system services would be disruptive. Small changes within the existing paradigm can be made in areas that are not well defined without disruption.

On the budget side, while I sympathize with a desire to constantly revise, I strongly agree with John, the cost of the work, and the costs and disruption imposed on customers to retrofit existing code, are an insurmountable obstacle to revisions.

It would also sacrifice one of OpenVMS' hallmarks. While other systems have been known for their disruptions and replacement of basic APIs, OpenVMS, despite the fact that it has advanced the cutting-edge technology on many fronts, has managed to live within its API for decades. The last disruptive change was with the introduction of changes into the logical name facility at roughly version 4 (I would have to look up the exact version, I don't have the old docsets handy as I am writing this; and that was handled without significant disruption to existing programs). OpenVMS is still running unmodified source programs from the beginning.

Not having to retrofit existing software frees HP and customer resources to expand the technology, not be consumed by retrofitting.

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



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

P.S. for John: Nice paraphrase of Churchill
Wim Van den Wyngaert
Honored Contributor

Re: Why are numeric user names allowed but their identifiers not ?

I understand that most of you are very proud on VMS but for me it's just an OS (but a good one compared with others, but I also classify MPE as a good one). I see strong points and I also see weak points.

Note that my statement was
*** I think this one and the "quota exceeded" stuff should have been refused by the test/acceptance team ***. And I stay with that.

About the points : John got 3 points for his original posting. 1 point because it's no longer on topic but only (intresting) background info. May be I should raise it to 2 because 1 is indeed low.

Q>
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?
\Q>

There are other possibilities such as keeping the status and using "Quota !AS exceeded".

Q>
introducing bugs in existing programs
\Q>

Then improving software is NEVER allowed.
And this is rather a rather safe change : cutting an if into pieces.
BTW : wasn't TCP not re-ported ? Wasn't that a big risk ? And decnet + ?

Wim
Wim
John Gillings
Honored Contributor

Re: Why are numeric user names allowed but their identifiers not ?

Wim,

Sigh. You seem to believe you're the only person who ever thought about this? People far smarter than myself, and maybe even smarter than you, have considered these issues, and many others where architectural decisions have caused difficulties over the last few decades.

I can assure you if there were a solution which did not risk the upwards compatibility of existing customer programs, it would long since have been implemented.

One example that bugged me for years were 16 bit length fields in descriptors. This HAS been fixed with 64 bit descriptors. For compatibility, the big descriptors "waste" a whole longword so they can be distinguished from the old, limited ones. Not really pretty but it solves the problem in an upwards compatible manner. Old code still works, and new code can escape the limitations of the earlier APIs.

Unfortunately there are some instances that are intractible. You can certainly criticise the original decision (and I'd agree with you), BUT, it's done and no amount of complaining is going to change the past. I'm sure we could all find architectural decisions that could have been done better in (say) the Empire State Building or the Effiel Tower, but no one's going to tear them down and rebuild them to "correct" the perceived problems. Even though software is sometimes easier to rework, there are some decisions that are as set in concrete as if they were physical buildings.

>There are other possibilities such as
>keeping the status and using "Quota !AS
>exceeded".

That would be fine, IFF the condition were signalled from a place where the quota was known, including a string to identify the quota in the signal array. However, the cases we're talking about are all in system services, and system services NEVER signal conditions (think about what happens when you signal a FATAL condition from kernel mode...). So, all you've got is the conditon code. There's no mechanism to return the !AS argument to anywhere where it would be of any use.

Improving software is always allowed, but only in ways that preserve upwards compatibility. Fortunately OpenVMS gives us plenty of mechanisms that help, BUT not everything is possible. Please read Bob's response.

Yes TCPIP and DECnet+ were reworked, but look at all the effort that went into preserving compatibility. All the old UCX and DECnet IV interfaces and APIs, both DCL and programmatic, are still present and still work as they always did. Your old code still runs without recompiling or relinking. If you want to, you can write code to use the new stuff.

If you feel so strongly about this, I suggest you log a formal case against your service contract and request an enhancement.
A crucible of informative mistakes
Jan van den Ende
Honored Contributor

Re: Why are numeric user names allowed but their identifiers not ?

John wrote


All the old UCX and DECnet IV interfaces and APIs, both DCL and programmatic, are still present and still work as they always did.


If that only were true!!!

Especially TCPIP is a DISASTER.

Let me just give you an example: it was TCP V5.3, some ECO (was it 4?).
_NOT A WORD_ in the releasenotes, no explanations at all, but _THAT ECO_, (just an ECO, = bugfix )completely changed the cluster alias mechanism. Worse: it _REMOVED_ some syntax that was in rather common use during TCP startup (which in turn is normally included in bootstrapping), generating syntax errors.

John, do you seriously mean this is acceptable? In the VMS environment?

Yes, I know the argument: we follow the standards, we had to.
But even then, would it not have been normal to WARN about this, doing every thing possible to make it noted BEFORE installing the patch? And having some way to postpone implementation till after relevant reprogramming of the startup had been done?

No, but it is (nearly) always the same with the (mostly) crap that is hauled over from *X.
It looks like Engeneering has two completely different sets of rules governing upward compatibility: the classic one we have come to love, and the U*X style we have come to hate!

Proost.

Have one on me.

jpe

Don't rust yours pelled jacker to fine doll missed aches.