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

Dave Froble davef at tsoft-inc.com
Wed Sep 29 13:27:22 EDT 2021


On 9/29/2021 1:02 PM, Stephen Hoffman wrote:
> On 2021-09-29 04:18:49 +0000, Lawrence D’Oliveiro said:
>
>> On Wednesday, September 29, 2021 at 9:52:33 AM UTC+13, Stephen Hoffman
>> wrote:
>>> Using GUIDs—as some platforms do—avoids that whole UIC/UID/GID mess.
>>> (Who really cares about the actual numeric values?
>>
>> If nobody cares about numeric values, why use them? Why not use names
>> instead?
>
> You're going to be re-inventing GUIDs on the path you're on.
>
> As for the small numeric values used, that's largely tradition.
>
> Users don't like and shouldn't even be looking at GUIDs.
>
> OpenVMS switched to showing names for UIC group and member values a very
> long time ago, but the numbers are still there and still waiting to trip
> up developers and admins.
>
>>> Same for app-specific usernames. Who cares?
>>
>> You have to use something for identification purposes, and that
>> something has to be either a number or a name.
>
> 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.
>
> (OpenVMS uses conventions and once had a facility registrar, most of
> which is unenforced, and more than a few of the details have been
> forgotten or ignored. And SYS$SCRATCH is problematic for various reasons.)
>
> The registrar can be replaced by a GUID, temporary filenames generated
> in a GUID-defined private path, etc. Generated file paths also cuts down
> on cross-app shenanigans.
>
> This change unfortunately breaks the code with dependencies on
> UICs/UIDs/GIDs and usernames and temporary file paths, and which gets
> back to the installed base and maintaining compatibility.
>
> Some platforms have gone to GUIDs, and have been providing ways to avoid
> these collisions and better to isolate apps, whether through app bundles
> and related, or through containers.
>
> But it's work. And app disruption. And it's not something I'd expect to
> find on OpenVMS, though a UIC and username (RH IdM-ish) and job
> controller subsystem would be a nice update.
>

I'm not going to claim that I understand everything being discussed 
because I'm not familiar with some of the tools, concepts, and such.

It is my opinion that as soon as one counts on some tooling, concepts, 
capabilities that one doesn't totally control and understand that total 
control of an application isn't possible.  I've never done so.  I've 
always thought that an application design must include understanding and 
being in control of the environment in which the application exists.

Long ago I designed applications in a manner that would let me run 
hundreds of copies of an application, totally separate from each other, 
on a single computer system.  Of course, the system would never support 
such numbers, but, the environments would be controlled in a manner to 
guarantee there would not be any collisions between each copy of the 
application.  Not talking small stuff, I'm talking about robust ERP systems.

In practice, multiple copies of the ERP system, with a few exceptions, 
doesn't happen.  The computer systems themselves just don't have the 
resources to do so.  But, the design still would support such activity.

Does it take some individual work on each copy?  Sure, when they are 
sharing resources such as disks.  The way I understand containers, they 
also need similar setup.  TANSTAAFL

So, for me, I'm not sure I understand all the commotion about GUIDs, 
containers, sand boxes, and such.

I will add that I'm not into using lots of off-the-shelf applications. 
Much more into very specific designs.

Regardless, there are already capabilities that exist for setting up 
applications, should the application design allow use of said 
capabilities, that will co-exist.

And yeah, I really like to use logical names ...1

-- 
David Froble                       Tel: 724-529-0450
Dave Froble Enterprises, Inc.      E-Mail: davef at tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA  15486



More information about the Info-vax mailing list