Der OpenVMS-Fachberater: DCL-Symbole, von Anfang an Der OpenVMS-Fachberater - 02-Mar-2009 14:58 UTC Von Robert Gezelter Für alle, die nicht mit der DCL-Symbolsubstitution in OpenVMS vertraut sind, ist sie eine Quelle der Verwirrung. Dieses mächtige DCL-Feature wird wegen Mißverständnissen gemieden. Das ist bedauerlich, weil Symbol-Substitution die Entwicklungszeit dramatisch verkürzen und die Kosten einer fortlaufenden Wartung reduzieren kann. Die Tatsache, dass DCL-Symbolsubstitution für einige Zwecke das Gleiche tut wie logische Namen, trägt zugegebenermaßen zu der Verwirrung bei. Indes, obwohl logische Namen und DCL-Symbole bei einigen Gelegenheiten für die gleichen Dinge eingesetzt werden können, sind sie sehr verschiedene Mechanismen. Eine frühere Reihe von Artikeln dieser Kolumne beschäftigt sich mit den Grundlagen von logischen Namen ("Der OpenVMS-Fachberater: Logische Namen (Teil 1)" war der erste Artikel dieser Reihe). Logische Namen werden implizit von RMS und anderen OpenVMS-Systemdiensten benutzt. Sie können explizit von Usermode-Programmen mittels Systemdiensten und Aufrufen der Laufzeit-Bibliothek definiert und abgerufen werden, und explizit aus DCL heraus mit der lexikalischen Funktion F$TRNLNM verwendet werden. Einige Tabellen von logischen Namen (z.B. LNM$SYSTEM, LNM$GROUP und LNM$JOB) sind außerhalb des Geltungsbereichs eines individuellen Prozesses ansprechbar. Im Gegensatz dazu sind Symbole reine Geschöpfe von DCL und sind durch die Implementierung von DCL auf bestimmte Semantiken und Verwendungen beschränkt. Sie sind auf den Kontext eines einzelnen Prozesses eingeschränkt, obwohl per Default sowohl lokale als auch globale Symbole in Subprozesse kopiert werden, die mit dem SPAWN-Kommando oder der RTL-Routine LIB$SPAWN aufgerufen werden. Als einfaches Beispiel schauen Sie sich das folgende geläufige DCL-Kommando an:         $ directory/size/date *.lis Dieses Kommando erzeugt eine Liste aller Dateien im aktuellen Verzeichnis, die einen Dateityp .lis haben, zusammen mit der Größe und dem Erstellungsdatum jeder Datei. Das Kommando ist nicht sehr komplex, enthält aber 25 Zeichen. Sogar mit dem OpenVMS DCL-Feature, Abkürzungen für Verben und Qualifier zuzulassen, solange die Eindeutigkeit gewahrt bleibt, müssen 17 Zeichen getippt werden. Dieses Beispiel zeigt nur einen einfachen Fall. Es ist nicht ungewöhnlich, Kommandos mit mehr als 80 Zeichen zu haben (was ein bekanntes Problem über alle Plattformen hinweg ist; viele Werkzeuge haben viele verschiedene Parameter). Die einfache Lösung dafür in OpenVMS ist, DCL-Symbole zur Definition von Abkürzungen zu verwenden. Das beseitigt die Notwendigkeit, immer das komplette Kommando eintippen zu müssen:         $ dsd :== directory/size/date Wenn dieses Symbol einmal in unserem Prozess definiert ist, setzt DCL automatisch den vollen Wert ein, wenn das Symbol als erstes Element in einer DCL-Anweisung auftaucht. Damit muss man wesentlich weniger tippen, nämlich:         $ dsd *.lis In diesem einfachen Fall eines Kommandos mit sehr einfachen Parametern funktioniert das recht gut. Bei komplexeren Fällen mit aufwendigerer Verarbeitung benötigt man oft DCL-Symbole in einer weiterentwickelten Weise, um benötigte Zeichenketten auseinanderzunehmen und zusammenzubauen. Kommando-Abkürzungen sind nur die einfacheste Verwendung eines Features mit wesentlich größeren Fähigkeiten. Die Nutzung dieser Fähigkeiten erfordert die Verwendung einer DCL-Kommandodatei. Lassen Sie uns also starten, indem wir eine kleine Kommandodatei schreiben, die den Dateityp (ohne die zugehörige Interpunktion) übernimmt, und alle Datei im aktuellen Verzeichnis mit diesem Dateityp auflistet.         $! DCL-Programm zur Anzeige von Verzeichnisinhalten         $! Autor:  Robert Gezelter , 1-Mar-2009         $ FILETYPE = P1         $ DIRECTORY/SIZE/DATE *.'FILETYPE'         $ EXIT $STATUS Zugegeben, dieser Fünfzeiler ist einfach gestrickt. Er ist aber ausreichend, um dieselbe Struktur wie sehr viel größere DCL-Kommandoprozeduren zu haben, sogar wenn sie aus hunderten oder tausenden von Codezeilen bestehen. Die Kommentarzeilen, welche die Datei, ihren Autor und das Erstellungsdatum ausweisen, sind das erste gemeinsame Merkmal. Oft enthalten diese Kommentare (Zeilen, die mit $! beginnen) Informationen über den Zweck, die Hintergründe und die Entwicklungsgeschichte der Kommandoprozedur. Die verbleibenden drei Anweisungen fallen in unterschiedliche Kategorien: Konfiguration, Verarbeitung und das Zurückgeben eines Status. Die Konfiguration in dieser Prozedur ist überschaubar. Sie beginnt mit der Verwendung des DCL-Features, das die Eingabezeile in einzelne, durch Whitespace (z.B. Leer- und Tabulatorzeichen) getrennte Zeichenketten zergliedert, und diese in einen vordefinierten Satz von lokalen DCL-Symbolen ablegt, die von P1 bis P8 nummeriert sind. Obwohl es für DCL einfach ist, die Parameter dort abzulegen, so sind P1 bis P8 nicht besonders aussagekräftig. Ein gebräuchlicher erster Schritt ist es, die von DCL vorbelegten Parameter in lokale Symbole zu speichern, die genau ihren Inhalt beschreiben. Die Zeile $ FILETYPE = P1 erfüllt diese Funktion in unserem Beispiel. Die eigentliche Verarbeitung findet im zweiten Kommando statt: $ DIRECTORY/SIZE/DATE *.'FILETYPE'. Hier wird eine DCL-Symbolsubstitution angezeigt, durch einen Symbolennamen, der in einfache ASCII-Anführungszeichen ("'") eingeschlossen ist. Der letzte Schritt ist, das Ergebnis der Kommandoprozedur an den zu liefern, der sie aufgerufen hat. Oft ist das der Benutzer am Kommandoprompt, es kann aber genausogut eine weitere Kommandoprozedur sein. Genauso, wie konventionelle Programme oft in einzelne Routinen aufgespalten werden, ist es üblich, interne und external DCL-Kommandoprozeduren zu haben. Das obige Beispiel ist freilich eine einfache Anwendung von Symbolen. Kommende Kolumnen werden sich mit fortgeschrittener Verwendung von DCL-Symbolen befassen. Leserfragen zur Verwendung von DCL und andere, auf OpenVMS bezogene Fragen sollten an OpenVMSConsultant (at) OpenVMS.org adressiert werden. Obwohl ich nicht versprechen kann, alle Nachrichten zu beantworten, werde ich es versuchen, wie es meine Zeit erlaubt. Der OpenVMS-Fachberater begrüßt Fragen von Lesern über OpenVMS und verwandte Technologien. Bitte senden Sie Ihre Fragen an den OpenVMS Consultant. Ü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 unter http://www.rlgsc.com zu erreichen. Original auf www.openvms.org