SMR not capturing SYSLOG output and queue is backing up, all DAILY files are still created

book

Article ID: 192182

calendar_today

Updated On:

Products

CA SMR

Issue/Introduction

SMRWRTR is automatically executed as specified in the options and the DAILY files are created as expected. The archive also completes with no issue. However, no SYSLOG is captured.

Cause

Environmental

Environment

z/OS any level
SMR 3.4 and and above

Resolution

The SYSLOGS on this system is spooled to CLASS=R. In this system SYS1.PARMLIB(IEASYSxx) member they have LOGCLS=R specified. Yours may be something else.
This class is a HOLD class defined in the JES2PARM
 
SMRWTR ran to completion with no issues but CLASS=R is not a class that can be read so nothing was dumped to the DAILY files. SMR believes it has processed all the SYSLOG that was available and will even execute the archive process which will still execute properly but the files will be empty.

Resolution:
Correct the parmlib member and change it to LOGCLS=L or another non-hold class.
To save all the backed up SYSLOG files change SMR options to gather CLASS=L in the PL34SOPT member.
Recycle SMR to pick up the new CLASS=L SYSLOG.
Update the MASTER and the ALTERN files and change the archive names to DAILY  names to save the old SYSLOGs. In case an archive has executed

Changed the class of the SYSLOG files in the output queue to CLASS=L.
Issue a WRITELOG L  command on the console to kick off SMRWTR so it will spool all the older SYSLOG files we changed.
Verify that all the SYSLOG was spooled to the correct DAILY file. You can do this by simply browsing the DAILY files and make sure the dates are correct