[comp.os.vms] Sending mail from a remote DECnet task

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