DECnet TASK= activation from an Ultrix machine
Jeff Michaud
michaud at decvax.dec.com
Fri Dec 15 13:21:55 AEST 1989
In article <1529 at propress.com>, pan at propress.com (Philip A. Naecker) writes:
> In article <6595 at shlump.nac.dec.com>, michaud at decvax.dec.com (Jeff
Michaud) writes:
> >> I'm trying to get the decnet "task=" to work from an Ultrix node
> >> to a VMS node.
> >> quayle %73 > dcp - muvms3::'task=decw_server'
> >
> > Sorry, the node::"0=taskname" convention is a RMS-32ism on VMS.
> > You are going to have to write a small C program to do the
> > equiv. For example:
>
> I just did it three days ago, using dcp. I seem to recall that there was
> something annoying about wildcards and directory specs, but other than
that it
> worked fine.
Could you please elaborate (ie. give an actual example/output
that worked)? Here is what I get:
% dcat vmssys/michaud::TASK=TEST
Password for vmssys/michaud:: ?
dcat: can't open "vmssys/michaud::TASK=TEST", Unspecified access error
File Open, filename syntax error.
which is what I expected since VMS filespec can't contain `=' signs.
As I was saying before, the reason you can do it under VMS is
because RMS gives special meaning to the syntax:
node::"N=XYZ"
where
N is the the number of a numbered DECnet object, and
XYZ is the name of a named DECnet object (when N is 0).
N can also be replaced by the network mangement name
of a local object defined in the object's database.
For example, TASK is usually defined in the objects
database with an object number of 0. Note however
that it's safer to use the actual number if you don't
want to be dependent on the object that you are trying
to access remotely having to be defined in the local
node's objects database also. To see the contents of
the local nodes objects database under VMS you can give
the command:
mcr ncp show known objects
What RMS does when it recognizes this syntax is instead of connecting
to the FAL object of the specified remote object to open a real file,
connects to the specified object on the remote node instead and returns
one record for each DECnet Session Control packet read if the direction
of I/O is READ. If I/O is to WRITE then one DECnet Session Control packet
is written (sent) to the remote object for each input record.
The node::N=XYZ syntax (no quotes because the users shell is going to
eat the quotes anyways before giving it to the program) doesn't work
under DECnet-ULTRIX because dcp and dcat just passes remote filespecs
to the remote FAL w/out looking at them at all (no hocus pocus :-).
If you really want to dcp and/or dcat to access a remote VMS object,
you can try the giving to dcp and/or dcat the filespec:
vmssys::'0::"0=XYZ"'
If access control is needed to access the object then try:
vmssys::'0"user password"::"0=XYZ"'
and if default FAL access on the VMS node is disabled:
vmssys/user/password::'0"user password"::"0=XYZ"'
This of course is a two hop process. From the local ULTRIX node
to the remote VMS FAL through RMS to the ultimate remote object
(ie. it uses PMR [Poor Man's Routing] through FAL)
> One definite problem in the original poster's example is the
> "task=verylongname". There is a limitation in the DECnet Task protocol that
> enforces task names no longer than 6 (I think) characters.
I think you are confusing this with the limitation on node names (which
can only be 1-6 alphanumerica characters w/at least one alpha character).
Named objects (ie. node::"0=XYZ") are 1-16 octets (usually ascii characters).
Note also that there really isn't anything such as "the DECnet
Task protocol". What RMS's node::"N=XYZ" syntax is doing is
making a DECnet Session Control connection to the specified remote
object and instead of talking the DECnet DAP protocol (which it can't
do since the remote object isn't going to understand DAP) to access
remote files, talks no protocol and simply sends and/or receives
the messages (records) that are given to RMS.
/--------------------------------------------------------------\
|Jeff Michaud michaud at decwrl.dec.com michaud at decvax.dec.com|
|DECnet-ULTRIX #include <standard/disclaimer.h> |
\--------------------------------------------------------------/
More information about the Comp.unix.ultrix
mailing list