Due to popular demand, the utilities MAIDIR and MAILCK have been
enhanced.  This is a major release (rewritten from scratch), and probably
has brand new bugs.

    As far as I know, the current usage is not affected at all (total
upwards compatibility), unless you have one mail file in particular
(DIR.MAI).

    Here's how to use the new stuff:

    In your LOGIN.COM file, you say
    	$MAI*L :== @SYS$SYSDEVICE:[UTILITIES.COM]MAIDIR
and from that time forth, when you invoke mail, a file (WAS MAIL.RVN,
NOW DIR.MAI) is created which indicates the time you exited.  Under the
new version, the contents of this file is a directory of SYS$LOGIN:*.MAI;,
so you can READ DIR to find out what categories you have filed stuff under.

    Somewhere AFTER the first definition (in your LOGIN.COM file), say:
    	$ @SYS$SYSDEVICE:[UTILITIES.COM]MAILCK
to automatically enter MAIL if you have received mail since you last exited
the MAIL program.  Note that it is possible to exit the program without reading
all your new mail, so it is conceivable to have new mail and not auto-invoke
MAIL.  But if this happens, you set it up that way, presumably on purpose.
You have not received any mail since you last exited MAIL.

    The really neat part is that you can also (or instead) say:
    	$ @SYS$SYSDEVICE:[UTILITIES.COM]MAILCK device/directory_spec
to check for new mail on other logins.  This even works across the network,
although you may find the time required for access to be restrictive.  You
might define the @...MAILCK part to be a word, and then CHECK [so-and-so]
interactively.  You can find out if the other accounts have mail, but
it is not possible to read their mail (don't bother), so you are simply
notified that there is "New mail in what-you-said".  It's up to you to
log in with your other account and read the mail.

    Incidentally, the DIR mail file will contain the directory as of the
last time you exited MAIL.  If you delete or rename files using DCL, these
changes won't be seen until you exit mail again.  The DIR file also does not
have the standard MAIL format (FROM and TO lines are missing) so a MAIL
DIRECTORY command will blow up (not my fault!).  Take my word for it, there
is only one message in the file.  I do not reccommend FILEing that message
anywhere.

    Another fine point:  the MAIDIR command procedure takes an optional
parameter.  If it is absent, the DIR.MAI file will be typed out before
the first MAIL prompt--this shows you where you have things FILEd.  If this
bothers you, you can supply anything for the first parameter, and it will
be skipped.  I reccommend "-Q" in case of further changes.  This is not
a change from the older version, and your LOGIN.COM definitions will work
the same way as they have in the past.

    If you find that the changes I have made make you unable to use MAIL,
please send me a mail message describing the problem.  Have fun, and good luck.

sas

	There are some problems with the new mail checker.  It works
fine in the applications it used to be used in; the (known) problems
are all in the enhancements.

	To start with, when you check someone elses mail file, you have
to have read access in order to find out the attributes (date of last
modification is an attribute).  So, you need to change the protection
on your mail file in order for that to work--and then anyone can read
your mail.  I think that's icky.

	Then, for CHECKs across the network, DCL doesn't close the channels
used to obtain the information about the file--so you wind up with 4
jobs started on the other node.  This is a somewhat excessive overhead.
These jobs stick around till you log off.

	Lastly, if circumstances are "right" (don't ask, I don't know
for sure myself) you can get an RMS error, Dynamic Memory Exhausted.  I
checked into that and the suggested cure is to relink the program so
that the control area is bigger.  The program I'm using is DCL, and I'm
not that eager to replace the current version.

	None of this happens if you are checking your own mail (which is
all it used to do).  I haven't decided whether or not to fix it, cuz of
version 4 coming up (mail is different in V4...you will get a { L O N G }
list of changes for V4 soon {maybe eventually, anyway}).  It seems that
the cure is to write a quick and dirty (or time-consuming and correct)
program to do the checks and return a status.

	Sorry for the false alarm, but I'm sure somebody with a dirty
mind once said it: Hope springs eternal in the human breast.  Don't let
it get you down.

sas

for those of us usually on CHARM:
  you can use the aforementioned MAIL CHECK routine IF you do a kludge in
your LOGIN.COM on KIM.  If you add 

$SET PROT=W:RE DIR.MAI

then CHARM::[WHATEVER] will be able to check your mail.

- by the way, It doesn't do it in a very elegant way:  if you DO get
new mail, you get an error message

%SYSTEM-F-NOPRIV, no privilege for attempted operation

And if you've read all your mail, you don't get the error.  Useful but UGLY.

The correction to the protection of the directory file ($SET PROT=W:RE DIR.MAI)
is indeed necessary to avoid a privilege violation.  Unfortunately, the
same kludge is necessary to the MAIL.MAI file, and I think the system
resets the protection if new mail is received.  I could have stuck these
commands in the file that creates DIR.MAI but I expected to get a lot
of flak for making your mail publicly accessible without telling you.
Also, I'm pretty sure the system will change the protection back, so
the error wouldn't go away.  And on top of that, there is still the
problem of the 4 processes (per $CHECK) that are created on the remote
node.

Public opinion poll:  How many people (not accounts, PEOPLE) would use
CHECK if it worked as intended?  That is to say, if it didn't blow up,
didn't advertise your mail, and also didn't use up multiple job slots
forever?

How many would use it if I couldn't avoid the advertising?

Please respond to KIM::SUTTLES.

sas