Vom OpenVMS-Fachberater Bob Gezelter
Prozesse sind ein Grundbaustein von OpenVMS. Die Erzeugung von Prozessen ist der Ausgangspunkt aller OpenVMS-Aktivität, seien es interaktive Sessions, Batchjobs, Netzwerkserver oder eigenständige ("detached") Prozesse. Obwohl ein Prozess ohne einen CLI-Kontext erzeugt werden kann, ist es verbreiteter, einen Prozess mit einem CLI-Kontext zu erzeugen. Meist ist die CLI der OpenVMS-Standard: DCL.
Wenn ein Prozess mit einem DCL-Kontext geschaffen wird, ist das ausgeführte Image SYS$SYSTEM:LOGINOUT.EXE. Als Teil seiner Verarbeitung übersetzt LOGINOUT den systemweiten logischen Namen SYS$SYLOGIN. Die durch diesen logischen Namen benannte Kommandodatei wird dann aufgerufen. In der Regel wird SYS$SYLOGIN zu SYS$MANAGER:SYLOGIN.COM übersetzt (der Einfachkeit halber im Weiteren SYLOGIN). SYLOGIN wird vor jeder vom Benutzer geschriebenen LOGIN.COM ausgeführt.
SYLOGIN bietet eine ungemein mächtige Möglichkeit, in den Login-Prozess einzugreifen. Mit SYLOGIN können zusätzliche Validierungen über diejenigen von SYS$SYSTEM:LOGINOUT.EXE hinaus ausgeführt werden. Auch können anlagenspezifische Standards durchgesetzt werden. Dagegen wird Code in der Benutzer-Loginprozedur (normalerweise SYS$LOGIN:LOGIN.COM) nach dem Belieben des Benutzers ausgeführt.
Aus dieser Mächtigkeit erwächst Verantwortung. Viele Produkte, sowohl von Hewlett-Packard als auch von Drittherstellern oder Inhouse entwickelte Applikationen erzeugen Batchjobs, Netzwerkserver und eigenständige Prozesse. Der normale Fluß der Prozess-Erzeugung mit DCL als Kommandointerpreter beinhaltet den Aufruf von SYLOGIN. Unbeabsichtigte Aktionen in SYLOGIN können damit die Systemverfügbarkeit beeinträchtigen.
Einträge in SYLOGIN fallen in drei allgemeine Kategorien:
- zusätzliche Prozessvalidierung
- Definitionen von anlagen- und gruppenspezifischen logischen Namen
- anlagenweite Kommandodefinitionen entweder durch DCL-Symbole oder SET COMMAND
Änderungen an SYLOGIN in jeder dieser drei Kategorien haben Einfluß auf die gesamte Anlage. Beim Ändern von SYLOGIN ist es allzu einfach, durch einen Fehler die Systemoperation negativ zu beeinflussen.
Prozesskontexte entwickeln sich von dem Zeitpunkt ihrer Entstehung an:
Basis-OpenVMS-Prozess ($CREPRC)
CLI-Initialisierung (SYS$SYLOGIN)
benutzer-spezifischer Login (User1)
benutzer-spezifischer Login (User2)
Eigenständiger Prozess ohne CLI
Insbesondere die eigenständigen Prozesse haben sich in eine interessante Richtung entwickelt. In der Vergangenheit haben viele Produkte und Applikationen eigenständige Prozesse ohne CLI-Kontext erzeugt. Daher wurde DCL niemals aufgerufen. In den vergangenen Jahren wurde die Nützlichkeit des Standard-CLI-Kontexts und besonders DCLs erkannt, und eine wachsende Anzahl von Produkten und Applikationen erzeugen eigenständige Prozesse jetzt mit einem DCL-Kontext.
Diese Verschiebung im Herangehen hat das Potential geschaffen, Probleme mit Änderungen der Benutzerumgebung aufzudecken. Was wie eine harmlose Änderung des Standard-DCL-Kommandosets aussieht (z.B. das Kommando DELETE durch Definition des Symbols DEL*ETE mit dem Wert "DELETE/LOG" zu ändern, so dass es automatisch mitloggt) wird jetzt informelle Meldungen bei Verwendung des Kommandos DELETE/SYMBOL ausgeben (DELETE/SYMBOL unterstützt den Qualifier /LOG nicht). Solche Änderungen stören den Betrieb, egal, ob sie in die Umgebung als DCL-Symbole oder mit SET COMMAND eingefügt werden.
Änderungen können unerwartete, weit verbreitete Auswirkungen haben. Applikationen und lokal entwickelter Code können Fehlfunktionen zeigen, nicht einmal wegen einer Änderung in der Verarbeitung von SYLOGIN, sondern weil ein Produkt oder eine Anwendung ihre Verwendung von eigenständigen Prozessen auf die Benutzung von DCL umstellt, und sie damit seit langem bestehenden, lokalen Änderungen der Standard-OpenVMS-Umgebung mit SYLOGIN aussetzt.
Zugrunde liegende Annahmen sind schädlich, insbesondere grundlegende Annahmen über die Umgebung des Basis-OpenVMS-Prozesskontext. Auftretende Schwierigkeiten sind oft nicht das direkte Ergebnis einer kürzlichen Änderung, sondern das Zusammenwirken mehrerer verschiedener Änderungen, von denen jede einzelne harmlos scheint, die aber in unvorhergesehener Weise interagieren. Es ist dieser "unter dem Radar"-Aspekt, der zu den schwierigsten Situationen führt.
In kommenden Kolumnen werde ich sicherere Methoden beleuchten, mit denen man Änderungen an der Standard- oder einer Gruppen-Umgebung umsetzt, und welche Methoden und Techniken man einsetzen kann, um Probleme zu identifizieren, die durch die Ausführung von SYLOGIN auftreten.
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
|