Sun-Spots Digest, v6n82

William LeFebvre Sun-Spots-Request at RICE.EDU
Fri May 13 08:41:58 AEST 1988


SUN-SPOTS DIGEST          Thursday, 12 May 1988        Volume 6 : Issue 82

Today's Topics:
                Re: Magic Number for running Diag on 4/110
                     Re: Looking for great CASE tool
                    Re: nifty sun plot program wanted
                         Re: SLIP on a CISCO box
                        Calctool v2.2 Part 1 of 2.
                             SUNOS 4.0 Notes
               Sun Common Lisp and FPA don't work together
                            bug in socketpair
                      More clock problems on a 3/50
                  curious behaviour of read() on devices
                         Cheap terminal servers?
                         Unix disk partitioning?

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:    Fri, 6 May 88 15:36:54 PDT
From:    Jordan Hayes <jordan at ads.com>
Subject: Re: Magic Number for running Diag on 4/110

	The address of the Emulex SCSI controller on the mainbus is
	A000000.  That's (A for apple and Six Zeros).  I hope this
	helps somebody.

The real tricky part about this was that the driver is not sc0 or si0 but
rather a new sw0 ... of course, not documented anywhere either.  In the
docs, there is GENERIC kernel config file, and I looked at it and matched
the numbers, but didn't see the sw0/A000000 stuff until a frustrating hour
later ...

/jordan

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

Date:    Fri, 6 May 88 10:30:19 PDT
From:    ultra!ted at ames.arc.nasa.gov (Ted Schroeder)
Subject: Re: Looking for great CASE tool

Try Atherton Technology's Software BackPlane.  Although it doesn't do
everything you suggest it does most and allows you to take any existing
tools you have and incorporate them into the system at any of several
different levels.

Call, write, or send mail to:

Steve Bauman
Atherton Technology
1333 Bordeuax Dr.
Sunnyvale, CA 94089
(408)-734-9822
sunncal!athertn!steve at sun.com

      Ted Schroeder                   ultra!ted at Ames.arc.nasa.GOV
      Ultra Network Technologies
      2140 Bering drive               with a domain server:
      San Jose, CA 95131                 ted at Ultra.COM
      408-922-0100


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

Date:    Sat, 7 May 88 11:30:14 EDT
From:    spencer at kazoo.cis.ohio-state.edu (Stephen Spencer)
Subject: Re: nifty sun plot program wanted

Earlier this year, some kind soul posted a program which opened a graphics
window and plotted points sent to it, along with axis labeling, etc.  I
have deleted this program from my directory, unfortunately, and would like
another copy of it.  If the person who originally posted it sees this
message, or if someone out there HAS it, could you send it to me?  Thanks.

Stephen Spencer, Graduate Student
The Computer Graphics Research Group
The Ohio State University (614)292-3416
1224 Kinnear Road, Columbus OH 43212

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

Date:    Sun, 8 May 88 23:27:13 EDT
From:    rick at seismo.css.gov (Rick Adams)
Subject: Re: SLIP on a CISCO box
Reference: v6n73

	From:    William Westfield <BILLW at mathom.cisco.com>

	The cisco Terminal server supports SLIP to end nodes only.  In
	particular, you can not have another network behind your sun 4
	and expect to route traffic between the two nets over the slip
	link.  Essentially, the cisco allows you to connect hosts via
	SLIP, but not networks.

	.....[text deleted]

	This version is compatible with 4.3bsd slip.

These two statements are contradictory. If it is truly compatible with
4.3bsd, it should work fine.  It's rather surprising. It should only take
a few entries in the routing tables to make it work "completely".  Pity.
We were considering buying one for exactly the application that it doesn't
support.

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

Date:    Wed, 4 May 88 15:55:41 EST
From:    rburridge at sun.com (Rich Burridge)
Subject: Calctool v2.2 Part 1 of 2.

This is the latest release of calctool, a desktop calculator for the Sun.
No new features, just an additional graphics interface for NeWS as well as
SunView. It has been sent to Sun-Spots for archiving purposes; it has also
been sent to comp.windows.news. Please no requests for a copy from me
(unless you are in Oz).

This is my very first NeWS program and I suspect the NeWS code is
pathetic.  I'd very much appreciate any suggestions for improvements with
this. I have two immediate questions for NeWS programmers out there:

(1) The calctool icon should only be 42 pixels wide. What is the
    coding sequence to stop it adopting a 1:1 ratio with the height?
(2) How can I easily construct and set a cursor image from an image file as
    opposed to one of the default cursor types?

All bugs and suggestions to me please. This has been tested under SunOS
v3.5, SunOS v4.0(beta)1 using NeWS v1.1.

To compile the SunView version, type "make sunview"; to compile the NeWS
version, type "make news".

    Rich.

Rich Burridge,           JANET richb%sunaus.oz at uk.ac.ucl.cs
ACSnet  richb at sunaus.oz  UUCP {uunet,hplabs,mcvax,ukc}!munnari!sunaus.oz!richb
PHONE: +61 2 436 4699    ARPAnet rburridge at Sun.COM
Sun Microsystems, Unit 2, 49-53 Hotham Pde, Artarmon, N.S.W. 2164, AUSTRALIA.

[[ The two shar files have been stored in the archives under "sun-source"
as "calctool2.shar.1" and "calctool2.shar.2".  This should not be confused
with the calctool written by Chuck Musciano.  They can be retrieved via
anonymous FTP from the host "titan.rice.edu" or via the archive server.
For more information about the archive server, send a mail message
containing the word "help" to the address "archive-server at rice.edu".
--wnl ]]

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

Date:    7 May 88 00:05:51 GMT
From:    tekbspa!joe at uunet.uu.net (Joe Angelo)
Subject: SUNOS 4.0 Notes


Attached is a -ms nroff file describing SunOS 4.0; I belive that I have
permission to publish this information, it was released to me by Sun
technical personal.

So far, over 204 people have replied requesting this information. It is my
feeling that *this many people* deserve to know what's going to happen. 

I sincerely hope this information is of use to alot of people.

Joe Angelo

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

[[ Stored in the archives as "sun-spots/4.0-notes.ms".  This is NOT a shar
file.  Retrieve the file and read the introductory comments to figure out
what to do with it.  It can be retrieved via anonymous FTP from the host
"titan.rice.edu" or via the archive server with the request
"send sun-spots 4.0-notes.ms".  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:    Fri, 6 May 88 23:18:11 CDT
From:    smu!leff at uunet.uu.net (Laurence Leff)
Subject: Sun Common Lisp and FPA don't work together

Sun Common Lisp and our Floating Point Accelerator are incompatable.  To
wit, when we do a "MAKEDEV /dev/fpa" and reboot, the behavior indicated
below occurs.  Note that this will occur with any 70 or more line program
that defines a couple of functions.  Small programs run OK.  Programs that
create big lists run OK.  Whatever space is needed for function
definitions just runs out quickly.  A program that keeps redefining the
same function over and over again runs OK.

When remove /dev/fpa, we can use LISP properly.

We are mystified!

Script started on Fri May  6 21:37:04 1988
mickey% lisp 
;;; Sun Common Lisp, Version 1.2, 13 June 1986
;;;
;;; Copyright (c) 1986 by Sun Microsystems, Inc.  All Rights Reserved
;;;
;;; This software product contains confidential and trade secret
;;; information belonging to Sun Microsystems.  It may not be copied
;;; for any reason other than for archival and backup purposes.

> (load "test.l")
;;; GC: 7566 words [30264 bytes] of dynamic storage in use.
;;; 74102 words [296408 bytes] of free storage available before a GC.
;;; 155770 words [623080 bytes] of free storage available if GC is disabled.
;;; GC: 9866 words [39464 bytes] of dynamic storage in use.
;;; 71802 words [287208 bytes] of free storage available before a GC.
;;; 153470 words [613880 bytes] of free storage available if GC is disabled.
;;; GC: 41858 words [167432 bytes] of dynamic storage in use.
       .
       .
       .
       .
;;; 39810 words [159240 bytes] of free storage available before a GC.
;;; 121478 words [485912 bytes] of free storage available if GC is disabled.
;;; GC required to re-organize memory for GC disabling
;;; GC: 41858 words [167432 bytes] of dynamic storage in use.
;;; 39810 words [159240 bytes] of free storage available before a GC.
;;; 121478 words [485912 bytes] of free storage available if GC is disabled.
>>Error: Not enough storage after GC.

GC:
   Optional arg 0 (SIZE): 159312
   Optional arg 1 (DONT-WORRY): NIL

:A    Abort to Lisp Top Level
:C    GC will be disabled: 
CONSers will use the storage normally reserved 
for copying currently allocated dynamic storage.
The next GC might fail.
-> :a
;;; Abnormal exit of load "test.l"
Back to Lisp Top Level

> (quit)
mickey% ^D
script done on Fri May  6 21:42:43 1988
________________________________________

How test.l looks

(defun barf1 (test)
(setq temp1 nil)
(dotimes (i test)
  (setq temp1 (cons 'a temp1))
)
)
(defun barf2 (test)
(setq temp1 nil)
(dotimes (i test)
  (setq temp1 (cons 'a temp1))
)
       .
       .
       .
       .
(defun barfr(test)
(setq temp1 nil)
(dotimes (i test)
  (setq temp1 (cons 'a temp1))
)
)
(defun barfs(test)
(setq temp1 nil)
(dotimes (i test)
  (setq temp1 (cons 'a temp1))
)
)

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

Date:    Fri, 6 May 88 21:45:28 +0200
From:    mcvax!corto.inria.fr!vassili at uunet.uu.net (Vassilis Prevelakis)
Subject: bug in socketpair

We have SunOS 3.4 and we have observed the following incompatibility
between the BSD4.3 socketpair(2) and the one in SunOS.

The problem is in the return value of socketpair; according to the manual
"A 0 is returned if the call succeeds, -1 if it fails."

Under BSD this is indeed the case, but under SunOS it returns the file
descriptor of the second socket of the pair.

To get around this problem don't test for 0 but for -1.  This is what most
people do anyway.

Anybody knows if it has been fixed in later revisions?

Vassilis Prevelakis (vassili at corto.inria.fr)

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

Date:    Sun, 8 May 88 17:42:37 +0300
From:    <ronen at TAURUS.BITNET>
Subject: More clock problems on a 3/50

ndmath!ndcheg!evan at iuvax.cs.indiana.edu (Evan Bauman):
>
> We've had a Sun 3/50 for just about a year, and lately, when we reboot we
> get a message that the clock has lost 29 days.  It also says to please
> check the clock and reset....

tomlin at hc.dspo.gov (Bob Tomlinson) answered:
>
> The "creeping clock" bug just looks different under 3.5.  It's the same bug.
> Install the same fix.

I have the same problem in one of my 3/50. System rel. is 3.4, and the
clock patch is installed. The problem started after we had a mean
electricity breakdown (power was lost and returned a few times in 20
seconds). I assume that some hardware part was ruined.

As I don't have a support contract, I will appreciate any help - am I
right, and  what should be replaced on the board.

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

Date:    Sat,7 May 15:32:53 1988
From:    Mario Wolczko <mario%mushroom.computer-science.manchester.ac.uk at nss.cs.ucl.ac.uk>
Subject: curious behaviour of read() on devices

Recently, and for the second time, I've noticed that the value returned by
the read() system call when applied to a device can be, well, to say the
least, unexpected.

When reading from a plain file, read() is supposed to return the number of
bytes read, which would normally be the number asked for, but may be less.
However, when used with a special file I've found it occasionally returns
*more* than asked for.  The first time I came across this was when
attempting to read from /dev/drum (the swap device); code of the form

	struct user u;	
	...
	if (read(swap, (char *)&u, sizeof(struct user))
	    != sizeof(struct user)) {
		...error handling code...

was signalling that an error occurred.  Upon closer inspection it turned
out that the read() was returning  sizeof(struct user)  rounded *up* to a
multiple of 512 (or maybe 1024; I forget the exact figure).

More recently I've had the same experience with the raw disk device;
requests of n bytes were rounded up to multiples of 512 bytes.

It strikes me that this is rather unusual behaviour; for one thing the
data returned by the call could be trampling over adjacent data
structures.   Is this a bug or has it been re-classified as a feature?  Is
there any definitive statement (apart from the kernel source :-) of which
devices do this?

[[ Have you been able to confirm if it really is overwriting its alotted
buffer?  --wnl ]]

The examples above were all under SunOS 3.2.

Mario Wolczko

Dept. of Computer Science    Internet:   mario%ux.cs.man.ac.uk
The University               USENET: mcvax!ukc!man.cs.ux!mario
Manchester M13 9PL           JANET:      mario at uk.ac.man.cs.ux
U.K.                         Tel:    +44-61-275 2000 extn 6146

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

Date:    Thu, 5 May 88 09:58:18 PD
From:    pixar!unicom!dv at ucbvax.berkeley.edu (Ivade Deviz @ Vern)
Subject: Cheap terminal servers?
Phone:   Work/662-1885, Home/485-6721

We're looking to possibly replace our vaxen.  All of the rest of our
machines are Suns (primarily Sun 2's).  The big plus that the vaxen have
is that they make nice terminal servers.  If we were to replace them with
Suns, we're looking at $3000 for a 16 port SysTech mux.

Is there something cheaper than that?  We're just thinking of cost per
port here, with whatever a sun (sun 3, probably) can handle.

Which brings me to my second question.  How many users (running mostly
mail and emacs, with a rare nroff/psroff) can you put on a sun 3
(standalone) and not have it bog down?

	Thanks for any help.

David W. Vezie, Systems Hacker
{{sun,ucbvax}!pixar,pacbell}!unicom!dv

[[ Our Sun 3/280 supports 25 to 35 people every day and it has very
reasonable response.  Most of them run emacs and read their mail.  Some do
research work:  c compiles, memory intensive lisp-like environments, and
the like.  Most users' files are there and many client machines mount its
main partition via NFS, but it is not an ND server for anyone.  Of course,
it also has 16 megabytes of memory (that makes a difference).  --wnl ]]

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

Date:    4 May 88 19:29:01 GMT
From:    karl at umb.umb.edu
Subject: Unix disk partitioning?

Is it possible to (re)partition a disk (SCSI, in this case) from Unix?
(single-user or timesharing) Or is one forced to back to diag for that
`partition' command?

If it's not proprietary, perhaps someone can tell me how setup does it.
(Since it obviously does relabel the disk.) Therefore, it can be done. But
how?

A semi-related question: `setup' read the disk label if we told it we were
``installing an upgrade''. Then one day, it stopped reading the disk label
ever, and simply always gave the default partitions. (Which is not how the
disk was labeled.) The only event we could think of here that was
concurrent with this was making /usr/lib (also /usr/bin, /usr/etc/, and
/usr/include) a copy of those directories on the file server. However, we
checked if /usr/etc/setup.files (and /usr/etc/setup) had changed, and they
hadn't.  Any ideas on how to force setup to read the label that's actually
on the disk?

Karl.     karl at umb.umb.edu        ...!harvard!umb!karl

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

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



More information about the Comp.sys.sun mailing list