home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #1 / NN_1993_1.iso / spool / bit / listserv / ibmmain / 2946 < prev    next >
Encoding:
Text File  |  1993-01-05  |  1.2 KB  |  31 lines
  1. Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
  2. Path: sparky!uunet!zaphod.mps.ohio-state.edu!sol.ctr.columbia.edu!spool.mu.edu!uwm.edu!psuvax1!psuvm!auvm!PLWATU22.BITNET!GRZES
  3. Return-Path: <@VM1.CC.UAKRON.EDU:IBM-MAIN@RUTVM1.BITNET>
  4. Message-ID: <IBM-MAIN%93010514402768@DEARN>
  5. Newsgroups: bit.listserv.ibm-main
  6. Date:         Tue, 5 Jan 1993 14:41: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: 19
  11.  
  12. > > But, for some reason, the data sets were only uncatalogged, and the
  13. > > VSAM space for the user catalog and the page spaces are still out there.
  14. >
  15. > Sounds like DELETE FORCE or DELETE RECOVERY was used.  Generally a
  16. > no-no unless you really know what you're doing and why.
  17. >
  18.  
  19.  I think that someone use :
  20.   DELETE name CLUSTER
  21.  If you specify CLUSTER VSAM deletes only cluster (not DATA and INDEX,
  22.            i don't know why but it's )
  23.  
  24.  Some time ago I do this.
  25.  the only way to recover this situation is SUPERZAP VTOC.
  26.  (I can't erase all VSAM files on volume)
  27.  I change in VTOC bit PASSWORD PROTECTED end erase file using DISP=(OLD,DELETE)
  28.  or from ISPF.
  29.  
  30. Gregory
  31.