🚀 go-pugleaf

In article <774@osiris.UUCP> eric@osiris.UUCP (Eric Bergan) writes:
>> >We would like to hear from other sites that have such a configuration [mainframe
>> >(of any sort) to Ethernet], preferable by means of an IO channel connection,
>> >since our application requires the bandwidth of an IO channel.
>> 
>> Yes, as far as I know, we were the first with TCP/IP on the Sperry.  We're
>> currently running a 40KB sync line to a fuzzball which has an ethernet on it.
>> It seem that we've got some users, and they have all this data you see.. and
>> they want to move it REAL fast.  So.  We are in the process of evaluating
>> the Sparticus (now Fibronics) and Auscom IBM-type-byte-channel ethernet
>> boards, and hope to have one here soon.  Well see how fast our purchasing
>> people can deal with this one.
>
>	We have an Auscom currently connected to our IBM systems, running
>XNS. I believe that our Auscom is a block channel, not a byte channel,
>interface, though. The XNS resides in the Auscom itself, and the
>virtual circuits look like a series of 327x terminals. This avoids the
>protocol load on the host. We have implemented Sun's RPC mechanism in
>the IBM, and our IBM is routinely making RPC calls from COBOL to our
>Pyramid over all of this. (The Pyramid does database lookups, and
>returns the information to the IBM.) We presented a paper on all of
>this at the last Uniforum, for those that are interested in more
>details.
>
>	We have also looked at the Sparticus equipment. At the time we
>were starting, Sparticus only supported VM, not MVS. I understand that
>this is currently changing. There is, however, still the issue that
>Sparticus runs TCP/IP in the host, and so you still have to pay for the
>mainframe cpu cycles to handle the protocol. We would be very
>interested in any Sparticus customers that could tell us how much of
>their cpu gets chewed up doing the TCP/IP protocols. I remember that
>the old UCLA code was estimated at chewing up about a third of a
>reasonable sized IBM mainframe, which is far more than we could put up
>with.
>
>-- 
>
>					eric
>					...!seismo!umcp-cs!aplcen!osiris!eric

I guess my terms were a bit incorrect.  When I said 'byte' channel I meant
an IBM style byte or block mux channel on the Sperry rather then the Sperry
36 bit wide "word" channel.

We've  been running TCP/IP on the host for quite a while, and found that it
doesn't present a high enough load to worry about off-loading the processing
to a front end.  For our application, we'd prefer not to have an overly
clever front end "helping" us, but rather a simple interface to an ethernet
that won't bend the existing code too far out of shape.

We'll see what happens; usage patterns are likely to change when the higher
bandwidth network connection arrives.  Who knows what these crazy users will
do next!

-- 
Louis A. Mamakos WA3YMH   University of Maryland, Computer Science Center
 Internet: louie@trantor.arpa
 UUCP: {seismo!umcp-cs, ihnp4!rlgvax}!cvl!umd5!louie