Sun-Spots-Request@RICE.EDU (William LeFebvre) (05/26/88)
SUN-SPOTS DIGEST Wednesday, 25 May 1988 Volume 6 : Issue 99
Today's Topics:
Re: SUNOS 4.0 IS HERE (2)
Re: Sun/LISP/KEE/68881 problems...
Re: ESTALE?
Re: NFS disk block sorting?
Decnet mailer for Suns
TIOCCONS (+program)
Miranda for the SUN
Xylogics 753
Send contributions to: sun-spots@rice.edu
Send subscription add/delete requests to: sun-spots-request@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@rice.edu" or mail the word "help" to the same address
for more information.
----------------------------------------------------------------------
Date: Mon, 23 May 88 17:48:54 mdt
From: era@scdpyr.ucar.edu (Ed Arnold)
Subject: Re: SUNOS 4.0 IS HERE (1)
In v6n93, Steve Blair <ascway.UUCP!scb@spar-20.spar.slb.com> writes:
>3) If you've not taken the time to read the following, you'd BETTER:
>
> Sun p/n: 800-1753-06 System Services Overview
> this manual is for understanding what the re-write means to YOU!!
>
> Sun p/n: 800-1732-15 Installing the SunOS
> this manual is to try to help you install this major release!!
>
>These are available from your Sun salesman by special request. That's how
>I got mine.
Whoooa there. If your Sun salesman is like ours, chances are he's got too
many things to do, so doesn't need requests for something you've already
got (or are about to get). The above are part of the full manual
shipment:
"Installing the SunOS" is in the System Administration Manuals minibox;
"System Services Overview" is in the Reference Manuals minibox.
------------------------------
Date: Sat, 21 May 88 20:59:08 EDT
From: umix!lokkur!scs@rutgers.edu (Steve Simmons)
Subject: Re: SUNOS 4.0 IS HERE (2)
It must be something about working for Schlumberger (hi Steve!). Ours
arrived last Wednesday the 18th as well. We had a beta (release 1) copy
for a while, and so had a few things on trips ready for testing:
Number one surprise was the reduction in disk space usage. My copy fits
quite comfortably (*all of it*) on a 2x70 shoebox. I expected a drop, but
not this much. I've still got 40-50MB to play with! It's now running on
a 3/50.
The use of the SysV cron is a real blessing. Dig out your manuals and
read about it. *Warning* -- if you use edcron (or whatever the durned
utility is called) improperly, you can blow away your cron file. Watch
out.
The system logger is another real improvement. It does wonders for
debugging maintainance scripts. Not sure if its sysV or what, but it's
definately better.
Bad point: system paging rates are definately increased. It's much better
than the beta release was, but still higher than 3.X. I suspect more
memory will give you a bigger performace improvement under 4.0 than 3.X --
but be sure and use those shared libraries. A couple of 65Kb programs
under 3.X compiled at about 40K under 4.0. Expect huge savings on
programs that use the window libraries. Are the shared libraries hard to
use? I dunno, I just compiled with my existing makefiles and there they
were...how nice.
>1) Unbundled s/w means you'd better get the stuff ordered now(i.e. NeWS, lisp
> f77vms, etc)
This is a *big* issue for us. We *need* f77 and pascal for our products.
You may too.
>2) You should have gotten a letter from SUN stating the "schedule" for
> shipement of unbundled s/w. Some of it like lisp is "TBA" meaning you
> better really read the info from them SEVERAL TIMES before considering
> SUNOS4.0.
I second and third this. We are now going through an exhaustive testing
cycle of all our products under 4.0. No results yet.
Down point: my 8mm tape drive doesn't read tapes written under 3.X/4.0
beta. I've not tried writing new ones yet. This is especially
distressing since it worked under the beta. Darn...
The install procedures are much better. Much better. You can exit the
install process, come back later, and it remembers where you were. The
interface isn't as pretty (termcap rather than sunwindows) but is the same
for all consoles. Error messages get saved reasonably. Some tape errors
are actually recoverable. You can put /usr on the second disk easily
right from the start.
The re-organisation of the file system is actually much less pain than I
expected. It took all of one day to get used to it. Besides, it's
something that's looong overdue for UNIX. I'm surprised at some of the
pieces they didn't change, tho -- I think there's still a /usr/ucb, for
example. And there's no justifiable reason for keeping the SysV stuff in
separate directories, given the stated goal of SVID conformance.
Intermixing our 3.X network and converting to 4.0 will be cumbersome but
doable. When we firm up plans I'll publish a note on how we handle the
intermixture of the new and old filesystem organizations. We've got some
ideas, but we'll see what actually stands the test of time.
And for those of you who want to ask me questions: I'm now on two weeks
vacation. But I'll be very interested in hearing about your results in
Sun-Spots!
Steve Simmons
UNIX Systems Mgr, Schlumberger CAD/CAM
simmons@applga.uucp (work)
scs@lokkur.uucp (home)
------------------------------
Date: Mon, 23 May 88 11:46:11 MDT
From: roberts%studguppy@lanl.gov (Doug Roberts @ Los Alamos National Laboratory)
Subject: Re: Sun/LISP/KEE/68881 problems...
Well, with some help from Sun (thanks, Alan) and a lot of digging we found
out what caused our LISP floating point problem. First, to summarize the
problem I had reported: While optimizing some old CL code to take
advantage of the Sun 3/260 68881 math co-processor, we kept experiencing
difficult-to-explain segmentation violations at run time. Numeric garbage
(very large or small numbers) was also resulting from declaring certain
variables as single-float. To set the stage for this little debugging
episode: the piece of code that was causing the trouble was part of a
large KEE application (~800 - 900 KEE units): the total size of the
application is approximately 6 MB of source and it is about two years old
by now, and represents approximately 10 man-years of development time. The
application was originally developed on a Symbolics 3600.
The cause of the problem: one of the variables in the problem code was
bound to data incorrectly defined in a KEE data structure. The offending
data point (supposedly single-float numeric data) was contained in a KEE
slot that had a value class of list. The slot contains X multi-element
lists, where each element is supposed to contain single-float data. ONE of
the list values had been entered (two years ago) as 0 instead of 0.0.
Now, since it has been repeatidly demonstrated that this is a very
powerful forum where customers can voice their concerns/displeasure/etc.
and be assured of their message being heard by the people who count (the
vendors), I'd like to offer a suggestion to the Lucid folks: Improve your
LISP debugging facilities. Admittedly, I am spoiled by the powerful
source-level window debugging tools provided on a Symbolics. However, I AM
familier with the use of the Lucid debugger provided with KEE on Suns, and
I found it to be of limited usefulness in tracking down this problem. The
backtrace facility WAS usefull in pointing to the function that had caused
the segmentation violation, and the verbose frame inspector did indicate
that a variable had been bound to out-of-range numeric data. But I was
unable to make the mapping between the inspector's arbitrary variable
renaming scheme (ex. Local 6:) and the actual local variable name that was
experiencing the data problem. As a result, I had to spend an unreasonably
lengthy period of time diagnosing this problem.
To compound the problem of the less-than-friendly debugger, Lucid's Emacs
has limited in-line debugging capabilities. For example, you can't save
keyboard macro definitions! There is almost no mouse support! These two
deficiencies make mark/yank/cut/paste/evaluate operations hopelessly
cumbersome. (Try looking at Gnu EMACS to get a feel for a fully functional
EMACS.)
It is because of these generally-recognized short-comings in the Lucid
LISP development environment that Sun has embarked on the SPE project
(where is our beta version, by the way?). I also hear that Franz is
beating on Sun's door with their CL (and improved debugging facilities?).
However, none of this is very helpful to us right now!
--Doug
Douglas Roberts
Los Alamos National Laboratory
(505)667-4569
dzzr@lanl.gov
------------------------------
Date: Mon, 23 May 88 14:10:55 PDT
From: sxn@sun.com (Stephen X. Nahm)
Subject: Re: ESTALE?
Reference: v6n91
>You might consider using the network lock manager to coordinate the rename/stat
>sequence. You could use a second file as a lock file and only rename or stat
>the file when you (the client or server) own the lock. (Use flock, not
>fcntl.)
What I meant to say was, "Use fcntl (or lockf), not flock." Sorry for the
confusion.
Steve
------------------------------
Date: 23 May 88 16:47:27 GMT
From: lmb%vsi1@uunet.uu.net (Larry Blair)
Subject: Re: NFS disk block sorting?
Is it true that a local machine will reorder disk requests when reading or
writing an NFS-mounted filesystem, as stated in Sun-Spots v6n94? We use
Interphase 4200 SMD controllers on our main server. Because the 4200 does
readahead caching, we have maxcontiguous set to 16 (i.e. tunefs -a 16) on
all of our filesystems. This gives us a more than 2 to 1 improvement in
read speeds. If NFS on the client is reordering the reads or writes, it
would dramatically slow down throughput.
Question: if a client does reorder disk accesses, does it know about
changes to latency and contiguity parameters on the NFS filesystem? If
not, how do I get it to stop reordering?
Larry Blair +1-408-432-8660
VICOM Systems Inc. sun!pyramid----\
2520 Junction Ave. uunet!ubvax----->!vsi1!lmb
San Jose, CA 95134 ucbvax!tolerant/
------------------------------
Date: Mon, 23 May 88 10:24:08 PDT
From: sunncal!leadsv!laic!darin@sun.com
Subject: Decnet mailer for Suns
[[ From the README file: ]]
OK, here is my mailer for use with Sunlink/DNI. You may use this with or
without sendmail, although using it with sendmail is much more convenient
(although it requires changes to the sendmail configuration files.)
1) Read dnamail.doc for instructions
2)
The patch files should work with the default 'sendmail.cf' files
off of the Sun distribution tape. If not, you can install the
patches by hand. Be SURE to keep the ".orig" files around in
case of problems.
4)
Let me know of any problems you have setting this up, or of any bugs.
This way I can either fix the code, or fix the documentation.
Note the copyright restrictions (as small as they are). Of course,
if Sun is negotiable, I may let them have it ;-)
Darin Johnson
Lockheed Missiles & Space
(...lll-lcc.arpa!leadsv!laic!darin)
(...ucbvax!sun!sunncal!leadsv!laic!darin)
[[ The shar file is in the archives as "sun-source/dnamail2.shar" and is
48342 bytes long. It can be retrieved via anonymous FTP from the host
"titan.rice.edu" or via the archive server with the reqeust
"send sun-source dnamail2.shar". For more information about the archive
server, send a mail message containing the word "help" to the address
"archive-server@rice.edu". --wnl ]]
------------------------------
Date: Mon, 23 May 88 19:00:29 BST
From: Aled Morris <aledm%cvaxa.sussex.ac.uk@nss.cs.ucl.ac.uk>
Subject: TIOCCONS (+program)
Is it possible to connect a slow hardcopy device to the CPU serial port
(ttya) and use it as a console? I couldn't find any method for setting
the speed to 300 baud, as opposed to 9600 baud.
To make up for this, I wrote the following program (see below) which can
be used on a terminal connected to any serial port, the intention being to
catch the console messages and keep a hard-copy. In use, I log in on the
teletype (connected to port B) and type "console /dev/ttyb".
Its good at recording problems like NFS timeouts, and BADSU requests. I
haven't yet had a system crash, so I can't report how useful it is at
recording the panic messages. I doubt that it will survive under such
extreme circumstances!
Comments?
Aled Morris
systems programmer
----c-u-t---h-e-r-e----------------------------------------------------
/*****
* NAME
* console - redirect Sun console messages to a named device
* SYNOPSIS
* console ttydevice
* DESCRIPTION
* Console is invoked with a single argument: the name of the device
* to which console messages are to be directed. The program then
* directs console messages via a pipe to the named device.
* FILES
* /dev/console where messages are sent in the first place
* /dev/tty* likely candidates for console message redirection
* BUGS
* The cons(4) driver should permit TIOCCONS directly on terminal
* devices, so there would be no need for the pty/tty pair.
* If Sun permitted slow serial-port consoles, this would not have
* been necessary.
* AUTHOR
* Aled Morris, April 1988
*
* Janet: aledm@uk.ac.sussex.cvaxa | School of Cognitive Science
* uucp: ..!mcvax!ukc!cvaxa!aledm | University of Sussex
* talk: +44-(0)273-606755 e2372 | Falmer, Brighton, England
*
* This software is public domain, and can be freely copied or adapted.
* The author would appreciate an acknowledgement on any derived work.
* Send comments/bug fixes, etc. to the above address.
*****/
#include <stdio.h>
#include <sys/ioctl.h>
#include <sys/file.h>
char *progname;
main(argc, argv)
int argc;
char **argv;
{
int in, out, pty;
char ch;
progname = argv[0];
if (geteuid()) {
fprintf(stderr, "Sorry - must be superuser\n");
exit(2);
}
if (argc != 2) {
fprintf(stderr, "usage: %s tty\n", progname);
exit(1);
}
if ((out = open(argv[1], O_RDWR)) < 0) {
perror(argv[1]);
exit(1);
}
get_pty(&pty, &in);
if (ioctl(in, TIOCCONS, 0) == -1) {
perror("TIOCCONS");
exit(1);
}
if (fork())
exit(0);
while (read(pty, &ch, 1) == 1)
write(out, &ch, 1);
perror(progname);
exit(1);
}
/* this code is modelled on (i.e. stolen from) the code in XTERM */
get_pty (pty, tty)
int *pty, *tty;
{
int devindex, letter = 0;
static char ttydev[] = "/dev/ttyXX", ptydev[] = "/dev/ptyXX";
while (letter < 4) {
ttydev[8] = ptydev[8] = "pqrs"[letter++];
devindex = 0;
while (devindex < 16) {
ttydev [9]= ptydev[9] = "0123456789abcdef"[devindex++];
if ((*pty = open(ptydev, O_RDWR)) < 0)
continue;
if ((*tty = open(ttydev, O_RDWR)) < 0) {
close(*pty);
continue;
}
return;
}
}
fprintf (stderr, "%s: Not enough available pty's\n", progname);
exit(1);
}
/* thats all folks */
------------------------------
Date: Mon, 23 May 88 19:02:33 BST
From: dat%ukc.ac.uk@nss.cs.ucl.ac.uk
Subject: Miranda for the SUN
Miranda - release one
---------------------
Miranda is a very pure functional language designed by Professor David
Turner of the University of Kent. It has polymorphic strong typing and
a simple but powerful module system. This is to inform anyone who may
be interested that the first full release of the Miranda functional
programming system is now available for a number of UNIX machines,
including SUN workstations. If you wish to receive a longer piece of
electronic mail telling you more about the Miranda system and how to
obtain it, this can be requested from
USENET: ...!mcvax!ukc!mira-request
ARPANET: mira-request@ukc%nss.cs.ucl.ac.uk
JANET: mira-request@ukc.ac.uk
------------------------------
Date: Mon, 23 May 88 12:17:24 MST
From: grandi@noao.arizona.edu (Steve Grandi)
Subject: Xylogics 753
We are trying to add more disk storage to our Sun-4/280. Currently we
have four SuperEagles spread over two Xylogics 451s. We have a Ciprico
controller sitting on a shelf waiting for a usable Sun-4 driver (wait for
4.0, we are told). We are either going to buy one of the Hitachi or NEC
drives that Sun is using or go with Fujitsu 2372s which we can buy at a
very good price (one Hitachi or NEC gives 0.9 Gb while two 2372s give 1.4
Gb and the cost for the latter configuration is only about $1K more than
the former).
Various vendors assure us that SunOS version 4.0 contains a driver for the
Xylogic 7053 (Sun's new VME disk controller) which is "software
compatible" with the Xylogics 753 which can be sold to one and all.
Having been burnt by our experiences with the Ciprico, I'm a bit worried.
Does 4.0 for Sun-4s include a driver for the Xylogics 7053/753? Does any
one have experience with Xylogics 753s on any Sun?
Steve Grandi, National Optical Astronomy Observatories, Tucson AZ, 602-325-9228
UUCP: {arizona,decvax,ncar,ihnp4}!noao!grandi or uunet!noao.arizona.edu!grandi
Internet: grandi@noao.arizona.edu SPAN/HEPNET: 5355::GRANDI or NOAO::GRANDI
------------------------------
End of SUN-Spots Digest
***********************