Sun-Spots Digest, v6n112

William LeFebvre Sun-Spots-Request at RICE.EDU
Fri Jun 17 13:22:32 AEST 1988


SUN-SPOTS DIGEST          Thursday, 16 June 1988      Volume 6 : Issue 112

Today's Topics:
                         Administrivia: Addresses
                        Re: Sun 3/50 eyestrain (3)
                Re: Optical Character Recognition for Sun
                    Re: [Unofficial] Patch to Fig 1.4
           Sun-3/260 to Sun-4/260 upgrades cannot be stabilized
                     SunOS 4.0 bug in .rhosts support
                   Problems with CDC EMD (368M) drives
         Looking for parameters for using dump with QIC 24 format
                         Synchronous I/O Drivers?
                                 /etc/sm?
                          Converting pic to fig?

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:    Thu, 16 Jun 88 15:42:00 CDT
From:    William LeFebvre <phil at rice.edu>
Subject: Administrivia: Addresses

Several mail messages have been sent to the Sun-Spots submission address
that suspiciously look like archive server requests.  Sigh.  Just to
review, these are the addresses that are pertinent to Sun-Spots readers:

	sun-spots at rice.edu		All messages that are intended for
					for inclusion in a Sun-Spots digest.
	sun-spots-request at rice.edu	All messages about administrative
					matters, such as additions,
					deletions, and mail problems.
	archive-server at rice.edu		All archive server requests (these
					are only seen by a program).
	archive-management at rice.edu	All messages about problems with
					the archive server (these are seen
					by a real person).

I generally do not have the time to redirect misdirected messages.  They
will usually be ignored.

A few notes:  some sites have "mail exploders"---addresses that resend a
digest to many other addresses.  If you think you are on one of these and
wish to be removed, it is faster to contact your local postmaster.  There
is one mail exploder for the entire United Kingdom.  I will not knowingly
add an address to the main list for a site in the UK, because of
communications cost.  If you wish to be added to or deleted from that
exploder, contact "postmaster at nss.cs.ucl.ac.uk".  Finally, bitnet readers
can add and remove themselves through the list server at node "RICE".

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

Date:    Thu, 9 Jun 88 07:32:43 EDT
From:    Chuck Musciano <chuck at trantor.harris-atd.com>
Subject: Re: Sun 3/50 eyestrain (1)
Reference: v6n105

We have found that turning off at least half of the flourescent bulbs in
your office can help relieve "beating" between the display and the lights.
In my office (shared with one other person) we have two Suns, and four
light fixtures with three bulbs each.  We disabled all but two of the
bulbs, and put a Luxo lamp on each desk.  You'd be surprised how more
soothing the lighting is, and the reduction in brightness is actually a
benefit.  Also, we put our monitors up on little stands, and I sit on one
of those "kneeling" chairs, which gets my eyes out of the path of
reflected light from the remaining flourescents.

Eye strain is also caused by the constant focusing your eyes do, even if
you have good vision.  The relaxed foxusing distance of your eye is 20
feet.  Like a camera, your eye is constantly racking in and out of focus
to view a screen which is just 20 inches from your face.  A company (whose
name escapes me, how helpful) makes a product called Vuers (pronounced
"viewers") which is tuned to your exact screen/eye distance, and changes
your relaxed focusing distance.  Perhaps someone else has the name of this
company.

Chuck Musciano
Advanced Technology Department
Harris Corporation
(407) 727-6131
ARPA: chuck at trantor.harris-atd.com

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

Date:    Thu, 9 Jun 88 09:28:13 CDT
From:    James Peterson <peterson%sw.MCC.COM at mcc.com>
Subject: Re: Sun 3/50 eyestrain (2)
Reference: v6n105

Rich Wales <wales at cs.ucla.edu> writes:

> My office has fluorescent lighting (and there is no hope of my getting
> said lights changed to incandescent)...

and wnl adds:

> [[ There is a distinct possibility that your eyestrain is caused by a poor
> interactoin between the screen's refresh and the fluorescent light's
> flicker...

We have a similar situation with fluorescent lighting.  Several people
have taken things in their own hands and brought in desk lamps -- either
the kind that set on their desks or the telescoping kind that clamp on the
edge of the tables.  They leave the overhead lights off.  The desk lamps
only need an outlet and you can get them at various brightnesses,
moveable, point them to provide only reflective light, dim, and so on.
Even if you have to pay for it yourself, the cost is probably less than
the cost of an eye exam.

jim

[[ Has it helped?  --wnl ]]

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

Date:    Thu, 9 Jun 88 10:12:18 PDT
From:    david at sun.com (David DiGiacomo)
Subject: Re: Sun 3/50 eyestrain (3)
Reference: v6n105

>[[ There is a distinct possibility that your eyestrain is caused by a poor
>interactoin between the screen's refresh and the fluorescent light's
>flicker...

I've heard this before, but I can't understand the reasoning behind it.
The screen emits light, the fluorescent emits light, and they just add.
Why should there be any interaction?  Do some people have non-linear eyes?

David DiGiacomo, Sun Microsystems, Mt. View, CA  sun!david david at sun.com

[[ Both fluorescent and incandescent lights "flicker" mainly because the
source voltage is alternating current.  Theoretically, the flicker is fast
enough (50-60 hz) that the eye won't notice it.  But not all parts of a
screen are on at the same time, either.  In reality, only one point of the
screen is on at any instant in time.  The cathode ray gun that excites the
phosphor on the screen scans from left to right then top to bottom.  Now a
phosphor's persistence will alleviate screen flicker, but parts of the
screen will still be brighter than other parts regardless of the
persistence.  Again, the idea is that this is happening so fast that the
human eye can't see it.  But if the screen is refreshing at a different
rate than the ambient light, it can cause subtle problems.  I guess that
fluorescent lights' flicker is substantialy worse than incandescent,
making eye strain much worse under those conditions.  This is also why
working by sunlight helps so much (provided that there's no glare)---the
light source is continuous.  An extreme example of this phenomenon would
be to illumiate a screen's surroundings with just a strobe light.  --wnl ]]

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

Date:    Wed, 8 Jun 88 16:50:01 EDT
From:    Root Boy Jim <rbj at icst-cmr.arpa>
Subject: Re: Optical Character Recognition for Sun

Try Palantir in my old home town, Rockville, MD. (301) 468-3395.

	(Root Boy) Jim Cottrell	<rbj at icst-cmr.arpa>
	National Bureau of Standards
	Flamer's Hotline: (301) 975-5688

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

Date:    Wed, 8 Jun 88 17:11:55 PDT
From:    david at sun.com (David DiGiacomo)
Subject: Re: [Unofficial] Patch to Fig 1.4
Reference: v6n104

I thought Wayne Mesard's rasterfile output patch was a great idea, but his
code didn't work quite right for me.  Maybe I misapplied the patch.
Anyway, here is the relevant part of *my* version of bitmap.c:

create_n_write_bitmap(fp)
FILE	*fp;
{
	extern struct pixwin	*canvas_pixwin;
        extern int Use_RT_STANDARD;
	int	 box, marker, xmin, ymin, xmax, ymax;
	Pixrect	*bitmap, *pw_pixrect, *pw_prretained;
	F_text	*t;

	/* Assume that there is at least one object */
	compound_bound(&objects, &xmin, &ymin, &xmax, &ymax);

	if (DEBUG) {
	    draw_rectbox(xmin, ymin, xmax, ymax, INV_PAINT);
	    }
	bitmap = mem_create(xmax-xmin+1, ymax-ymin+1, 1);
	pw_pixrect = canvas_pixwin->pw_pixrect;
	pw_prretained = canvas_pixwin->pw_prretained;
	canvas_pixwin->pw_pixrect = canvas_pixwin->pw_prretained = bitmap;
	translate_compound(&objects, -xmin, -ymin);
	marker = pointmarker_shown;
	pointmarker_shown = 0;
	box = compoundbox_shown;
	compoundbox_shown = 0;
	pw_batch_on(canvas_pixwin);
	redisplay_arcobject(objects.arcs);
	redisplay_compoundobject(objects.compounds);
	redisplay_ellipseobject(objects.ellipses);
	redisplay_lineobject(objects.lines);
	redisplay_splineobject(objects.splines);
	redisplay_textobject(objects.texts);
	put_msg("Writing . . .");

	if (Use_RT_STANDARD) {
	    pr_dump(bitmap, fp, (colormap_t *) 0, RT_BYTE_ENCODED, 0);
	    Use_RT_STANDARD = 0;
	}
	else
		write_icon(fp, bitmap);

	put_msg("Done");
	fclose(fp);
	pr_destroy(bitmap);

	canvas_pixwin->pw_pixrect = pw_pixrect;
	canvas_pixwin->pw_prretained = pw_prretained;
	pw_batch_off(canvas_pixwin);
	pointmarker_shown = marker;
	compoundbox_shown = box;
	translate_compound(&objects, xmin, ymin);
	}

static
write_icon(fp, bitmap)
FILE		*fp;
struct pixrect	*bitmap;
{
	int		i, j, width, height, shorts_per_row, off;
	u_short		*ptr;

	width = bitmap->pr_size.x;
	height = bitmap->pr_size.y;
	shorts_per_row = (int) ((width + 15) / 16);
	off = mpr_mdlinebytes(bitmap) / 2 - shorts_per_row;

	ptr = (u_short*) mpr_d(bitmap)->md_image;
	fprintf(fp, "/* Format_version=1, Width=%d, Height=%d, ",
		width, height);
	fprintf(fp, "Depth=1, Valid_bits_per_item=16\n */\n");

	for (i = 0; i < height; ) {
		fprintf(fp, "\t");
		fprintf(fp, "0x%04X", *ptr++);
		for (j = 1; j < shorts_per_row; j++) 
			fprintf(fp, ",0x%04X", *ptr++);
		if (++i >= height) /* if i is not the last row */
			fprintf(fp, ","); 
		fprintf(fp, "\n");
		ptr += off;
	}
}

David DiGiacomo, Sun Microsystems, Mt. View, CA  sun!david david at sun.com

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

Date:    Wed, 8 Jun 88 13:36:43 EDT
From:    hull at cs.buffalo.edu (Jon Hull)
Subject: Sun-3/260 to Sun-4/260 upgrades cannot be stabilized

We have recently upgraded two Sun-3/260G's to Sun-4/260G's.  One of the
systems periodically crashes with a 'panic: vgetu' error and the other
with a 'panic: data fault' error.  Various boards have been replaced, etc.
to no avail.

Both systems use the Interphase 3200 disk controller with software
supplied by Interphase.  Each machine has a pair of Fujitsu 2333 disks
attached to the 3200.  The rest of the hardware is all vanilla Sun stuff.
The machine that gives the 'panic: vgetu' error includes the Xylogics 472
tape controller with a Fuji 1600/6250 bpi tape and a Sun 71MB SCSI disk. 

Before the upgrades these systems were working fine.

If you have run across either of these problems before or have any idea
about their cause, please let me know.

Thanks,
Jon Hull
hull at cs.buffalo.edu

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

Date:    Wed,  8 Jun 88 14:41:55 PDT
From:    Jim Nisbet <GG.JDN at forsythe.stanford.edu>
Subject: SunOS 4.0 bug in .rhosts support

".rhosts" problem in SunOS 4.0

We are running SunOS 4.0 on Sun-4 and Sun-3 computers.  The problem
described below with ".rhosts" exists in both the SPARC and the 68020
versions.

The user ".rhosts" file checking essentially stopped working when we went
to SunOS 4.0.  The /etc/hosts.equiv checking is still being done, but the
external appearance is that the user's .rhosts file is NOT checked.  I
traced it down to a suspected bug in the ruserok() routine (called by
/bin/login and /usr/etc/in.rshd).  It gets a protection exception in the
code that checks .rhosts.

I wrote a little test program that confirms this.  The "ruserok" routine
in rcmd gets a protection exception when you run the following program
under SunOS 4.0.  When I ran it under a 4.3 BSD system it just returned a
return code (as expected).

/j
____________________

Script started on Wed Jun  8 14:30:42 1988
lindy[1]> cat /tmp/niz.c
/*  Test program to demonstrate bug in ruserok().  */

char *rhost = "forsythe.stanford.edu";
char *ruser = "niz";

main () {
   int rc;

   rc = ruserok(rhost, 0, ruser, ruser);
   printf("rc = %d\n", rc);
}
lindy[2]> cc -o /tmp/niz /tmp/niz.c
lindy[3]> rm core
rm: core: No such file or directory
lindy[4]> dbx /tmp/niz
Reading symbolic information...
Read 11 symbols
warning: main routine not compiled with the -g option
(dbx) run
Running: /tmp/niz
signal SEGV (segmentation violation) in _checkhost at 0xf7723d70
0xf7723d70:     st      %o4, [%l7]
(dbx) where
_checkhost() at 0xf7723d70
_validuser() at 0xf7723acc
ruserok() at 0xf772380c
main() at 0x22b0
(dbx) quit
lindy[5]> ^D
script done on Wed Jun  8 14:31:35 1988

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

Date:    8 Jun 1988 1722-EDT (Wednesday)
From:    Andy Wilcox <ajw at beach.cis.ufl.edu>
Subject: Problems with CDC EMD (368M) drives

I've got a particularly weird problem with these drives.  I've just hooked
one up to my xylogics in the normal way.  My system is a 3/160 running
3.4.  The drive formatted and verified with no problems.  It even works
fine for several hours at a time, but then...  these start creeping up,
usually causing a hard swap error, and thus a panic:

xy1b: write retry (operation timeout) -- blk #10656, abs blk #26976
xy1b: write retry (operation timeout) -- blk #10656, abs blk #26976
xy1b: write failed (operation timeout) -- blk #10656, abs blk #26976

A few other notes on this problem.  It's not always in the swap partition.
The drive is unit 1 on the xylogic 0 (I only have 1 controller).  If I run
'scan' from diag over whatever block is reported, it's fine.  The block
numbers are mostly random (ie.  few errors in lots of different places).
The drive works better if *un*terminated, could someone explain this to
me?  I use all the default values supplied by diag to format it, 'cept for
the number of cylinders.  The drive has 1217, I use 1212 with 2 spares
(and 3 empty -- they just wouldn't work), sun's default was 1147.  Is
there a terminator somewhere on my M2333 that I have to remove?  I
couldn't find one.  Sun came out and change controllers, but the problem
persists.  (Current controller is prom rev 'a' -- is this the current one?

If anybody has this drive working, I'd love to hear from you.

--Andy Wilcox
  (ajw at beach.cis.ufl.edu)

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

Date:    Wed, 8 Jun 88 15:39:16 PDT
From:    marcl at vax.3com.com (Marc Lavine)
Subject: Looking for parameters for using dump with QIC 24 format

I'm using SunOS 3.4 on a 3/160.  The st(4S) man page indicates that using
the rst8 device will allow me to access the tape drive in QIC 24 format.
I would like to find out what values to use for the dump parameters (c, d,
and s) to store as much as possible on a standard-length tape.

Thanks,
Marc Lavine

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

Date:    Wed, 8 Jun 88 14:19:48 EDT
From:    J.S.Singh at cive.ri.cmu.edu
Subject: Synchronous I/O Drivers?

We are looking to do some synchronous I/O (HDLC 38.4K Baud) with a sun
3/280.  Does anyone have I/O drivers for such communication?  Any
information about sources for such drivers would be much appreciated.

Jeff Singh
CMU Robotics Institute

(jsingh at cive.ri.cmu.edu)

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

Date:    8 Jun 88 08:13:27 GMT
From:    Hans van Staveren <mcvax!cs.vu.nl!sater at uunet.uu.net>
Subject: /etc/sm?

>From time to time files with names of local machines show up in /etc/sm
on a server, that isn't even very related to that machine.

Does anyone know what this /etc/sm directory is, and who or what creates
these files?

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

Date:    Wed, 08 Jun 88 13:10:14 PDT
From:    michaele at tektronix.tek.com
Subject: Converting pic to fig?

Now that I have fig running I would like to be able to use it to clean up
all my old files that are in pic format.

Does anyone have or know of some software that converts files in pic
format to fig1.4 format?

Thanks (please mail responses to me and I'll summarize)

Michael Edelman
Engineering Network Services
Tektronix, Inc.

michaele at tektronix.tek.com

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

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



More information about the Comp.sys.sun mailing list