Sun-Spots-Request@Rice.edu (William LeFebvre) (09/20/88)
SUN-SPOTS DIGEST Monday, 19 September 1988 Volume 6 : Issue 229
Today's Topics:
Gilbert the Giant
Re: Old Sunspots question: SPE
Re: Problems with fork() and wait()
Re: mail between uucp-smtp-uucp users
Re: ID Prom
Re: uucico at 19200 baud
Re: Can someone give me a hand with color canvases
Scsi vs. SunOS 4.0
Shared Memory vs. malloc()
'netstat -I ie0' and 'netstat -i' fails
slip problem
curses keypad() under Berkeley style curses?
RTC's for SUN ?
3/60 memory: Parity Systems?
Music font for Sun?
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: Mon, 19 Sep 88 17:42:26 CDT
From: William LeFebvre <phil@Rice.edu>
Subject: Gilbert the Giant
Hurricant Gilbert has spared the upper Texas coast, but its threat did not
go unnoticed by residents of Houston and Houston's southeastern suburbs.
For awhile, it looked like I was going to spend the weekend in Austin,
Texas, but I waited here instead. Nonetheless, my life was temporarily
disrupted as were the computers here at Rice. So I am a little behind in
handling sun-spots messages. Fortunately, there are not many backed up in
the queue (there are quite a few programs and patches waiting to go out---
I'll get around to them as time permits). Sorry about the little setback.
Houston and Rice are still on the map and Sun-Spots should be resuming its
normal schedule this week.
William LeFebvre
------------------------------
Date: Tue, 13 Sep 88 09:35:48 -0400
From: Henry B.J. Krempel <krempel@pacrat.npac.syr.edu>
Subject: Re: Old Sunspots question: SPE
I've been catching up on my sunspots reading and came across am question
you had about SPE.
I've been looking closely at SPE and Franz' Allegro Common Lisp, and I've
come to a few conclusions:
Lucid and SPE are expensive, and site licenses aren't
available if you are looking for a bunch of machines.
Franz is much cheaper, and has attractive site licenses.
On the up side:
Franz has a number of interesting features recently
released: a GNU-emacs interface that tightly couples
the editor and the listener (a' la Lisp Machine), M-.
is in there.
A TCP package that allows remote lisp'ing, you can
run it through a socket somehow.
A windowing package (Common Windows) under NeWS.
The GNU stuff is available (ftp from ucbarpa, I
think) so you can look at that before buying.
On the down side:
Franz is purported to be slightly slower than Lucid.
I get the impression that Franz is a smaller more aggressive company, more
likely to keep up with changes than Sun/Lucid. Anyway, we haven't bought
either yet, but I think I will recommend Franz.
Henry B. J. Krempel <krempel@pacrat.npac.syr.edu>
Northeast Parallel Architectures Center (NPAC)
Syracuse University
250 Machinery Hall
Syracuse, N.Y. 13244
------------------------------
Date: Tue, 13 Sep 88 09:03:01 EDT
From: chuck@morgan.com
Subject: Re: Problems with fork() and wait()
If several child processes have become zombies by the time wait() is
called they will all disappear from the process table. The status
information you get back will be for the last of the children that died.
This has caused problems for people who use 2 popen() calls
simultaneously. This is because pclose() does a wait() for the child
process. If both child processes have terminated before the first
pclose() the 2nd pclose() will hang because there are no more children to
wait for.
Chuck Ocheret
Morgan Stanley
(212) 703-4474
------------------------------
Date: Tue, 13 Sep 88 11:28:30 PDT
From: ultra!shj@ames.arc.nasa.gov (Steve Jay)
Subject: Re: mail between uucp-smtp-uucp users
In v6n206, Tahsin Choudhuri (choudhur@umn-cs.cs.umn.edu) asks how to
address mail from A to E when they are connected:
A.host -- uucp -- B.host -- uucp -- C.host -- SMTP -- D.host -- uucp -- E.host
wnl gave his suggestion (B!C!E!ue@D), which I think will work. However, I
think you can also use uucp only type addresses: "B!C!D!E!ue". That is,
I'm pretty sure that the sendmail on C will do the right thing with
"D!...", even though it has an SMPT connection to D. On my own local
ethernet, I can send from any Sun to any other Sun using uucp style
addresses.
The uucp style address might be easier to use, rather than trying to
figure out the right combination of !'s and @'s.
Note that I haven't actually tried this beyond my own local ethernet. I'd
be curious to hear if this really works in the configuration shown above.
Steve Jay domain: shj@ultra.com
Ultra Network Technologies Internet: ultra!shj@ames.arc.nasa.gov
101 Daggett Drive uucp: ...ames!ultra!shj
San Jose, CA 95134
408-922-0100
------------------------------
Date: Tue, 13 Sep 1988 17:27:05 CDT
From: King Ables <ables@mcc.com>
Subject: Re: ID Prom
There was an article in a Sun Technical Support Bulletin once that talked
about it. Unfortunately, I don't have the reference, only the info:
1st digit is machine type:
0 = sun 2
1 = sun 3
2 = sun 4
2nd digit is specific machine type:
1 = sun 2 with multibus, sun 3/160, sun 4/260
2 = sun 2 with VME bus, sun 3/50
3 = sun 3/260
4 = sun 3/110
-king
ARPA: ables@mcc.com
UUCP: {gatech,nbires,seismo,ucb-vax}!cs.utexas.edu!pp!ables
------------------------------
Date: Wed, 14 Sep 88 09:29:04 EDT
From: Sergei A. Gourevitch <asg@space.mit.edu>
Subject: Re: uucico at 19200 baud
I got this from Mike Ballard at Telebit:
To use uucico at 19200, you must modify the Sun version using "adb".
We will use the 4800 baud entry and replace it with 19200.
cd /usr/lib/uucp
cp uucico uucico.orig
adb -w uucico
20000?L 0t4800
--- at this point you'll get output something like:
20a0c:
--- so enter:
?DD
--- it will respond with ADDRESS:DATA like:
20a0c: 4800 12
--- so enter:
?W 0t19200 0t14
--- now type ^D. This completes the uucico modification.
NOTE: Don't forget to check the permissions and ownership of uucico.orig
to be the same as uucico.
MODIFY /usr/lib/uucp/uucico TO RUN 19200 BPS:
------------------------------
Date: 14 Sep 88 17:21:46 GMT
From: mkhaw@teknowledge-vaxc.arpa (Mike Khaw)
Subject: Re: Can someone give me a hand with color canvases
Reference: v6n227
Ron Hitchens said:
> In V6n210 Anne Becker (anne@cvl.umd.edu) described a problem with retained
> color canvases not repainting properly. The solution to this is quite
> simple, once you understand what's going on.
...
> You're stumbling across a mis-feature of SunView, namely the rather goofy
> method it uses to determine how deep to make the backing memory pixrect
> for a retained pixwin. So far as I know, this rule was undocumented until
> the 4.0 SunView manual. Luckily, someone finally realized this
> information may be useful and the following paragraphs appear on page 72
> of the 4.0 SunView Programmer's Guide:
Actually, it's documented in my 3.2 SunView Programmer's Guide (Revision A
of 15 October 1986), Chapter 5 - Canvases, Section 5.8 Color in Canvases,
subsection "Color in Retained Canvases", page 69; but not drawn attention
to as prominently as it needs to be. I quote:
If the canvas is retained, then the colormap segment must
be set _before_ CANVAS_RETAINED is set to TRUE. This is
because the canvas package will determine the depth of the
backing pixrect based on [the] depth of the colormap segment
defined for WIN_PIXWIN. (If the colormap segment depth is
greater than two, then the full depth of the display will be
used. Otherwise, the backing pixrect depth will be set to
one.)
Since the depth of the backing pixrect is determined when the
canvas is created, you must create the canvas with CANVAS_RETAINED
FALSE, then set the colormap segment, then set CANVAS_RETAINED
to TRUE.
Mike Khaw
--
internet: mkhaw@teknowledge.arpa
uucp: {uunet|sun|ucbvax|decwrl|uw-beaver}!mkhaw%teknowledge.arpa
hardcopy: Teknowledge Inc, 1850 Embarcadero Rd, POB 10119, Palo Alto, CA 94303
[[ Thanks also to Brian Raymor <east!ronin!brian@sun.com> for pointing
this out. --wnl ]]
------------------------------
Date: Tue, 13 Sep 88 12:24:20 CDT
From: natinst!brian@cs.utexas.edu (Brian H. Powell)
Subject: Scsi vs. SunOS 4.0
I sent this to hotline@sun.com a few days ago. They insist that it's a
hardware problem. Since I've found several serious bugs in SunOS 4.0 so
far, I'm hesitant to believe them when they say it isn't the new OS. I'm
curious if anybody else has had similar problems.
Before we installed SunOS 4.0 on our Sun 3/160, when we ran SunOS 3.2, our
cartridge tape drive worked just fine.
We recently installed SunOS 4.0. We are now unable to reliably read QIC
tapes. (For example, the Serial I/O patches for SunOS 4.0.) I tried
cleaning the heads, but that didn't seem to help. Since the error I get
is a scsi bus error, I think it's probably not the drive, but a bug in the
SunOS. (Is there any reliable way of figuring out if it's the drive or
the controller?)
This is one of the messages that appeared on the console (and in the log.)
Sep 7 10:08:49 natinst vmunix: sc0: scsi bus error. icr 714f resid 65534
Sep 7 10:08:49 natinst vmunix: sc0: resetting scsi bus
We have lots of cards in our Sun 3/160, so perhaps the scsi driver just
can't cope with a busy vmebus.
Brian H. Powell National Instruments Corp.
brian@natinst.uucp 12109 Technology Blvd.
cs.utexas.edu!natinst!brian Austin, Texas 78727-6204
AppleLink:D0351 (512) 250-9119 x832
------------------------------
Date: Wed, 14 Sep 88 09:17:22 EDT
From: chuck@morgan.com
Subject: Shared Memory vs. malloc()
Various descriptions of the System V shared memory calls state that shared
memory should not be attached during invocations of malloc(), realloc(),
etc... This is because malloc() does not know about the shared memory and
may begin to overlap with it. I cannot find any definite warning of this
type in the SUN documentation. The simple fix is to encapsulate malloc()
type calls so that shared memory is detached and then reattached, keeping
track of the shared memory start address in an extern variable. This is
an unattractive solution because of the overhead of attaching and
detaching and because shared memory may be at a different address each
time it is attached. It would be convenient to be able to maintain
pointers to absolute locations within shared memory (for certain
applications) rather than maintaing offsets within shared memory for them.
In an attempt to overcome the conflict with malloc(), I attempted to
valloc() a chunk of memory the size of the desired shared memory segment
and them perform a shmat() at the valloc'd address. If this were to work,
then malloc() calls would never stomp on the shared memory since it would
think of that memory as already in use. However, shmat() returns with
error EINVAL (invalid address).
What is the best solution to this problem (mapped files with mmap?).
Chuck Ocheret
Morgan Stanley
(212) 703-4474
------------------------------
Date: Wed, 14 Sep 88 10:41:58 EDT
From: ehrlich@shire.cs.psu.edu (Dan Ehrlich)
Subject: 'netstat -I ie0' and 'netstat -i' fails
Reply-To: bugs@blitz.cs.psu.edu
Machine Type: Sun 4/260S
O/S Version: SunOS 4.0
Organization: Computer Science Department
The Pennsylvalia State University
333 Whitmore Laboratory
University Park, PA 16802
Phone Number: +1 814 865 9723
Description:
Invoking 'netstat -I ie0' with out specifying a redisplay
interval, or 'netstat -i' generates no output other than the
column headers. 'netstat -I ie0 5' works as expected.
Repeat-By:
% netstat -I ie0 # or
% netstat -i
------------------------------
Date: Wed, 14 Sep 88 09:58:14 EDT
From: Sergei A. Gourevitch <asg@space.mit.edu>
Subject: slip problem
I haven't seen this problem mentioned in sun-spots.
I'm running slip between a diskless 3/60 running 3.4 and a standalone 3/60
running 3.5. The standalone is not part of any network while the diskless
one is, obviously, on our local Ethernet.
Each machine has only one modem (Telebit trailblazer plus) and they are
not dedicated; I use them for tip,uucp, kermit etc. as well as slip. My
problem comes when ending a slip session: Even though I kill off the
slattach (or the equivalent) and mark the sl interface "down" using
ifconfig; some rogue process(es) start using up resources at a steadily
increasing rate until the machine is hung. I've seen this mainly on the
newtworked 3.4 machine. The only clue I have is that if I can get "ps
laxw" to actually run and complete, I find that (biod),rwhod and maybe
some other processes are all hanging in a non-interruptable (negative
priority) waiting-on-I/O ("D") state.
The only thing I've been able to do is to make it a rule to reboot after a
slip session. This is not satisfactory. Any ideas out there?
Sergei Gourevitch
Center for Space Research
MIT
(617) 253-8208
asg@space.mit.edu
{seismo,mit-eddie}!space.mit.edu!asg
------------------------------
Date: Wed, 14 Sep 88 09:32:38 EDT
From: chuck@morgan.com
Subject: curses keypad() under Berkeley style curses?
System V curses provides a function keypad() which enables input
canonicalization of special keys like function keys, arrow keys, etc..
When keypad mode is in effect, the function getch() returns special
integer codes for these keys. Is there equivalent high level processing
with the Berkeley curses (3X) provided by SUN?
Until such processing is provided it seems that the only solution is to
write your own runtime finite automata compiler and parse the keystrokes
yourself. This is not too hard but it seems a common enough problem for
curses users that something should be provided already.
In addition, since I am already using curses, I am using getcap() to
obtain the character sequences for special keys. However, getcap() seems
to corrupt curses termcap information. Therefore, I have found it
necessary to do something like the following:
initscr(); /* Initialize curses */
ku = getcap("ku"); /* Get termcap capabilities (corrupts curses) */
:
kr = getcap("kr");
endwin(); /* Terminate corrupted curses */
initscr(); /* Reinitialize uncorrupted curses */
Am I doing something wrong or is this a curses bug?
Chuck Ocheret
Morgan Stanley
(212) 703-4474
chuck@morgan.com
------------------------------
Date: Tue, 13 Sep 88 16:29:58 EDT
From: dan@rna.rockefeller.edu (Dan Ts'o)
Subject: RTC's for SUN ?
Does anyone have experience with a Real Time Clock for Sun's (3 and 4) ?
I'm looking for the functional equivalent of the DEC Qbus KWV-11.
Basically, it should have an internal oscillator that can be programmed
from 1-Mhz down to 1Hz, a counter register that can be preloaded with a
value, at least one Schmitt trigger input that can except external events,
modes to allow the counter register to count either external events or
clock/oscillator ticks and interrupts available from either external
events or counter register equal zero.
Of course, a driver would be nice, too.
BTW, is there a system clock on Sun's that has a consistent frequency from
model to model ?
Please reply by email. Thanks.
Cheers,
Dan Ts'o 212-570-7671
Dept. Neurobiology dan@rna.rockefeller.edu
Rockefeller Univ. ...cmcl2!rna!dan
1230 York Ave. rna!dan@nyu.arpa
NY, NY 10021 tso@rockefeller.arpa
------------------------------
Date: 14 Sep 88 8:37 -0400
From: naren <naren@sce.carleton.ca>
Subject: 3/60 memory: Parity Systems?
We have a few of the 3/60s with Clearpoint memory. We are considering
buying some more for the new 3/60s and have found that Parity Systems
memory are a lot cheaper then the Clearpoint memory. Does anyone have any
experince with Parity (or Helios) memory? Thanks.
Narendra Mehta,
Systems & Computer Eng. Department, Carleton University, Ottawa, Canada
Domain: naren@sce.carleton.ca
UUCP: {allegra,decvax,ihnp4,linus,utzoo}!watmath!sce!naren
ARPA: naren%sce.carleton.ca@relay.ubc.ca
------------------------------
Date: Wed, 14 Sep 88 10:59:16 EDT
From: tynor@pyr.gatech.edu (Steve Tynor)
Subject: Music font for Sun?
Can anyone help me find a 'music' (i.e. notes, rests, clefs) screen font
for a Sun? Any pointer will be greatly appreciated.
[[ The original Hershey vector font set has some music characters in it
(the clefs, sharp, double sharp, flat, notes, etc.). --wnl ]]
Steve Tynor
tynor@gitpyr.gatech.edu
------------------------------
End of SUN-Spots Digest
***********************