lkw@csun.edu (Larry Wake) (03/12/89)
(Before sending this, I got a chance to see the NeXT support camp notes,
which says rstat is "available but unsupported." But the question
still intrigues me, because of the symptoms given below.)
We just got our first NeXTs; previously, we've had Sun-3s and IBM RTs
running IBM/4.3. When I got the latest release of the RT operating
system, which now includes RPC support, I noticed that rstat(3) works
fine when dealing with other RTs, but breaks when querying or being
queried by Suns. A typical response when a Sun asks about an RT,
followed by the RT asking about itself:
solaria% rup dingo ; rsh tim rup dingo
dingo up 7006 days, 2:24, load average: 0.80, 1.88, 0.00
dingo up 3 days, 21:32, load average: 0.00, 0.00, 0.00
"Must be some kind of byte order problem," I muttered, and promised
myself to look into it someday. (Which I can, since we've got *source*
on the RTs...)
Now come the NeXTs, and lo and behold, they behave exactly like the
RTs! So much for my byte-order theory (which I had serious doubts
about anyway), since the cube and the Suns use the same family of
processors.
The final tally: Suns talk to Suns (of any flavor; no problem with our
386i's, for example), RTs and cubes talk to cubes and RTs, but a Sun
querying an RT or cube gets a bogus answer, and a cube or RT querying a
Sun complains that it "can't decode the result."
So, before I RTFS, has anyone solved this particular bit of strangeness,
or does anyone have a clue as to where the problem might lie?
--
Larry Wake lkw@csun.edu
CSUN Computer Center uucp: {hplabs,rdlvax}!csun!lkw
Northridge, CA 91330 BITnet: LKW@CALSTATE
"Oh, sorry; thought you said 'The Satanic NURSES.' Never mind." - R. Khomeini