[Info-vax] Multi-site OpenVMS field upgrade options?

Stephen Hoffman seaohveh at hoffmanlabs.invalid
Mon Apr 15 14:23:25 EDT 2019


On 2019-04-15 16:54:35 +0000, Dave Froble said:


> Thus it should be an integral part of the overall design of a "system" 
> to recognize future activity and plan for it.  It seems that you feel 
> most of this responsibility should be born by the OS.  True, some good 
> tools can make things easier.

Migration is ultimately up to the apps and app developers.

I'm pointing out that OpenVMS stinks at even basic migrations, far 
behind what—for instance—macOS routinely provides for a simplistic and 
off-line computer-to-computer migration.

Server-to-server was pretty good too, though Apple is now out of the 
server business.

Also that express practices of OpenVMS—editing startup files, etc—make 
these server-to-server migrations more difficult, as well as 
installations and upgrades.

Which usually means tossing around disk images.  Which works.  But then 
restoring disk images or disk savesets can be somewhat lacking in the 
area of reproducibility.

> But ultimately, it is the designer(s) of the overall system who should 
> bear the responsibility.  I'm pretty sure that you'd agree that even 
> your beloved Macs can be screwed up.

Ah, thanks for the setup there, David.  Yes.  macOS and Mac hardware 
can certainly be "screwed up", as you put it.

But I'm quite happy with how fast a replacement and redeployment can 
happen with macOS, or a wholesale reload can happen with macOS, though.

Whether that's a wholesale restoration, or migrating the apps and 
documents and settings to a new macOS installation.

The Time Machine defaults here work nicely.  OpenVMS and BACKUP, not so 
much.  There are no defaults there.  Which means some DCL skills and 
some knowledge of the pitfalls, and not without writing backup 
procedures.  And periodically testing those.

Not that all of the OpenVMS sites recognize the pitfalls of BACKUP and 
(for instance) /IGNORE=INTERLOCK qualifier, for that matter.

> Just sayin, don't be too quick to blame the tool (OS) for the errors of 
> the workman (app system designers).

I'm blaming the OS for being too-complex and too-manual around software 
installations and integration, and around configurations, upgrades, 
patches, and migrations.

This all ties into backups, startups, configuration files and app and 
system configuration profiles, the integration of IP and network 
services into OpenVMS, and more than a few related topics I've 
previously grumbled about.

> And also agreeing that better tools are and should be possible.

There can be a path ahead for folks to migrate their apps to better 
approaches, and that takes thought and that takes leadership from the 
folks at Bolton.

But then the new work at Bolton is seemingly saturated with the efforts 
around the x86-64 port.


-- 
Pure Personal Opinion | HoffmanLabs LLC 




More information about the Info-vax mailing list