Problem with wiring a networking device or devices

Never mind. I'd love to read more of this historical stuff.

Jens

Reply to
Jens Link
Loading thread data ...

I stand corrected.. :-)

Reply to
Bob Vaughan

(snip)

Somewhere I heard a story that the OSI seven layers were a compromise between six and eight proposed by two sides. Is this the eight?

(I heard that about the same time as the story of ATM's 48 bytes being a compromise between 32 and 64.) (Though I would have said it should be the geometric mean instead.)

(snip)

Well, maybe part of DECnet in the sense that it isn't TCP/IP, and a networked VAX without TCP/IP won't talk to a TCP/IP terminal server.

As I remember, (along with a discussion in another group) DECnet was very expensive. If LAT was licensed separately, that would make it useful even for non-networked machines.

(snip)

(snip)

I think I remember this when the 8xxx series VAX came out. They didn't have serial ports, but had to be connected through such terminal servers. The place I was at then had Gandalf for connecting terminals to different machines, so it was then two levels to get to the machine. It was explained that this was faster than serial ports on the machine, which seemed strange. Well, much DEC software expects character by character response (consider TECO, or even EDT).

Otherwise, IBM mainframe systems generally interrupt once per line, for normal terminals, or even once per page for 3270's. You can't write editors that depend on character I/O.

-- glen

Reply to
glen herrmannsfeldt

Well, I would round to 45.

Some years ago I was on jury duty for a civil case. Using a very complicated system the jury came up with an amount for damages.

After the case one of the lawyers told us the last settlement amounts that the two sides had come up with. The jury amount was pretty close to the geometric mean of the two.

Say, for example, the numbers were 10000 and 100 bytes. Which makes a more fair compromise, 1000 or 5050? 5050 is about half the first value and over 50 times the second, not so fair if you ask me.

(Remember, Moore's law is exponential.)

-- glen

Reply to
glen herrmannsfeldt

45.254834 bytes??? ;-)
Reply to
James Knott

Hello from the Eighth Doctor Quite. It is indeed DECNet. However their hardware does do normal Ethernet. However, I participate in a forum who discusses the implementation of the LAT protocol over Linux, called appropriately enough Linux-DECnet,

formatting link

Reply to
The Eighth Doctor

No, LAT is "not DECnet" in the sense that it has nothing to do with the DECnet protocol stack. It does not use any of the DECnet protocols, from Layer 3 on up. The LAT entity interfaced directly with the Ethernet controller/device driver (downward), and with the operating system terminal driver (upward).

While it is true that "a networked VAX without TCP/IP won't talk to a TCP/IP terminal server," this is irrelevant. A networked VAX without LAT won't talk to a LAT terminal server, either. They are completely independent. By the way, during the 1980s, LAT was a much more popular terminal server protocol than anything running on TCP/IP. (In addition, DECnet was more popular than TCP/IP, until the very late 1980s.)

Also (unlike DECnet) LAT did not require that the Ethernet MAC address be reconfigured to conform to the DECnet Routing Layer conventions.

I don't see how LAT could be useful on a non-networked machine; LAT operates only over an Ethernet network. At one point, LAT was the *only* DEC-supported means to connect terminals to VAXen; by the late 1980s they had dropped support for any directly-connected terminals. LAT was bundled with the core operating system, and did not require any separate license.

(DECnet was also bundled with the core O/S, however you have to purchase a cryptographic "key" to unlock the functionality. You are correct that, depending on the system configuration, this "key" could be expensive.)

Well, clearly you can, as most editors do rely on keystroke-by-keystroke interpretation. Take vi for instance; the fact that it interprets each keystroke in the context of each prior keystroke (e.g., an ESC shifts you out of input-mode for the next character) is a primary reason why Telnet sends one character-per-packet, and the visual "echo" of the keystroke on the screen must come from the remote host.

-- Rich Seifert Networks and Communications Consulting 21885 Bear Creek Way (408) 395-5700 Los Gatos, CA 95033 (408) 228-0803 FAX

Send replies to: usenet at richseifert dot com

Reply to
Rich Seifert

(snip)

Not networked, as in not connected to any other hosts, machines that actually do useful computing work.

With hardware that only interrupts the host on carriage return you can't write vi or teco.

3270 based editors have the user modify the screen and then send the changes to the host as one I/O operation. I believe telnet has a line mode to allow it to work with such hosts.

-- glen

Reply to
glen herrmannsfeldt

Great to hear the history of such things.

Reply to
Alan J. McFarlane

Cabling-Design.com Forums website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.