[z/OS]

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.

Suchen Sie zunächst die Task mit dem ABEND-Signal EC3:
  1. 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.

  2. 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.

  3. 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.
Sie können bestimmen, welche Zeitlimitwerte wirksam sind, indem Sie den Ursachencode, der der EC3 zugeordnet ist, überprüfen.
Tabelle 1. Ursachencode und Erläuterungen. Sie können bestimmen, welche Zeitlimitwerte wirksam sind, indem Sie den Ursachencode, der der EC3 zugeordnet ist, überprüfen.
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.
Versuchen Sie, den Methodennamen herauszufinden, um festzustellen, ob es
httpRequest
,
httpsRequest
oder
DispatchbyURI
oder eine andere Methode war. Wenn die Anforderung nicht spezifisch ist und über die HTTP- oder HTTPS-Transporthandler behandelt wurde, sind die Zeitlimitwerte für
 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
DispatchbyURI
ist, wird die Anforderung über das RMI/IIOP-Protokoll empfangen, damit die Variablen des Typs
protocol_http
keine 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.


Symbol, das den Typ des Artikels anzeigt. Referenzartikel



Symbol für Zeitmarke Letzte Aktualisierung: 25.05.2016
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-nd-mp&topic=rtrb_analyzetimeout
Dateiname:rtrb_analyzetimeout.html