Langläufer-Job - verflixter Zombie!
In der Jobübersicht ist ein Langläufer sichtbar - der läuft schon so lange, man mag es kaum glauben. Und siehe da, in der Workprozess-Übersicht ist er nicht zu finden (der Workprozess kann ja recht leicht über die Job-Details, "Ausführungsserver" / "WP-Nummer / PID" herausgefunden werden). Eine Statusprüfung ("Job" -> "Status") bleibt ohne Wirkung.
Und dann finden sich im Syslog auch noch so eigenartige Meldungen:
E06 Zusicherung Too may DB-rows. in Programm : //b Ort 001 nicht erfülltQ0E Signal 6 vom Betriebssystem empfangenQ02 Stop Workproc 9, Pid 15204606
Für den gleichen Zeitpunkt existiert ein Dump mit Abbruch-ID SYSTEM_CORE_DUMPED.
Ja, was ist denn hier los?
Nach einiger Suche hat sich die Ursache gezeigt:
Der Job hat eine Spolliste erzeugt, deren Speicherbedarf oberhalb der 2GB-Grenze liegt. Der Workprozess bricht dadurch ab.
Die Ursache für so eine große Spoolliste kann darin liegen, daß in den Druckparametern keine Markierung bei "Neuer Spool-Auftrag" gesetzt ist. Dadurch wird die Spoolausgabe an einen vorhandenen passenden Spoolauftrag angehängt.
SM37 > Job auswählen > Step auswählen > Button "Print Data" > Button "Properties" > Output Options > New Spool Request
Ein Seiteneffekt daraus ist auch, daß das Löschdatum immer weiter verschoben wird. So wird bei einem täglichen oder wöchentlichen Ablauf und einer Spoolreorganisation mit Fristen größer 1 bzw. 7 Tage die Spoolliste nie gelöscht und immer weiter vergrößert. Irgendwann wird dann die 2GB-Grenze erreicht.
Die Lösung besteht darin, den Spoolauftrag zu identifizieren und entweder in dessen Kopfdaten eine Markierung bei "Abgeschlossen, kein Anfügen mehr möglich" zu setzen...
SP01 > Spool-Auftrag auswählen > Goto > Request attributes
... oder den Spoolauftrag gleich zu löschen. Wer braucht schon eine Liste mit einem Volumen von 2 GB? Und damit das Problem nicht in einigen Tagen oder Wochen wieder auftritt, sollte die Ursache natürlich auch behoben und im Job in den Druckparametern eine Markierung bei "Neuer Spool-Auftrag" gesetzt werden (siehe Bild oben). Zur Identifikation des Spoolauftrages kann auch das Programm RSTS0014 (Große Spoolaufträge selektieren") genutzt werden.
Den Job-Status des Zombies kann man nur durch manuelles Ändern des Status in Tabelle TBTCO auf "A" (aborted) korrigieren (möglich z.B. mit SE16N (sofern verfügbar) oder mit "Shortcut for SAP Systems"). Die Statusprüfung in SM37 ("Job" -> "Status prüfen") zeigt keine Wirkung.
Es gibt noch keine Rezension.