Sun-Spots Digest, v6n100

William LeFebvre Sun-Spots-Request at RICE.EDU
Thu Jun 2 14:05:51 AEST 1988


SUN-SPOTS DIGEST          Wednesday, 1 June 1988      Volume 6 : Issue 100

Today's Topics:
                In celebration of this year's 100th issue
                    Re: Suns lose track of console (3)
                     Re: Problem with multiple groups
                             Re: Csh bug (2)
                              silo overflow
                  Phillips Monitors and Sun Workstations
                     Phillips Monitors-JUST SAY NO!!
                           if( vs. if ( in CSH
                      persistent clock drift problem
                             68881 on a 3/50?
                        68020 upgrades for sun2s?

Send contributions to:  sun-spots at rice.edu
Send subscription add/delete requests to:  sun-spots-request at 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 at rice.edu" or mail the word "help" to the same address
for more information.

----------------------------------------------------------------------

Date:    Wed,  1 Jun 88 14:57:14 CDT
From:    William LeFebvre <phil at Rice.edu>
Subject: In celebration of this year's 100th issue

If someone had told me late last year that I would produce well over 100
issues of the Sun-Spots digest in 1988, I would have either (1) laughed in
their face or (2) politely declined the job.  I am absolutely amazed that
the readership has produced so much input to this forum.  We aren't even
half way through the year and we are already reading issue number 100.  I
must say that this digest has proven to be more work than I anticipated,
but at the same time I am very pleased with what I am seeing.  I think
that the quality of messages is still high overall, and that the exchange
of information brought about by Sun-Spots is phenomenal.  With just a
little bit of pride I'll step out on a limb and say that I think this list
has one of the highest signal to noise ratios of any newsgroup or mailing
list, especially considering its volume.

I want to take the time to thank everyone who has sent me words of
encouragement.  It means quite a bit to me to know that there are people
who appreciate my efforts and are happy with what they see.  I am also
thankful that everyone has been so patient with me while I struggle to get
rid of the backlog of messages and while Rice copes with its networking
problems.  Finally, I want to say that this list would not be nearly as
successful as it is without the readers who take time to contribute good
messages, whether they are bug reports, answers to simple or difficult
questions, parts of a discussion, programs, or even icons.  A big thank
you to everyone who has contributed to this forum.  Without all of you, we
would have nothing to read!

Now I get to find out how much of my homebrew digestification software
breaks with three digit issue numbers!

			William LeFebvre
			Department of Computer Science
			Rice University
			<phil at Rice.edu>

------------------------------

Date:    Mon, 23 May 88 15:29:45 mdt
From:    era at scdpyr.ucar.edu (Ed Arnold)
Subject: Re: Suns lose track of the console (1)

We've noticed the same thing under 3.3, so it's not a bug peculiar to 3.5.
We also have a Wyse terminal as a console, attached to a 3/280.  The
problem is *not* in the terminal; the console interface locks up.  It's
not a simple matter of someone having typed ctl-s on the console.

------------------------------

Date:    Mon, 23 May 88 10:24:36 EDT
From:    mcb%jones at research.att.com
Subject: Re: Suns lose track of console (2)

My servers (OS3.2) also occasionally have console lock-up, which in this
case is caused by a hung `getty' process.  It is cured by logging in as
root from another machine and doing:
	ps aux | grep getty
to find a line like
	root 123 ...	-2 (getty)
and `kill -9' it.  These sometimes appear shortly after reboot, to judge
from the process numbers.  BTW, this is no permanent cure.  After a day or
so, it often hangs again.

No great solution, but it avoids a reboot.  If someone happens to know the
cause &/or cure for this problem with tty consoles, please post.

Mark Beutnagel
AT&T Bell Labs
mcb at research.att.com

------------------------------

Date:    Wed, 25 May 88 20:42:40 EDT
From:    Stephen J. Roznowski <sjr at mimsy.umd.edu>
Subject: Re: Suns lose track of console (3)

I had this same problem.  The fix was to remove all the devices associated
with the display hardware. [Since they are not being used.]

Remove /dev/mouse /dev/kbd /dev/fb on the server.  Since I have removed
them I have not had any problems [In over a month]

The reasoning I was given (which I don't really believe) was that a user
logging into the server and trying to start up suntools would confuse the
server as to where the console is.

Stephen

P.S. I'm assuming that your console is attached either to ttya or ttyb.

------------------------------

Date:    Mon, 23 May 88 17:01:53 EDT
From:    libes at cme-durer.arpa (Don Libes)
Subject: Re: Problem with multiple groups

Summary: User logs in on yp server and is in 4 groups, but only 2
groups on client.

What's going on is that the client is getting the yp group data, but its
wrong.  For example, if a line is missing a colon, all the groups after
that are ignored.  What is confusing is that yp reorders the data, so that
you have to look for the error between the last group you make it into and
the first group you don't in "ypcat group", not "cat /etc/group".

Don Libes          cme-durer.arpa      ...!uunet!cme-durer!libes

------------------------------

Date:    23 May 88 15:41:47 PDT (Mon)
From:    mills%tessi at tektronix.tek.com
Subject: Re: Csh bug (1)

>psune% echo !#:h
>Segmentation fault (core dumped)

That bug was in the early releases of SUN's csh in 1983/84.  I assume it
was the classic dereferenced NULL pointer bug you see porting from
VAX-based Berkeley Unix.  I may even have reported it to SUN.  I thought
it had been fixed sometime between then and now.  Has it been with us all
along?

-- Charlie Mills
   Test Systems Strategies, Inc.
   ...!ucbvax!tektronix!tessi!mills

[[ I just checked and it still exists under version 3.2 and 3.5.  Note
that the "echo" is not necessary, only the argument "!#:h".  It's a great
way to log off (provided you have set "limit core 0")!  --wnl ]]

------------------------------

Date:    Tue, 24 May 88 09:53:07 N
From:    Sven-Ove Westberg <sow at cad.luth.se>
Subject: Re: Csh bug (2)

A typical nil pointer!! The monster is still lurking around :-) (sigh)
By the way, is the nil pointer in "sed -e" still alive??

This is the fix. Check for nil pointer in any() in sh.misc.c.

any(c, s)
	register int c;
	register char *s;
{

	if(!s) return(0); 	/*  Check for nil pointer */
	while (*s)
		if (*s++ == c)
			return(1);
	return(0);
}

------------------------------

Date:    Mon, 23 May 88 19:12:47 EDT
From:    smb at research.att.com
Subject: silo overflow

When a character arrives on a serial port (or any sort of port, actually,
but the message usually refers to a serial port), it's put in the top of
the ``input silo'', and an interrupt is generated.  When the CPU fields
the interrupt, it pulls the character out of the bottom of the silo.  In
the mean-time, though, more characters may have arrived; they're put in
the top also, and the CPU can retrieve them all at the expense of one
interrupt.  Another way to look at the silo is that it's simply a
multi-character buffer, though just how large depends on the
implementation.

Silo overflow occurs when characters are arriving faster than the CPU can
field them.  It may be a genuine problem (if, say, you've got a rackful of
Trailblazers all talking at 19.2Kb/sec at the same time); more often,
though, it's a symptom of something else -- the CPU is too busy fielding
higher-priority interrupts during a burst of heavy input.  I've often seen
silo overflows during panics, when the kernel is syncing the disks with
interrupts masked; the silo overflow messages are gratuitous, and should
be ignored.

Do not confuse this condition with a user process running too slowly; the
characters are pulled out of the silo immediately, and either queued for
the process or discarded if the input queue is too long.

------------------------------

Date:    Mon, 23 May 88 23:04:16 EDT
From:    hull at cs.buffalo.edu (Jon Hull)
Subject: Phillips Monitors and Sun Workstations

We are upgrading a Sun-3/260M to a Sun-3/260G by adding a Sun CG3 color
board as well as a Phillips 2064M monitor.

Before going with this monitor, I was wondering if anyone has experience
with it or with other Phillips monitors when used as grey scale
workstation monitors.

How well can you discern differences in grey level?  Is the resolution
adequate for good text display?

Any other comments you might have about this or other Phillips monitors
would be greatly appreciated.

Thanks in advance,
Jon Hull
hull at cs.buffalo.edu
..!{ames,boulder,decvax,rutgers}!sunybcs!hull

------------------------------

Date:    Tue, 24 May 88 08:23:10 PDT
From:    Steve Blair <spar!ascway!scb at decwrl.dec.com>
Subject: Phillips Monitors-JUST SAY NO!!

You may be surprised to find this out, but a fellow I work with has found
a way to rid himself(and his group) of those @#$% Phillips Monitors that
Sun so thoughtfully sells. We were on our 3/rd failure of the usual
Phillips on the same machine. Expense of repair was driving this guy nuts.
Since Sun has now decided that WE THE CUSTOMERS SHOULD PAY MORE FOR BAD
CHOICES IN MONITORS
           (i,e,: 30 day color repairs now=$1600.00, monochrome=$1100.00).
	   (old cost"		     " was=$800.00, monochrome=$600.00)

I find it very hard to swallow that Sun is passing this additional cost of
poor monitors onto the customers. I have told my local Sun representative
that I was unwilling to get "ripped-off"(exact quote from conversation)
for monitors that I didn't pick. Why, oh why Sun did you double the prices
INSTEAD of getting NEW MONITOR Suppliers??

Oh, well, here's some sources of new monochrome and color monitors:
**(They are 100% SUN compatable(and the users have not had ANY COMPLAINTS)***

Moniterm
--------
P/N vy1962 19" Monochrome monitor	cost=$1525.00

Sony Trinitron(16")
-------------------
P/N gdm-1604-15	Color Monitor		cost=$~2200.00

In each of these cases, I know that they cost a little more than sending the
@#$% things back to Sun for repair. But please read a little further, there's
some good reasons here:

Moniterm Monitor is ECL/TTL. It has a jumper inside that changes the
interface.  This means that you can use it on Sun 3/50's & 3/160's. It has
a 1yr. warranty vs. Sun's 90day warranty. It will pay for itself the
second(and perhaps 1/st) time that you have to send one back to Sun. I got
mine 4 days after ordering.  I can now use the parts from the
Phillips(groan) to repair the other Phillips until I get rid of them. You
also get the luck of it being field repairable and parts are common for
it.

Sony Trinitron(16") is an INCREDIBLY sharp picture reminiscant of Sony's
usual quality. If one measures screen real estate of the presentation
surface, you'll discover what I did: The Sony's presentation surface is
only 3/4" less than that of the 19" Hitachi/Ikegami that Sun sells. My
user who has one has said the Sony will only leave when I pry his mutated
dead fingers off of his mouse.  Sure, it costs a little more, but what
with the track record that Sony has in the world, cone can expect that the
thing will be more reliable.

I can get the Moniterm from almost any vendor. Sun uses these also. If you
have access to a GOLD BOOK, they're in it.  I can get the Sony from my
local Electronics stores. I know not where from Sun is getting them.

In either case, I highly urge other Sun administrators and users to
consider these sources. It can be a good budget win for YOU the user!!!!!

Steve Blair
Schlumberger Technology Corporation
Austin, Texas
uucp: {backbone}!decwrl!spar!ascway!scb

DISCLAIMER: The info given is from my research and doesn't reflect any policy
	    OR opinions of Schlumberger or associated companies!

------------------------------

Date:    Tue, 24 May 88 10:08:18 EDT
From:    csrobe at icase.arpa (Charles S. Roberson)
Subject: if( vs. if ( in CSH

Can someone please explain why the addition of a space (' ') between the
"if" and the '(' in line 7 below causes the script to take two different
execution paths?  

[41] work18: > cat csh1		[43] work18: > cat csh2
#!/bin/csh                      #!/bin/csh

echo start                      echo start
if(0) then                      if(0) then
    echo 1                          echo 1

    if (0) then                     if(0) then		# line 7
        echo 2                          echo 2
    endif                           endif

    echo 3                          echo 3
else                            else
    echo 4                          echo 4
endif                           endif

echo end                        echo end

[42] work18: > csh1             [44] work18: > csh2
start                           start
4                               3
end                             end

It might be easier for me to understand if the space only affected the
second "if" statement but it affects the flow of the first as well!

thanks,
-c

Chip Roberson                ARPANET:  csrobe at icase.arpa
1105 London Company Way      BITNET:   $csrobe at wmmvs.bitnet
Williamsburg, VA 23185       UUCP:     ...!uunet!pyrdc!gmu90x!wmcs!csrobe

[[ This is a long-standing csh problem.  The command line "parser" was
pretty much thrown together and it causes quite a few little
inconsistencies like this.  In general it is a good idea to always put
spaces around keywords in a cshell script.  If you want more fun, check
out the difference between "set foo=a", "set foo= a" and "set foo =a".
--wnl ]]

------------------------------

Date:    Tue, 24 May 88 00:00:43 PDT
From:    George Rinker <gcr at aristotle-gw.jpl.nasa.gov>
Subject: persistent clock drift problem

I have a persistent clock drift problem (on a Sun-3/50 with Release 3.4)
even after the clock patch has been installed correctly (and verified by
chuq at sun.com). Does anyone know the solution?

George Rinker
Jet Propulsion Laboratory
gcr at aristotle.jpl.nasa.gov
(818)354-6711

[[ Dying battery?  Dying crystal?  --wnl ]]

------------------------------

Date:    Tue, 24 May 88 18:26:36 CDT
From:    wucs1!wuccrc!jst at uunet.uu.net (Jon Turner)
Subject: 68881 on a 3/50?

I need to add a 68881 math co-processor to my Sun 3/50.  Sun has an
upgrade available for $700 if you first ship your system back to them. On
the other hand, the 68881 is available for about $200. Is there any reason
that I can't simply buy the chip and plug it into the socket? Are there
any jumpers I need to worry about? If you've done this before, please let
me know. Thanks.

Jon Turner
jst at wuccrc.wustl.edu

------------------------------

Date:    Wed, 25 May 88 09:22:18 EDT
From:    ted at braggvax.arpa
Subject: 68020 upgrades for sun2s?

We have a large collection of sun2 hardware and were wondering if there
are any third party cpu boards that can upgrade a multibus sun2 to a
68020.  I know this wouldn't give us sun3s, but it seems as though it
would be worthwhile if the price were reasonable.  I'd appreciate hearing
about any such thing, and your experiences with it.

Thanks,

Ted Nolan
ted at braggvax.arpa

------------------------------

End of SUN-Spots Digest
***********************



More information about the Comp.sys.sun mailing list