SBMJOB mit RUNPTY

[Fuerchau]

Kurze Erklärung:
Job-Scheduling funktioniert mit einer sog. Zeitscheibe.

Das folgende ist ein vereinfachtes bildliches Modell:

Alle aktiven Jobs werden gleichmäßig auf diese Scheibe verteilt, wobei die Priorität quasi die Häufigkeit auf der Scheibe bestimmt.
Wenn die Prio 1 die höchste ist, dann wird "100 - Prio" gerechnet, ansonsten halt die Prio.
M.a.W: Bei der Prio 50 ist jeder Job 50 mal vertreten, bei Prio 51 dann 49 Mal.
Bei 1000 laufenden Jobs macht dies 49999 Einträge, also 999 x 50 + 1 x 49.
Hinzu kommt die Verteilung und auch ggf. Verschiebung von Jobs auf verschiedene CPU's, da jede CPU ihre Zeitscheibe verwaltet.

Somit lässt sich ausrechnen, wie stark der Prio 51-Job tatsächlich verlangsamt wird.

Hinzukommt, dass jede E/A-Aktion (Platte, Netzwerk, Geräte) den zugeteilten Zeitanteil unterbricht und der nächste Job in der Reihe drankommt. Die nicht verbrauchte Zeit wird nicht angespart sondern kommt dem Gesamtsystem zugute. Der Job wird erst wieder aktiv, wenn die E/A-Operation beendet ist und der Job in der Zeitscheibe wieder dran ist.

Zu sehen ist das Ganze dann bei WRKSYSSTS.
"Aktiv => Warten" = Jobs mit vorzeitigem Zeitscheibenende.
"Warten => nicht wählbar" = Jobs, deren E/A beendet ist aber in einer bestimmten Zeit laut Zeitscheibe noch nicht wieder dran waren.
"Aktiv => nicht wählbar" = Jobs, die ihre Zeitscheibe voll ausnutzen, aber in einer bestimmten Zeit noch nicht wieder dran waren.
Die letzten beiden Angaben können auf CPU-Engpässe hindeuten.

Bei DSPJOB kannst du die Laufzeit im Verhältnis zur verbrauchten CPU-Zeit eines Jobs ausrechnen.

[dschroeder]

Hallo Baldur. Danke für die wirklich gute Erklärung.

Das würde dann bedeuten, dass die Zahl bei runpty nicht nur die Reihenfolge der Jobs beeinflusst, sondern tatsächlich auch den Anteil an der Zeitscheibe mitbestimmt.
Wenn ich nur Jobs mit Prio 50 hätte und dann einen mit Prio 51 zusätzlich definieren würde, dann würde die Prio 51 bewirken, dass der Job öfter zum Zuge kommt, als wenn ich den Job mit 60 definieren würde. Das war mir bisher nicht klar. Ich dachte immer, die exakte runpty wäre egal und es ginge nur darum, welcher Job niedriger oder höher priorisiert ist.

[Fuerchau]

Nicht die Reihenfolge wird beeinflusst sondern der Anteil an der gesamt verfügbaren Zeit.
Prio 51 heißt, 1x weniger, da 1 die höchste Prio und 99 die niedrigste ist.

Wenn du also nur 2 Jobs hättest, käme Job 1 50 Mal, und Job 2 49 Mal innerhalb einer vorgegebenen Zeit dran.
Um Jobs gleichmäßig zu bedienen und die Zeit nicht unendlich ist, bekommt ein Job nur max. x Milli-/Microsekunden je Zeitscheibenanteil.

Bei diesen 2 Jobs hast du also 99 Anteile in einer vorgegeben Zeit zur Verfügung.
Interessant ist also eher die Differenz von 20 zu 80, wobei die IBM i i.M. 20 für Dialog und 50 für Batch wählt, in der Hoffnung, dass Dialogjobs i.d.R. ihre Zeitscheibe nie ausnutzen (warten auf den User), was die Problematik rechenintensiver Dialoge erklärt.

[dschroeder]

Vielen Dank. Man lernt nie aus ...

Dieter