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

[DaveFroble]

Stephen Hoffman wrote:
> On 2018-01-10 19:03:31 +0000, DaveFroble said:
> 
>> Stephen Hoffman wrote:
>>>
>>> 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.
> 
> I usually poll and translate the SHUTDOWN$TIME logical name, but that's 
> not entirely reliable as interrupted shutdowns don't get that deleted 
> when last I checked.   I'll defer grumbling about the use of logical 
> names for this, and the use of polling.
> 
> There are existing notification mechanisms with system services and ASTs 
> (everybody knows about $SET_SYSTEM_EVENT and  $SETCLUEVT and friends, 
> right?  Why that's two separate services?  Donno.  There's also 
> home-grown schemes using locks or such.
> 
> None of which is as simple as it should be, nor is any of this as 
> modular nor easy to package together into a deployable package as it 
> should be.  You can't package up the app and its necessary startup and 
> shutdown.  SYSMAN STARTUP et al never fully got there.   You have to go 
> edit files when you add or remove an app.  And you have to add or remove 
> apps with dependencies in the right order.   Hopefully, few folks toss a 
> startup or shutdown merge operation or migration onto the end-users 
> here, but OpenVMS itself has forced these merges and migrations on 
> end-users on various occasions.
> 
> These are all part of generic notification mechanisms, generic process 
> control and scheduling mechanisms, integration with packaging and 
> installation tools, and with distributed system and app upgrade 
> mechanisms, too.
> 
> SYSHUTDWN.COM is often the wrong spot for this, too.   For many cases, 
> the shutdown operations should be over in the ever-familiar and 
> wonderfully named SYSHUTDWN_0010.COM procedure, as that runs somewhat 
> ahead of when everything goes away.    SYSHUTDWN.COM runs after most of 
> the system has become inaccessible.
> 
> Better approaches and all of what I am discussing here already exist on 
> other platforms, too.
> 
> Oh, and none of this accounts for the network going away for whatever 
> reason, and which is a whole 'nother pile of fun I'm having to deal 
> with.  When the system is running fine, but the network burbled or 
> somebody restarted IP to fix some other issue.
> 
> Again: I'm not questioning whether any of this can be done with existing 
> APIs and tools.   It can be.   I'm commenting on whether any of us 
> really think it's easy for everybody to do this and that all developers 
> know and adopt this, if it's well documented, and if it's been 
> structured such that developers folks either default to usage and 
> availability, or want to adopt the usage and can easily do so,   I don't 
> think it is.  And that's also from having to step a number of OpenVMS 
> folks through modifying system startups and shutdowns, and through the 
> accreted warren that constitutes the TCP/IP configuration mechanisms.  
> That's a level of manual effort that many other platforms now require.   
> Or as many folks are doing and yes increasingly even with OpenVMS: 
> https://www.youtube.com/watch?v=p85xwZ_OLX0
> 
> 

Well, my opinion is that much of this rests with the application designer.

In our applications, we have a message manager, and all background tasks get 
their assignments through the message manager.  When we want them down, we just 
send a command to the message manager, and it directs all active background 
tasks to shut down gracefully.  Rather simple.  Works very well.

Even if some of the things you mention were available, application designers 
would still have to figure out how to use them, and to implement that usage.


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