Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watnot!watmath!clyde!rutgers!mit-eddie!genrad!decvax!ucbvax!TAMVM1.BITNET!X230GV
From: X230GV@TAMVM1.BITNET.UUCP
Newsgroups: mod.computers.vax
Subject: Re: DEC-IBM Connections
Message-ID: <8702251923.AA05291@ucbvax.Berkeley.EDU>
Date: Wed, 25-Feb-87 12:12:35 EST
Article-I.D.: ucbvax.8702251923.AA05291
Posted: Wed Feb 25 12:12:35 1987
Date-Received: Fri, 27-Feb-87 22:22:03 EST
Sender: daemon@ucbvax.BERKELEY.EDU
Distribution: world
Organization: The ARPA Internet
Lines: 48
Approved: info-vax@sri-kl.arpa

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.