IBM i: Jobs, Subsysteme und Joblogs – WRKACTJOB, WRKSBS, DSPJOBLOG und das sichere Beenden eines Jobs

Worum es geht

Jede Arbeitseinheit auf IBM i – eine interaktive 5250-Sitzung, ein Batch-Job, ein per SSH gestarteter PASE-Prozess, ein TCP/IP-Server-Job – läuft als Job innerhalb eines Subsystems. Ein Subsystem ist eine Laufzeitumgebung mit eigenen Speicherpools und Job-Warteschlangen (QINTER für interaktive Jobs, QBATCH für Batch-Jobs, QSYSWRK und QUSRWRK für viele Server-Jobs). WRKACTJOB listet alle aktuell aktiven Jobs über alle Subsysteme hinweg mit CPU- und Statusinformationen auf; WRKSBS listet die aktiven Subsysteme selbst auf.

Jeder Job führt ein Joblog: die ausgeführten Befehle sowie die empfangenen oder gesendeten Nachrichten. Es hilft bei der Diagnose, wenn sich ein CL-Befehl unerwartet verhalten hat. DSPJOBLOG zeigt das Log eines Jobs, der noch aktiv ist oder dessen Log noch aussteht (noch nicht ausgeschrieben wurde). Nach dem Ausschreiben liegt das Log als Spool-Datei QPJOBLOG dieses Jobs vor. DSPJOB oder WRKJOB können einen Job im Status aktiv, in der Job-Warteschlange oder in der Ausgabewarteschlange anzeigen, und WRKUSRJOB listet alle Jobs auf, die unter einem bestimmten Benutzerprofil übergeben wurden – aktiv, eingereiht oder mit ausstehender Ausgabe. Wie ausführlich das Log wird, steuern die Protokollierungsstufe (Message Logging Level) und die Textattribute der Jobbeschreibung.

Systemweite Operatornachrichten – Meldungen zum Start und Stopp von Servern, Geräte- und Kommunikationsfehler, Sicherheitswarnungen – landen in der Nachrichtenwarteschlange QSYSOPR und nicht im Log eines einzelnen Jobs. DSPMSG QSYSOPR zeigt sie an; über das PASE-Dienstprogramm system (siehe den Artikel zu SSH/PASE) ist das auch in einer SSH-Sitzung aus der Ferne möglich.

Einen Job zu beenden bedeutet nicht einfach, ihn abzuschiessen: ENDJOB verlangt einen OPTION-Wert. OPTION(*CNTRLD), der Standardwert, fordert den Job auf, sich innerhalb der DELAY-Zeit (Standard: 30 Sekunden) kontrolliert zu beenden. Hat der Job einen Signal-Handler registriert und Interesse an asynchronen Signalen angemeldet, erzeugt das Betriebssystem das Signal SIGTERM, damit die Anwendung aufräumen kann; erst nach Ablauf der Verzögerung wird die Beendigung erzwungen. OPTION(*IMMED) überspringt diese kooperative Phase und beendet den Job sofort, ohne Garantie für SIGTERM – das ist nur für einen Job angemessen, der bereits hängt oder nicht mehr reagiert.

Warum es wichtig ist

Ein Agent, der Jobsteuerung skriptet, muss unterscheiden zwischen „dieser Job soll sauber heruntergefahren werden“ (*CNTRLD, mit einer Verzögerung, die für jedes Aufräumen in mehreren Threads ausreicht) und „dieser Job hängt und muss weg“ (*IMMED). Ausserdem muss er wissen, in welcher Nachrichtenwarteschlange – im eigenen Joblog oder in QSYSOPR – sich die Hinweise auf die Fehlerursache tatsächlich finden.

So wird es angewendet

• Einen Job vor jedem Eingriff mit WRKACTJOB oder WRKUSRJOB user-id ermitteln, statt eine Jobnummer zu raten.
• Den vollqualifizierten Namen verwenden: ENDJOB JOB(number/user/name) OPTION(*CNTRLD) DELAY(nnn); ein blosser Jobname kann auf mehrere Jobs passen. *IMMED nur für Jobs einsetzen, die auf ein kontrolliertes Beenden nicht reagieren. Um Jobs anderer Benutzer zu beenden, ist in der Regel die Sonderberechtigung *JOBCTL nötig.
• DSPMSG QSYSOPR auf Fehler auf Systemebene prüfen (Server ausgefallen, Gerätefehler), die im Joblog eines Anwendungsjobs nicht erscheinen.
• Ist ein Joblog dünn, vor der Annahme, es sei nichts passiert, die Protokollierungsstufe in der Jobbeschreibung prüfen.

Stolpersteine

• Einen Job mit mehreren Threads mit einer zu kurzen Verzögerung beenden, sodass die Threads SIGTERM nicht bemerken und nicht aufräumen können; das wird dann nur zu einem langsameren *IMMED.
• Einen Start- oder Serverfehler im Joblog suchen, obwohl er in QSYSOPR gemeldet wurde.