iwm@icdoc.UUCP (06/18/87)
I would like to be able to pass parameters to a DECNET task, looking at examples in the manuals, the 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. For example we have TCP/IP on machine AVAX, on another node I should like to be able to type COPY prog.pas avax::"task=ftp asun2 prog.p" and have the ftp task read SYS$NET and ftp it to machine asun2 as prog.p. 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. Does anybody know whats going on here ? Does DECNET make use of the arguments (e.g for the FAL task) ?
LEICHTER-JERRY@YALE.ARPA (06/23/87)
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
-------