[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