Sun-Spots-Request@RICE.EDU (William LeFebvre) (12/15/87)
SUN-SPOTS DIGEST Monday, 14 December 1987 Volume 5 : Issue 69
Today's Topics:
ARPANet problems made accessing archives difficult
Re: rasfilter8to1
Re: Use of 4.2 stuff on Sun OS
Re: Licensing question
Re: SunOS and Sun 2's
Re: NFS over arpanet
rstatd
compiler(iropt) error: find_parent: couldn't find parent
Bug in Sun 3.x lint is still there in 3.4
Process limit under Sunix (various)
ntext on Suns
CDC 9720 SCSI Drives
LaserWriter Drivers
Diffs to rcs distribution for Sun's
Sun screendump filter for Epson printer?
conversion from VAX to Sun?
VAX floating point to IEEE conversion?
Text-retrieval program?
----------------------------------------------------------------------
Date: Mon, 14 Dec 87 16:00:54 CST
From: William LeFebvre <phil@Rice.edu>
Subject: ARPANet problems made accessing archives difficult
My apologies to everyone who unsuccessfully tried to FTP archive material
from "titan.rice.edu" last week. I received several notes from
disgruntled readers complaining that they could not sustain (or open) a
connection with titan. I understand that some official ARPANet types were
testing out a new protocol and that it was causing us connectivity
problems. I also understand that our IMP crashed at one point (probably
unrelated to the testing). But things seem to be running smoothly now, so
everyone can try once again to FTP things from titan. Thanks for your
patience.
William LeFebvre
Department of Computer Science
Rice University
<phil@Rice.edu>
------------------------------
Date: Wed, 2 Dec 87 12:27:09 GMT
From: Steve Platt <steve@mrc-apu.cam.ac.uk>
Subject: Re: rasfilter8to1
I'm obviously not the only one to try the -d option in rasfilter8to1!
Sun tell me this is a feature caused by "upgrading" to 3.4... The script
should link rasfilter8to1 (and a few other commands) to the new binary
"screendump" - try it, you'll be amazed how much screendump can do.
Others inclded clear_colourmap and screenload, I think.
I gather the "install" gets it right ...
Steve Platt
[[ I hear that 3.4 is just filled to the rim with "features". --wnl ]]
------------------------------
Date: Wed, 2 Dec 87 08:28:08 PST
From: weiser.pa@xerox.com
Subject: Re: Use of 4.2 stuff on Sun OS
Regarding Keith's comments that: "You should be able to extend your unix
32/v, systemIII, or system V license that you had to acquire in order to
receive 4.2 on your vax to cover your sun as well. This should not be
very expensive (something like $400)."
That is the University price, of course. The commercial price for
extending a license seems to be quite a bit higher, and there doesn't seem
to be a way to do lots of machines at once for a single price, as there is
for Universities.
-mark
------------------------------
Date: Wed, 2 Dec 87 16:09:24 EST
From: mnetor!utzoo!henry@uunet.uu.net
Subject: Re: Licensing question
> We have a vax running 4.2 and several suns. We have a source license for
> the vax, but not the suns. Can anyone tell me whether it would be legal
> to transfer part of the source to our suns and compile it there (with
> modifications)? If not, how about cross compiling on the vax and copying
> the .o files?
If the Suns are not source-licensed, then you are violating your license
if you put any licensed source on them. Furthermore, you should read the
fine print on your non-source licenses very carefully: I think they
usually say that updates to the licensed software must come from your
vendor, or words along those lines. That is, no, you can't cross-compile
on the VAX and copy the object modules. If you want those Suns to have
the benefits of a source license, you're going to have to get them
source-licensed -- that is the idea behind the rules. No cheating, or
AT&T will push their magic button and melt your telephones! :-)
Henry Spencer @ U of Toronto Zoology
{allegra,ihnp4,decvax,pyramid}!utzoo!henry
------------------------------
Date: Wed, 2 Dec 87 08:32:41 PST
From: path@sun.com (Pat Harding)
Subject: Re: SunOS and Sun 2's
Responding to the following inquiry from Don Speck:
It makes perfect sense that Sun-2's won't be supported by
SunOS 4.0, at least not with the current boot proms. Sun-2's
boot by requesting sectors 1 through 15 of public net-disk
zero (ndp0); but ND is slated to disappear in SunOS 4.0, so
this won't work any more. Will new proms be available to
make Sun-2's boot via tftp, like Sun-3's? At what cost?
Don Speck speck@vlsi.caltech.edu {amdahl,scgvaxd}!cit-vax!speck
Good news!! As I have previously assured this forum, SunOS 4.0 will
support Sun-2s (and has been doing so internally for many months.) True.
We did have to add code to simulate the missing functionality so that
Sun-2s can boot. This added nominal overhead to the boot code and
requires no PROM changes for the Sun-2s.
[[ Ahhh, but how much memory will the Sun-2 need to run 4.0? --wnl ]]
------------------------------
Date: Wed, 2 Dec 87 14:49:21 PST
From: rob@presto.ig.com (Rob Liebschutz)
Subject: Re: NFS over arpanet
While casually playing around during a recent visit to Rutgers, I was able
to sucessfully mount and access an NFS file system over the Arpanet
(cross-country). Things were a bit slow and I experienced timeouts, but
it did work (and that was back when the performance of our Arpanet
connection was quite bad). I didn't even bother to specify anything other
than the default NFS mount parameters.
I was waiting to see if the operator at Rutgers would come running into
the systems office complaining about messages on the console "NFS server
presto.ig.com not responding" what should I do :-).
Rob
------------------------------
Date: Mon, 30 Nov 87 22:39:41 GMT
From: aledm@cvaxa.sussex.ac.uk (Aled Morris)
Subject: rstatd
Is there any documentation for the Sun rpc daemons?
I've been trying to get status information (load av., cpu, disk transfers,
etc.) from the rstatd, using "callrpc". The only documentation I've found
has been the include file <rpcsvc/rstat.h> and the source code for
perfmon. Have I missed something?
The structure "statsswtch" (in rstat.h) has a field
long avenrun[3];
which, I assume, is supposed to correspond to the load average for the
previous 1, 5 and 15 minutes. More by luck than judgment, I found that
the load is actually stored as a fixed-point binary number, with the
binary point at the 8th bit (i.e. 8 places of fraction). So the "real"
load average can be computed by
statsswtch.avenrun[i] / 256.0
Any help on this, and on any of the other rpc daemons would be much
appreciated.
System: Sun-3/160 SunOS 3.4
Aled Morris
Systems Programmer
School of Cognitive Science
University of Sussex
Falmer
Brighton BN1 9QN
England
ARPA/Janet: aledm%uk.ac.sussex.cvaxa@nss.cs.ucl.ac.uk
UUCP: ...!mcvax!ukc!cvaxa!aledm
Tel: +44-(0)273-606755 Ext. 2372
[[ The SUNRPC release announced in the last digest comes with quite a bit
of documentation (on-line manuals and such). Would that suffice? --wnl ]]
------------------------------
Date: Wed, 2 Dec 87 14:17 PST
From: <JON@UCLASTRO.BITNET>
Subject: compiler(iropt) error: find_parent: couldn't find parent
To all,
Yeah, another simple question. I am trying to perform the
following under SunOS 3.2:
% f77 lines.f -c -O
This gets me the following results:
lines.f
linef::
Warning on line 801 of lines.f: local variable w never used
Warning on line 801 of lines.f: local variable wv1ikl never used
Warning on line 801 of lines.f: local variable wv2ikl never used
Warning on line 801 of lines.f: local variable sv1 never used
compiler(iropt) error: find_parent: couldn't fine parent of T[966]
If I remove the -O option, everything works. This is the only source that
does this (other sources also have unused variables). In my shallow
understanding, the error is that the compiler (specifically the iropt
program) is looking for the parent of the process T (process number 966).
However, the number 966 never changes, so it is definitely not refering to
a process created by the compiler. Since the Sun manuals are weak on
diagnostics, I have no clue as to what is happening. Using the -dryrun
option, I get the following:
/usr/lib/f77pass1 -O lines.f /tmp/f77pass1.1318.s.0.s /tmp/f77pass1.1318.i.1.s /
tmp/f77pass1.1318.d.2.s
/usr/lib/iropt -O -fc -o /tmp/iropt.1318.3.none /tmp/f77pass1.1318.i.1.s
rm /tmp/f77pass1.1318.i.1.s
/usr/lib/cg -ffpa -mc68020 /tmp/iropt.1318.3.none > /tmp/cg.1318.4.s
rm /tmp/iropt.1318.3.none
/usr/lib/inline -i /usr/lib/ffpa.il < /tmp/cg.1318.4.s> /tmp/inline.1318.5.s
rm /tmp/cg.1318.4.s
/lib/c2 -20 -dscheduling < /tmp/inline.1318.5.s> /tmp/c2.1318.6.s
rm /tmp/inline.1318.5.s
/bin/as -o lines.o -mc68020 /tmp/f77pass1.1318.s.0.s /tmp/c2.1318.6.s /tmp/f77pa
ss1.1318.d.2.s
rm /tmp/f77pass1.1318.s.0.s
rm /tmp/f77pass1.1318.d.2.s
rm /tmp/c2.1318.6.s
which doesn't look significantly different than any other source. This
same source compiles (with optimization) ok with VMS Fortran. Any
comments/suggestions/personal remarks ;-) are welcome. Is this a typical
failure mode for the optimizer?
Along the same lines, is there any documentation about the above compiling
process available to joe user (i.e. what does each program do, what are
their available options, etc.). Also, explanation of the diagnostics
would be more than helpful.
Thanks,
Jonathan D. Eisenhamer
UCLA Astronomy
jon@uclastro.bitnet
bonnie::jon (SPAN 5828)
(213) 206-8596
"POST NO CODE"- Recently spotted on side of building.
------------------------------
Date: Thu, 3 Dec 87 22:50:58 GMT
From: James Davenport <jhd%maths.bath.ac.uk@nss.cs.ucl.ac.uk>
Subject: Bug in Sun 3.x lint is still there in 3.4
harvard!munsell!jwf@seismo.css.gov said on 16 Jun 87 18:38:48 GMT: There
is a bug in Sun 3.0 and 3.2 lint related to use of static variables
declared in include files. For example, the simple C files shown below
will generate the following bogus lint messages:
$ lint foo.c
foo.c:
foo defined( ./foo.h(1) ), but never used
foo used( foo.c(6) ), but not defined
where foo.h is just
static int foo; /* private variable used by foo.c */
and where foo.c is
#include "foo.h"
main()
{
foo = 42;
(void) printf ("%d\n", foo);
}
Making the variable foo external (i.e., int foo) makes lint happy, but
this violates the principal of information hiding and shouldn't be
necessary.
I assert that this bug is still present in Sunix 3.4
------------------------------
Date: Thu, 3 Dec 87 12:46:09 GMT
From: James Davenport <jhd%maths.bath.ac.uk@nss.cs.ucl.ac.uk>
Subject: Process limit under Sunix (various)
Thanks to era@scdsw1.ucar.edu for pointing this out. In fact the "feature"
#define MAXUPRC (NPROC - 5)
is in Sunix 3.2 and 3.4, as well as the 3.3 you mention. MAXUPRC would be
25 were it not for this piece of insanity. On doing some measurements, I
concluded that 25 was not enough for a window-using user, and have
replaced the above line by
#define MAXUPRC 50
My systems have run for several days with no complaints after I made this
change - I recommend it.
------------------------------
Date: Thu, 3 Dec 87 12:46:09 GMT
From: James Davenport <jhd%maths.bath.ac.uk@nss.cs.ucl.ac.uk>
Subject: ntext on Suns
Dan <@flash.bellcore.com:dan@wind> mentioned that the default for ntext
(24 + MAXUSERS) was probably inappropriate. It certainly is - I have
found that a Sun with this (and MAXUSERS = 4 or less) to be unusable as a
single-user system. Try running tbl | eqn | ptroff. My first hack was to
go to 24+MAXUSERS*2, which improved things, but didn't fix all the
problems. After analysing an "idle" system with one person logged in at
the console running suntools, I decided that 30+MAXUSERS*2 was a better
formula. Since then, no-one has complained (do they dare??).
J.H. Davenport
jhd@uk.ac.bath.maths
------------------------------
Date: Tue, 1 Dec 87 11:41:40 CST
From: shamash!jwabik@umn-cs (Jeff Wabik)
Subject: CDC 9720 SCSI Drives
With all the talk recently regarding the usage of CDC SCSI Drives with Sun
workstations, I decided to give it a shot. My experiment was with a Sun
3/60C and a CDC 9720-500 drive (The 500 is available with an SMD
interface, as well). After a few hours of messing around, I managed to
get the drive to function..
Concerns with implementation:
The SCSI connectors on the rear of the 9720 are NOT the SCSI
connectors you'll find on Sun "bread boxes" (The SCSI boxes Sun
sells that contain st0 and sd0 devices.. ), so you'll need to
improvise.
You MUST specify correct disk physical layout information (no
matter how much "it shouldn't matter") to "diag", else the
drive will hang the system when you "newfs". (1209 cylinders,
10 heads, 69 data sectors/track == 830070 blocks == 424,995,840
formatted bytes (1203 actual data cylinders))
Other than that, after some partitioning and relabelling, everything
worked like a charm, and the drive turned out to be a real screamer.
I'm not in marketing, but the 9720-500 (~500mb unformatted, ~358mb
available to UNIX after formatting and making the filesystem) runs about
5000. Other models of the 9720 drive with identical SCSI interface boards
are available from CDC in capacities from 300MB to 1.2GB. I did not test
the other models.
For the record: These comments and observations are my own, and not
necesarily those of Control Data Corporation. At this time CDC does not
support this particular connectivity, nor would I imagine that Sun
supports or maintains this particular CDC disk drive. To the best of my
knowledge, this the first time this particular experiment has been tried.
This experiment was ONLY conducted on a Sun 3/60C, but Sun tells me that
the 3/50 standard SCSI specs and the SCSI board specs for the upscale Sun
machines are identical. (Which seems to make sense.) Hand-eye comparision
of pin_outs showed them to be exact between the Sun and the 9720.
Also, for the record, my organization within CDC is now gearing up to
install six 9720-500's with 3/60's, thus I/we am/are confident of the
compatibility within our own shop.
I'll be happy to provide additional information on the 9720 or of my
experiments via E/mail.
-Jeff
Jeff A. Wabik @ Control Data Corporation
Corporate Research and Engineering Division.
Bloomington, MN 55440
UUCP: {rosevax,umn-cs,meccts,ems}!shamash!jwabik
Disclaimer: These opinions are my own and not necesarily those of CDC.
Live long and program.
------------------------------
Date: Wed, 2 Dec 87 10:17:08 EST
From: erm@rice.edu
Subject: LaserWriter Drivers
While I don't know much about Sun's re-package of the Adobe drivers, I've
delt with Adobe's TranScript. By and large, it seems to be a solid
product, and they're very good about supporting it. When I encountered a
problem with one of the filters, I had no trouble getting hold of the guy
in charge of TranScript development. He recognized the problem as a known
bug and sent me the corrected source so I could recompile the system.
Worked like a charm. He also told me that that fix, along with many
others (minor and major), were going to be "made public" with the next
major release, which should have occured last month.
By and large, I'd say the up-to-date Adobe stuff is worthwhile. Why Sun
may still be shipping older versions, I don't know.
Evan R. Moore
Williams College
ARPA: erm@cs.williams.edu
------------------------------
Date: Thu, 03 Dec 87 18:16:57 -0500
From: randy@ncifcrf.gov
Subject: Diffs to rcs distribution for Sun's
I offered to make these availible some while back and have come up on the
internet in the meanwhile, so I thought I'd send another note out on the
subject. I have availible the diffs to rcs to make it workable (fix a few
nil-dereferencing bugs, etc.) on the suns. (Credit where credit is due:
These changes were made by Guy Harris at Sun.) They are availible on
ncifcrf.gov (129.43.1.11) via anonymous ftp in directory
pub/rcsfixes.shar.Z. Note that this is not the rcs distribution; that you
have to get through Walter Tichy (see the sun-spots archive on the subject
or contact tichy@germany.csnet). Any problems, send me a note.
-- Randy
Randy Smith @ NCI Supercomputer Facility
c/o PRI, Inc. Phone: (301) 698-5660
PO Box B, Bldng. 430 Uucp: ...!uunet!mimsy!elsie!ncifcrf!randy
Frederick, MD 21701 Arpa: randy@ncifcrf.gov
(may need to use randy@fcs280s.ncifcrf.gov)
------------------------------
Date: 2 Dec 87 17:44:45 GMT
From: carlg@rosesun.rosemount.com (Carl Gansen)
Subject: Sun screendump filter for Epson printer?
I am in need of a filter that allows a Sun 3/60 to do a screendump to one
of the less expensive Epson printers. I have a Microphaser II print buffer
that is capable of doing the serial input/parallel output conversion
coupled to an Epson FX 86e printer. If anybody has developed a filter for
this purpose and is willing to share it, I'd appreciate it.
------------------------------
Date: Wed, 2 Dec 87 20:58:56 AST
From: David Trueman <dalcs!david@uunet.uu.net>
Subject: conversion from VAX to Sun?
We are planning on replacing our VAX 785 running 4.3BSD with a Sun 4.
Given the difference in prices between DEC and Sun, I am sure that many
other sites have done this or are contemplating doing it. I would be
interested in hearing stories (horror or otherwise) about how the
conversion process went. I realize that in many cases the conversion
would have been to a Sun 3, but the process was probably similar. I will
post a summary of what I hear if it is interesting enough.
------------------------------
Date: Wed, 2 Dec 87 17:11:59 PST
From: mday@cgl.ucsf.edu
Subject: VAX floating point to IEEE conversion?
We are in need of a utility to convert files that are in VAX floating
point format to the IEEE floating point format that our new Suns use. I
have tried converting the numbers to ascii, but our 11/750 takes too long
to convert our large data files (10-20 MB) to be of practical use. If
anybody else has done the direct bit manipulation, I would be very
greatful if you would forward sources/insights.
Thanks,
Mark Day
UUCP: ..ucbvax!ucsfcgl!mday
ARPA: mday@cgl.ucsf.edu
BITNET: mday@ucsfcgl.BITNET
------------------------------
Date: 3 Dec 87 9:02 +0100
From: Igor Metz <metz%iam.unibe.ch@relay.cs.net>
Subject: Text-retrieval program?
We are looking for a text-retrieval program for our Sun (pd preferred).
With 'text-retrieval program' I mean a program that can index the words in
a text-file (ascii) and provides some type of access to the indexed data.
In this sense grep and awk are "trivial" examples of text-retrieval
programs. Such a program should read a stopword file (file of words to be
skipped while indexing, eg. "the", "a", "and" etc.).
Such a program could be used to search big files (like the SUN-SPOTS) for
keywords (eg. find message where the body contains keywords "environment"
and "pascal", but does not contain the keyword "TeX"), or it could be used
to build thesauri etc.
Thanks in advance, Igor
Igor Metz EAN: metz@iam.unibe.ch or metz@iam.unibe.chunet
Institut fuer Informatik or iam.unibe.ch!metz@seismo.CSS.GOV
und angewandte Mathematik UUCP: ..!uunet!mcvax!iam.unibe.ch!metz
Universitaet Bern BITNET: u04z@cbebda3t.bitnet
Switzerland Phone: (+31) 65 49 02
[[ Such a thing would be useful to help people find things in the archived
Sun-Spots digests. Sadly, there is no mechanism to do so right now.
--wnl ]]
------------------------------
End of SUN-Spots Digest
***********************