home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #1 / NN_1993_1.iso / spool / bit / listserv / ibmmain / 2965 < prev    next >
Encoding:
Text File  |  1993-01-08  |  1.5 KB  |  35 lines
  1. Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
  2. Path: sparky!uunet!zaphod.mps.ohio-state.edu!howland.reston.ans.net!paladin.american.edu!auvm!USCMVSA.BITNET!LDW
  3. Message-ID: <IBM-MAIN%93010802033462@RICEVM1.RICE.EDU>
  4. Newsgroups: bit.listserv.ibm-main
  5. Date:         Fri, 8 Jan 1993 00:01:00 PST
  6. Sender:       IBM Mainframe Discussion list <IBM-MAIN@RICEVM1.BITNET>
  7. From:         Leonard D Woren <LDW@USCMVSA.BITNET>
  8. Subject: Re: Dangling VSAM truenames
  9. Lines: 24
  10.  
  11. On Thu, 7 Jan 1993 14:12:22 EST,
  12.    Arthur Gutowski <AGUTOWS@WAYNEST1.BITNET> said:
  13. > Yes, this approach is tricky.  Delete VVR will clean up the VVDS, though.
  14. > If the VVR entries are gone with the catalog entries, then ICF can't
  15. > do anything for you anyway.  Then you have to zap the VTOC and scratch the
  16. > datset.
  17.  
  18. I believe (but am too lazy to look it up, and I'm certainly not going
  19. to create a test case) that DELETE VVR is supposed to delete the VTOC
  20. entry IF IT EXISTS, and delete the VVR entry IF IT EXISTS.  My
  21. understanding is that the lack of one of those will not stop DELETE
  22. VVR from deleting the other, although I won't swear to this.
  23.  
  24. It may also be possible to do something with DEFINE RECATALOG and then
  25. DELETE.
  26.  
  27. > If you're sharing a catalog with VM, which isn't smart enough to handle ICF,
  28. > then you have no choice but to use VSAM catalogs.  We share our ACF2 database
  29. > which means we have to share a catalog.
  30.  
  31. Yep, it's another problem with VM, the OS for the 1960s.  (Let's see
  32. if everybody has enough willpower to ignore this flame bait.)
  33.  
  34. /Leonard
  35.