Logger Abended MODULE=IXGF2DEL,ABEND=S01C5,REASON=00000804

Document ID : KB000123508
Last Modified Date : 28/12/2018
Show Technical Document Details
Issue:
CA SYSVIEW 15.0, z/OS 2.2
We are experiencing a problem with the CICSLOGR.TSUM logger, it got the following abend:
IXG063I LOGGER ABENDED AND REQUESTED AN SVC DUMP WHILE PROCESSING 959 LOGSTREAM: CICSLOGR.TSUM.MVP1 STRUCTURE: **UNKNOWN** GROUP: **UNKNOWN**
MODULE=IXGF2DEL,
ABEND=S01C5,

REASON=00000804 IXG063I LOGGER ABENDED AND REQUESTED AN SVC DUMP WHILE PROCESSING 333 LOGSTREAM: CICSLOGR.TSUM.MVP1 STRUCTURE: **UNKNOWN** GROUP: **UNKNOWN** MODULE=IXGF2DEL,ABEND=S01C5,REASON=00000804

After that all information recorded on this loggers were missing also we have realized that many of their loggers (GDG) were deleled also. In the joblog of the sysview
I have found the following error previous this problem:
15.30.00 S0017762 GSV2802E (MVP1LOGR) IXGWRITE failed. R15=0301 15.30.00 S0017762 GSV2801I (MVP1LOGR) IXGWRITE FC:0301 RC:00000008 RSN:00000865 Token:DA4FDFC8.00000002 LS:CICSLOGR.TSUM.MVP1 .
Resolution:
A user, was logged into the SYSVIEW user address space and issued a series of 3 log stream record delete line commands from the CTRANSUM display. 

#1: 

DRO PRODAOR2 05/12/18 16:45:00 WTT8 

which resulted in this SYSVIEW command: 

LGDRO CICSLOGR.TSUM.MVP1 0000002669BAFE2A NOVERIFY NOCONFIRM 

#2: 

DRO PRODAOR2 05/12/18 16:45:00 CSSY 

which resulted in this command: 

LGDRO CICSLOGR.TSUM.MVP1 0000002669BCFCA3 NOVERIFY NOCONFIRM 

#3: 

DRO PRODAOR2 05/12/18 16:45:00 UEC8 

which resulted in this command: 

LGDRO CICSLOGR.TSUM.MVP1 0000002669BAFE2A NOVERIFY NOCONFIRM 

You can see from above, command #1 and command #3 are targeting the exact same log block ID (0000002669BAFE2A). You can also see that command #2 is deleting all record blocks older than 0000002669BCFCA3 (which includes 0000002669BAFE2A). On command #3, you are attempting to delete a log block that was deleted by command #2. This is why the system logger took ABEND=S01C5,REASON=00000804. 

I can see why there may be some confusion. After you issue the DRO command, SYSVIEW does not re-update the data on the command. This means there can be stale data on the screen. This is why you were still able to see the old record block that you previously deleted. If you had pressed enter to refresh the display, you would have seen that the log block you deleted is now gone. 

When this problem occurs, the system logger should not delete the GDGs that I am aware of. The system logger should recover and continue to process requests for reads and writes from the log stream. I find it odd that you are missing data. You may experience a period of time that the log stream is unresponsive while the system logger IXGLOGR is taking a dump. 

Also with regards to the dump being taken, this is not the default that SYSVIEW gives you out of the box. During the install of SYSVIEW, who ever defined the SYSVIEW log stream set the DIAG option to YES in the INST004x jobs. This is not a problem, but we have these set to NO by default to prevent unwanted dumps like this. You may want to consider running a IXCMIAPU job to set the DIAG option back to NO on your SYSVIEW log streams: 

//UPDATE01 EXEC PGM=IXCMIAPU 
//SYSPRINT DD SYSOUT=* 
//SYSIN DD * 
DATA TYPE(LOGR) REPORT(NO) 

UPDATE LOGSTREAM 
NAME(log.stream.name) 
DIAG(YES) 
/* 

I confirmed you have this set to YES in the dump: 

Report for Logstream: CICSLOGR.TSUM.MVP1 

LCB: 1ED51C68 
DSSEQ.... A0008119 

Logstream Available 
DUPLEX=YES 
SMF Buffer available 
Config 3 (Dasd-Only Type) Logstream 
Diag=Yes 
Recall offload data sets 

Store Thru mode 

Going forward, we will consider adding a REFRESH into the DRO line command to prevent a user from accidentally issuing a delete on a log block that does not exist in the log stream. For now, you should issue a refresh between DRO line commands to prevent this scenario from happening again.