WARNOCK@clemson.CSNET.UUCP (02/23/87)
We would like to be able to directly access BITnet from out VAXes. Several solutions have been posed locally, but it seems no one is really clear on what's the best way to proceed. Out VAXes are running VMS v4.5 and out NAS AS XL-60 (IBM 3090 clone) is running MVS/XA. We are currently running TCP/IP and DECnet on the VAXes and have ethernet strung most places (including across campus to our NAS, which, right now, has our BITnet feed. Stringing cables are not a *big* problem, although using the existing ethernet would be nice. Mention has been made of JNET. Knowing very little about this, I would appreciate any information about JNET, public domain versions of JNET (if there is such a thing), as well as information on whether or not it's possible to use our existing ethernet to accomplish what we'd like. Thanks ! Todd Warnock Clemson University CSnet: Warnock@Clemson.CSnet BITnet: Warnock@Clemson
X230GV@TAMVM1.BITNET.UUCP (02/25/87)
From Todd Warnock: >We would like to be able to directly access BITnet from out VAXes. Several >solutions have been posed locally, but it seems no one is really clear on >what's the best way to proceed. The only thing I know of is jnet. We run it here, and are satisfied in the sense that it works as promised . . . but some things could be a lot better. They supply a DECnet connection driver for connecting VAXes on Bitnet, and that works great. The interactive messaging is widely used as an alternative to the incredibly annoying phone utility, and the file transfer is fast and reasonably clean. This may not seem too useful since we can do DECnet copies, but it is nice to be able to have file transfer initiated by the sender, without having to set up proxies or protections or acls etc. Also, since Bitnet is a store-and-forward net, you can send a file even if the destination node is down. It adds a lot of versatility to the DECnet. The big problem is that the only other driver they supply is for an asynch connection which is terribly slow. The entire campus DECnet is a subtree connected to the rest of Bitnet via an asynch connection to TAMVM1 (a VM/CMS node). This is the big bottleneck. Anything between VAXes works great, but when you want to reach the outside world you might have to wait a while. The messaging works okay, but file transfer is slow. Also, jnet doesn't multi-stream its links like IBM's RSCS does, so a single big file can tie up the link for a long time, not letting small files pass. There are two horrible things which *may* have been fixed (if the people at Joiner have any sense) but which caused us a lot of problems. The file queues that jnet keeps are FIFO (seems like they should be size scheduled to me). Also, jnet does not correctly translate incoming NETDATA format files (seems to do ok with outgoing ones, though). There's one other problem which may be unavoidable. You must run one daemon process for each link you wish to run, plus one for the machine itself. This can cause problems on one or two VAXes if you don't organized your subtree carefully. Glenn Vanderburg Texas A&M University P.S. One final note in case anybody from Joiner is listening. When you send a file using jnet, the send utility copies the file to a special queueing directory somewhere, doing any necessary translation to special formats, before returning a prompt to the user. Seems to me that it should just note the location of the file and come get it when it's ready to send. This is the way the print queues work; VAX users are used to it. This would make it easier on systems with limited disk space, and the translation could be done on jnet's time instead of the user's.