![[z/OS]](../images/ngzos.gif)
Zeitlimitüberschreitungen: Diagnosedaten analysieren
Die folgenden Richtlinien enthalten Anweisungen zur Lokalisierung von Diagnosedaten in einem SVC-Speicherauszug. Anhand dieser Daten können Sie festlegen, welche Zeitlimitüberschreitungen eingetreten ist.
- Formatieren Sie die TCB-Zusammenfassung für den Servant, der das zulässige Zeitlimit
überschritten hat:
ip summ format asid(x' Adresse ')
Dabei bezeichnet Adresse ist die Adressraum-ID des Servant.
Lokalisieren Sie den TCB mit dem Beendigungscode EC3. Ignorieren Sie jeden Beendigungscode EC3 im Hauptthread, d. h. im vierten in der Zusammenfassung aufgelisteten TCB (dem ersten nach den drei MVS-TCBs). Der Hauptthread von WebSphere wartet in BBO_BOA::impl_is_ready. In diesem Thread werden keine Anforderungen zugeteilt, daher ist kein Zeitlimit anwendbar. Bei der Zeitlimitverarbeitung wird der Hauptthread für die Server-Region ebenfalls mit EC3 als Verfahren zur Inaktivierung des Adressraums abnormal beendet. Daher kann der Beendigungscode EC3 im Hauptthread erscheinen. Dies ist jedoch keinesfalls die Ursache eines Zeitlimits, sondern ein Ergebnis der Zeitlimitverarbeitung.
- Ist der Beendigungscode EC3 in der TCB-Zusammenfassung nicht aufgeführt, prüfen Sie
den Systemtrace (systrace). Formatieren Sie den Systemtrace im GMT-Zeitformat,
da die anderen Zeitmarken, die Sie zum Vergleich verwenden, dieses Format haben. Zum
Formatieren im GMT-Format müssen Sie den folgenden Befehl
eingeben:
ip systrace all time(gmt)
Möglicherweise enthält auch der Systemtrace den Beendigungscode EC3 nicht, da er sich auf einen kurzen Zeitraum beziehen kann.
- Sie können auch den ip verbx mtrace oder das syslog prüfen, um festzustellen, ob das ABEND-Signal EC3 abgesetzt wurde. Sie benötigen diesen Zeitwert, um die Endzeit der Anforderung zu bestimmen, d. h. die GMT-Zeit, zu der der Zeitlimitwert erreicht wurde.
Ursachencode | Erläuterung |
---|---|
04130002 | Der Controller hat ein ABTERM-Signal für diese Servantregion ausgegeben, da ein Zeitlimit für die Transaktion eingetreten ist. Der Programmcode war möglicherweise ausgelastet. |
04130003 | Der Controller hat ein ABTERM-Signal für diese Servantregion ausgegeben, da beim Versuch, eine Controller-Anforderung in die Servantregion zu verschieben, eine Blockierung eingetreten ist. Die Zielanforderung hat ein Zeitlimit überschritten, aber der Servant war dabei, die Anforderung zu kopieren. Der Controller hat den Servant regelmäßig auf Fortschritt geprüft, bevor er ein ABTERM-Signal ausgegeben hat. |
04130004 | Der Controller hat ein ABTERM-Signal für diese Servantregion ausgegeben, da ein Zeitlimit für die WLM-Warteschlange eingetreten ist. Der Programmcode war möglicherweise ausgelastet. |
04130005 | Der Controller hat ein ABTERM-Signal für diese Servantregion ausgegeben, da ein Zeitlimit für die Transaktion eingetreten ist. Die Transaktion hat ein Zeitlimit überschritten, aber es wurde keine aktuelle, der Transaktion zugeordnete Anforderung gefunden. Der Servant, der der Transaktion zugeordnet ist, wird möglicherweise beendet. |
04130006 | Ein Controller-Thread hat beim Verarbeiten einer Anforderung einen Fehler ermittelt. Die Anforderung wurde für WLM in die Warteschlange gestellt und einer Servantregion zugeordnet. Die Beendigung der zugeordneten Servantregion ist erforderlich, um die Bereinigung der Anforderung durchzuführen. |
04130007 | Der Controller hat ein ABTERM-Signal für diese Servantregion ausgegeben, da ein Zeitlimit für die HTTP-Ausgabe eingetreten ist. Der Programmcode war möglicherweise ausgelastet. |
httpRequest,
httpsRequestoder
DispatchbyURI
protocol_http_output_timeout(HTTP) und
protocol_https_timeout_output(HTTPS) kein Faktor, der zu berücksichtigen ist. Mit anderen Worten, wenn die Anforderung eine Methode des Typs
DispatchbyURIist, wird die Anforderung über das RMI/IIOP-Protokoll empfangen, damit die Variablen des Typs
protocol_httpkeine Auswirkung haben.
Anschließend können Sie mit IPCS verbexit LEDATA und der Option CEEDUMP oder NTHREADS den Stack-Trace für diese Anforderung abrufen.