Fehlerunterlagen erstellen

Zur Fehlerdiagnose sind folgende Angaben nötig:

• Genaue Beschreibung der Fehlersituation

• Angabe der Versionsstände der beteiligten Software

• Genaue Angabe des Rechnertyps

Die Fehlerunterlagen sollten möglichst vollständig vorhanden sein. Als Fehlerunterlagen können dienen:

• UTM-Dumps von allen Workprozessen sowie zugehörige „gcores“ auf Unix- und Linux-Systemen.

• Die SYSLOG-Datei(en) (siehe "UTM-Protokolldatei SYSLOG").

• Die stdout- und stderr-Protokolle aller UTM-Prozesse.

• Die stdout-, stdin- und stderr-Protokolle der KDCDEF-Generierung und die Startprozedur einschließlich der Startparameter.

• Alle Binderlisten, Übersetzungslisten und Übersetzungsprozeduren.

• Bei Fehlern, die in Zusammenhang mit der UTM-Netzanbindung stehen, können zusätzlich folgende Unterlagen erstellt werden:

  • Meldungen der UTM-Netzprozesse auf stdout und stderr

  • CMX-Traces

  • dynamischer openUTM-Trace, siehe "Dynamischer openUTM -Trace über Umgebungsvariable"

  Wie Sie CMX-Traces erzeugen, entnehmen Sie den CMX-Handbüchern.

• Bei Fehlern in UTM-Cluster-Anwendungen werden zusätzlich folgende Unterlagen benötigt:

  • Alle Cluster-globale Dateien, Protokolle (und DUMPs) aller Knoten-Anwendungen

  • Die Cluster-Konfigurationsdatei und bei administrativen Problemen auch alle Dateien des Administrations-Journals mit Suffix JKAA, JRN1, JRN2.

  • Bei Problemen, die durch das Zusammenspiel der Knoten-Anwendungen verursacht wurden, die Protokolldateien von allen anderen Knoten-Anwendungen

  • Die Startprozedur und die bei der UTM-Generierung als EMERGENCY-CMD und FAILURE-CMD angegebenen Prozeduren

  • Bei Problemen zu Benutzern (z.B. Anmeldeprobleme) auch die Cluster-User-Datei (d.h. die Datei mit dem Suffix UTM-C.USER)

• Nur auf Unix- und Linux-Systemen:

  Eine Auswertung der core-Datei des Prozesses, der das Problem verursacht hat - falls vorhanden. Eine Auswertung einer core-Datei erfolgt mit einem Debugger. Eine wichtige Information dabei ist die Aufrufhierarchie, die zu dem Problem geführt hat.

  core-Dateien werden nur geschrieben, wenn dies mit dem Kommando ulimit entsprechend konfiguriert ist. Standardmäßig werden im Fehlerfall meist keine core-Dateien geschrieben.

  Sie können mit dem Kommando ulimit -a überprüfen, ob vollständige core-Dateien geschrieben werden, z.B.:

  ulimit -a
  core file size          (blocks, -c) unlimited
  ....
  

  Der Wert unlimited für die Größe zeigt an, dass immer vollständige core-Dateien geschrieben werden. Wird dagegen als Größe 0 angezeigt, dann werden keine core-Dateien erzeugt.

  Mit dem Kommando ulimit -c unlimited kann das Schreiben von vollständigen core-Dateien erlaubt werden.

Vorgehen bei Fehlern

• Bei Vorgangsabbruch/Anwendungsabbruch gehen Sie wie folgt vor:

  1. UTM-Dump auswerten mit dem Tool KDCDUMP, siehe "Das Tool KDCDUMP".

  2. Fehler reproduzieren unter Verwendung geeigneter Debugger wie z.B.

     • dbx, sdb, adb, xdb, gdb, debug auf Unix- und Linux-Systemen

     • bzw. dem in Microsoft Visual Studio integrierten Debugger auf Windows-Systemen.

  3. Aufrufhierarchie beim core-Schreiben mit Hilfe eines Debuggers ermitteln.

     Wenn Sie mit der Beispielanwendung arbeiten, können Sie sich diese Aufrufhierarchie auf Unix- und Linux-Systemen von dem Shell-Skript p/stack anzeigen lassen.

• Abbruch mit Signalen

  Trat ein PENDER-Dump mit 70Z/XT10 oder XT11 oder Anwendungsabbruch mit SIG010/SIG011 (Signal SIGBUS/SIGSEGV) auf, sollte die UTM-Signalbehandlung mit dem Startparameter START STXIT=OFF ausgeschaltet werden.

  Der Startparameter STXIT=OFF bewirkt, dass das System nach einem fehlerhaften Befehl

  • sofort (ohne Verzögerung durch openUTM) einen core-Dump erzeugt und den Prozess ohne UTM-Dump beendet (Unix- und Linux-Systeme).

  • bzw. automatisch den Debugger startet (Windows-Systeme)

  Vor dem nächsten Neustart müssen Sie auf jeden Fall KDCREM aufrufen, da openUTM bei STXIT=OFF keine Prozessende-Behandlung durchführt.

• Nach Startfehlern wie z.B. Fehlernummer 32 oder 40 muss vor einem erneuten Start das Tool KDCREM aufgerufen werden.