-
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;-).
-
Zitat von Fuerchau
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?
-
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....
-
Zitat von 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;-).
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.
-
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".
-
Zitat von Fuerchau
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
-
Zitat von Fuerchau
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.
-
Zitat von KingofKning
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
Similar Threads
-
By loeweadolf in forum NEWSboard Programmierung
Antworten: 4
Letzter Beitrag: 08-06-21, 07:35
-
By _MG_ in forum NEWSboard Programmierung
Antworten: 10
Letzter Beitrag: 14-12-16, 15:45
-
By Albundy in forum IBM i Hauptforum
Antworten: 21
Letzter Beitrag: 10-08-16, 15:39
-
By GJV23 in forum IBM i Hauptforum
Antworten: 7
Letzter Beitrag: 18-02-16, 17:09
-
By labm in forum NEWSboard Programmierung
Antworten: 6
Letzter Beitrag: 22-04-14, 14:30
Berechtigungen
- Neue Themen erstellen: Nein
- Themen beantworten: Nein
- You may not post attachments
- You may not edit your posts
-
Foren-Regeln
|
Erweiterte Foren Suche
Google Foren Suche
Forum & Artikel Update eMail
AS/400 / IBM i
Server Expert Gruppen
Unternehmens IT
|
Kategorien online Artikel
- Big Data, Analytics, BI, MIS
- Cloud, Social Media, Devices
- DMS, Archivierung, Druck
- ERP + Add-ons, Business Software
- Hochverfügbarkeit
- Human Resources, Personal
- IBM Announcements
- IT-Karikaturen
- Leitartikel
- Load`n`go
- Messen, Veranstaltungen
- NEWSolutions Dossiers
- Programmierung
- Security
- Software Development + Change Mgmt.
- Solutions & Provider
- Speicher – Storage
- Strategische Berichte
- Systemmanagement
- Tools, Hot-Tips
Auf dem Laufenden bleiben
|
Bookmarks