Warum bekomme ich mal ein joblog, mal nicht

[ILEMax]

Die Jobeinstellungen sind (im 1. Joblog sehe ich ja die submitteten Parameter) identisch.
Ein PRTF QPJOBLOG gibt es nur ein mal auf dem SYSTEM. Der ECHT Job erzeugt ein Joblog, am Ende des Jobs mit mehreren tausend Seiten, der TESTJOB erzeugt LOGS mit 255-260 Seiten.
Eine Codierung Test/Echt gibt es nicht. Auch die SBSD und die CLS beschreibungen sind annährend gleich. Der einzige Unterschied ist die Geschwindigkeit, mit der im Test LOG-Daten erzeugt werden.
Aber das kann es doch nicht sein. Wenn ich die laufenden Jobs vergleiche, oder die ersten Seiten der joblogs ... ALLES ist gleich! (außer Liblist und SBS)
Sch...lecht

Oder kann es sein, das der Job, der schnell viele Daten ezeugt 'Überläuft' der, der die Daten langsam bekommt aber immer durch Paging o.ä. genügen Platz für den Joblog hat und daher nicht 'Überläuft'?

[Christian Bartels]

Paging sollte keine Rolle spielen, weil sich die 64 MB Grenze auf virtuellen Speicher bezieht, nicht auf Hauptspeicher (RAM). Mein Gedankengang beim Lesen von http://www.ibm.com/support/docview.wss?uid=nas8N1018242 war wie folgt:

Angenommen, alle Joblog-Einträge im "ECHT"-Job bräuchten zusammen weniger als 64 MB Platz. Dann tritt der "PRTWRAP"-Fall nicht ein, und am Ende des "ECHT"-Jobs wird der gesamte Joblog in eine Spool-Datei mit mehreren tausend Seiten gestellt.

Im "Test"-Job werden dagegen aus irgendwelchen Gründen mehr Meldungen erzeugt, so dass die 64 MB nicht ausreichen und der "PRTWRAP"-Fall eintritt. Sobald die 64 MB-Grenze überschritten wird, wird 1 MB freigeräumt und gespoolt. Daraus ergibt sich eine Spool-Datei mit ca. 260 Seiten. Das freie MB wird relativ schnell wieder vollgeschrieben, und dann wird wieder eine Spool-Datei mit ca. 260 Seiten erzeugt und 1 MB freigeräumt. Dies setzt sich fort, bis der Job zu Ende ist. Ganz am Ende werden die letzten 63 bis 64 MB gespoolt, d.h. ganz am Ende müsste der Job nochmal eine Spool-Datei mit mehreren tausend Seiten erstellen.

Zu klären wäre, warum der Testjob mehr ins Joblog schreibt als der "ECHT"-Job, obwohl die Jobeinstellungen gleich sind. Wenn die Art der Nachrichten für "ECHT"- und Testjob gleich ist, könnte es dann sein, dass die Anzahl stark abweicht, weil die Testdaten anders aussehen? Wird im Test-Job vielleicht zwischendrin mal der Debugger angeschaltet? Dann würde die Datenbank wesentlich mehr Meldungen ins Joblog schreiben. Vielleicht muss man sich nicht nur die Daten am Jobanfang ansehen, sondern auch stichprobenartig in der Mitte und am Ende, um zu verstehen, wo die Unterschiede sind.

[ILEMax]

Ja, du hast recht. Wenn ich den letzten Test-Joblog-Spool ansehe, so hat der mehrere 1000 Seiten.
Dann wird das soetwas sein. Mehr Daten hat der Testjob bisher immer gehabt (ca. das doppelte)
Ich werde beim nächsten Test mal versuchen nur die Hälfte auf zu bereiten, dann dürfte der Job ja auch nur noch das große END Journal aufbereiten. Nächste Test dauert aber!
Erstmal vielen Dank!
der ILEMax

[Fuerchau]

Zur Laufzeit gibt es für Jobs keine Unterscheidung zwischen virtuellem um physischem Speicher (Einspeicherkonzept). Was nicht in den Hauptspeicher passt wird halt gepaged, egal ob DB, Programme oder Job-Speicher.
Soweit ich weiß bezieht sich die Speicherbegrenzung des Joblogs auf die Job-MSGQ. Wäre ja fatal wenn ich mehere 1000 Jobs habe und die sich 64 Jobs teilen.
Man bedenke, dass schließlich jede Nachricht in der Job-MSGQ aufgezeichnet wird!
Deswegen fragte ich ja nach der Zeitdifferenz zwischen den Spools.
Allerdings sagtest du ja, dass du alles in die DTAQ pumpst, also die Abstände dann doch gering ausfallen.

Für einen MSGQ-Überlauf sollte eigentlich auch eine Nachricht am Ende des Joblogs oder am Anfang des Folgejoblogs stehen.