Fehlermanagement und E-Recording

Transkript

1 Fehlermanagement und E-Recording E-Recording steht für zentrale Fehlerregistrierung. Welcher Betreiber großer IT-Infrastrukturen hat sich nicht schon einmal gewünscht Fehler, die Programme feststellen oder verursachen und Anwendungen oder ganze Systeme lahmlegen, möglichst verzugslos zentral sammeln und abfragen zu können? Die Berichtswege, bis ein Fehler gemeldet ist, erfasst, weitergeleitet, analysiert und behoben wird, sind in der bürokratisch geprägten Arbeitswelt großer Unternehmen meist sehr lang und manchmal dauert es daher Tage, bis ein Fehler erkannt und behoben wird. Was tut E-Recording Es gibt Daten zu Fehlern aus Batch, DB2-, IMS- oder CICS-Anwendungen an einer zentralen Stelle aus. Diese zentrale Stelle kann wahlweise eine DB2 Tabelle, die Spool (SYSPRINT) oder beides sein. Das DB2 Subsystem muss nicht das selbe sein, wie das, welches die Anwendung referiert. Z.B. kann eine produktive Stored Procedure (STP) erkannte Fehler im DB2-System für Qualitätssicherung ausgeben. Es gibt Daten in DB2 auch dann aus, wenn die Anwendung einen Rollback ausführt. Die Fehlertexte können Variablen enthalten, deren Inhalte zur Ausführungszeit in den Text eingebaut werden Es generiert beim Preprocessing die Fehlertexte für die Dokumentation. Gibt das SQL-Statement bei dem ein Fehler aufgetreten ist als Text mit aus (optional) oder Gibt die DB2-Fehlernachricht aus (optional) Wenn der externe Logger nicht gestartet wurde gehen die Daten trotzdem nicht verloren Beantwortet die Fragen nach - Wo (auf welchem System) ist der Fehler aufgetreten - in welchem Subsystem - in welchem Projekt - welcher Job, welches Programm oder Unterprogramm hat den Fehler festgestellt - wie oft ist der Fehler aufgetreten - wann ist der Fehler zuletzt registriert worden - welcher Return- und Reasoncode wurde vergeben - gibt es einen Kurzdump zu dem Fehler - war es ein IMS / DL/1 Fehler, wenn ja mit welchem Statuscode - ist es ein DB2 Fehler gewesen, wenn ja mit welchem SQL-Code - wie sah das SQL-Statement aus, das den Fehler verursacht hat - ist der Fehler schon einmal korrigiert worden, wenn ja, wann und von wem

2 Wie funktioniert E-Recording E-Recording wurde für Anwendungen im SYSPLEX entwickelt mit dem Ziel, Fehler möglichst aller Mainframeanwendungen zentral zu erfassen, strukturiert zu speichern und Mehrfachmeldungen zu vermeiden. Es lag nahe, DB2 zu benutzen, um Probleme und Lösungen zu verwalten und gezielt abfragen zu können. Das Problem aber war, dass nicht alle Anwendungen auch DB2- Anwendungen sind und dass Fehler in DB2 nur dann registriert werden können, wenn die verursachende Anwendung nach dem Auftreten des Fehlers keinen ROLL Back ausführt. In E-Recording sind diese Probleme auf elegante Art gelöst. Es wurde folgender Ablauf entwickelt: Die Anwendung stellt einen Fehler fest und stellt in einer Struktur die entsprechenden Daten bereit. Ein Interface ergänzt Daten, wie die SSID des Subsystems und legt die Daten in Speicherbereichen ab, die nicht von einem Rollback zurückgesetzt werden. Die Anwendung bekommt die Kontrolle zurück und arbeitet entweder weiter, führt einen Rollback aus, oder terminiert abnormal. Die zwischengespeicherten Daten sind davon nicht betroffen. Ein timergetriggerter, asynchroner Listener, der External Logger, ist als eigenständige Task mit einem DB2 System (dem Zielsystem) im SYSPLEX verbunden. Dieser Listener kann als Batchprogramm oder started task ausgeführt werden. Er prüft nach jedem Ablauf eines einstellbaren Zeitintervalls, ob Daten für ihn abgelegt wurden. Er liest diese Daten aus und speichert sie in der dafür vorgesehenen Tabelle, nicht ohne zuvor nachgesehen zu haben, ob nicht die gleiche Fehlermeldung bereits registriert wurde. In diesem Fall werden nur ein Error Counter hochgezählt und ein Timestamp aktualisiert. Anschließend erfolgen ein Commit und die Freigabe der Datenbereiche.. Danach geht der Logger wieder in den Sleep Modus. Die in der Tabelle hinterlegten Daten können von einem Serviceteam oder Programmierern nach unterschiedlichsten Kriterien abgefragt werden. Die Lösung des Problems kann in der selben Tabelle abgelegt werden und steht somit bei einem neuerlichen Auftreten des Fehlers zur Verfügung. E-Recording besteht aus Einer DB2 Tabelle, einem Interface für Anwendungen, einer einfachen Datenschnittstelle, dem externen Logger.

3 E-Recording ist in jedes DB2 Subsystem eines Mainframe integrierbar und kann von jedem der Zugriff auf diese Tabelle hat abgefragt werden. E-Recording könnte auch aus der dezentralen Welt benutzt werden. Das setzt allerdings andere Transportmechanismen voraus (z.b. MQ-Series). Fehlermeldungen per weiterleiten. Diese Features sind bislang nicht implementiert.

4 Beispiel Aufruf des E-Recording aus einem CICS PL/1 Programm: /********************************************************************/ /* FEHLERBEHANDLUNG */ /********************************************************************/ IF SQLCODE = 0 THEN EREC = PRM_VAL; /* ERRORRECORDING */ ELSE DO; /* SONST USE DEFAULT */ IF SQLCODE ^= 100 THEN DO; /* FEHLER */ $ERRMSG /* */ $JOB(APPLID) /* */ $PGM('TANGO01') /* */ $RCD(8) /* */ $RSN(16) /* */ $TBL('TANGO.XPRM') /* */ $SQLCD(SQLCODE) /* */ $STMT(*) /* */ $MOD('TANGO01') /* */ $ERRID('TANGO011') /* */ $MSG(SQLERRM); /* */ END; /* */ END; /* */ Standardausgabe (SYSPRINT) des external Logger nach dem Hochfahren EXTERNAL LOGGER: CONNECTED TO SUBSYSTEM..:DSN1 DB2 PLAN...:LOGGER TIME INTERVAL...:0005 SEC PRINT OPTION...:Y TABLE OPTION...:Y Der external Logger läuft als Server (Batch oder Started Task) unter z/os. und führt einen CONNECT zu dem ihm vorgegebenen DB2 Subsystem (hier DSN1) aus. Das Zeitintervall ist auf 5 Sekunden eingestellt, d.h. der Listener prüft im Abstand von 5 sec, ob inzwischen in irgendwelchen Anwendungen Fehler aufgetreten sind, die auf SYSPRINT und / oder der vorgegebenen DB2 Tabelle darzustellen sind. Das Beispiel gibt vor, dass diese Fehler sowohl auf SYSPRINT als auch in der DB2 Tabelle auszugeben sind (OPTIONs).

5 Das folgende Beispiel zeigt 2 Fehlernachrichten, die auf SYSPRINT des external Loggers ausgegeben wurden: A06CICS TANGO01 TANGO01 TANGO011..TANGO01.19B749BF182B6B60 TANGO TANGO011 RC = 8, RSN = 16, STATCD =" " TANGO011 SQLCODE = TANGO011 TABLE = TANGO.XPRM TANGO011 SQLSTMNT = EXEC SQL SELECT * INTO :XPRM FROM TANGO.XPRM WHERE PRM_ID = :PRM_ID AND PRM_NR = 1 ; A06CICS TANGO01 TANGO01 TANGO012..TANGO01.19B749BF182B6B60 TANGO TANGO012 RC = 8, RSN = 16, STATCD =" " TANGO012 SQLCODE = TANGO012 TABLE = TANGO.XWRK TANGO012 SQLSTMNT = EXEC SQL SELECT * INTO :DCLXWRK FROM TANGO.XWRK WHERE CICS_LTM = :CICS_LTM ; ******************************* BOTTOM OF DATA ******************************** Die Fehlernachrichten enthalten: Datum und Uhrzeit wann die Fehler aufgetreten sind das Subsystem in dem der Fehler auftrat (hier A06CICS) Haupt- und Unterprogramm in dem die Fehler festgestellt wurden (beide TANGO01) die Error IDs (TANGO011, TANGO012) DB2 Fehlertexte Return und Reasoncode (beide 16 und 8) den DL/1 Statuscode (hier Blank, da kein DL/1) die SQL-Codes (beide -805) die Tabellen, bei welchen die Fehler auftraten (TANGO.XPRM und TANGO.XWRK) Die SQL-Statements, dieser Fehlern Der Ausgabefile kann bei laufendem Betrieb unter SDSF oder EJES eingesehen werden. Der maximale Zeitversatz der Ausgabe beträgt 5 Sekunden.

6 Die in der DB2 Tabelle CALYPSO.FREC registrierten Fehler können mit SQL nach unterschiedlichen Kriterien selektiert werden. Im folgenden Beispiel wurde die Abfrage über SPUFI gestartet und das Ergebnis aus Platzgründen untereinander dargestellt. Die Inhalte sind jedoch identisch mit denen der Druckausgabe SELECT * FROM CALYPSO.FREC WHERE ERR_DATE >= ' ' ; ERR_DATE ERR_JOB ERR_PGM ERR_MODULE ERR_ID ERR_MSG A06CICS TANGO01 TANGO01 TANGO011..TANGO A06CICS TANGO01 TANGO01 TANGO012..TANGO01. DSNE610I NUMBER OF ROWS DISPLAYED IS RETCD RSNCD STACD TABLE SQLSTMNT TANGO.XPRM EXEC SQL SELECT * INTO :XPRM FROM 8 16 TANGO.XWRK EXEC SQL SELECT * INTO :DCLXWRK FR SELECT * INTO :XPRM FROM TANGO.XPRM WHERE PRM_ID = :PRM_ID AND PRM_NR = 1 ; SELECT * INTO :DCLXWRK FROM TANGO.XWRK WHERE CICS_LTM = :CICS_LTM ; Der Unterschied zur Ausgabe auf SYSPRINT ist, dass die registrierten Fehler erhalten bleiben, solange sie nicht explizit gelöscht werden.