Shutdown mit STARTUP.COM

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.

 

Neue Phase für Startup

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.

AUTOGEN

Das AUTOGEN Utility ist eine Command-Procedure, mit man einerseits in kontrollierter Art und Weise Systemparameter also auch Filegrösen für Page, Swap und Dumpfiles verändern kann. Das Autogen Utility befindet sich in SYS$UPDATE. Bei der Neuinstallation von OpenVMS werden die ersten System-Parameter immer automatisch mit dem AUTOGEN Utility erzeugt.

Das Autogen Utility kann:

  • Feedback Informationen über den Resourcenverbrauch aus dem laufenden System persistieren (AGEN$FEEDBACK.DAT)
  • Devices konfigurieren
  • Systemparameter aufgrund der gewünschten Zielwerte und den Feedbackinfromationen anpassen
  • Die Grössen von PAGEFILE, SWAPFILE und DUMPFILE an die aktuelle Konfiguration anpassen.

In folgenden Szenarien sollten Sie unbedingt auf das AUTOGEN Utility setzen:

  • Während einer Neuinstallation oder eines Release-Upgrades
  • Wenn sich die Workload auf dem System signifikant ändert
  • Wenn neue Layered-Products installiert werden.
  • Wenn Images mit /SHARED installiert werden sollen. Für Shareable Images sind passende Werte in GBLSECTIONS und GBLPAGES wichtig. Diese werden am besten mit AUTOGEN adjustiert. Wenn neue Softwareprodukte neue SHAREABLE Images liefern, ist meistens auch eine Anpassung dieser Werte nötig.

Aufruf und Parameter

Das Autogen Utility durchläuft immer eine Reihe von Phasen. Beginn- und End-Phase werden dabei als Parameter mitgegeben.

$ @SYS$UPDATE:AUTOGEN <START-PHASE> <END-PHASE> <MODUS>
  • P1 - START-PHASE
  • P2 - END-PHASE
  • P3 - MODUS - kann entfallen oder einen der folgenden Werte aufweisen:
    • FEEDBACK - verwendet das abgespeicherte Resourcen FEEDBACK aus AGEN$FEEDBACK.DAT
    • NOFEEDBACK - die Werte werden nur aufgrund der Setup-Files erzeugt
    • CHECK_FEEDBACK - Feedback Information werden verwendet, wenn diese gültig ist.

Die AUTOGEN-Phasen

Phase Beschreibung Start
Phase
Input
Files
Output
Files
Privilegien
SAVPARAMS Feedback Informationen persistieren JA - AGEN$FEEDBACK.DAT -
GETDATA Sammelt alle Informationen für die Berechnung JA MODPARAMS.DAT PARAMS.DAT SYSPRV,CMKRNL
GENPARAMS Erzeugt neue Systemparameter
und Installed-Images-List
JA PARAMS.DAT SETPARAMS.DAT SYSPRV,OPER
TESTFILES Liefert die empfohlenen Grössen der Files NEIN - AGEN$PARAMS.REPORT SYSPRV,CMKRNL
GENFILES Erzeugt neue Files mit den empfohlenen Grössen NEIN - - SYSPRV,CMKRNL
SETPARAMS Erzeugt neue Systemparameter files (je nach
Architektur).
JA SETPARAMS.DAT

VAXVMSSYS.PAR
VAXVMSSYS.OLD

ALPHAVMSSYS.PAR
ALPHAVMSSYS.PAR

IA64VMSSYS.OLD
IA64VMSSYS.PAR

SYSPRV
SHUTDOWN Führt einen Shutdown durch JA - - SYSPRV,SETPRV
REBOOT Führt einen Restart durch JA - - SYSPRV,SETPRV

 

 

Startup mit SYSMAN erweitern

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.