[Info-vax] OpenVMS development tooling (was: Re: VSI strategy for OpenVMS)

[Stephen Hoffman]

On 2021-09-29 22:21:53 +0000, Lawrence D’Oliveiro said:

> On Thursday, September 30, 2021 at 6:03:00 AM UTC+13, Stephen Hoffman wrote:
>> 
>> You're going to be re-inventing GUIDs on the path you're on.
> As a counterexample, consider that the DNS has nothing resembling 
> GUIDs. Its whole point is to abstract away from numbers (which can 
> change), and let people use names instead. That system is able to 
> interoperate between millions, nay, billions of users and services 
> worldwide.

Reversed domain names works fine for what it does and its certainly 
more human-friendly for naming and without a central registrar as 
OpenVMS has long assumed, but it's also rather less than applicable for 
UIC/UID/GID replacements, among other details.

I haven't checked to see if reverse domain names are enforced on Linux. 
On some of the platforms I've worked with that use that—OpenVMS does 
not—the rather similar UTI notation isn't. In various places, it's 
still a convention.

>> As soon as a user or a developer creates a traditional fixed name or a 
>> traditional UIC/UID/GID value or the ever-popular fixed filenames for 
>> log files or such, there are opportunities for collisions.
> There have been systems for allowing developers to come up with their 
> own package names, in Java for example. They tend to implement a 
> hierarchy with a remarkable resemblance to ... guess what ... the DNS.
> 
> Consider also that a Linux distro like Debian offers something like 
> 50,000 packages for a user to install. Yet they manage to avoid 
> filename collisions.

Please see previous posts for links for more information on tooling 
related to what is referenced here, and particularly around managing 
the ensuing complexity that arises within Linux in this same area.

Though I should not need to state this, present OpenVMS tooling and 
OpenVMS features work rather differently than do the various installers 
on Linux, and with differing limits and considerations arising within 
OpenVMS, as well.

And to be blunt, if this whole area gets overhauled—unlikely as that 
seems at present—I'd rather not copy a problematic convention from 
Linux or Java, if a better and more automated approach is available.

Go write some OpenVMS installers, and you'll start to encounter some of 
the limits that arise here.  And some of the collisions. PCSI tries to 
work with some of those collisions, but some are... intractable.


-- 
Pure Personal Opinion | HoffmanLabs LLC