home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #26 / NN_1992_26.iso / spool / comp / os / vms / 17839 < prev    next >
Encoding:
Internet Message Format  |  1992-11-12  |  2.2 KB

  1. Path: sparky!uunet!wupost!usc!elroy.jpl.nasa.gov!nntp-server.caltech.edu!SOL1.GPS.CALTECH.EDU!CARL
  2. From: carl@SOL1.GPS.CALTECH.EDU (Carl J Lydick)
  3. Newsgroups: comp.os.vms
  4. Subject: Re: File format change by BACKUP?
  5. Date: 12 Nov 1992 12:54:50 GMT
  6. Organization: HST Wide Field/Planetary Camera
  7. Lines: 27
  8. Distribution: world
  9. Message-ID: <1dtk6rINNenk@gap.caltech.edu>
  10. References: <1992Nov12.122046.484@hhcs.gov.au>
  11. Reply-To: carl@SOL1.GPS.CALTECH.EDU
  12. NNTP-Posting-Host: sol1.gps.caltech.edu
  13.  
  14. In article <1992Nov12.122046.484@hhcs.gov.au>, sharmp@hhcs.gov.au writes:
  15. =We have just had a situation where the backup command has done a funny on us. 
  16. =The situation was a backup to tape was being done of a number of indexed RMS
  17. =files.  The operator was prompted for another tape, and had to abort due to
  18. =problems with the tape mount.  
  19. =
  20. =When the files are recovered from tape, the last file on the tape prior to the
  21. =operator abort is in sequential format.  I was fairly sure that backup restored
  22. =files in the same format as they were put on tape.  Is it possible for the file
  23. =to be still opened when the operator aborted and for this to result in a 
  24. =different file format?  The recovery command used was just
  25. =    backup/log/select=(filenames)
  26.  
  27. This is just a guess, but:  The fastest way to restore a file to disk is to
  28. simply copy the contents in block mode then fiddle with the file header after
  29. you've copied all the data.  I suspect that this is the technique that BACKUP
  30. uses.  Now, when you say "the last file on the tape prior to the operator
  31. abort," are you *SURE* that the entire file was on the tape? Or could it be
  32. that BACKUP hadn't finished processing that file?
  33. --------------------------------------------------------------------------------
  34. Carl J Lydick | INTERnet: CARL@SOL1.GPS.CALTECH.EDU | NSI/HEPnet: SOL1::CARL
  35.  
  36. Disclaimer:  Hey, I understand VAXen and VMS.  That's what I get paid for.  My
  37. understanding of astronomy is purely at the amateur level (or below).  So
  38. unless what I'm saying is directly related to VAX/VMS, don't hold me or my
  39. organization responsible for it.  If it IS related to VAX/VMS, you can try to
  40. hold me responsible for it, but my organization had nothing to do with it.
  41.