home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #19 / NN_1992_19.iso / spool / bit / listserv / lvmctr / 241 < prev    next >
Encoding:
Text File  |  1992-08-29  |  2.2 KB  |  50 lines
  1. Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
  2. Path: sparky!uunet!paladin.american.edu!auvm!UMINN1.BITNET!IJIM
  3. Message-ID: <L-VMCTR%92082817173633@VM1.CC.UAKRON.EDU>
  4. Newsgroups: bit.listserv.l-vmctr
  5. Date:         Fri, 28 Aug 1992 14:33:56 CST
  6. Sender:       VMCENTER Components Discussion List <L-VMCTR@AKRONVM.BITNET>
  7. From:         Jim Colten <IJIM@UMINN1.BITNET>
  8. Subject:      Re: Last date a minidisk was updated.
  9. In-Reply-To:  Message of Fri, 28 Aug 1992 15:03:06 EDT from <RWWMAINT@MSU>
  10. Lines: 38
  11.  
  12. >>Hi,
  13. >>    Am I wrong or does moving a minidisk with VMSECURE change the
  14. >>"last updated" date you see when you do a MDSKSCAN or run the VMRMUA
  15. >>report?  If so, how do I work around this?  I want to clean old minidisks
  16. >>off a couple of volumes.  Thanks.  T.S.
  17. >
  18. >I believe that date is simply the latest file update timestamp
  19. >encountered for that minidisk; ie. moving the minidisk will
  20. >not change the timestamp.  We run our Clearvol process (front
  21. >end to VMSECURE) to clear entire volumes without worrying about
  22. >changing any data or timestamps within minidisks.
  23. >
  24.  
  25.  
  26. Well, that depends.  Here is what I see (VMSECURE 4.0, CMS5):
  27.  
  28.    1) look at the FILE timestamps on a disk
  29.    2) do a VMSECURE MDSKSCAN for the disk
  30.    3) move the disk, same device-type, same size
  31.    4) repeat steps 1 & 2 above, neither the FILE timestamps nor the
  32.       last update timestamp reported by MDSKSCAN show any change.
  33.    5) move the disk to a different device-type (3380->3370)
  34.    6) repeat steps 1 & 2 above, the FILE timestamps are preserved, but
  35.       MDSKSCAN indicates that the disk was updated TODAY.
  36.  
  37. I believe that this is because MDSKSCAN takes its info from a timestamp in
  38. the CMS file system's directory on the mdisk, not from file timestamps,
  39. from a directory timestamp.
  40.  
  41. I also believe that VMSECURE will use DDR to move a disk when DDR is a
  42. viable option (same device architecture, same size).  Otherwise it will
  43. use COPYFILE (or alternative).  With DDR, the entire disk image, including
  44. the file system directory is moved intact, with no change.  With COPYFILE,
  45. only the data is kept intact, the physical structure of the file system
  46. will changed, and the file system directory will be re-written (more than once)
  47. and will contain today's filestamp.
  48.  
  49. Jim Colten
  50.