z/OS-Protokolldatenströme
Die z/OS-Systemprotokollfunktion (Logger) unterstützt Datensammlungen, so genannte Protokolldatenströme, die in lokale Speicherpuffer und anschließend eine Coupling-Facility des Sysplex oder zur Langzeitspeicherung auf eine DASD-Einheit geschrieben werden. Protokolldatenströme ermöglichen bestimmten Anwendungen eine Hochleistungsprotokollierung.
Allgemeine Informationen zu Protokolldatenströmen finden Sie in der Veröffentlichung z/OS Setting Up a Sysplex (IBM Form SA22-7625).
Fehlerprotokoll von WebSphere Application Server
Im Fehlerprotokoll von WebSphere Application Server werden detaillierte Laufzeitfehler- und Statusnachrichten aufgezeichnet. Wenn die Variable "ras_log_logstreamName" gesetzt ist, werden Fehlerprotokollnachrichten in den benannten z/OS-Protokolldatenstrom geschrieben. Wenn die Variable "ras_log_logstreamName" nicht gesetzt ist oder der benannte Protokolldatenstrom nicht vorhanden ist, werden Fehlerprotokollsätze nach STDERR geschrieben.
Der Hauptvorteil des Sendens des Fehlerprotokolls von WebSphere Application Server an einen z/OS-Protokolldatenstrom ist die Möglichkeit, Fehlerprotokolle mehrerer Server und Servant-Regionen konsolidieren zu können. Wenn Sie den Fehlerprotokolldatenstrom in eine Coupling-Facility schreiben, können Sie auch die Fehlerprotokolle unterschiedlicher Systeme in demselben Sysplex konsolidieren.
- Erstellt einen Coupling-Facility-Protokolldatenstrom für das Fehlerprotokoll von WebSphere Application Server.
- Erstellt einen reinen DASD-Protokolldatenstrom für das Fehlerprotokoll von WebSphere Application Server.
Nachdem Sie den Protokolldatenstrom erstellt haben, können Sie über Scripting oder die Administrationskonsole die Variable "ras_log_logstreamName" auf den Namen des Protokolldatenstroms für alle Server setzen, deren Ausgabe in den neu erstellten Protokolldatenstrom geschrieben werden soll.
Verwenden Sie das Script BBORBLOG in der SBBOEXEC-Profildatei, um das Fehlerprotokoll anzuzeigen. Weitere Informationen finden Sie im Abschnitt Inhalt des Fehlerprotokolls mit dem Log Browse Utility anzeigen im Information Center.
Partnerprotokoll für Transaktionen (XA)
Wenn Sie einen z/OS-Protokolldatenstrom für das Transaktionsprotokoll von WebSphere Application Server verwenden und diesen Protokolldatenstrom in einer Coupling-Facility speichern, können Sie damit die Leistung von systemübergreifenden Neustartoptionen verbessern.
- Erstellt einen Coupling-Facility-Protokolldatenstrom für ein Transaktionsprotokoll von WebSphere Application Server.
- Erstellt einen reinen DASD-Protokolldatenstrom für ein Transaktionsprotokoll von WebSphere Application Server.
Nachdem Sie den Protokolldatenstrom erstellt haben, verwenden Sie die Administrationskonsole, um auf der Registerkarte "Konfiguration" in der Anzeige mit den Einstellungen für Servertransaktionsservices (Server > Servertypen > WebSphere-Anwendungsserver > Servername > Containerservices > Transaktionsservice) das Transaktionsprotokoll eines einzelnen Servers auf logstream://Name_des_Protokolldatenstroms zu setzen, und starten Sie anschließend den Server neu. Weitere Informationen finden Sie im Abschnitt Einstellungen des Transaktionsservice im Information Center.
Protokolldatenstrom für SIP-Wiederherstellung erstellen
Wenn die Konfiguration Ihrer Network-Deployment-Zelle Replikationspartner mit verschiedenen LPARs enthält, müssen Protokolldatenströme für die SIP-Wiederherstellung in einer Coupling-Facility enthalten sein. DASD-Wiederherstellungsprotokolldatenströme können nur verwendet werden, wenn alle Replikationspartner denselben LPAR verwenden.
SIP-Protokolldatenströme müssen einem ganz spezifischen Beispiel hinsichtlich der Namen folgen: Zellenname.Servername.D und Zellenname.Servername.M.
Es können Fehler auftreten, die auf einen vollen oder beschädigten Protokolldatenstrom hinweisen. In solchen Fällen müssen Sie den Protokolldatenstrom unter Umständen löschen und erneut definieren. Die folgenden Beispiele zeigen Jobs, mit denen diese Aktionen ausgeführt werden können:
//DEFLOGA JOB MSGLEVEL=(1,1),MSGCLASS=H,NOTIFY=&SYSUID,REGION=0M
//*
//LOGDEFN EXEC PGM=IXCMIAPU,REGION=4M
//SYSPRINT DD SYSOUT=*
//*
//SYSIN DD *
DATA TYPE(LOGR)
DELETE LOGSTREAM
NAME(WT0CELL.WT0S000.M)
DELETE LOGSTREAM
NAME(WT0CELL.WT0S000.D)
DELETE LOGSTREAM
NAME(WT0CELL.WT0S001.M)
DELETE LOGSTREAM
NAME(WT0CELL.WT0S001.D)
/*
//DEFLOGA JOB MSGLEVEL=(1,1),MSGCLASS=H,NOTIFY=&SYSUID,REGION=0M
//*
//LOGDEFN EXEC PGM=IXCMIAPU,REGION=4M
//SYSPRINT DD SYSOUT=*
//*
//SYSIN DD *
DATA TYPE(LOGR)
DEFINE LOGSTREAM
NAME(WT0CELL.WT0S000.M)
DASDONLY(YES)
HLQ(LOCAL) MODEL(NO)
LS_SIZE(2048)
STG_SIZE(2048)
LOWOFFLOAD(60)
HIGHOFFLOAD(80)
DEFINE LOGSTREAM
NAME(WT0CELL.WT0S000.D)
DASDONLY(YES)
HLQ(LOCAL) MODEL(NO)
LS_SIZE(2048)
STG_SIZE(2048)
LOWOFFLOAD(60)
HIGHOFFLOAD(80)
DEFINE LOGSTREAM
NAME(WT0CELL.WT0S001.M)
DASDONLY(YES)
HLQ(LOCAL) MODEL(NO)
LS_SIZE(2048)
STG_SIZE(2048)
LOWOFFLOAD(60)
HIGHOFFLOAD(80)
DEFINE LOGSTREAM
NAME(WT0CELL.WT0S001.D)
DASDONLY(YES)
HLQ(LOCAL) MODEL(NO)
LS_SIZE(2048)
STG_SIZE(2048)
LOWOFFLOAD(60)
HIGHOFFLOAD(80)
/*
//