Why are numeric user names allowed but their identifiers not ?

[John Gillings]

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.

[Robert Gezelter]

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]

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

[John Gillings]

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.

[Jan van den Ende]

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