View Full Version : Datei kopieren
Hallo zusammen,
bräuchte doch nochmal eine Info zum Thema kopieren.
In einem Programm - welches oft und auch von verschiedenen Bildschirmen aus bei uns gestartet wird, wird die u.a. Output-Datei verwendet.
Ich möchte jetzt, dass immer nach Durchlauf des Programms - also nach dem CLOSE - die Output-Datei sofort mit unterschiedlichem Namen (z.B. mydat_datum_uhrzeit) ins IFS kopiert wird.
Wie würde sowas aussehen ?
Für Infos vielen Dank und schönes WE. Gruss A.
FLOGBM00A O E DISK USROPN
Das kann man leider nicht am CLOSE aufhängen, dazu musst du den CPYFRMIMPF in jedem Programm einbauen und den Dateinamen halt zusammenbauen.
Hierzu kannst du einen kleinen Service schreiben (ILERPG), dem du Lib/Name übergibst und der dann den CPY per QCMDEXC oder System() aufruft.
Dies ist nach jedem Close dann aufzurufen.
Das kann man leider nicht am CLOSE aufhängen, dazu musst du den CPYFRMIMPF in jedem Programm einbauen und den Dateinamen halt zusammenbauen.
Hierzu kannst du einen kleinen Service schreiben (ILERPG), dem du Lib/Name übergibst und der dann den CPY per QCMDEXC oder System() aufruft.
Dies ist nach jedem Close dann aufzurufen.
... könnte man schon (mit Journal und RCVJRNE). Die Anforderung klingt mir aber eher nach Wackelhaufen, dass hier nämlich ein Job einem anderen die Workdatei in die Tonne klopft.
D*B
Eine Möglichkeit wäre mit dem API QMHSNDSM (Send Scope Message) zu arbeiten.
Bei dem API-Aufruf kann man ein (Scope-)Programm und ggf. auch Parameter-Werte die an das (Scope-)Programm übergeben werden sollen, aufrufen.
Das API ruft man am Besten zu Beginn des Verarbeitungs-Programms auf.
Wenn das Verarbeitungs-Programm endet (unabhängig davon ob normal oder abnormal) wird das beim API-Aufruf angegebene (Scope-)Programm ausgeführt.
Dein Scope-Programm würde dann nur den Befehl, der die Daten ins IFS kopiert, enthalten.
Send Scope Message (QMHSNDSM) API (https://www.ibm.com/docs/api/v1/content/ssw_ibm_i_74/apis/QMHSNDSM.htm)
Wenn es sich nicht um ein Programm, sondern um eine ILE-Prozedur handeln würde, könnte man am Ende der Prozedur einen ON-EXIT command angeben und danach die Daten kopieren.
Was nach dem ON-EXIT folgt wird immer ausgeführt, egal ob die Prozedur normal oder abnormal beendet wird.
Das hilft aber nur, wenn man nach dem Close das Programm/Callstackentry/Job auch beendet.
Hinzu kommt, dass man eigentlich für alle 3 Situationen gewappnet sein müsste, also ggf. 3 Calls benötigt.
Das ist dasselbe, wie das von D*B bereits öfter erwähnte Exit-Programm oder das Einbringen von Commit-Ressourcen, die bei Commit/Rollback ebenso automatisch aufgerufen werden.
Aber warum eine Nachricht senden, wenn ich nach dem CLose das Kopierprogramm direkt aufrufen kann?
Die Logik dahinter entzieht sich mir.
Und abnormales Ende sollte inzwischen dank Monitor-Group den Gang der Geschichte antreten.
In anderen (moderneren) Programmiersprachen (C++, .Net, Java, JavaScript, ...) kennt man das Prinzip Try/Catch/Finally sowie Throw für gezielte Fehlerbehandlung, das eingeschränkt nun ebenso mit ILERPG durchaus umsetzbar ist.
Und ob ein ENDJOB den Call ausführt weiß ich nicht, eine Commit-Ressource wird auf jeden Fall berücksichtigt.
1) Vor dem Pgm wird die Datei (LEER!) mit CRTDUPOBJ in die QTEMP kopiert.
2) In der F-Bestimmung wird explizit auf die QTEMP-Datei verwiesen.
3) Am Ende ein CALL auf ein CL, welches die QTEMP-Datei in's IFS kopiert
Dadurch gibt's auch keine Probleme, wenn mehrere gleichzeitig das Pgm aufrufen (was der Fragesteller ja explizit erwähnt)
Er/sie/es hat ja nicht geschrieben, dass er bei paralleler Nutzung Probleme hätte.
Wenn es nicht so lange dauert (kleiner 1 Minute), kann man ja vor der Ausgabe einen ALCOBJ und nachdem Copy einen DLCOBJ machen.
Bei Verwendung von SQL werden Daten beim Insert ja bis Commit gesperrt.
Also schön inserts, copy in IFS (Lesen geht ja), Rollback um den Inhalt wieder zu löschen.
Es gibt viele Wege zum Erfolg.
und wie üblich - Fürchau muss immer seinen Senf d'raufgeben
1) Auch wenn der Fragesteller es nicht geschrieben hat - bei - Zitat "oft und von verschiedenen Bildschirmen aufgerufen" kann und wird es früher oder später zu Problemen kommen.
2) ALC benötigt man nicht, weil ohnehin gesperrt.
3) "wenn es nicht so lange dauert, kann man ALCOBJ usw.." ja sehr schön - und wenn das dann zufällig mal mehrere gleichzeitig aufrufen, gibt's eine schöne Wette "wer läuft zuerst auf MSGW" ...
oh mann...
Nun ja, ALCOBJ schließt ja nun mal eine Prüfung mit MONMSG ein.
Man weiß schließlich, dass das auch mal fehlschlagen wird;-).
Schließlich habe ich schon genug Programme mit SQL gesehen, die sich auch darauf verlassen, dass alles gutgeht (kein SQLCODE oder SQLSTATE geprüft).
Und wer kennt nicht die vielen Jobhänger und MSGW bei Satzsperren im Multiuser-Betrieb.
Und auch MONMSG wird irgendwie ungern gesehen.
In anderen Welten ist Try/Catch, also Fehlerbehandlung, scheinbar eher üblich.
Nur um noch den Senf zu würzen;-).