From: bruce@ais.com (Bruce C. Wright)
Newsgroups: comp.os.vms
Subject: Re: Alternative callable editors in MAIL?
Date: 25 Dec 92 23:47:51 GMT
Organization: Applied Information Systems, Chapel Hill, NC

In article <34147@twics.co.jp>, burress@twics.co.jp (Tim Burress) writes:
> We're running VMS 5.5, and have lots of people logging in through captive
> accounts.  The trouble is that they need to use MAIL and have the ability
> to edit their messages, BUT the default callable EDT editor is not sufficient
> for our multilingual/multistandard (whatever multistandard means) environment.
> 
> For non-captive users, we simply use the MAIL$EDIT logical to point to a
> command procedure which is then spawned by mail, but the code inside MAIL
> will not allow this to work for captive users.

Actually I think it's DCL that won't allow this to work (DCL is processing
the MAIL$EDIT file, not MAIL).  But the end result is the same.

> So my question is whether there is a procedure for installing a different
> callable editor, and having MAIL use that one instead of EDT.  I know it's a
> longshot, but the alternative is using the callable mail routines to write my
> own mailer, and it's not how I planned to spend my holiday.

You can very often set things up so that almost any editor can be used as
a callable editor in MAIL.  For example, suppose you have a locally-written
editor named XYZ -- what you need to do to make it callable from MAIL is:

    1)	Create a sharable image containing the basic editor code.
	It may be necessary to make this a `jacket' image that 
	spawns the actual editor in a subprocess if you don't have
	sources/objects for the editor and/or the editor refuses to
	run in the same process context as MAIL.  I think that in
	this case you'll be in trouble if the editor needs DCL in
	its image (say to read command arguments) -- this won't
	work from a captive account.

    2)  Have a procedure named XYZ$EDIT in the sharable image.  The
	arguments should look like the callable EDT interface routine
	named EDT$EDIT, although I think you can just get by with 2
	arguments for callable MAIL (input_file, output_file).  Note
	that the arguments are passed by descriptor!!  This procedure
	should start up the editor on input_file and write it to
	output_file when done.  You'll probably want to do the image
	`properly' with a transfer vector and so forth, this often 
	makes things simpler to deal with when things change.

    3)	Place the sharable image in SYS$SHARE:XYZSHR.EXE.  Alternatively,
	define a logical name (probably system-wide so it will be visible
	to captive users) called XYZSHR that points to the sharable editor
	image.

    4)	Optionally install the image.  It doesn't have to have any
	special privs, but you may want to install it /OPEN /HEADER /SHARE
	to minimize startup time and memory usage if several people are
	using the editor.  It should work without being installed however,
	unless the editor does something funny that needs privs :).

    5)	Within MAIL, do a SET EDITOR XYZ (and DON'T set the MAIL$EDIT
	logical name, that will override the SET EDITOR command when MAIL
	starts up and the users will need to do an explicit SET EDITOR
	every time they get into MAIL).

    6)	You should probably start up MAIL as MAIL/EDIT so that the
	editor is invoked by default when the user SENDs or REPLYs to
	message.

That's all there is to it.

If you're using a standard DEC editor like EDT, TPU, or TECO, they already
have the appropriate sharable image in SYS$SHARE and you can just skip to
step 5.  

Good luck -

Bruce C. Wright