home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #31 / NN_1992_31.iso / spool / comp / os / vms / 20096 < prev    next >
Encoding:
Internet Message Format  |  1992-12-30  |  2.9 KB
  1. Path: sparky!uunet!gatech!paladin.american.edu!howland.reston.ans.net!zaphod.mps.ohio-state.edu!moe.ksu.ksu.edu!ux1.cso.uiuc.edu!usenet.ucs.indiana.edu!master.cs.rose-hulman.edu!rosevc.rose-hulman.edu!mgrthh
  2. From: mgrthh@rosevc.rose-hulman.edu (Thomas H. Hopson)
  3. Newsgroups: comp.os.vms
  4. Subject: Re: MAIL problem (NOT newmail count :)
  5. Date: 30 Dec 1992 19:00:32 GMT
  6. Organization: Rose-Hulman Institute of Technology
  7. Lines: 46
  8. Distribution: world
  9. Message-ID: <1hsrkgINNt6r@master.cs.rose-hulman.edu>
  10. References: <1992Dec30.122948.13315@bsu-ucs>
  11. Reply-To: mgrthh@rosevc.rose-hulman.edu
  12. NNTP-Posting-Host: hydra.rose-hulman.edu
  13.  
  14.  
  15. In article <1992Dec30.122948.13315@bsu-ucs>, 00mjstum@leo.bsuvc.bsu.edu (Matthew J. Stum) writes:
  16.  
  17. >Anyway, it's nothing tragic, but I've been wondering for a long time now
  18. >why we end up with a lot of MAIL.LIS files in our [SYSLOST] directories.
  19. >Here's my assumption based on what little detective work I've been
  20. >motivated to do:  The MAIL.LIS files are temporary files used when PRINTing
  21. >from MAIL... however, for some reason the MAIL.LIS file doesn't get deleted
  22. >properly.  More like a SET FILE/REMOVE thing.
  23. >
  24. >The problem arises that we have quotas enabled on our user disks and it
  25. >wreaks havoc with a user if (s)he prints a lot from MAIL.
  26.  
  27. The MAIL.LIS files are created when a user issues a PRINT command from 
  28. within MAIL.  The MAIL utility creates a "temporary file" that it only knows
  29. by file ID; the file is not stored in any directory.  It issues the equivalent
  30. of a PRINT/DELETE (using, of course, the $SNDJBC system service) giving the
  31. file ID of the file it created.
  32.  
  33. If the print job is deleted or for whatever reason doesn't complete, the file
  34. doesn't get deleted.  Since it doesn't exist in a directory, it is really
  35. difficult for people to even know that they own the file, much less delete it.
  36.  
  37. >Is this normal?  Or do we have something set up strangely?  Is there
  38. >another way around it besides routinely cleaning the [SYSLOST] directories
  39. >of MAIL.LIS files?
  40.  
  41. It is normal in the sense that it seems to happen a lot, especially if users
  42. print a lot of mail, and especially if print jobs get deleted a lot.  There
  43. really isn't a *nice* way of cleaning up the files, especially since you've
  44. lost track of (never really knew) the file IDs of the files being created.
  45.  
  46. >Hmmm... now that I think of it, I don't use PRINT/DELETE a whole lot... is
  47. >this something connected with the queueing system and not MAIL?  I don't
  48. >see anything about PRINT in the docs that would nail it down one way or
  49. >another.
  50.  
  51. It's not a fault of PRINT/DELETE nor of the queueing system.  It's really a
  52. fault of MAIL for deciding to use a "temporary" file when the possibility
  53. exists that the file may not be printed and deleted immediately.
  54.  
  55. --
  56. Thomas H. Hopson                      work: mgrthh@rosevc.rose-hulman.edu
  57. VMS Manager / CS geek                       mgrthh@rhit
  58. Rose-Hulman Institute of Technology   play: hopsonth@cs.rose-hulman.edu
  59. Terre Haute, Indiana
  60.