Der OpenVMS-Fachberater: Logische Namen (Teil 2) Der OpenVMS-Fachberater - 18-Okt-2002 00:00 UTC von Bob Gezelter Der vorhergehende Artikel (Teil 1) untersuchte die Grundlagen der logischen Namen in OpenVMS. Diese Folge beleuchtet, wie Applikationen logische Namen ge- und missbrauchen können. Logische Namen werden implizit über die Record Management Services (RMS) verwendet, oder explizit über den Systemdienst $TRNLNM und die entsprechenden Routinen der Laufzeitbibliothek. Logische Namen können fast überall dort auftauchen, wo es um Dateinamen geht; daher können logische Namen potentiell jedes Öffnen einer Datei auf einem OpenVMS-System beeinflussen. Durch die Kombination von iterativen Übersetzungen mit unterschiedlichen Benutzer-Kontexten können logische Namen sehr wirksam eingesetzt werden. Logische Namen können aber auch missbraucht werden, was zu schlechter Performance und Ressourcenverschwendung führt. Während aktuelle Systeme oft mehr Ressourcen als frühere Systeme haben, ist doch auch die Arbeitslast heutzutage höher, mit mehr Benutzern und komplexeren und zahlreicheren Aufgaben. Ich wurde einmal bei einem Klienten gebeten, mir ein Problem mit der "Login-Performance" anzuschauen. Ich fand heraus, dass es sich um mehrere zusammenhängende Probleme handelte, von denen ich einige in späteren Artikeln beschreiben werde. Die "Login-Performance" aber war ziemlich überschaubar, und hing mit einer ineffezienten Struktur von logischen Namen zusammen. Das erste Problem war, dass beim Login jedes Benutzers eine gemeinsame Prozedur ausgeführt wurde, die mehr als 40 logische Namen definierte. Für nahezu jeden Benutzer wurden die genau gleichen logischen Namen definiert. In diesem speziellen Fall gehörten die betroffenen Benutzer zu mehreren UIC-Gruppen, und die spezifische Applikation war der Hauptzweck des Systems (wäre die Benutzergemeinde inhomogener gewesen, hätte ich eine ausgeklügeltere Lösung mit dem gleichen Effekt entwickelt, ohne den Overhead von mehr logischen Namen für jeden Benutzer). Die Login-Kommandoprozedur jedes Benutzers rief eine gemeinsame Kommandoprozedur auf, die eine Vielzahl von Anweisungen der Art $ ASSIGN string logischer_name enthielt, jede für einen anderen logischen Namen der Applikation. In einigen Fällen wurden lexikalische Funktionen verwendet, um Teile des Äquivalenz-Strings zu generieren, die sich auf den Verzeichnispfad bezogen. Der erste Schritt hätte die Erzeugung von Gruppen-Tabellen sein können (die während des Systemstarts erzeugt und gefüllt werden), aber dieser spezielle Fall erlaubte einen anderen Ansatz. Ich änderte als erstes die gemeinsame Prozedur, so dass die logischen Namen in der Systemtabelle definiert wurden, und rief die Prozedur während des Systemstart auf; das eliminierte die Definition der logischen Namen während des Benutzer-Logins. Dies verkürzte die Login-Zeit beträchtlich. Wir waren aber noch nicht fertig. Nicht alle Benutzer-Gruppen verwendeten die exakt gleichen logischen Namen. Einige Gruppen benutzten parallele Strukturen von logischen Namen wie folgt (ein Name soll als Beispiel genügen, ohne Einschränkung der Allgemeinheit): Community Name Äquivalenz-String Gruppe A DATABASE DISK$DUCK1:[PRODUCTION.DATA]DATABASE.FIL Gruppe B DATABASE DISK$DUCK1:[TESTING.DATA]DATABASE.FIL Gruppe C DATABASE DISK$DUCK1:[SUBPRODUCTION.DATA]DATABASE.FIL Indem wir iterative Übersetzungen benutzten, waren wir in der Lage, alle Gruppen auf die Verwendung eines gemeinsamen logischen Namens zu normalisieren: Community Name Äquivalenz-String Gruppen A, B, C DATABASE DATADISK:[DATA]DATABASE.FIL mit unterschiedlichen Definitionen von DATADISK in den Gruppentabellen: Community Name Äquivalenz-String Gruppe A DATADISK DISK$DUCK1:[PRODUCTION.] Gruppe B DATADISK DISK$DUCK1:[TESTING.] Gruppe C DATADISK DISK$DUCK1:[SUBPRODUCTION.] Dadurch hing eine Vielzahl von Übersetzungen von den Einzelheiten des Werts des logischen Namens DATADISK ab, der in der Gruppentabelle enthalten war. Die Resultate des Kommandos DIRECTORY zeigen den Effekt der iterativen Übersetzung: Community Tatsächlicher Dateiname für Gruppe A DISK$DUCK1:[PRODUCTION.][DATA]DATABASE.FIL für Gruppe B DISK$DUCK1:[TESTING.][DATA]DATABASE.FIL für Gruppe C DISK$DUCK1:[SUBPRODUCTION.][DATA]DATABASE.FIL Für einen einzigen logischen Namen (DATABASE) sind die Ergebnisse rein semantisch. Der Erfolg liegt in der Eliminierung der Dubletten der logischen Namen pro Benutzer, und der resultierenden Uberführung zu einer Definition pro Aufruf der Applikation. Um es mit einem dem verstorbenen Senator Dirksen zugeschriebenen Zitat zu sagen: "Eine Million hier, eine Million dort, früher oder später ist es richtig Geld." Wenn Sie mitgezählt haben: es gibt jetzt eine einzige Kopie der applikationsspezifischen logischen Namen, plus einen logischen Namen in jeder Gruppentabelle zur Festlegung des Verzeichnisbaums - eine beträchtliche Ersparnis, was Speicher, Login-Overhead, Overhead beim Aufruf von SPAWN und Komplexität angeht. Tatsächlich ist dies einer der einfacheren Anwendungsfälle von logischen Namen. Im folgenden Artikel werden wir uns ein komplexeres Beispiel anschauen. Der nächste Artikel in dieser Reihe von Robert Gezelter: Logische Namen (Teil 3) Der vorhergehende Artikel in dieser Reihe von Robert Gezelter: Logische Namen (Teil 1) Über den Autor: Robert Gezelter ist der Gründer der Consulting-Firma, die seinen Namen trägt (www.rlgsc.com). 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 1978 gearbeitet. Seine Kundenstamm umfasst sowohl kleinere Firmen wie auch Firmen in den Fortune 10, lokal, national und international. Er ist per Email zu errreichen unter gezelter@rlgsc.com. Original auf www.openvms.org