home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #1 / NN_1993_1.iso / spool / bit / listserv / ibmmain / 2962 < prev    next >
Encoding:
Text File  |  1993-01-07  |  2.1 KB  |  41 lines

  1. Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
  2. Path: sparky!uunet!gatech!usenet.ins.cwru.edu!magnus.acs.ohio-state.edu!zaphod.mps.ohio-state.edu!howland.reston.ans.net!paladin.american.edu!auvm!WAYNEST1.BITNET!AGUTOWS
  3. Return-Path: <@VM1.CC.UAKRON.EDU:AGUTOWS@WAYNEST1.BITNET>
  4. Message-ID: <IBM-MAIN%93010714210701@VM1.CC.UAKRON.EDU>
  5. Newsgroups: bit.listserv.ibm-main
  6. Date:         Thu, 7 Jan 1993 14:12:22 EST
  7. Sender:       IBM Mainframe Discussion list <IBM-MAIN@RICEVM1.BITNET>
  8. From:         Arthur Gutowski <AGUTOWS@WAYNEST1.BITNET>
  9. Subject: Re: Dangling VSAM truenames
  10. In-Reply-To:  Message of Thu, 7 Jan 1993 01:21:00 PST from <LDW@USCMVSA>
  11. Lines: 28
  12.  
  13. On Thu, 7 Jan 1993 01:21:00 PST Leonard D Woren said:
  14. >>  the only way to recover this situation is SUPERZAP VTOC.
  15. >>  (I can't erase all VSAM files on volume)
  16. >>  I change in VTOC bit PASSWORD PROTECTED end erase file using
  17. >>  DISP=(OLD,DELETE) or from ISPF.
  18. >
  19. >This type of approach should be used only as a last-ditch effort, if
  20. >you have ICF catalogs.  ICF provides enough recovery capability that
  21. >this should never be necessary.  If you do the above for ICF VSAM
  22. >objects, you'll end up with junk in the VVDS, and likely trouble down
  23. >the road.
  24. Yes, this approach is tricky.  Delete VVR will clean up the VVDS, though.
  25. If the VVR entries are gone with the catalog entries, then ICF can't
  26. do anything for you anyway.  Then you have to zap the VTOC and scratch the
  27. datset.  We recently bought VSAM Mechanic.  An invaluable tool for cleaning
  28. up VSAM objects that got trashed beyond ICF's ability to recover.  It also
  29. provides other VSAM  utilities that AMS and DFP don't have.  I think we
  30. paid around $5K for it.  Well worth the cost for us.
  31.  
  32. >I cannot imagine any reason for not converting to a pure ICF catalog
  33. >environment.  ICF catalogs are faster, smaller, and more reliable than
  34. >VSAM catalogs and CVOLS, and I don't think there are any negatives.
  35.  
  36. If you're sharing a catalog with VM, which isn't smart enough to handle ICF,
  37. then you have no choice but to use VSAM catalogs.  We share our ACF2 database
  38. which means we have to share a catalog.
  39.  
  40. /Art
  41.