Abfrage Jobq leer

[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