Logger Abended MODULE=IXGF2DEL,ABEND=S01C5,REASON=00000804
Article ID: 123508
Updated On:
Products
Issue/Introduction
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.xxxx STRUCTURE: **UNKNOWN** GROUP: **UNKNOWN**
MODULE=IXGF2DEL,
ABEND=S01C5,
REASON=00000804 IXG063I LOGGER ABENDED AND REQUESTED AN SVC DUMP WHILE PROCESSING 333 LOGSTREAM: CICSLOGR.TSUM.xxxx 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 (xxxxLOGR) IXGWRITE failed. R15=0301 15.30.00 S0017762 GSV2801I (xxxxLOGR) IXGWRITE FC:0301 RC:00000008 RSN:00000865 Token:DA4FDFC8.00000002 LS:CICSLOGR.TSUM.xxxx.
Environment
Component: SYSVW
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.xxxx 0000002669BAFE2A NOVERIFY NOCONFIRM
#2:
DRO PRODAOR2 05/12/18 16:45:00 CSSY
which resulted in this command:
LGDRO CICSLOGR.TSUM.xxxx 0000002669BCFCA3 NOVERIFY NOCONFIRM
#3:
DRO PRODAOR2 05/12/18 16:45:00 UEC8
which resulted in this command:
LGDRO CICSLOGR.TSUM.xxxx 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.xxxx
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.
Feedback
