home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #27 / NN_1992_27.iso / spool / comp / os / vms / 18143 < prev    next >
Encoding:
Internet Message Format  |  1992-11-17  |  2.4 KB
  1. Path: sparky!uunet!charon.amdahl.com!pacbell.com!ames!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: Wierd BACKUP change in VMS 5.5-2
  5. Date: 18 Nov 1992 03:05:15 GMT
  6. Organization: HST Wide Field/Planetary Camera
  7. Lines: 28
  8. Distribution: world
  9. Message-ID: <1ecbtbINNmki@gap.caltech.edu>
  10. References: <1992Nov17.203345.23090@aplcen.apl.jhu.edu>,<1992Nov17.141404.1@slacvx.slac.stanford.edu>
  11. Reply-To: carl@SOL1.GPS.CALTECH.EDU
  12. NNTP-Posting-Host: sol1.gps.caltech.edu
  13.  
  14. In article <1992Nov17.141404.1@slacvx.slac.stanford.edu>, fairfield@slacvx.slac.stanford.edu writes:
  15. >    Just curious, from which version of VMS did you upgrade to V5.5-2?
  16. >The reason I ask is that we are running V5.5-1 and I ran into essentially
  17. >the same problem: subprocess unable to access the drive allocated to the
  18. >parent (don't take me too literally, can't remember whether the drive
  19. >was mounted or just allocated...).   This had nothing to do with BACKUP.
  20. >I just gave up without thinking much more about it :-(
  21.  
  22. If memory serves, you've *NEVER* been able to mount a tape that was allocated
  23. to the parent of the current process.  VMS v4.0 made some changes in the way
  24. tape mounting was done that allowed the tape to be shared among processes in a
  25. job.  If I recall correctly, that version of VMS had a bug that caused the
  26. MOUNT to also allocate the tape (or maybe it changed the ownership of a tape
  27. allocated by the subprocess to ownership by the parent; it's been a long time
  28. since 4.0 and my memory's a bit fuzzy).  Thus if one mounted a tape from a
  29. subprocess, then dismounted it, a subsequent attempt to mount it would fail.
  30.  
  31. Now, someone else has posted something about another problem with BACKUP under
  32. v5.5-2 which indicates that the way BACKUP handles continuation tapes has
  33. changed.  The problem currently under discussion is probably related.
  34. --------------------------------------------------------------------------------
  35. Carl J Lydick | INTERnet: CARL@SOL1.GPS.CALTECH.EDU | NSI/HEPnet: SOL1::CARL
  36.  
  37. Disclaimer:  Hey, I understand VAXen and VMS.  That's what I get paid for.  My
  38. understanding of astronomy is purely at the amateur level (or below).  So
  39. unless what I'm saying is directly related to VAX/VMS, don't hold me or my
  40. organization responsible for it.  If it IS related to VAX/VMS, you can try to
  41. hold me responsible for it, but my organization had nothing to do with it.
  42.