| Benutzer | | Gäste online: 9
Benutzer online: 0
|
 | |
|
Hinweis: Links zu OpenVMS.org funktionieren nicht. Der Website ist offline. |
|
| Alchemie mit Dateinamen - Einsetzen von Standardwerten in F$PARSE | | Der OpenVMS-Fachberater - 21-Okt-2010 08:22 UTC | vom OpenVMS-Fachberater Bob Gezelter
Durchgehend einheitliche Dateitypen sind ein wohlbekanntes Feature von OpenVMS. Tatsächlich sind sie eine Designentscheidung, die OpenVMS von seinen Vorgängern geerbt hat. Quelldateien jeder Sprache haben bestimmte Dateitypen (z.B. .FOR, .C, .CXX, .COB, .PAS, .PLI, .MAR, .BAS). Andere, aus diesen Quelldateien erzeugten Dateien haben ihre eigenen bestimmten Dateitypen: .OBJ, .LIS, .EXE, .STB, .MAP, um nur einige der stadardisierten Möglichkeiten zu nennen. Die Implementierung dieser Namenskonventionen wird fälschlicherweise oft als sperrige Last empfunden; nichts könnte entfernter von der Wahrheit sein. Der OpenVMS-Systemdienst SYS$PARSE und in DCL die entsprechende lexikalische Funktion F$PARSE bieten alles Nötige für die Implementierung in einem einzigen Aufruf.
F$PARSE wird oft unterbewertet und uneffektiv verwendet. In der Regel wird F$PARSE zum Extrahieren einzelner Elemente (z.B. Knoten, Gerät, Verzeichnis, Name, Typ) aus einer gegebenen Dateibezeichnung verwendet. Das ist aber nicht die zugrundeliegende Idee von F$PARSE, es ist ein blosser Seiteneffekt. Die darunterliegende und oft ignorierte Funktionalität ist wesentlich nützlicher. Der Text der Online-Hilfe enthält einen subtilen Hinweis auf die beabsichtigte Funktionalität:
...
related-spec
Specifies a character string containing the related file specification.
The fields in the related file specification are substituted in the output string if a particular field is missing from both the filespec and default-spec arguments.
...[aus "HELP LEXICALS F$PARSE Arguments"; OpenVMS 7.3-2]
Diese Beschreibung hat sich über die Jahre wenig verändert und ist ohne Zweifel präzise. Mit allem schuldigen Respekt gegenüber den Autoren der Dokumentation: es fehlt ein Beispiel für die in Wirklichkeit beabsichtigte Verwendung der Funktion. In der Online-Hilfe (unter HELP LEXICALS F$PARSE Examples) sind beide Beispiele gleichermassen knapp, und keins beinhaltet alle drei möglichen Parameter, welche die F$PARSE-Schnittstelle vorsieht. Ohne zusätzliches eingehendes Studium der Dokumentation bleibt Benutzern die Absicht hinter F$PARSE oft verborgen.
SYS$PARSE ist der Schlüssel zur einfachen Implementierung der Standard-Verarbeitung von OpenVMS-Dateispezifikationen. F$PARSE ist lediglich die von DCL aus nutzbare Einfassung des zugrundeliegenden System-Aufrufs. Die Verarbeitung ist vollständig mit allen ihren Feinheiten:
- Einsetzen von Standardwerten für Dateitypen;
- Übersetzung von logischen Namen; und
- Erzeugung von verwandten Dateinamen für Listings, Objekten, Symboltabellen, Linker-Maps und anderen Dateien.
Kurz gesagt stellt F$PARSE/SYS$PARSE sicher, dass die Verarbeitung von Dateinamen komplett konsistent mit COPY, LINK und anderen OpenVMS-Standard-Werkzeugen ist. Es besteht keine Notwendigkeit für speziell angepasstem Code.
Dass F$PARSE dies leistet, ist kein Zufall. Es dürfte kaum zufällig sein, dass die fünf Parameter von F$PARSE genau hinreichen, um die verschiedenen Möglichkeiten abzudecken, die bei der Verarbeitung von benutzer-spezfizierten Dateinamen benötigt werden. F$PARSE ist die DCL-Schnittstelle zum darunterliegenden SYS$PARSE RMS-Einsprungpunkt; die Parameter der lexikalischen Funktion finden sich genau so beim RMS-Aufruf wieder.
Auf OpenVMS ist dieses Einsetzen von Standardwerten so fundamental, dass es oft übersehen wird. Es bildet einen roten Faden, dessen Auswirkungen in der gesamten Umgebung zu spüren sind. Der durchgehend einheitliche Gebrauch von Dateitypen erzeugt eine Art Datei-Kennung, bei der der Typ verschiedener Eingabedateien implizit in der Wahl des Werkzeugs enthalten ist. Betrachten wir das einfache Kommando FORTRAN TEST. Implizit setzt der FORTRAN-Compiler die Namen
- der Quelldatei auf TEST.FOR;
- des Compiler-Listings auf TEST.LIS (Dateityp .LIS); und
- der Objektdatei auf TEST.OBJ.
In ähnlicher Weise verarbeitet das entsprechende LINK-Kommando LINK/MAP/SYMBOL_TABLE TEST die Objektdatei TEST.OBJ und erzeugt:
- eine ausführbare Datei (TEST.EXE);
- eine Linker-Map-Datei (TEST.MAP); und
- eine Symboltabellen-Datei (TEST.STB).
Während diese zwei Beispiele das Standard-Verhalten zeigen, können die Namen, Dateitypen und Verzeichnisse der Ausgabedateien einfach dadurch überschrieben werden, indem die zusätzliche Information mit relevanten DCL-Kommando-Qualifiern mitgegeben wird (z.B. LINK/SYMBOL_TABLE=TESTDBG TEST).
Das Erzeugen von Dateinamen nach diesen Regeln mit dem erlaubten Überschreiben durch Benutzer würde auf vielen Plattformen erhebliche Investitionen in die Entwicklung, das Debuggen und die Wartung von Code erfordern. Es gäbe auch ein Risiko, oder genauer eine an Sicherheit grenzende Wahrscheinlichkeit, dass verschiedene Implementierungen diese Verarbeitung in etwas unterschiedlicher Weise durchführen würden, was Inkonsistenzen erzeugt und Benutzer verwirrt. So etwas passiert auf anderen Betriebssystem-Plattformen oft.
Auf OpenVMS schrumpft alle Verarbeitung auf einen Aufruf von F$PARSE (bzw. des darunterliegenden direkten RMS-Aufrufs SYS$PARSE) zusammen, inklusive der Verarbeitung von logischen Namen und Standardwerten. Dies erlaubt sogar dem Durchschnitts-Nutzer, OpenVMS-konforme Dateinamen-Behandlung in selbstentwickelten Prozeduren und Applikationen zu bieten, ohne zusätzliche Kosten für Implementierung oder Wartung.
Wenn in der SYS$PARSE-Verarbeitung Erweiterungen vorgenommen werden (z.B. Support für erweiterte Dateinamen unter ODS-5), stehen diese implizit in der gesamten Code-Basis zur Verfügung, und befolgen alle Standard-OpenVMS-Einstellungen (z.B. SET PROCESS/PARSE_STYLE=EXTENDED).
Die Umsetzung in der Realität ist bei weitem einfacher als die Erklärung. Betrachten wir ein einfaches Beispiel: eine Kommandoprozedur, die eine Datei mit dem Typ .XYZ verarbeitet. Der DCL-Code zum Einsetzen dieses Standardwerts für den Dateityp - ohne die Verwendung der mehreren Defaults von F$PARSE - könnte etwa so aussehen:
...
$ NODENAME = F$PARSE(FILENAME,,,"NODE")
$ DEVICENAME = F$PARSE(FILENAME,,,"DEVICE")
$ DIRECTORYNAME = F$PARSE(FILENAME,,,"DIRECTORY")
$ FILENAME = F$PARSE(FILENAME,,,"NAME")
$ FILETYPE = F$PARSE(FILENAME,,,"TYPE")
$ VERSION = F$PARSE(FILENAME,,,"VERSION")
$ IF FILETYPE .EQS. "." -
THEN FILETYPE = ".XYZ"
$ FILENAME = NODENAME+DEVICENAME+DIRECTORYNAME -
+FILENAME+FILETYPE+VERSION
...
Wenn komplexere Verarbeitung benötigt wird, kann dieser Code entsprechend komplizierter werden. Bei Verwendung von F$PARSE wie vorgesehen ergibt sich eine deutlich kürzere Sequenz:
...
$ FILENAME = F$PARSE(FILENAME, "::[].XYZ;")
...
Dieser einfache Fall ist in den Beipielen enthalten unter dem Namen OPENVMS-F$PARSE-EXAMPLE1.COM.
Andere, umfassendere Fälle sind aussagekräftiger, und von weitergehenderer Bedeutung. In diesen Fällen muß eine Kommandodatei die Namen einer Reihe von in Beziehung stehenden Dateien bestimmen, im Einklang mit den OpenVMS-Konventionen (z.B. eine Reihe von Dateien mit dem Default-Namen der Quelldatei, einer Vielzahl verschiedener Dateitypen, und möglicherweise Überschreibungen des Ausgabe-Dateinamens und -Verzeichnisses). Dies ist genau das von den Compilern unter OpenVMS oder dem OpenVMS-Linker (aufgerufen über das LINK-Kommando) bekannte Verhalten.
Ein Compiler verwendet eine Eingabe-Quelldatei, um eine Reihe von Ausgaben zu generieren. Einige dieser Ausgaben sind irgendwie ausführbar, andere sind Listings, Maps und weitere Dokumentationen. Ich habe bei vielen Gelegenheiten Kommandodateien geschrieben, die "Konfigurations-Compiler" sind. Ein Konfigurations-Compiler benutzt die Beschreibung der verwendeten Konfiguration, um eine oder mehrere Kommandodateien für den Systembetrieb zu erzeugen. Dies vereinfacht die Wartung einer großen Anzahl von Maschinen in einer Produktionsumgebung erheblich. Im folgenden Beispiel nimmt der Konfigurations-Compiler eine .CONF-Datei als Eingabe, führt einige Berechnungen durch, und erzeugt eine Sammlung von verwandten Dateien:
- ein Listing (.LIS);
- eine Übersicht der Konfiguration (.MAP); und
- eine Kommandodatei zur Ausführung beim Systemstartup (.COM)
Die Aufruf-Syntax ist an derjenigen von Standard-Compilern ausgerichtet:
$ @generate "/list/map" sitealpha1
GENERATE.COM enthält eine kurze Reihe von Zeilen, um die Namen seiner Ein- und Ausgabedateien zu berechnen:
...
$ SPECIFIED_SOURCEFILE = P2
$ SPECIFIED_LISTING = ""
$ SPECIFIED_MAP = ""
$ SPECIFIED_COMMANDFILE = ""
...
$ SOURCE_FILESPECIFIER = F$PARSE(SPECIFIED_SOURCEFILE, -
"::SYS$DISK:[].CONF",,, -
"SYNTAX_ONLY")
$ LISTING_FILESPECIFIER = F$PARSE(SPECIFIED_LISTING, -
"::SYS$DISK:[].LIS;", -
SOURCE_FILESPECIFIER)
$ MAP_FILESPECIFIER = F$PARSE(SPECIFIED_MAP, -
"::SYS$DISK:[].MAP;", -
SOURCE_FILESPECIFIER)
$ COMMAND_FILESPECIFIER = F$PARSE(SPECIFIED_COMMANDFILE, -
"::SYS$DISK:[].COM;", -
SOURCE_FILESPECIFIER)
...
Abgesehen von den Prüfungen, ob die Eingabedatei existiert, und ob die Ausgabedateien fehlerfrei erzeugt werden, ist obiges der gesamte Aufwand, der zur Erzeugung der Ein- und Ausgaben dieses Programms notwendig ist. Ich habe außerdem den geringen Anteil der Logik zur Verarbeitung der "Schalter" auf der Kommandozeile weggelassen, mit dem die Standard-Namen der Ausgabedateien bei Bedarf überschrieben werden können.
Eine Kommandodatei, die diese Verarbeitung auf einer interaktiven Basis implementiert, ist in dem Satz von Beispielen als OPENVMS-F$PARSE-EXAMPLE3.COM enthalten.
Kurz gesagt ist die Verwendung von F$PARSE und des darunterliegenden SYS$PARSE eine wesentlich effektivere Methode zur Verarbeitung von Datei-Spezifikationen als jeder mögliche manuelle Ablauf. Die Benutzung von durch OpenVMS zur Verfügung gestellen Funktionen entlastet den Programmierer von der Notwendigkeit, sich im Detail mit dem Auseinandernehmen und Zusammensetzen der Komponenten einer Datei-Spezifikation auseinandersetzen zu müssen.
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.
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)