Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!watmath!clyde!burl!ulysses!allegra!princeton!orsvax1!pyrnj!caip!topaz!root From: root@topaz.RUTGERS.EDU (Charles Root) Newsgroups: net.lan Subject: Re: Ethernet connections for mainframes Message-ID: <4816@topaz.RUTGERS.EDU> Date: Wed, 23-Apr-86 04:44:34 EST Article-I.D.: topaz.4816 Posted: Wed Apr 23 04:44:34 1986 Date-Received: Thu, 24-Apr-86 07:06:21 EST References: <1104@uwmcsd1.UUCP> <169@brl-sem.ARPA> Organization: Rutgers Univ., New Brunswick, N.J. Lines: 30 We have a product from ACC which is an Ethernet interface for an IBM mainframe. It is a controller with several processors in it. One of them talks to an IBM channel. Another one talks to the Ethernet. Somewhere in all that hardware is a program that pretends to be an IMP. The idea is that the whole thing taken together looks exactly like an ACC 1822 interface (the hardware you would use to connect an IBM mainframe to the Arpanet). This allows us to use UCLA's TCP/IP implementation for MVS, since it supports IMP's. I kept putting off saying anything about this, in hopes that I would be able to write a more definitive article, with some performance figures and the like. Unfortunately, I have yet to be able to figure out our IBM system well enough to transfer files on it. I have been assured by people who know that our IBM users are using it all the time, and it works. So far I have been losing my battles with ACF2 (the MVS protection system). (This has nothing to do with the ACC box or the TCP software.) The design goal was to have a system that could do very high-speed transfers. It was intended to be an answer to those (including us) who were sceptical of the throughput of a DACU. Eventually I hope to be able to give you actual performance numbers. Actually, their design goals were such that we probably don't have any other systems fast enough to see what it really can do. One other thing: What they are really trying to do is to produce a network front end. The same box, with some slightly different cards, can talk to DDN. They think there is a market for people who would like to talk to both DDN and their own local Ethernet, using the same box. They are also talking about moving parts of the network code into the box, in the long run. I believe they are working with a consulting company that will help you install things and support the UCLA MVS code, though our systems staff seemed to have no trouble getting things up with the code as it comes from UCLA.