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

[DaveFroble]

Stephen Hoffman wrote:
> 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.

Yes, that would have helped.  My main worry was that the progress flags I'd set 
actually made it to disk.

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

Set up this in the SYSHUTDWN.COM command file.

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

Not all those ideas would benefit me, but, then, I'm not the only one using the 
OS.  Perhaps the low hanging fruit will be picked.

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