Re: Best way to clean up NOT Cat datasets in SMS
If you are a CA MICS customer and have the MICS DASD component, there is a CATCHECK=Y option with the VCC (VTOC/Catalog Collector) - very efficient. I have a few MICS customers I support who run a weekly VCC with the option on (left off for the regular daily runs) and then their Monday AM MICS database is checked using a SAS report, and also some generate the necessary IDCAMS batch utility jobstream for automated clean-up, if desired. Scott Barry SBBWorks, Inc. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Best way to clean up NOT Cat datasets in SMS
Looking to find the best process to identify and delete uncataloged data sets that are in SMS Pools. These can either be VSAM or NON VSAM data sets. How often should this process run? How would I go about reducing or elimiating the fact data sets can be not cataloged in SMS Pools? Thanks for the input. Lizette -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Best way to clean up NOT Cat datasets in SMS
On Wed, 7 Nov 2007 12:24:49 -0600, Staller, Allan wrote: I do not think you can completely eliminate the possibility of having an uncataloged dataset in the SMS pool. Anyone with access to ISPF 3.4 can uncat a properly created SMS dataset and presto! A brand new instance of the problem. Not unless they have access to STGADMIN.IGG.DELETE.NOSCRTCH. -- Tom Marchant -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Best way to clean up NOT Cat datasets in SMS
snip Looking to find the best process to identify and delete uncataloged data sets that are in SMS Pools. These can either be VSAM or NON VSAM data sets. How often should this process run? How would I go about reducing or elimiating the fact data sets can be not cataloged in SMS Pools? snip If the pools are HSM managed, HSM issues a return code 70 (IIRC) for uncataloged datasets during backup and migration processing. Parse the HSM migration/backup logs to create a dataset list. If the quantity is small, I usually issue IDCAMS DEFINE ... RECATLOG, followed by DELETE. I have found that once a month or so is adequate to stay on top of the situation. YMMV. I do not think you can completely eliminate the possibility of having an uncataloged dataset in the SMS pool. Anyone with access to ISPF 3.4 can uncat a properly created SMS dataset and presto! A brand new instance of the problem. HTH, -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Best way to clean up NOT Cat datasets in SMS
On Wed, 7 Nov 2007 13:16:28 -0500, Lizette Koehler wrote: Looking to find the best process to identify and delete uncataloged data sets that are in SMS Pools. These can either be VSAM or NON VSAM data sets. Have you figured out what's causing it? Is it because you restore volumes from full volume backups after data sets were deleted? Did you have to restore a catalog? Or maybe someone has access to STGADMIN.IGG.DELETE.NOSCRTCH and has uncataloged the data set? Is your SMS environment shared? If so, do you share the catalogs too? How often should this process run? How would I go about reducing or elimiating the fact data sets can be not cataloged in SMS Pools? It shouldn't happen under normal circumstances. If you can figure out why it's happening, that should help you figure out what to do about it. -- Tom Marchant -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Best way to clean up NOT Cat datasets in SMS
Lizette, If you have DSS, you can run the following to find datasets that are not cataloged: //* //* LIST DATA SETS NOT CATALOGED ON A VOLUME //* //NOCAT EXEC PGM=ADRDSSU,PARM='TYPRUN=NORUN' //SYSPRINT DD SYSOUT=* //OUTPUT DD DUMMY //SYSIN DD * DUMP DS (BY ((CATLG EQ NO))) - INDYNAM((WRK001) , - (WRK002)) ODD(OUTPUT) Note the PARM=NORUN - this causes DSS to only report what uncataloged datasets are on the volumes you specify, it does not actually dump them. I've used this for SMS and non-SMS volumes. When I run this, all I see are the SYS1.VTOCIX.Vvolser data sets listed. How often? I've not found a great reason to do this on any scheduled basis. Of course, YMMV in your shop depending on the answer to your third question - which I'll leave to a good storage management person who's a lot smarter than I am about how you get SMS data sets on SMS volumes that are not cataloged... Tom Chicklon -- Looking to find the best process to identify and delete uncataloged data sets that are in SMS Pools. These can either be VSAM or NON VSAM data sets. How often should this process run? How would I go about reducing or elimiating the fact data sets can be not cataloged in SMS Pools? Thanks for the input. Lizette -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Best way to clean up NOT Cat datasets in SMS
snip Looking to find the best process to identify and delete uncataloged data sets that are in SMS Pools. These can either be VSAM or NON VSAM data sets. How often should this process run? How would I go about reducing or elimiating the fact data sets can be not cataloged in SMS Pools? snip Forgot to mention there is probably something along the lines of delete any uncataloged dataset on these volumes on the CBT tape, but I haven't specifically looked. HTH, -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
