View Full Version : Abfrage Jobq leer
programmer400
28-03-25, 14:25
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?
Glaub die Jobq reicht nicht. Nur weil die JOBQ leer ist, können noch (in deinem Fall) bis zu 3 Jobs laufen, die die Daten sichern. Die siehts du im Subsystem aber nicht mehr in der JOBQ.
Also müsstest du auch die Jobs im Subsystem beachten. z.B. per SQL:
https://www.rpgpgm.com/2020/06/subsystem-status-using-sql.html
Gibts inzwischen per SQL:
https://www.ibm.com/docs/en/i/7.4?topic=services-job-queue-entries-view
https://www.ibm.com/docs/en/i/7.4?topic=services-active-job-info-table-function
Da die Jobs hoffentlich alle denselben Namen haben, kannst du mit dem Namen danach filtern.
Einfach IBM i ohne Neustart durchlaufen lassen!?
Wenn alle jobs abgearbeitet sind, soll noch ein Befehl laufen (z.B. reboot System). (…)
Oder denk ich da falsch und es gäbe andere Möglichkeiten?
programmer400
29-03-25, 08:52
Einfach IBM i ohne Neustart durchlaufen lassen!?
Geht nicht nur um Neustart, es soll ein Mail mit Protokolldatei geschickt werden, wenn alles fertig gelaufen ist.
programmer400
29-03-25, 09:03
Gibts inzwischen per SQL:
https://www.ibm.com/docs/en/i/7.4?topic=services-job-queue-entries-view
https://www.ibm.com/docs/en/i/7.4?topic=services-active-job-info-table-function
Da die Jobs hoffentlich alle denselben Namen haben, kannst du mit dem Namen danach filtern.
Vielen Dank, thats it :-)
... schon wieder so ein Graberjob, der rumrödelt und nix tut und am Ende auf Dinge wartet, die schon fertig sind.
Auf etwas geduldig warten und unmittelbar zuschlagen, wenn etwas fertig ist, macht man über Sperren oder Nachrichten.
D*B
KingofKning
02-04-25, 10:18
... schon wieder so ein Graberjob, der rumrödelt und nix tut und am Ende auf Dinge wartet, die schon fertig sind.
Auf etwas geduldig warten und unmittelbar zuschlagen, wenn etwas fertig ist, macht man über Sperren oder Nachrichten.
D*B
Das ist Old School Herr Dinosaurier. ;-)
Heute hat die Kiste mehr Wumms als meine D02 je von zu träumen wagte.
GG 2250
Trotzdem muss man sich nur vorstellen, wie die neuen SQL-Views arbeiten, da die Daten nicht als Tabelle vorliegen sondern erst eben die API's bemüht werden, um diese dann als dynamische Sicht darzustellen.
Wenn man die API's selber bemühen würde, wäre das auch schneller.
Dieter kann ich aber auch verstehen. Denn die parallelen Jobs, die von einem andere Job in einer vorgegebene Anzahl gestartet werden, könnten am Ende einen Zähler in einer Tabelle rauf- oder runterzählen und bei Erreichen des Ziels kan ein Trigger dann den nächsten Folgejob starten. Somit ist ein permanenter Überwachungsjob dann vollkommen unnötig.
Das hat dann mit Oldschool nun gar nichts zu tun.
KingofKning
02-04-25, 11:13
Das hat dann mit Oldschool nun gar nichts zu tun.
Sehe ich etwas anders.
Zu Zeiten als ich noch im Team COBOL geschrieben habe, habe ich mit dem Kollegen manchmal stundenlang über den besten Weg gestritten.
Mit dem Ergebnis das wir auch Jahre später noch glücklich mit der Lösung waren.
Der Lösungsansatz der hier beschrieben Problemstellung sieht für mich nicht nach lange drüber nachgedacht aus. Warum auch immer.
Sprich Old School ist für mich viel Erfahrung und einen Optimalen Lösungsansatz zu wählen anstatt Maschinenpower zu verschwenden.
Aber ohne Bier ist das Diskutieren darüber blöd, und jeder soll auf seine Weise Glüklich werden.