Discussion:
New installment in The OpenVMS Consultant: Shutdowns using STARTUP.COM
(too old to reply)
geze...@rlgsc.com
2020-12-27 14:26:23 UTC
Permalink
The latest installment of The OpenVMS Consultant has been posted.

OpenVMS STARTUP.COM is far more than a tool for controlling system startup. It can also be used to accomplish a phased Shutdown of a complex environment.

See http://www.rlgsc.com/blog/openvms-consultant/shutdown-using-startup.html

- Bob Gezelter, http://www.rlgsc.com
David Jones
2020-12-27 15:30:46 UTC
Permalink
Post by ***@rlgsc.com
The latest installment of The OpenVMS Consultant has been posted.
OpenVMS STARTUP.COM is far more than a tool for controlling system startup. It can also be used to accomplish a phased Shutdown of a complex environment.
See http://www.rlgsc.com/blog/openvms-consultant/shutdown-using-startup.html
The biggest hazard to an orderly shutdown is that you terminal session goes when the network is shut off, leaving your system in a partially shutdown state.
I changed my shutdown symbol from "@sys$system:shutdown ..." to "$SYSMAN SHUTDOWN NODE /minutes=..." (appending /auto/save as needed).
Simon Clubley
2020-12-28 01:26:55 UTC
Permalink
Post by David Jones
The biggest hazard to an orderly shutdown is that you terminal session goes when the network is shut off, leaving your system in a partially shutdown state.
That's another thing that Unix got right big time.

I routinely reboot Linux servers from a SSH session to the server
and never have to worry about this.

Simon.
--
Simon Clubley, ***@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.
Dave Froble
2020-12-28 02:13:01 UTC
Permalink
Post by Simon Clubley
Post by David Jones
The biggest hazard to an orderly shutdown is that you terminal session goes when the network is shut off, leaving your system in a partially shutdown state.
That's another thing that Unix got right big time.
I routinely reboot Linux servers from a SSH session to the server
and never have to worry about this.
How much of a network was there in 1978 when VMS was released?

Regardless, VMS did get it right.

$ SHUTDOWN == "@SYS$SYSTEM:SHUTDOWN 0 SHUTDOWN YES NO LATER NO NONE"
$ REBOOT == "@SYS$SYSTEM:SHUTDOWN 0 SHUTDOWN YES YES LATER YES NONE"
--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: ***@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486
Phillip Helbig (undress to reply)
2020-12-28 08:12:36 UTC
Permalink
Post by Simon Clubley
Post by David Jones
The biggest hazard to an orderly shutdown is that you terminal session goes when the network is shut off, leaving your system in a partially shutdown state.
That's another thing that Unix got right big time.
I routinely reboot Linux servers from a SSH session to the server
and never have to worry about this.
I think that at some point that was fixed on VMS.
Jan-Erik Söderholm
2020-12-28 12:48:45 UTC
Permalink
Post by Phillip Helbig (undress to reply)
Post by Simon Clubley
Post by David Jones
The biggest hazard to an orderly shutdown is that you terminal session goes when the network is shut off, leaving your system in a partially shutdown state.
That's another thing that Unix got right big time.
I routinely reboot Linux servers from a SSH session to the server
and never have to worry about this.
I think that at some point that was fixed on VMS.
What was "fixed" in VMS? I do not remember anything that was
fixed that has any bearing on the issues with running SHUTDOWN.COM
from an interactive telnet or ssh session. Just do not do that.
And it is easy to avoid.
Stephen Hoffman
2020-12-28 16:48:42 UTC
Permalink
Post by Phillip Helbig (undress to reply)
Post by Simon Clubley
Post by David Jones
The biggest hazard to an orderly shutdown is that you terminal session
goes when the network is shut off, leaving your system in a partially
shutdown state.
"$SYSMAN SHUTDOWN NODE /minutes=..." (appending /auto/save as needed).
That's another thing that Unix got right big time.
I routinely reboot Linux servers from a SSH session to the server and
never have to worry about this.
I think that at some point that was fixed on VMS.
What was "fixed" in VMS? I do not remember anything that was fixed that
has any bearing on the issues with running SHUTDOWN.COM from an
interactive telnet or ssh session. Just do not do that. And it is easy
to avoid.
Some of this shutdown "design" did get fixed. Changes related to the
DECnet terminal session shutdown in antiquity, and later with that
weirdly-named SYSHUTDWN_0010.COM from VMS831H1I_MANAGE-V0200 ECO and
later. Prolly a few other places. Some of this still needs work. This
whole area is messy. q.v. this discussion, among some of the more
inured OpenVMS users around. This should work, without requiring
special knowledge or knowledge of magical sequences.

Startups, shutdowns, installations and upgrades and patches, product
licensing, these are among the longstanding areas of OpenVMS that are
not shining examples of what is a very expensive product.

These areas should just work. And the fact that ~forty years on, the
widely-used shutdown procedure is not perceived as working by default?

SYSMAN was an attempt to fix some of these issues, but then SYSMAN
seemingly hasn't been looked at or integrated with or worked on in
~twenty years, and little else has adopted or integrated SYSMAN.

Again, these are basic functions of any modern operating system. These
operating system requests should just work. Without needing to know
different sequences or workarounds or variants. The default and most
common tooling should work. And yes, I too use these workarounds.

TL;DR: This is OpenVMS, and we hate new users. "Just do not do that" is
our mantra.
--
Pure Personal Opinion | HoffmanLabs LLC
Jan-Erik Söderholm
2020-12-29 09:32:53 UTC
Permalink
Post by Phillip Helbig (undress to reply)
Post by Simon Clubley
Post by David Jones
The biggest hazard to an orderly shutdown is that you terminal session
goes when the network is shut off, leaving your system in a partially
shutdown state.
"$SYSMAN SHUTDOWN NODE /minutes=..." (appending /auto/save as needed).
That's another thing that Unix got right big time.
I routinely reboot Linux servers from a SSH session to the server and
never have to worry about this.
I think that at some point that was fixed on VMS.
What was "fixed" in VMS? I do not remember anything that was fixed that
has any bearing on the issues with running SHUTDOWN.COM from an
interactive telnet or ssh session. Just do not do that. And it is easy to
avoid.
Some of this shutdown "design" did get fixed.......
OK. Back on track, what was "fixed" around the issues with a lost
terminal session when doing a shutdown using a telnet or ssh session?
Phillip Helbig (undress to reply)
2020-12-29 13:34:30 UTC
Permalink
Post by Jan-Erik Söderholm
OK. Back on track, what was "fixed" around the issues with a lost
terminal session when doing a shutdown using a telnet or ssh session?
If I recall correctly, the current process was taken off the list of
processes to be killed.
Jan-Erik Söderholm
2020-12-29 14:19:30 UTC
Permalink
Post by Phillip Helbig (undress to reply)
Post by Jan-Erik Söderholm
OK. Back on track, what was "fixed" around the issues with a lost
terminal session when doing a shutdown using a telnet or ssh session?
If I recall correctly, the current process was taken off the list of
processes to be killed.
OK. But the problem was (is?) that the TCPIP communication is lost,
not that the process was killed (even if the lost network link
might indirectly cause that).

I has for a very long time been possible to shut down using a LAT
connection (since LAT stays up longer then TCPIP), so that process
"fix" must also have been a very long time ago.

Anyway, the supplied SHUTDOWN.COM routine could very well be changed
into a detached shutdown, so that everyone gets happy. Or you just
add that 10 lines of DCL code and you can be happy anyway.
Stephen Hoffman
2020-12-30 19:27:26 UTC
Permalink
Post by Jan-Erik Söderholm
Some of this shutdown "design" did get fixed.......
OK. Back on track, what was "fixed" around the issues with a lost
terminal session when doing a shutdown using a telnet or ssh session?
SHUTDOWN used to fail with DECnet network terminal sessions, similar to
what is happening now with IP.

DECnet network terminal sessions also once failed with the DST time
change, but that too was fixed. But I digress.

Fixes related SHUTDOWN initiated from IP network terminal sessions?
None. This mess has largely been ignored.

The experienced users know the workarounds. The inexperienced and
incautious get to learn or re-learn the lessons.

OpenVMS suffers many lingering effects of decisions around IP
networking from decades ago.

And the effects of decisions around investments, with few focused
toward usability of installations and upgrades, startup, shutdown,
licensing, docs, and such.

Embedded systems yes, but how many other general-purpose operating
systems still have optional IP networking and not integrated?

TL;DR: OpenVMS can't reliably shut down using default tooling and IP
network terminal sessions, some forty years on.
--
Pure Personal Opinion | HoffmanLabs LLC
Jan-Erik Söderholm
2020-12-30 23:39:35 UTC
Permalink
OpenVMS can't reliably shut down using default tooling...
Sure it can. It is just a 10 lines a DCL script needed.
Craig A. Berry
2020-12-30 23:56:38 UTC
Permalink
Post by Jan-Erik Söderholm
OpenVMS can't reliably shut down using default tooling...
Sure it can. It is just a 10 lines a DCL script needed.
If that. I have routinely shut down multiple different VMS systems over
a period of years from IP-connected terminal sessions using both
SYS$SYSTEM:SHUTDOWN.COM and MCR SYSMAN SHUTDOWN NODE. The only time I
have ever seen a problem with doing so was when I forgot what I was
doing and logged out of the terminal session immediately after
initiating the shutdown. Otherwise the shutdown (and, if requested,
restart or power off) sequence seems to know what it needs to do to
complete.

Now, maybe I am a blind person who routinely steps off the curb into the
street and have just never happened to do so when there was a car
coming. Or maybe the state of the VMS shutdown code is not quite as
derelict as many believe it to be based on decades-old memories of what
used to happen.
Stephen Hoffman
2020-12-31 01:09:22 UTC
Permalink
Post by Jan-Erik Söderholm
OpenVMS can't reliably shut down using default tooling...
Sure it can. It is just a 10 lines a DCL script needed.
You view that ten-line procedure as a solution, and I view that 10-line
procedure as a workaround, and—for new users—as an unpleasant surprise.

I view this less about technical capabilities—that ten-line procedure,
SYSMAN, etc—and more about new-user empathy, and about least-surprise
designs and behaviors.

I'd prefer the provided tooling just work. The sorts of fit and finish
details and consistency that OpenVMS was once well known for. Without
needing custom procedures.

I'm usually logged into the iLO console when shutting down, or using
SYSMAN, or using some local variation of your ten-line procedure.

Remotely-installing and remotely-administering an OpenVMS server
("hosting") without iLO, DRAC, Minicom, terminal server, or analogous
remote console access has long been painful, unfortunately.

Now if telnet and ssh did get this mess fixed, that's great. Given I'm
usually accessing via iLO, I haven't been inclined to test for this bug
in a number of years.
--
Pure Personal Opinion | HoffmanLabs LLC
Jan-Erik Söderholm
2020-12-28 12:46:29 UTC
Permalink
Post by Simon Clubley
Post by David Jones
The biggest hazard to an orderly shutdown is that you terminal session goes when the network is shut off, leaving your system in a partially shutdown state.
That's another thing that Unix got right big time.
I routinely reboot Linux servers from a SSH session to the server
and never have to worry about this.
Simon.
As I have always done for VMS servers. I do not see what
Unix "got right" here that is different from VMS.

As long as you do not run SHUTDOWN.COM interactivily
from a TCPIP based termninal session, you are fine,
but that is easy to avoid.
Simon Clubley
2020-12-28 14:00:13 UTC
Permalink
Post by Jan-Erik Söderholm
Post by Simon Clubley
Post by David Jones
The biggest hazard to an orderly shutdown is that you terminal session goes when the network is shut off, leaving your system in a partially shutdown state.
That's another thing that Unix got right big time.
I routinely reboot Linux servers from a SSH session to the server
and never have to worry about this.
As I have always done for VMS servers. I do not see what
Unix "got right" here that is different from VMS.
Shutdown or reboot on Unix consists of sending a message to the
system via a command and then the system takes care of it from there.

On Unix, after the initial shutdown or reboot request is sent by the
user, no shutdown commands whatever are issued within the context of
the session requesting the shutdown or reboot.

VMS has a number of good and unique features, even now, but the
shutdown/reboot architecture and especially the system startup
architecture is far superior in Unix than it is in VMS.
Post by Jan-Erik Söderholm
As long as you do not run SHUTDOWN.COM interactivily
from a TCPIP based termninal session, you are fine,
but that is easy to avoid.
But in a properly designed system, that simply should not be a concern.

Simon.
--
Simon Clubley, ***@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.
Jan-Erik Söderholm
2020-12-28 14:34:26 UTC
Permalink
Post by Simon Clubley
Post by Jan-Erik Söderholm
Post by Simon Clubley
Post by David Jones
The biggest hazard to an orderly shutdown is that you terminal session goes when the network is shut off, leaving your system in a partially shutdown state.
That's another thing that Unix got right big time.
I routinely reboot Linux servers from a SSH session to the server
and never have to worry about this.
As I have always done for VMS servers. I do not see what
Unix "got right" here that is different from VMS.
Shutdown or reboot on Unix consists of sending a message to the
system via a command and then the system takes care of it from there.
Yes, what I just described on our VMS systems.
Post by Simon Clubley
On Unix, after the initial shutdown or reboot request is sent by the
user, no shutdown commands whatever are issued within the context of
the session requesting the shutdown or reboot.
Yes, same here.
Post by Simon Clubley
VMS has a number of good and unique features, even now, but the
shutdown/reboot architecture and especially the system startup
architecture is far superior in Unix than it is in VMS.
The popularity of Unix has nothing to do with good design.
Post by Simon Clubley
Post by Jan-Erik Söderholm
As long as you do not run SHUTDOWN.COM interactivily
from a TCPIP based termninal session, you are fine,
but that is easy to avoid.
But in a properly designed system, that simply should not be a concern.
Simon.
I would not say that our systems are properly designed, but shutdown
or reboot are not of any concern, in our systems.

I really do not understand why you feel urged to become so upset
over less then 10 lines of DCL to get what is requested.
Chris Townley
2020-12-28 10:09:59 UTC
Permalink
Post by David Jones
Post by ***@rlgsc.com
The latest installment of The OpenVMS Consultant has been posted.
OpenVMS STARTUP.COM is far more than a tool for controlling system startup. It can also be used to accomplish a phased Shutdown of a complex environment.
See http://www.rlgsc.com/blog/openvms-consultant/shutdown-using-startup.html
The biggest hazard to an orderly shutdown is that you terminal session goes when the network is shut off, leaving your system in a partially shutdown state.
That is a good idea. I had this problem at work on development VAX and
Alpha, where the serial console terminals barely worked, so we had to
shutdown etc from terminal sessions (LAT or TCP/IP)

Now, at home I will use this on my physical alpha - no need on the
virtual ones - they have a console courtesy of Putty

Chris
geze...@rlgsc.com
2020-12-28 12:15:40 UTC
Permalink
Post by Chris Townley
Post by David Jones
Post by ***@rlgsc.com
The latest installment of The OpenVMS Consultant has been posted.
OpenVMS STARTUP.COM is far more than a tool for controlling system startup. It can also be used to accomplish a phased Shutdown of a complex environment.
See http://www.rlgsc.com/blog/openvms-consultant/shutdown-using-startup.html
The biggest hazard to an orderly shutdown is that you terminal session goes when the network is shut off, leaving your system in a partially shutdown state.
That is a good idea. I had this problem at work on development VAX and
Alpha, where the serial console terminals barely worked, so we had to
shutdown etc from terminal sessions (LAT or TCP/IP)
Now, at home I will use this on my physical alpha - no need on the
virtual ones - they have a console courtesy of Putty
Chris
Chris,

Quite. Console access is less of an issue on Itanium and x64, where there is always access through the console subsystem.

An alternative approach on VAX/Alpha is to not shutdown the network service, but shutdown individual services.

- Bob Gezelter, http://www.rlgsc.com
Jan-Erik Söderholm
2020-12-28 12:51:41 UTC
Permalink
Post by ***@rlgsc.com
Post by Chris Townley
Post by David Jones
Post by ***@rlgsc.com
The latest installment of The OpenVMS Consultant has been posted.
OpenVMS STARTUP.COM is far more than a tool for controlling system startup. It can also be used to accomplish a phased Shutdown of a complex environment.
See http://www.rlgsc.com/blog/openvms-consultant/shutdown-using-startup.html
The biggest hazard to an orderly shutdown is that you terminal session goes when the network is shut off, leaving your system in a partially shutdown state.
That is a good idea. I had this problem at work on development VAX and
Alpha, where the serial console terminals barely worked, so we had to
shutdown etc from terminal sessions (LAT or TCP/IP)
Now, at home I will use this on my physical alpha - no need on the
virtual ones - they have a console courtesy of Putty
Chris
Chris,
Quite. Console access is less of an issue on Itanium and x64, where there is always access through the console subsystem.
An alternative approach on VAX/Alpha is to not shutdown the network service, but shutdown individual services.
- Bob Gezelter, http://www.rlgsc.com
Weird discussion... I have never had any issues with a shutdown
or a reboot from a remote (telnet or ssh) session at all. As long
as you do not run SHUTDOWN.COM interactively.

We have a small COM file called REBOOT.COM:

$ type sys$manager:reboot.com
$IF F$MODE().NES."OTHER"
$THEN
$ RUN /DET /INP='F$ENVIRONMENT("PROCEDURE")' -
/OUT=OPA0: /PRIV=ALL /USER=SYSTEM -
SYS$SYSTEM:LOGINOUT
$ELSE
$ SET PROC/PRIV=ALL
$ ASS OPA0: SYS$COMMAND
$ @SYS$SYSTEM:SHUTDOWN 0 SHUTDOWN YES YES LATER YES NONE
$ WAIT 08:00
$ENDIF

Just run it and it will run a detached reboot. A minor update
to do a shutdown without automatic reboot of course.

And if you like:

$ sh sym reboot
REBOOT == "@sys$manager:reboot.com"
$

Another way, if you have multiple hosts and have LAT running, is
to connect from another system using SET HOST/LAT. LAT is up long
enough to have the system shutting down automatically even after
that you have lost the terminal connection.

This is on Alpha and yes, we also have access to the consoles.
Chris Townley
2020-12-28 13:15:03 UTC
Permalink
Post by ***@rlgsc.com
Post by Chris Townley
Post by David Jones
Post by ***@rlgsc.com
The latest installment of The OpenVMS Consultant has been posted.
OpenVMS STARTUP.COM is far more than a tool for controlling system startup. It can also be used to accomplish a phased Shutdown of a complex environment.
See http://www.rlgsc.com/blog/openvms-consultant/shutdown-using-startup.html
The biggest hazard to an orderly shutdown is that you terminal session goes when the network is shut off, leaving your system in a partially shutdown state.
That is a good idea. I had this problem at work on development VAX and
Alpha, where the serial console terminals barely worked, so we had to
shutdown etc from terminal sessions (LAT or TCP/IP)
Now, at home I will use this on my physical alpha - no need on the
virtual ones - they have a console courtesy of Putty
Chris
Chris,
Quite. Console access is less of an issue on Itanium and x64, where there is always access through the console subsystem.
An alternative approach on VAX/Alpha is to not shutdown the network service, but shutdown individual services.
- Bob Gezelter, http://www.rlgsc.com
I still remember fondly the VAX8530 or 8550 consoles - I believe they
were repurposed PDPs with their 3 modes of operation.

Chris
Hans Bachner
2020-12-28 21:06:59 UTC
Permalink
Post by Chris Townley
Post by ***@rlgsc.com
Post by Chris Townley
Post by David Jones
Post by ***@rlgsc.com
The latest installment of The OpenVMS Consultant has been posted.
OpenVMS STARTUP.COM is far more than a tool for controlling system
startup. It can also be used to accomplish a phased Shutdown of a
complex environment.
See
http://www.rlgsc.com/blog/openvms-consultant/shutdown-using-startup.html
The biggest hazard to an orderly shutdown is that you terminal
session goes when the network is shut off, leaving your system in a
partially shutdown state.
"$SYSMAN SHUTDOWN NODE /minutes=..." (appending /auto/save as needed).
That is a good idea. I had this problem at work on development VAX and
Alpha, where the serial console terminals barely worked, so we had to
shutdown etc from terminal sessions (LAT or TCP/IP)
Now, at home I will use this on my physical alpha - no need on the
virtual ones - they have a console courtesy of Putty
Chris
Chris,
Quite. Console access is less of an issue on Itanium and x64, where
there is always access through the console subsystem.
An alternative approach on VAX/Alpha is to not shutdown the network
service, but shutdown individual services.
- Bob Gezelter, http://www.rlgsc.com
I still remember fondly the VAX8530 or 8550 consoles - I believe they
were repurposed PDPs with their 3 modes of operation.
There were various incarnations of PDP-11 technology used as consoles
for various VAX models.

The VAX-11 /780 had an LSI-11 as a console.

On the other end, some of the VAX 8xxx models had a DEC Pro-350 as the
console subsystem. Some other stuff between these two examples...

Hans.
Jan-Erik Söderholm
2020-12-28 12:50:23 UTC
Permalink
Post by Chris Townley
Post by David Jones
Post by ***@rlgsc.com
The latest installment of The OpenVMS Consultant has been posted.
OpenVMS STARTUP.COM is far more than a tool for controlling system
startup. It can also be used to accomplish a phased Shutdown of a
complex environment.
See
http://www.rlgsc.com/blog/openvms-consultant/shutdown-using-startup.html
The biggest hazard to an orderly shutdown is that you terminal session
goes when the network is shut off, leaving your system in a partially
shutdown state.
SHUTDOWN NODE /minutes=..." (appending /auto/save as needed).
That is a good idea. I had this problem at work on development VAX and
Alpha, where the serial console terminals barely worked, so we had to
shutdown etc from terminal sessions (LAT or TCP/IP)
LAT has always been fine. LAT stays active long enough for the shutdown
process to go inte automatic mode with no requirement of a terminal.
Any TCPIP terminal is a problem, if you run SHUTDOWN.COM interactively.
Post by Chris Townley
Now, at home I will use this on my physical alpha - no need on the virtual
ones - they have a console courtesy of Putty
Chris
Loading...