Sun-Spots Digest, v6n98
William LeFebvre
Sun-Spots-Request at RICE.EDU
Thu May 26 03:23:52 AEST 1988
SUN-SPOTS DIGEST Wednesday, 25 May 1988 Volume 6 : Issue 98
Today's Topics:
Re: curious behaviour of read() on devices
Re: A SunView Interrupt Button
Re: Sun Common Lisp and FPA don't work together
Re: 8mm back-up error checking
Re: Shared memory references
Symbollic Link list in 4.0
patches for clock loosing 29/30 days
Label your VT100 tool
Proxy ARP
compiling cmdtool
Problems with NFS/IP fragmentation on Sun-4?
Bad Disk Reads Not Noticed?
Opinions about ArborText preview versus VorTeX dvitool?
Sun manual folder labels?
Pictex a hog?
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, 13 May 88 20:54:54 CDT
From: texsun!convex!jthomp at sun.com (Jim "Cookie" Thompson)
Subject: Re: curious behaviour of read() on devices
Reference: v6n82
Mario Wolczko is disturbed by the fact that a read on a raw disk will
return more than requested. This is, indeed, a feature, and documented as
such in the manual. To wit:
In raw I/O counts should be a multiple of 512 bytes (a disk
sector). Likewise seek(2) calls should specify a multiple
of 512 bytes.
(from 'man 4 xy')
Jim Thompson Convex Computer Corporation
(214) 952-0536 701 N. Plano Road
"panic: getfs: bad magic" Richardson, Texas 75081
{uiucdcs,ihnp4,sun,allegra,harvard,killer,usenix}!convex!jthomp
------------------------------
Date: Sat, 21 May 88 15:31:33 PDT
From: fxgrp!tigger!jwm at ames.arc.nasa.gov (Jeff Mc Carrell)
Subject: Re: A SunView Interrupt Button
> From: csrobe at icase.arpa (Charles S. Roberson)
> Subject: A SunView Interrupt Button (any suggestions)
> My question is this, is there some way that I can define an INTERRUPT
> button that when depressed takes control from the rogue routine and
> returns it to the window_manager?
See the SunView Programmer's Guide, Revision A of 15 Oct 1986, chapter 6
"Handling Input", subsection "Stop Event" for the relevant discussion. A
suntools "interrupt" key is already defined; all you have to do is set up
the SIGURG interrupt handler to set some globabl variable, and then check
that variable in any loop you wish to interrupt. It works just fine for
me.
Jeff McCarrell VorTeX Group, UC Berkeley.
jwm at renoir.Berkeley.EDU {ihnp4,seismo,decwrl}!ucbvax!jwm
------------------------------
Date: Thu, 19 May 88 20:33:54 PDT
From: alank at sun.com (Alan Kostinsky)
Subject: Re: Sun Common Lisp and FPA don't work together
Reference: v6n82
SCLisp 1.2 does give such errors when it runs on a machine with an FPA
installed. This problem has been fixed since Release 2.0 of Sun Common
Lisp (the current release is 2.1).
Alan Kostinsky
Sun S/W Support
------------------------------
Date: Mon, 23 May 88 08:52:59 BST
From: Operator <mcvax!nw.stl.stc.co.uk!root at uunet.uu.net>
Subject: Re: 8mm back-up error checking
Having read Sam Nuwayser's comments regarding read-after-write error
checking on 8mm video back-ups, and being interested myself in this
medium, I was a little concerned. However I have just received some info
from Michael Couch of PBI which puts my mind at rest. I have pasted a
couple of lines below.
> The EXB-8200 uses the helical scan recording technique with full read-after-
> write error correction (ECC) and error recovery procedures. The peak
> data transfer rate is 1.5 MBytes per second, and the sustained data transfer
> rate is 246 KBytes per second. The non-recoverable error rate is less than
> 1 hard error per 10e13 bits read...
By the way it is good to see an advertiser (in Sun Technology) giving an
e-mail address.
Usual disclaimer: I have no connection with etc. etc.
Howard Pelling (admin at nw.stl.stc.co.uk, +44 782 662212 x235)
System Manager, STC Technology Ltd (North West)
------------------------------
Date: Mon, 23 May 88 10:40:19 EDT
From: clapper at nadc.arpa (Brian M. Clapper)
Subject: Re: Shared memory references
> Does anyone have some good references for using the System V shared memory
> stuff.
Try _Advanced_UNIX_Programming_ by Marc J. Rochkind (Prentice-Hall, 1985).
It not only describes how to use the System V Inter-Process Communication
(IPC) facilities, including shared memory, but outlines various pitfalls
one can expect when using them. It's also an excellent overall reference
book.
Brian M. Clapper ARPA: clapper at nadc.ARPA
Code 7031 UUCP: ...!harvard!clapper at nadc.ARPA
Naval Air Development Center
Street and Jacksonville Roads Phone: (215) 441-2118
Warminster, PA 18974 AUTOVON: 441-2118
------------------------------
Date: 19 May 88 22:07:09 GMT
From: tekbspa!tss!joe at uunet.uu.net (Joe Angelo)
Subject: Symbollic Link list in 4.0
The following is a list of symbollic links on 4.0 generated with the
command line:
find / -type l -exec ls -ld {} \; | \
awk '{ NF >= 2 { print $(NF-2), $(NF-1), $NF } } '
If you ask me, Sun forgot one: /etc/yp -> /var/yp
[[ Ths list is about 43 kilobytes long---far too long for a digest. I was
going to try to generate a bried synopsis, but it's just too long. The
complete message is stored as "sun-spots/4.0-symlinks" and is 43189 bytes
long. It can be retrieved via anonymous FTP from the host
"titan.rice.edu" or via the archive server with the request
"send sun-spots 4.0-symlinks". For more information about the archive
server, send a mail message containing the word "help" to the address
"archive-server at rice.edu". --wnl ]]
Joe Angelo -- Senior Systems Engineer/Systems Manager
at Teknekron Software Systems, Palo Alto 415-325-1025
uunet!tekbspa!joe -OR- tekbspa!joe at uunet.uu.net
------------------------------
Date: Thu, 19 May 88 09:31:26 EDT
From: Peter Marshall <peter at hadrian.uwo.ca>
Subject: patches for clock loosing 29/30 days
These are the patches that I got from sun. These may be the same as those
published in SunSpots v6n1, but I have not been able to get that number to
verify, and since I promised (and have been unable to contact some of the
sites that asked me to send them out) I am sending them to the list. I
have installed these on our systems here and it appears to have solved the
problem with no side effects. Note that we were not seeing the problems
mentioned in the BUG summary, but the fix seems to get a lot of Clock
related bugs.
Peter Marshall, Data Comm. Manager
CCS, U. of Western Ontario, London, Canada N6A 5B7
(519)661-2151x6032
pm at uwovax (BITNET); peter at julian.uucp; peter.marshall at uwo.ca
The five different versions of the patch are the following:
Machine Type Operating System level
------------ ----------------------
I. Sun 3 3.0
II. Sun 3 3.2 - 3.5
III. Sun 3 4.0 alpha5, 4.0beta0, 4.0beta1
IV. Sun 4 SYS4-3.2FCS
V. Sun 4 4.0 Alpha5, 4.0beta0, 4.0beta1
[[ This is more complete than the one posted in v6n1. The patches listed
as III and V above are new, but the other three are basically the same. I
suspect that the real version of 4.0 does not have this bug, and that many
people with alpha and beta copies of 4.0 will soon be switching over to
the real version. Nonetheless, if you still want the patches, they are
stored in the file "sun-spots/tod-patch". It can be retrieved via
anonymous FTP from the host "titan.rice.edu" or via the archive server
with the request "send sun-spots tod-patch". For more information about
the archive server, send a mail message containing the word "help" to the
address "archive-server at rice.edu". --wnl ]]
------------------------------
Date: Mon, 23 May 88 09:13:19 EDT
From: gfr%wolfgang at gateway.mitre.org (Glenn Roberts)
Subject: Label your VT100 tool
I use Sun's VT100tool to communicate with a number of VAX systems in
house, and often have several tools on my screen at once connected to
several vaxen. To help me keep track of which system is on the other end
of each of these tools, I place the following in my LOGIN.COM on each VAX
account I have:
$SET TERM/INQUIRE
$!
$! The following sets window identifiers on Sun VT100 tool
$!
$x=f$getdvi(f$getjpi("","TERMINAL"),"DEVTYPE")
$y=f$trnlnm("SYS$NODE")
$if x.ne.96 then $goto notasun
$write sys$output "<ESC>]l''y'<ESC>\<ESC>]L''y'<ESC>\"
$notasun:
This has the effect of labeling each VT100tool with the DECnet node name
of the VAX system on the other end. Device type 96 indicates a VT100, so
if you ever log in from a real VT100 instead of the Sun, you'll see some
garbage on your screen about the node name. There are other neat things
you can do with these escape sequences such as change the icon,
automatically close the window on logout, etc
------------------------------
Date: Mon, 23 May 88 11:19:37 EDT
From: bob at allosaur.cis.ohio-state.edu (Bob Sutterfield)
Subject: Proxy ARP
We're running a subnetted network that includes hosts that don't do
subnets, like a DECsystem-2060, an Encore MultiMax, a BBN Butterfly, an
Intel Hypercube, some AT&T 3B2/400s, and probably others I can't think of
now. I'm not sure whether our 3/280's brain transplant to a 4/280 has
been completed yet, but it will be running the 3.2-ish SunOS for a while,
thereby leaving it out of the real subnetting world, too.
The trick is to use a proxy ARP daemon that responds to ARP requests from
the dumb hosts, for things off their subnet, with the Ethernet address of
the gateway to the subnet containing the thing being ARPed for. It all
works just fine - once the gateway is in the dumb host's ARP cache,
packets fly through the gateway with as much performance as those between
hosts that know about subnetting.
We got the proxyd that runs on our Suns from Barry Shein at Boston
University - thanks, Barry!
Bob Sutterfield, Department of Computer and Information Science
The Ohio State University; 2036 Neil Ave. Columbus OH USA 43210-1277
bob at cis.ohio-state.edu or ...!att!osu-cis!bob
------------------------------
Date: Mon, 23 May 88 08:46:39 EDT
From: gfr%wolfgang at gateway.mitre.org (Glenn Roberts)
Subject: compiling cmdtool
Reference: v6n94
> Does anyone know how to create a tool containing a cmdtool-type terminal
> emulator? It should obviously be possible to use the same sort of code
> the cmdtool does, but in 3.5 /usr/src/sun/suntools/cmdtool.c doesn't even
> compile.
Don't forget that cmdtool was not intended to be a standalone utility, but
is rather part of /usr/bin/suntools, which also encompasses mailtool,
textedit, shelltool, get_selection, clocktool, perfmeter, and others.
Suntools decides which tool you want by looking at argv[0]. These are
compiled as one unit in order to save disk space (I wonder if SunOS 4.0's
shared libraries will make these separate utilities again - anyone know?)
Glenn Roberts, MITRE Corp., McLean VA
gfr%wolfgang at gateway.mitre.org
------------------------------
Date: Mon, 23 May 88 09:35:57 EDT
From: ksr!dudek at harvard.harvard.edu
Subject: Problems with NFS/IP fragmentation on Sun-4?
We are having intermittent problems running NFS from/to/through Sun-4's
which seems to be related to IP fragmentation. More specifically, NFS
requests to Sun-4's (or through Sun-4 gateways) which result in a single
UDP packet fragmented across several IP packets intermittently hang with
"nfs server not responding" messages. Etherfind shows the request and a
response, followed by a minute or so of silence, then another request and
response - looks like a retransmission to me. Throttling the rsize and
wsize parameters on the NFS mounts to 1024 and rebooting causes the
problem to go away, but presumably at the small expense of performance.
Has anyone else seen (or solved) this problem? Many thanks in advance.
We are running Sun 0S Sys4-3.2 on our Sun-4's and Sun OS 3.5 on our Sun-3's.
Glen Dudek
dudek at ksr.com, or ksr!dudek at harvard.harvard.edu
------------------------------
Date: Wed, 18 May 88 11:02:12 EDT
From: umix!lokkur!scs at rutgers.edu (Steve Simmons)
Subject: Bad Disk Reads Not Noticed?
Got an interesting one. We have what appears to be a bad disk block which
is not reported as bad by either the disk, the controller, or the OS.
Here's the supporting data:
We have a file which, when read, has bad data always at the same spot.
The nature of the bad data varies over time, usually appearing to be some
other random block from the disk. On the rare occasions when the data can
be recognised, it was always either some other recently accessed file or
another part of the same file.
Running a checksum on the file reported the wrong checksum about 2/3 of
the time. Repeatedly running a checksum (in a shell loop) repeatedly got
the *same* checksum. Doing this on different workstations got different
(wrong) checksums. If looping, the checksum was always the same. Stop
the loop, do something to cause a lot of disk activity, retry the sum, and
it comes up different.
The "bad" data is always in the same place, about 8K bytes into the file.
Move the offending file to a different name, create a new copy of the same
file. The new copy is fine. The original still has the same bad
problems.
The original configuration was a Xylogics 451 controller, a Fuji2361, and
a Fuji 2351. The bad file was one the 2351. We moved the 2351 to a
separate Xy450 controller, no change in performance.
The /usr/adm/messages file shows there has *never* been a bad block report
on the disk for the life of the messages file, about 3 months. This is
contrary to our experience with similar configurations.
Before splitting the disks between two controllers, operators had level 0
dumps of the 2351 fail consistantly at the same spot with the message
"spurious level 7 interrupt on xy0" (not xy1). Now that they're split
there are no more errors.
Hypothesis:
There is a bad block on the disk (or a parallel failure in the disk
electronics) which is not being properly detected as bad. The odd
performance with checksumming leads me to believe that the bad block gets
into the buffer cache, causing repeatability of the bad checksum as long
as it stays in the cache. Force the cache to flush, and you get a
different sum next time through.
Has anyone heard of such a thing? We've reported it to Sun, but we're on
software maintainance only. Our regular disk repair company hasn't seen
it before. The workarounds I'm going to try are (1) spare the block out
anyway (assuming I can identify it), and (2) have the electronics in the
drive replaced.
Steve Simmons
Schlumberger CAD/CAM
scs at applga.uucp
------------------------------
Date: Sun, 22 May 88 21:27:11 PDT
From: langdon at lll-lcc.llnl.gov (Bruce Langdon)
Subject: Opinions about ArborText preview versus VorTeX dvitool?
We happily use ArborText's preview for TeX, but I read here recently that
"dvitool is very nice". Could someone who know both make any comments?
Bruce Langdon L-472 langdon at lll-lcc.llnl.gov
Physics Department 339650%d at nmfecc.arpa
Lawrence Livermore National Laboratory
Livermore, CA 94550 (415) 422-5444
UUCP: ..{ihnp4,qantel,ucdavis,pyramid,harvard,topaz}!lll-lcc!langdon
------------------------------
Date: Mon, 23 May 88 10:23:55 BST
From: Ida <ida at EAGLE.WARWICK.AC.UK>
Subject: Sun manual folder labels?
Does anyone have a copy of the (postscript) file which prints labels for
the edges of Sun manual folder? Can someone send it to me?
Thanks.. Russ.
Russ Lomax. Department of Engineering
russ at uk.ac.warwick.eagle University of Warwick,
[+44|0]203 523523 ext 2115 Coventry, CV4 7AL, England
------------------------------
Date: 21 May 88 14:32:01 GMT
From: mds at bu-cs.bu.edu (Michael Siegel)
Subject: Pictex a hog?
So I have worked with this Pictex stuff a little longer seems like LATEX
processes things like line and text just fine. But when I try to write any
object with a curved surface I run out of memory. I this a common
problem...if so are there solutions besides never draw a curved object?
---Michael Siegel
[[ First, this is not a good topic for sun-spots. It is related only
because one can use Fig (a suntool) and a fig to pictex utility to
generate pictex. Second (and the answer you want), pictex is known for
really chewing up TeX's memory. So, yes this is a common problem. You
need to use a "fat TeX": either TeX in C with the memory cranked way up
or the "BIG" or "BIGG" versions of Mondaro's Common TeX. --wnl ]]
------------------------------
End of SUN-Spots Digest
***********************
More information about the Comp.sys.sun
mailing list