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

Stephen Hoffman seaohveh at hoffmanlabs.invalid
Wed Jan 10 15:21:30 EST 2018


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


-- 
Pure Personal Opinion | HoffmanLabs LLC 




More information about the Info-vax mailing list