home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #27 / NN_1992_27.iso / spool / comp / os / vms / 18134 < prev    next >
Encoding:
Text File  |  1992-11-17  |  2.2 KB  |  42 lines
  1. Newsgroups: comp.os.vms
  2. Path: sparky!uunet!charon.amdahl.com!pacbell.com!ames!saimiri.primate.wisc.edu!zaphod.mps.ohio-state.edu!pacific.mps.ohio-state.edu!linac!unixhub!slacvx.slac.stanford.edu!fairfield
  3. From: fairfield@slacvx.slac.stanford.edu
  4. Subject: Re: Wierd BACKUP change in VMS 5.5-2
  5. Message-ID: <1992Nov17.141404.1@slacvx.slac.stanford.edu>
  6. Lines: 30
  7. Sender: news@unixhub.SLAC.Stanford.EDU
  8. Organization: Stanford Linear Accelerator Center
  9. References: <1992Nov17.203345.23090@aplcen.apl.jhu.edu>
  10. Date: Tue, 17 Nov 1992 22:14:04 GMT
  11.  
  12. In article <1992Nov17.203345.23090@aplcen.apl.jhu.edu>, rubin@procon.jhuapl.edu (Don Rubin) writes:
  13. > 
  14. > We recently upgraded one of our clusters to 5.5-2, everything
  15. > went well and we had no complaints from the users until someone
  16. > ran one of my programs that is a front end to BACKUP. We have
  17. > a database of backups that allows the user find which tape has
  18. > the desired data. The restore program gets info from the user
  19. > and then mounts the tape (all of our programs do mounts and
  20. > dismounts so the users never have to worry about doing that)
  21. > if the label agrees with the one the user specified then a
  22. > subprocess is created (using smg$create_subprocess) and BACKUP
  23. > is spawned. UNTIL 5.5-2 this worked properly, since the drive
  24. > was mounted in the parent process, backup just went ahead and
  25. > did the restore. NOW backup aborts saying the tape drive is
  26. > allocated by another process (yes, the parent). After much
  27.  
  28.     Just curious, from which version of VMS did you upgrade to V5.5-2?
  29. The reason I ask is that we are running V5.5-1 and I ran into essentially
  30. the same problem: subprocess unable to access the drive allocated to the
  31. parent (don't take me too literally, can't remember whether the drive
  32. was mounted or just allocated...).   This had nothing to do with BACKUP.
  33. I just gave up without thinking much more about it :-(
  34.  
  35.         -Ken
  36. -- 
  37.  Dr. Kenneth H. Fairfield    |  Internet: Fairfield@Slac.Stanford.Edu
  38.  SLAC, P.O.Box 4349, MS 98   |  DECnet:   45537::FAIRFIELD (45537=SLACVX)
  39.  Stanford, CA   94309        |  BITNET    Fairfield@Slacvx
  40.  ----------------------------------------------------------------------------
  41.  These opinions are mine, not SLAC's, Stanford's, nor the DOE's...
  42.