Sun-Spots-Request@RICE.EDU (William LeFebvre) (06/20/88)
SUN-SPOTS DIGEST Sunday, 19 June 1988 Volume 6 : Issue 116 Today's Topics: Re: Sun 3/50 eyestrain Re: Anti-Glare/Polarizing Screen for 19" screens Re: tape drive sharing via switch Re: Binders for the manuals Re: Direct Sun <--> PSN connection Re: Summary of investigation into Backup Applications Re: SunOS 4.0 & sed Re: New TCP/IP release and Sun 3 Strange behaviour of pw_line() under SunView NFS bug? 386i GPIB cards? TIFF to Rasterfile? HyperC*rd for the Suns? 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: Fri, 10 Jun 88 08:50:24 PDT From: weiser.pa@xerox.com Subject: Re: Sun 3/50 eyestrain Something I and others have used that seems to helps a lot in some kinds of bad lighting situations: a cardboard lightshield. This is just a thing you make yourself from an 8.5x11 (A4) piece of cardboard, taped to the top of the CRT so that the overhead light does not directly strike the screen. Works wonders. -mark ------------------------------ Date: Fri, 10 Jun 88 09:10:12 PDT From: celeste@coherent.com (Celeste C. Stokely) Subject: Re: Anti-Glare/Polarizing Screen for 19" screens After my users started complaining about glare and static on their 3/60 and 3/50 monitors, I got some great carbon mesh screens from Sun-Flex in Novato California. The mesh is very fine, is coated with carbon stuff, and the whole thing attaches to a screw on the chassis, so it gets rid of static. It's not a polarizer, but it does a great job at sharpening the contrast, and cutting out a lot of the glare. I paid $110 each, considerably better than Inmac's $229/$279. Of course, Inmac's is glass with an optical coating, etc., but if the mesh works for your type of reflection, you can save a lot of money. Sun-Flex installed one for me, and let me try it out for a week before making up my mind. Be prepared for a major afternoon of installation. It fits BEHIND the bezel, and has to be on tight, or you get moire patterns. Get someone with strong arms to assist. Since I had 10 screens to install, I bought a battery-operated screwdriver, and it helped a LOT! The address is: Sun-Flex 20 Pimentel Court Novato, CA 94949 (800) 458-FLEX / (415) 883-1221 ..Celeste Stokely Coherent Thought Inc. UUCP: ...!{ames,sun,uunet}!coherent!celeste Domain: celeste@coherent.com Internet: coherent!celeste@ames.arpa or ...@sun.com or ...@uunet.uu.net VOX: 415-493-8805 SNAIL:3350 W. Bayshore Rd. #205, Palo Alto CA 94303 ------------------------------ Date: Fri, 10 Jun 88 19:20:08 EDT From: dan@wind.bellcore.com (Daniel R. Strick) Subject: Re: tape drive sharing via switch I have a Pertec-interface tape switch made by Gafford Technology. I have connected it to a Fuji M2444 and to an old CDC Keystone drive (one of the 1600 bpi models that SMI used to sell) using both Xylogics 472 and Ciprico TAPEMASTER 3000 tape couplers. The switch seems to work ok, but it has not yet been heavily used. My switch has 8 computer (Pertec tape coupler) ports and connects to a single string of tape formatters. I think it cost somewhere between 5K and 6K. I believe the product line can be configured for up to 18 computers and up to 18 tape drives (but the cabling for such a configuration must be ferocious, I doubt it has ever been tested, and you have to make sure that no two tape units switched to the same machine respond to the same formatter or formatter/transport address). The guy who makes the Gafford switch insists that all computers connected to the switch have an explicit common logic ground (even if the switch seems to work without one) and gives instructions for "fixing" suns. SMI seems to insist that this not be done. The issue is rather messy. The common ground problem is not particular to this brand of switch or to tape switches in general. The common ground problem can arise whenever you connect logic grounds of separate boxes through interface cabling (including simple arrangements such as one computer connected to one disk drive) but tends to get worse as the number of interconnected boxes increases. It just happens that Tom Gafford has decided to address the problem, probably because a tape switch tends to connect a lot of boxes. Most peripheral equipment manufacturers either ignore the problem or give incomplete or incorrect instructions (see the fine print in your favorite disk drive manual). The telephone number for Gafford Technology is (415) 499-1673. There is a manufacturer's rep in Eastern PA: Peripheral Devices Corp. (215)640-0446. I believe AVIV also makes a tape switch, but I have no experience with it. AVIV: (617) 933-1165. ------------------------------ Date: Fri, 10 Jun 88 08:51:50 PDT From: weiser.pa@xerox.com Subject: Re: Binders for the manuals Binders for Sun manuals are available from the Sun User Group. The binders are precomputed to be the right sizes, and include pre-printed labels for the outside indentifying the contents. -mark ------------------------------ Date: Fri, 10 Jun 88 15:53:58 EDT From: jsol@bu-it.bu.edu Subject: Re: Direct Sun <--> PSN connection Reference: v6n105 Sunlink/DDN is a package you might be intereted in. We use it for our 56kbd connection to an IMP (from a Sun 3/50). Notedly our IMP is at MIT and not directly here. Sunlink/DDN is like Sunlink/X.25 except that it is for HDLC connections. ------------------------------ Date: Fri, 10 Jun 88 10:30:10 MDT From: djn@nmt.edu (Northrop) Subject: Re: Summary of investigation into Backup Applications Reference: v6n105 czei@accelerator.eng.ohio-state.edu (Michael S. Czeiszperger) writes: > >I recently posted an inquiry on sun spots asking for any information about >commercial backup systems. I found one product that claims to provide a >comprehensive backup system for suns, but the company was unable to backup >any of their claims. The company is Spectre, and the product is called >REELbackup. > >Although the salesman claimed the product worked fine on suns, he admitted >that they had not actually sold the program to any sun users.... Gee. That's funny. I have their Sales Order No. 870107 dated 04/30/87 to my employer for use on our Suns. And it's for REEL BACKUP 1.1. Obviously, the salesman you talked to "forgot" about us. I know their "support" people did. >...Spectre has just recently ported the program to suns, so >there was no references or performance data he could provide.... Unless what they are selling now is a complete rewrite of the software we have, I would hesitate to call it "recently ported". I would also strongly recommend you ignore REELBackup. The software we purchased was bug ridden. It should never have left their office let alone been sold. In terms of support they were awful. They were very bad about answering their phone (I got the impression that there were at most three people in the company). When we reported bugs, they claimed that it was because we were using Suns (which they weren't used to). We loaded a tape full of source, provided them an account and they still didn't do anything. Weeks on end of getting either no answer or a busy signal convinced me that they weren't serious. I'm STILL waiting for an update. Since last summer. Even if their product had worked as the abysmal manuals had indicated, we couldn't have used it. It wants tapes pre-labelled by a special program. It wants a DIFFERENT tape for EVERY file system for EVERY save it does. And it wants ALL tapes to be exactly the same size. So you either end up using lots of little tapes for your big file systems, or wasting big tapes on your little file systems. The user interface is stupid. It takes over the entire screen while each dump is done and doesn't even let you ^Z out and do something else. On and on and on. Got idea? I hate their software and I don't have anything good to say about the company (which, by the way, is spelled Sceptre). djn djn@nmtsun.nmt.edu ...!unmvax!nmtsun!djn ------------------------------ Date: 10 Jun 88 14:15:41 GMT From: fed!m1rcd00@uunet.uu.net (Bob Drzyzgula) Subject: Re: SunOS 4.0 & sed Reference: v6n113 OK, so sun!bugs sez that my sed problem is probably because they went to System V.3 sed. They're deciding if they want to call it a problem or a feature. I'll keep you posted. Bob Drzyzgula Federal Reserve Board, Washington, DC, 20551; uunet!fed!rcD ------------------------------ Date: Fri, 10 Jun 88 14:52:45 -0500 From: Gurudatta Parulkar <guru@flora.wustl.edu> Subject: Re: New TCP/IP release and Sun 3 Reference: v6n105 Regarding my message: "Has anybody tried to install the new TCP/IP from UCB...on a Sun 3/50?..." Please do not reply to it. I have got what I wanted. Thanks., -guru ------------------------------ Date: Thu, 9 Jun 88 11:35:15 +0100 From: mcvax!swivax!anjo@uunet.uu.net (Anjo Anjewierden) Subject: Strange behaviour of pw_line() under SunView The function pw_line() for drawing a variety of lines under SunView exhibits somewhat strange behaviour when used as in the following function: /* declarations of global stuff omitted */ /* Draw a nice line from x1,y1 to x2,y2 in the given Pixwin, with thickness and a texture. */ r_nice_line( pw,x1,y1,x2,y2,thickness,texture ) Pixwin *pw; int x1, y1, x2, y2, thickness, texture; { struct pr_brush p_brush; struct pr_texture p_texture; switch( texture ) { case DOTTED: p_texture.pattern = pr_tex_dotted; break; case DASHED: p_texture.pattern = pr_tex_dashed; break; case DASHDOT: p_texture.pattern = pr_tex_dashdot; break; case DASHDOTTED:p_texture.pattern = pr_tex_dashdotdotted; break; case LONGDASH: p_texture.pattern = pr_tex_longdashed; break; default: return; } p_brush.width = thickness; pw_line( pw,x1,y1,x2,y2,&p_brush,&p_texture,PIX_SET ); return; } Sometimes this crashes, with a stack trace identifying the following function responsible: pattern_offset( 0xffff0eff,0xfffff524,0xefff36c,0xefff370,0x9,0x0,0xffffffff,0x0,0xefff4e4 ) bres_majx( 0x9,0x1,0xa,0xfffffffc,0x1,0x0,0x8,0x0,0xefff4e4,0x263ee0 ) pr_texvec( 0x263e3c,0x0,0x8,0x9,0x9,0xefff4e4,0x1f ) pro_line( 0x263e3c,0x0,0x8,0x9,0x9,0xefff4e0,0xefff4e4,0x1e,0x0 ) pw_line( 0x263ce0,0x0,0x8,0x9,0x9,0xefff4e0,0xefff4e4,0x1e ) r_nice_line( 0x15,0x1d,0x1e,0x1e,0x1,0x234 ) The r_nice_line() function was called from a number of different places (to draw lines, boxes and arrow-heads with nice lines). At first I thought the bug was somewhere in my code, clobbering something somewhere. After four hours of debugging and just about to blame the microcode, I modified the r_nice_line( pw,x1,y1,x2,y2,thickness,texture ) Pixwin *pw; int x1, y1, x2, y2, thickness, texture; { static struct pr_brush p_brush; /* must be static */ static struct pr_texture p_texture; /* must be static */ And luck struck, this works! What apparently happens is that one of the functions called by pw_line() behaves differently depending on the address of the brush and texture arguments. In the first version of r_nice_line() brush and texture where allocated on the stack (and therefore had very large addresses). In the second version the addresses are on the "heap" and therefore in the low end of memory. I have not found any documentation on "struct pr_texture", any pointer to such documentation is greatly appreciated. Anjo Anjewierden (...!mcvax!swivax!anjo; anjo@swivax.uucp) University of Amsterdam, The Netherlands. ------------------------------ Date: Thu, 9 Jun 88 12:32:19 +0200 From: mcvax!olsen!nagler@uunet.uu.net (Robert Nagler) Subject: NFS bug? We are running Sun OS 3.2 on Sun 3 machines. Given the "right" circumstances, we have seen seriously corrupted data written by an NFS client to a network partition. The environment is: partition mounted hard,rw,bg server is 3/180 (with no ND clients) client is 3/50 with or without a local disk program uses /dev/ttya (raw mode), alarms, and UDP messages all events are caught via signals, but the the data is not read or written in the signal handler (i.e. the signal handler just sets a boolean). The program is a communications server which was written locally. The language is Modula-2, but this is probably irrelevant. The program is invoked as follows: program >& log & "log" is on the NFS partition. If you do not look at the file "log", everything is ok, that is, the data appears to be uncorrupted. However, if you run a tail, as follows: tail -f log on the same host that is running the program, the log file will become corrupted. The output of the "tail", the actual data in the file (viewed from an independent NFS client), and what should be in the file all do not agree. The errors are sometimes lost values and, more strangely, misplaced values. The program writes to its log file without doing "seek" operations, but we have seen data which looks like: Bla BWOOPSa Bla Bla "" Bla Bla where the correct output should be: Bla Bla Bla Bla Bla "WOOPS" Bla Bla Another interesting problem is that the tail runs very very slowly when compared with a tail of the same file under the same circumstances on another host. The essential facts: - If we run another program, say B, which doesn't do alarms and I/O to a "tty", but does UDP messages. We can't reproduce the problem. - If the tail is run on a different host from where the program is running, the results are just fine. - If the tail is not run, the file is fine. - The tail output does not agree with what is actually in the file unless the tail is run on a different machine from the program. We use NFS for all of our files (user data). We have never seen any weird (reproducible) behavior like this. There is the occasional "stale NFS handle" when we use the "on" program, but I think this is an unrelated issue. Normally, we write our log files to a local file system so this problem has not been seen before. The programs have been running for a half year or so. Has anyone seen this type of problem? The program is a bit too complicated (and large) to include in this message and we are too busy to trace it down, sorry. The critical conditions seem to be the alarm/IO signals and having reader/writer on the same machine. Any opinions, help, etc. will be appreciated. Rob Nagler olsen!nagler@uunet.uu.net ------------------------------ Date: Fri, 10 Jun 88 15:55:17 PDT From: M_Helm@csa3.lbl.gov Subject: 386i GPIB cards? If you know anything about/have any experience with GPIB (IEEE-488) cards + software for the Sun 386i, I'd like to hear from you! Michael Helm (415 486 7248) (Arpanet M_Helm@lbl.gov) MS 46-161 (possibly uunet!LBL.Gov!M_Helm) Lawrence Berkeley Lab Berkeley CA 94720 ------------------------------ Date: Fri, 10 Jun 88 19:29:58 pdt From: olson@anl-mcs.arpa (Bob Olson) Subject: TIFF to Rasterfile? Does anyone have a TIFF to Sun rasterfile conversion program?? Or at least, does anyone have a complete specification of the TIFF graphics format? Thanks... Bob Olson Argonne National Laboratory olson@anl-mcs.arpa ------------------------------ Date: Thu, 12 May 88 00:44:28 -0400 From: Henry B.J. Krempel <krempel@pacrat.npac.syr.edu> Subject: HyperC*rd for the Suns? I think it's a great idea, but my own opinion is that it would be easier (and better) to develop this for NeWS. The high-level environment NeWS provides, with an existing graphics interpreter makes me think that HyperCard wouldn't be too difficult to write. I think we should all get together, and contribute to a PD HyperC*rd for NeWS, to be stored in some public ftp area somewhere (brillig.umd.edu?) ala GNU. (Can they sue us if we give it away?) [[ Anyone can use anyone at any time about anything. And if the lawsuit doesn't get thrown out immediately (for being obviously and completely preposterous to a judge), then the defendant can easily sink large sums of money into legal fees. Recall the recent "look and feel" lawsuit that Apple filed against (I believe) Hewlett Packard. I don't recall the outcode, but even if Apple lost and even if HP recovered its legal fees, Apple succeeded in wasting alot of HP's time and effort and in delaying the product's introduction into the marketplace. Whoops! I better get off my soapbox before I say something *really* nasty. --wnl ]] ------------------------------ End of SUN-Spots Digest ***********************