mcguffey@muvms3.bitnet (Michael McGuffey) (12/02/89)
I'm trying to get the decnet "task=" to work from an Ultrix node to a VMS node. The following is the command I'm using (although I've tried every combination of node/directory/quote marks I know): quayle %73 > dcp - muvms3::'task=decw_server' The following is the error I'm getting: dcp: can't create "muvms3::task=decw_server", Unspecified access error File Open, filename syntax error. My goal is to be able to (from the Ultrix node) run a .COM file on a VMS node that will open DECterm and application DECwindows on the Ultrix node. I'm currently logging in to the VMS machine to activate the .COM files. The Ultrix node is a DS3100 w/DECnet installed The VMS nodes vary from a VS3100 to a 6000-430. All nodes have the same result. thanks, -- michael ----------------------------------------------------------------------- Michael McGuffey, Senior Software Applications Analyst Phone: 304/696-3212 University Computer Center FAX: 304/696-3601 Marshall University BITNET: mcguffey@muvms1 Huntington, WV 25755-5320 Internet: mcguffey%muvms3@wvnvms.wvnet.edu
michaud@decvax.dec.com (Jeff Michaud) (12/05/89)
> 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: #include <stdio.h> #include <sys/types.h> #include <netdnet/dn.h> main(argc, argv) int argc; char *argv[]; { int sock; char str[128]; sock = dnet_conn( argv[1], argv[2], SOCK_SEQPACKET, (u_char *)0, 0, (u_char *)0, (int *)0); if( sock < 0 ) { nerror(argv[1]); exit(1); } while( gets(str) != NULL ) write(sock, str, strlen(str)); /* now wait for server side to close connection */ while( read(sock, str, 1) > 0 ) ; close(sock); exit(0); } (ignore the use of gets() and the lack of checking the arg list and ...) > My goal is to be able to (from the Ultrix node) run a .COM file on > a VMS node that will open DECterm and application DECwindows on the > Ultrix node. I'm currently logging in to the VMS machine to activate > the .COM files. You may want to look at "dcp -S" which may do enough of what you want that you won't have to write any code. /--------------------------------------------------------------\ |Jeff Michaud michaud@decwrl.dec.com michaud@decvax.dec.com| |DECnet-ULTRIX #include <standard/disclaimer.h> | \--------------------------------------------------------------/
michaud@decvax.dec.com (Jeff Michaud) (12/15/89)
In article <1529@propress.com>, pan@propress.com (Philip A. Naecker) writes: > In article <6595@shlump.nac.dec.com>, michaud@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@decwrl.dec.com michaud@decvax.dec.com| |DECnet-ULTRIX #include <standard/disclaimer.h> | \--------------------------------------------------------------/