Shutdowns using STARTUP.COM

A system can always be shut down by a simply “hitting the switch” or stopping one or more processes. The simplicity of such an uncontrolled shutdown is belied by the effort expended to undo the resulting damage. Orderly shutdowns create far less damage.

In my experience orderly shutdowns significantly improve debugging speed. Effort expended repairing self-inflicted damage is not available for useful progress. Orderly shutdown logic is the first step in building a foundation, not a final stage frill.

Shutting down a system is no less complex than starting. Orderly shutdowns require services be quiesced, generally in the reverse sequence than that they were started, volumes dismounted, and system activity brought to a standstill. Restarts are far simpler when the system was quiesced in the correct sequence.

The standard recommended method of an orderly shutdown in OpenVMS is running SYS$SYSTEM:SHUTDOWN.COM. In turn, SHUTDOWN.COM invokes a site-localization file SYS$MANAGER:SYSHUTDWN.COM.¹ Adding sequential steps to SYSHUTDWN.COM is adequate for simple configurations. For more complex configurations, and shorter times, it is helpful to be able to execute multiple independent steps in parallel.

This description should sound familiar. In earlier installments, STARTUP was described similarly. In fact, we can re-purpose STARTUP.COM to do a database-driven shutdown sequence.

In Adding a Phase to STARTUP, I noted that SYSMAN and STARTUP.COM both use a phase list identified by logical name STARTUP$PHASES. We can take advantage of this feature to re-purpose STARTUP.COM into a general-purpose sequencer. STARTUP.COM can then be utilized to orchestrate a multi-stage, orderly shutdown in much the same manner as it orchestrates OpenVMS Startup.

First, create a command file RLGTEST.COM containing the following:

Now create seven copies of RLGTEST.COM in SYS$MANAGER under the names RLGTEST1.COM, RLGTEST2.COM, through RLGTEST7.COM.

Next, create a shutdown phase file in SYS$SPECIFIC:[SYSMGR] named VMS_SHUTDOWNPHASES.DAT containing a list of shutdown phases, for example:

Before starting SYSMAN:

Next, we add the desired files to the layered products database:

Our next step is to have SYS$MANAGER:SYSHUTDWN.COM invoke SYS$SYSTEM:STARTUP.COM with our shutdown phase list. To do this, we modify SYS$MANAGER:SYSHUTDWN.COM by adding:

When we invoke a shutdown, STARTUP.COM will execute the files we have specified, in the order specified. If a phase includes more than a single file with SPAWN execution, they will be executed in parallel.

Could we have accomplished the same result by manually editing SYS$MANAGER:SYSHUTDWN.COM? Certainly. However, accomplishing the same result requires implementing and maintaining essentially the same code which already exists in the OpenVMS Engineering-maintained STARTUP.COM and SYSMAN. “Re-inventing the wheel” is wasteful. STARTUP.COM already exists, and is easily adapted to our purposes. Using an existing tool is preferable to developing and maintaining a new set of tools. All of the capabilities used for managing STARTUP (e.g. ENABLE/DISABLE) become available for SHUTDOWN.

Notes

[1]	OpenVMS System Manager's Manual, Volume 1: Essentials, Section 4.8.3.2

References

URLs for referencing this entry

• Home
• Services
  • OpenVMS
  • Windows
  • Printers
  • PostScript
  • Architectures
  • Networks
  • Embedded Systems
• Speaking
• Upcoming Events
• TechnicalCounsel^SM News Archive
• Ruminations – An IT Blog 
• The OpenVMS Consultant 
• Presentations
• Publications
• Technology Demonstrations
• Bookstore
• Contact Us