Broken software using ULTRIX 1.2

[rad at mitre-bedford.arpa]

     Jeff Parke (...!phred!jeffp) writes:
>We recently "upgraded" a vax750 to ULTRIX 1.2.  Suddenly the following don't
>work anymore:
>
>finger (core dumps occasionally)
>sps
>top
>uw (windows program)
>sccs (admin command bombs)
>
>Has anyone else seen this?  Has anyone figured out how to fix?  Or is there
>something wrong with our installation of ULTRIX?

     I think someone has commented on every one of the programs that
jeff has asked about except uw, the mac-unix windows program.  We've
got ultrix1.2 here, too, and I ran into problems with uw also.  I don't
have an elegant fix, but I have a kludge to help make uw "work".

     uw calls getdtablesize to find out how many file descriptors are
available.  On ultrix 1.2, this returns a value of "64", which is the
value of NOFILE in /sys/h/param.h.  (Increasing the number of available
file descriptors can generally be construed as "good", or as a
"feature".)  You'll note that 64 is a nice large number (larger than
the long-time Unix standard of 20), but it's too many bits to fit into
a VAX integer.  select(2) assumes that you're going to pass a pointer
to an int that's serving as a bit mask, where the i'th bit being set
signifies something about file descriptor #i.  Something has to give;
probably select's argument types have to change.  The select routine is
where uw bombs out.

     If someone can come up with an elegant solution to the problem
that results from pushing the maximum number of file descriptors past
32, I'd be interested in seeing it.  In the meantime, jeff can get by
by substituting:

	nfds = 32;
for the line
	nfds = getdtablesize();
in uw.c of John Bruner's wonderful uw program.

Dick Dramstad
rad at mitre-bedford.arpa