Jason Java aufräumen

[holgerscherer]

... was zu KiloHertz CISC-Zeiten richtig war, muss zu GigaHertz RISC-Zeiten nicht mehr universell stimmen. Nichtsdestotrotz ist das Vielfach-starten von JVMs ein Kunstfehler und es wäre schon lange an der Zeit, dass IBM die Jobnummer auf BigInt aufbohrt.

Das stimmt immer noch, weil die Jobstrukturen nicht schlanker werden - und es gibt genug I/O, den man damit vermeiden kann. Gerade, wenn der Hauptspeicher zufällig etwas knapp ist.

Das mit der Jobnummer hatte ich schon mal. Bin krank daheim, könnte also noch RFEs schreiben. Aber ich schätze, da knallts wieder an diversen Parameter-Ecken.

[Fuerchau]

Man merkt es ja an den API's für Spoolfiles, da hat sich die Anzahl Spools je Job auch von 9999 auf int(9) erweitert.
Zumal die Jobtabelle eine Speichertabelle ist und die Jobnummer der relative Index. Beim Umlauf muss dann die nächste freie Jobnummer in den Lücken gefunden werden.
Da empfiehlt es sich ebenso, so wenig wie möglich Spools und damit auch Jobs aufzuheben.
Diese Diskrepanz kann man sehr schön zwischen WRKSYSSTS (Total Jobs) und WRKACTJOB sehen. Da werden schon mal gerne mehrere 10.000 Jobs aufgehoben, was nicht gerade zur Systemerleichterung dient.