Sun-Spots Digest, v6n116
William LeFebvre
Sun-Spots-Request at RICE.EDU
Mon Jun 20 12:07:19 AEST 1988
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 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: Fri, 10 Jun 88 08:50:24 PDT
From: weiser.pa at 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 at 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 at coherent.com
Internet: coherent!celeste at ames.arpa or ... at sun.com or ... at 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 at 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 at 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 at 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 at nmt.edu (Northrop)
Subject: Re: Summary of investigation into Backup Applications
Reference: v6n105
czei at 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 at nmtsun.nmt.edu ...!unmvax!nmtsun!djn
------------------------------
Date: 10 Jun 88 14:15:41 GMT
From: fed!m1rcd00 at 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 at 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 at 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 at swivax.uucp)
University of Amsterdam, The Netherlands.
------------------------------
Date: Thu, 9 Jun 88 12:32:19 +0200
From: mcvax!olsen!nagler at 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 at uunet.uu.net
------------------------------
Date: Fri, 10 Jun 88 15:55:17 PDT
From: M_Helm at 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 at 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 at 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 at anl-mcs.arpa
------------------------------
Date: Thu, 12 May 88 00:44:28 -0400
From: Henry B.J. Krempel <krempel at 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
***********************
More information about the Comp.sys.sun
mailing list