🚀 go-pugleaf

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.