Natürlich kann man ein System immer herunterfahren, indem man die Stromzufuhr unterbricht oder bestenfalls noch den Ein/Aus Schalter drückt. Das Resultat eines solchen unkontrollierten Endes kann aber durchaus unerfreulich sein. Korrupte Filesysteme, halb abgeschlossene Verarbeitungen, nicht auffindbare Datensätze. Die Liste liesse sich endlos erweitern.

Die Vorteile eines geregelten Shutdown liegen also auf der Hand.

Hintereinander oder gleichzeitig?

Natürlich lässt sich der Shutdown fein säuberlich in einem Script seriell abarbeiten, OpenVMS stellt dazu auch die Prozedur SYSHUTDWN.COM zur Verfügung, in der wir alle Appliktionen sauber beenden können. Aber geht es nicht vielleicht ein bisschen schneller und vielleicht gleichzeitiger?

Robert Gezelter hat in seinem Whitepaper "OpenVMS STARTUP: Underappreciated Flexibility"  ausführlich beschrieben, dass der OpenVMS Startup ein modulares und erweiterbares Werkzeug darstellt, mit dem eine OpenVMS Instanz gestartet wird. STARTUP.COM ist demzufolge nicht mehr als ein etwas erweiterter Dispatcher für durchzuführende Arbeitsschritte. Warum also das Rad neu erfinden, wenn doch ein fertiges Werkzeug zur Verfügung steht.

Neue Phasen für Startup

Die Phasenbeschreibung entnehmen sowohl STARTUP.COM als auch SYSMAN der Textdatei, auf die mit dem Logical VMS$PHASES gezeigt wird. Also erzeugen wir uns eine neue Datei SYS$MANAGER:SHUTDOWN_PHASES.DAT

SHUTDOWNPH1
SHUTDOWNPH2

Shuidown konfigurieren

$ DEFINE VMS$PHASES SYS$MANAGER:SHUTDOWN_PHASES.DAT
$ mcr sysman
SYSMAN> startup set database startup$startup_layered
SYSMAN> startup add file SHUTDOWN_CAMPUS_APPL1.COM /phase=SHUTDOWNPH1/mode=spawn
SYSMAN> startup add file SHUTDOWN_CAMPUS_APPL2.COM /phase=SHUTDOWNPH1/mode=spawn
SYSMAN> startup add file SHUTDOWN_CAMPUS_APPL3.COM /phase=SHUTDOWNPH1/mode=spawn
SYSMAN> startup add file SHUTDOWN_CAMPUS_FINAL.COM /phase=SHUTDOWNPH2/mode=spawn
SYSMAN> ^Z

Damit haben wir nun die Schritte für unseren Shutdown definiert.

SYS$MANAGER:SYSHUTDWN.COM

Damit der System-Shutdown nun auch noch unsere Schritte ausführt, passen wir die Site-Shutdown-Procedure ein wenig an:

$ DEFINE/SYSTEM/EXEC VMS$PHASES SYS$MANAGER:SHUTDOWN_PHASES.DAT
$ SPAWN @SYS$SYSTEM:STARTUP

Der System-Shutdown wird nun die Dispatching Funktionalitäten von STARTUP.COM nutzen, um alle usnere Applikationen zu stoppen.

Danksagung

An dieser Stelle herzlichen Dank an Bob Gezelter für die Idee. Den Link zu seinem Artikel und seinen Ausführungen zum OpenVMS Startup finden Sie weiter unten.

Robert Gezelter hat in seinem Whitepaper "OpenVMS STARTUP: Underappreciated Flexibility"  ausführlich beschrieben, dass der OpenVMS Startup ein modulares und erweiterbares Werkzeug darstellt, mit dem eine OpenVMS Instanz gestartet wird.

Der OpenVMS Startup besteht aus 9 Phasen (INITIAL, DEVICES, PRECONFIG, CONFIG, BASEENVIRON, LPBEGIN, LPMAIN, LPBETA, and END). Zwei dieser Phasen werden von OpenVMS selbst nicht vewendet. Während der anderen 7 Phasen durchläuft die Startup-Sequence von OpenVMS zumindest 25 Prozeduren, die mit der der OpenVMS Distribution bereitgestellt werden.

Natürlich können alle Startup-Schritte von Layered-Products oder anderen site-spezifischen Startup-Sequenzen seriell in einem Step einer Phase durchlaufen werden. Oft aber gibt es Schritte, die unhabhängig von einander und somit auch gleichzeitig durchgeführt werden können, um die Startup-Zeit zu reduzieren und die vohandenen Ressourcen besser auszunutzen.

SYS$STARTUP:VMS$PHASES.DAT

In dieser Text-Datei werden die Phasen des OpenVMS Startup verwaltet:

INITIAL
DEVICES
PRECONFIG
CONFIG
BASEENVIRON
LPBEGIN
LPMAIN
LPBETA
END

Die Reihenfolge der Phasen dürfen naturgemäss nicht verändert werden, wir können uns aber eine eigene Phase LPCAMPUS, dazudefinieren:

INITIAL
DEVICES
PRECONFIG
CONFIG
BASEENVIRON
LPBEGIN
LPMAIN
LPCAMPUS
LPBETA
END

Diese Phase kann dann mit dem SYSMAN Utility mit Schritten versorgt werden.

SYS$STARTUP:VMS$LAYERED.DAT

In dieser Datei sucht (die standardmässig leer mitgeliefert wird), sucht der Startup nach zusätzlichen Startup-Schritten. Mit dem SYSMAN Utility können wir dort Einträge vornehmen:

$ mcr sysman
SYSMAN> startup set database startup$startup_layered
SYSMAN> startup add file campus1.com /phase=lpcampus/mode=spawn
SYSMAN> ^Z

Beim nächsten System-Startup wird OpenVMS Startup nun versuchen, die Prozedur CAMPUS1.COM als Subprozess auszuführen.

Robert Gezelter hat in seinem Whitepaper "OpenVMS STARTUP: Underappreciated Flexibility"  ausführlich beschrieben, dass der OpenVMS Startup ein modulares und erweiterbares Werkzeug darstellt, mit dem eine OpenVMS Instanz gestartet wird.

Der OpenVMS Startup besteht aus 9 Phasen (INITIAL, DEVICES, PRECONFIG, CONFIG, BASEENVIRON, LPBEGIN, LPMAIN, LPBETA, and END). Zwei dieser Phasen werden von OpenVMS selbst nicht vewendet. Während der anderen 7 Phasen durchläuft die Startup-Sequence von OpenVMS zumindest 25 Prozeduren, die mit der der OpenVMS Distribution bereitgestellt werden.

SYS$MANAGER:CAMPUS_STARTUP.COM

Beispielhaft legen wir uns unsere Startup-Prozedur an:

$!
$ SET NOON
$ stdrv$say "Startup CAMPUS Startup procedure"
$!
$ DEFINE/SYSTEM/EXEC CAMPUS$HOME "DSA100:[CAMPUS.HOME}"
$!
$ stdrv$say "CAMPUS startup finished"
$ EXIT

Diese Prozedur soll nun vom OpenVMS Startup ausgeführt werden:

$ mcr sysman
SYSMAN> startup set database startup$startup_layered
SYSMAN> startup add file campus_startup.com /phase=lpmain/mode=spawn
SYSMAN> ^Z

Beim nächsten System-Startup wird OpenVMS Startup nun versuchen, die Prozedur CAMPUS_STARTUP.COM als Subprozess auszuführen.