Datei kopieren

[hel400]

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)

[Fuerchau]

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.

[hel400]

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...

[Fuerchau]

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;-).

[holgerscherer]

Nur um noch den Senf zu würzen;-).

Um noch mehr Würze dazu zu geben, frage ich mich, was der Sinn des Inhalts dieser Datei ist, wenn da mehrere Jobs was rein schreiben und dann immer wieder exportiert wird ins IFS.

Vielleicht sollte jeder Job seine eigene LOG-Datei in der QTEMP haben und dann nach Beendigung exportieren?

[Fuerchau]

Oh Holger, Du Oberschlauer;-).
Über manchen Unsinn mache ich mir keine Gedanken mehr. Da ist sogar D*B inzwischen drüber weg.
Wenn ich mal sooo alt werde wie D*B....

[hel400]

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;-).

Und wieder ein Kleckser dazu!

LESEN!

Was heißt bitte - Zitat:
"...Man weiß schließlich, dass das auch mal fehlschlagen wird;-)"...

So arbeitest Du, echt jetzt??

Und "...Schließlich habe ich schon genug Programme mit SQL gesehen, die sich auch darauf verlassen, dass alles gutgeht (kein SQLCODE oder SQLSTATE geprüft)...."

Genau deshalb macht man das ja über die (gute alte) QTEMP!!
Dann wird es NICHT fehlschlagen und niemand sieht in diesem Falle mehr MSGW und Jobhänger usw...

Also bitte seriös bleiben und nicht irgendetwas schreiben.

[Fuerchau]

Ich schreibe eben nicht irgendetwas, sondern berichte i.W. aus meiner langjährigen Erfahrung:-).
D*B spricht da eben auch häufiger von Wackelhaufen, die irgendwann zusammenbrechen.

Und meine Erfahrung besagt:
Im Durchschnitt besteht eine Software zu 80% daraus, Bedienerfehler abzufangen und zurückzuweisen.
Dazu gehören dann auch sog. Korrekturprogramme, die Programmier- und Konzeptfehler wieder ausbügeln. Diese Programme werden dann regelmäßig, täglich, wöchentlch oder sonstwie aufgerufen und erledigen Dinge, die bei korrekter Berücksichtgung im Design oder Behebung der Ursache nicht erforderlich sind.

Weitere 18% sind dann die sog. Businesslogik.
Ein weiteres Prozent sind dann Nice-To-Have oder optische Verbesserungen und das restliche Prozent wird als zu teuer oder langwierig nie realisiert.

Leider gehören dazu auch heute noch MSGWAIT's wegen Deadlocks, Transaktions- oder nur Satzsperren über Bildschirmgrenzen hinweg. Konkurrierende oder überschreibende Updates u.v.m.

Ich betreibe nun ca. 46 Jahre Anwendungsentwicklung auf verschiedensten Plattformen. Von Nixdorf Computer über IBM i bis Windows VB6, C++ und .Net.
Und überall sind mir dieselben Probleme begegnet.

Wie der Rheinländer ja sagt: "Es ist ja immer gut gegangen".

[BenderD]

D*B spricht da eben auch häufiger von Wackelhaufen, die irgendwann zusammenbrechen.

... instruktiv hierzu auch das Freelancer Denkmal, die Extern-Steine im hessisch-niedersächsischen Grenzgebiet:
https://de.wikipedia.org/wiki/Datei:...ackelstein.jpg

D*B

[KingofKning]

Wie der Rheinländer ja sagt: "Es ist ja immer gut gegangen".

Da sträuben sich dem Kölner als solches der ja nun mal auch Rheinländer ist die Nackenhaare....

Et hätt noch emmer joot jejange.

[BenderD]

Da sträuben sich dem Kölner als solches der ja nun mal auch Rheinländer ist die Nackenhaare....

Et hätt noch emmer joot jejange.

... da kommt ja auch der Rhein-GAU her!

D*B

[Fuerchau]

@King
Ich wollte es ja nur allgemeiner verständlich machen;-)

https://mingsprooch.de/
"Isch wollt et ija nor allgemeiner verständlich maache"