Path: utzoo!mnetor!uunet!husc6!rutgers!mcnc!ecsvax!tpmsph
From: tpmsph@ecsvax.UUCP (Thomas P. Morris)
Newsgroups: comp.os.vms
Subject: Re: DECServer and DECnet incompatibility??
Message-ID: <4365@ecsvax.UUCP>
Date: 28 Dec 87 17:17:45 GMT
References: <8712250035.AA24175@jade.berkeley.edu>
Organization: UNC Educational Computing Service
Lines: 53
Summary: Why is DDCMP not supported on DECservers??!!


	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