[Info-vax] OpenVMS development tooling

[Dave Froble]

On 9/29/2021 1:55 PM, Stephen Hoffman wrote:
> 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.

Of course.  TANSTAAFL  Some work is required.

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

It's not just "like to".  It is mandatory if one is going to insure the 
applications are installed properly.  As much automation as possible is 
helpful.  Count on it 100%, and you're going to lose.

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

If designed properly from the beginning, it's much easier.  For poor 
designs, there isn't much hope.

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

If one does not understand the environment, then there will be problems. 
  It takes work, and understanding, and study, and R&D.


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