Sun-Spots Digest, v6n50
William LeFebvre
Sun-Spots-Request at RICE.EDU
Tue Apr 12 06:57:03 AEST 1988
SUN-SPOTS DIGEST Sunday, 10 April 1988 Volume 6 : Issue 50
Today's Topics:
Re: Changes in user mail interface (2)
backups in multiuser mode
Our experience with 2.3 gbytes cartrige storage system
Crashes due to timeouts
NEC Silentwriter LC-890 "RS-232"
Help needed with SunView background proc's
le0: ENP/STP bits
SPARC User Manual?
Experience with 56Kbps Interfaces?
How to set-up the mail environement?
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: 31 Mar 88 21:00:22 GMT
From: mkhaw at teknowledge-vaxc.arpa (Mike Khaw)
Subject: Re: Changes in user mail interface (1)
Reference: v6n37
woods at handies.ucar.edu (Greg Woods) writes:
> ...Sun has decided to reverse the sense of the 'R' and 'r' commands
> in /usr/ucb/Mail...
1) It's consistent with the change in 4.3bsd's mail user-agent.
2) 4.3bsd probably changed it because naive users tend to type "r" when
meaning to reply to just the sender, then get all kinds of flames from
everyone else on the list who didn't care to get their maildrop
cluttered with irrelevant mail. I don't recall offhand what it is,
but I think 4.3bsd mail lets you revert to the old sense of "R" vs.
"r" via an option in your .mailrc -- with any luck, SunOS does the same.
Mike Khaw
internet: mkhaw at teknowledge-vaxc.arpa
usenet: {uunet|sun|ucbvax|decwrl|uw-beaver}!mkhaw%teknowledge-vaxc.arpa
USnail: Teknowledge Inc, 1850 Embarcadero Rd, POB 10119, Palo Alto, CA 94303
------------------------------
Date: Fri, 1 Apr 88 22:45:20 EST
From: Chris Torek <chris at mimsy.umd.edu>
Subject: Re: Changes in user mail interface (2)
Reference: v6n37
woods at handies.ucar.edu (Greg Woods) writes:
>...Sun has decided to reverse the sense of the 'R' and 'r' commands...
Not only did they do this, they did it in what can only be described as a
stupid way (although it could have been worse). For years ucbmail has had
a runtime configuration option to control this; the option can be set
globally for any machine in /usr/lib/Mail.rc, and locally for any user in
~/.mailrc.
Which one you believe is `right' (or is that `Right'? :-) ) amounts to a
religious argument. It has, however, always been configurable. On 4BSD
systems, if you put the command
set Replyall
in /usr/lib/Mail.rc or ~/.mailrc, that reverses the sense of r/R (so that
you get the behaviour ascribed to the Sun above). That is, Replyall means
`R'=>all and `r'=>sender. If your system administrator has put this in
/usr/lib/Mail.rc and you personally worship the opposite convention, you
simply put the command
unset Replyall
in your own .mailrc. This variable is in fact documented in mail(1), at
least in 4.3BSD.
Now, when Sun changed Mail, they did it not by putting a
set Replyall
in the distributed /usr/lib/Mail.rc. Instead, they changed the source so
that the default is `r'=>sender, `R'=>all. They *also* changed the
variable from `Replyall' to `replyall'. Now, if you `set replyall', you
get the 4BSD behaviour; to switch to the Sun behaviour you must `unset
replyall'.
Fortunately, Mail allows any name to be set or unset, regardless of
whether it is used internally or currently set. Hence if you wish to
guarantee the 4BSD behaviour, put the commands
set replyall
unset Replyall
in /usr/lib/Mail.rc or ~/.mailrc. If you wish to guarantee the present
SunOS behaviour, use instead the commands
set Replyall
unset replyall
While you are at it, you might add a comment to help the next
administrator figure out why all the foolery:
# set replyall makes Sun r=>all, R=>sender;
# unset Replyall makes 4BSD r=>all, R=>sender.
If no one at Sun had noticed the Replyall variable, I might forgive them
this mistake---the option is somewhat obscure---but that they changed the
name shows that they knew exactly what this did. Of course, had they not
changed the name, .mailrc files would be machine-dependent, so good did
come of it after all. The best solution would be for Sun to back this
change out of future releases, and instead put a `set Replyall' in the
distributed versions of /usr/lib/Mail.rc.
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163)
Domain: chris at mimsy.umd.edu Path: uunet!mimsy!chris
[[ Soon everyone will be using their own workstations complete with a much
better (mouse oriented) interface to the mail system, and ucbmail will
become obsolete and never used. Well, I can dream, can't I? --wnl ]]
------------------------------
Date: Wed, 30 Mar 88 12:50:44 EST
From: warsaw at cme-durer.arpa (Barry A. Warsaw)
Subject: backups in multiuser mode
> I wondering if there is a way to backup Sun systems without having to goto
> single-user mode, as this causes background processes (long cpu intensive
> jobs) to die.
>
> Does anyone have a solution to this or recommendations ?
We've been using a software package called Ubackup from a Virginia company
called Unitech. Among other things, it allows you to do backups in
multiuser mode with very little impact on the rest of the system.
Essentially you create a 'backup' script that outlines which files you
want to backup. Ubackup then backgrounds the job and returns control to
the operator.
Ubackup also does things like automatic media control, verified dumps,
etc. Its a very nice system although I haven't really had time to play
with some of the more robust features. Its not terribly expensive either
and would be worth looking into.
My only complaint is that they use their own ascii-type menu system which
doesn't use termcaps and is somewhat bizzare. You can control ubackup
from the command line as well.
The biggest plus is that the people there are friendly and very willing to
help.
For more information:
Unitech Software, Inc.
1800 Alexander Bell Drive, Suite 101
Reston, Virginia 22091
(703) 264-3301
Barry
Disclaimer: I have no connection with Unitech except as a user of their
software. My opinion does not in anyway imply an endorsement of the
product by my employer. [[...or by the moderator or his employer, or
anyone else for that matter. --wnl ]]
------------------------------
Date: Wed Mar 30 13:50:11 1988
From: portal!cup.portal.com!Clement_-_Vaillancourt at sun.com
Subject: Our experience with 2.3 gbytes cartrige storage system
We just installed a Delta Microsystems SS-200T tape drive on our Sun 3/280
SCSI interface. It use a 8 mm video cartrige from Sony. We used the
manual installation procedure and it run very well! It does support tar,
dump and rdump. With dump from a local disk we saved 280 mbytes in 40
minutes. It is even a bit faster than the big 9 tracks tape at 6250 bpi.
The restore works the same way... Very good product!
Clement Vaillancourt,
Institut de Recherche d'Hydro-Quebec,
1800 Montee Ste-Julie,
Varennes, P. Quebec, Canada.
UUCP: sun!cup.portal.com!clement_-_vaillancourt
clouso!ireqs3!vaillancourt
sun!sunlegende!amadeus!vaillan
Tel.: 514-652-8238
------------------------------
Date: Thu, 31 Mar 88 10:53:53 PST
From: richk at larry.cs.washington.edu (Richard Korry)
Subject: Crashes due to timeouts
Our Sun 3/280 running Sun 0S 3.3 has hardly ever crashed in 9 months of
use. But over the past 2 weeks it has gone down 3 times with the same
error. Here are snippets from the log messages:
-----------
rlogin:
trap address 0x8, pid 7811, pc = f01c85c, sr = 2008, stkfmt b, context 6
Bus Error Reg a0<INVALID,TIMEOUT>
data fault address b46dd774 faultc 0 faultb 0 dfault 1 rw 1 size 0 fcode 5
KERNEL MODE
page map 20000000
----------
sendmail:
trap address 0x8, pid 3641, pc = f01c85c, sr = 2008, stkfmt b, context 5
Bus Error Reg a0<INVALID,TIMEOUT>
data fault address d73d0e78 faultc 0 faultb 0 dfault 1 rw 1 size 0 fcode 5
KERNEL MODE
page map 20000000
---------------
sendmail:
trap address 0x8, pid 20662, pc = f01c85c, sr = 2008, stkfmt b, context 4
Bus Error Reg a0<INVALID,TIMEOUT>
data fault address c60cbfcc faultc 0 faultb 0 dfault 1 rw 1 size 0 fcode 5
KERNEL MODE
page map 20000000
I can send more info if anyone needs it. Is this old stuff or does anyone
have any ideas before I start rummaging through kernel sources... thanks
rich
------------------------------
Date: 31 Mar 88 9:47 -0800
From: David Harris <david at pharm.ubc.ca>
Subject: NEC Silentwriter LC-890 "RS-232"
We recently purchased a Sun 3/60 and a NEC Silentwriter LED array printer.
Its "RS-232" port drives 0-5V only. While this works on our AT clone and
an Atari ST1040, it doesn't work with the Sun (I guess that's called
getting burned with standards :-). The problem presents with the Sun not
receiving any debug info from the printer, but more importantly, not
receiving XON/ XOFF from the printer -- hence, ends of long jobs (>3
pages) are lost to the void.
None of the retailer, distributor, or NEC are interested in fixing the
problem but would rather pass the buck. I resent this!
My fix to the problem was a TTL->RS232 driver chip in the interface cable.
If anyone what's details, drop me a line. Some other people here solved
the problem with a commercial printer buffer and a commercial line driver
would do the trick too (at greater expense but less time !-).
David P. Harris, PhD MD
Faculty of Pharmaceutical Sciences
University of British Columbia
Vancouver, BC, CANADA V6T 1W5
(604) 228-6216
------------------------------
Date: Wed, 30 Mar 88 15:52:55 EST
From: warsaw at cme-durer.arpa (Barry A. Warsaw)
Subject: Help needed with SunView background proc's
Okay, another obscure question for those who have hacked with SunView.
Let me first explain my final objective and then the methods I've tried to
achieve this. BTW, I'm running OS 3.3
I have a sunview application with multiple frames; a base frame and 5
sub-frames. The various frames have different combinations of subwindows
consisting of canvases and panels. The panels are populated with panel
items.
I want the application to handle a set of keystrokes no matter which
frame/subwindow/panel_item it was typed over, but I need to know which
frame received the keystroke. I've been able to make all the windows and
panel items respond to a keystroke but as yet haven't been able to link
the window object that gets the event to the subframe that its in (at
least not in all cases).
Here's what I've done so far:
I set up the base frame and populated it with two panels and a canvas. In
the canvas, I set WIN_CONSUME_PICK_EVENTS to include WIN_UP_ASCII_EVENTS
and I set the WIN_EVENT_PROC to be my_canvas_p. In my_canvas_p, I check
for the desired keystroke and if its what I'm looking for,
window_get(canvas, WIN_OWNER) gives me the frame that canvas is a part of.
To get all panels and panel_items to respond to keystrokes, I do the
following in both PANEL definitions:
PANEL_ACCEPT_KEYSTROKE, TRUE,
PANEL_BACKGROUND_PROC, my_bgnd_p,
PANEL_EVENT_PROC, my_bgnd_p,
The event proc handles events falling on the panel (ie: not over a panel
item) and the background proc handles events falling on all the member
panel items. This is my understanding, correct me if I'm wrong.
Anyway, my_bgnd_p checks for the desired keystroke and then, if its the
one I want, it tries to find the frame that the object belongs to. If the
object is a panel then WIN_OWNER attribute finds the frame.
However if its a panel_item, then WIN_OWNER doesn't find the frame or the
parent panel. So I figure that PANEL_PARENT_PANEL will find the parent
panel owner of the item and then I could use WIN_OWNER of the parent to
find the frame. For some reason though, PANEL_PARENT_PANEL returns zero!
Now I know something else is going on here because I've used
PANEL_PARENT_PANEL successfully when the panel item handle is passed by
the *item's* notify proc (PANEL_NOTIFY_PROC) instead of the panel's
default background proc. I suspect that the background proc is passing
something different than the notify proc. This might cause
PANEL_PARENT_PANEL to barf.
I should point out that I can't seem to find a clean way to find out if
my_bgnd_p is getting a Panel or a Panel_item. It looks like either type
can be passed to my_bgnd_p but how do I find out which it is? Right now I
just do the procedure describe above as if it were a Panel and if that
fails, I try it for a Panel_item (which also fails).
The obvious solution would be to make the background proc different from
the event proc in the panel definition; one would handle panels and the
other panel-items. I'd rather not duplicate code though and anyway I'm
not sure my understanding of the differences between the background and
event procs is right.
Another alternate method would be to query which frame contains the cursor
at the time of the event, or which frame is the keyboard (or pick) focus
at the time of the event. I haven't yet found a way to do this.
Any help would be greatly appreciated.
NAME: Barry A. Warsaw TELE: (301) 975-3460
USMAIL: National Bureau of Standards ARPA: warsaw at cme-durer.arpa
Rm. B-124, Bldg. 220 UUCP: {...}!uunet!cme-durer!warsaw
Gaithersburg, MD 20899
------------------------------
Date: Wed Mar 30 14:20:55 1988
From: portal!cup.portal.com!Eldon_R_Mast at sun.com
Subject: le0: ENP/STP bits
One isolated segment of our LAN is causing 18 of our 3/50's to produce the
famed:
le0: Received packet with STP bit in rmd cleared
le0: Received packet with ENP bit in rmd cleared
le0: Receive buffer error - BUFF bit set in rmd
to their consoles. We have replaced transceivers, TDR'd the cable
segment, swapped fan-out units, and re-done and re-shielded all cable
connections. This isolated segment is serviced by a pair of fibre-optic
repeaters that connect us to the segment containing the two 3/280
fileservers that serve the 18 client 3/50's. The 3/280's never produce
the messages. (Never see the trashed packets.) I have exausted my
LANanalzing skills. It seems to me that there exists a device (3/50 or
transceiver or repeater) that continues to transmit on the net when it
should be "backing off." Have any of you experienced/solved similiar
problems?
I have noticed that three of the 3/50's on that segment are running ROM
rev 2.0. These 3/50's will always fail internal and external le
diagnostics. Is this a bug in the le diagnostic routines for 2.0 or could
this be my problem? For fun can anyone tell me exactly what the rmd
structure is?
Eldon R Mast
Telenet Communications 703-689-6372
Eldon_R_Mast at portal.COM
[[ For anyone who is still having STP/ENP problems, they were discussed in
Volume 6 issues 28 and 40. If anyone has any further information about
the cause of or the fix for this problem, please send it in. --wnl ]]
------------------------------
Date: Tue, 29 Mar 88 13:46:30 EST
From: moss!codas!novavax!proxftl!jesse at rutgers.edu (Jesse Perry)
Subject: SPARC User Manual?
I hear great things about the SPARC processor, but rarely anything
specific. Can anyone tell me where I can get a copy of the SPARC User
Manual to learn more?
Jesse Perry
Proximity Technology
uunet!proxftl!jesse
------------------------------
Date: Thu, 31 Mar 88 14:49:19 CST
From: scrumb at ncsa.uiuc.edu (Steve Crumb)
Subject: Experience with 56Kbps Interfaces?
Does anyone have experience with high-speed serial interfaces for DDS
circuits (i.e. 56Kbps)? We are beginning some experimentation with linking
Suns across 56Kbps serial networks and are looking for vendors and
products that would help us in this research. If you know of a vendor of
serial interfaces that run at 56 or 64Kbps could you pass their name and
contact person along?
Thank you
Steve Crumb
National Center for Supercomputing Applications
(scrumb at ncsa.uiuc.edu)
------------------------------
Date: Thu, 31 Mar 88 08:56:32 CST
From: Stephan Wasserroth <wasserroth at fokus.berlin.gmd.dbp.de>
Subject: How to set-up the mail environement?
I have the following problem with setting up the mail environement (spool
directories, spool files, mail aliases) on out SUNs. First, our
configuration of the machines:
1 3/280S used as NFS-file-server (exports /usr2), YP-master-server
and ND-server for 7 diskless 3/50 and 3/60 machines,
1 3/160C used as NFS-file-server (exports /usr4), YP-slave-server
and ND-server for 3 diskless machines,
1 3/50 with local disk,
1 3/260 with local disk,
1 1/160 with local disk.
About 70 percent of the home directories are located on /usr2, the other
users have their home directory on /usr4. These both directories are
network-wide mounted. All users may login on any machine, we don't have
"personal" workstations. The first step I have done already, is linking of
the client spool directories (/usr/spool/mail) to either /usr2/spoolmail
or /usr4/spoolmail (using the respective server). The best solution is of
course to have only one network-wide spool-directory (say on /usr2), but
in that case, the other machines are not able to use mail, if the serving
machine is dead.
So I need advise for a setup, which allows any user to login on any
available machine, get his own mail, send mail to any other machine
without knowning on which machine the receiver will login -- AND the setup
should work with only one server running.
Any ideas??
DFN-EAN: <wasserroth at fokus.berlin.gmd.dbp.de>
ARPA: <wasserroth%fokus.berlin.gmd.dbp.de at relay.cs.net>
GMD-FOKUS
Stephan Wasserroth Hardenbergplatz 2
System Manager for D-1000 Berlin 12
VAXes and Sun-WS Fed. Rep. of Germany
------------------------------
End of SUN-Spots Digest
***********************
More information about the Comp.sys.sun
mailing list