Reihenfolge Abarbeitung JOBQ

[TheDevil]

Hi,

Zitat : "Alle Jobs sind für 21:00:00 geplant." ... Heisst das das die PGM doch alle einzeln über den JOBSCDE gestartet werden ? Oder werden die PGM in EINEM "Tagesabschluss CL" an die JOBQ nacheinander übergeben ?
Gruß,
Ralf

[Starocotes]

Hallo,
welches Release ist denn auf der system i installiert ? Wurden vor kurzem Ptfs installiert ?

V6R1M0 ist installiert und wir haben tatsächlich vor kurzem PTFs installiert.
SF99601
SF99609
SF99610

Könnte also damit zusammenhängen.

Hi,

Zitat : "Alle Jobs sind für 21:00:00 geplant." ... Heisst das das die PGM doch alle einzeln über den JOBSCDE gestartet werden ? Oder werden die PGM in EINEM "Tagesabschluss CL" an die JOBQ nacheinander übergeben ?
Gruß,
Ralf

Letzteres, alle mit den Parametern
SCDDATE
SCDTIME
Auf dem selben Wert (aktueller Tag, 21:00:00)

[Fuerchau]

Wenn du alle Job's mit der selben Uhrzeit per SCDJOB einzeln in die JOBQ stellst wundert mich das schon dass es bisher immer geklappt hat;-).
Die Reihenfolge muss nicht auf Grund der Uhrzeit zwingend sequentiell in die JOBQ kommen.
Begründung:
Der Scheduler liest die Liste der Jobs sequentiell und submitted bei Erreichen der Uhrzeit den jeweiligen Job. Je nach dem, bei welchem Eintrag der Scheduler gerade ist und welche Uhrzeit gerade eintrifft, geht der Job in die QUEUE.
Möchtest du eine garantierte Reihenfolge solltest du die Jobs mit den Zeiten 21:00, 21:01, 21:02 ... starten lassen oder ein CLP um 21:00 Uhr starten, dass dann die gewünschten Jobs ohne Planungszeit submitted.

[Starocotes]

Nein, ich habe ein CL Programm wo viele SBMJOB's drin sind, das läuft nicht über den Scheduler.

Im SBMJOB kann ich ja zusätzlich noch die Paramter SCDDATE und SCDTIME angeben. Die sorgen aber nur dafür das keiner der Jobs VOR 21:00:00 startet.

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