[comp.os.vms] DECServer and DECnet incompatibility??

MANAGER@SKIDMORE.BITNET (Leo Geoffrion) (12/21/87)

Some internal DEC documentation for the DECserver 500 suggest that it may
be incompatible with asynchronous DECnet.  In other words, if you intend
to use asynchronous DECnet to connect to micros with either DECnet DOS or
TSSnet (for the Mac's), then you cannot use a Terminal Server for your
communication port.

This is somewhat annoying since DEC is steering most buyers toward the
DECservers as the preferred mode for user i/o.  At the same time, we find
that asynchronous DECnet provides the nucleus for integrating micros and
Vaxen without expensive Ethernet boards on every micro.  (our 9600 Baud
PBX lines are fast enough for most small files).

Is it indeed impossible to connect asynchronous DECnet on top of LAT-11?
Has anyone seen a work-around for this?  I'd really hate to have to go back
to reinstalling our old DZ-11's.


===================================================================
Leo D. Geoffrion                  BITNET:  MANAGER@SKIDMORE.BITNET
Associate Director for             NYNEX:  (518) 584-5000 Ext. 2628
Academic Computing
Skidmore College
Saratoga Springs, NY  12866

WARNER..NAGY@FNALB.BITNET (Frank.J.Nagy@jade.Berkeley.EDU, (12/23/87)

Leo Geoffrion <MANAGER%SKIDMORE.BITNET@CUNYVM.CUNY.EDU> writes:

> Some internal DEC documentation for the DECserver 500 suggest that it may
> be incompatible with asynchronous DECnet.  In other words, if you intend
> to use asynchronous DECnet to connect to micros with either DECnet DOS or
> TSSnet (for the Mac's), then you cannot use a Terminal Server for your
> communication port.

> Is it indeed impossible to connect asynchronous DECnet on top of LAT-11?
> Has anyone seen a work-around for this?  I'd really hate to have to go back
> to reinstalling our old DZ-11's.

This might well be true.  However, you might want to look into another
Digital product, the DECRouter-200 (I think its -200 and not -100), this
is a box based upon the DECServer-200 (8 lines) which becomes a DECnet
router box on the Ethernet and provides up to 8 asynchronous DECnet
connections for PCs, etc.  In other words, this does exactly what you
want it too and, since the DECRouter is self-contained, does not impose
additional load on your host VAXes to handle the async DECnet connections.


= Frank J. Nagy   "VAX Guru & Wizard"
= Fermilab Research Division EED/Controls
= HEPNET: WARNER::NAGY (43198::NAGY) or FNAL::NAGY (43009::NAGY)
= BitNet: NAGY@FNAL
= USnail: Fermilab POB 500 MS/220 Batavia, IL 60510

tedcrane@batcomputer.tn.cornell.edu (Ted Crane) (12/24/87)

In article <8712222310.AA00987@ucbvax.Berkeley.EDU> MANAGER@SKIDMORE.BITNET (Leo Geoffrion) writes:
>Some internal DEC documentation for the DECserver 500 suggest that it may
>Is it indeed impossible to connect asynchronous DECnet on top of LAT-11?
>Has anyone seen a work-around for this?  I'd really hate to have to go back
>to reinstalling our old DZ-11's.

Bullseye.  As of the last time I tried this (DECnet via LAT), it didn't quite
work.  DEC documents it as not working.  Typically, DECnet will come up briefly,
then fail when you start using it in a non-trivial manner.  Sometimes i fails
without even being used.

I had quite a series of conversations with DEC folk about this limitation,
commenting on the dilemma between DEC's current steering of customers toward
LAT terminals, but not supporting async DECnet on them.  It is a big dilemma
when you take into account the proliferation of cheap, standalone VAXen
which can reasonably connect to the office network only by telephone line.

Unless someone submits an article to contradict your and my experience, why
don't we all continue pushing Dr. DEC on this issue.  It needs changing!

LEICHTER@VENUS.YCC.YALE.EDU ("Jerry Leichter ", LEICHTER-JERRY@CS.YALE.EDU) (12/28/87)

	Some internal DEC documentation for the DECserver 500 suggest that it
	may be incompatible with asynchronous DECnet.  In other words, if you
	intend to use asynchronous DECnet to connect to micros with either
	DECnet DOS or TSSnet (for the Mac's), then you cannot use a Terminal
	Server for your communication port.

	This is somewhat annoying since DEC is steering most buyers toward the
	DECservers as the preferred mode for user i/o.  At the same time, we
	find that asynchronous DECnet provides the nucleus for integrating
	micros and Vaxen without expensive Ethernet boards on every micro.
	(our 9600 Baud PBX lines are fast enough for most small files).

	Is it indeed impossible to connect asynchronous DECnet on top of
	LAT-11?  Has anyone seen a work-around for this?  I'd really hate to
	have to go back to reinstalling our old DZ-11's.

Running async DECnet over LAT sometimes works, and sometimes doesn't.  The
fundamental problem is that both levels are doing timeouts and retries, and
they can interfere destructively.  The result:  Sometimes it works, sometimes
it doesn't.  If you have a clean, relatively unloaded Ether, the links between
your micros and your DECServer are also clean, your hosts aren't very heavily
loaded, and your DECServer isn't very heavily loaded - basically, if the setup
makes clobbered packets, hence retries, extremely unlikely - you may get re-
sults you are happy with, or at least can live with.  It's tough to say for
sure, which is exactly why it's not supported.
							-- Jerry

tpmsph@ecsvax.UUCP (Thomas P. Morris) (12/29/87)

In article <8712250035.AA24175@jade.berkeley.edu>, WARNER..NAGY@FNALB.BITNET (Frank.J.Nagy@jade.Berkeley.EDU, writes:
>                                    you might want to look into another
> Digital product, the DECRouter-200 (I think its -200 and not -100), this
> is a box based upon the DECServer-200 (8 lines) which becomes a DECnet
> router box on the Ethernet and provides up to 8 asynchronous DECnet
> connections for PCs, etc.  In other words, this does exactly what you
                                                       ^^^^^^^^^^
> want it too and, since the DECRouter is self-contained, does not impose
 ^^^^^^^^^^^
> additional load on your host VAXes to handle the async DECnet connections.
> 

  It's not entirely clear that the DECrouter-200 does exactly what many sites
want to do: mix, on a dynamic basis, regular asynchronous terminal connections
with dynamic asynchronous DECnet (DDCMP protocol) connections, often from the
same terminal line connected to a PC. DECnet-DOS is great for _some_ uses,
such as wildcarded massive file transfers (where it easily outperforms, in both
transfer speed and VAX CPU efficiency, systems like Kermit, and XMODEM or 
HST/XFR), and even for multiple terminal sessions via SETHOST. 

	But the "responsiveness" of the SETHOST/CTERM terminal emulation in
DECnet-DOS leaves __much__ to be desired. (No flames, please: I fully under-
stand _why_ the lack of responsiveness occurs.) For that reason, among others,
it is very desirable to be able to alternate normal asynchronous connections
and dynamic asynchronous DECnet (DDCMP protocol) connections from a single line
attached to a PC. (Accomplished via PC/MS-DOS BAT files which rename the
autoexec and config files, after which a quick ctrl-alt-del reboot brings up
the PC in the desired configuration.)

	It is not clear, though, from the scant information I've seen in the 
Networks and Communications catalogs, whether a DECrouter-200 _can_ mix 
regular asynch and DDCMP connections! Anyone out there with one of these
beasts who knows?

Tom Morris
UNC School of Public Health
Division of Computing and Information Systems

tom@uncsphvx.bitnet  or tmorris@uncsphvx.bitnet or ...!mcnc!ecsvax!tpmsph

tpmsph@ecsvax.UUCP (Thomas P. Morris) (12/29/87)

	It appears that the reason why DECservers do not support asynchronous
DECnet connections, is that the LT-class terminal port driver used by LAT
prototocl connections does not support the SET TERM/PROTO=DDCMP/SWITCH
command. FOr the other terminal drivers used by hardwired terminal port inter-
faces, this command has the effect of "hooking" the DDCMP protocol driver
software into the communications chain "between" the hardware interface
and the VMS terminal driver communications handler. (This is a gross over-
simplification, but it catches the flavor of what occurs---the terminal line is
put into a passall-like mode, and the DDCMP driver handles packet assembly and
disassembly, and sequencing and verification according to the DDCMP protocol.)

	As Mr Nagy alluded to in a previous posting, dynamic asynchronous
DECnet (DDCMP protocol) connections _do_ "cost" in terms of overhead on the
DECnet host handling the connection. It costs in terms of CPU and interrupt
overhead. DECserver async (LAT protocol) connections are more efficient than
either DDCMP or normal TX or TT --style async (RS232/ASCII) connections. But 
the question still exists:

	WHY IS DDCMP NOT SUPPORTED ON DECSERVERS??!!

By setting terminals into passall or similarly transparent modes, other 
protocols such as Kermit or XMODEM or HST/XFR can be run on DECserver LT-class
terminal ports! Supporting DDCMP ought to be possible:

	1.) set the terminal-to-DECserver connection to passall or other
	  transparent mode, as used by Kermit, XMODEM, HST/XFR et al;

	2.) let the DECserver-to-LAThost connection continue to run normal
	  LAT protocol. (Use LAT as a transport service: this is just what
	  Kermit et al do.)

	3.) at the LAThost end of the connection, "connect" a DDCMP protocol
	  driver (protocol _only_: hardware driver not needed as LAT provides
	  the hardware equivalent of the packet transport service trans-
	  parently) BETWEEN the LAT character transport service and the QIO
	  interface.


Perhaps this has not been done because the LAT character transport service is
__too tightly integrated__ with the QIO interface? Yes, I _do_ recognize that
this method would "cost" almost as much LAThost overhead as the standard
asynchronous DDCMP terminal driver configuration. On the other hand, this would
provide equivalent capability to normal async software, without requiring 
additional hardware! After all, we didn't have to buy special "hardware" to
run DDCMP on our existing terminal cards; why should we have to buy DECrouters?


Tom Morris
UNC School of Public Health
Division of Computing and Information Systems

tom@uncsphvx.bitnet or tmorris@uncsphvx.bitnet or ...!mcnc!ecsvax!tpmsph