From:	CSBVAX::MRGATE!@KL.SRI.Com:leichter-jerry@yale-venus.ARPA@SMTP 22-JUN-1987 14:44
To:	EVERHART
Subj:	Re: Parameters to network tasks

Received: from yale-venus.ARPA by KL.SRI.COM with TCP; Mon 22 Jun 87 09:03:59-PDT
Date: 22 JUN 1987 11:58:23 EST
From: <LEICHTER-JERRY@YALE.ARPA>
To: eagle!icdoc!iwm@ucbvax.Berkeley.EDU (Ian Moor)
cc: info-vax@kl.sri.com
Subject:  Re: Parameters to network tasks
Reply-To: <LEICHTER-JERRY@YALE.ARPA>

    I would like to be able to pass parameters to a DECNET task.... [T]he
    recommended way seem to be to write them on  the DECNET link and have the
    task read them from SYS$NET, this seems too complex for simple uses and
    requires producing special sending software.  Some experimentation shows
    that one extra argument is passed as P1 to the task (a command file) IF it
    is only alphanumeric, putting more arguments causes an error 'incorrect
    device type', giving a fileid with a dot in it causes a network protocol
    error and quoting the arguments  seems to prevent them being transmitted.

What follows the "TASK=" is a task specification to be interpreted by the
remote system.  The local system is not assumed to understand what task spe-
cifications on the remote system look like, so it doesn't look at them closely.
However, there are some restrictions imposed by the network protocol.  You'd
have to dig around to be sure, but it appears that the task specification
must (a) consist only of alphanumerics and spaces (?); (b) be no more than
some number of characters - I think the number is 15.  What appears to be
happening is that the TASK object works by taking whatever "task specification"
it is handed, dropping an "@" in front of it, and passing the string to DCL.
Thus, an access to "TASK=COM 1 2" results in DCL seeing @COM 1 2, which re-
sults in COM running with arguments P1=1, P2=2.

Further experimentation reveals that there are (at least) two possible error
messages:  "Network protocol error" and "Error in device name".  It looks as
if the latter occurs when the complete string - "TASK=..." - gets longer than
some limit the local RMS imposes, while the former occurs when the string
itself is legal, but the task specification is not.  Embedding things that are
not legal characters for a task specification also causes errors to be repor-
ted, as you've noticed.

Two things to note:

	The fact that VMS passes the additional arguments at all may very
		well be a bug - I find it strange that the definition of a
		task specification should include spaces;

	Even if it is not a bug, the exact way the task specification is
		handled by the TASK object is undocumented and subject to
		change. It is also unique to the TASK object - you can send
		FAL any odd-looking specification you like, but all it is
		going to do is pass the whole thing on to RMS as a file
		specification.

So...returning to your original question:  There is no way to pass additional
data along when using transparent DECnet access.
							-- Jerry
-------