Sun-Spots-Request@RICE.EDU (William LeFebvre) (04/07/88)
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@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 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@rice.edu". ---------------------------------------------------------------------- Date: Sun, 27 Mar 88 14:06:47 EST From: phri!roy@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@aramis.rutgers.edu (Charles Hedrick) Subject: Re: Changes in user mail interface (2) Reference: v6n37 woods@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@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@cpsvax.cps.msu.edu ihnp4!msudoc!flynn FLYNN@MSUEGR.BITNET ------------------------------ Date: Fri, 25 Mar 88 17:59:54 PST From: ultra!shj@ames.arc.nasa.gov (Steve Jay) Subject: Re: Whining disk drive (2) Reference: v6n36 In v6n36, Joel Riedesel (riedesel@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@ultra.com Ultra Network Technologies Internet: ultra!shj@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@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@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@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@arizona.edu ------------------------------ Date: Thu, 24 Mar 88 11:05:28 EST From: Mike Peterson <petersn@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@aurora.toronto.edu ------------------------------ Date: Sat, 26 Mar 88 12:12:22 PST From: grand!day@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@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@radio.toronto.edu Radio Astronomy, U. Toronto UUCP - {uunet,pyramid}!utai!radio!brian +1 (416) 978-5558 BITNET - glendenn@utorphys.bitnet ------------------------------ Date: Sat, 26 Mar 88 15:31:58 PST From: cvbnet!cvedc!opus!markh@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@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@sbcs.sunysb.edu CSnet: rayk@suny-sb ------------------------------ End of SUN-Spots Digest ***********************