Sun-Spots-Request@Rice.edu (William LeFebvre) (09/07/88)
SUN-SPOTS DIGEST Tuesday, 6 September 1988 Volume 6 : Issue 218
Today's Topics:
Re: Non-Sun SCSI disks & Sun4/110 (2)
Re: SunOS 4.0 problem with .rhosts
Re: Ethernet Cards
Re: Symbolic Computing Environment for Lucid Lisp
Re: colormap segments
Re: old csh source? (tcsh for SunOS 3.5 csh?)
VME Ethernet cards (ideally) with SunOS Drivers
SL/IP is broken if used with ALM-2's
nfs-problems
The Reagents of the University of California
Send contributions to: sun-spots@rice.edu
Send subscription add/delete requests to: sun-spots-request@rice.edu
Bitnet readers can subscribe directly with the CMS command:
TELL LISTSERV AT RICE SUBSCRIBE SUNSPOTS My Full Name
Recent backissues are available via anonymous FTP from "titan.rice.edu".
For volume X, issue Y, "get sun-spots/vXnY". They are also accessible
through the archive server: mail the request "send sun-spots vXnY" to
"archive-server@rice.edu" or mail the word "help" to the same address
for more information.
----------------------------------------------------------------------
Date: Sun, 04 Sep 88 11:06:19 GMT
From: "Timothy H Panton." <mcvax!westhawk!thp@uunet.uu.net>
Subject: Re: Non-Sun SCSI disks & Sun4/110 (1)
Doug Roberts @ Los Alamos National Laboratory writes:
> Pin 26 on the SCSI connector may be grounded. _Do NOT use
> non-Sun SCSI disk drives with any Sun4/110 or any 4100 CPU based system.
I once borrowed a 3/60 from Sun (UK) and the SCSI connector on the cable
had one pin snipped off, I don't remember wich one, but it didn't look
accidental.
Does this mean the above caveat also applies to 3/60's?
Also, can one blow a _Sun_ drive by using a non Sun cable ?
Tim. (..!mcvax!ukc!cam-cl!westhawk!thp)
------------------------------
Date: Mon, 5 Sep 88 21:58:30 EDT
From: dan@wind.bellcore.com (Daniel Strick)
Subject: Re: Non-Sun SCSI disks & Sun4/110 (2)
Once upon a time, every other conductor in a single ended SCSI interface
cable was grounded, presumably to reduce crosstalk. If you look at the
standard unshielded SCSI connector pinout (two rows of pins, 0.1"
spacing), you will see that pin 25 (using the standard flat cable
conductor numbering convention) is on the grounded side of the connector
and is opposite pin 26 (terminator power, ~5v). People have several
sloppy habits, including plugging cables in backwards. Therefore modern
SCSI specs say that pin 25 should left unconnected and pin 26 should be
fused.
The obvious mistake that one might make in a SCSI interface is to ground
pin 25. If the "Read Me First" that comes with a sun-4/110 is to be
believed (pin 26 grounded), someone really botched it. Perhaps the "Read
Me first" is incorrect. I think someone from SMI should post an
explanation to Sun-Spots digest.
P.S. SCSI devices do not always supply terminator power to pin 26. The
feature is optional, usually selected by a jumper or a switch which leaves
pin 26 unconnected if the feature is not selected. If a SCSI device has
internal terminators, they are probably powered internally. SCSI host
adapters usually have internal terminators. SCSI systems may work ok even
if one end of the cable is not terminated or there is an extra set of
terminators on the cable. Many non-SMI SCSI devices would work ok on a
sun-4/110 even if pin 26 is grounded. Some would burn up.
------------------------------
Date: Sat, 3 Sep 88 23:15:35 EDT
From: John T. Nelson <jtn@potomac.ads.com>
Subject: Re: SunOS 4.0 problem with .rhosts
Reference: v6n118
Jim Nisbet <GG.JDN@forsythe.stanford.edu>:
> The effect is that when you try to 'rlogin' or 'rsh' to a SunOS 4.0
> computer you may get an immediate 'connection closed' (because
> login/in.rshd got the seg violation and exited).
Ooooh boy does THIS sound familiar! I have the same problem, however I
tried [[ the fix from bien@aerospace.aero.org ]] (changing the hosts.equiv
file) and it STILL doeosn't work. That's right... even when the official
host name of the machine is first in the hosts.equiv file, I still get
connection closed.
Here's the interesting part:
One of my machines is a 3.5 machine and the other is a 4.0 machine. I can
rsh and rlogin from the 4.0 machine into the 3.5 machine but NOT from the
3.5 machine to the 4.0 machine.
I suspect there is a more complex underlying bug in there than we suspect
(i.e. just changing the ordering of entries in a file).
SunOS is begining to remind me of Symbolics Genera 7.X. The switchover to
the new grand improved feature-filled (and SLOW) Genera 7.X was horrendous
for Symbolics users. I hope Sun is smart enough not repeat such a mistake
(but 4.0 doesn't give me much hope).
John T. Nelson UUCP: sun!sundc!potomac!jtn
Advanced Decision Systems Internet: jtn@potomac.ads.com
1500 Wilson Blvd #512; Arlington, VA 22209-2401 (703) 243-1611
------------------------------
Date: Sun, 4 Sep 88 10:50:59 pdt
From: Phil Klimbal <klimbal@riacs.edu>
Subject: Re: Ethernet Cards
>From: "Pawel Stefanski" <stefan@gmuvax2.gmu.edu>
>
>We ordered our second Ethernet card in the middle of April, with the
>promise of 30 days delivery. We are still waiting for it today. Is it a
>single case, or a symptom of something more common, caused by 'SUN rapid
>growth'?
We are having the same experience. We ordered a second Ethernet card in
early July; the promised ship date was August 12, the card still hasn't
arrived. Recent conversations with our Sun sales rep seem to indicate
that Sun is having a problem with its supplier. Anyone heard anything to
confirm this?
--Phil Klimbal
Research Associate
Research Institute for Advanced Computer Science
klimbal@riacs.edu, ..!{ames,rutgers,decwrl}!riacs!klimbal
------------------------------
Date: Sat, 3 Sep 88 19:49:50 MDT
From: roberts%studguppy@lanl.gov (Doug Roberts @ Los Alamos National Laboratory)
Subject: Re: Symbolic Computing Environment for Lucid Lisp
> I'm looking for info about the Symbolic Computing Environment for Lucid
> lisp that I believe Sun just came out with....
SPE is a step in the right direction for bringing some of the power of the
Symbolics' lisp development environment to the Sun. It has an improved
editor (but face it, nearly _anything_ would have been an improvement over
the Lucid sub-emacs editor :-( ). You now have a little bit more of a
mouse interface to the editor, and can do the equivalent of CTRL-Shift-A
to get the arguments of a function by mousing on a help item. (Note to the
developers of SPE: It would be nice to also be able to do the equivalent
of CTRL-Shift-D, get the function documentation string). There is a
scrollbar. You can mark & compile regions. There is much functionality
that I would still like to see added to the editor (I use GNU as an
example of a full-featured EMACS.)
Chief complaints about the editor:
1. You still can't save keyboard macro definitions to a file!!
2. The mouse interface is still sparse.
3. The documentation could stand fleshing out.
4. It's obviously immature.
I feel the most powerful feature of SPE is going to be the debugger,
especially when _it_ is little more mature. In SPE you now have a true
source level window-based debugger and an inspector that will allow you to
look at local variable bindings (finally! This has been a chief bitch of
mine regarding the crummy Lucid debugger.), arguments, or any object at
all, for that matter: arrays, lists, function definitions, etc.
There are a couple of other goodies that come with SPE: an application
planner and something else that I can't remember. Suffice it to say that I
haven't used them yet. One of the other folks in my group has used the
application planner & says that it's nice. He'll probably see this note &
follow up on it.
Time for a short tirade: Prior to SPE I estimated that it took ~3X (yes,
THREE TIMES!) longer to develop a large lisp application on the Sun as it
did on a Symbolics. This due to the powerful editor & debugging facilities
provided by the Symbolics' environment (and lack of same on the Sun, of
course). I feel that this discrepancy in productivity is diminishing now
that SPE is out.
The tirade: (unfortunately aimed at a large audience & probably only
meaningful to a small part of it, those of you who use KEE [Knowledge
Engineering Environment, a product of IntelliCorp, Mountain View,
California] on your Suns) -- SPE doesn't do _us_ any good, because most of
our lisp work is done from within the KEE package, and Intellicorp doesn't
seem to be in any hurry to provide its customers with a version of KEE
running on top of SPE! End of Tirade.
Hope this helps.
--Doug
Douglas Roberts
Los Alamos National Laboratory
(505)667-4569
dzzr@lanl.gov
------------------------------
Date: Mon, 5 Sep 88 13:54:44 CDT
From: thompson%umn-ai@umn-cs.cs.umn.edu (William B. Thompson)
Subject: Re: colormap segments
The Sun color frame buffer on our 3/110C allows text and images to coexist
by supporting separate 8 bit color and 1 bit mono frame buffers, along
with a 1 bit multiplex array to specify which frame buffer to use for
every pixel. If the mouse is in a window used to display an image which
requires a full 8-bit color map, all is well -- both the image and any
text windows look as they should. Move the mouse outside of the image
window, however, and SunOS loads a color map which causes the image to
disappear. This occurs even if no other windows are using the color map.
The disappearance of image windows is unavoidable with the traditional
8-bit frame buffers. The 3/110C maintains compatibility with these older
designs at the expense of significantly decreasing the utility of the
10-bit frame buffer. Perhaps Sun would consider some sort of switch to
enable a more sensible behavior?
William B. Thompson
University of Minnesota
------------------------------
Date: Mon, 5 Sep 88 14:40:19 +0200
From: Ephraim Silverberg <ephraim@TECHUNIX.BITNET>
Subject: Re: old csh source? (tcsh for SunOS 3.5 csh?)
Comments: Domain style address is "ephraim@techunix.technion.ac.il"
> From: Jeffrey A. Sullivan <idis!cisunx!jasst3@psuvax1.cs.psu.edu>
>
> Can anyone tell me where I can get a copy of the csh (4.3 or newer)
> sources so I can patch them to get tcsh?
> [ It's not public domain. It's part of Unix. You would probably need a
> Unix source license to legally obtain the sources. --wnl ]
Well, we do have a site-wide Unix licence for both 4.3 BSD and SunOS 3.5.
The problem is that patching the 4.3 BSD csh to get tcsh and trying to get
it to run on a Sun is not working (e.g. Control-C on a blank line causes
tcsh to die with 'exit 1'). Patch fails over 50% of the time if the 4.3
patches are applied to SunOS 3.5. Do SunOS 3.5 csh patches for tcsh
exist?
Ephraim
------------------------------
Date: 4 Sep 88 07:41:46 GMT
From: mo@uunet.uu.net (Mike O'Dell)
Subject: VME Ethernet cards (ideally) with SunOS Drivers
Does anyone have any recommendations regarding Ethernet cards to be used
with SUN 3 and 4 series computers? I have used SUN's expansion "ie" card,
but for various reasons don't want to use it in what I am doing (eg, I
need it to be a standard-size VME card). I don't really want a card with
a processor on it since the networking is in the kernel, and the only ones
I know of offhand are front-end processors. So if anyone out there knows
of a good, fast (ie, NOT the 80586 chip) VME Ethernet card, ideally with a
driver for SunOS 4.0, I'd love to hear about it.
-Mike O'Dell
uunet!mo
------------------------------
Date: 4 Sep 88 23:53:31 GMT
From: munnari!sirius.ua.oz.au!mrp@uunet.uu.net (Mark Prior)
Subject: SL/IP is broken if used with ALM-2's
Reply-To: munnari!sirius.ua.oz.au!simon@uunet.uu.net (Simon Hackett)
The story so far:
We have 9 or so Sun-4 servers and 50-60 Sun-3's here (I loose count).
On all but one Sun-4, we have ALM-2 multiport serial boards. Most of these
systems are distributed around the campus, and most of them are on
ethernet. However, that ethernet hasn't got to all the campus buildings
(yet).
We have multiple locations housing Sun-3's and PC's which we wish to
connect to the network via Serial Line IP (which I'll call SLIP from now
on). Sun "support" this with the addition of some patches, which come on
the PC-NFS 3.0 distribution disks.
With these patches applied to a Sun (e.g. one of our Sun-4's), one is
supposed to be able to network in Sun-3's and PC's via serial lines. Since
there is only one spare serial line on each Sun-4 cpu board (after the
console is plugged into the first port), we HAVE to use our ALM-2 boards
to link in the SL/IP connections, because we have more than one SL/IP line
in use. (2 currently, we'd have more like 2 dozen if this would work)
It actually does work initially, but a while after you start using the
network link the Sun-4 server crashes, saying 'panic: mget'. This is
un-tenable for machines we need to have running for long periods to
process compute- intensive jobs.
The local sun office says this is a known problem with SL/IP and ALM-2's,
where the SL/IP driver and the ALM-2's interrupt priority don't get along.
They also say this was fixable with ALM-1 serial boards, but can't be
fixed with ALM-2's. We are not very impressed by this, and we are not of
the opinion that "we can't fix it" is a good enough answer from a company
who says "the network is the computer". That trademark is becoming a sore
point around here. Without any O/S source code yet (another sore point),
we can't fix it ourselves.
The suggested workaround (don't use ALM-2's, use the CPU boards' second
serial port) doesn't help us much, when we want dozens of PC-NFS to Sun-4
connections, and probably several more Sun-3 to Sun-4 connects as well.
Surely this is a problem Sun can fix. Particularly if there are others in
the same situation who can help us put pressure on Sun to act.
So: Has anyone else got the same problem? Can anyone suggest another
solution?
regards,
Simon Hackett
P.S. I don't want to complain about this. I just want it to work. Funny,
that's what our users keep saying, too...
--
Mark Prior Phone : +61 8 228 5680
University Computing Services Telex : UNIVAD AA89141
University of Adelaide Fax : +61 8 224 0464
GPO Box 498 Adelaide S.AUSTRALIA 5001 ACSnet: mrp@sirius.ua.oz
------------------------------
Date: 3 Aug 88 09:28:49 GMT
From: mcvax!tugiig!plipp@uunet.uu.net (Lipp Peter)
Subject: nfs-problems
Looking for help! Wonder if anybody out there had a similar problem.
Here it is:
We have an Ethernet-work with three Apollos and several PC`s. We are
using TCP-IP, NFS and TELNET. Using the PCI of Apollo is unsuitable for
future use because the network will be expanded one day to an
university-wide one which will contain Vaxes, Suns and whatsoever. TCP-IP
(seemingly) and TELNET work properly, NFS not.
Problem 1: An (pure) Apollo-Problem: when booting, nfs does not always
start up properly. Usually all processes (mountd, portmap, nfsd) are up
and running, the PC-s seem to be partially able to communicate but
are not able to access anything. (General error on Drive .......).
If I kill nfsd and start it again manually - everything is fine!
I followed all the instructions and do not know what to do.
Apollo-staff here in Austria seems to be rather uninformed as are their
manuals (call this a manual.???) and uninterested (they want us to
use PCI but we do not).
Anybody some help available?
Problem 2: As Apollo stated: NFS is supported for use in an
heterogeneous network together with suns. If we had a sun, it would be
responsible for authentication. We have none. We have the PCNFSD-sources
which we are unable to translate because there are some .h-files and
rpc-routines missing. And I do not know how to access the passwords
which are not stored in /etc/passwd. How can I do authentication?
Fear, nobody else had this problem. But: any ideas how to authorise users
more than user.none.none.none.....???
Apreciate any responses - pleas use email!
Peter Lipp - plipp@tugiig.uucp
University of Technology Graz
Institute for Information Processing
Austria
[[ NFS network problems of this nature (when the hardware is more than
just Sun's and especially when PC's are involved) is probably more
appropriately discussed on the NFS list: "nfs@tmc.edu" (mail requests to
be added to "nfs-request@tmc.edu"). --wnl ]]
------------------------------
Date: Sun, 4 Sep 88 00:51:14 EDT
From: John T. Nelson <jtn@potomac.ads.com>
Subject: The Reagents of the University of California
Reference: v6n215
"The Reagents of the University of California"
Is this in all the BSD code too???!!!
------------------------------
End of SUN-Spots Digest
***********************