home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #1 / NN_1993_1.iso / spool / bit / listserv / ibmmain / 2958 < prev    next >
Encoding:
Text File  |  1993-01-07  |  1.9 KB  |  53 lines
  1. Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
  2. Path: sparky!uunet!spool.mu.edu!darwin.sura.net!paladin.american.edu!auvm!PLWATU22.BITNET!GRZES
  3. Return-Path: <@VM1.CC.UAKRON.EDU:IBM-MAIN@RUTVM1.BITNET>
  4. Message-ID: <IBM-MAIN%93010710372578@DEARN>
  5. Newsgroups: bit.listserv.ibm-main
  6. Date:         Thu, 7 Jan 1993 11:37:00 PST
  7. Sender:       IBM Mainframe Discussion list <IBM-MAIN@RICEVM1.BITNET>
  8. From:         Gregory Plucinski 257508 <GRZES@PLWATU22.BITNET>
  9. Subject: Re: Dangling VSAM truenames
  10. Lines: 41
  11.  
  12. > On Tue, 5 Jan 1993 14:41:00 PST,
  13. >    Gregory Plucinski 257508 <GRZES@PLWATU22.BITNET> said:
  14. > >  I think that someone use :
  15. > >   DELETE name CLUSTER
  16. > >  If you specify CLUSTER VSAM deletes only cluster (not DATA and INDEX,
  17. > >            i don't know why but it's )
  18. >
  19. > This is not true.  Try it.  DELETE CLUSTER deletes the cluster and all
  20. > lower level related objects.
  21. >
  22.   In my VSAM it's work as i wrote, i check it.
  23.   I use MVS/SP 1.3.6 may be it's to old ?
  24.   And of course ICF catalogs.
  25.  
  26. > >  the only way to recover this situation is SUPERZAP VTOC.
  27. > >  (I can't erase all VSAM files on volume)
  28. > >  I change in VTOC bit PASSWORD PROTECTED end erase file using DISP=(OLD,DELE
  29. TE
  30. > >  or from ISPF.
  31. >
  32. > This type of approach should be used only as a last-ditch effort, if
  33. > you have ICF catalogs.  ICF provides enough recovery capability that
  34. > this should never be necessary.  If you do the above for ICF VSAM
  35. > objects, you'll end up with junk in the VVDS, and likely trouble down
  36. > the road.
  37. >
  38.  all information about cluster, data and index are deleted from
  39.  catalog.
  40.  I don't check VVDS.
  41.  in this case ICF recovery procedures are not usable.
  42.  
  43. > I cannot imagine any reason for not converting to a pure ICF catalog
  44. > environment.  ICF catalogs are faster, smaller, and more reliable than
  45. > VSAM catalogs and CVOLS, and I don't think there are any negatives.
  46. >
  47. >
  48. > /Leonard
  49.  
  50.  I really use ICF catalogs
  51.  
  52. Gregory.
  53.