Sun-Spots Digest, v6n114

William LeFebvre Sun-Spots-Request at RICE.EDU
Fri Jun 17 13:22:32 AEST 1988


SUN-SPOTS DIGEST          Thursday, 16 June 1988      Volume 6 : Issue 114

Today's Topics:
                             SUNOS 4.0 Report
                        Re: Question for ksh users
                          Re: How do you use rex
                          Problems with fig-1.4
                       Scrolling multiple canvases?
                      Driver for VME bus extenders?
                 Is there a better Boggletool interface?
                   Question about the newsgroup and YP

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:    Thu, 9 Jun 88 13:43:23 PDT
From:    Steve Blair Wkstn-Support <spar!ascway!scb at decwrl.dec.com>
Subject: SUNOS 4.0 Report

**********************SunOS 4.0 Comments************************************

I have now spent the better part of the last 3 days installing and trying
to understand SUNOS4.0. I have a few comments that will trickle in from
time-to-time to help others who're probably deciding how & when to go to
it.

Installation:

System: 4/280c-32(xy0=280mbSun disk, xy1=Fuji2372-890mb)1/4" tape-local

1) "suninstall" utility: I used it and was not impressed. I really loved
	the old one in the graphics modes it used. If some of you have
	ever had to install a Sun with a serial terminal, you may well
	like it. I have done that when I worked inside of Sun and didn't
	like it one bit. The graphics interfaces provided by the older
	"suninstall" were much better. However, this is a first pass and
	I feel that Sun will listen to our comments.

2) Ease of Installation: I took a 30 minute nap in each tape since 4 tapes
	now= 2 tapes. I did it very late at night and was tired when I started
	and this is a nice feature. Be sure that you're firmware that is
	described in the READ THIS FIRST is compatable!! Otherwise, you can't
	install until you get it.

3) Client Setup: I have (1) 4/110 booting off of this machine at this time.
	I only had to tell "suninstall" a few things to get going. Then when
	I was ready the next morning, I ran their new utility "setup_client"
	to finish. This is really neat as it makes the links, etc, that most
	 used to have to do to install additional clients. I have given this
	4/110 80mb of swap since he'll be a lisp user(whenever it comes avail.)
	and the client runs remarkably well so far.  NFS, YP, and other client
	related stuff worked FINE. Client booted on the FIRST TRY-Yeah!!

4) Filesystem Layout: The filesystem takes a while to get used to, but what
	you find is well worth it! Directories that used to be either embedded
	children, or on top are now easily located(most of the time). I enjoy
	the fact that this looks more like SYS V.3 than 4.X filesystems. Makes
	thinking a trivial task. However, you must be careful as there's links
	all over the place during these transitionary releases. I also enjoy
	not having to login into the client to see if there's a problem in
	his filesystems. I can now 'cd' to /export/... and look at his stuff.

5) Overall Impressions: I really enjoy the speed  of the filesystem. The same
	machine which ran reasonably well for some time on SUNOS Sys4-3.2
	now really runs much faster. Perhaps some of the criticism on the
	"MIPS" of the Sun 4 were to do with some o/s problems in the interim
	releases? The machine even seems faster logging in from my 3/110-12c
	machine. It really screams! I also have a lot more space now. But don't
	be fooled, space that was in "/" is now in "/usr/*". I think we'll see
	some more growth in '/usr' and possibly some more shrinkage in '/'. The
	machine can be seen by NFS & YP with no problems. I have as of 6-8-88
	not turned-on the security features and will be doing so shortly.

SUMMARY:
=========

I credit a lot of folks at Sun for a seemingly well done job. These
operating system changes have been long overdue. The overall quality of
what has been done is really good. Ther's a lot of neat features in this
release that have been only in SYS V for some time now. Stuff like the
'format' @ runtime is one of the biggest wins yet. I have already
re-partitioned one of the disks on this machine and the utility is a
winner. Sun has spent a lot of time and money developing this release. It
appears to have paid-off well. 

Sure, you say there may be some bugs. I haven't played with some stuff
like lightweight processing yet, but you can bet I will.  There as always
will be some bugs in ANY VENDOR SOFTWARE, but that sure doesn't make the
release a loser. However, I sure need SUNLINK DNI, Lisp, & X.25 software
soon. I'm comfident that they'll be out soon(please!!!!)...

Steve Blair
Unix Administrator
Schlumberger-Austin Systems Center

internet: spar!ascway!scb at decwrl.dec.com
uucp:{backbone}!decwrl!spar!ascway!scb

"Ken Thompson has an automobile which he helped design. Unlike most
automobiles, it has neither speedometer, nor gas gage, nor any of the
other numerous idiot lights which plague the modern driver. Rather, if the
driver makes a mistake, a GIANT "?" lights up in the center of the
dashboard". "The experienced driver", says he, " will usually know what's
wrong".

scb

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

Date:    9 Jun 88 16:27:25 GMT
From:    actnyc!jsb at uunet.uu.net (The Invisible Man)
Subject: Re: Question for ksh users
Reference: v6n103

)From:    ksr!benson at uunet.uu.net (Benson Margulies)
)
)I'm running the toolchest ksh atop sunos 3.5 and sys4-3.2.  I changed it
)to call getpwnam to do ~ expansion in tilde.c so that it would grok yp.
)It memory faults in getpwnam every time, for any string....

This has been discussed recently at length in comp.unix.wizzards.  The
problem was ultimately traced to ksh using its own _filbuf() This was
their conclusion:

>From: dupuy at douglass.columbia.edu (Alexander Dupuy)
>Date: 4 Jun 88 11:35:28 GMT

Here's the fix: (credit to Chris Maio for finally tracking this down - why he
has to wait until we started running YP on his workstation I don't know :-)

First rip out the crap in shlib/tilde.c and make it use getpwnam() instead.
(It sounds like you have already done this).

Then, patch sh/io.c (your line numbers will vary).

*** old/io.c	Wed Nov 18 11:17:03 1987
--- io.c	Sat Dec  5 18:19:57 1987
***************
*** 606,611 ****
--- 610,622 ----

  	if ((iop->_flag&_IOREAD) == 0)
  		return(EOF);
+ 
+ #if BUGFIX
+ 	/* will this let us call getpwnam? */
+ 	if (iop->_base == 0)
+ 		_findbuf(iop);
+ #endif BUGFIX
+ 
  	if(fnobuff(iop))
  	{
  		/* unbuffered reads needed for pipes */

This patch is for ksh-i, but it ought to work for the older ksh as well.

@alex
-- 
inet: dupuy at columbia.edu
uucp: ...!rutgers!columbia!dupuy
-- 
		"Notitiae gratia notitiarum"
				jim (uunet!actnyc!jsb)

[[ Thanks also to David Comay <dsc at seismo.css.gov> for sending me a copy
of that article.  He also sent in a handful of other ksh patches.  I will
make them available any day now (honest!).  --wnl ]]

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

Date:    Thu, 9 Jun 88 19:07:07 PDT
From:    sxn at sun.com (Stephen X. Nahm)
Subject: Re: How do you use rex
Reference: v6n103

>I'm mystified still as to what values to give for port0, port1, and port2;
>they correspond somehow to stdin, stdout, and stderr of the remote
>process, but I'll be danged if I know how.  

You stick in the port number of a TCP stream.  You must first create a
stream to use.  This involves using socket(2) to get a socket fd, then
bind(2)ing it to the INET domain, and calling listen(2) to arrange for the
port to be setup so that later on you can accept(2) a connection on it.

Having done this, you can use getsockname(2) to pull out the TCP port
number from the bound socket.  Use this (sin_port) for the rst_port values
of the rex_start structure.  Note: one port can be used for stdin and
stdout; use the same number in rst_port0 and rst_port1.  You'll want a
second socket for the stderr port, though.

After your call to the rex daemon returns successfully, rexd will attempt
to connect(2) to these ports.  If this is successful, rexd will pass the
stdin/stdout/stderr from the process it started for you over these
streams.  Your job is to fill stdin and read stdout and stderr.

To complete the connections to these streams, you have to do an accept(2)
on each port (here's where you use the fd that makeport returned to you).

Finally, you stuff things from the local side into the port0 socket (for
stdin to the remote program) using write, and grab output from the remote
side (its stdout) using read of the port1 socket (usually the same as
port0).  You probably will want to use select(2) to avoid blocking.

In your example, you use callrpc() to talk to rexd.  I suggest you not use
this interface; use the lower level interface instead (clnt_call()).  This
allows you to have better control over the timeout-setting for the
connection.

Steve Nahm
Portable ONC/NFS

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

Date:    Wed, 8 Jun 88 10:16:18 BST
From:    mcvax!gec-epl.co.uk!Don_Ward at uunet.uu.net
Subject: Problems with fig-1.4

We built fig with no problems and initially it worked fine: we were (and
still are) impressed.  Then we noticed problems when reloading previously
drawn sketches - fig gave a segmentation violation.  The problems were
traced by my colleague, James House, to uninitialised variables in read.c.
a context diff follows:

 ***************
*** 204,209 ****
--- 204,213 ----
  	    }
  	a->pen = NULL;
  	a->area_fill = NULL;
+ /*
+  * [dpw] Next line added in case no arrows are present
+  */
+ 	a->for_arrow = a->back_arrow = NULL;
  	a->next = NULL;
  	n = sscanf(buf, "%*d%d%d%d%d%d%*d%*d%f%d%d%d%f%f%d%d%d%d%d%d\n",
  		&a->type, &a->style, &a->thickness, 
***************
*** 428,433 ****
--- 432,441 ----
  	    put_msg(Err_mem);
  	    return(NULL);
  	    }
+ /*
+  *[dpw]	Next line added to cope with single point lines
+  */
+ 	p->next = NULL;
  	if (fscanf(fp, "%d%d", &p->x, &p->y) != 2) {
  	    put_msg(Err_incomp, "line", line_no);
  	    free_linestorage(l);

This fix works fine for us.

Because I didn't want to hit the same problem somewhere else, I also
kludged alloc.h to use calloc() instead of malloc().  If read.c is fixed,
it shouldn't be required, but it also cures our problems without modifying
read.c.  I figured (sic) that I'd rather sketch slightly slower, than do a
sketch and spend time working out why exactly it wouldn't reload.

alloc.h
____________________

/*
 * [dpw] As a cheap (and nasty) way of avoiding 'uninitialised thingy'
 *	problems, all use of malloc has been changed to calloc. The
 *	definitions used to read:
extern char	*malloc();
extern char	*calloc();

#define		Line_malloc(z)		z = (F_line*)malloc(LINOBJ_SIZE)
#define		Spline_malloc(z)	z = (F_spline*)malloc(SPLOBJ_SIZE)
#define		Ellipse_malloc(z)	z = (F_ellipse*)malloc(ELLOBJ_SIZE)
#define		Arc_malloc(z)		z = (F_arc*)malloc(ARCOBJ_SIZE)
#define		Compound_malloc(z)	z = (F_compound*)malloc(COMOBJ_SIZE)
#define		Text_malloc(z)		z = (F_text*)malloc(TEXOBJ_SIZE)
#define		Point_malloc(z)		z = (F_point*)malloc(POINT_SIZE)
#define		Control_malloc(z)	z = (F_control*)malloc(CONTROL_SIZE)
#define		Arrow_malloc(z)		z = (F_arrow*)malloc(ARROW_SIZE)
 *
 *	And have been replaced by:
 */
#define		malloc	Do_*not*_use_malloc /* In case a malloc() call is */
					    /* lurking somewhere	  */
extern char	*calloc();

#define		Line_malloc(z)		z = (F_line*)calloc(1,LINOBJ_SIZE)
#define		Spline_malloc(z)	z = (F_spline*)calloc(1,SPLOBJ_SIZE)
#define		Ellipse_malloc(z)	z = (F_ellipse*)calloc(1,ELLOBJ_SIZE)
#define		Arc_malloc(z)		z = (F_arc*)calloc(1,ARCOBJ_SIZE)
#define		Compound_malloc(z)	z = (F_compound*)calloc(1,COMOBJ_SIZE)
#define		Text_malloc(z)		z = (F_text*)calloc(1,TEXOBJ_SIZE)
#define		Point_malloc(z)		z = (F_point*)calloc(1,POINT_SIZE)
#define		Control_malloc(z)	z = (F_control*)calloc(1,CONTROL_SIZE)
#define		Arrow_malloc(z)		z = (F_arrow*)calloc(1,ARROW_SIZE)


extern char	Err_mem[];
extern char	Err_incomp[];
____________________

Don Ward
Systems Design Division
GEC Electrical Projects Ltd
Boughton Road, Rugby, CV21 1BU.
Email: Don_Ward at gec-epl.co.uk
Tel:   (+44 788  or 0788) 542144

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

Date:    Thu, 9 Jun 88 16:59:21 EDT
From:    gotham!marine!mars!reynolds at sun.com (Brian Reynolds)
Subject: Scrolling multiple canvases?

Is there any way for one scrollbar to scroll more than one canvas
subwindow?  I want to display a scrollable graph with scales on the x and
y axis.  To keep the scales visible when the graph is scrolled I want to
display them in separate canvases.  Each scale canvas would have one
scrollbar.  The y-axis would have a vertical scrollbar and the x-axis
would have a horizontal scrollbar.  When the vertical scrollbar is
scrolled the y-axis scale canvas and the graph canvas would both scroll
vertically, but the x-axis canvas would not scroll.  Thanks in advance.

Brian Reynolds
Technical Analysis Group
Marine Midland Bank
...!sun!gotham!marine!reynolds

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

Date:    9 Jun 88 04:11:13 GMT
From:    ihnp4!umn-cs!mmm!schultz at rutgers.edu (John C Schultz)
Subject: Driver for VME bus extenders?

Does anyone have a vectored interrupt driver for a Bit 3 VME-VME repeater
connected to a SUN?

Some background: We are using a Bit 3 VME-VME bus repeater to extend the
backplane of a SUN 3.  While in general this works pretty good, nicely
isolating the remote bus from the SUN backplane, the current generation of
Bit 3 products does not work well with vectored interrupts.  

Specifically, when a remote interrupt occurs, the BIT 3 answers it and
sends an interrupt to the SUN with a vector of 0XFF.  The interrupt
routine then has to poll the Bit 3 card to get the actual vector in order
to execute the proper interrupt routine.  We are facing the task of
writing the little interrupt routien at 0XFF and I wondered if this was a
solved problem.

Thanks for any help.

   john c. schultz         schultz at mmm.UUCP          (612) 733-4047
           3M Center, Bldg 518-1-1, St. Paul, MN 55144-1000

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

Date:    9 June 1988 1633-PDT (Thursday)
From:    montague at nprdc.arpa (Bill Montague)
Subject: Is there a better Boggletool interface?

Has anyone bothered to modify Boggletool so that a player spells words by
pointing with the mouse rather than by typing?  It seems a shame that the
reasonably functional interface used for Chesstool and Gammontool was not
carried over.

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

Date:    Thu, 09 Jun 88 15:39:19 PDT
From:    Mike Kiernan <kiernan at cory.berkeley.edu>
Subject: Question about the newsgroup and YP

I'm not sure if this is the correct newgroup for me to post this to, so if
it isn't, could you let me know so I can repost it to the right one.
Thanks.

[[ It's the right one.  --wnl ]]

We are running Sun UNIX 4.2 release 3.5 on a Sun 3.  Our version of the YP
server, specifically the password map, doesn't seem to have the data
fields for the office and phone info.  Our yppasswd also doesn't
understand the "-f" and "-s" options to change the finger info, or the
login shell.  Is there a way to get the version that allows you to have
this info and to change it?  It would make things much simpler.  Right now
we have a separate database set up with everybody's name, office, and
phone number in it.

Thanks,

Mike Kiernan

[[ The office and phone number have traditionally been placed in the same
field as the user's full name, separated with commas.  Unfortunately, the
order in which the various pieces of information appear, and the
assumptions and abbreviations made by finger, have never been agreed upon
outside of the Berkeley campus.  --wnl ]]

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

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



More information about the Comp.sys.sun mailing list