home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #31 / NN_1992_31.iso / spool / comp / os / vms / 20161 < prev    next >
Encoding:
Internet Message Format  |  1992-12-31  |  3.1 KB
  1. Path: sparky!uunet!gatech!usenet.ins.cwru.edu!agate!ucbvax!lrw.com!leichter
  2. From: leichter@lrw.com (Jerry Leichter)
  3. Newsgroups: comp.os.vms
  4. Subject: re: MAIL problem (NOT newmail count :)
  5. Message-ID: <9212311443.AA20444@uu3.psi.com>
  6. Date: 31 Dec 92 13:21:12 GMT
  7. Sender: daemon@ucbvax.BERKELEY.EDU
  8. Distribution: world
  9. Organization: The Internet
  10. Lines: 58
  11.  
  12.  
  13.     Hey, I have a MAIL question, and it doesn't involve the NEWMAIL
  14.     count.. :-)
  15.  
  16.     Anyway, it's nothing tragic, but I've been wondering for a long time
  17.     now why we end up with a lot of MAIL.LIS files in our [SYSLOST]
  18.     directories.  Here's my assumption based on what little detective work
  19.     I've been motivated to do:  The MAIL.LIS files are temporary files
  20.     used when PRINTing from MAIL... however, for some reason the MAIL.LIS
  21.     file doesn't get deleted properly.  More like a SET FILE/REMOVE thing.
  22.  
  23. When mail spools files for printing, it never enters them into a directory in
  24. the first place - it's not a matter of SET FILE/REMOVE, since there is no
  25. entry to remove!  If you did a SHOW QUE/FUL on such a file, you'd see a
  26. display like the following:
  27.  
  28.   MAIL            LEICHTER       818       5  Printing
  29.     Submitted 31-DEC-1992 09:07 /FLAG=ONE /FORM=PORTRAIT (stock=DEFAULT) 
  30.     /PRIORITY=100 /NOTRAILER
  31.     File: _TOPS$DUA0:[]MAIL.LIS; (printing) /DELETE
  32.  
  33. Note the lack of a directory name in the file specification.
  34.  
  35.     The problem arises that we have quotas enabled on our user disks and
  36.     it wreaks havoc with a user if (s)he prints a lot from MAIL.
  37.  
  38.     Is this normal?  Or do we have something set up strangely?  Is there
  39.     another way around it besides routinely cleaning the [SYSLOST]
  40.     directories of MAIL.LIS files?
  41.  
  42. It's "normal" in the sense that the software isn't doing anything unusual;
  43. but it's NOT normal in that these files should not be hanging around.  The
  44. spooler should be deleting them after they are printed.
  45.  
  46. It's hard to know WHY these files aren't being deleted.  You might want to
  47. take a closer look at them the next time you get a bunch.  Were they all
  48. created at about the same time?  Did something happen on the system at about
  49. that time (like a crash?)
  50.  
  51. Some experimentation with MAIL seems to indicated that it doesn't actually
  52. create an output file until you exit (or type PRINT/PRINT or PRINT/NOW), so
  53. the problem is not something like people typing PRINT, then CTRL/Y and STOP -
  54. although I suppose they MIGHT be able to cause the problem by noticing that
  55. MAIL was taking a long time to exit, realizing that was because of some
  56. forgotten PRINT command, then saying "Oh, I didn't really what that printed!")
  57.  
  58.     Hmmm... now that I think of it, I don't use PRINT/DELETE a whole
  59.     lot... is this something connected with the queueing system and not
  60.     MAIL?  I don't see anything about PRINT in the docs that would nail it
  61.     down one way or another.
  62.  
  63. The files that MAIL spools are always temporary copies, and are always marked
  64. /DELETE.  Of course, a user COULD modify the queue entry, causing the file to
  65. stick around.  If people are under the misapprehension that the /DELETE on
  66. the queue entry means that the ORIGINAL MESSAGE will be deleted, they might
  67. fall into this trap.  But somehow I doubt it.
  68.                             -- Jerry
  69.  
  70.