View Full Version : Abfrage Jobq leer
Sollen oder müssen hier wirklich alle Jobs gleich heißen?
Welche Protokolldatei soll per E-Mail gesendet werden?
Was bringt ein Neustart am Schluß?
... es geht hier nicht um Power oder Performance. Es geht um Stabilität, Transparenz, Korrektheit und Modularisierung.
Unix hat zum Beispiel eine Funktion waitpid(), die wartet bis ein Prozess mit einer bestimmten Prozess id fertig ist. Damit kann man sehr flexibel Prozesse koordinieren.
Dazu braucht man:
eine procedure createProcess, die einen neuen Prozess startet und eine ProzessID zurückgibt.
(create DTAQ zur Kommunikation
Submit des Tochterjobs
ALCOBJ auf ein Synchronobject (Rxxxxxx xxxxxx = JobNr
Ausführung der angeführten Funktion (CommanString)
bei Ende wird der ALC automatuisch frei gegeben)
eine procedure joinProcess mit der man auf einen kindjob warten kann.
Bedienen tut man dass dann mit
pid = createProces( commandString, length)
joinProcess(pid)
Damit kann man beliebige schedules bauen, die nahtlos ablaufen.
Haben wir mal benutzt um Langläufer massiv parallel abzufahren. (100te von Millionen Transaktionen in den Ladeprozessen eines DWHs).
D*B
In einem CL wird pro LIB ein Job in eine JOBQ gestellt (Sicherung in *savf, ftp auf NAS).
In dieser JOBQ sind 3 jobs auf einmal erlaubt, damit die ganze Sache schneller fertig ist.
Wenn alle jobs abgearbeitet sind, soll noch ein Befehl laufen (z.B. reboot System).
Meine Frage jetzt: gibts eine Möglichkeit abzufragen, ob noch jobs in einer JOBQ sind? Erst wenn 0, dann soll ja der Ende-Job gestartet werden.
Oder denk ich da falsch und es gäbe andere Möglichkeiten?
------------------------------------------------------
a) starte als erstes ein Abfrageprogramm (mit Steps b-e) in einer Endlosschleife
b) Wartezeit einige Sekunden
c) WRKACTJOB *PRINT
d) CPYSPLF QPDSPAJB in eine "Datei"
e) ein Prüfprogramm für "Datei" (Schleifenende ja/nein)
------------------------------------------------------
a) starte als erstes ein Abfrageprogramm (mit Steps b-e) in einer Endlosschleife
b) Wartezeit einige Sekunden
c) WRKACTJOB *PRINT
d) CPYSPLF QPDSPAJB in eine "Datei"
e) ein Prüfprogramm für "Datei" (Schleifenende ja/nein)
... und wenn Du gerade den Zeitpunkt erwischst, wo der vorletzte Job gerade eben fertig geworden ist, hast Du ins Klo gegriffen.
Ach ja, das passiert ja nur ganz selten und dann schimpft man den user aus, dass er was falsch gemacht hat.
E305GL ist wohl eben doch noch Oldschool, deshalb ist da sowas wohl noch erforderlich;-).
WRKACTJOB mit CPYSPLF habe ich wohl zuletzt mit V2R1 gemacht.
Danach hatte ich bereits die API's entdeckt.
Nach dem CPYSPLF fehlt noch die Umsetzung via SQL mit SUBSTR in eine DDS-PF.
Dafür gabs mal sogar ein kostenpflichtiges Programm: Spools to Excel.
... und wenn Du gerade den Zeitpunkt erwischst, wo der vorletzte Job gerade eben fertig geworden ist, hast Du ins Klo gegriffen.
Ach ja, das passiert ja nur ganz selten und dann schimpft man den user aus, dass er was falsch gemacht hat.
auf Grund meiner 56-jährigen IT-Erfahrung gehe ich davon aus, dass ein versierter Entwickler im Falle Deiner theoretischen Annahme erkennt, dass am Ende eine kurze Wartezeit Dein mukiertes Problem einfach löst.
E305GL ist wohl eben doch noch Oldschool, deshalb ist da sowas wohl noch erforderlich;-).
WRKACTJOB mit CPYSPLF habe ich wohl zuletzt mit V2R1 gemacht.
Danach hatte ich bereits die API's entdeckt.
Nach dem CPYSPLF fehlt noch die Umsetzung via SQL mit SUBSTR in eine DDS-PF.
Dafür gabs mal sogar ein kostenpflichtiges Programm: Spools to Excel.
von wegen Oldschool: Wozu Du ein Umsetzen, eine DDS, ein SQL und gar ein kostenpflichtiges Programm brauchst ist eine gravierdende Fehleinschätzung. Hast wohl beim IBM "AS400 inside"-Kurs nicht aufgepasst. Wir haben uns bereits 1984 von der so hochgelobten modernen API- und SQL-Modernität auf diesen Dritt- bzw. Viertgenerationslevel verabschiedet und sind bereits in der Fünften. Nur wer bereits auf der IBM-360 RPG und Assenbler Programmiert hat kann beurteilen was API's SQL und ILE'S unter OS400 nicht mehr können.
Ja, ILERPG ist weit von Objektorientierung entfernt. Speicherverwaltung ist eher rudimentär.
Mit C++ oder Java kommt man vielleicht weiter.
Aber auch vom Greenscreen sollte man sich da langfristig verabschieden.
Allerdings:
Nie war die Belegerfasssung und Bearbeitung schnellr als mit dem Greenscreen. Seit Erfindung der Maus (die gabs auch für die IBM-Terminals) haben die User gelernt mit Hand-/Augekoordination die richtige Stelle auf dem Bildschirm zu treffen, was die Eingabegeschwindigkeit um mehrere Potenzen verlangsamt hat.
Bei den virtuellen Touch-Tastaturen vermisse ich auch schon mal die Pfeiltasten, mit denen man auch auf dem Tablet/Handy schnell navigieren kann.
Aber nun ist ja die KI auf dem Vormarsch. Nicht-Entwickler können inzwischen mit AI Programme schreiben, ansprechende Dialoge zaubern und grundlegende Funktionen bereitstellen.
Allerdings kommt diese KI bei komplexeren Aufgaben, bei denen vor allem Kreativität gefordert ist, schnell an ihre Grenzen.
Aktuell habe ich auch einen solchen Fall, wo ich nicht bereit bin, diese AI-Standalone-Lösung in unsere Softwarelandschaft einzubetten. Zumal dann zusätzliche Anforderungen immer eine grundlegende neue Lösung benötigen, die dann ebenso nicht integriert werden kann.
Und zu guter letzt:
Deine Funktionen C+D (WRKSPLF, CPYSPLF) lassen sich eben inzwischen (gefühlt seit 5 Jahren) mit SQL erledigen.
Ich liebe aber auch eher triggerbasierte Lösungen, sei es DTAQ's (kann man auch per SQL lesen) oder eben TABLE/PF-Trigger.
Ich habe mal eine Schnittstelle gebaut, in dem ein Client Daten via SQL in eine Tabelle geschrieben hat und mit demselben Befehl auch die Ergebnisse zurück erhält. Zusätzlich war ein Protokoll der Ereignisse gleich mit erledigt:
1: select * from final table (insert into mytable (f1, f2, ...) values(?, ?, ...)
2: Before-Insert-Trigger auf der Tabelle
3: Daten beschaffen, Aktionen auslösen, Ergebniss(e) in Variablen schreiben
4: Insert wird ausgeführt
5: Der Client erhält nach Erfolg sofort die Ergebnisse
6. Ggf. nun Commit/Rollback.
Es ist duchaus vergleichbar zu Services (SQL-Prozeduren) mit Ein + Ausgabeparametern. Allerdings spart man sich da das selber Schreiben und wieder lesen.
auf Grund meiner 56-jährigen IT-Erfahrung gehe ich davon aus, dass ein versierter Entwickler im Falle Deiner theoretischen Annahme erkennt, dass am Ende eine kurze Wartezeit Dein mukiertes Problem einfach löst.
Ein "versierter Entwickler" benutzt solchen Murks (output *print und CPYSPLF) schon seit Jahrzehnten nicht mehr, geschweige denn, dass er sowas empfiehlt.
D*B
Ich kenne genügend "versierte Entwickler", die auf dem Stand von vor 30 Jahren stehen geblieben sind, weil alles Neue zu kompliziert erscheint.