Sun-Spots Digest, v6n47

William LeFebvre Sun-Spots-Request at RICE.EDU
Thu Apr 7 14:03:32 AEST 1988


SUN-SPOTS DIGEST         Wednesday, 6 April 1988       Volume 6 : Issue 47

Today's Topics:
                  Re: Changes in user mail interface (2)
                        Re: Whining disk drive (2)
                      Re: Problems reading TAR tapes
              Solution: Sun 3 won't pass diags, dead battery
              Deficiencies in SUNOS 3.4 TTY and PTY drivers
                             Strange f77 bug
              I want a better SCSI adaptor for an older sun3
                            Doing a Fast Zoom?
                      Backplane Schematics Anyone??
                   Changing canvas colors dynamically?

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 stored on "titan.rice.edu".  For volume X, issue Y,
"get sun-spots/vXnY".  They are also accessible through the archive
server:  mail the word "help" to "archive-server at rice.edu".

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

Date:    Sun, 27 Mar 88 14:06:47 EST
From:    phri!roy at cmcl2.nyu.edu (Roy Smith)
Subject: Re: Changes in user mail interface (1)
Reference: v6n37

I suspect that Sun did it because their use of r/R is "the right way";
i.e. the most usual default is that you only want to reply to the person
who sent the message.  Of course, that's a matter of opinion, but it does
happen to agree with my opinion, so it must be right :-)  Of course, there
is a lot to be said for "if it ain't broke, don't fix it, and even if it's
broke, as long as it's not *really* broke, don't fix it either".

Anyway, the thing to do is set the "replyall" mail variable, which puts
things back to the way vanilla UCB mail does it.  You should be able to
put "set replyall" in your personal .mailrc file, or in /usr/lib/Mail.rc
to make it the system-wide default.  BTW, I think the r/R reversal goes
back to at least 3.0, and probably even earlier.

Roy Smith, {allegra,cmcl2,philabs}!phri!roy
System Administrator, Public Health Research Institute
455 First Avenue, New York, NY 10016

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

Date:    Sun, 27 Mar 88 21:26:52 EST
From:    hedrick at aramis.rutgers.edu (Charles Hedrick)
Subject: Re: Changes in user mail interface (2)
Reference: v6n37

woods at handies.ucar.edu (Greg Woods) asks about changes that Sun has made
to the behavior of UCB mail, particular "r" replying only to the sender.
First, it is clear that Sun has put some work into mail, both in minor
enhancements and in documentation.  Some of these move it closer to 4.3
Mail, but some seem to be Sun's own idea.  I heartily agree with the
change in default "r" behavior.  However if you don't like it, you can set
the replyall variable, either in your own startup file or the system
startup file.  Under other versions of mail, we have had several cases
where faculty sent mail to more people they intended, with embarrasing
results.  It only takes a couple of such cases before users start leaning
on us to change the software.  We finally ended up modifying mail on our
other BSD machines to act like Suns, and doing the same to Emacs rmail.
We think Sun is right that it is better to be "safe", and let the user to
R instead of r if he wants the mail to go to everyone.  As far as I know,
this change is not specific to the Sun 4, but is present on our Sun 3's as
well (SunOS 3.2).

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

Date:    Mon, 28 Mar 88 12:16:18 EST
From:    flynn%boopsie at cpswh.cps.msu.edu (Pat Flynn)
Subject: Re: Whining Disk Drive (1)
Reference: v6n36

We had the same problem with the shoebox on our 3/110 (141MB + tape).  We
got it last June, and it started whining soon after.  The sound ranged
from a mild high-pitched squeal to a obnoxious roar that made it really
hard to think in the machine's vicinity.

We talked to our Sun rep about this and he said that the problem is
usually due to an antistatic brush.  It connects the shaft of the disk
drive to the controller PCB.  What we did was

1. Make a FULL BACKUP of the disk.

2. Open up the disk drive.  On our unit, the drive (Micropolis) is mounted
on the right side of the enclosure.  The controller PCB is on the right
side of the disk.  The brush can be seen in the approximate center of the
PCB.  It's copper and its tip goes into a hole in the PCB, and touches the
drive shaft.  (Not for the faint-hearted: you can fire up the machine with
the cover off and see if touching the brush causes the sound to change. On
our machine the brush is kinda hard to reach, but we managed to touch it
with the eraser end of a pencil.  Sure enough, the sound changed.)

3. Gingerly dismount the drive.  There are some screws and some nuts to
loosen.

4. Fiddle with the brush.  Some people (even Sun reps) have suggested
clipping the brush off, or bending it so that it no longer touches the
shaft.  We really didn't want to do this (it was put there for a purpose,
right?) so we taped the brush down with some clear tape.  Make sure any
foreign objects you introduce into the cabinet won't come off if the box
is moved.

5. Reassemble the unit, etc.

Since we taped our brush (1 month ago) we haven't had any problems. It
will let out a gentle moan once in a while, but it's nowhere near as bad
as it was.

I heard that this phenomenon (screaming disks) is quite widespread.

Pat Flynn, Dept. of Computer Sci., Michigan State U.
flynn at cpsvax.cps.msu.edu     ihnp4!msudoc!flynn    FLYNN at MSUEGR.BITNET

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

Date:    Fri, 25 Mar 88 17:59:54 PST
From:    ultra!shj at ames.arc.nasa.gov (Steve Jay)
Subject: Re: Whining disk drive (2)
Reference: v6n36

In v6n36, Joel Riedesel (riedesel at aisunj.cs.uiuc.edu) complains about
Micropolis 141 MB disks whining.  We had the same problem.  In response to
a service call, the Sun guy removed what he called the "static brush" from
the drive.  He said they are having to perform that surgery on many
Micropolis drives.  I have heard of similar problems with disks from many
manufacturers over the years.

Steve

Steve Jay                       domain: shj at ultra.com
Ultra Network Technologies	Internet: ultra!shj at ames.arc.nasa.gov
2140 Bering drive               uucp: ...ames!ultra!shj
San Jose, CA 95131		
408-922-0100

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

Date:    Sat, 26 Mar 88 16:24:47 est
From:    suneast!alliant.Alliant.COM!werme at sun.com (Ric Werme)
Subject: Re: Problems reading TAR tapes
Reference: v6n34

I suspect the problem is byte ordering.  While I'm not familiar with
Masscomp, Intel does byte ordering the opposite of Motorola.  Since you
can use tar between Masscomp and Intel, I deduce they must have similar
byte ordering.

The tar headers have miscellaneous ints and shorts, hence it matters.

I do know of a tar tape written by a Vax that was unreadable by an
Integrated Solutions(?) workstation (68xxx), but readable just fine on
another Vax.

Eric J Werme
uucp: decvax!linus!alliant
Phone: 603-673-3993

[[ Sorry Mr. Werme, but you are completely incorrect here.  The header for
a tar file is an array of character strings.  All data (even uid, gid, and
size, are stored in the headers as ASCII strings, and not in binary form.
Hence they are not subject to byte ordering problems.  I have personally
written a tar tape on a VAX and read it successfully on a Sun.  Tar tapes
transferred across the Internet (via FTP) untar successfully regardless of
byte order (provided they were transferred with "type image"---the nulls
do sometimes present a problem to FTP "type ascii" transfers).  If you
doubt me, go read it for yourself in the section 5 manual page for "tar".
--wnl ]]

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

Date:    25 Mar 1988 17:47-PST
From:    Patrick Boyle <boyle at pescadero.stanford.edu>
Subject: Solution: Sun 3 won't pass diags, dead battery

Symptoms:
  Turn on your Sun3 (in my case a 3/50) and wait. The screen stays blank and
  the LEDs on the back of the processor board stop, indicating an error.

Sleuthing:
  Turn off the Sun, connect a terminal to the serial port A, 
  flip the switch from NORMAL to DIAG, turn on the workstation, and watch
  the diagnostics play on.
  If the diagnostics stop with something like 
    TOD clock interrupt test
       clock should have interrupted 	<- not the exact messsage
  Then ....

Solution:
  Pull the cpu board from the machine and replace the clock battery
  (actually 2 little 391 batteries in our case, available at your local
  camera/drug store).

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

Date:    Fri, 25 Mar 88 15:48:56 mst
From:    modular!olson at arizona.edu (Jon Olson)
Subject: Deficiencies in SUNOS 3.4 TTY and PTY drivers

We have recently developed a  multiplexor board which  has eight RS232
ports.  This board which allows a single RS232 port on a SUN workstation
to support seven ports (the eighth port on the multiplexor board connects
to the RS232 port on the SUN).

A MUX daemon on the SUN provides the interface software between the single
RS232 port and seven pseudo-terminal (pty) ports.  Although the interface
was simple to develop and debug there are a few shortcomings with the
`tty' and `pty' drivers which would be useful in this application (and
many other applications).

  1) I have found that SUNOS 3.4 does not support hardware (CTS/RTS)
     handshaking on RS232 lines.  Since the MUX should pass any binary
     information through the TTY port, ^S/^Q handshaking won't work
     without messy encoding of the data stream.  Hopefully SUNOS 4.0
     will support hardware handshaking (is this true?).

  2) The standard TTY driver does not have sufficient buffering to
     accept large data packets.  I have limited the size of packets
     sent to the SUN to 64 bytes to overcome this limitation.  It
     would be useful to have an `ioctl' which configures a large
     buffer for a TTY port.

  3) I tried the `bk' driver but it doesn't work with the `select'
     system call.  When given a file descriptor of a tty using the
     `bk' line discipline, `select' always returns immediately even if
     there is no data to be input.

  4) The `pty' driver has a TIOCPKT mode which gives one of the
     following control flags.

	TIOCPKT_FLUSHREAD
        TIOCPKT_FLUSHWRITE
        TIOCPKT_STOP
        TIOCPKT_START
        TIOCPKT_DOSTOP

     Ultrix (DEC's Unix) has an extra (very useful) control flag which
     SUN leaves out, TIOCPKT_IOCTL, which indicates that the slave
     process has executed an ioctl operation.  This allows the master
     to manipulate the device to emulate the ioctl operation  that the
     slave just performed.

Any comments on hardware handshaking or high-speed input of data over
RS232 lines would be appreciated.

Jon Olson, Modular Mining Systems
USENET:     {ihnp4,allegra,cmcl2,hao!noao}!arizona!modular!olson
INTERNET:   modular!olson at arizona.edu

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

Date:    Thu, 24 Mar 88 11:05:28 EST
From:    Mike Peterson <petersn at aurora.toronto.edu>
Subject: Strange f77 bug

The following f77 program gives a "bus error" at execution time on several
different Unix systems, including SUN 4/200, Iris 2400 and Gould UTX,
causes the compiler to abort on uVax/Ultrix, but works on SUN 3/180 (with
VMS-compatible compiler) and SUN 3/50 (with ?? compiler).  Has anyone seen
this before, or would like to make a comment ?

C
C     PROGRAM TO GENERATE STARS WITH UP TO 4 ARMS
C
      real*8 R(200,4),WT(0:200)
      INTEGER*2 M(401,401)
      INTEGER*2 LX(200,4),LY(200,4)
C
      DATA M/160801*0/,R/800*0.d0/
C
      lx(1,1) = 0
      ly(1,1) = 0
      WT(1)=1.d0
C
C     The following statement is essential to make it fail !
C
      M(200,200)=1
      i = 1
      l = 1
      write (6,9990) i, l
 9990 format (' i =',i4,', l =',i4)
      R(L,I)=R(L,I)+((LX(L,I)-200)**2+(LY(L,I)-200)**2)*WT(L)
      write (6,*) 'Made it!'
      STOP
      END

Mike Peterson, Univ. of Toronto Chemistry, (416) 978-7094
E-Mail: petersn at aurora.toronto.edu

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

Date:    Sat, 26 Mar 88 12:12:22 PST
From:    grand!day at uunet.uu.net
Subject: I want a better SCSI adaptor for an older sun3

The horrible cartridge tape performance on older (first 1.5 years of)
sun3's is well known.  The problem is that the SCSI adaptor doesn't allow
the system to release the SCSI bus when the tape is doing non-useful work,
like rewinding (lack of the disconnect-reconnect feature).

Finally after much delay, Sun came out with a new SCSI adaptor (the
SCSI-3) to fix this problem but it only works with late-model CPUs that
support 32-bit DMA, so I and many others who would have liked be rid of
this crock would have to pay quite a lot to do so.

Is there a 3rd-party VME SCSI adaptor that one could just drop in and get
disconnect-reconnect without ROM, boot, or driver changes?  Is such a
thing even possible?

 --dave yost

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

Date:    Fri, 25 Mar 88 20:01:48 EST
From:    Brian Glendenning <brian at radio.toronto.edu>
Subject: Doing a Fast Zoom?

Does anyone have a piece of code to do a fast zoom to a window under
suntools?  I have a program that acts as a graphics server to a large
astronomy package, and every last little bit of speed will be felt.

What I'm now doing is stepping through the image a line at a time, zooming
that line into a temp array by "hand", and then pw_rop'ing the zoomed line
into the screen. That is:

                                       111000111000111000111000111000
1010101010101010  Zoom by 3 (say) ---> 111000111000111000111000111000 -> pw_rop
                                       111000111000111000111000111000

(original image line)                        (zoomed temp array)



While this is a lot faster than some of my earlier efforts, I thought I'd
ask if anyone had any really fast code, or suggestions. For instance, I'm
doing an incore transfer that in principle isn't necessary if I wrote to
screen memory, but I'm not quite sure how to do that, especially if one
wants to worry about overlapping windows etc. My code now takes a couple
of seconds to zoom the full screen (colour sun 3/180).

Any advice, programs, or code fragments would be much appreciated. Thanks.

Brian Glendenning                INTERNET - brian at radio.toronto.edu
Radio Astronomy, U. Toronto          UUCP - {uunet,pyramid}!utai!radio!brian
+1 (416) 978-5558                  BITNET - glendenn at utorphys.bitnet

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

Date:    Sat, 26 Mar 88 15:31:58 PST
From:    cvbnet!cvedc!opus!markh at sun.com (Mark Holm)
Subject: Backplane Schematics Anyone??

A friend and I are attempting to build a pair of multibus (010) Sun's
(s/120??) from spare boards that we have aquired and are having a little
trouble getting the backplane correct.  We are using surplus Intel
rack-mount multibus frames from ICS 80 systems. The backplane "seems" to
be wired the same with the exception of pin 16 (BPR0) on P1 bus  which is
daisy chained from pin 15 (BPRI) down the line on the Intel backplane and
(as near as I can tell) Pin 16 on the Sun backplane is all tied together.
I made that modification and installed the processor board and one memory.
The processor made it through selftest and started the heartbeat but gave
no sign-on message or monitor prompt.

Has anybody else done anything similar, have any suggestions, possibly
have a set of schematics for a 2/120 that they would like to share??? At
this point any information at all would help!

Mark Holm			..tektronix!ogcvax!cvedc!mholm
Computervision                  ..sun!cvbnet!cvedc!mholm
14952 NW Greenbrier Parkway     Phone (503)645-2410
Beaverton, Oregon 97006         FAX   (503)645-4734

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

Date:    Sat, 26 Mar 88 17:43:43 EST
From:    rayk at sbcs.sunysb.edu (Raymond T Kreisel)
Subject: Changing canvas colors dynamically?

Question: is there anyway that I can change the canvas size dynamicly and
still have a retained canvas that is 8 bit planes deep ???

 My program does the following:

   1.) I create a frame (this is on a color Sun)
   2.) I create a canvas which is a child of that frame
	that canvas now is 8 bit planes deep, which is correct.
   3.) Now I try to change the canvas size by doing the following:

(void)window_set(canvas,
            CANVAS_WIDTH,               file_header.ras_width,
            CANVAS_HEIGHT,              file_header.ras_height,
            0);

Whenever it executes this instruction to change the canvas size it also
changes the retained canvas from 8 bit planes deep to 1 bit plane deep so
then the retained canvas is no longer color.

thanks in advance,
ray

Ray Kreisel
UUCP: {allegra, philabs, pyramid, research}!sbcs!rayk   
ARPA-Internet: rayk at sbcs.sunysb.edu			CSnet: rayk at suny-sb

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

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



More information about the Comp.sys.sun mailing list