[Info-vax] OpenVMS servers and clusters as a cloud service

[Stephen Hoffman]

On 2018-01-09 17:13:48 +0000, DaveFroble said:

> So, I'm still having some problem in seeing how any OS capabilities 
> could have helped.  Of course, all in the context of what my apps were 
> doing.  Perhaps other apps could benefit.

A call in the main processing loop that quiesces all file activity and 
flushes local caches and checkpoints all open files.  This operation is 
penultimate to what's needed for process migration, too.

A callback that informs the app that a backup would like consistent 
access to the app's open files, and allows the app to do whatever, 
flush caches, and quiesce itself, and that allows the app to inform the 
backup tool which files need to be captured or selected for file-level 
mini-merge.

A callback that can read in and can write out the contents of 
user-defined and system-defined structures comprising the process 
context.  We're headed this way with non-volatile memory already, and 
we're going to have some "fun" dealing with the implications of that.

A way to marshal and unmarshal state and configuration data, for that 
matter.  That's not a "fun" operation on OpenVMS, and I'm always 
writing what an OO API usually provides me, when I need to do that.

A way for the system to tell the app to cleanly exit because the app or 
the system is shutting down or because patches need to be be applied, 
for that matter.

A way to easily select a primary app among those of a cluster, without 
having to slog through the lock manager code and its documentation.  
That same API could flag the lack of available secondary apps to system 
management or other sorts of app-related faults, for instance.  Tying 
into distributed process management, which doesn't exist on OpenVMS 
without either piles of glue code and hackery and more than a little 
time debugging corner cases, or without an add-on package.

Some of the approaches here can involve different app design patterns 
than are common on OpenVMS, too; where OpenVMS calls the app for 
various tasks and the app responds to those requests and uses its own 
code and services and local and system APIs as part of that, rather 
than the app having "processing primacy" once launched and calling 
OpenVMS APIs.  Various OO systems routinely use this event- or 
request-driven design.  Device drivers are an OpenVMS construct that 
follow this pattern.

All this is certainly possible from first principles and existing APIs 
and with enough skills and schedule and testing time and some with the 
use of add-on third-party code and tools, outside of integration with 
process-level or system/VM-level migrations and integration with 
platform archival tools and such.  But it's a slog. And it's a pile of 
glue code.  And in practice, this stuff just doesn't happen in most 
apps.  Not as often as it should, if the goal is to be robust and 
available.





-- 
Pure Personal Opinion | HoffmanLabs LLC