home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #19 / NN_1992_19.iso / spool / comp / os / vms / 14382 < prev    next >
Encoding:
Internet Message Format  |  1992-08-31  |  3.1 KB

  1. Path: sparky!uunet!inmos!bra.isnet.inmos.co.uk!npe.isnet.inmos.co.uk!isodonovan
  2. Newsgroups: comp.os.vms
  3. Subject: Re: ?Cause of error message under $SUBMIT
  4. Message-ID: <1992Sep1.102042.1@npe.isnet.inmos.co.uk>
  5. From: isodonovan@npe.isnet.inmos.co.uk
  6. Date: 1 Sep 92 10:20:42 GMT
  7. References: <1992Aug28.130419.1@woods.ulowell.edu>
  8. Organization: Inmos Limited
  9. Nntp-Posting-Host: gnbstx
  10. Nntp-Posting-User: netnonpriv
  11. Lines: 57
  12.  
  13. In article <1992Aug28.130419.1@woods.ulowell.edu>, welchb@woods.ulowell.edu writes:
  14. > Here is the error message I often get from a simple .com file
  15. > when it is $SUBMITted: 
  16. >     Error opening primary file SYS$INPUT
  17. >     File not found
  18.  
  19. [...]
  20.  
  21. The chances are you'll get many responses to this.  When I've encountered this
  22. before it's been due to submitting a file to a batch queue and then deleting
  23. the file.  When you submit a file, the queue manager retains a pointer to the
  24. file (by name and file id number I think), it does not take a copy of the file
  25. - so the file still needs to be around when the job starts executing.  If you
  26. create multiple versions of a file that you submit e.g. bat.com;1 ,;2, ;3 ...
  27. and either PURGE or have a version limit set, then the earlier versions will be
  28. deleted and when they come to the top of the queue, they will not be found.
  29.  
  30. Also (sorry if this is going on a bit!) if you submit a file, then change it,
  31. it will be the OLD version that executes not the new one.  Because the queue
  32. manager keeps a note of the file id, you cannot fool it into executing the new
  33. version - you'd have to delete the old job and resubmit, so again, you need to
  34. keep the old version aroud if you want it to run.
  35.  
  36. If you have an application that creates temporary files to submit, the best
  37. thing I can think of is to ensure that they all have different names, so that
  38. they will not be lost by purging, or by a limit on the number of versions.  One
  39. way of achieving this is to use the data & time (e.g. from F$CVTIME) as part of
  40. the filename.  From memory, I think I tend to use
  41.  
  42.   yyyymmddhhmmsscc = F$CVTIME()-"-" -"-" -" " -":" -":" -"."
  43. to produce something like
  44.   1992090110171755
  45. which I then make part of the filename.
  46.  
  47. You'll need to clean up these files (probably!) and funnily enough, they can be
  48. set to delete themselves if you put something like 
  49.  
  50.   $ DELETE 'F$ENVIRONMENT("PROCEDURE")
  51.  
  52. at the end of the command procedure.
  53.  
  54. I hope this is of some use to you!
  55.  
  56.   -- Brian
  57.  
  58. > -- 
  59. > Brendan Welch, UMass/Lowell, W1LPG,  welchb@woods.ulowell.edu
  60. -- 
  61. ---------------------------------------/--------------------------------------
  62. Brian O'Donovan                        /                       'o-Dzin Tridral
  63. eMail: Isodonovan@Isnet.Inmos.Co.Uk    / "Sang-ngak-cho-dzong" -
  64. Phone: +44 633 810121 X384             / Tibetan Buddhist Group in the UK & US
  65. Mail : Inmos Ltd, Cardiff Road,        / 5 Court Close, Whitchurch, Cardiff,
  66.        Newport, Wales, UK, NP9 1YJ     / Wales, UK, CF4 1JR
  67. ---------------------------------------/--------------------------------------
  68.       "No one's ever come back to say there *isn't* a life after death"
  69. ---------------------------------------/--------------------------------------
  70.