CEARLEY_K%UMS@VAXF.COLORADO.EDU ("Ke t Cearley ...UMS... 492-9262") (05/26/90)
Patrick from Interlink writes... > You are correct, there are products that emulate DEC VT220 terminals on > a 3278 terminal. Interlink does this by software on the host using a > CTERM protocol stream to the vax. Has anyone actually used this product? CTERM is a very inefficient protocol for terminal i/o, it transfers one byte per ethernet packet, for full-screen VT220 applications I suspect it would grind. LAT would be a better option. Does this product allow keyboard redefinition? *------------------------------------------------------------------* | Kent Cearley | CEARLEY_K@COLORADO.BITNET | | Management Systems | 'Reason is the bound or outward | | University of Colorado | circumference of Energy' | | Campus Box 50 | -W. Blake | | Boulder, CO 80309 | | | | | *------------------------------------------------------------------*
pjj@ntrlink.interlink.com (Patrick Johnston) (05/30/90)
In article <9005252035.AA09839@lilac.berkeley.edu> "Ke t Cearley ...UMS... 492-9262" <CEARLEY_K%UMS@VAXF.COLORADO.EDU> writes: >Patrick from Interlink writes... > >> You are correct, there are products that emulate DEC VT220 terminals on >> a 3278 terminal. Interlink does this by software on the host using a >> CTERM protocol stream to the vax. > >Has anyone actually used this product? CTERM is a very inefficient protocol for >terminal i/o, it transfers one byte per ethernet packet, for full-screen VT220 >applications I suspect it would grind. LAT would be a better option. >Does this product allow keyboard redefinition? I hope I am not belaboring this issue, but Kent is right, LAT is a much more efficient protocol for terminal access. CTERM is used for two reasons. CTERM is layered over DECnet and can therefore be routed. This is important to many of our customers because Interlink routes DECnet over SNA. If we used LAT this would not be possible. Reason number 2 is that when the product was built, it was not possible to license the LAT protocol. LAT was protected by DEC as a proprietary protocol. A few months ago, DEC started to license LAT for a fee and Interlink now has a LAT license. I will let users comment on the performance of the current product. Anyone with a marketing title should not be trusted to make those comments on the NET! It is possible to reconfigure the key definitions. We use "soft keys" to define each key. The users can easily change any key and save the definition off in file to be recalled later. Many files may be saved away and recalled even during a session. Because of the inherent differences between block and byte mode terminals, there are some things that are not exact. For a software product, it seems to work pretty good. (users??)
pjj@ntrlink.UUCP (Patrick Johnston) (05/30/90)
In article <9005252035.AA09839@lilac.berkeley.edu> "Ke t Cearley ...UMS... 492-9262" <CEARLEY_K%UMS@VAXF.COLORADO.EDU> writes: >Patrick from Interlink writes... > >> You are correct, there are products that emulate DEC VT220 terminals on >> a 3278 terminal. Interlink does this by software on the host using a >> CTERM protocol stream to the vax. > >Has anyone actually used this product? CTERM is a very inefficient protocol for >terminal i/o, it transfers one byte per ethernet packet, for full-screen VT220 >applications I suspect it would grind. LAT would be a better option. >Does this product allow keyboard redefinition? I hope I am not belaboring this issue, but Kent is right, LAT is a much more efficient protocol for terminal access. CTERM is used for two reasons. CTERM is layered over DECnet and can therefore be routed. This is important to many of our customers because Interlink routes DECnet over SNA. If we used LAT this would not be possible. Reason number 2 is that when the product was built, it was not possible to license the LAT protocol. LAT was protected by DEC as a proprietary protocol. A few months ago, DEC started to license LAT for a fee and Interlink now has a LAT license. I will let users comment on the performance of the current product. Anyone with a marketing title should not be trusted to make those comments on the NET! It is possible to reconfigure the key definitions. We use "soft keys" to define each key. The users can easily change any key and save the definition off in file to be recalled later. Many files may be saved away and recalled even during a session. Because of the inherent differences between block and byte mode terminals, there are some things that are not exact. For a software product, it seems to work pretty good. (users??)