From: CSBVAX::MRGATE!@KL.SRI.Com:leichter@venus.ycc.yale.edu@SMTP 17-OCT-1987 13:28 To: EVERHART Subj: re: DEC Mail Utility Madness Received: from venus.ycc.yale.edu by KL.SRI.COM with TCP; Sat 17 Oct 87 09:46:53-PDT Date: 17 Oct 87 11:43:00 EDT From: "Jerry Leichter" Subject: re: DEC Mail Utility Madness To: "vms.macc.wisc.edu!dorl" cc: info-vax@kl.sri.com Reply-To: "Jerry Leichter" We have several users who have choosen to use a different editor to compose their mail messages using the MAIL$EDIT logical name feature in DEC's Mail utility as explained in section 3.1 of the 'Mail Utility Reference Manual'. This all worked fine until one of them tried to read a message with the READ/EDIT, NEXT/EDIT, FIRST/EDIT, or LAST/EDIT commands. Mail produces the following error messages when one has defined MAIL$EDIT and attempts to use these commands. %MAIL-E-NOTCALEDT, this command procedure cannot be executed. MAIL$EDIT does not specify a callable editor. Does anyone have any insight into this? How would one define MAIL$EDIT so that the whatever/EDIT commands would work? You cannot use a MAIL$EDIT value that causes a command procedure to be executed with these commands - exactly as the error message says. If you want to use these commands, (a) your editor must support the standard callable editor interface [see the documentation of callable TPU]; (b) your editor must be INSTALL'ed (since it will be called, using LIB$FIND_IMAGE_SYMBOL, by MAIL, which is a privileged program; (c) MAIL$EDIT must be defined to be CALLABLE_your_editor. WARNING Don't do around blindly installing alternate editors to make them work with this interface; they will run with MAIL's privileges, which are quite sufficient to do anything you like to the system. -- Jerry (As to why this happens: The commands that fail to work are those for which the data to be edited may be in a temporary file with no directory entry (LAST/EDIT), or not in its own file at all (the others - the message may exists only as a couple of records in an ISAM mail file). MAIL can provide callbacks to itself across the callable editor interface, and thus provide access to the data; for the "spawned editor" interface, all it can do is give a file spec - which it doesn't have in these cases.) ------