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

Sun-Spots-Request@RICE.EDU (Vicky Riffle) (08/14/86)

SUN-SPOTS DIGEST           Thursday, 14 August 1986	 Volume 4: Issue 25

Today's Topics:
			      SUN and Subnets (5)
		      3.0 setup flames and comments (2)
			     Exec'ing SUNTOOLS(2)
			       SUN PC-NFS board
		   /bin/as output format request/bug?/fix...
	       Getting fullscreen mouse location under SunView
	 File System Tuning on Sun 3/180 with Xylogics 451 and CDS2476
		      Problems and fixes for lpr software
	    Warning about rack-mount fans and a comment on disk cables
			       SunView questions?
		        Long Video Cable for Sun 3/160?
			       Undump for SUN3's?
		    Sun/2 Memory Expansion Manufacturers?
				 Rental Suns?
		  Request for info. about office systems?
		     VME to VME bus adapter for Sun-3?
		       Apple personal modem and uucp?
			       Ghosts and such?
		UNIX network/kernel changes ? errors ? bugs ?
			      UREP for Sun 3/160?
		    Menus in 3.0 Suncore graphics window?
------------------------------------------------------------------------
Date: Sat, 09 Aug 86 16:15:00 PDT
From: Milo S. Medin (NASA ARC Code ED) <medin@orion.arpa>
Subject: SUN and Subnets (1)

Hi folks.  I'm working on building some IP based networks for NASA, and
in talking with several sites, I've found that many would like to shove
an additiional ethernet board into a SUN fileserver, and gateway the traffic
from the busy local ethernet to a 'backbone' type ethernet.  Further, a couple
places are using Sun's SUNlink package running over 9600 baud synch. lines
linking a couple machines out in remote locations, and would prefer to
continue using it.  The problem I've run into is that SUN doesn't support
subnetting.  We subnet here at Ames, and have some SUNs in the local
internet, but none as gateways.  We can deal with them because our IP
gateways run with the 'arphack' and so we fool the SUNs into working
into the subnet structure of the local network.  But you can't deal with
subnetting if the gateway doesn't know about it.  So I'm faced with swapping
out all the SUN machines being used as gateways with a 'real' gateway, or
using bunches of Class C nets here and there.  Using a more capable
gateway is probably in the future for all the long haul links, but
the campus LAN's will probably continue to use SUN fileservers as gateways
simply because they may have a lot of diskless SUN clusters.

When I asked my SUN rep. about subnetting, he said that SUN OS 4.0 might
have it, and that would be released in the Jan./Feb. '87 timeframe, but would
make no committments.  Other people I know who have asked got no commitment
from SUN at all.  Further, my SUN rep. mentioned that subnetting requires
some non-trivial changes in NFS.  I can't understand why this would be the 
case.  I'm aware that various sites have patched up SUN kernels
to run with subnets, and that it was fairly easy if you had source code.
Many of the sites I talk to however, would really not like for
me to come in with a special set of .o files and start messing
with their working vanilla SUN kernels unless I absolutely had to.  
I can't figure out why SUN is being so tardy about implementing
subnetting.  RFC 950 has been out for some time, and considering
the amount of business they do with universities, I would think many
people would be grateful for some relief in this area.  Has anyone
out there gotten a committment from SUN to implement subnetting,
or gotten any reason why its hard for them to do so?  It sure would
be easier on the Internet community if they did so.  Anybody from
SUN care to comment?

					Milo Medin
					NASA Ames Research Center
					Moffett Field, CA 

			      Internet: medin@ames.arpa
			      UUCP:	{seismo,amdcad}!nike!medin

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

Date: Sat, 9 Aug 86 20:48:36 EDT
From: Rick Adams <rick@seismo.CSS.GOV>
Subject: SUN and Subnets (2)

Back in March I got a pseudo answer out of Sun. They would like to
have it in the 3.2 release, but it would probably break the binary backwards
compatibility with 3.0, so they would probably have to wait for 4.0.

From the sound of it 3.2 should really be called 4.0, and 4.0 shold be
called 5.0.

It seems to be more of a marketing decision than an engineering decision.
I'd gladly accept the tiny backwards incompatibility as I'm sure most 
people would.

---rick

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

Date: Sat, 09 Aug 86 20:41:49 PDT
From: karels@monet.berkeley.edu (Mike Karels)
Subject: SUN and Subnets (3)

Berkeley has been using Suns on subnetted networks and (sigh) as gateways
for nearly two years.  We added subnet support before we even had source
code by substituting 1 kernel source file and 2 header files, plus
ifconfig and routed.  Unfortunately, several Sun changes have made this
harder to support, and the subnet scheme used is the old Berkeley scheme
which supports only 8-bit subnet fields with the high bit set.  I have
been told by Sun systems people that subnet support will be in the 4.0
release, but that's not as helpful as I would like.  I have been tempted
to figure out how to package and distribute subnet support for Suns,
but haven't taken the time to do so.  Perhaps I could convince someone
else working with Suns at Berkeley to package things up if a few sites
could test it.

		Mike

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

Date: Sun, 10 Aug 86 02:13:29 EDT
From: Chris Torek <chris@gyre.umd.edu>
Subject: SUN and Subnets (4)

We just insist on source, so that we can fix things like that (and
like the lack of checksumming in NFS) ourselves.  (We seem already
to have been bitten several times by Ethernet bit rot: `mysterious'
NFS errors that are not reproducible.  There was no other disk
activity at the time, so this is not the namei bug.)

Steve Miller dropped the 4.3 TCP into our 3.0 kernels.  Aside from
one locally-introduced bug, it has been working well for some time.
(The local bug was fixed a few days ago.)  Once the file servers
are stable---we have been suffering with disk problems (another
local hack, this time in hardware)---we might consider distributing
the code; but we will likely have to require both 4.3 and 3.0 source
licenses (alas!).

Chris

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

Date: Mon, 11 Aug 86 09:49:57 EDT
From: Steve D. Miller <steve@brillig.umd.edu>
Subject: SUN and Subnets (5)

   I've heard a lot of things from a lot of people, and have some things
to say on my own.  Let's see if I can't make a stab at answering some
of the questions here...

   In the first article in this discussion, Milo Medin (medin@ames) says:

	When I asked my SUN rep.  about subnetting, he said that SUN OS 4.0
	might have it, and that would be released in the Jan./Feb.  '87
	timeframe, but would make no committments.  Other people I know who
	have asked got no commitment from SUN at all.  Further, my SUN rep.
	mentioned that subnetting requires some non-trivial changes in NFS.
	I can't understand why this would be the case.

   OK.  From what I have heard, Sun is trying to move to a 4.3BSD networking
base with the 4.0 release.  I have talked to (a) some people at a Sun/LMI
NFS conference held in Boston in April and (b) one of the people supposedly
working on it, and unless I have grossly misunderstood something I believe
that this is indeed the case.  The timeframe for the release sounds right
to me; the 3.0 release is slated for October.  Again, no commitments...but
I did it myself and didn't think it was too hard.  I didn't even have a real
understanding of the networking code at the time I did it and I'm sure that
the Sun people do, so they should have even less of a problem.

   Sun said at the NFS workshop that they were trying to get rid of ND,
and that NFS was going to undergo a protocol rollover with the 4.0 release.
I'm sure that NFS will need a lot of work to allow things like swapping,
but I *know* that NFS version 2 (the one running in 2.0 and 3.0) works
with little or no changes on top of a subnet-based kernel.  I *ran* it
on top of one (see below).  If there's a problem, I'd love to hear what
it is so I can fix it...but I think the rep is wrong on this one.  The
only thing that comes to mind at all is that the kudp_fastsend() routine
used to get kernel RPC/UDP packets onto the wire as fast as possible
takes a number of liberties (like no checksums) with the UDP/IP output
routines and might well need a rewrite for subnets.  Commenting it out
works just as well, though...and I confess that's what I did.

   In another article on the subject, Mike Karels (karels@monet.berkeley.edu)
says:

	I have been tempted to figure out how to package and distribute
	subnet support for Suns, but haven't taken the time to do so.
	Perhaps I could convince someone else working with Suns at Berkeley
	to package things up if a few sites could test it.

   You've got yourself a volunteer.  I don't know how useful I'd be, but I
can try to make sure that the stuff works for gatewaying.  There's a room
here that could stand to be its own network; now if I can just convince my
bosses...

   In yet another article, Chris Torek (chris@mimsy.umd.edu) says:

	Steve Miller dropped the 4.3 TCP into our 3.0 kernels.  Aside from
	one locally-introduced bug, it has been working well for some time.
	(The local bug was fixed a few days ago.)  Once the file servers are
	stable---we have been suffering with disk problems (another local
	hack, this time in hardware)---we might consider distributing the
	code; but we will likely have to require both 4.3 and 3.0 source
	licenses (alas!).

   Well, I haven't really done all that yet.  I had all of the 4.3BSD (beta!)
networking code, including XNS and a protocol-independent version of NFS, in
a local kernel based on Sun 2.0.  It ran subnets to the same extent as the
4.3BSD beta release, and NFS didn't hiccup at all.  As I said though, I did
comment out the one (relatively small) piece of code that did the fastsend
stuff.  I will probably start work on the 3.0-based version in the next
week or two, and we will probably let it out (with licensing restrictions
like I stated above) once it seems stable.  I don't know if "distribute"
is the right word...

	-Steve

Spoken: Steve Miller 	ARPA:	steve@mimsy.umd.edu	Phone: +1-301-454-1516
CSNet:	steve@umcp-cs 	UUCP:	{seismo,allegra}!umcp-cs!steve
USPS: Computer Science Dept., University of Maryland, College Park, MD 20742

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

Date: Tue, 5 Aug 86 14:12:10 CDT
From: Keith Cooper <cooper@rice.edu>
Subject: Setup flames and Comments (1)

In SUN-Spots 4(24), Leonid Rosenboim asked the question:

  Why is the Setup program so bloody automatic?  Is it really intended
for dumb people? or was it meant only to impress?

Leonid, the answers should be obvious.  Setup was designed as a demonstration
program that might work in real life situations.  Try using it on a machine
without a SUN console, like a factory configured 3/160S.  If you give it a
termcap name for a terminal, the odds are reasonable that it will dump core
and leave you back in mini-UNIX without either the source or a debugger; of
course, you need to use one of the handful of termcap entries that it 
supports (for example, ansi works while vt100 does not!).  Try using it 
to install software on a working network.  Of course it doesn't work, it 
only appears to be able to deal with internet addresses beginning with 
the SUN default network.  If your site has class A or B addresses, well, 
that's too bad.  I won't bother to detail all the different ways we've found
to make setup dump core... I'm sure everyone else with a non-trivial network
has found several.

What galls me the most, however, is dealing with technical support people on
this issue.  Invariably, you end up dealing with someone who has been with 
the company for a short period of time.  Time and again, I've gotten responses
that take the tenor of "well, if you read page xxx in the manual, you'll
see that ..."  It takes all of the restraint I can muster to keep from saying
"look you bozo, I read the manual three times and tried this three times 
before calling."

So Leonid, the answer to your question is obvious: Setup is a cute 
demonstration program, but if SUN was serious about helping users set up 
their machines, they would include the source for it in the normal 
distribution so we can at least figure out what is going wrong.

keith cooper
(cooper@rice)

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

Date: Tue, 5 Aug 86 10:46:58 EDT
From: cjh@CCA.CCA.COM (Chip Hitchcock)
Subject: 3.0 setup (2)

   A Sun "customer support engineer]"told me that Sun "does not support"
running 68010 binaries on a 68020 cpu. This sucks---but at least it's a
reason for automagically providing two full sets of binaries.
   I also am unhappy with the degree of automation of 3.0 installation, and I
certainly don't consider myself a hacker---I'm an ex-chemist with some computer
experience who was handed some Suns two years ago and told to make them work
the way the programmers wanted. Automation *does* make installation easier if
you have a completely independent system (I've done that) but I'm not looking
forward to doing it for our cluster.

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

Date: Sun, 3 Aug 86 7:12:41 EDT
From: "William P. Caloccia" <caloccia@ccv.bbn.com>
Subject: Exec'ing suntools (sun-spots v4/23-4) (1)

	While using public or shared Sun 2's at RPI, occasionally I would
find a Sun with an non-functional mouse.

	 If you have an conditional 'exec suntools' in your .login,
that can be a problem, especially if your cursor does not end up in a
sub-window, you literally have no input devices, and have to rlogin
from elsewhere to kill yourself. (When I started working with one of
the file servers, which intentionally did not have a mouse, I found
exec'ing suntools to be a bad concept.) 

	Also, a tip: check to see if the current login is on the console,
not if the person on the console is you, there is a difference.

	With Sun-2's, if you were rlogin'd into a sun, you could start
suntools if the /dev/console was not de-permitted to you (it wasn't too
useful though).

	The best general answer is probably to alias 'suntools' or
a shorter phrase to 'exec suntools'.

	--bill

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

Date: Wed, 6 Aug 86 21:13:37 EDT
From: Mike Muuss <mike@BRL.ARPA>
Subject: Exec'ing SUNTOOLS (2)

Here is how I cope with the issue of wanting to run SUNTOOLS most of
the time, except when it's an async line, rlogin, or a debugging session.
From my .login:

switch ($term)
	case dialup:
	case telnet:
	case su:
	case network:
	case pacx:
		echo -n "Input TERM Type? "; set term=$< ; breaksw
	case tty5620:
		set term=dmd;
#		exec /usr/local/DMD/bin/mpx ;
		breaksw
	case sun:
		switch (`tty`)
		case /dev/console:
			echo -n "Suntools file? "
			set ans=$<
			switch ($ans)
			case "":
				setenv DEFAULT_FONT /usr/brl/sunfonts/screen.r.12+
				exec /usr/suntool/suntools
				breaksw
			case "n":
				breaksw
			default:
				exec /usr/suntool/suntools -s $ans
				breaksw
			endsw
		default:
			breaksw
		endsw
		breaksw
endsw

switch ($term)
	case "":
		set term=vi200;
	case vi200:
		cat ~mike/.vis200-clear; stty tabs; breaksw
	case tty5620:
		cat ~mike/.5620-clear; breaksw
	case adm42:
	case 42-f:
		cat ~mike/.adm42-clear; stty tabs; breaksw
	case cdc:
		stty erase ;  breaksw
endsw

umask 002
unset ignoreeof

Best,
 -Mike

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

Date: Mon, 4 Aug 86 14:07:05 pdt
From: nike!scubed!proffer@ucbvax.Berkeley.EDU (Bill Proffer)
Subject: SUN PC-NFS board

We just finished evaluating a Sun PC-NFS board at our site for
a week.

Bottom line:

If you're a Unix junkie, forget it.

If you're a MSDOS freak, you'll love it.

It does nothing for users of Unix, other than provide a slow,
jerky Ethernet and serial telnet emulator running on the PC.  No rlogin,
rsh, etc.

For MSDOS PC users it's great, however.  It provides 26 virtual hard
disks of unlimited size & of access speed greater than or equal to
the best of the AT disks (we've got Eagles on our Suns...the smaller
disks are going to be less impressive).  Looks just like MSDOS...you
don't have to know anything about Unix.  Gives you access to shared
resources like printers, tape drives and big disks.  File locking
is not good however...don't try to share a file among PC users.

If you've got a lot of floppy disk PC around and got users wanting
hard disks and laser printers, this is the only way to go.

Bill Proffer  

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

Date: Fri, 1 Aug 86 22:52:57 EDT
From: Barry Shein <bzs%bu-cs.bu.edu@CSNET-RELAY.ARPA>
Subject: /bin/as output format request/bug?/fix...

Hey, let's get obscure...

Reference: SUN3/R3.0

In the good ole' days*, one could write an assembler program
that needed no ld resolutions, assemble it, chmod u+x it,
and it would run.

Those days are gone, but for a (I believe) trivially easy
to fix reason:

/bin/as should set the exec.a_entry to 0x2000 (it is a 0407 file),
rather than 0x0 as it does now. Default would seem to make sense, I
suppose I could live with a command line option to /bin/as.

Ld does not seem to care if it is later fed such a file (I patched
that location and it both caused the .o relevant files to work and had
no effect on subsequent loading of random .o files fed back thru cc or
ld, nor would I have expected it to, but who knows.)

...why? Let's not go into it, suffice it to say it would cause certain
command files written for the vax and sun2 to just continue working on
the SUN3 without change (and these are not unique to this site.)

It also seems ideologically correct (!!)

	-Barry Shein, Boston University

* Mostly good cuz they're gone

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

Date: Sat, 2 Aug 86 15:08:57 cdt
From: wca@deneb.UTEXAS.EDU (William Anderson)
Subject: Getting fullscreen mouse location under SunView

/*
Recently, Bill Janssen <janssen@mcc.arpa> wanted to know how to track the
mouse under SunView.  Here is a little subroutine I wrote that goes into
fullscreen mode and returns the name of the window that is under the mouse
when the left button is clicked (other buttons abort the window selection
procedure).  I include some additional notes at the end.
*/

/* get_window.c */

#include <suntool/sunview.h>
#include <suntool/fullscreen.h>
#include <sys/file.h>
#include <stdio.h>

#define ROOT_NAME "/dev/win0"

/* This is a printer's fist cursor image.  If you don't like it,   */ 
/* use icontool to create a cursor for your fullscreen action. WCA */
static short mycursor_image[] = {
/* Format_version=1, Width=16, Height=16, Depth=1, Valid_bits_per_item=16 */
	0x0020,0x0070,0x009C,0x0106,0x0083,0x01C9,0x03E2,0x07FE,
	0x0FF0,0x1FF0,0x3FF0,0x3FE0,0x77E0,0x61C0,0xE000,0xC000
};
mpr_static(mycursor_pr,16,16,1,mycursor_image);
#define XHOT 0
#define YHOT 15

/* get_window_name() - select desktop window and return its name in theName; */
/* if successful, return 0, else return -1 */

int
get_window_name(fd, theName)
int fd;                         /* file descriptor of calling program's frame */
char *theName;                  /* name of window chosen */
{
        struct fullscreen *fullScreen;
        Cursor myCursor; 
        struct inputevent myEvent;
        int rootfd;
        int done = FALSE;
        int winnum;
        int result = -1;
        extern int errno;

        /* initialize special cursor for window selection mode */
        myCursor = cursor_create(
                CURSOR_IMAGE, &mycursor_pr,
                CURSOR_XHOT, XHOT,
                CURSOR_YHOT, YHOT,
                CURSOR_OP, PIX_SRC^PIX_DST,
        0);

        /* get rootfd for use in win_findintersect() below */
        rootfd = open(ROOT_NAME, O_RDONLY, 0);

        /* get full screen access */
	/* note - must use the fd from the *frame* of your program */
	/* or events will not be routed correctly.  Get this file  */
	/* descriptor by: fd = (int)window_get(myFrame,WIN_FD);    */
        fullScreen = fullscreen_init(fd);

        /* install new cursor (fullscreen_destroy() restores the old one) */
        win_setcursor(fullScreen->fs_windowfd, myCursor);

        /* do event loop */
        while( done == FALSE ){
            if(!input_readevent(fullScreen->fs_windowfd, &myEvent)) {
                switch ( myEvent.ie_code ) {

                    case MS_LEFT:       /* window select event */
                        winnum = win_findintersect( rootfd,
                            myEvent.ie_locx - fullScreen->fs_screenrect.r_left,
                            myEvent.ie_locy - fullScreen->fs_screenrect.r_top);
                        if(winnum != WIN_NULLLINK) {
                            win_numbertoname(winnum, theName);
                            result = 0;
                            done = TRUE;
                        }
                        break;

                    case MS_MIDDLE:     /* abort events */
                    case MS_RIGHT:
                        *theName = '\0';
                        result = 1;
                        done = TRUE;
                        break;

                    default:            /* we ignore all other events */
			/* note that, depending upon the event mask,  */
			/* we could do other things with the mouse    */
			/* position, like echoing it to a window, etc.*/
                        break;
                }
            }
        }

        /* cleanup */
        cursor_destroy(myCursor);
        fullscreen_destroy(fullScreen);
        close(rootfd);
        return(result);
}

/*
I hope that this code is straightforward enough so that I can omit extensive
comments here.  However, a word is in order about the way I use coordinates
and the rootfd here.

I was interested in finding the window name of any window running under
suntools.  Therefore, in win_findintersect() I used the file descriptor
of the root window /dev/win0 (this assumes a single display screen and
will need to be modified for workstations with more than one display).
This is because win_findintersect() finds child windows of the window
whose fd it is passed.  This also explains why I needed to modify the
coordinates of the event I am passed.  The coordinates of the event
are always the coordinates of the frame to which the event is passed
(which in this case is the frame of the calling program).  This is why
I modify the mouse coordinates with the location of the fullscreen rect
(which is also in the coordinate system of the frame of the calling
program).

There are, of course, many other ways in which fullscreen_init() and
fullscreen_destroy can be used; this is just a way that worked for me.
Note that win_grabio() does not need to be called explicitly since
fullscreen_init() calls it for me.

Enjoy,

Willie Anderson
University of Texas Computation Center
*/

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

Date: Tue, 5 Aug 86 12:38:58 PDT
From: brian@sdcsvax.ucsd.edu (Brian Kantor)
Subject: File System Tuning on Sun 3/180 with Xylogics 451 and CDS2476

I recently set up a Sun 3/180FS with a Xylogics 451 controller and a
pair of CDS 2476 drives (these are the 1/2-size Eagle equivalents).

Playing with 'tunefs', I found that the default rotational delay
of 4 ms that Sun uses (which is apparently the Berkeley default) is
grossly wrong in this configuration.

By adjusting the rotational delay to various values, and reading back a
large file, I saw a very noticeable difference in the elapsed time with
a larger value of rotational delay.

The actual method is this (for file system xy1a, which is an 8K block
system):

	First, throw everybody else off the system.  Run in single-user
	mode if you wish.

	foreach n (1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20)
		umount /dev/xy1a
		tunefs -d $n /dev/xy1a
		mount /dev/xy1a /spare
		write-500-8K-blocks-to-/spare/xxx
		sync
		sync
		time read-500-8K-blocks-from-/spare/xxx
		rm /spare/xxx

(The read and write programs are little 3-line C programs using 
read(2) and write(2), not stdio.)

Anyway, with this, there is a drop from 10-12 seconds elapsed time 
to 6 seconds elapsed time for the read when the rotational delay is 
set to 19 mS.  I've therefore set it to 20mS (to allow for a slight 
windage for busy queues and such).  I think this is a simple enough 
procedure that it should be repeated for EACH controller and disk 
combination to ensure that a file system is optimised for better 
performance.  It took about 10 minutes to perform the test, so I did it
three times to make sure it was a repeatable result.

One problem with using 'tunefs' is that usually (and for certain with
Sun's 'setup' program), you've already loaded /usr with all the programs
you'd like the system to be able to get to faster.  So what you have to
do is dump the entire file system to tape, newfs to clear it, tune it,
and reload from tape.

	Brian Kantor	UC San Diego

	decvax\ 	brian@sdcsvax.ucsd.edu
	ihnp4  >---  sdcsvax  --- brian
	ucbvax/		Kantor@Nosc 

   "There is more harmony in films than in life."
	- Francois Truffaut

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

Date: Thu, 7 Aug 86 17:00:09 cdt
From: knutson@ngp.UTEXAS.EDU (Jim Knutson)
Subject: Problems and fixes for lpr software

Lpr and crew have two problems that are very simple to fix but are
extremely bothersome if they aren't.  In particular, if you use hostnames
that use domains, then lprm will not remove a queued file.  This is due
to setting the hostname of the machine at boot time (thereafter returned
by gethostname()) to a hostname without domains and having gethostbyaddr()
return official hostnames that do have domains tacked on them.

To get around the problem, change all references to:

	gethostname(host,sizeof(host));

to

	gethostname(host,sizeof(host));
	if ((hp = gethostbyname(host)) != (struct hostent *) NULL)
		strcpy(host,hp->h_name);        /* use official name */

This also allows for the case of hosts with the same hostname but with
different domains using the same remote printer since spool files will
be named by the official hostname (including the domain).

The second problem had to deal with what cropped up after fixing the
first.  The file cmds.c has a routine defined called select() which
is used by lpc.  This name conflict with select(2) would not normally
cause a problem except when the gethostbyname() call was added, the
yellow pages are used which naturally uses select(2).  The fix is to
declare the select() routine in cmds.c as static (or change it's name
altogether).

By the way, how do we let Sun know about these problems?  Is someone
from Sun on the mailing list?

Jim Knutson
knutson@ngp.utexas.edu

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

Date: Sat, 9 Aug 86 23:51:45 edt
From: seismo!allegra!phri!roy@SALLY.UTEXAS.EDU (Roy Smith)
Subject: Warning about rack-mount fans and a comment on disk cables

	I installed our new Eagle in one of our 3/180's yesterday.  While
rummaging around in the bottom of the rack cabinet I noticed something
interesting -- a loose power cord.  Some investigation showed that the bank
of cooling fans at the bottom rear of the cab had never been plugged in!  I
don't know how common a problem this is (I haven't had a chance to check our
other 180 yet), but those of you with rack-mount systems might want to take
a peek down there and see what the story is.  This is what I paid Sun to
install our systems for?

	A while ago I asked about hooking up a second disk, and several
people told me not to bother with the fancy Sun-supplied cabling.  I took
their advice and just ran the flat daisy-chain command cable out of one
drive and into the other, bypassing those stupid cable bulkheads Sun uses.
For the radial data cable from the controller, I just disconnected the
short internal cable Sun puts in the Multibus-to-VMEbus adapter card and
ran a standard flat cable from the drive to the socket on the Xylogics-450
board.  Removing an adjoining blank panel made enough room for the cable to
hang out.  So far (I've made the file systems but don't have any real data
on the new disk yet), everything seems to be working fine.

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

Date: Thu, 7 Aug 86 14:07:06 pdt
From: bcsaic!michaelm@uw-june.arpa
Subject: SunView questions?

Would someone have mercy on a poor Lisp programmer trying to use SunView?
The goal is the following:  I have lisp (BSD Frantz) running in a tty window; 
part of lisp's output is to draw graphics in a canvas.  I would like the
canvas to have scrollbars (as well as some other things, e.g. menus, but
I'd settle for the scrollbars for now).
I have tried six dozen ways of doing this conceptually simple task, and so far
have not succeeded.  A few ideas I've tried:

1. When lisp starts up in a tty window, it cfasl's in a set of C functions
that make calls on SunView.  Next, a lisp function (call it 'opencanvas')
calls window_create to create a frame, and again to create a canvas using the 
previously created frame as a base frame.  The base frame and canvas are both 
created with the attribute "WIN_SHOW" set to "TRUE", and the canvas attribute
"WIN_CONSUME_PICK_EVENT" is set to "LOC_DRAG".  We then return; other C 
functions are called to draw to the canvas.  This works fine, except that the 
created window is 'dead': it shows no response to the mouse, and its border is
transparent.  (If the canvas's "WIN_INPUT_DESIGNEE" is set to 
win_nametonumber(getenv("WINDOW_ME")), i.e. to lisp's window, any keyboard 
input directed to the canvas is sent to lisp.)

2. Same as (1), except that before the return in 'opencanvas', we call 
window_main_loop() with the base frame of the created window.  Now the 
canvas responds to the mouse (e.g. the scrollbars work), but (understandably)
the lisp window is dead.  If the canvas's "WIN_INPUT_DESIGNEE" is set 
to lisp's window, keyboard input directed to the canvas is sent to lisp, 
but lisp can't do anything with it, because it's waiting in vain for the
'opencanvas' function to return.

3. Same as (1), except that instead of creating a base frame, I try to use the
window lisp is running in as the base frame for the canvas.  This fails to 
create the canvas, with an error msg. to the effect that a canvas needs a base 
frame.  Any ideas how to get a handle to the base frame of a window created by 
suntools?  I certainly can't find it anywhere in the documentation...

4. Have an independently running C program create a base frame + a tty
subwindow with lisp running in it, and let lisp call window_create to create 
a canvas for lisp to draw on.  But I can't figure out how to pass the base 
frame's handle to lisp.

And some ideas I've had, but haven't figured out how to try:

5. Replace the call to window_main_loop() in (1) above with either the
explicit or implicit dispatching code given in the Sunview Programmer's Guide,
section 16.6.  But since I'm running a lisp interpreter instead of some C
function with an explicit control loop, it's not clear to me how this would
work.

6. Somehow pipe the relevant output of lisp (i.e. calls to the C functions, 
such as pw_vector) to a C program running in a separate canvas window, 
and let the C program read and execute those functions.  But how do
you pipe to a window?  Also, I'm not familiar enough with C to know how the C
program can handle input from both the mouse and a pipe, although this might
not be hard for a *real programmer* :-).

etc. etc.
It just seems like this shouldn't be so hard.  What am I missing?
Oh, and how do you prevent the error msg--
	SunDefaults Error: /SunView/Ttysubwindow/Retained is '-Undefined-'; 
	which is an unrecognized boolean value
--when creating a tty subwindow?

Mike Maxwell
Boeing Artificial Intelligence Center
	...uw-beaver!uw-june!bcsaic!michaelm

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

Date: Fri, 8 Aug 86 12:22:47 -0100
From: prlb2!bernard@seismo.CSS.GOV (Bernard Yves)
Subject: Long Video Cable for Sun 3/160?

	I'd like to extend to about 10 meters the video cable connecting
	the B/W monitor of our Sun 3 160.  Is there anyone who tried to
	do that ?  What is the effect on the video quality ?  What are
	the specifications of the cable he used ?

	Reply to : 
		 Yves bernard ("prlb2!bernard"@seismo.ARPA)

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

Date: Fri, 1 Aug 86 16:42:03 pdt
From: white@ee.UCLA.EDU (Joseph White)
Subject: undump for SUN3's?

Does anyone have a version of the undump program that works on the SUN3.
Thanks in advance.

-Joe White

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

Date: Tue, 5 Aug 86 11:40:48 -0200
From: Jacob Levy  <jaakov%wisdom.bitnet@WISCVM.ARPA>
Subject: Sun/2 Memory Expansion Manufacturers?

We are interested in getting names and addresses of sun/2 memory
expansion makers. We already have a set of sun/2's and are expecting
to get very soon a new set of sun/3. In order that they all will work
on a single Ethernet (that we already have for the sun/2's),
we have to upgrade sun/2 opreating system. To do that one
has to increase sun/2 memory.

We have receive from Sun Inc. suggested prices for memory expansion
and we feel that they are too high and we are subsequently looking for
an alternative. Therefore, if we could get similar compatable memory
expansion elsewhere, it could save us some important $'s.
Your help in letting us know these names is valuable to us and appreciated
in advance.Thank You.

Jacob Itzikowitz,
Site & System Manager
Applied Math & Computer Science Dept.
Weizmann Institute Of Sci.
Rehovot, Israel

P.S. - Please e-mail your responses to          yi@wisdom.bitnet
                                        or      yi%wisdom.bitnet@wiscvm.arpa
                                        or      yi@wisdom.csnet

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

Date: Tue, 5 Aug 86 10:20:02 EDT
From: cjh@CCA.CCA.COM (Chip Hitchcock)
Subject: rental Suns?

   Does anyone know of a place that has color Suns available for short-term
rentals? We are porting a project from Jupiters to Suns and must run a hands-on
class afterwards, for which the single Sun on which we've been working will be
inadequate. The local Sun sales office has all its color loaners (2-3) booked
substantially ahead, and gave us the names of assorted banks which do
6-to-12-month "leases" (presumably hire-purchases), which is a bit stiff for a
3-to-5-day class.

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

Date: Wed, 6 Aug 86 11:25:21 BST
From: Ewgorc@Cs.Ucl.AC.UK
Subject: request for info. about office systems?

Does anyone have any information on Office Systems software for Sun 
IIIs ?  I'd like to hear of any packages for use on a Sun III network
with a Sun laserwriter which provide any or all of the following 
features.......
	a graphics editor
	a word processor
	a spreadsheet.

Thanks in advance.

John Connors
BP Research Centre
Sunbury-on-Thames, England

P.S. I know a bit about SunAlis so any comparisons would help.

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

Date: Wed, 6 Aug 86 13:33:20 EDT
From: dms@raisin-bran.ai.mit.edu
Subject: VME to VME bus adapter for Sun-3?

I was wondering if anyone has hooked up a VME to VME bus adapter on a
Sun-3? What I'd like to do is extent the Sun-3's bus to a standard
sized VME backplane. I'd like recommendations on VME bus adapter
boards and any hints on what might go wrong when I try to do this. 

Thanks!
				-Dave

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

Date: Thu, 7 Aug 86 12:21:10 pdt
From: Herb Barad <barad%brand@usc-oberon.ARPA>
Subject: Apple personal modem and uucp?

I am trying to hook up an Apple personal modem to a Sun.  I have
succeeded in getting the modem hooked up and running tip, but uucp
is not happy with it.  The Apple personal modem has a mini-8 connector
on it and the Sun has a 25-pin.  The Sun manual tells me that is wants
signals in pins 2-8 and 20.  Do the proper signals come out of the
Apple modem.  What should the cable look like.  I'd appreciate any
help.

PS: Please me a response as I do not usually read these groups.

				Thanks........
-- 

Herb Barad	[USC - Signal and Image Processing Institute]

USENET:		...!sdcrdcf!usc-oberon!brand!barad			or
		...!mcvax!seismo!sdcsvax!sdcrdcf!usc-oberon!brand!barad

ARPANET:	barad%brand@USC-ECL.ARPA

USMail:		Univ. of Southern California
		Powell Hall 306, MC-0272
		Los Angeles, CA 90089-0272
		phone: (213) 743-0911

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

Date: Fri, 8 Aug 86 09:06:42 PDT
From: gerolima@Ford-wdl1.ARPA (Mark Gerolimatos)
Subject: Ghosts and such?

Ever noticed that when you quit suntools, you often get ghost
users appearing to be using up swaydo-ports? These are just entries
in Mr. /etc/utmp which were never cleared. This often happens when
/bin/*sh is not exited nicely (!(exit || kill - HUP)).

My question is: doesn't suntools kill all it's processes with
HUP before exiting?


	"For almost a quarter of a century..."

"...Change Baby, Don't Worry!...	Mark Gerolimatos
 ...Welcome! Welcome!... 		ARPA:	gerolima@ford-wdl1.arpa
 ...Change Baby, Don't Worry!...	UUCP:	{sun,fortune}!wdl1!gerolima
 ...Box! Box! Box! Box!...		AT&T:	(415) 852-4105
 ...Now, We Say Good-Bye...		Mail:	c/o Ford Aerospace
 ...Welcome to the GALATT...			3939 Fabian Way
 ...G-A-L-A-T-T We're GALATT..."		Palo Alto CA 94306
 -English phrases from a Japanese song		Mail Stop X20

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

Date: Fri, 8 Aug 86 18:55:50 EDT
From: "William P. Caloccia" <caloccia@ccv.bbn.com>
Subject: unix network/kernel changes ? errors ? bugs ?

I'm porting code to support the HMP protocol,
from a Sun-2 running SunOS 1.3, to a Sun-2 running  SunOS 3.0.

The code was running on the Sun with the earlier OS, but will not
work on the Sun 3.0.

In particular, the problem appears on the input side, after processing
by hmp_input().

	hmp_input() gets called from the IP layer to extract
	struct sockaddr info from the packet. It then calls sbappendaddr(),
	and if successful, it invokes sorwakeup().

The mbuf chain appears ok until the call to sbappendaddr, and sbappendaddr
 seems to work ok.

Problem #1: the (privledged) user program's recvfrom() gets correct
 information in the struct sockaddr, but receives NO data when there IS data.

Problem #2: apparently if the total data in the incoming hmp packet is very
 short (say 8 bytes), then the system crashes with a "PANIC: RECEIVE 2A"
 apparently from soreceive(). (so the mbuff chain appears to get munged)

Does anyone know of any changes in the sun network code (between
 versions 1.3 and 3.0) that might cause this program to break ?

Have any of the data structures (mbuf, sockaddr, socket, sockbuf)
 or calling procedures changed (hmp_input, sbappendaddr, sorwakeup) ?

thanks,
--bill	(caloccia@bbnccv.arpa)

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

Date:    Mon, 11 Aug 86 16:41 EDT
From: <BSD%PSUVM.BITNET@WISCVM.ARPA> (Scott Dickson 863-0422)
Subject: UREP for Sun 3/160?

I have heard from a very reliable source (the author) that
there exist ports of UREP (Un*x RSCS Emulator Program) to Sun 3/160's
Does anyone know of one?  Where can I get it?  How much does it
cost?  Sun was not particularly helpful when I talked to them
about this.

--Scott Dickson

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

Date: Tue, 12 Aug 86 12:09:35 EDT
From: mrz@BRL.ARPA
Subject: Menus in 3.0 Suncore graphics window?

	Does anybody know if it is possible to have a popup menu in a
Suncore graphics window?  According to the Sunview programers guide(3.0), 
the function menu_show() requires that you pass it the pointer to the event
queue (page 208).  But in the Suncore reference manual it is stated that the
event queue is not supported and all input is synchronous (page 9 & 97).

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

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