Sun-Spots Digest, v6n120
William LeFebvre
Sun-Spots-Request at RICE.EDU
Wed Jun 22 07:57:28 AEST 1988
SUN-SPOTS DIGEST Tuesday, 21 June 1988 Volume 6 : Issue 120
Today's Topics:
Re: Xylogics 754
Re: Fast bcopy() on Sun-4
Re: panic 'iechkcca'
Re: persistent clock drift problem
Re: Identifying monitor
Deliver mail to receiver's login directory
touchup: a bitmap editor for the Sun
Problems running touchup
name daemon on SUNOS goes nuts
Questions: static menus and sunview items
partitioning whole disk?
changes to ksh-i for yellow pages & other sun 3.x `features'
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: Tue, 14 Jun 88 02:37:12 EDT
From: dan at rna.rockefeller.edu (Dan Ts'o)
Subject: Re: Xylogics 754
Yes, we have a 754. We started out with a 752, which worked okay but not
great. The most serious problem was that we could not reliably run an
rdump off that machine -- probably not enough buffering to hedge against
bus contention. Also the performance did not seem better than a 451
(although we never had a 451 to do a direct comparison).
Xylogics was VERY nice in allowing us to swap our 752 for a 754, and even
came down to install it. It seems to work fine. I haven't measured the
performance yet, but at least it fixes the rdump contention problem.
Cheers,
Dan Ts'o 212-570-7671
Dept. Neurobiology dan at rna.rockefeller.edu
Rockefeller Univ. ...cmcl2!rna!dan
1230 York Ave. rna!dan at nyu.edu
NY, NY 10021 tso at rockefeller.edu
------------------------------
Date: Tue, 14 Jun 88 00:44:30 PDT
From: weiser.pa at xerox.com
Subject: Re: Fast bcopy() on Sun-4
Apparently the concern about bcopy speeds on Sun-4's can go away. The
bcopy for Sun-4's in SunOS 4.0 is about 10 times as fast than the one
under 3.2gamma. (This measured either by moving the same block of 1024
bytes 10000 times, or by moving a block of 1024000 bytes 10 times).
Furthermore, the difference is not some artifact of measurement or VM or
something: the same a.out compiled on the SunOS machine (with -Bstatic)
runs just as fast on the 3.2gamma machine.
So we can all go back to using bcopy again.
-mark
------------------------------
Date: Tue, 14 Jun 88 04:26:50 -0400 (EDT)
From: Bradley White <bww at cs.cmu.edu>
Subject: Re: panic 'iechkcca'
For another reference point, one of our (non-NFS) Sun-3's was recently
struck down with a series of iechkcca panics. It turned out to be a
flakey disk controller.
------------------------------
Date: Tue, 14 Jun 88 04:32:08 -0400 (EDT)
From: Bradley White <bww at cs.cmu.edu>
Subject: Re: persistent clock drift problem
It is my understanding that the interrupt priority levels are not set
sensibly, and that clock interrupts are often lost. The only thing that
keeps the time of day reasonably accurate is the ``dosynctodr'' code in
the clock driver. Note, however, that this breaks the adjtime() system
call - after making the user's adjustment the system will start pushing
the time back to where it was before as the change is never blasted
through to the TOD register.
------------------------------
Date: Tue, 14 Jun 88 08:40:04 CDT
From: gene at uicsl.csl.uiuc.edu (Gene Gardner)
Subject: Re: Identifying monitor
Reference: v6n109
The Philips monitor can be identified by a short, screw-driver shaft on
the rear to adjust the screen brightness....also a twist-lock type fuse.
The Moniterm can be identified by a long, black plastic shaft (to be
turned by fingers) for the screen brightness....also its fuse/powercord
combination has a plastic sliding-door arrangement. Of course either can
be identified by a name-tag inside if you remove the plastic case (which
is very simple to do).
------------------------------
Date: 14 Jun 88 08:30:51 GMT
From: howard at erix.ericsson.se (Howard Gayle)
Subject: Deliver mail to receiver's login directory
I propose that new mail be placed in the receiver's login directory, as is
done on Andrew. Here's the background: We have a network of SUN 3 file
servers and diskless clients running SUNOS 3.[245]. Because of NFS and
yellow pages, users can log in on any client and access their login
directories. However, there can be mail waiting for them in any
/usr/spool/mail directory on any machine in the yellow pages domain. We
have solved this problem temporarily by doing two things. First, we ask
users to place .forward files in their login directories to forward their
mail to the file server they use most often. Second, we have set up each
file server so that it and all its clients share a single /usr/spool/mail
directory (using symbolic links). The result is that all mail to users
ends up on their "favorite" server. Also, users who are logged in to
their favorite server or any of its clients are notified of new mail and
can read that mail directly. However, users who are not logged into their
favorite server or one of its clients must perform an explicit rlogin to
check for new mail and read it.
Placing new mail in users' login directories would eliminate this problem,
as well as the need to set up new symbolic links for /usr/spool/mail on
every machine, plus all those .forward files, plus any need for a setid
program to remove mail from /usr/spool/mail.
Why is there a /usr/spool/mail directory (or its predecessor /usr/mail)?
One of my co-workers speculates that it comes from the good old days of
RK05 cartridge disks. A system could have many users in the password
file, but at any one time only a few (perhaps only one) would have their
login directories mounted. Mail had to be placed in a directory that was
always mounted.
In any case, the only problem I can see with placing mail in login
directories is that they could be filled with junk, either inadvertently
or maliciously. This could be prevented by some kind of optional mail
limit feature, e.g. a .mailquota file that says "Return any mail that
would cause the total size of my incoming mail file to exceed x bytes."
TN/ETX/TX/UMG Howard Gayle
Ericsson Telecom AB
S-126 25 Stockholm
Sweden
howard at erix.ericsson.se
{mcvax, uunet}!enea!erix!howard
Phone: +46 8 719 5565 or +46 8 749 9554
FAX : +46 8 719 9598 or +46 8 47 89 37
Telex: 14910 ERIC S
------------------------------
Date: Fri, 1 Apr 88 18:22:13 EST
From: rayk at sbcs.sunysb.edu (Raymond T Kreisel)
Subject: touchup: a bitmap editor for the Sun
[[ It occurs to me that I never placed this announcement in a digest. My
sincere apologies to Mr. Kreisel. The files have been sitting in the
archives for well over a month now. I just misplaced this message. Upon
checking the file of pending messages, I found the newest version of
touchup waiting for me. So, version 2.3 has just been placed in the
archives... --wnl ]]
I have written a paint program for the sun that is similar to M*cpaint,
called touchup. This program is very helpful if you need to edit
screendumps or any other bitmaps. If you could please put each of the 7
parts into the sun-spots archives, I think that other sun-spots readers
would be interested in using this program.
ray
[[ In the archives under "sun-source" as "touchup.shar.1" through
"touchup.shar.7". The sizes of the files range from 39681 to 64299 bytes
and they average 54147 bytes apiece. They can be retrieved via anonymous
FTP from the host "titan.rice.edu" or via the archive server. 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: Tue 14 Jun 88 12:24:30-EDT
From: Laura Burchard <LAURA at vax.darpa.mil>
Subject: Problems running touchup
I've unshared, make installed, and make'd touchup, but when I try to
invoke it, I get:
sun8/darpa2/laura/tmp/touchupdir %touchup
Cannot execute binary file.
touchup: Exec format error
Why? I'm running it on a Sun120.
Laura Burchard
laura at vax.darpa.mil
[[ You might want to try the new version. --wnl ]]
------------------------------
Date: Tue, 14 Jun 88 18:08:38 CDT
From: "Matt Crawford" <matt at oddjob.uchicago.edu>
Subject: name daemon on SUNOS goes nuts
Phone: +1 312 702 8207
Someone on my system had a process in the background doing
"finger al at nrao.arpa". Our hostname lookups go through the sun yellow
page server and thence to named. The ypserver keeps retrying forever.
Nrao.arpa has only a CNAME record pointing to nrao.edu. Nrao.edu has no
address information. My named (the sunos 3.5 distributed one) kept
getting bigger and bigger. I first noticed that it was getting slow to
respond. "Ps" showed it always in "P" (paging) state, and it had a size
of 22 MB! Strings on a forced core dump shows many instances of "nrao"
and "arpa".
Tomorrow I'll install bind 4.8 and hope that that cures the problem.
Matt Crawford
------------------------------
Date: Tue, 14 Jun 88 09:32:22 +0100
From: everson%COMPSCI.BRISTOL.AC.UK at cunyvm.cuny.edu
Subject: Questions: static menus and sunview items
I have 2 questions:
1) Is there any way of using Sunview's menu facility to make static menus
- i.e. a menu which is on the screen permanently, with pull-right submenus
that only appear if you select them?
2) Has anyone created a data structure that can be used to describe
Sunview items, including the item type, position etc? It would be nice if
this could include menus as well.
I hope someone out there can help me with these. Thanks.
Phill Everson
------------------------------
Date: 14 Jun 88 22:37:18 GMT
From: stpstn!aad at ames.arc.nasa.gov (Anthony A. Datri)
Subject: partitioning whole disk?
I'm about to set up a sun 3/280 with one ~900 meg disk. I plan to make
the root and swap partitions as big as they have to be, and to make the
entire rest of the disk /usr. As I perceive the new structure of things
in SunOS 4.0, diskless clients' areas become part of the filesystem, so
separate partitions for them aren't needed anymore.
The question:
Is there any pressing reason *not* to do this; to make a /usr,/usr2,/usr3...
Danke.
@disclaimer(Any concepts or opinions above are entirely mine, not those of my
employer, my GIGI, or my 11/34)
beak is beak is not
Anthony A. Datri,SysAdmin,StepstoneCorporation,stpstn!aad
------------------------------
Date: Tue, 07 Jun 88 15:25:59 EDT
From: dsc at seismo.css.gov (David S. Comay)
Subject: changes to ksh-i for yellow pages & other sun 3.x `features'
[[ This message contains a long diff. It is the last message in this
issue, so you may safely skip it if you would like. --wnl ]]
since there seems to be lots of recent interest in getting ksh-i running
under the yellow pages, here are the changes i made to get it running on
our suns.
dsc
*** src/sh/builtin.c.orig Wed May 4 17:21:03 1988
--- src/sh/builtin.c Wed May 4 17:23:22 1988
***************
*** 1291,1298 ****
static void sig_list()
{
register SYSPTR syscan;
! register int n = MAXTRAP+1;
! char *names[MAXTRAP+1];
syscan=signal_names;
p_setout(standout);
/* not all signals may be defined */
--- 1291,1298 ----
static void sig_list()
{
register SYSPTR syscan;
! register int n = MAXTRAP+2;
! char *names[MAXTRAP+2];
syscan=signal_names;
p_setout(standout);
/* not all signals may be defined */
*** src/sh/io.c.orig Wed May 4 17:21:12 1988
--- src/sh/io.c Wed May 4 17:23:22 1988
***************
*** 16,22 ****
--- 16,26 ----
# ifdef BSD_4_2
# include <fcntl.h>
# endif /* BSD_4_2 */
+ # ifdef sun
+ # define CAST (unsigned char*)
+ # else
# define CAST (char*)
+ # endif /* sun */
#else
# ifdef VENIX
# include <sys/types.h>
*** src/sh/makefile.orig Wed May 4 17:21:17 1988
--- src/sh/makefile Wed May 4 17:23:23 1988
***************
*** 87,96 ****
ctype.o: ctype.c
-set -ex; if test "$(FIXDATA)" != "" ;\
then \
! $(C) -O -S -c ctype.c ;\
! sed 's/^\([ ]*\.*\)$(DATA)/\1$(FIXDATA)/g' ctype.s > temp.s ;\
! $(AS) -o ctype.o temp.s ;\
! rm ctype.s temp.s ;\
else \
$(CC_CMD) ctype.c ;\
fi
--- 87,93 ----
ctype.o: ctype.c
-set -ex; if test "$(FIXDATA)" != "" ;\
then \
! $(C) -O -R -c ctype.c ;\
else \
$(CC_CMD) ctype.c ;\
fi
***************
*** 98,107 ****
msg.o: msg.c
-set -ex; if test "$(FIXDATA)" != "" ;\
then \
! $(C) -O -S -c msg.c ;\
! sed 's/^\([ ]*\.*\)$(DATA)/\1$(FIXDATA)/g' msg.s > temp.s ;\
! $(AS) -o msg.o temp.s ;\
! rm msg.s temp.s ;\
else \
$(CC_CMD) msg.c ;\
fi
--- 95,101 ----
msg.o: msg.c
-set -ex; if test "$(FIXDATA)" != "" ;\
then \
! $(C) -O -R -c msg.c ;\
else \
$(CC_CMD) msg.c ;\
fi
*** src/sh/msg.c.orig Wed May 4 17:21:19 1988
--- src/sh/msg.c Wed May 4 17:26:53 1988
***************
*** 241,258 ****
"ed", "/bin/ed",
"false", "let 0",
"functions", "typeset -f",
! #ifdef BSD
"grep", "/usr/ucb/grep",
#else
"grep", "/bin/grep",
! #endif /* BSD */
"hash", "alias -t",
"history", "fc -l",
"integer", "typeset -i",
"lpr", "/usr/bin/lpr",
"ls", "/bin/ls",
"make", "/bin/make",
"mail", "/bin/mail",
"mv", "/bin/mv",
"nohup", "nohup ",
"pr", "/bin/pr",
--- 241,266 ----
"ed", "/bin/ed",
"false", "let 0",
"functions", "typeset -f",
! #if defined(BSD) && !defined(sun)
"grep", "/usr/ucb/grep",
#else
"grep", "/bin/grep",
! #endif /* defined(BSD) && !defined(sun) */
"hash", "alias -t",
"history", "fc -l",
"integer", "typeset -i",
+ #ifdef BSD
+ "lpr", "/usr/ucb/lpr",
+ #else
"lpr", "/usr/bin/lpr",
+ #endif /* BSD */
"ls", "/bin/ls",
"make", "/bin/make",
+ #ifdef BSD
+ "mail", "/usr/ucb/mail",
+ #else
"mail", "/bin/mail",
+ #endif /* BSD */
"mv", "/bin/mv",
"nohup", "nohup ",
"pr", "/bin/pr",
***************
*** 311,319 ****
#ifdef SIGCHLD
{"CHLD", (SIGCHLD+1)|(SIGNOSET<<SIGBITS)},
#endif /* SIGCHLD */
! #ifdef SIGCLD
{"CLD", (SIGCLD+1)|(SIGNOSET<<SIGBITS)},
! #endif /* SIGCLD */
#ifdef SIGCONT
{"CONT", (SIGCONT+1)|(SIGNOSET<<SIGBITS)},
#endif /* SIGCONT */
--- 319,327 ----
#ifdef SIGCHLD
{"CHLD", (SIGCHLD+1)|(SIGNOSET<<SIGBITS)},
#endif /* SIGCHLD */
! #if defined(SIGCLD) && !defined(SIGCHLD)
{"CLD", (SIGCLD+1)|(SIGNOSET<<SIGBITS)},
! #endif /* defined(SIGCLD) && !defined(SIGCHLD) */
#ifdef SIGCONT
{"CONT", (SIGCONT+1)|(SIGNOSET<<SIGBITS)},
#endif /* SIGCONT */
***************
*** 329,341 ****
#endif /* SIGIO */
{"IOT", (SIGIOT+1)},
{"KILL", (SIGKILL+1)|(SIGIGNORE<<SIGBITS)},
#ifdef SIGPHONE
{"PHONE", (SIGPHONE+1)|((SIGNOSET|SIGCAUGHT)<<SIGBITS)},
#endif /* SIGPHONE */
{"PIPE", (SIGPIPE+1)},
! #ifdef SIGPOLL
{"POLL", (SIGPOLL+1)|((SIGNOSET|SIGCAUGHT)<<SIGBITS)},
! #endif /* SIGPOLL */
#ifdef SIGPROF
{"PROF", (SIGPROF+1)|(SIGNOSET<<SIGBITS)},
#endif /* SIGPROF */
--- 337,352 ----
#endif /* SIGIO */
{"IOT", (SIGIOT+1)},
{"KILL", (SIGKILL+1)|(SIGIGNORE<<SIGBITS)},
+ #ifdef SIGLOST
+ {"LOST", (SIGLOST+1)},
+ #endif /* SIGLOST */
#ifdef SIGPHONE
{"PHONE", (SIGPHONE+1)|((SIGNOSET|SIGCAUGHT)<<SIGBITS)},
#endif /* SIGPHONE */
{"PIPE", (SIGPIPE+1)},
! #if defined(SIGPOLL) && !defined(SIGIO)
{"POLL", (SIGPOLL+1)|((SIGNOSET|SIGCAUGHT)<<SIGBITS)},
! #endif /* defined(SIGPOLL) && !defined(SIGIO) */
#ifdef SIGPROF
{"PROF", (SIGPROF+1)|(SIGNOSET<<SIGBITS)},
#endif /* SIGPROF */
*** src/shlib/tilde.c.orig Wed May 4 17:21:38 1988
--- src/shlib/tilde.c Wed May 4 17:24:24 1988
***************
*** 173,178 ****
--- 173,228 ----
}
}
while(c != EOF);
+ #if defined(accel) || defined(sequent) || defined(sun)
+ {
+ char *buff;
+ char *domain;
+ if(yp_get_default_domain(&domain) != 0)
+ return(-1);
+ if(yp_match(domain,"passwd.byname",user,strlen(user),&buff,&val) != 0)
+ return(-1);
+ sp = user;
+ while((c= *buff++) !='\0')
+ {
+ if(c == ':')
+ {
+ if(field==5)
+ goto good;
+ else if(field++ ==0)
+ {
+ if(*sp)
+ field = 10;
+ else
+ sp = u_logdir;
+ }
+ }
+ else if(c=='\n')
+ {
+ if(field==5)
+ goto good;
+ sp = user;
+ field = 0;
+ }
+ else
+ {
+ switch(field)
+ {
+ /* match name */
+ case 0:
+ if(c != *sp++)
+ field = 10;
+ break;
+
+ case 5:
+ *sp++ = c;
+ /* see if too big */
+ if(sp >= (u_logdir+LOGDIR))
+ goto leave;
+ }
+ }
+ }
+ }
+ #endif /* defined(accel) || defined(sequent) || defined(sun) */
goto leave;
good:
rval = 0;
------------------------------
End of SUN-Spots Digest
***********************
More information about the Comp.sys.sun
mailing list