From:	MERC::"uunet!CRVAX.SRI.COM!RELAY-INFO-VAX" 16-JAN-1993 14:33:58.28
To:	info-vax@kl.sri.com
CC:	
Subj:	Re: Problem with "TASK=dclproc"

In article <1j4ggfINN1aad@rs1.rrz.Uni-Koeln.DE>, aeg03@rrz.uni-koeln.de (Jan T. Kim) writes:
> TYPE vax"foo bar"::"task=dclproc"
>
> does not successfully execute the DCLPROC.COM procedure in  foo's
> login directory. Instead, I get error messages:
>
> %TYPE-W-OPENIN, error opening VAX"foo password"::"task=dclproc" as input
> -RMS-F-ACC, ACP file access failed
> -SYSTEM-F-LINKEXIT, network partner exited.

You know, it would have helped a WHOLE LOT (and probably would have saved you
some flames, which are no doubt already being transmitted) if you had included
the contents of DCLPROC.COM .  A copy of the NETSERVER.LOG (found in the
SYS$LOGIN directory of the target user on the target node) would have helped
even more, as would the output from the ACCOUNTING utility showing the final
completion status of the target process.

However, this problem is a common one and is probably solvable without that.
(More on THAT point in another article.)

It sounds very much as though DCLPROC.COM is never confirming the inbound
connect, _i.e._, it is not doing anything that opens a channel to SYS$NET.

(If your DCLPROC.COM *does* open SYS$NET, something is killing it before it's
getting that far.  But in that case the error is usually not "Network
partner exited".)

Suppose DCLPROC.COM looks like this:

        $ open/write the_link SYS$NET   ! (1)
        $ write the_link "HI THERE"     ! (2)
        $ close the_link                ! (3)
        $ exit 1                        ! (4)

If line (1) is missing, you will always get the "...network partner exited".

btw, you may need some way to synchronize with the reading of the messages
before you do (3).  If you see evidence of "dropped writes" (eg DCLPROC.COM
sends 10 messages, but the reading task only sees the first eight), you are
seeing the effects of DECnet pipelining.  The right way to fix this is to have
the task that is (mostly) reading send a message back to the writer when it's
gotten the writer's last message.  THe writer shouldn't close its end of the
link until it's read this "Over and out" message.  (If you're lazy you can just
wait a reasonable time, ten seconds or so, between WRITEing the last buffer and
closing the link.)  Failure to do this in executable programs almost always
results in lost data.  I can't swear that I've never seen it happen in DCL, but
it certainly seems rare.  DCL may be doing some extra synchronization steps (no
doubt an undocumented interface to NETDRIVER).

	--- Jamie Hanrahan, Kernel Mode Systems, San Diego CA
drivers, internals, networks, applications, and training for VMS and Windows NT
uucp 'g' protocol guru and release coordinator, VMSnet (DECUS uucp) W.G., and
Chair, Programming and Internals Working Group, U.S. DECUS VMS Systems SIG
Internet:  jeh@cmkrnl.com, hanrahan@eisner.decus.org, or jeh@crash.cts.com
Uucp:  ...{crash,eisner,uunet}!cmkrnl!jeh