vom OpenVMS-Fachberater Bob Gezelter
Winzige Kommandodateien verstopfen viel zu viele Verzeichnisse. Das ist eine Entwicklung, die ich sowohl bei meinen eigenen Projekt-Verzeichnissen als auch denen von Kollegen und Klienten sehe. Diese Unmenge von Kommandodateien implementiert sehr unterschiedliche Aufgaben. Einige Aufgaben erfordern Logging, andere laufen zu lange, als dass sie interaktiv ausgeführt werden könnten. Das wirft die Frage auf: Wie kann - mit normalen OpenVMS-Mitteln - die Notwendigkeit für diese Dateien eliminiert werden?
Schaut man sich diese Dateien an, dann sieht man, dass viele davon nur aus zwei Zeilen bestehen: einem einzelnen DCL-Kommando, dem ein SET DEFAULT vorausgeht, oft in das Verzeichnis, das die Kommandodatei enthält. Gelegentlich findet man noch eine dritte Zeile: EXIT. Die Kommandos sind typischerweise einfache DCL-Kommandos mit potentiell langen Laufzeiten (z.B. ANALYZE/DISK_STRUCTURE/READ_CHECK, DELETE/ERASE, PURGE, ZIP). Gibt es einen besseren Weg, diese Kollektion von Aufgaben zu verwalten? Gibt es einen Ansatz oder eine Technik, welche die Notwendigkeit für diese Menge an kleinen Dateien eliminieren kann? Das ist die Geburtstunde des Konzepts von Batchjobs mit einzelnen Kommandos.
OpenVMS ist bekannt für die Leistungsfähigkeit seiner Architektur. Die Konzepte und Bestandteile von OpenVMS bieten ein solides Fundament für neuen Techniken, ohne dieses Fundament zu verändern. Die grundlegenden Bestandteile sind gut entworfen und robust. Dies erlaubt es, mehr mit weniger zu erreichen, was bei vielen anderen Betriebsystem-Plattformen nicht der Fall ist. Das Laufenlassen von einzelnen Kommandos in Batch-Queues ist so ein Fall: zwei einfache DCL-Prozeduren können die Notwendigkeit von hunderten Dateien eliminieren. Wie es oft der Fall ist, ermöglicht ein solides Verständnis der Grundlagen eine solche Erweiterung.
In OpenVMS kann man auf viele Arten Programme laufen lassen, abgesehen vom Eintippen eines Kommandos am DCL-Prompt. Programme können auch ausgeführt werden
- aus einer Kommandodatei
- aus einer Kommandodatei, die in einer Batchqueue läuft
- als eigener (detached) Prozess (Privilegen erforderlich), oder
- als Subprozess mit dem DCL-Kommando SPAWN.
Jede dieser Techniken hat sowohl Stärken als auch Schwächen. Mit SPAWN können einzelne Kommandos ausgeführt werden, aber eine Unterbrechung des Vater-Prozesses (etwa durch eine Netzwerkstörung oder Ctrl-Y) wird den Subprozess abbrechen. Einige dieser Probleme können durch Änderungen der Einstellungen behoben werden. Störungen in der Kommunikation können durch den Einsatz von virtuellen Terminal reduziert werden; mit /INPUT=NL: kann verhindert werden, dass Ctrl-Y Subprozesse abbricht. Jedoch können nicht auf jedem System virtuelle Terminal eingerichtet werden, und manche Ereignisse kann man nicht umgehen. Virtuelle Terminals bringen auch nichts, wenn die Verbindung nicht innerhalb des Wiederverbindungs-Intervalls wiederhergestellt wird.
Allein stehende (detached) Prozesse erfordern erhöhten Privilegien (z.B. DETACH). Normale Benutzer erhalten aber keine erhöhten Privilegien. Wenn das System crasht, verschwinden allein stehende Prozesse. Auch existiert kein eingebauter Mechanismus zum Neustarten allein stehender Prozesse.
Batchjobs sind völlig unabhängig von dem Prozess, der sie in die Batchqueue stellt. Wenn der Systembetrieb unterbrochen wird, können nicht vollendete Batchjobs automatisch neu gestartet werden - entweder wenn das System wieder läuft, oder auf einem anderen Mitglied des OpenVMS-Clusters. Allerdings verarbeitet der Batch-Prozessor Kommandodateien, nicht einzelne Kommandos. Daher ist es üblich, dass ein Benutzer oder Systemadministrator eine große Sammlung von extrem kurzen Kommandodateien für diverse Aufgaben anhäuft. Das erzeugt Dateiensalat, etwa als elektronische Version einer Küchenschublade - dort ein bestimmtes Werkzeug zu finden ist eine Herausforderung.
Die Fähigkeit, einzelne Kommandos als Batchjobs zu starten, ohne die Notwendigkeit der Erzeugung einer temporären Kommandodatei, würde dieses Durcheinander beseitigen. OpenVMS bietet uns die Werkzeuge, um genau diese Fähigkeit zu schaffen.
Ein neues Denkmodell ist unnötig. Das existierende Batchqueue-Modell ist dafür gut geeignet. Die bestehenden Batchqueue-Fähigkeiten können als Fundament für Lauf-Modus einzelner Kommandos diesen. Eigentlich ist das Ergebnis ein SUBMIT-Kommando mit einem literalen Operanden. Solche ein Kommando erinnert an die literalen Operanden in den Befehlssätzen vieler Maschinen, einschließlich PDP-11, VAX und Alpha. Mit dieser Fähigkeit kann eine lange laufende Operation (z.B. ein DELETE/ERASE von tausenden großer Dateien) an eine Batchqueue gesendet werden, ohne die Notwendigkeit für eine kleine Kommandodatei.
Diese neue Fähigkeit kann vollständig durch die Ergänzung der bestehenden Batch-Fähigkeiten durch zwei kleine DCL-Prozeduren. SUBMIT wurde ausführlich getestet und wird vollständig unterstützt. Normalerweise werden Batchjobs durch das SUBMITten einer Kommandodatei gestartet. Es ist jedoch auch möglich, ein DCL-Kommando in einer Parameterliste an einen Batchprozess zu übergeben. Als Teil der Parameterliste könnte auch das aktuelle Standard-Verzeichnis an den Batchjob übergeben werden. Eine generische Kommandoprozedur übernimmt diese Parameter und erzeugt damit einen Batchprozess. Diese umhüllende Prozedur holt sich die nötige Information aus den Parametern und führt das eigentliche Komamndo aus. Mit dieser Vorgehensweise kann ein Kommando als Batchjob ausgeführt werden, ohne dass eine eigene Kommandodatei geschrieben werden muss.
Zwei Prozeduren werden benötigt: eine, die den Batchjob erzeugt, und eine, die das eigentliche Kommando ausführt. Einige der grundlegenden Qualifier von SUBMIT (etwa /AFTER, /LOG_FILE, /NAME, /QUEUE und /USER) sind nützlich und können ohne Schwierigkeiten unterstützt werden.
Der Ansatz ist nicht nur theoretisch; er wurde in zwei Demo-Kommandodateien implementiert: SUBMIT_SINGLECOMMANDJOB.COM und RUN_SINGLECOMMANDJOB.COM (beide Dateien sind auf dem Website meiner Firma im Demonstrationsbereich unter www.rlgsc.com/demonstrations/single-command-batch-jobs.html verfügbar).
SUBMIT erlaubt dem Benutzer acht benutzer-spezifische Parameter. Diese werden dem Batchjob durch den Queue-Manager beim Start des Batchjobs übergeben. SUBMIT_SINGLECOMMANDJOB.COM und RUN_SINGLECOMMANDJOB.COM verwenden die ersten beiden Parameter, um das aktuelle Standardverzeichnis und das eigentliche Kommando zu übergeben. Die übrigen Parameter stehen für andere Zwecke zur Verfügung. Mit anderen Worten: P1 enthält die Benutzerumgebung, und P2 enthält das Bathc-Kommando.
Diese Herangehensweise ist völlig sicher. Keine erhöhten Privilegien werden bei der Benutzung dieser Kommandodateien benötigt. Die Dateien können von jedem benutzt werden, der ausreichende Provilegien zum Starten eines Batchjobs hat. Daher gibt es keine zusätzlichen Sicherheits-Konsequenzen. Die Prozeduren sind total sicher, um sie von Studenten in einer Bildungseinrichtung einsetzen zu lassen. Wenn gewünscht, können Systemadministratoren oder Teamleiter diese Dateien in Projekt- oder System-Verzeichnissen für den allgemeinen Gebrauch installieren. Normale OpenVMS-Benutzer mit Zugriff auf DCL und Batchqueues können diese Dateien aus ihren eigenen Verzeichnissen heraus einsetzen. Es gibt keine Gefahren.
Einzelne Kommandos als Batchjobs sind ein weiteres Beispiel dafür, dass OpenVMS sowohl Systemadministratoren als auch gewöhnlichen Benutzern mehr Fähigkeiten bietet, als auf den ersten Blick sichtbar sind. Es ist ein weiteres Beispiel für die inhärente Mächtigkeit und Erweiterbarkeit der OpenVMS-Architektur.
Wie immer begrüße ich Leserkorrespondenz zu den Inhalten dieser Kolumne. Ich bin zu erreichen über den Website meiner Firma unter http://www.rlgsc.com.
Ãœber den Autor:
Robert Gezelter, CDP, CSA, CSE, Software Consultant, hat mehr als 30 Jahre internationale Erfahrung mit der Fachberatung im privaten und öffentlichen Sektor. Er ist regelmäßiger Gastredner auf technischen Konferenzen weltweit, einschließlich des HP Technology Forums. 2004 hat die IEEE Computer Society Mr. Gezelter in ihr Distinguished Visitors Program berufen, das Redner auf Veranstaltungen von IEEE-Verbänden in ganz Nordamerika vermittelt. Außerdem hat er zahlreiche technische Artikel und Buchkapitel verfasst, einschließlich zweier Kapitel in dem kürzlich erschienenen Computer Security Handbook, 5. Auflage.
Kürzlich hat er begonnen, Ruminations - An IT Blog über IT-Themen zu schreiben, die nicht mit OpenVMS in Verbindung stehen.
Die Tätigkeit seiner Firma betont detaillierte technische Expertise in den Bereichen Computer-Architekturen, Betriebssysteme, Netzwerke, Sicherheit, APIs und verwandte Themen. Mr. Gezelter hat mit OpenVMS seit der ersten Release von VAX/VMS 1977 gearbeitet.
Seine Kundenstamm umfasst sowohl kleinere Firmen wie auch Firmen in den Fortune 10, lokal, national und international, mit Arbeitsbereichen, die von individuellen Telefon-Fragen bis zu größeren Projekten reichen.
Im Web ist er über den Website seiner Firma unter http://www.rlgsc.com zu erreichen.
Original auf www.openvms.org
Original auf Bob Gezelters Site
|