Misleading information in cleanup AT5#RPT report
search cancel

Misleading information in cleanup AT5#RPT report

book

Article ID: 216159

calendar_today

Updated On:

Products

Cleanup

Issue/Introduction

There was an issue during house keeping activity which was based on a cleanup report.

Situation:

Targeted SYS1 HLQ to clean up unused rules.

Used the output of the CA Cleanup Report, generated with following job:

//ETCREP0 EXEC PGM=AT5#RPT,PARM='UNREF=ALL'          
//STEPLIB   DD DSN=XX.CDMELINK,DISP=SHR     
//SORTWK01  DD UNIT=3390,SPACE=(CYL,150)             
//SORTWK02  DD UNIT=3390,SPACE=(CYL,150)             
//DBASE     DD DISP=SHR,DSN=XX.DB   
//SYSPRINT  DD DSN=YY.IPO1,             
//             RECFM=FBA,LRECL=133,DSORG=PS,         
//             SPACE=(CYL,(20,10),RLSE),             
//             UNIT=DISK,DISP=(NEW,CATLG,DELETE)     
//SYSOUT    DD DUMMY                                 
//SYSIN     DD DUMMY          

The result was filtered for all rules with days_not_used (column 6) = "n/a" or  days_not_used   > 500 and

this output was marked for removal.

After applying the cleanup script, there was an issue during the IPL.

VTAM and the RESOLVER were not able to start up

anymore because of missing authorization.

The SMF DSNVIO Report created with JCL

//DSNVIO EXEC PGM=ACFRPTDS,PARM='VIO'     
//RECIN01  DD DISP=SHR,DSN=SYS1.XX 
//SYSPRINT DD SYSOUT=T                    
//HEXDUMP  DD SYSOUT=T                    

 

These rules were deleted based on the information from the cleanup report.

The SYS1 Key uses a NEXTKEY to point to SYS1A and SYS1A points with another NEXTKEY to SYS1B. 

Is there an issue with the cleanup information?

Environment

Release : 12.1

Component : CA Cleanup for ACF2

Resolution

It seems that the interim Nextkeys did not get marked, only the final rule.


Note:
the Cleanup STC must be fully up and active before it can track any usage,
it is  recommend bringing it up as a subsys Immediately after ACF2 in order 
to get these validations.

Ptf RO99473 can help to address Logonid use, but not DSNs, 

Consider Excluding (some?) SYS1 from the DB file
for this issue.