| Benutzer | | Gäste online: 14
Benutzer online: 0
|
 | |
| DCL-Umleitungen und -Callbacks | | Der OpenVMS-Fachberater - 02-Jan-2011 00:00 UTC | vom OpenVMS-Fachberater Bob Gezelter
Selten sieht man DCL-Kommandoprozeduren, die allein stehen. Wesentlich häufiger findet man DCL-Prozeduren, die Teil von größeren Zusammenstellungen sind, Sammlungen von schon existierenden und zweckgebundenen Werkzeugen, die zusammenwirken, um ein gemeinsames Ziel zu erreichen. Aufrufe von DCL-Prozeduren eines niedrigeren Levels und Callbacks in benutzerdefinierter Verarbeitung sind ein fester Bestandteil beim Zusammenfügen dieser Ensembles. Diese setzen ganz naürlich Entwickler- und Wartungsressourcen wirksam ein.
Ensemble-Applikationen sind wesentlich effizienter, als jede Anwendung für sich zu schreiben. Die Wiederverwendung von Code ist nicht nur eine Kostenfrage. Durch die Benutzung bestehender Komponenten wird auch sichergestellt, dass die Kern-Verarbeitung konsistent ist. Mit derselben Argumentation sieht man, dass der Aufruf einer externen Prozedur wesentlich sicherer ist als das Einfügen des Prozedurtextes in jede DCL-Datei.
In anderen Fällen muss ein generelles Verarbeitungs-Rahmenwerk für spezifische Anforderungen erweitert werden. Verschiedene Erweiterungen sind oft inkompatibel zueinander. Callbacks ermöglichen es, Basis-Rahmenwerken effektiv auf Arten zu erweitern, die ansonsten inkompatibel wären, indem sie gewissermaßen eine Struktur implementieren, die einer Basisklasse einer objekt-orientierten Sprache ähnelt. In DCL können sowohl konventionelle Aufrufe von Dienst-Routinen als auch Callbacks implementiert werden, diese benutzer-spezifischen Ergänzungen, die nicht im Voraus bekannt sind.
Die Implementierung beider Techniken in DCL ist unkompliziert. Eine Sammlung kleiner Beispiele dafür, wie dies bewerkstelligt werden kann, steht zum Download bereit.
Aufrufe bekannter Routinen scheinen einfach, es gibt aber viele Möglichkeiten, auf Probleme zu stoßen. DCL-Prozeduren verwenden oft eine Vielfalt von Techniken, um andere Prozeduren, Programme und Datendateien zu lokalisieren. Einige dieser Ansätze haben negative Seiteneffekte, z.B. beziehen sich viele Prozeduren explizit auf ihr eigenes Verzeichnis (etwa DISK$USERS:[TOOLS.FRED]). Eine solche Prozedur in ein anderes Verzeichnis zu verschieben endet katastrophal, und erfordert eine Menge Änderungen am Text. Dabei bringt DCL die Fähigkeiten mit, um Gefahren dieses Typs zu reduzieren, oder sogar zu eliminieren.
Eine weitere Technik ist es, sich auf den Ort der DCL-Dateien mittels eines logischen Namens zu beziehen. Während das effektiv ist, erfordert es eine riesige, immerzu wachsende Anzahl von logischen Namen. Das verstopft die Tabellen von logischen Namen und kompliziert die Wartung.
In viele Fällen ist es effektiver, den Bezug zu dem Verzeichnis, welches die Datei enthält, mit der lexikalischen Funktion F$ENVIRONMENT herzustellen. F$ENVIRONMENT("PROCEDURE") gibt den vollständigen Dateinamen der gerade ausgeführten DCL-Prozedur zurück. Sich auf Dateien im gleichen Verzeichnis wie die aktuelle Prozedur zu beziehen wird durch die Verwendung einer Kombination von F$ENVIRONMENT und F$PARSE einfach (F$PARSE war Gegenstand einer früheren Kolumne: Alchemie mit Dateinamen - Einsetzen von Standardwerten in F$PARSE). In den herunterladbaren Beispielen verwendet OPENVMS-CALLBACK-EXAMPLE1.COM diese Technik, um OPENVMS-CALLBACK-EXAMPLE2.COM zu lokalisieren.
Diese Technik ist der Verwendung von logischen Namen zur Bestimmung des Orts einer ausgeführten Kommandoprozedur vorzuziehen. F$PARSE kann dann benutzt werden, um einen bekannten Teil-Dateinamen (z.B SUBPROCEDURE) in einen voll-qualifizierten Dateinamen zu integrieren. Dies ist eine Syntax mit einiger Macht. Ob diese Macht dem Benutzer an die Hand gegeben werden soll, ist eine Design- und Implementations-Entscheidung. Durch Weglassen des Dateityps (etwa SUBPROCEDURE statt SUBPROCEDURE.COM) erlaubt man das Überschreiben des Dateinamens durch einen logischen Namen. Dies mag während der Testphase wünschenswert sein, kann aber im produktiven Einsatz eine Gefahr darstellen. Es gibt kein definitives "richtig" oder "falsch", aber die Unterschiede sollten klar sein. Daher sind - nach einmaligem Zugriff auf den extern definierten Einsprungpunkt - Verweise, die auf dem Namen der ausgeführten Prozedur basieren, selbst-bezüglich; ein logischer Name zur Lokalisierung von Dateien, die bei der Kommandoprozedur gespeichert sind, ist nicht notwendig. Das hat mehrere Vorteile:
- es eliminiert die Notwendigkeit der Erzeugung und Wartung eine logischen Namens;
- die Prozedur und ihre Sub-Prozeduren können ohne Änderung auf ein anderes Gerät und/oder in ein anderes Verzeichnis verschoben werden;
- es gibt keine Notwendigkeit, vor der Ausführung per SET DEFAULT in das Verzeichnis mit der Kommandoprozedur zu wechseln; und
- die Erzeugung von Debug-Kopien der Kommandoprozedur in anderen Verzeichnissen ist ohne Änderungen an der DCL-Datei möglich.
Callback sind ein dazu komplementärer Ansatz. Werkzeuge so zu entwerfen, dass sie für alle Fälle gerüstet sind, ist extrem schwierig. Es ist schwer genug, alle gegenwärtig bekannten Fälle abzudecken; vorausschauend zu arbeiten ist wesentlich problematischer. Wenn zukünftige Möglichkeiten einbezogen werden sollen, wachsen die Anforderungen ins Unmögliche.
Es gibt jedoch eine effektive Antwort. Anstatt Werkzeuge für alle möglichen Anwendungen zu entwerfen, ist es wesentlich effektiver und weniger komplex, einen Mechanismus bereitzustellen, um die Funktionalität zu erweitern. Callbacks sind ein lange bekanntes Entwurfsmuster, eine Technik, die auf dieses Problem zugeschnitten ist: Werkzeuge über ihre grundlegenden Fähigkeiten hinaus zu erweitern. Die Standard-Funktionalität kann z.B. durch einen Null-Callback implementiert werden (d.h. einen Callback, der immer Erfolg oder Fehler zurückliefert, je nach Anwendungsfall). Ausführlichere Callbacks können jegliche benötigte ergänzende Verarbeitung bereitstellen, so dass die Funktionalität eines Werkzeugs nahezu unbegrenzt erweitert werden kann. Anstatt ein bestimmtes Problem zu lösen, wird aus einem Werkzeug, das Callbacks bereitstellt, ein Rahmenwerk zum Lösen von ganzen Klassen von Problemen.
Callbacks sind nicht auf kompilierende oder interpretierende Sprachen beschränkt. Prozeduren in DCL und anderen Skriptsprachen können ebenfalls Callbacks implementieren, wenn die Möglichkeit besteht, den Namen einer in Zukunft aufzurufenden Prozedur zu übergeben.
Es gibt mehrere Methode, in DCL Callbacks zu implementieren. Die am wenigsten flexible Methode ist, über logische Namen eine Pfadliste bereitzustellen. Dieser Ansatz sollte allen OpenVMS-Systemmanagern bekannt vorkommen. Er wird in OpenVMS als Grundlage der STARTUP-Verarbeitung genutzt. Der logische Name SYS$STARTUP ist eine Pfadliste, die diese Hierarchie implementiert. Knoten-spezifische Versionen von Dateien werden im geeigneten knoten-spezifischen (genauer: spezifisch für die Boot-Root) Verzeichnis abgelegt, wo sie bevorzugt gegenüber den im Cluster gemeinsam genutzten Versionen (die im SYS$COMMON-Baum gespeichert werden) ausgeführt werden. Eigentlich bietet das im Cluster gemeinsam genutzte Verzeichnis also einen Standard-Callback, der auf Knoten-Basis überschrieben werden kann.
Obwohl diese Technik sehr mächtig ist, sind doch die Namen der Callbacks fixiert. Dies begrenzt die Fähigkeiten des Mechanismus. Anstatt die fixierte Struktur von genau benannten Funktionen zu nutzen ist es wesentlich kraftvoller, den Namen eines Funktions-Callbacks zur spezifischen Verarbeitung zu übergeben. Das ist eine Standard-Technik, die in den meisten Programmiersprachen implementiert ist. Im Kontext einer DCL-Prozedur erfordert diese Technik, dass der Dateiname des Callbacks dem aufgerufenen Werkzeug gestellt wird.
OPENVMS-CALLBACK-EXAMPLE1.COM demonstriert auch das Übergeben eines benannten Callbacks an eine Prozedur. Oben habe ich beschrieben, wie OPENVMS-CALLBACK-EXAMPLE1.COM die Datei OPENVMS-CALLBACK-EXAMPLE2.COM in seinem eigenen Verzeichnis aufruft. Außerdem nimmt OPENVMS-CALLBACK-EXAMPLE1.COM auch einen Parameter: den Namen einer DCL-Prozedur, die während der Verarbeitung aufgerufen wird. Standardmäßig ist der Ort dieses Callbacks das derzeitige Standard-Verzeichnis. Da die Implementation die lexikalische Funktion F$PARSE nutzt, kann der Ort der Datei mit den üblichen OpenVMS-Konventionen überschrieben werden.
Das Beispielprogramm akzeptiert auch einen Null-Callback. Derzeit gibt das Beispiel in diesem Fall eine Fehlermeldung aus; ebenso hätte es diesen speziellen Callback einfach überspringen können.
Aus diesen zugegebenermaßen simplen Beispielen ist direkt ersichtlich, wie eine bessere Implementation von externen DCL-Aufrufen - seien es Aufrufe von definierten Dienst-Prozeduren oder Callbacks - mittels Verarbeitungs-Erweiterungen eine mächtige Technik ist, welche die Felxibilität steigern und die Fehleranfälligkeit durch Duplizierung und fortgesetzte Wartung verringern kann.
Am Ende des Jahres 2010 wünsche ich allen meinen Lesern ein glückliches, gesundes und sicheres Neujahr und ein gesundes und erfolgreiches 2011.
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 im Computer Security Handbook, 5. Auflage.
Außerdem veröffentlicht er Ruminations - An IT Blog über IT-Themen, die nicht unbedingt 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
| | Links zum Thema: | Version zum Drucken | |
|
|
|
![[OpenVMS Swoosh]](/images/OpenVMS_VSI_72x88.png)
de.OpenVMS.org![[Future Forward]](/images/swoosh160w.jpg)