View Full Version : Ohne Verzug Daten vom Unix-Rechner bearbeiten
Das ist korrekt.
"cd pfad" wirkt nur für das IFS. Wenn der Pfad nicht existiert, passiert auch nichts. FTP macht mit dem nächsten Befehl weiter.
Wenn die LIB in der QUSRLIBL steht, klappt auch der CALL.
Wofür aber noch RCMD? "Quote CALL" oder "Quote SBMCMD" sollte doch reichen.
loeweadolf
15-02-17, 23:08
Vielen Dank an Baldur und an die anderen für die Mühe. Es war sehr hilfreich.
Das ist korrekt.
"cd pfad" wirkt nur für das IFS. Wenn der Pfad nicht existiert, passiert auch nichts. FTP macht mit dem nächsten Befehl weiter.
Wenn die LIB in der QUSRLIBL steht, klappt auch der CALL.
Wofür aber noch RCMD? "Quote CALL" oder "Quote SBMCMD" sollte doch reichen.
nur ungefähr!
- was cd macht, hängt vom namefmt ab und das wiederum vom eingestellten home des users
-- bei namefmt 1 wirkt cd im ifs, wie Baldur bemerkt
-- bei namefmt 0 wirkt cd wie chgcurlib, was in dem Beispiel wohl erwünscht ist
-- namefmt wechseln kann man, wenn das aktulle Verzeichhnis im QSYS.LIB auf einer Bibliothek verweist
-- der Wechsel geht dann mit: quote site namefmt 0
-- quote site namefmt 1 geht immer
wenn ich denn das aufzurufende PGM im libl habe
- ohne quote werden FTP Befehle auf dem client ausgeführt
- bewirkt quote lediglich, dass der folgende FTP (!!!) Befehl auf dem Server ausgeführt wird
- quote rcmd call myPgm ruft dann also auf dem server über den FTP command rcmd mein Programm auf
- lasse ich das rcmd weg,wird ein ftp befehl erwartet => quote call irgendwas geht nicht!!!
natürlich sollte man noch sicherstellen, dass das ganze auch bei mehrfachen Aufrufen funzt, auch wenn bereits das nächste gesendet wird, bevor die Verarbeitung des ersten fertig ist und wenn es schief geht, sollte man noch alle Informationen haben, was da eigentlich gesendet wurde!
Vorwärts synchronisieren, wie Ludger das macht, ist immer besser als HKGP (Haufenkacker-Graber-Prinzip), am besten ist es immer, wenn man den Übertragungen eine ID verpasst (Suffix oder Präfix im Dateinamen) und diese ID als Parameter im Aufruf mitgibt (dazu müsste man das FTP Skript dynamisch erzeugen.
Ludgers Variante würde ich verschlanken: die stored Procedure und das CL sind überflüssig, wenn man einen externen Trigger mit ADDPFTRG anhängt. So umständlich fände ich das dann nicht mehr - wobei ich mich natürlich frage, warum man nicht gleich wo und was schreibt, wo es hin soll.
D*B
KingofKning
16-02-17, 07:22
Hallo,
so sieht es bei mir aus:
USER batch batch
cd rptrade
quote RCMD call AUFRPTRADE
quit
Der FTP wird vom PC aus angestoßen ftp -n -s:c:\tools\ftp.txt 172.x.x.x
nach dem Transfer wird der Verarbeitungsjob angestoßen.
Aber jeder nach seiner Fasson
Also:
Wie Kollege Bender schon sagte:
In der Datei ftp.txt sind die Befehle so drin wie ich sie normalerweise beim händischen FTP eingeben würde.
User batch mit Kennwort batch
cd rptrade Dann ein Wechsel der Bibliothek nach RPTrade
quote RCMD call AUFRPTRADE Dann der Aufruf des Cls AUFRPTRADE der die Aufträge importiert.
Zeitliche Konflikte habe ich nicht, da die Daten nur alle paar Stunden kommen. Aber selbst wenn könnte über ein Flag gesteuert werden wenn das Programm läuft dann warte 2 Minuten, da der Import der Daten bei mir nur 30 Sekunden dauert. (Erstellen von EDI-Daten im Format Orders für EDDY)
GG 4854
Zeitliche Konflikte habe ich nicht, da die Daten nur alle paar Stunden kommen. Aber selbst wenn könnte über ein Flag gesteuert werden wenn das Programm läuft dann warte 2 Minuten, da der Import der Daten bei mir nur 30 Sekunden dauert. (Erstellen von EDI-Daten im Format Orders für EDDY)
GG 4854
... und genau da fängt der Wackelhaufen doch an!!! Was heute alle paar Stunden kommt, kann morgen in einem ganz anderen Turnus kommen und zwei Minuten warten kann eine Sekunde zu wenig sein und Murphy's law sagt...
D*B, der ein absoluter Gegner von Wackelhaufen ist, die alle und immer vermeidbar sind, ohne zusätzliche Aufwände.
KingofKning
16-02-17, 08:09
... und genau da fängt der Wackelhaufen doch an!!! Was heute alle paar Stunden kommt, kann morgen in einem ganz anderen Turnus kommen und zwei Minuten warten kann eine Sekunde zu wenig sein und Murphy's law sagt...
D*B, der ein absoluter Gegner von Wackelhaufen ist, die alle und immer vermeidbar sind, ohne zusätzliche Aufwände.
Naja,
vielleicht hast Du den Satz ja anders interpretiert als ich es meinte.
Da mit einem Flag gearbeitet wird kann das nächste Programm nur starten bis das erste sauber beendet ist. Bis dahin muß es halt jeweils 2 Minuten warten.
Und wenn man ein Programm schreibt was darauf ausgerichtet ist alle paar Stunden mal zu laufen, sollte man natürlich wenn sich die Rahmenbedingungen ändern auch das Programm anpassen.
Von vorneherrein so zu arbeiten als wäre das ein Hochfrequenzhandel an der Börse, wäre wie mit der dicken Berta auf ein Würmchen zu schießen.... (es leben die Spatzen)
GG 4854
... Hundekacke auf Bürgersteigen ist statistisch gesehen außerordentlich selten - und dennoch treten immer wieder Leute rein!
Und das hat doch was magisches...
Zur Statistik hätte ich auch noch was. Meine das mal von Norbert Blüm gehört zu haben.
„Wenn Herr Meier 2 Bratwürste isst, und Herr Schmidt keine, dann hat statistisch gesehen jeder eine Bratwurst gegessen. Nur ist Herr Meier satt, und Herr Schmidt hat immer noch Hunger.“
(Auch wenn wir jetzt wieder vom Thema abschweifen.)
Gruß Ronald