Sun-Spots Digest, v6n68

William LeFebvre Sun-Spots-Request at RICE.EDU
Tue May 3 06:08:32 AEST 1988


SUN-SPOTS DIGEST            Monday, 2 May 1988         Volume 6 : Issue 68

Today's Topics:
                 Re: Conference room sized color displays
                               Re: newtool
                       Re: Sun4 Optimixer problems
                         Re: Adding a third Eagle
                           Re: Need more groups
                mods to dump for dumping live file systems
            restarting executing programs where they left off
                                SUNOS 4.0
                        color terminal emulation?
                     Ada benchmarks on the Sun-3/260?
                          Bug in initgroups(3)?
                  Diag's efficacy at spotting bad blocks
                            number of nfsd's?
              Getting mail between Suns and VAX/VMS DECNET?

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:    Wed, 20 Apr 88 10:29:51 PDT
From:    jim at boeing.com
Subject: Re: Conference room sized color displays

Both electrohome and Barco have high resolution and high bandwith
projection systems which will display a Sun Color image.  We ran a little
shootoff.  Where we had both systems in the same room and hooked them up
to Suns, Symbolics, Macintosh, PCs and standard NTSC video equipment.  The
electrohome was more versatile in that changes to the configuration are
done almost entirely through a remote control and an inboard computer.
However, it did not present a sharp a picture as did the Barco system.
The Barco system was able to as many systems as the electrohome but
configuration was done with dip switches and such inside the cabinet.  We
elected to purchase the Barco, partially because it was so difficult to
change and that would reduce the probability that untrained users would
screw the thing up.  Both systems were able to do extensive convergence
across the entire projected surface.  We did not try either system with a
high res monitor but I don't believe that either system had the bandwith
to support the high res monitor.

These systems cost about $25,000 and are typically available from your
local high end video merchant.  

Jim Van Every                jim at boeing.com
Advanced Technology Center   
Boeing Computer Services     !uw-beaver!ssc-vax!bcsaic!jim
(206) 865-3364

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

Date:    Wed, 20 Apr 88 12:35:52 PDT
From:    gandalf at csli.stanford.edu (Juergen Wagner)
Subject: Re: newtool

The alias 'newtool' would not work in my environment. I am making use of
the -s flag for suntools, which allows me to specify a .suntools file
depending on the machine I am working on (e.g. distinguishing large
1280x1600 screens from 900x1152 screens, b&w screens from color screens,
etc.). In that case, 'newtool' would have to find out which .suntools file
has been used to startup the window system. In fact, my .suntools files
aren't called .suntools but .suntools.large, .suntools.small, ...

My preferred solution to restarting tools which died away for some
mysterious reasons is to have a submenu allowing me to restart the initial
tools, one at a time. A short sed command will generate the necessary menu
file.

Besides that, I have modified suntools themselves (the menu stuff) such
that now environment variables are expanded, blank (non-selectable) lines
can be inserted into a root menu, and refreshing the screen can be done by
typing ^Q^R into the background.

Juergen "Gandalf" Wagner,		   gandalf at csli.stanford.edu
Center for the Study of Language and Information (CSLI), Stanford CA

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

Date:    Wed, 20 Apr 88 15:07:59 est
From:    mp at allegra.att.com
Subject: Re: Sun4 Optimixer problems

Scott Schwartz writes 

> compiling the 4.3BSD troff (which runs fine on a Sun3 or a Vax) fails in
> EXACTLY the same way the SunOS4-3.2 troff does.  Conclusion: a compiler
> problem, obviously.

His previous message, which describes the problem, says in part

	nroff and troff fail in strange ways.  Try:
		troff -rc1 /dev/null
	and notice that troff wants to read stdin. 

I decided to look into this, since we also found an optimizer bug in the
Sun-4 C compiler.  I don't think Scott's problem is due to a bug in the
compiler, though.  I copied the 4.3bsd troff to a Sun-4, compiled it with
-g, ran it under dbx, and found that giving troff the -rc1 option causes
this same problem: it ignores the rest of the argument list and starts to
read from stdin.

cnum(), which is supposed to parse the "1" from the -rc1 argument, sets up
an input buffer to contain the given string, and calls atoi().  A few
nested subroutines later we get to getch0, which contains the line:

		if(nx || ((ibufp >= eibuf) && (ibufp != (char *) MAXPTR))){
			/* code to read more data from a file */
		}

cnum had set ibufp to the string containing the "1" (some address on the
stack), and had set eibuf to be MAXPTR (0x7fffffff) But on a Sun-4,
pointers can be bigger than that.  When I tried it, ibufp was 0xfeffff9d.
So the body of the if statement gets executed, and as best I can tell,
nextfile() gets called, which sets the input file to be stdin.

My fix, which I can't completely test because we don't have typesetters
here that will understand old troff output, was to change MAXPTR to
0xffffffff.  (I looked for something more mnemonic that I could import
from values.h, but didn't find anything).

	Mark Plotnick
	allegra!mp
	mp at allegra.att.com

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

Date:    20 Apr 88 18:11:50 GMT
From:    hpda!sun!megatest!cander at uunet.uu.net (Charles Anderson)
Subject: Re: Adding a third Eagle

roy%phri at uunet.uu.net (Roy Smith) says:
> The XY board can supposedly handle up to 4 drives but the kernel driver
> won't support than many.  Is there some good reason why not?

The kernel easily supports 4 drives.  You just have to config the kernel
correctly.  Tell it that you have four drives on xyc0:

    disk            xy0 at xyc0 drive 0
    disk            xy1 at xyc0 drive 1
    disk            xy2 at xyc0 drive 2
    disk            xy3 at xyc0 drive 3

We run all of our sun 3/160's with 3 or 4 Eagles.  

We've evaluated the Ciprico Rimfire, and it screams when driving a single
drive.  With the large command buffer, it should do even better in a
multi- drive configuration.  

Charles.
{sun, decwrl, fortune, pyramid}!megatest!cander

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

Date:    Wed, 20 Apr 88 21:16:36 EDT
From:    Stephen J. Roznowski <sjr at mimsy.umd.edu>
Subject: Re: Need more groups

I had this problem also, while you can change the number of groups to be
greater than 8 in sys/param.h and recompile, it will not do you any good.
The current implementation of NFS only supports groups of size 8 or less.
That means the other groups over 8 will not be passed during any NFS
attempts to acess a file.

The solution (more than 8 groups) will have to wait until Sun decides to
correct the NFS implementation.

Stephen J. Roznowski                 sjr at mimsy.umd.edu

[[ The problem is more than just NFS.  ANY program that depends on the
number of groups being 8 (which is any program that uses the parameter
NGROUPS from param.h) will have to be at least recompiled.  --wnl ]]

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

Date:    Wed, 20 Apr 88 12:44:51 EST
From:    davy at intrepid.ecn.purdue.edu (Dave Curry)
Subject: mods to dump for dumping live file systems

Well, there seems to be enough interest in our mods to 4.3BSD dump to
allow dumping mounted file systems in multi-user mode that it warrants
sending this to the digest.

--Dave Curry
Purdue University
Engineering Computer Network

[[ Stored in the archives as "sun-source/dump-diffs.shar".  It can be
retrieved via anonymous FTP from the host "titan.rice.edu" or via the
archive server with the request "send sun-source dump-diffs.shar".  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:    Wed, 20 Apr 88 12:47:11 EST
From:    davy at intrepid.ecn.purdue.edu (Dave Curry)
Subject: restarting executing programs where they left off

There's been a lot of interest in my "chkpt" library to allow restarting
programs in mid-execution that I've made it available for anonymous FTP
from the host intrepid.ecn.purdue.edu as the file "pub/chkpt.tar.Z".

If you make it work on something other than 4.3BSD VAXes, I'd be
interested in having the diffs sent back to me.

--Dave Curry
Purdue University
Engineering Computer Network

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

Date:    20 Apr 88 23:57:14 GMT
From:    tekbspa!tss!joe at uunet.uu.net (Joe Angelo)
Subject: SUNOS 4.0

Our local SUN sales and tech reps have just presented us with some of the
details of SUNOS 4.0 ... I'm trying to put together a list of all the nice
things. If you'll interested, send mail to indicate such and I'll put
forth more effort in preparing the list.

There are ALOT of changes.

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:    Wed, 20 Apr 88 10:23:19 PDT
From:    vanhelde at stout.ind.trw.com (Jeanne Van Helden)
Subject: color terminal emulation?

Does anyone know where I can get or buy a color terminal emulation tool to
run in suntools?

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

Date:    20 Apr 88 21:19:06 GMT
From:    umbc3!tron!celozzi at uunet.uu.net (Dominic J Celozzi)
Subject: Ada benchmarks on the Sun-3/260?

Has anyone run the PIWG Benchmarks on the Sun-3/260 for Ada?  An associate
is interested in getting these and asked if I would post it to the
network.  We have gotten them for the MIPS machine, but would like to
compare them to the Sun-3.  If you would like to include those for the
Sun-4 as well, great!  Please mail all responses to
...!uunet!umbc3!tron!squire with a Cc: to ..!uunet!umbc3!tron!celozzi.
Thanks in advance for your time.

Dominic Celozzi
Westinghouse Electronics Systems Group
UUCP: ...!uunet!umbc3!tron!celozzi

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

Date:    Wed, 20 Apr 88 21:07:04 EDT
From:    dupuy at columbia.edu (Alexander Dupuy)
Subject: Bug in initgroups(3)?

Description:

When using rsh or on to start processes on another machine, initgroups
doesn't seem to be adding the "wheel" (0) group correctly.  Strangely
enough, this doesn't seem to happen with login or rlogin, which also use
initgroups.

Repeat-By:

Script started on Mon Apr 11 18:47:52 1988

douglass% rlogin localhost
Last login: Mon Apr 11 18:46:50 from amsterdam.columb
Sun UNIX Release 3.5 (3.280) #1 built on Sat Apr 9 16:49:32 EDT 1988

douglass% groups
tech operator daemon dcc wheel nest staff sys

douglass% bye
Connection closed.

douglass% rsh localhost groups
tech operator daemon dcc nest staff sys

douglass% on localhost groups
tech operator daemon dcc nest staff sys

douglass% rlogin columbia		# Vax running 4.3
Last login: Sat Apr  2 13:04:29 on ttyA0
4.3 BSD UNIX #7: Sun Dec 13 08:55:26 EST 1987
[columbia]

columbia% groups
staff wheel dcc

columbia% bye
Connection closed.

douglass% rsh columbia groups
staff wheel dcc

douglass% 

script done on Mon Apr 11 18:51:28 1988

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

Date:    Thu, 21 Apr 88 00:40:47 PDT
From:    mangler at csvax.caltech.edu (Don Speck)
Subject: Diag's efficacy at spotting bad blocks

Has anybody else noticed that SunOS 3.x /stand/diag finds very few bad
blocks on Xylogics controllers?

The three Eagles that we bought from Sun had thirty-some bad blocks each,
and were last formatted under SunOS 2.0.  The next Eagle was bought
elsewhere, and SunOS 3.0 /stand/diag only found one bad block.  I thought
this anomalous, and asked Sun Hotline if diag was forgetting to inhibit
ECC, but they told me:  no, Eagles had simply gotten that much better.

On our next Eagle, this time on a Xylogics 451, SunOS 3.2 /stand/diag
found NO bad blocks at all.  Hmm...

Recently, I moved an old Eagle from a pair of VAXen with Emulex SC7000's
onto a Sun-3/160S with Xylogics 451.  A combination of diskformat,
badblock, and disktest on the vax had found one or more bit errors in 54
sectors.  SunOS 3.4 /stand/diag found only 4 bad blocks, even after
running a 'scan' subcommand for 5 passes.  Obviously, the xy driver trusts
in ECC.  I ran disktest for 100 passes (2 days) to see if the driver would
say anything about having to apply ECC, but it was completely silent.

The ECC on SMD disks is not robust enough to depend on it that totally!
It's only supposed to be invoked occasionally, maybe a few times a day.

Should I dig out SunOS 2.x /stand/diag and reformat my disks on a Sun-2,
or should I hope that SunOS 3.5 or 4.0 will fix this?

By the way, has anyone actually observed any overlapped seeks?  On SunOS
3.4, I measure the same total seeks/second for two disks as for one, even
on the 3/160S that has a brand-new Xylogics 451.  On my vaxen the same
experiment produces almost twice as many seeks/second for two disks as for
one.  Will overlapped seeks ever be made to work?

Don Speck   speck at vlsi.caltech.edu  {amdahl,ames!elroy}!cit-vax!speck

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

Date:    Thu, 21 Apr 88 09:48:30 CDT
From:    "Dan A. Dickey" <ddickey at gonzo.eta.com>
Subject: number of nfsd's?

We have several file servers here which we have 6 nfsd's running on.  They
still are collecting the majority of time and service for NFS doesn't seem
to have improved after changing to six daemons from four.  Is there a good
number of nfsd's that we can run?  Is 10 or 12 too many?  By how much will
more daemons imporove performance?  Can someone out there descibe how the
nfs daemons work?	-Dan

Dan A. Dickey  ddickey%gonzo.eta.com at uc.msc.umn.edu

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

Date:    Thu, 21 Apr 88 08:34:25 EDT
From:    John Sloan <jsloan at odin.wright.edu>
Subject: Getting mail between Suns and VAX/VMS DECNET?

Dave Capshaw <capshaw at austin.lockheed.com> asks:
>What are other people doing for mail service when they add Suns to an
>existing DECNET network ?

I've heard of four solutions.

[1] Run DECnet on your Sun. Sun has a version, and although the initial
release did not include email support, it is my understanding that it does
now. I recall seeing an email interface posted to USENET.

[2] Run TCP/IP software on one of your VAXen. There are a number of
vendors marketing such a package, including one that is endorsed by DEC.

[3] Use some other package between the Suns and the VAXen. I've heard of
people using Unix/PMDF and OSU's VMS/PMDF to do this. One of your Suns and
one of your VAXen serve as gateways. If you have a CSNET connection, you
may already have PMDF on one of the systems.

[4] If you happen to be running Ultrix on one of your VAXen (from your
posting, I would suppose this is not the case, but this is the solution we
use) get DEC's DECnet/Ultrix product and use the Ultrix VAX as a gateway.
With some hacking on your sendmail configuration file it is easy to
provide a bidirectional gateway. We used one of our Ultrix VAXen to
gateway mail between all VMS and Unix/TCP/IP/SMTP machines, as well as to
CSNET and UUCP. This is easier if you have some simple Sendmail
"subroutines" to do the address conversions to and from DECnet's :: syntax
so that Internet-type addresses can be expressed at least approximately in
DECnet form.

e.g.

### Internet to DECnet: convert from internet %@ form to pure DECnet
### :: form, mostly for the benefit of the DECnet mailer regarding
### paths.
###
### user{%hostn}*@host1 --> host1{::hostn}*::user

S11
R$*<$*>$*		$1$2$3				defocus
R$*$=N.DECNET$*		$1$2$3				strip DECNET domains
R$*@$*			$1%$2				all @ => %
R$*%$*			$:$2<DECNET>::$1		begin at left
R$*%$*<DECNET>$*	$2<DECNET>::$1$3		move gaze right
R$*<DECNET>$*		$@$>10$1$2			recanonicalize
R$+			$@$1				catch all

### DECnet to Internet: convert from DECnet :: form to internet focused
### %@ form, mostly for the benefit of users who are used to using VMS.
###
### host1{::hostn}*::user --> user{%hostn}*@host1

S12
R$*<$*>$*		$1$2$3				defocus
R$*$=E::$+@$+		$3@$4				drop DECnet forward
R$*@$*			$@$1@$2				already there
R$+::$*			$:$2<DECNET><@$1>		focus on domain
R$+::$*<DECNET>$*	$2<DECNET>%$1$3			move gaze right
R$*<DECNET>$*		$@$>10$1$2			recanonicalize
R$+			$@$1				catch all

### Generic Canonicalization: convert back to focused internet %@ form
### after possibly hacking off some host names or domains.
###
### user{[@%]host}* --> user{%host}*<@host>

S10
R$*<$*>$*		$1$2$3				defocus
R$+@$+			$1%$2				convert @ to %
R$+%$+			$:$1<%$2>			begin at left
R$+<$+%$+>		$1$2<%$3>			move gaze right
R$+<%$+>		$@$1<@$2>			refocus and leave
R$+			$@$1				catch all

### Precedence: assign precedence to @, % and ! operators in mixed
### addresses to remove ambiguity. Of course, we may misinterpret
### it completely, too. The reason for the strategy here is that
### we're seeing a lot of UUCP bang paths (some generated by Dnagent
### as a result of UUCP-zone RFC920 domains) that use UUCP to get to
### a gateway, then use % to specify a machine within that domain.
###
### e.g. dnagent(user%host2 at sub.domain.top)=hosta!hostb!user%host2
###
### host1!user at host2 --> host1!user<@host2>
### host1!user%host2 --> user%host2<@host1>
###
### We also try to canonicalize bang paths that contain RFC920 domains.
###
### domain!path --> path at domain
###

S14
R$*<$*>$*		$1$2$3			defocus
R$*$=U!$+@$+		$3@$4			drop UUCP forward
R$+!$+@$+		$@$1!$2@$3		@ precedence in a!b at c

R$+!$+			$:<$1>!$2		focus
R<$+!$+>!$+		<$1>!$2!$3		move gaze left
R<$*.$=I>!$+		$@$3@$1.$2		domain!path -> path at domain
R$*<$*>$*		$1$2$3			defocus

R$+!$+%$+		$@$2%$3@$1.UUCP		! precedence in a!b%c
R$+			$@$1			catch all

John Sloan, The SPOTS Group    Wright State University Research Building
CSNET: jsloan at SPOTS.Wright.Edu  3171 Research Blvd., Kettering, OH 45420
UUCP: ...!cbosgd!wright!jsloan          +1-513-259-1384  +1-513-873-2491
Logical Disclaimer: belong(opinions,jsloan). belong(opinions,_):-!,fail.

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

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



More information about the Comp.sys.sun mailing list