MACPHEDR@SASK.BITNET (04/28/87)
This is a question on VMS MAIL & why it doesn't work from a DECnet task. (At least under VMS version 4.4 and 4.5) I have a DECnet task running asynchronously which I would like to monitor indirectly (i.e. not typing NETSERVER.LOG to see if it's done yet, or SHOW PROC, etc.) by having it send me mail. However, the mail message does not come through, nor is an error generated. An example is the following file: $! TESTMAIL.COM $ MAIL NLA0: ONODE::MACPHEDRAN/SUBJ="TEST OF MAIL" $ EXIT It will send me a null message (which I intended) when run as a) a regular command procedure ($ @MAILTEST); b) a subprocess ($ SPAWN/NOWAIT/INPUT=TESTMAIL.COM/OUTPUT=TT:); c) a batch process ($ SUBMIT/NOPRINT TESTMAIL.COM); but does nothing when run as a network task ($ TYPE ONODE::"0=MAILTEST" {I have a proxy across}). The process starts up MAIL, but does not send anything, and appears to `hang'. Does anyone know why this happens, and if there is a way around it, other than spawning off a subprocess, or submitting a batch job from my network task? (I have tried both options, and they do work, but it isn't all that nice to do, especially for some applications I am thinking of doing in the future.) Thanks in advance. Ian. +------------------------------------+--------------------------------+ | Ian MacPhedran | USEnet ihnp4!sask!macphed | | Engineering Applications | BITNET MacPhedran@Sask | | Department of Computing Services | Phone (306) 966-4832 | | 2B13 Engineering Bldg. | Telex 064-2659 | | University of Saskatchewan, Saskatoon, Saskatchewan, Canada S7N 0W0 | +---------------------------------------------------------------------+ (for those on ARPAnet try macphedran%sask.bitnet@wiscvm.edu)
PKARP@IU.AI.SRI.COM (Peter Karp) (04/29/87)
I believe that your problem with trying to use MAIL from within a network task results from the fact that the MAIL program is used not only to compose outgoing mail, but to receive incoming mail from other DECnet nodes. When mail starts up it determines what mode (interactive/network/batch) its job is running in, and if it's running in network mode it assumes that it's being invoked as an agent to receive incoming mail. Thus it's probably hung on you trying to read an incoming message from the network. This would explain why it works when your network job runs it from batch. Gee, and I thought I had already determined all the ways in which VMS MAIL is brain damaged... As a fix, maybe before running MAIL you could run a program which toggles the mode bit in the PCB (or wherever it is) to fool MAIL into thinking it's running interactively. PKarp -------
ESMP09@SLACTWGM.BITNET (Ed Miller SLAC x3291 or [415]854-1055) (04/29/87)
Ian MacPhedran inquires about the following problem: > I have a DECnet task running asynchronously which I would like to > monitor indirectly (i.e. not typing NETSERVER.LOG to see if it's > one yet, or SHOW PROC, etc.) by having it send me mail. However, > the mail message does not come through, nor is an error generated. I believe that the cause of your difficulty is that MAIL.EXE, when it sees that it is running as a network job, assumes that its mission is to support requests from remote nodes to deliver mail to addresses on the local node. See, for instance, SYS$SYSTEM:MAIL.COM, which supports this mode of operation. I too encountered this problem. The only work-around I found was to replace the MAIL command in my similar network task with a SPAWN command which executed the desired MAIL command. The specific format of the command I use is $ SPAWN/NOLOG/NOSYMBOLS/NOLOGICAL/INPUT=NLA0:/OUTPUT=NLA0: - MAIL/SUBJ="subject text" nla0: address Ed Miller ESMP09@SLACTWGM.BITNET
NED@YMIR.BITNET (Ned Freed) (04/29/87)
The reason that MAIL behaves peculiarly from a DECnet task is that MAIL assumes it is acting as a network object when it runs within a network job. It tries to open SYS$NET and talk its little NJE protocol on the link. MAIL is not unique in this respect; a lot of utilities operate in a different mode when run as a network process (e.g. PHONE). Your idea of running MAIL as a subprocess will probably avoid this difficulty. Ned