| Benutzer | | Gäste online: 1
Benutzer online: 0
|
 | |
|
Hinweis: Links zu OpenVMS.org funktionieren nicht. Der Website ist offline. |
|
| Der OpenVMS-Fachberater: DCL-Dateizugriff | | Der OpenVMS-Fachberater - 08-Feb-2011 03:53 UTC | von Bob Gezelter
Das Erzeugen, Lesen und Schreiben von Dateien sind alltägliche Programmieraufgaben, besonders in DCL und anderen Skriptsprachen. Während sich die Syntax und Semantik von Dateioperationen zwischen den Programmiersprachen unterscheiden, haben wenige dieser Unterschiede Konsequenzen; die meisten sind nur syntaktisch. Zu erkennen, welche Unterschiede wirklich signifikant sind, hat oft seine Feinheiten. Im Fall von OpenVMS DCL kann die genaue Syntax des OPEN-Kommandos Anlaß zu Fehleinschätzungen geben. Diese syntaktischen Annahmen können manches Mal Verwirrung stiften, besonders aus der Sichtweise der Programmierung in anderen Umgebungen. Das muss nicht zwingend der Fall sein. DCLs Dateibehandlung ist genauso mächtig wie in fast jeder Programmiersprache der dritten Generation, sobald man die Syntax und die Implikationen versteht.
Ein bedeutender Unterschied besteht darin, wie eine Datei identifiziert wird. Konventionelle Programmiersprache unter OpenVMS verwenden entweder RMS-Kanäle oder Datenstrukturen, die ihrerseits auf RMS-Kanäle verweisen (z.B. FORTRAN-Unit-Nummern oder C-Dateihandle oder -Zeiger). Im Gegensatz dazu greifen DCL-I/O-Anweisungen auf Dateien über logische Namen zu, die zuvor in der Prozeßtabelle mit der Datei verknüpft worden sind. Diese Implementierung bietet dieselben Features wie in anderen Programmiersprachen, manche mechanischen Details können sich aber scheinbar unterscheiden. Dies kann zusammen mit DCLs Symbolsubstitution und seiner interpretativen Natur zu Verwirrung führen; wenn man es jedoch im richtigen Kontext versteht, bieten sie Implementierungs-Chancen für die Eingeweihten. Schauen wir uns das folgende einigermaßen triviale Beispiel an:
$ OPEN/WRITE OUTPUT_FILE X.TMP
$ WRITE OUTPUT_FILE "Written from main procedure"
$ CLOSE OUTPUT_FILE
Das Beispiel schreibt eine einzige Zeile in eine Datei - ein einfache Aufgabe. Etwas komplizierter wird es, wenn wir das Beispiel um eine Subroutine erweitern, z.B.:
$ OPEN/WRITE OUTPUT_FILE X.TMP
$ CALL ASUBROUTINE "Written for main procedure by ASUBROUTINE"
$ CLOSE OUTPUT_FILE
$ ASUBROUTINE: SUBROUTINE
$ STRING = P1
$ WRITE OUTPUT_FILE 'STRING'
$ EXIT
$ ENDSUBROUTINE
Auch dieses zweite Beispiel enthält keine Komplikationen. Wenn wir es jedoch ein wenig erweitern, zeigen sich Komplexitäten, etwa:
$ OPEN/WRITE OUTPUT_FILE X.TMP
$ OPEN/WRITE LISTING_FILE X.TMP
$ CALL ASUBROUTINE "Written for main procedure by ASUBROUTINE"
$ CALL BSUBROUTINE "Written for main procedure by BSUBROUTINE"
$ CLOSE OUTPUT_FILE
$ ASUBROUTINE: SUBROUTINE
$ STRING = P1
$ WRITE OUTPUT_FILE 'STRING'
$ EXIT
$ ENDSUBROUTINE
$ BSUBROUTINE: SUBROUTINE
$ STRING = P1
$ WRITE LISTING_FILE 'STRING'
$ EXIT
$ ENDSUBROUTINE
ASUBROUTINE und BSUBROUTINE sind nahezu identisch. Der einzige Unterschied besteht darin, in welche Datei geschrieben wird. In einer umfangreichen Kommandoprozedur könnte eine Subroutine mit verschiedenen Dateien arbeiten müssen. Ein ähnlicher Fall tritt auf, wenn eine einzelne Subroutine als externe Datei aufgerufen wird (z.B. $ @LIBRARY:ASUBROUTINE). Wie behandelt man die Tatsache, dass die gewünschten Ausgabedateien unterschiedliche Namen haben können, je nachdem, welche Prozedur die Bibliotheksroutine aufruft?
Es gibt mehrere Wege, mit dieser Anforderung umzugehen. Eine Möglichkeit besteht in der Verwendung einer Umleitung von logischen Namen, eine andere benutzt Symbolsubstitution. (Ein Satz Beispiel-Prozeduren, die beide Techniken demonstrieren, steht auf dem Website meiner Firma unter http://www.rlgsc.com/demonstrations/openvms-dcl-fileaccess-logicals.html zum Download zur Verfügung).
Der logische Name, der in einer READ- oder WRITE-Anweisung verwendet wird, wird iterativ übersetzt. Man kann diese Iteration nutzen, um eine Ebene der Umleitung zu schaffen; einen logischen Namen, der auf denjenigen logischen Namen verweist, an den die Datei gebunden ist. Als Beispiel:
$ OPEN/WRITE OUTPUT_FILE X.TMP
$ OPEN/WRITE LISTING_FILE X.TMP
$ ASSIGN OUTPUT_FILE KUMQUAT_OUTPUT_FILE
$ CALL KUMQUAT "Written for main procedure by KUMQUAT"
$ ASSIGN LISTING_FILE KUMQUAT_OUTPUT_FILE
$ CALL KUMQUAT "Written for main procedure by KUMQUAT"
$ CLOSE OUTPUT_FILE
$ KUMQUAT: SUBROUTINE
$ STRING = P1
$ WRITE KUMQUAT_OUTPUT_FILE 'STRING'
$ EXIT
$ ENDSUBROUTINE
Die oben gezeigte Methode bietet diverse Vorteile. Wenn der logische Name KUMQUAT_OUTPUT_FILE am Beginn von KUMQUAT nicht definiert ist, kann automatische eine Standarddatei zugewiesen werden; ist er definiert, wird diejenige Datei verwendet, auf die er verweist. Das hilft dabei, komplexe Kommandoprozeduren zu schreiben und zu debuggen, die oft aus mehreren Dateien bestehen.
Ein alternativer Ansatz besteht darin, die erforderliche Information per DCL-Symbol an die Subroutine zu übergeben, und in READ- und WRITE-Anweisungen mit Symbolsubstitution zu arbeiten. Die Symbole können in einem weiter außen liegenden Geltungsbereich definiert werden, oder sie können als formale Parameter an die Subroutine übergeben werden, wie in:
$ OPEN/WRITE OUTPUT_FILE X.TMP
$ KIWI_OUTPUT_FILE = "OUTPUT_FILE"
$ CALL KIWI "Written for main procedure by KIWI"
$ CLOSE OUTPUT_FILE
$ KIWI: SUBROUTINE
$ STRING = P1
$ WRITE 'KIWI_OUTPUT_FILE' 'STRING'
$ EXIT
$ ENDSUBROUTINE
Es gibt noch andere Wege, Symbolsubstitution einzusetzen, mit größerer Flexibilität und etwas besserer Struktur. Eine solche Technik ist, den Namen des logischen Namens als Teil der Parameterliste der Subroutine einzusetzen, wie in:
$ OPEN/WRITE OUTPUT_FILE X.TMP
$ CALL KIWI "OUTPUT_FILE" "Written for main procedure by KIWI"
$ CLOSE OUTPUT_FILE
$ KIWI: SUBROUTINE
$ OUTPUT_FILE = P1
$ STRING = P2
$ WRITE 'OUTPUT_FILE' 'STRING'
$ EXIT
$ ENDSUBROUTINE
Diese Beispiele zeigten mehrere verschiedene Wege, wie der logische Name einer in einer weiter außen liegenden DCL-Prozedur geöffneten Datei an eine weiter innen liegende DCL-Prozudur kommuniziert werden kann. Jede der Techniken hat ihre Stärken und Schwächen, das allgemeine Prinzip des Übergebens der Identität einer bereits geöffneten Datei hat aber viele Vorteile.
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 und des Connect OpenVMS Bootcamps.
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)