B37 abend executing CAPLWTR (SMRWTR) proc that spools SYSLOG files

Products

• SMR

Issue/Introduction

We are using SMR 3.4 and we find there is no SYSLOG file being spooled.  We discovered B37 abend in CAPLWTR every time it executes. No SYSLOG is getting spooled and is backing up the JES output files.

 

Environment

Release : 3.4

Component : SMR

Resolution

Experienced B37 abend in the SMRWTR task that writes the daily SYSLOG files from JES to the HOLD file and then to the SMRyyddd DAILY file.

SMS routines were shrinking the allocation of the prefix.XWTRL.HOLD file so small that it could not contain the daily SYSLOG from JES. You can find this information in the SMRWTR JES messages.

UNIT=smssys  was SMS managed. The customer found a NON-SMS managed volume UNIT=nonsms. Also  increased the allocation to a higher value to accommodate all the backed up SYSLOG JES data sets. Probably the increased allocation can be reduced if desired in the future. Once this change was made the SMRWTR task completed normally and created the files back to YYDDD. 

With the backed up SYSLOG files now being spooled the new DAILY SYSLOG files were all allocated properly based on the various days they were created. Do not be surprised if multiple daily SYSLOG files are created from the backed up JES SYSLOG data sets.

Procedure to test:

1) Bring down SMR started task

2) Update the allocation of the HOLD file for a larger allocation and a NON-SMS controlled volume. If you still have an old version of the HOLD file on disk, rename it or delete it.

3) Start the SMR started task. Review the task output to make sure all the correct allocations are completed and it says it is active:  SMR001I - SMR ACTIVE VERSION 3.4 GENLEVEL 0309

4) Issue the WRITELOG command from the console, this should start the CAPLWTR proc automatically

5) Review the output of the CAPLWTR proc for any errors. If not, then you should have the SYSLOG daily files on disc.

At this point all is good.