[mod.computers.sun] SUN-Spots Digest, v4n1

Sun-Spots-Request@RICE.EDU (Scott Alexander) (01/14/86)

SUN-SPOTS DIGEST             Monday, 13 Jan 1986            Volume 4 : Issue 1

Today's Topics:
				Administrivia
			  Re: Loading TeX on a Sun-3
			     undump.c on a Sun 3
			  LCF memory board followup
			  more memory for SUN-1/150U
			            LCF boards
			       Getting the time
				 the battery
			    Re: removing batteries
		       Re: Benchmarks - DN330 vs. Sun-3
		  Re: Dhrystone benchmark - DN330 vs. Sun-3
				 3Com boards
			      how to beep a sun
		 Undecoded keyboard desupported in Sun 3.0??
			Looking for a SMTP SEND daemon
				 dumping suns
		       incoroporating sun source code.
		     SUN raster to VAX (4.2BSD) versatec
			     disk configurations
			  Sun & PC software question
		     saving the history from sun windows

------------------------------------------------------------------------
Date: Mon, 13 Jan 86 18:40:02 CST
From: Scott Alexander <sun-spots-request@rice.edu>
Subject: Administrivia

The new year has not been kind to this list so far.  The machine on which
the list lives has been down with disk problems for about half a week so
far.  Also, the alias for sun-spots and sun-spots-request got deleted when I
was cleaning up our alias file.  Sigh.  If your request seems not to have
occurred or your article seems to be missing, resubmit it;  I am up to date
on both requests and submissions now.  I shall be sending out weekly copies
of the digest starting with this one.

Let me also remind everyone that submissions go to sun-spots@rice.edu and
request for changes in the list, etc. go to sun-spots-request@rice.edu.

A happy new year to all,
Scott

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

Date: Wed, 25 Dec 85 14:32:00 est
From: Barry Shein <bzs%bostonu.csnet@CSNET-RELAY.ARPA>
Subject: Re: Loading TeX on a Sun-3

When we had an evaluation SUN-3 here at Boston University with
SUN/3 Pilot I managed to get GNUemacs up which does the same
sort of 'undump' that TeX will have to do (I am familiar with
both) except it does it via a built in subroutine rather than
an external program. Various things in a.out.h have changed
slightly thus undump will be calculating wrong so the answer is
yes, undump.c will have to be modified to work on the SUN/3 unless
something changes in the final release of the SUN/3 software.
Shouldn't be very hard (I will end up doing it here if it's not
posted by the time our SUN/3's arrive in a couple of weeks), mainly
just a few magic calculations on things like the text offset.

As I have said before, it's too bad that an option to UNIX was
never added to request that a core-dump be made in a restartable
format (ie. a.out format) rather than a core image, but I recognize
this is non-trivial in the general case. At any rate, this renders
a (fine) program like undump extremely sensitive to slight changes
(hah, just try moving it to a SYSV/COFF system!)

	-Barry Shein, Boston University

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

Date: Tue 31 Dec 85 21:17:29-PST
From: Pierre MacKay <MACKAY@WASHINGTON.ARPA>
Subject: undump.c on a Sun 3

For a brief time we had some hope that a VAX 4.3 fix to undump
might work on SUN-3s.  No luck.  It seems that the format
of both core dump files and a.out files is very seriously
altered in the SUN-3 kernel.    I have one report from Pereira
at sri that:

Both a.out and core formats changed for the Sun-3 (in fact, they will
change for all machines from Sun release 3.0, now in beta test). The
a.out change is very simple, just an added field to the a.out header
for the machine type. I don't know the details of the core file format
changes, though.


		and another from colorado that the VAX 4.3
fix absolutely does not work on the SUN-3.  

Any help would be much appreciated.

					Pierre MacKay
					Unix-TeX site-coordinator

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

From: allegra!mp@seismo.CSS.GOV
Date: Thu, 2 Jan 86 12:53:42 est
Subject: LCF memory board followup

A couple months ago I asked the list about LCF 4-meg multibus memory
boards, and said that I'd report back if there were any surprises.

We first got one for a 100U.  It worked fine, and its owner loves
having 5 meg.  We then ordered 7 more, for our 120's.  Of these, 1 was
bad upon receipt (it got parity errors), and 1 went bad in about a week
(the system detected bad data in a memory location during its
self-check).  We're sending them back to LCF for exchange.

A more severe problem is that, when the 120's have more than 4
megabytes in them, they tend to get transient parity errors (i.e., no
address is mentioned in the error message) anywhere from once every
couple hours to once every couple days.  The frequency seems to depend
on the system rather than on the memory board, and is worst if you have
the 4 meg board along with 3 Sun boards.  I talked to someone from LCF
about it, who said that their boards are electrically identical to
Sun's, and that if we're running 2.0 (we are) he "guarantees" we shouldn't
have any problems.

Further information, in case you can offer any help: the 120's are all
diskless, though some have Sky and color boards, and have rev N and rev
R proms and the 3com ethernet board.  We tried sandwiching the CPU
board in the middle of the memory boards, and the order of boards doesn't
affect things at all.  Putting in Sun prime memory boards makes no difference,
either.

	Mark Plotnick
	allegra!mp

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

Date: Wed, 25 Dec 85 11:43:56 cst
From: oddjob!kaos!sra@lbl-csam.ARPA (Scott Anderson)
Subject: more memory for SUN-1/150U

I asked about this a few issues back (v3 #11).  The one response I got
said that they had installed a 4MB LCF board and were happily using
5MB of memory.  I also called LCF and they confirmed that you could
pack the 100U/150U with their boards.

				Scott Anderson
				ihnp4!oddjob!kaos!sra

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

Date:         Mon, 30 Dec 85 09:02:15 CDT
From: Stan Hanks <drilltech!stan@rice.edu>
Subject:      LCF boards

The LCF folks are committed to getting a real Sun 3 VME memory  out.
They had considered entering the "regular" VME memory market, but
concluded that there was no percentage in it as there are something
like 50 other manufacturers building VME memory. 

It should be exactly like their Multibus memory, but for the Sun 3.
I believe that projected prices are around $5k for 16 meg.

				Stan Hanks

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

Date: Mon 30 Dec 85 13:16:54-PST
From: Fernando Pereira <@SRI-IU.ARPA:PEREIRA@SRI-CANDIDE.ARPA>
Subject: Getting the time

With respect to Mark Weiser's complaint about having to enter the time
each time he powers up his machine, I don't have any hardware solution
for his woes, but I have the software solution I use for my diskless
2/50, the following line at the bottom of /etc/rc.local

	/usr/ucb/rdate host-with-time

where host-with-time is the machine on our net with a working clock.
Maybe this is obvious to all in the net, but it took me a while to
figure it out because the rdate page was missing in my issue of the
documentation...

-- Fernando Pereira

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

Date: Wed, 1 Jan 86 22:16:13 est
From: mark@markssun.cs.umd.edu (Mark Weiser)
Subject: the battery

A call to sun revealed that the bad batteries and/or boards were only in
the some early suns, that there is no problem now.  Either I misunderstood
or the article I read in the Sun user group newsletter wasn't clear.
I have put my batteries back.
	-mark
--------
Spoken: Mark Weiser 	ARPA:	mark@maryland	Phone: +1-301-454-7817
CSNet:	mark@umcp-cs 	UUCP:	{seismo,allegra}!umcp-cs!mark
USPS: Computer Science Dept., University of Maryland, College Park, MD 20742

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

Date: Mon, 30 Dec 85 15:26:11 cst
From: Dave Capshaw <capshaw@mcc.arpa>
Subject: Re: removing batteries

We had a number of batteries explode.  The batteries exploded with
enough force to bend the battery retaining clips.  The metal ends of
the batteries and lots of former battery chemicals rattled around 
for a while inside the pedestal.  Not a good situation.

Running rdate in rc.local has been a workable alternative to the
batteries.

Dave

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

Date: Mon 30 Dec 85 13:54:45-PST
From: Fernando Pereira <@SRI-IU.ARPA:PEREIRA@SRI-CANDIDE.ARPA>
Subject: Re: Benchmarks - DN330 vs. Sun-3

I haven't benchmarked a DN330, but my experience is that a Sun-3
is 2 to 3 times faster than a Sun-2, depending on application.
This seems to support the Dhrystone benchmarks that have been
posted to the net. I also know that an Apollo DN220 is substantially
slower than a Sun-2, even though both use the 68010. My suspicion
is that memory management overheads may account for some of the
difference. Could this be the cost of the more sophisticated VM
mechanisms of Apollo machines?

-- Fernando Pereira

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

Date: Mon 30 Dec 85 17:44:47-MST
From: John W Peterson <JW-Peterson@UTAH-20.ARPA>
Subject: Re: Dhrystone benchmark - DN330 vs. Sun-3

One other question - when you got your DN330 upgrade, did you also get
new compilers for them?  The stock SR9 compilers have some problems on the
020's - I've found bugs in the floating point department, and could easily
believe they might miss some optimisations for the DN330's.  (The easy way
to check is to try "/bin/cc kloo.c -M330" - if it doesn't work you're running
old compilers).

We got our hardware upgrades several weeks ago but had to nag the field 
office for the compiler upgrades.

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

Date: Tue, 31 Dec 85 13:54:13 cst
From: Keith Cooper <fbag@rice.edu>
Subject: 3Com boards

Amen to Sid Stuart.  At Rice, we have 10 Sun-2/120's with 
3Com boards.  All were ordered after the announcement of 
Sun's ethernet controller for the 120, and we expected
delivery with Sun's controllers.  At the time we received
the machines, I complained bitterly about getting 3Com
controllers.  Technical, marketing, and sales people from
Sun all reassured me that the 3Com boards would "never"
be a problem.  

Today, they assure me that the problem can easily be fixed,
for an inexpensive upgrade.  It may look inexpensive in 
quantity one, but to those of us with many machines (10 
Sun 2/120's, 8 Sun 1/100's, 2 Sun 1/150's) it adds up 
in a hurry.  

keith cooper
(cooper@rice)

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

Date: 10-Jan-86 15:28:34-PST
From: gerolima@FORD-WDL1
Subject: how to beep a sun

/*

So You want to beep a Sun? Well,
I got this from Sun, and it works. 

	However, I'd like to know WHY it works...
Here goes....


	"Eeez next...SOFTVARE!....verrrry niiice..."

	Mark Gerolimatos
	ARPA: gerolima@ford-wdl1.arpa
	UUCP: {sun,fortune}!wdl1!gerolima

One very basic reason that there are no beeps in suntools: How could
you tell which window is doing the beeping? Suntools catches all ^Gs
and turns them into a flash on the correct window.

If you really MUST beep, and have a beepable workstation (50, 120,
etc...) an application program can make it beep.  (Suntools itself will
still flash, e.g., "echo '^G'" to a window will make it flash.) Compile
and run the following program to hear the beep.

This is unsupported, of course!

This program lets you to ring the bell. Along with this program you
need to create a device in /dev with the same major # as ttya & ttyb,
but with an unused minor number, e.g., 

	/etc/mknod bell c 12 2	(or other appropriate major,minor #s)

crw-rw-rw-  1 root      12,   0 Mar 23 13:16 /dev/ttya
crw-rw-rw-  1 root      12,   1 Mar  6 10:51 /dev/ttyb
crw-rw-rw-  1 root      12,   2 Mar  6 10:51 /dev/bell


WHY DOES THIS WORK??????????????????????????????????????????
--------------------------------------------------------------------------*/

#include <sys/time.h>

#define	RING_ON		0x02	/* Control-B */
#define RING_OFF	0x03	/* Control-C */
#define NULL		0

main()
{
	int	bell;
	char	outbuf[1];
	static  struct  timeval  ring_time  =  {0, 125000};

	if ( (bell = open("/dev/bell",2)) < 0 )
		{
		perror("ring:failed opening /dev/bell");
		exit(1);
		}

	outbuf[0] = RING_ON;
	if ( write(bell,outbuf,1) < 0 )  /*turn bell on*/
		{
		perror("ring:failed writing RING_ON");
		exit(1);
		}

	select(0, NULL, NULL, NULL, &ring_time);

	outbuf[0] = RING_OFF;
	if ( write(bell,outbuf,1) < 0 )	/*turn bell off--very important*/
		{
		perror("ring:failed writing RING_OFF");
		exit(1);
		}
}

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

Date: Thu, 26 Dec 85 13:49:48 PST
From: Deutsch.pa@Xerox.ARPA
Subject: Undecoded keyboard desupported in Sun 3.0??

It appears that the ability to get every key transition, undecoded, has
been desupported in Sun's 3.0 system release.  Is this true?  If so,
would anyone like to add their vote to ours in asking Sun to reinstate
it?  If not, could someone tell us how to get to it?  (Apparently the
way one used to get to it no longer works.  I'm relaying information
from someone who knows the code that uses it, which I don't.)  We depend
on this facility for our Smalltalk-80 system implementation, and we can
kludge around its absence only at the cost of some functionality.

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

Date: Tue 31 Dec 85 14:34:59-PST
From: Fernando Pereira <@SRI-IU.ARPA:PEREIRA@SRI-CANDIDE.ARPA>
Subject: Looking for a SMTP SEND daemon

We run an Ethernet with a variety of machines (LispM, VAX, ...). We would
like to have a mechanism to send warnings to every machine on the net.
Most of them take the SMTP SEND protocol, but the Suns don't seem to.
Does someone have a daemon for this? Thanks

-- Fernando Pereira

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

Date: Wed, 1 Jan 86 22:19:36 est
From: mark@markssun.cs.umd.edu (Mark Weiser)
Subject: dumping suns

What is anyone doing about dumping suns?  With 15 suns the estimate
here is that weekly epoch dumps would keep 2 people busy full-time.
Needless to say we are not doing this at the moment.  
Most of our users do not have tape drives so that is no solution.
All the suns have private disks.  Any good solutions?
	-mark
-------------
Spoken: Mark Weiser 	ARPA:	mark@maryland	Phone: +1-301-454-7817
CSNet:	mark@umcp-cs 	UUCP:	{seismo,allegra}!umcp-cs!mark
USPS: Computer Science Dept., University of Maryland, College Park, MD 20742

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

From: mark@markssun.cs.umd.edu (Mark Weiser)
Date: Sat, 4 Jan 86 21:05:02 est
Subject: incoroporating sun source code.

Sun is nice enough to incorporate many example programs in their window
documentation, even for object only sites.  Suppose I write some code
based on these examples.  (For instance, borrowing unchanged entire
subroutines even thought the final purpose of the whole program is completely
different.  Using 'clock.c' comes to mind.)  Can I post the results
to net.sources, presuming I still give credit to Sun for the portions 
originally theirs?
	-mark

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

Date: Sat, 4 Jan 86 09:33:53 mst
From: unmvax!kurt@rice.edu (Kurt Zeilenga)
Subject: SUN raster to VAX (4.2BSD) versatec

I am trying to get our SUNs to screendump to our versatec connected to
one of our vaxens.  Screendump, according to SUN software support, is
creating a standard versatec raster file.  However, when this is
printed on the vaxen's versatec (w/ "vax% lpr -Pva -v raster" ) I get
lots of junk.  I tried swapping the bytes and printing the result, but
again, junk.  Has anyone gotten rasters made on a SUN to print on a
raster drive on a vaxen?  If you have, please contact me (via mail) and
tell me how you did it.  I am also getting nothing out of our Imagen
8/300 with a sun raster.

From this, I gather that SUN rasters are not versatec rasters?  Is this
correct?  If so, any one got a program to convert from sun to versatec
and from versatec to sun.

Thanks a million,	Kurt

-----
Kurt D. Zeilenga               |  UUCP: {gatech|lanl|ucbvax}!unmvax!kurt
Computer Science Department    |  ARPA: unmvax!kurt@lanl.ARPA
University of New Mexico       |  (505) 277-3112  (Dept. Office)
Albuquerque, New Mexico 87131  |  (505) 277-6571  (Lab./Office)

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

Date: Tue, 7 Jan 86 16:56:30 EST
From: Steve M. Burinsky <smb@mimsy.umd.edu>
Subject: disk configurations

        I'd like some advice on disk configurations for my Sun's.
Which  disk  options  provide me with the best throughput?  Which
are more/less reliable?  I would like to have a reasonable amount
of  local  storage per node, so for now I won't have any diskless
nodes.  I would like to stick with a single pedestal, also.
        I have an abundance of disk space on my Vax, so I am con-
sidering  using  it  as  a NFS server.  Am I going to pay a large
price for byte swapping between the Vax and Suns?  How will a Vax
NFS server perform compared to a Sun NFS server?

Thanks,
Steve Burinsky

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

Date: Tue, 7 Jan 86 00:52:20 pst
From: ihnp4!felix!abspc!mb@ut-sally.arpa
Subject: Sun & PC software question

Hello! Does any body know out there if there's any type of CAD/CACD
systems out there that run both on a PC & SUN? What I'm looking for
is a CAD system that can do the layouts on the PC and send it to
the SUN (via ethernet, rs-232, etc) to do the number crunching and
send the results back to the PC. 

			Thanks in advance!

				Mike Burg
				trwrb!felix!abspc!mb
				oliveb!felix!abspc!mb

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

From: wetzel@nprdc.arpa (Douglas Wetzel)
Date: 31 December 1985 1453-PST (Tuesday)
Subject: SAVING THE HISTORY FROM SUN WINDOWS


               Saving the 'history' from  Sun Windows ?

We are implementing programs to compile statistics on the commands issued by
individual users.  Because of certain limitations associated with 'lastcomm'
we have been working on programs and shell scripts  which rely on the
history mechanism of the cshell (i.e., the shell variable activated by 'set
savehist' stores the history in the file .history).  Not having a source
license, we resorted to this cshell method, which unfortunately has a
problem when this history-saving program is used on our Suns.

When a user logins in, the .history file is read into a buffer in the Csh
program, and when the user logs out from the login shell this buffer is
written out to the .history file.  Between logging in and logging out from
the login shell, the user may create various shells (e.g., each sunwindow).
The problem is that the history for each of these windows is extremely
difficult, if not impossible to save.  If the user exits a window by typing
'exit', then the history for that shell is written to the .history file, but
of course when the login shell exits it is overwritten and lost.  Further,
it is very unusual for anyone to exit a window with 'exit', rather most
users exit a window with 'quit' from the popup menu.  When the shell is
terminated with the mouse in this way the history of that window is not
saved at all.

We would really like to save the history for each window in a login session;
You can see it right there on the screen but can't get it!! We have tried a
number of tricks, but to no avail [e.g., various ways of setting savehist or
ampersanding away a script that keeps trying to save the history (after a
sleep) in each window: problem is that this script has its own associated
history and can't access the parent's history].

If anyone has any helpful suggestions for saving the histories associated
with multiple shells (windows) when they exit, we would be happy to hear
them.

           Doug Wetzel    [ wetzel@nprdc.arpa  ]

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

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