Reihenfolge Abarbeitung JOBQ

[TARASIK]

Hallo,
es gibt einen Apar der IBM dieser beschreibt genau Dein Problem, bzw. wir hatten das Problem bei einem Kunden von uns, aber R710.
Hier der Apar: http://www-912.ibm.com/n_dir/nas4apa...scheduled,jobs
In dem Apar gibt es keinen Hinweis auf das R610. Falls Du einen IBM Wartungsvertrag hast, dann eröffne einen Call mit dem Hinweis auf den Apar SE59123 und ob es einen Apar für R610 gibt. Gefunden habe ich aktuell keinen.

[Pikachu]

Works as designed.

Das "Problem" steht tatsächlich beim Parameter SCDTIME des Befehls SBMJOB beschrieben:

Die Reihenfolge, in der Jobeinträge mit identischen Werten für
SCDDATE und SCDTIME in der Jobwarteschlange erscheinen, kann sich
von der Reihenfolge unterscheiden, in der sie dort eingetroffen
sind. Ebenso kann die Reihenfolge, in der die Jobs die
Jobwarteschlange zur Verarbeitung verlassen, von der Reihenfolge
abweichen, in der sie eingegeben wurden. Es kann nicht davon
ausgegangen werden, dass Jobs, deren Start für denselben Zeitpunkt
geplant ist, nacheinander in die Jobwarteschlange gestellt oder
nacheinander verarbeitet werden.

Hier der Apar: http://www-912.ibm.com/n_dir/nas4apa...scheduled,jobs

[Starocotes]

Holy Fuck!

Habe dann mal eben die 44 Jobs per Hand geändert und werde dann nächste Woche das Programm anpassen was die absetzt.

Danke!

[Fuerchau]

Tja, Glück gehabt bisher.
Wenn du alles in einem CLP machst, dann reicht es das CLP zur gewünschten Uhrzeit zu starten.
Dieses submitted dann die Jobs in der gewünschten Folge ohne SCDTIME.
Dann werden die Jobs auch in der Folge aus der JOBQ heraus gestartet.

Wie die Beschreibung oben schon sagt, gilt hier das selbe wie für die SCDJOB's.
Durch sequentielle Bearbeitung der JOBQ für geplante Zeiten kann eben jeder beliebige Eintrag freigegeben werden.
Wenn die JOBQ aber gerade belegt ist, bleibt der Eintrag bis zum nächsten Zyklus drin und es könnte ein ganz anderer Job gestartet werden.

[Starocotes]

Scheinbar Glück (keine Ahnung ob da sonst schon was schief gelaufen ist).

Das aufrufende Programm ist ein RPG Programm was zuerst interaktiv Parameter empfängt (z.B. die Startzeit oder welche Jobs überhaupt aufgerufen werden sollen) also muss ich das doch mit dem hochzählen machen.

[Fuerchau]

Das Hochzählen hilft hier auch nicht!
Wenn der 1. Job länger als die 1 Minute benötigt, wird eben der nächst fällige wieder ausgeführt.
Dies kann aber der 21:02 statt 21:01-Job sein.

Du kannst dir die Jobs in eine eigene JOBQ submitten.
Die JOBQ setzt du auf Hold.
Dann startest du einen Job für 21:00 in einer anderen JOBQ.
Dieser Job hat nichts weiter zu tun als die erste JOBQ freizugeben.

Die Alternative:
Du merkst dir die aufzurufende Jobfolge in einer Tabelle (Datei).
Dann submittest du einen Job für 21:00 Uhr.
Dieser liest dann die Einträge und führt
a) direkt die CALL's
oder
b) die Submit's aus.

[Pikachu]

Das Hochzählen hilft hier auch nicht!
Wenn der 1. Job länger als die 1 Minute benötigt, wird eben der nächst fällige wieder ausgeführt.
Dies kann aber der 21:02 statt 21:01-Job sein.

Scheint laut IBM wohl doch zu helfen:

Circumvention
To control the order in which the jobs will be started, the date
and time values must be unique. For example, an application that
submits multiple jobs can increment the Schedule time (SCDTIME)
by one second for each job. The QIBM_QCA_CHG_COMMAND exit point
can be used when the application source is not available.

Quelle: http://www-912.ibm.com/n_dir/nas4apa...=Circumvention

[Fuerchau]

Es könnte reichen da ein SCDTIME-Job ja quasi in HOLD ist. Bei Erreichen der Zeit in Released (RLS) kommt aber auf Grund eines aktiven Job's der JOBQ noch warten muss.

[BenderD]

... selbstverständlich reicht das, sonst wäre die JOBSCD am Ende, wenn da ein Job auf St. Nimmerlein wartet, oder da ein HKGP Job submitted würde.

D*B

[AG1965_2]

Was ist denn ein "HKGP"-Job? HLDC hab' ich ja schon mal gehört - hier loopt der Chef - aber HKGP ist mir neu. :-)

[BenderD]

... das ist eine Abart, im wahrsten Sinne des Wortes, eines NEP (never ending programm).

[fpxx]

Auch bei einem meiner Kunden hatte ich dasselbe Problem; ich vermute aber, dass es mit V7R1 zusammenhängt; vorher hatten wir mehr als 20 Jahre(!) absolut kein Problem.
Vorgehensweise war wie oben beschrieben, dh. ein CL setzt hintereinander mehrere SBMJOB mit derselben SCDDAT/SCDTIME ab und die Abarbeitungs-Reihenfolge war ident mit der Reihenfolge der SBMJOB.
Nach Install. von V7R1 hat es manchmal funktioniert, manchmal aber nicht.