View Full Version : Dateierzeugung im IFS und FTP versendet unfertige Files trotzdem
Hallo Zusammen,
heute hatten wir folgendes Problem:
- Data convert ins IFS und Erzeugung einer 40 MB großen Datei
- gleichzeitig krallt sich der FTP Async Job die Datei und versendet 6 MB davon und sagt fertig
Der FTP Process liest mit den API's OPENDIR, READDIR das Verzeichnis aus.
Gibt es eine Möglichkeit hier einzuschreiten um nur "fertige" Files zu ermitteln. Es gibt wohl keine Möglichkeit die IFS File solange zu sperren, bis sie fertig erzeugt ist.
Danke.
Gruß Klaus
Andreas_Prouza
30-01-23, 14:47
Hallo Klaus,
Du kannst leider nie ausschließen, dass ein Programm lesend auf eine Datei zugreift.
Die einfachste und sicherste Variante ist, dass du die Datei temporäre z.B. im /tmp erstellen lässt und erst nach fertigstellung in dein FTP Verzeichnis stellen.
Falls dein FTP-Prozess auf bestimmte Dateinamen geht (z.B. *.csv), kannst du auch während der Konvertierung in .csv.tmp und dann nach Fertigstellung auf .csv umbenennen.
lg Andreas
Danke Dir Andreas,
eventuell geben die SQL Table functions mehr her. Ich teste mal, sonst bleibt nur der beschriebene Weg von Dir.
Auch die Tablefunction macht genau das selbe und kann daher auch ggf. nur Teile einlesen.
In FTP-Scripts muss daher man erst in eine Arbeitsdatei, z.B. "xxx.wrk" hochladen und bei Fertigstellung in den erwarteten Namen "xxx.csv" umbenennen.
FTP unterstützt da auch das Rename-Kommando.
Bei der Verarbeitung filtert man halt auf *.csv Dateien.
U.U. kann mit CHKOUT eine Sperre geprüft werden, die mit CHKIN gelöst wird.
Danke Euch, hatte es befürchtet, auch die Table functions zeigen keine Unterschiede bei den Attributen zu den bereits fertigen Files.
Was soll auch der Unterschied sein? SQL greift mit denselben C-Funktionen auf das IFS zu was du mit ILERPG auch kannst und was CPYxxxSTMF/CPY...IMPF auch tun.
Wie gesagt, du kannst probieren mit CHKIN/CHKOUT einen Schreibschutz zu versuchen. Während FTP noch überträgt sollte es nicht klappen. Ebenso ein Rename sollte erfolglos sein.
Sobald es klappt, kannst du verarbeiten.
Moin,
wir machen ein LS (oder find?) in eine Outfile, dann 10 Sekunden warten, das selbe nochmal.
mit SQL lesen wir die Outfile gegroupt incl Datum und Zeit mit having count(*) = 2.
Bei uns reichen 10 Sekunden. Laufende Jobs haben innerhalb der 10 Sekunden die Datei verändert.
Sicher ist das auch nicht, da die Datei immer noch in Benutzung sein kann.
Eine FTP-Übertragung oder auch Kopiervorgang kann schon eine Weile dauern.
Ohne eine Sperre zu setzen ist das halt nicht sicher.
Wenn 10 Sekunden bei euch reichen hast du nur Glück gehabt.
na ja, wenn die Datei noch geschrieben wird, verändert sich die Zeit.
Dann übertrage ich Sie nicht, erst(evtl) beim nächsten Lauf (bei uns alle 15 Minuten)
... Problem ist doch in all diesen Fällen das miserable Design! Die Daten enthalten kein Prüfkriterium für Vollständigkeit oder es wird nicht geprüft und dann auch noch das nicht auszurottende Haufenkacker-Graber-Prinzip angewandt. Asynchrone Übertragungen können auch abbrechen, dann hilft warten nichts und durch HKGP kommt dann noch das Problem von Doppelübertragungen hinzu - schließlich merkt der Sender ja, dass es nicht gefunzt hat und machts nochmal.
Am einfachsten und saubersten ist es, wenn der Sender nach erfolgreichem senden ein Event auf dem Zielsystem auslöst, das den Empfang regelt. Statt an Murkslösungen festzuhalten und Aufwand in untaugliche Versuche zu stecken, das irgendwie zu heilen, die bestenfalls die Fehlerquote verkleinern, sollte man das Übel lieber an der Ursache - dem miesen Design - anpacken.
D*B