patrick@pandh.demon.co.uk and Eduardo Serrat
emserrat@hotmail.comDECnet was designed by Digital as a way to interconnect their range of products. In its Phase IV implementation, released in 1983, it can support 63 areas of 1023 nodes each. The specifications for DECnet Phase IV are freely available. This has allowed others to provide DECnet connectivity in their products such as Sun's Sunlink DNI, and now of course Linux.
As with TCP/IP there are a number of higher-level protocols layered on top the basic DECnet protocol to provide services to applications. The ones currently available for Linux are DAP (Data Access Protocol, a File transfer protocol analagous to ftp in the TCP/IP world) and CTERM for remote terminal access (analagous to telnet).
DECnet for Linux is only really of use to you if you have OpenVMS machines, or other machines that use DECnet, on your site. There are several TCP/IP stacks for OpenVMS available from Compaq and several third-party vendors. These tend to be quite expensive, particularly when licenced for larger VAX or Alpha machines or clusters with large numbers of workstations.
DECnet is very common in OpenVMS shops because (although licenced seperately) it is bundled with OpenVMS. DECnet for Linux allows Linux boxes to participate as end nodes in a DECnet network. Maybe you have a Linux box as part of an OpenVMS to Unix migration plan (poor you!) or maybe it is providing internet services to your company. DECnet for Linux aims to provide you with the tools for Linux to participate inthe DECnet network.
In a nutshell, if you have OpenVMS machines and Linux machines at your installation then this software will probably be useful to you. If you've never heard for OpenVMS (or just plain VMS as us old-timers refer to it!) then you probably don't need it.
An end-node is a DECnet node that has no routing information. It can only (directly) access other machines in the same DECnet area (like a TCP/IP subnet) as itself. To access nodes in other DECnet areas a DECnet router must be present on the network.
The code is written to conform to the published DECnet phase IV specifications and so should work with any Phase IV node - this means VMS 4.0 and above should work.
In practice we are limited in the versions of VMS we can test on. Tramp (the machine in the picture on the web page) runs VMS V5.4 and Eduardo has access to machines running other versions up to V7.1 I reckon that all VMS 5.x should be fine - if anyone has any reports (good or bad) of this software with VMS V4.x I would be interested to know.
The DECnet for Linux home page is at http://linux.dreamtime.org/decnet There you will find all the sources for the kernel as well as several useful applications and utilities. Binaries are available for Intel and Alpha machines.
LAT (Local Area Transport) is a terminal protocol usually used for accessing terminals and printers conneced to terminal servers. LAT is an unpublished protocol only available under non-disclosure from Compaq. Because of this there are no plans to support it.
"DECnet-Plus" or "DECnet Phase V" or "DECnet-OSI" has been available in various forms for several years now and is standard with newer releases of OpenVMS. It is backward compatible with Phase IV.
There is no freely available documentation for the low-level details DECnet plus and there are no plans to support it.
Yes you can. If you want to run X-WIndows programs on OpenVMS and display them on linux you can download a DECnet enabled X-Server from http://linux.dreamtime.org/decnet/Xservers.html. If your X-server is not available then you will have to compile it yourself using the instructions at http://linux.dreamtime.org/decnet/x11r6.html. If you are using a commercial X-server then you may be out of luck.
If you want to run Linux applications on a VMS workstation then I have no doubt that it is possible to rebuild libX11 to allow this and if someone will give me a VMS workstation then I'll post instructions on how to do it !
Not at the moment but Steve Whitehouse is currently working on providing this functionality for a future release. So watch this space.
Currently only Intel and Alpha have been tested. I now own a SPARCstation IPC so a SPARC version will be available soon.
Contact the authors at the top of the FAQ to see what projects are underway to make sure you're not duplicating work. You will probably want to check the various DECnet specifications available at ftp://gatekeeper.dec.com/pub/DEC/DECnet/PhaseIV/index.html
DECnet uses the MAC(hardware) address to route messages between nodes. This effectively does away with the ARP protocol used by TCP/IP to map IP address to hardware addresses.
For most ethernet cards you will therefore have to change the card's hardware address so that it can pick up DECnet requests sent to it. (The DEC Tulip ship does not need this. If you are using the tulip or de4x5 driver for Linux then you probably don't need to do this).
See the web page for more information on how to do this and a program that can calculate the new MAC address for you.
You probably haven't run startnet to configure the interface.
It is most likely that you have not configured your ethernet card to listen to the correct hardware address (see "What's all this about configuring my ethernet card?")
If things spring back to life when you run "tcpdump" then this is almost certainly your problem.
Check that the decnet module is installed or compiled into the kernel. There should be a file /proc/net/decnet. If this does not exist then DECnet support is not installed. Check your kernel configuration.
Failing that check the /etc/decnet.conf file is set up correctly. If you installed the RPM files then a default one was installed that will certainly need editting for your site.
It is likely you have not added the node name to /etc/decnet.conf. The names of all nodes you need to communicate with must exist in this file.
Yes. This shows the address of the last router broadcast received.
The most likely cause is that the header files are not installed. These are distributed as part of the kernel patch and you must apply this patch to the kernel before building the tools.
You may have to make a link as follows:
ln -s /usr/src/include/netdnet /usr/include/netdnet
If it all compiles but fails to link then make sure you also have the DECnet libraries installed - get them from the download page.
Because DECnet file specifications contain shell reserved characters (such as quotes and square brackets) it is usually necessary to enclose them in single quotes thus:
$ dncopy 'tramp"patrick password"::[bin]forcex.exe' forcex.vax-exe
Because it's the most useful default. Unix files are stored as just a collection of bytes and where there is any record structure at all they are delimited by Linefeed characters.
Sending files this way ensures that the files keep their data and structure as intact as possible and also means that C programs can lseek() the files on VMS. (other VMS file formats can only be accessed by record)
If it's a sequential file you are sending then adding the switches -rvar
-acr will make the file into a normal VMS text file. If it's a binary
file you are sending then you will need to know what block size to use.
When you know this send the file with the switches -mblock -b512
where 512 is the block size (not a bad guess usually).
I suppose it could, it just doesn't! I'm working on an automatic conversion system for FAL and will probably retro-fit it to dncopy at some point. It won't be perfect though, there are always plenty of exceptions that will need to be catered for manually.
You certainly can. If you use the special filename '-' (that's a hyphen) as the input file name then dncopy will read from standard input, using a hyphen as an output filename will send the file to standard output. Thus:
dncopy 'tramp::login.com' | wc -l
will print the number of lines in your login.com file.
dncopy will copy all the data in a file (particularly if you use the -mblock switch) but it cannot copy file attributes such as key definitions. It will currently only copy sequential files to and from VMS. If you need to copy indexed or relative files then I recommend you back them up into a saveset and copy the saveset around.
dndir defaults to showing the file size in 512 byte blocks. This is what VMS does with its directory command. As of version 0.11 of the dntools dndir will show the file size in bytes if you use the -b or -l switches.
No. You can use a system known as DECnet proxies. You will probably need
to speak to your OpenVMS administrator to set these up. The authorizecommand can associate remote users on remote machines with local users.
A common default (entered as *::* */DEFAULT) will associate all remote
users with a similarly named user on the local VMS machine. See your
OpenVMS administration guide for more details.
Yes, if you run fal. FAL is part of the standard dnprogs distribution and
is started be default if you use the installation scripts provided. So all
your VMS users need to get access to Linux files is a username on the Linux
box. It is possible to set up DECnet proxies to help with this. type
man decnet.proxy for details.
It usually means that the command procedure does not exist on the OpenVMS machine, although it could also mean that the username/password was wrong or the DECnet proxies are not set up correctly. I'm sorry the error message isn't more helpful but DECnet simply refuses connections to unknown objects so there's not a great deal I can do about it. Sorry
The first thing to remember is that the command procedure on the OpenVMS machine must always send some output to SYS$NET, even if you are just launching an X-windows application (see DECTERM.COM), the DECnet protocol demands it.
Also remember that accessing command procedures as objects is actually quite a low-level function so things can break very easily. Make sure that the switches you give to dntask match the characteristics of the remote command procedure. If your object is behaving strangely it may be useful to look in the NETSERVER.LOG files in the SYS$LOGIN directory of the remote user. If you want to debug a task then WRITEs to SYS$OUTPUT will appear in NETSERVER.LOG too so you can trace what is happening.