Abfrage Jobq leer

[programmer400]

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?

[TR1]

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/subsy...using-sql.html

[Fuerchau]

Gibts inzwischen per SQL:

https://www.ibm.com/docs/en/i/7.4?to...e-entries-view
https://www.ibm.com/docs/en/i/7.4?to...table-function

Da die Jobs hoffentlich alle denselben Namen haben, kannst du mit dem Namen danach filtern.

[Pikachu]

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]

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]

Gibts inzwischen per SQL:

https://www.ibm.com/docs/en/i/7.4?to...e-entries-view
https://www.ibm.com/docs/en/i/7.4?to...table-function

Da die Jobs hoffentlich alle denselben Namen haben, kannst du mit dem Namen danach filtern.

Vielen Dank, thats it :-)

[BenderD]

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

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

[Fuerchau]

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]

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.

[Pikachu]

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ß?

[BenderD]

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