dorl@vms.macc.wisc.edu (Michael (NMI) Dorl) (10/16/87)
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?carl@CITHEX.CALTECH.EDU (Carl J Lydick) (10/17/87)
> 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? The READ/EDIT, NEXT/EDIT, FIRST/EDIT, and LAST/EDIT commands require a callable editor (i.e., one that has an entry point that allows the mailer to map the image and call the entry point from within the process running MAIL, rather than requiring that the editor be invoked via a DCL command). As far as I know, the only two editors that currently let you do this are EDT (the default) and TPU. To use TPU as the editor, define MAIL$EDIT to be CALLABLE_TPU.
leichter@VENUS.YCC.YALE.EDU ("Jerry Leichter") (10/17/87)
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.) ------
u3369429@murdu.OZ (Michael Bednarek) (10/19/87)
In message <1894@uwmacc.UUCP> dorl@vms.macc.wisc.edu (Michael (NMI) Dorl) wrote: >[defining MAIL$EDIT as explained in section 3.1 of the 'Mail Utility Reference > Manual' doesn't work for READ/EDIT, NEXT/EDIT, FIRST/EDIT, or LAST/EDIT > commands as it does for SEND/EDIT REPLY/EDIT] and asks the important question: >How would one define MAIL$EDIT so that the whatever/EDIT commands would work? to which carl@CITHEX.CALTECH.EDU (Carl J Lydick) in article <871017023422.00f@CitHex.Caltech.Edu> responded: >[define MAIL$EDIT as CALLABLE_TPU to use TPU with READ/EDIT, NEXT/EDIT, > FIRST/EDIT, and LAST/EDIT] to which nagy%warner.hepnet@LBL.GOV (Frank J. Nagy/VAX Guru) in article <871017100017.023@Lbl.Arpa> further elaborated: >As of LSE V2, you can also use callable-LSE with MAIL (I'm using it >right now as a matter of fact :-) by defining MAIL$EDIT as CALLABLE_LSE. Then, leichter@VENUS.YCC.YALE.EDU ("Jerry Leichter") in article <8710171848.AA08295@ucbvax.Berkeley.EDU> explained: >(As to why this happens: [read the referenced article] Well, the original question hasn't been answered yet: >How would one define MAIL$EDIT so that the whatever/EDIT commands would work? That is, how to send AND read mail using the same editor interface, not just the same editor. E.g. my MAIL$EDIT points to a EDTINI.EDT file in a group's common directory, which defines a number of additional keys and such. I realise that an EDTINI.EDT file in my current directory would be read by a CALLABLE_EDT, but I'm not always in my SYS$LOGIN when I read mail. The only workaround seems to me to: *include <my-usual-EDTINI.EDT> =INI *define macro ini *ini This, however, does not completely work as a number of EDT commands are executed properly only during startup, like SET COMMAND, SET MODE CHANGE. So how does one cause CALLABLE_EDT to execute a specific startup file? (BTW, DEFINE CALLABLE_EDT <my-usual-EDTINI.EDT> and DEFINE MAIL$EDIT CALLABLE_EDT doesn't work :-) ) Michael Bednarek Institute of Applied Economic and Social Research (IAESR) Melbourne University, Parkville 3052, AUSTRALIA, Phone : +61 3 344 5744 Domain: u3369429@{murdu.oz.au | ucsvc.dn.mu.oz.au} or mb@munnari.oz.au "bang": ...UUNET.UU.NET!munnari!{murdu.oz | ucsvc.dn.mu.oz}!u3369429 "POST NO BILLS."
u3369429@murdu.OZ (Michael Bednarek) (10/21/87)
Inferring from the speed and number of responses to my question about MAIL and EDT, it seems that my problem was an easy one. My problem was: >>How would one define MAIL$EDIT so that the whatever/EDIT commands would work? > >That is, how to send AND read mail using the same editor interface, not just >the same editor. The solution is: o Have MAIL$EDIT undefined or defined as CALLABLE_EDT, e.g.: DEFINE MAIL$EDIT CALLABLE_EDT o Have EDTINI defined as your EDT startup file, e.g.: DEFINE EDTINI COM_LIB:OUR_EDT.STARTUP A very good discussion about EDT and startup files can be found through: HELP EDIT /EDT /COMMAND In some of the mail I received, I also got lectured about the ambiguous wording of my posting. I agree completely. In fact, I was aware of the rule: "State your problem, not what you think the solution might be" and loathed a number of postings to this newsgroup because they failed to follow this rule. And still, I ran into that very trap. So, here are a few sentences which should probably appear whenever one is about to post a message to comp.os.vms/INFO-VAX: "And now, once more with feeling, a message to all who would ask questions on "the net: Please, please, DON'T assume you understand exactly where or what "your problem "really" is. If you did, you would most likely already know the "answer. Don't ask "How can I change my editor" when what you are trying to "do is change your initialization file! Describe the PROBLEM you are having, "NOT what you think the solution is, or ought to be. You are more likely to "get a useful response. Also, READ THE RESPONSES YOU GET. What you want to "do may be impossible! If your responses tend in that direction, don't assume "everyone is out to get you or is just ignoring your question. Maybe you "haven't phrased your question in way that can be answered. Maybe you haven't "provided all the information needed for someone to provide you with an answer. "Try again if you think you can provide more information - and take it as a "lesson in question phrasing for the next time. Thanks to all who took he time to mail me. In order of appearance: MVAX::DIRK (Dirk van der Knijff) JIMR@METRO (Jim Richardson) SIT.BUSH@CU20B.COLUMBIA.EDU (Nick Bush) BOTMAN@HLERUL5.BITNET (Carlo Mekenkamp) IUS%DACTH51.BITNET@CUVMA.COLUMBIA.EDU (el) LEICHTER@VENUS.YCC.YALE.EDU (Jerry Leichter) BSU-CS!CFCHIESA@MUNNARI (Chris Chiesa) I also would like to thank these people for doing the right thing, i.e. sending mail to me, rather than posting to the net. Michael Bednarek Institute of Applied Economic and Social Research (IAESR) Melbourne University, Parkville 3052, AUSTRALIA, Phone : +61 3 344 5744 Domain: u3369429@{murdu.oz.au | ucsvc.dn.mu.oz.au} or mb@munnari.oz.au "bang": ...UUNET.UU.NET!munnari!{murdu.oz | ucsvc.dn.mu.oz}!u3369429 "POST NO BILLS."
mithomas@bsu-cs.UUCP (Michael Thomas Niehaus) (10/23/87)
In article <1315@bsu-cs.UUCP>, neubauer@bsu-cs.UUCP (Paul Neubauer) writes: > ...If you are logged in to your own account, then your LOGIN.COM > can say DEFINE EDTSYS SYS$LOGIN:EDTINI.EDT and then you can use that setup > from any of your subdirectories, or if you frequently use other accounts (as > I do) then you can have an initialization file of your own on that account > that runs a command procedure (e.g. one kept in your own account) that > contains the appropriate definition (except change the "SYS$LOGIN" in the > above to refer to the actual account and directory where that file is > located. Note that your EDTINI.EDT file need not be in your SYS$LOGIN > directory, or even in your own acocunt, as long as EDTSYS is defined to > refer to it. In fact, it need not even be named EDTINI.EDT, though life is > probably simpler if the name you use for it is not too opaque. > -- > Paul Neubauer UUCP: <backbones>!{iuvax,pur-ee,uunet}!bsu-cs!neubauer > Here is some more complete information on EDT: In the LOGIN.COM file type the following line: $ define/nolog edtsys disk_whatever:[directory_whatever]edtini.edt When running EDT, it follows the following steps to determine how to initial- ize: 1. /COMMAND=filename qualifier included? If so, use. If not... 2. EDTSYS logical name assignment defined? If so, use. If not... 3. File SYS$LIBRARY:EDTSYS.EDT found? If so, use. If not... 4. EDTINI logical name assignment defined? If so, use. If not... 5. EDTINI.EDT file in current default directory? If so, use. If not... 6. Begin EDT in default state. As you can see, there are many ways that a command file can be used with EDT. Take your pick. Michael Thomas Niehaus UUCP: <Backbones>!{iuvax,pur-ee,uunet}!bsu-cs!mithomas P.S. I couldn't pass up the chance to expand on one of my former professor's discussion.