[comp.unix.ultrix] 3rd hsc on ultrix 3.1

gilad@il3cad.intel.com (Gilad Yaron) (03/07/90)

We currently have 4 vax8800 and 2 vax6310 running Ultrix3.1.
All the disks of these vaxes are connected thru 2 HSCs.

As the number of disks ports is limitted, we would like very much to
connect a third hsc (which we already have since the good 'ole VMS
days)

According to DEC documentation, only 2 hscs are supported under ultrix
(Yes, I did RTFM).

Is anybody out there using more than 2 hsc is ultrix environment?
-- 
--------------------------------------------------------------------
Gilad Yaron - Intel Design technology - Haifa  |  Never say I
Bitnet Adress: gilad@il5cad.intel.com          |  didn't warn you!
--------------------------------------------------------------------

grr@cbmvax.commodore.com (George Robbins) (03/07/90)

In article <12674@il3cad.intel.com> gilad@il3cad.intel.com (Gilad Yaron) writes:
> We currently have 4 vax8800 and 2 vax6310 running Ultrix3.1.
> All the disks of these vaxes are connected thru 2 HSCs.
> 
> As the number of disks ports is limitted, we would like very much to
> connect a third hsc (which we already have since the good 'ole VMS
> days)
> 
> According to DEC documentation, only 2 hscs are supported under ultrix
> (Yes, I did RTFM).

It's an interesting question, which only someone at DEC or with access to
appropriate sources can answer conclusively.

Most of the max # of devices issues are really "soft" limits based on the
number of devices configured into "BINARY.vax", the source of all the objects
for "binary" systems. 

The resulting number shows up in two places - first as sanity checks on the
maximum device number (checks on minor device number) and second as the
size of statically allocated tables.   The first item requires object patching
to circumvent, the second can be a real problem if the tables are contained
in the object modules, however many are actually in "c" from in the /sys/data
directory.

One expample where people have gotten burned is in the number of serial
interfaces.  Apparently there are enough buried tables with 10 entries that
trying to exceed the suported number of interfaces results in some entries
getting corrupted.

The case of the HSC's a bit non-obvious, since there don't seem to be any
visible data elements, BINARY.vax has only one HSC defined, there is no
obvious kernel error message for "too many HSC's" and so forth.

Since you have the metal lying about, probably the simplest thing is to plug
it in, tell one of the "less critical" systems it has 3 hsc's and see what
happens.  Obviously there is some risk associcated with such a course, but
unless someone from DEC is willing to step forth with the true facts or you
can get clarification from DEC, I don't see a whole lot of choice...

-- 
George Robbins - now working for,     uucp:   {uunet|pyramid|rutgers}!cbmvax!grr
but no way officially representing:   domain: grr@cbmvax.commodore.com
Commodore, Engineering Department     phone:  215-431-9349 (only by moonlite)

avolio@decuac.DEC.COM (Frederick M. Avolio) (03/08/90)

The support you are looking for is expected to be in the next release of 
ULTRIX.

Fred