Last time I changed EDT.COM, I added some filespec defaulting, which
was, to say the least, not appreciated.  By most.  But some people want
the new way (oops).  So, here's the compromise.  Beleive it or not, it is
just as easy/hard for the system to do it this way as the other way;
I just didn't choose this way the first time.

    How it comes up with the filespec to edit is this:
    	First, it extracts the filespec you supplied, if any.
    	Next, it applies defaults from the global symbol USER$_FILE_DEFEXT.
This symbol might be set to ".MAC" or ".C" in your login.com file.
    	Next, it applies defaults from the global symbol EDT$MEMORY (if it
exists yet).
    	Then it extracts just the name and extension from the result and
makes that the new value of the global symbol EDT$MEMORY.
    	Finally, it invokes the editor on the fully-specified file (device
and directory too).

    So, if you want the default to ALWAYS be such-and-such, give that value
to USER$_FILE_DEFEXT.  If you want the default to be what it was last time,
leave USER$_FILE_DEFEXT undefined.  You can stick a filename in
USER$_FILE_DEFEXT if you want a default filename too, but this might
break other stuff.  For which I will take no responsibility.

    The advantage of all this noise is that if you use EDT.COM, you guarantee
that you won't step on anybody elses edit, unless they go out of their way
to fool EDT.COM, or you both start your edits more-or-less simultaneously
(on the order of a second or so apart).

    If there should be discovered a way to break this protection, PLEASE LET
ME KNOW since a fair number of people (you just wouldn't BELEIVE how many)
depend on this protection.

    FYI, here is the comment block at the beginning of the file which is
supposed to give an overview of the algorithm.

$! Apply filespec defaults:
$!	Take filespec user supplied (command line must first be parsed)
$!	Apply "''USER$_FILE_DEFEXT'" as default
$!	Apply "''EDT$MEMORY'" as default
$!	save resultant name and extension (only) as EDT$MEMORY
$! Check for other people editing same file:
$!	Determine journal filespec
$!	Check for journal file's existence
$!	if journal file is open, abort
$!	if not /RECOVER, abort
$! Select EDT initializer file:
$!	Select filename (EDTVT100, EDTVT52, or EDTINI)
$!	If file exists in UTL$COM:, select that
$!	If file exists in SYS$LOGIN:, select that
$!	If file exists in current default directory, select that
$! Invoke editor.


From:	KIM::SUTTLES      20-MAR-1985 09:45:30.43
To:	@SYS$MAIL:ENGINEER.UAF,@CHARM::SYS$MAIL:ENGINEER.UAF,SUTTLES     
CC:	
Subj:	EDT.COM again

	It has been pointed out that since I forced the journal file to be
created in the same directory as the file being edited, you can't
@EDT somebody else's file /READ cuz you can't create the journal file.

	So I changed it (surprise!).
\
	As of this morning, /READ will imply /NOJOURNAL.  If you want
a journal file with a /READ, use /READ/JOURNAL or /JOURNAL/READ (order
doesn't matter).  The location for the journal file will be your current
default directory.  Or you can specify a filename on the journal switch,
ie, /JOURNAL=SYS$LOGIN: or some such.

	Because the primary purpose of the com file is to provide protection
against two people in the same directory editing the same file, when you
use the com file and cause no journal file to be created (this is what it
checks for) a warning is printed on the terminal to let you know that you
should be careful.  This applies to the /READ qualifier as well.

	Contrary to popular opinion, the com file does NOT exist to generate
junk mail.  Just works out that way.

sas