Problem with wiring a networking device or devices

Here they are. This stuff hasn't changed in 15 years.

Ebay has a bunch of A-T styuff.

Most of the 10 Mb hubs that were common a few years back had several 10baseT connectors and one BNC connector. I've got one here. You may still be able to find one, either new or used.

Hello from the Eighth Doctor Does any company that any of you know of make a device to translate Coax/BNC connector based networking to 10BASE-T?

I have here a DEC Terminal Server model 90L+, it works, I can see it working on the screen of my host. I need to connect it to my LAN, which is a 10BASE-T based one. I have the AUIs that contain the same connectors, and have the DB15 connectors at one end, (Your right Rich I have cursed at those things, but never in your direction.). I also have the same AUIs from Cabletron, and it seems they might have all been made by AMP since the design matches the one the company has online. I also have the 10BASE-T to AUI connecter, from Synoptics. One of those is normally connected to my network for my VS 3100 Model 76.

However I don't have the beast I've described. I also have a hub made to connect four computers together via the same AUI described method. I'm thinking I can kludge together something around that hub, since its an active device, but the problem lies on the connector for the DEC TS, it has attached to one end of T connector a termination resistor. Someone from Digital Networks suggested that step.

And that's my problem.

Hello from the Eighth Doctor Nice. Expect that's there, and I'm here. I am based in the US, despite my "borrowing" of the Doctor's names.

That is the solution I need. Who makes the thing?

We would use one of our old hubs which has 8 (or 12) 10-base-T ports and an AUI port.

Simply slot a coax transceiver into the AUI port, and away you go.

Not sure if one can still buy such things, but we've got several festering on the shelf, as must many other folks whose networking goes back a decade or so.

search here for item/code LE1502-R3, see if it is what you want.

--reed

[..]

Well, we've got several, some from 3com and some from AT (Allied Telesyn), but they're ancient, I doubt that you could buy them now.

Try a google for the terms 10baseT and AUI, it brings several hits that appear to point to current products that you could buy.

How about this

8 Port Mini Network Hub w/ BNC & AUI $69.00

You'd need your coax transceiver too, of course, but maybe you already have one.

I'm dreaming. If your existing kit connects to a BNC then you can connect to this box's BNC connector (maybe with a T-piece and terminator).

Froogle "10baset bnc hub" and you'll get around 90 hits, starting at 4 bucks.

I have Asante hub that has 8 10baseT ports and a 10base2 coax port that I will give away for the cost of shipping.

Barry Streets

Hello from the Eighth Doctor I am based in NYC, Queens in fact. What's the shipping costs from where you are to approximately where I am? If you need my physical address feel free to contact me off list with details.

------ Gregg drwho8 atsign att dot net "This signature perspires!"

DECnet is a networking protocol, like IP, that can be transported on ethernet, among other layer 2 protocols.

As DEC was part of the original DIX (the D part) ethernet, it would seem likely that it was ethernet.

It seems that the 90L+ is LAT, the non-DECnet, non-IP protocol DEC used for terminal servers.

-- glen

I'll throw a wrench in the works, are you sure it's coax ethernet (thinnet,

10Base5). There was/is a thing called DEC-Net which looks like coax ethernet....But isn't.

DEC-Net is ethernet. DEC was the "D" in DIX, with Intel and Xerox as the originators of ethernet.

Actually, DECnet is a complete architectural suite, including protocols from Layer 1 up to Layer 8. Yes, that's right, I said Layer *EIGHT*. The DECnet Phase IV stack model included the following:

Layer 1--Physical Link Layer: Essentially the same as the OSI Physical Layer

Layer 2--Data Link Layer: Essentially the same as the OSI Data Link Layer. Supported technologies included Ethernet, X.25, and DDCMP, DEC's proprietary Digital Data Communications Message Protocol.

Layer 3--Routing Layer: Essentially the same functionality as the OSI Network Layer. However, I consider the term "Routing Layer" to be more properly descriptive of the primary function performed, i.e., routing packets across the internetwork.

We *consciously* chose NOT to call this layer the "Network" layer for historical reasons. In DECnet Phase III, Layer 3 was called the

*Transport* Layer (although it performed internetwork routing, the same as any Layer 3 protocol), and Layer 4 was called the *Network* Layer, although it did the end-to-end communications functions of a typical Layer 4. That is, DECnet Phase III reversed the terminology of Layers 3 and 4 relative to OSI. This was not an "error"; DECnet Phase III predated the OSI model, so we were not bound by any widespread understanding of the meaning of given terms.

Trust me, this caused no end of confusion during the late '70s and early '80s, as us "old timers" at DEC used "Network" to mean end-to-end, and "Transport" to mean internetwork routing. So that we didn't have to totally flip the terms and stand on our heads, in Phase IV we went to "neutral" terms for these two layers, avoiding either "Network" or "Transport" for either of them. When Phase V came around, DEC had fully migrated to the OSI model, and used the now-standard terms.

Layer 4--End Communication Layer: As I said above, this is the same functionality as the OSI transport, but with a "neutral" name (relative to DECnet Phase III). Actually, as with "Routing Layer" for Layer 3, I think "End Communication" is more descriptive of the functions performed, but the terms never caught on outside of DEC.

Layer 5--Session Control Layer: Essentially the same as the OSI Session Layer.

Layer 6--Network Application Layer: Essentially the same as the OSI Application Layer. The most common modules included file transfer and access (a la FTP), and remote virtual terminal (a la Telnet).

Layer 7--Network Management Layer: This does not exist in the OSI model as a "layer" in the stack. In OSI, network management is "on the side", i.e., it has insight into every layer through a private network management interface. In DECnet, network management was viewed as a functional layer in the stack.

Also note that DECnet did not have any Presentation Layer. To the extent that there are no incompatibilities among data-storage formats among machines, there is no need for this function. Since all of the machines in a DECnet were DEC machines, running DEC software (at least in the beginning), there was little need for canonical data formatting. To the extent that DECnet users needed to access files on non-DEC machines (e.g., through the DECnet-SNA gateway), the format conversion was done in the gateway application, at the Network Application Layer (Layer 6 in DECnet).

Layer 8--User Layer: DECnet models user applications communicating across the network as residing within a network layer. OSI considers these to be "outside" the network. This is more of a semantic issue than anything else, although it is clearer in DECnet that user programs do NOT reside in the "Application Layer."

I know many people who (wrongly) think that the OSI Application Layer contains end-user applications. Architecturally, it does not; entities within the OSI Application Layer are application *interface* routines, e.g. X.400 e-mail messaging. Placing end-user applications in a separate layer makes this abundantly clear.

Actually, LAT is a terminal service application (OSI Layer 7) protocol that runs directly over Ethernet. It is *NOT PART OF DECnet*; it and uses NO DECnet functionality, other than possibly sharing an Ethernet controller with the DECnet stack. The fact that LAT does not include any internetwork capability is what makes it "unroutable".

Note that there is *nothing wrong* (architecturally) with having an application interface directly with Layer 2; there is no requirement to use all of the functionality in a given stack. This is a tradeoff; by omitting functionality one loses certain capabilities (e.g., the ability to communicate across an internetwork). In return, you might get better performance in the target environment.

In reality, LAT was never intended to be what it came out to be. In the early '80s, we were working on a number of new products and ideas. One of them was a low-cost terminal server that could be implemented with relatively little processing power and memory; DECnet required a lot of both. As an *experiment*, one of the software guys cobbled together a miniature terminal access program in his basement over the weekend (literally), so that we could play with the equipment and see how things worked. In order to get it up quickly (no pun intended), he wrote the code to operate directly over the Ethernet controller interface, and avoided the entire DECnet protocol stack.

Unfortunately (as discussed below), the performance was vastly better than the DECnet VTP (Virtual Terminal Program, a.k.a. the "Set Host" command on VMS). IIRC, we were able to support 64 simultaneous terminal sessions on a terminal server using a single 6 MHz 68000 (what became the DECserver 100). At the host (VAX) end, terminal performance was better going through LAT than it was going through a DZ-11.

For you under-50 or non-DEC types, a DZ-11 was the standard RS-232 terminal interface, used for direct connection of terminals to a VAX mainframe, similar to the serial port on a modern machine. That is, we were getting better terminal response by going through the *network* than if we were directly connected to the mainframe! This was primarily because the DZ-11 (like most serial ports) generated a host interrupt for each character typed; LAT generated a host interrupt for each packet received, which could contain many keystrokes from many different, simultaneous terminal sessions. LAT gathers up all keystrokes from all ports on the terminal server over a period of 20 ms or so, and sends them off in a single packet to the target host.

The product marketing folks got so worked up about this "screaming" terminal server that they made us convert this "cobbled basement prototype" into a commercial product; the end result was LAT--a very fast terminal server protocol that was limited to a single Layer 2 entity. In part, it was the success of LAT that pushed DEC to develop and push bridging technology, since a bridge allowed multiple physical Ethernet to act as a single logical LAN, extended the reach of LAT terminal services.

Sorry for the long post, but: (1) I thought it might be enlightening, (2) I have lots of time now that school is out, and (3) It was fun (for me) to recollect some of this stuff. The one thing I'm trying to remember (but can't, for the moment) is the name of the guy who wrote the LAT code over the weekend. It will come to me.

-- 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

Lets clarify that a bit.. As I understand it, ethernet was developed at Xerox PARC, and was in use there, and a few other locations for a few years before it was marketed as a commercial product. The original ethernet ran at 3mb/sec, and was designed originally to support the Xerox Alto and Star.

Dec/Intel/Xerox cooperated to market an improved ethernet as a commercial product, giving us the 10mb/sec ethernet that we know today.

3Com was also founded around this time by one of the original inventors of ethernet, following his departure from Xerox PARC.

There's a good book called "Dealers of Lightning" that details a lot of what went on at Xerox PARC during the early years when ethernet was invented, along with the Alto, the laser printer, and the graphical user interface.

Hi, as someone who grew up with these protocols :-) here're my 2c

glen herrmannsfeldt schrieb:

Yes, DECNET Phase IV is a L3-protocol, just like IPX, IP or Appletalk. It is a routable protocol and the predecessor of DECNET phase V, which is the first and only true ISO/OSI-implementation (AFAIK)

Well, this protocol DOES run on ethernet and fddi, but is, in theory, not limited to that. DECNET uses the feature of "locally administered MAC-addresses", usually in the range AA:.. So, every L2-system capable of a) hardware-addressing and b) broadcasting could run decnet.

LAT is just another L3 protcol, but this time not routable (just as NETBEUI). It is used for terminalservices only and relies on a broadcast mechanism for announcing the "services. I've not seen any other implementation. Again, LAT relies on the same L2-protocols as decnet since they are related.

Mathias

Yep, I remember them, along with (IIRC) the DV-11 and also the Data General ALM - 8 & ALM-16. Incidentally, I used to work on a Collins system, which had a lan that predates ethernet by several years. It used a TDM loop, instead of packets. This system was used to front end a Univac system, for Air Canada and it also used several PDP 11 systems, containing a few cards built with a Motorola 6800 and 8 UARTs, to handle the world wide agent's terminal traffic for Air Canada.

I believe it was 2.94 Mb. Incidentally, 3 millibit/sec would be a tad slow. ;-)