On 8/30/2013 9:54 AM, Ed Jaffe wrote:
I assumed that RETPD(2) and AUTODELETE(YES) would keep the number of
health checker data sets to a minimum, but there is a space explosion
of literally thousands of IXGLOGR.HZS.** data sets--with the oldest of
them allocated last year:
My attempt to manually delete the oldest data set resulted in:
IEC331I 050-088(,MVSNV1),EDJXADM,$IKJTEST,VCMP,IGG0CLE4
IDC0550I ENTRY (D) IXGLOGR.HZS.HEALTH.CHECKER.JZSV7FLI DELETED
IDC0550I ENTRY (C) IXGLOGR.HZS.HEALTH.CHECKER.HISTORY.A0000471 DELETED
IDC3014I CATALOG ERROR+
IDC0551I ** ENTRY IXGLOGR.HZS.HEALTH.CHECKER.HISTORY.A0000471 NOT DELETED
IDC0014I LASTCC=8
IDC3009I ** VSAM CATALOG RETURN CODE IS 50 - REASON CODE IS IGG0CLFL-88
***
050-088 means:
Explanation: A VVR or NVR with the correct component
name was found, but the catalog name did not match. On
a delete request, the BCS record will be deleted, but
the VVR or NVR and the format 1 DSCB will not be
scratched. There is no SFI data.
It turned out the IXGLOGR prefix was not an alias. IXGLOGR data sets
were (unknowingly) being cataloged in the master catalog! We used a
separate master catalog for a z/OS 2.1 image that we joined last year to
our sysplex with existing z/OS 1.13 images. Apparently, that's about the
time when automatic deletion stopped working for this log stream...
I deleted all of the HZS logger data sets, removed the (literally)
thousands of "dangling" VVRs, and created a user catalog alias for
IXGLOGR so this can't happen again. Sheesh!
Thanks for your attention...
--
Edward E Jaffe
Phoenix Software International, Inc
831 Parkview Drive North
El Segundo, CA 90245
http://www.phoenixsoftware.com/
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
