File I/O mit CRTL unter OpenVMS

Transkript

1 DECUS München Symposium - Bonn File I/O mit CRTL unter OpenVMS Hartmut Becker März 2000 Seite 1

2 Themen Die Aufgabe Den Durchsatz erhöhen Die Feinheiten File I/O mit CRTL unter OpenVMS Seite 2

3 Die Aufgabe Ein Beipiel aus dem realen Leben: fh = fopen (filname, AccessMap[accessType]); wobei AccessMap[ReadOnly] = "r"; AccessMap[ReadWrite] = "r+"; AccessMap[Append] = "a"; AccessMap[Rewrite] = "r+"; AccessMap[ReadAll] = "r"; AccessMap[ReadOnlyTransparent] = "rb"; AccessMap[AppendTransparent] = "ab"; AccessMap[Create] = "a"; File I/O mit CRTL unter OpenVMS Seite 3

4 Die Aufgabe... Ist das portierbar auf OpenVMS? Ist es wirklich so harmlos, wie es aussieht? File I/O mit CRTL unter OpenVMS Seite 4

5 Die Aufgabe... Sicher ist das portierbar, aber wie wird das Codefragment benutzt: Prozeß A fopen("log", Append); Prozeß B fopen("log", ReadOnly); Kein Problem unter UNIX (wirklich nicht?) Aber so einfach geht s nicht unter OpenVMS: fopen: non-translatable vms error code: 0x1828A %rms-e-flk, file currently locked by another user File I/O mit CRTL unter OpenVMS Seite 5

6 Die Aufgabe... Wo wird File sharing gemacht? - keine Funktionalität von ANSI I/O - keine Funktionalität von UNIX I/O - bei VMS macht es RMS mit Record locking - bei UNIX macht es das File system Folglich muß bei VMS RMS Record I/O mit File shareing (damit Locking) erzwungen werden - voreingestellt in der CRTL ist Block I/O File I/O mit CRTL unter OpenVMS Seite 6

7 Die Aufgabe... Sicher war das portierbar, das Codefragment sieht jetzt so aus Prozeß A Prozeß B fopen("log", Append, fopen("log", ReadOnly, "ctx=rec", "ctx=rec", "shr=get"); "shr=get,put,upd"); Das war s, oder? File I/O mit CRTL unter OpenVMS Seite 7

8 Den Durchsatz erhöhen Noch nicht ganz... plötzlich wird die Applikation unheimlich zäh und träge, was ist passiert? - ANSI I/O unter VMS ist nicht mehr gepuffert * mindestens jeder fwrite() geht an RMS * ist in den Daten \n enthalten so sind s mehr - Standard RMS Record I/O schreibt jeden Satz auf die Platte - ANSI I/O unter UNIX puffert noch immer - UNIX Buffer cache puffert noch immer File I/O mit CRTL unter OpenVMS Seite 8

9 Den Durchsatz erhöhen... Welche Rolle spielen Puffer? - wo gibt es Puffer * im Prozeß, verwaltet von CRTL/libc bei ANSI I/O * in Prozessen, verwaltet von RMS * im System, verwaltet von VIOC/Buffer cache File I/O mit CRTL unter OpenVMS Seite 9

10 Den Durchsatz erhöhen... damit Daten über Prozeßgrenzen hinaus sichtbar werden, müssen die ANSI I/O-Puffer geleert werden: fflush() - bei VMS müssen sie hier nach RMS (egal, ob dort gepuffert wird oder nicht) - bei Unix in das File system (egal, ob dort gepuffert oder nicht) File I/O mit CRTL unter OpenVMS Seite 10

11 Den Durchsatz erhöhen... Hmm, haben wir jetzt die Semantik geändert? - ja! - jeder RMS Record ist jetzt sichtbar - der Teil eines Ausgabedatenstroms sein kann - sollte nichts ändern, oder? File I/O mit CRTL unter OpenVMS Seite 11

12 Den Durchsatz erhöhen... Machen wir s schneller Prozeß A Prozeß B fopen("log", Append, fopen("log", ReadOnly, "ctx=rec", "ctx=rec", "shr=get", "shr=get,put,upd"); "fop=dfw", "alq=500", "deq=500"); File I/O mit CRTL unter OpenVMS Seite 12

13 Den Durchsatz erhöhen... Sharing: ok Schreibleistung ohne gleichzeitigen Leser: optimal Schreibleistung mit gleichzeitigem Leser: es kommt drauf an. - Daten müssen auf die Platte oder in einem Global buffer gehalten werden - Global buffer lohnt sich nur, wenn in der Relation zum Schreiben viel gelesen wird File I/O mit CRTL unter OpenVMS Seite 13

14 Den Durchsatz erhöhen... Schneller Schreiber, lahmer Leser: keine Global buffers Lahmer Schreiber, viele lahme Leser: Global buffers Lahmer Schreiber, schneller Leser(?): Global buffers File I/O mit CRTL unter OpenVMS Seite 14

15 Die Feinheiten So weit, so gut, aber... wir hatten die Semantik geändert, was wenn noch jemand schreibt? Prozeß A Prozeß AA fopen("log", Append, fopen("log", Append, "ctx=rec", "ctx=rec", "shr=get,put,upd", "shr=get,put,upd" "fop=dfw", "alq=500", "fop=dfw", "alq=500", "deq=500"); "deq=500"); File I/O mit CRTL unter OpenVMS Seite 15

16 Die Feinheiten... Prozeß A Prozeß AA fwrite (..."hello\nworld"...) fwrite(..."hello\neurope"...) => hello hello Europe World File I/O mit CRTL unter OpenVMS Seite 16

17 Die Feinheiten... Trickserei Prozeß A Prozeß AA fopen("log", Append, fopen("log", Append, "ctx=rec,bin", "ctx=rec,bin", "shr=get,put,upd", "shr=get,put,upd" "fop=dfw", "alq=500", "fop=dfw", "alq=500", "deq=500"); "deq=500"); fwrite (..."hello\nworld"...) fwrite(..."hello\neurope"...) Beim Schreiben werden die Daten von fwrite() wie ein Satz behandelt, beim Lesen sind es jeweils 2 Sätze. File I/O mit CRTL unter OpenVMS Seite 17

18 Die Feinheiten... Warum eigentlich nicht rfm=var? Der Leser soll im Datenstrom positionieren können - fseek() geht nur im Stream mode Und wenn nun der Schreiber auch noch positionieren und dort schreiben soll? - z.b. wurden die gleichen fopen() dafür benutzt - nun werden unter VMS aber standardmäßig beim Lesen die Records exklusiv gelockt, es kommt zu Konflikten File I/O mit CRTL unter OpenVMS Seite 18

19 Die Feinheiten... mehr Trickserei Prozeß A Prozeß B fopen("log", ReadWrite, fopen("log", ReadOnly, "ctx=rec,bin", "ctx=rec", "shr=get", "shr=get,put,upd" "rop=rlk", "rop=nlk"); "fop=dfw", "alq=500", "deq=500"); File I/O mit CRTL unter OpenVMS Seite 19

20 Die Feinheiten... Wunderbar, die Datei wurde geschrieben, man kann sie mit dem EDT anschauen, und verändern und alles ist bestens, es sei denn... - neu angelegte Dateien von EDT, EDIT/TPU haben rfm=var - das Record format sollte beim Öffnen überprüft werden - ggf. konvertieren File I/O mit CRTL unter OpenVMS Seite 20

21 Die Feinheiten... #include <stdio.h> #include <stdlib.h> #include <string.h> #include <rms.h> static int beforefopen (struct FAB**, struct FAB *, struct RAB *); int main (int argc, char *argv[]) { FILE *fd; struct FAB* f= NULL; if (argc==1) return fprintf (stderr, "usage: %s file\n", argv[0]), EXIT_FAILURE fd= fopen(argv[1],"a+", "acc", beforefopen, &f); if (FAB$C_STMLF!=f->fab$b_rfm) { fprintf (stderr, "-w-wrf, %s, wrong record format, " "not Stream_Lf\n", argv[1]); return EXIT_FAILURE; } File I/O mit CRTL unter OpenVMS Seite 21

22 Die Feinheiten... } fclose (fd); static int beforefopen (struct FAB **f, struct FAB *fab, struct RAB *rab) { *f= fab; return EXIT_SUCCESS; } File I/O mit CRTL unter OpenVMS Seite 22

23 Die Feinheiten... War s das nun? Nein, jetzt das Ganze noch einmal, aber mit binären Daten... - ctx=rec und Stream_Lf geht nicht mehr * im ASCII mode ist \n erwünscht, enthält die Struktur * fread() bekommt es geliefert. * im Binär mode gehört es nicht zu den Daten * fread() bekommt es nicht geliefert - Ausweg rfm=udf File I/O mit CRTL unter OpenVMS Seite 23

24 Die Feinheiten... noch mehr Trickserei Prozeß A Prozeß B fopen("log", fopen("log", AppendTransparent, ReadOnlyTransparent, "ctx=rec", "ctx=rec", "shr=get", "shr=get,put,upd" "rfm=udf", "rop=rlk", "rfm=udf", "rop=nlk"); "fop=dfw", "alq=500", "deq=500"); File I/O mit CRTL unter OpenVMS Seite 24

25 Die Feinheiten... Sharing: ok - die Daten eines fwrite() sind ein Record - ebenso die Daten eines fread() Leider nicht mehr editierbar (ansonsten wäre es DIE Lösung) File I/O mit CRTL unter OpenVMS Seite 25

26 Zusammenfassung Das war s aber nun wirklich, nur, aus einem kurzen Unix Code Stück wurde ein größeres Case statement, aber, nur eine lokale Änderung (!) keine RMS-Aufrufe, transparent gegenüber übergeordneter Software File I/O mit CRTL unter OpenVMS Seite 26

27 Zusammenfassung Application ANSI I/O UNIX I/O RMS Block I/O Record I/O Block I/O Files File I/O mit CRTL unter OpenVMS Seite 27

28 ? File I/O mit CRTL unter OpenVMS Seite 28