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

[Stephen Hoffman]

On 2021-09-29 17:27:22 +0000, Dave Froble said:

> 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.

As a specific example, installing an app that creates an app-specific 
username and UIC and that then wants to set up its own environment and 
protect its files is tough to reliably automate on OpenVMS. That 
usually gets tossed over to some other procedure, and—best case—the 
user then has to enter a bunch of prompts for this data, which—best 
case—the app then has to verify that no collisions occur.

> 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.

I'd like to, but the environments—even OpenVMS itself—have gotten past 
what most of us can keep track of. Apps and platforms and networks have 
gotten big enough that we can only hope to keep hunks in focus at any 
one time.

> 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.

Yeah, that's naming coordination and job control and the rest. All 
possible to implement. But it can make for complex app code, or—as 
happens more often than not—no code and a pile of documentation for the 
installer to follow and to deconflict. Or for guests, as many of us are 
probably heading for. VSI will probably be discussing how x86-64 guests 
will be licensed, but that's still a year or three ahead for many of us.

> 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.

Typical for many are old and production and new and development 
versions for instance, and—as I've experienced—the occasional username 
or logical name or UIC collisions across disparate and utterly 
unrelated packages. Some of which will be silent errors. Or weird 
errors.

> 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

The difference with having common code is that most of the easy 
app-separation mistakes have already been made.

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

It's more about automation, and working to reduce the cognitive load on 
the developers or support folks or the end-user folks. Coding an app to 
do what you did is that effort, all within the app. Having similar app 
coordination implemented in the underlying platform is what is being 
discussed.

Preferably with better means to isolate and protect apps against 
developer-created mistakes, or support- or end-user folks' mistakes, 
too. App and server reliability and robustness, in marketing terms.

This whole area is part of why robust OpenVMS installers stink to 
write, and part of why isolating potentially-vulnerable app servers (or 
components of apps, such as parsers) is difficult.

Simple installers and simple configuration scripts are somewhat faster 
to write, and suitable for isolated apps and dedicated servers.

But when we're dealing with ever-increasing numbers of 
dependencies—yeah, we'd all like less of that, but that's not the path 
any of us are on—problems and collisions are inevitable.

And each of us would really rather not have to learn each app's own way 
of doing this coordination, for those apps that do it for themselves 
(VSI SSL/TLS sorta-kinda tries this, Oracle Rdb does pretty well, some 
others leave it all to the installer.)

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

Downside there is owning lots of code that then has to be maintained 
and updated. Which can then have knock-off effects around—for 
instance—online backups of app data using BACKUP or other tools. 
Features that would be useful, but that never get near the top of the 
development schedule. Some databases can do live backups, while that's 
much less common with apps using RMS.

> 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

I've chased a whole bunch of logical name collisions around, over the 
years. Met several that collided with OpenVMS verbs the developers 
didn't know about, too.



-- 
Pure Personal Opinion | HoffmanLabs LLC