C. David Young (DYOUNG@A.ISI.EDU)
10 Apr 1987 08:13:29 EDT
Since I got quite a number of responses to my query about how one goes
about interfacing an IBM to a PROnet and just as many requests for CC on
all information that I receive, I thought it would be worthwhile and
easier to just broadcast the information.
By far the most common configuration is that of using Wiscnet running
under VM and going through a DACU unibus interface with a corresponding
unibus interface to the PROnet. Nick Gimbrone took the time to give me
a thorough description of this setup and his message follows for those
interested. Unfortunately, our situation requires the speed of PROnet
80 (80 mbs) with an upgrade to FDDI (100 mbs) when it is available.
(Proteon has an upgrade policy that is quite reasonable.) However, from
what I know about the DACU, it is a relatively slow device (256 kbs?).
It just does not make much sense to us to use such a slow interface
on such a fast bus! I am about to give up trying to attach the IBM
directly to the PROnet and instead attach it to an Ethernet through
an ACS9310 from Advance Computer Communications. This device will work
at the full 10 mbs of the Ethernet and then we can go through an
Ethernet/PROnet gateway which should also operate at several mbs. ACC
also has TCP/IP for MVS in a package called ACCES/MVS.
Bob Dixon also indicated they were using two 4341s connected to a tcp/ip
Ethernet via Fibronics KNET hardware and software (and then gatewaying
onto the PROnet). I have not investigated this device yet.
Once again, thanks to everyone who sent input.
Received: FROM WISCVM.WISC.EDU BY USC-ISI.ARPA WITH TCP ; 9 Apr 87 18:55:46 EDT
Received: from CORNELLA.BITNET by wiscvm.wisc.edu on 04/09/87 at 17:55:31 CDT
Received: by CORNELLA (Mailer X1.23b) id 5100; Thu, 09 Apr 87 18:42:05 EDT
Date: Thu, 09 Apr 87 18:11:13 EDT
From: Nick Gimbrone <NJG%CORNELLA.BITNET@wiscvm.wisc.edu>
Subject: Re: tcp/ip/IBM/PROnet
cc: Mark Bodenstein <cc: Mark Bodenstein <MAB@CornellC>,
Mike Hojnowski <Mike Hojnowski <MQH@CornellC>,
Scott Brim <firstname.lastname@example.org>
>I was given your name by Selden Ball as a person who might know
>something about hooking an IBM 4381 to a Proteon Pronet. Could
>you tell me about your configuration, both hardware and software?
>We are interested in using TCP/IP on an IBM on a PROnet 80.
Any of the 4341/4381/308x/3090 series will work just the same. We use
Pronet 10 here, and I understand that there MAY be a minor
consideration with Pronet 80 and how the software picks up the card's
address (some timing difference between the two systems) which MAY not
be handled correctly (or may be done just fine) by the software (I'm
just not in a position to know yet). Also, we are a VM shop. I know
nothing about MVS (or at least will never admit to knowing anything
about it), so beware the VM slant in the following. Lastly, feel free
to come back with further questions or give me a call at (607)255-3748.
Now, on with the show:
We are using the Unibus Pronet10 cards to plug an IBM 7170 "DACU" into
the Pronet. The 7170 also plugs into an IBM channel (either on a 370
or XA mode machine). This 7170 has an IBM PC (don't know if it is
ordered separately or as a package from IBM) on top of it. The PC runs
some code from IBM (called DACU FUNCTIONAL CODE) which makes the 7170
look to the channel like a 3250 (thus you gen it to VM as a 3250 or
2250 graphics device). In addition this functional code calls some
'user exits' which in this case are supplied w/ the host TCP/IP
software. These exits will deal w/ the protocol that the host TCP/IP
software uses to pass info to the PC on what to send where, etc. It is
this software that MAY need to be upgraded for PRONET 80. The 7170 is
not currently FE supported, but for now a user supported box. Thus you
will need to deal with the details of getting it attached to the
channels, etc (unless you have a good relationship with FE). At this
point the hardware side is basically dealt with... off to software.
We are running the Wiscnet 1.3B package (1.3.1 is now available from
U.ofWisc, we just haven't upgraded yet). This software is not
installed nor maintained quite like any other normal VM software (if
you follow the instructions in the package). For all intents and
purposes one can also consider it to be equivalent to the IBM TCP/IP
package 5798-DRG. In the case of Wiscnet 1.3.1 you can pick up from a
server at UofMaryland ($WNTSRV at UMDD, see Bruce Crabill
<Bruce@UMDD.Bitnet> for more info) some 'common mods' and some service
utilities to make the system maintainable using a natural method for VM.
We have gone this route and it is in our opinion the best way to go.
In addition these common mods address several problem areas in the base
code, and thus are things you want on the base anyway (things like
subnetting support, etc).
Of course, the above host software is only available to Universities,
but from your address I assume that is not a problem.
When setting up the server machines that Wiscnet runs on be sure to
also set the CP Scheduler performance settings (set favor, set qdrop
off, set reserved, set priority, etc) needed to give good performance
to servers of this sort (similar to what one would do for a guest
intruder such as MVS or VTAM, etc under VM). This is critical to
You will want to be able to regularly update the public copies of the
HOSTS ADDRINFO and HOSTS SITEINFO files which are built from the
hosts.nic file you get from sri-nic.arpa (or where ever) to describe
all the host names on the network. This may be a problem if they are
on the Y-disk (or may not, depending upon your shop's policies). (Yes,
there is no Name Server or query'r support in Wiscnet, may be in some
future time IBM will release the stuff that UofW did but was not
allowed to release.)
I'm sure I've missed lots, perhaps the others copied will add to the
info and copy the rest of us (hint, hint). Also feel free to ask
questions (it will help us prepare for a talk we need to give soon on
this very question, so this would help us too).
This archive was generated by hypermail 2.0b3 on Thu Mar 09 2000 - 14:38:07 GMT