Makrotyp: R-Typ
Mit dem Makroaufruf OPEN muss jede Datei vor der Bearbeitung eröffnet werden. Die Voreinstellung für den OPEN-Makroaufruf ist durch die Angabe im OPEN-Operanden von FCB oder FILE (über die TFT) gegeben; ist dort keine Angabe zum OPEN-Modus gemacht, gilt OPEN=INPUT.
Format
Operation | Operanden |
|
|
Operandenbeschreibung
fcbadr
Adresse des FCB-Makroaufrufs für die Datei, die eröffnet werden soll.
(1)
Die FCB-Adresse steht im Register 1.
mode
OPEN-Modus, siehe Tabelle unten: Spalte 1
(0)
Der OPEN-Modus wird im Register 0 übergeben, codiert im niedrigstwertigen Byte.
Die folgende Tabelle zeigt die Zuordnung von OPEN-Modi und Codes.
OPEN-Modus | Code | Bedeutung |
unbestimmt | X'00' | der im TU-FCB angegebene OPEN-Modus hat Vorrang. Ist auch dieser X'00', wird eine Fehlermeldung ausgegeben. |
INPUT | X'01' | die Datei wird als Eingabedatei eröffnet, anschließend sind nur Leseoperationen zulässig; Leserichtung: „vorwärts“ |
REVERSE | X'02' | die Datei wird als Eingabedatei eröffnet, anschließend sind nur Leseoperationen zulässig; Leserichtung: „rückwärts“ Dateiende |
OUTPUT | X'04' | die Datei wird als Ausgabedatei eröffnet und, falls sie schon existierte, von Beginn an überschrieben; es ist nur sequenzielles Schreiben zulässig |
EXTEND | X'08' | die Datei wird als Ausgabedatei eröffnet zur sequenziellen Erweiterung; es sind, beginnend an einem definierten Punkt der Datei, nur sequenzielle Schreiboperationen zulässig |
UPDATE | X'10' | die Datei soll aktualisiert werden; es sind sowohl Lese- als auch Schreiboperationen zulässig |
INOUT | X'20' | die Datei soll aktualisiert werden; es sind sowohl Lese- als auch Schreiboperationen zulässig |
OUTIN | X'40' | die Datei soll zunächst erstellt (bzw. überschrieben) werden; anschließend sind sowohl Lese- als auch Schreib-Operationen zulässig |
PARMOD
gibt den Generierungsmodus an, entsprechend dem im FCB-Makroaufruf für die Datei gültigen Wert.
Voreinstellung: | der durch den Assembler oder den GPARMOD-Makroaufruf im Programm eingestellte Wert. |
= 24
Es wird ein Objekt erzeugt, das nur im 16-MB-Adressraum ablauffähig ist
(nur 24-Bit-Adressierung).
= 31
Es wird ein Objekt erzeugt, das im 2-GB-Adressraum ablauffähig ist
(24-Bit- oder 31-Bit-Adressierung).
Hinweise zur Programmierung
Der OPEN-Makroaufruf zerstört die Register 0, 1, 14 und 15.
Wird während eines Programmlaufs bei einem OPEN-Aufruf für eine Datei eine FCB-Adresse angegeben, die bereits für einen anderen erfolgten OPEN verwendet wurde, wird das Programm abnormal mit Fehlerschlüssel DMS0D9F beendet.
Hinweise zur Programmierung bzgl. großer Dateien
Der Makro OPEN und die Zugriffsmethoden sind nur von der Einführung großer Dateien, nicht aber von der Einführung großer Volumes betroffen.
Die Schnittstelle OPEN prüft, ob Dateierweiterungen über 32 GB hinaus und das Erstellen oder Zugriffe auf Dateien >= 32 GB zulässig sind.
Hierbei gibt es zwei Aspekte:
Abweisen des Zugriffs auf oder der Erzeugung von großen Dateien für Zugriffsmethoden, die eine Bearbeitung von großen Dateien nicht gestatten.
Kennzeichnen, dass ein Programm Dateien >= 32 GB erzeugen bzw. öffnen kann.
Unverträgliche Schnittstellenvarianten
Schnittstellen, an denen 3-Byte-Blocknummern verwendet werden, sind prinzipiell nicht in der Lage, mit Dateien >= 32 GB zu arbeiten. Es handelt sich hier um folgende Fälle:
Sämtliche Dateien im Key-Format (BLKCTRL=PAMKEY):
Die logischen Blocknummern im Pamkey sind nur 3 Byte breit.24-Bit-Schnittstelle von UPAM:
Das Feld für die logischen Blocknummern in den UPAM-Parameterlisten und im TU-FCB ist nur 3 Byte breit.24-Bit-Schnittstelle von SAM:
Hier sind die logischen Blocknummern als Teil der Wiedergewinnungsadresse betroffen.
In allen oben aufgeführten Fällen gilt:
Der Zugriff auf Dateien >= 32 GB wird mit dem Returncode
X'0000D9D'
oderX'00000D00'
abgewiesen, abhängig von der Größe des für die Datei allokierten Speicherplatzes (FILE-SIZE).Die Überschreitung einer Dateigröße von 32 GB durch Sekundärallokierung wird unterbunden (LARGE-FILE).
Semantische Inkompatibilität
Es kann nicht ausgeschlossen werden, dass Anwendungen zwar Schnittstellen benutzen, die bezüglich der oben angeführten Datenfelder bereits 4-Byte-Felder verwenden, ihrerseits jedoch explizit oder implizit von der bisherigen Beschränkung auf Werte kleiner X'00FFFFFF' Gebrauch machen.
Beachten Sie deshalb, dass bei der Anpassung von Assemblercode für Dateien >= 32 GB neben der Umstellung auf 4-Byte-Blockzähler und -nummern auch zu prüfen ist, ob die Programmlogik implizit von der Annahme Gebrauch macht, dass Dateien nicht größer als 32 GB werden können.
Ohne Anspruch auf Vollständigkeit folgen einige Beispiele für derartige semantische Inkompatibilitäten:
Die höchste 3-Byte-Blocknummer X'FFFFFF' hat eine spezielle Bedeutung.
„Blocknummern“ > X'00FFFFFF' repräsentieren nicht Blöcke, sondern andere Objekte.
Bei Berechnungen mit Blocknummern oder - zählern > X'00FFFFFF' kann es zum Überlauf kommen.
Die Stellenzahl von Ein- oder Ausgabefeldern reicht nicht zur Darstellung beliebig großer Blocknummern oder -zähler.
Bei Umrechnungen von Hexadezimalzahlen in Dezimalzahlen ist die Feldlänge für die Dezimalzahl zu klein.
Es wird unterstellt, dass Datenstrukturen, deren Umfang von einer Dateigröße abhängt, stets im virtuellen Speicher Platz finden. Diese Annahme kann für Dateien < 32 GB gültig sein, nicht aber, wenn diese Größe überschritten wird.
Eine abschließende Liste von Problemfällen kann nicht gegeben werden. Potenziell kritisch ist jedenfalls Coding, das auf Blocknummern, Dateigrößen und davon abgeleiteten oder abhängigen Strukturen aufsetzt.
Über die Ausführung des Makros bzgl. großer Dateien informieren folgende Returncodes:
X'cc' | X'bb' | X'aaaa' | Erläuterung |
X'00' | X'00' | X'0D9D' | Fehler beim Eröffnen einer Plattendatei. |
X'00' | X'00' | X'0D00' | Systemfehler beim Eröffnen einer Datei. |