Sun-Spots-Request@RICE.EDU (Vicky Riffle) (11/24/86)
SUN-SPOTS DIGEST Monday, 24 Nov 1986 Volume 4 : Issue 32
Today's Topics:
PCNFS notes
Device Independent Troff Previewer (SunTroff)
Re: typesetting previewers for Sun workstations
Re: SUN 3 rdump
complaints about ND and SunView size
Problems with rdump, tcp_{send,recv}space, etc.
Bug in 3.2 /lib/ccom
Common Lisp 1.2 GCs infinitely on Sun3s with fpa
Problems with f77?
Sun 2 monitor problem?
Eikonix digitizing camera on a Sun-3 with VME bus?
videotaping Sun workstations?
Sun-3 hardcopy to LaserWriter (request)?
Sun 2 Workstation monitor 35 meters from CPU?
disks for SUN?
adding an ASCII console?
Diffs for RCS on Suns?
anyone have a "newstool"?
Sun 3.0 Make and VPATH?
maps for Sun?
HPGL to Postscript?
Next release of Sun software -- NeWS?
NFS future enhancements?
-------------------------------------------------------------------------
Date: Sat, 25 Oct 86 09:44:24 cdt
From: knutson@huey.cc.UTEXAS.EDU (Jim Knutson)
Subject: PCNFS notes
We just finished playing with PCNFS for a couple of weeks and here are
some interesting points if you plan to put it on your Suns.
1. PCNFS uses two methods of user validation (login). One is by a daemon
on a server which looks up password entries, and the other is by
yellow pages. If you tell the configuration program that you have a
yellow pages server, it will try to use that method. However, we could
not get yellow pages lookup for validation to work (although it could
do ypcat and ypmatch (same as ypcat | grep). The fix was to explicitly
set the pcnfsd host in the AUTOEXEC.BAT file after the yellow pages
server information is set up.
2. If you don't get a correct validation on the PC side, you are left
as the current uid which initially is root (actually nobody on the Sun
side). This is ok except that there is no logout concept so to reset
the uid on the PC to something other than yourself, you would have to
reboot.
3. All logins in /etc/passwd on your server need to have some sort of
password set. The validation program does do password checking, BUT
it doesn't honor the shell (obviously). That means that the standard
logins like sync and sysdiag (which I hope you have set a password for)
can be logged into without passwords and get a shell.
4. If you run a PCNET and put PCNFS on one of the PCs, it can act as a
gateway for virtual disk on the Sun and lineprinter access from the
Sun. I don't know if telneting will work from the others or not though.
Jim Knutson
ARPA: knutson@ngp.utexas.edu
knutson@huey.cc.utexas.edu
UUCP: {ihnp4,seismo,kpno,ctvax}!ut-sally!ut-ngp!knutson
Phone: (512) 471-3241
------------------------------
Date: Sun 2 Nov 1986 20:02:58 EST
From: Malcolm Slaney <spar!malcolm@decwrl.DEC.COM>
Subject: Device Independent Troff Previewer (SunTroff)
I am nearly ready to distribute a program to preview Device Independent
Troff on a Sun Workstation. I call it SunTroff. The program is
currently in beta test at a couple of sites and has been in use at
Schlumberger Palo Alto Research (SPAR) for several months. I hope to
release the sources to the world in the next week or so.
This program was originally written by Rich Hyde (Purdue) and David
Slattengren (Berkeley) and was nearly all rewritten by myself during
the last year or so. It now runs under SunView and provides the user
with the ability to display a page of the document as a window within
SunTools, search for simple strings and print part of the document.
If you are interested in this program please drop me a note. In return
I will send you a copy of the manual page so you can decide if SunTroff
will do what you expect. I expect to make the sources for SunTroff
available via anonymous FTP. Other forms of distribution are possible
if there is sufficient interest. Please let me know how you would
want to get access to the code.
Malcolm Slaney
spar!malcolm@decwrl.dec.com
malcolm@ecn.purdue.edu
{decwrl,amd,pur-ee}!spar!malcolm
------------------------------
Date: Tue, 4 Nov 86 11:25:55 EST
From: Root Boy Jim <rbj@ICST-CMR.ARPA>
Subject: Re: typesetting previewers for Sun workstations
> I'm looking for a TeX previewer for Sun-3 workstations. If anyone out there
> knows of a previewer for TeX, DVI, Scribe, Impress, or PostScript, please
> let me know.
Try anonymous FTP to `sally.utexas.edu'.
[[Then what??? --Ed.]]
doug
(Root Boy) Jim Cottrell <rbj@icst-cmr.arpa>
I had pancake makeup for brunch!
------------------------------
Date: Tue, 28 Oct 86 04:37:05 EST
From: Chris Torek <chris@mimsy.umd.edu>
Subject: Re: SUN 3 rdump
>>When I increased [tcp_sendspace and tcp_recvspace] to 4k per send/recv
>>socket, the performance jumped up .... This does not need to be done
>>on 4.3, however, since they were clever enough to insert a "SO_SNDBUF"
>>and SO_RCVBUF setsockopt calls ...
From: speck@vlsi.caltech.edu (Don Speck)
>The fact that 4.3bsd /etc/rmt sets SO_RCVBUF is what *causes* the problem.
Yes, although in fact the SO_RCVBUF trick is a good idea---*if*
you can get dump to make a similar SO_SNDBUF call.
>Observe that if tcp_recvspace is made too big relative to tcp_sendspace,
>throughput is terrible. But tcp_sendspace can be made large without any
>problems. This derives from some TCP window bug. Imagen has described
>the same phenomenon.
It is more of an `optimisation gone awry' than a bug. Over high-
delay networks (ARPAnet), it is generally wise to delay TCP
`ack'nowledges for a bit---say, one fifth of a second---because
there is a very good chance that the ack can be sent along with
some data, or that it may ack a second or third packet that will
arrive before then. The 4.2 and 4.3 TCP will apply this 0.2 second
delay unless certain conditions are met. One of these conditions
involves how much data the TCP peer (dump) can send if the ack is
delayed. With the receive buffer set to 10K, 4.3 will not send an
ack until its peer has sent at least 3.5K of data, or two tenths
of a second has elapsed, whichever occurs first.
Now, on the Sun side, dump has written 10K of data to its TCP send
socket. Unfortunately, tcp_sendspace is set to 2K, so the TCP code
has moved 2K of that 10K into a buffer and sent it. It is now
waiting for an ack from its TCP peer (/etc/rmt). It has no extra
space available, so it cannot send more until it is certain its
peer has received the original 2K. Alas, now both TCPs are waiting
for each other to do something. The deadlock is broken only by
the timer expiration. At most this will move 10K per second.
There are innumerable workarounds: remove the setsockopt in 4.3's
/etc/rmt; add the setsockopts to the Sun kernel, and port the 4.3
rdump; raise tcp_sendspace in the Suns; turn on tcp_nodelack in
the 4.3 kernel (not recommended if you have anything more than one
high speed local net!). Perhaps the best (and most difficult)
solution involves teaching the TCP code to guess at the sender's
window size, and to alter the ack delay based upon that guess.
Myself? I just raised tcp_sendspace to 8K on the Sun file servers.
--
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7690)
UUCP: seismo!umcp-cs!chris
CSNet: chris@umcp-cs ARPA: chris@mimsy.umd.edu
------------------------------
Date: Mon, 3 Nov 86 16:56:50 est
From: mike@bambi.bellcore.com (Mike Caplinger)
Subject: complaints about ND and SunView size
Well, I'm back from Apollo land, or at least I will be when my disk
server shows up. But there's trouble in paradise...
I'm looking longingly at a Sun-3/50 sitting in a box that I can't run because
I don't have any server I can add a new set of ND areas to. Now, on the
Apollos I just hook a diskless node up, tell it who to boot from, and the
rest is totally automatic. None of this /etc/nd.local, format the new
ND disk, etc, etc, nonsense.
So the first question is this: when is ND going to be superseded in favor of
something easier to administrate? ND was never ever considered to be
anything more than a hack, but it seems to have become a cornerstone of
Sun's architecture.
Seems like the best way of handling this would be to allow the specification
of Unix files to be contiguous, then make the swap partition one big
contiguous file. The root partition could simply be a directory tree
that's mounted by only one machine (the way node_data directories work
on the Apollos.)
Now, my second bitch. The most trivial Suntools (or SunView or whatever)
application runs more than 500K. The mere size doesn't bother me, but the
link time does. It takes at least 30 seconds to link a simple line-
drawing program on a Sun 3, which really makes interactive program
development kind of a pain. Is anyone considering
1) smaller Suntools libraries
2) a faster, smarter linker
3) shareable libraries?
I hate to say it, but in some ways I'm probably going to miss the Apollo...
Mike Caplinger (mike@bellcore.com)
------------------------------
Date: Mon, 27 Oct 86 19:27:32 -0100
From: Havard Eidnes <H_Eidnes%vax.runit.unit.uninett@tor.ARPA>
Subject: Problems with rdump, tcp_{send,recv}space, etc.
I have some problems with rdump on a Sun-3/160. My configuration is:
1 MicroVAX II, running Ultrix-1.1
1 Sun-3/160-4M, running Sun-Unix 3.0
Trying to run rdump from the Sun to the MicroVAX's TK-50 tape seemed
*very* slow -- dumping 57Mb from the Sun would take 3h20min! I recently
saw a message on Sun-Spots indicating that if tcp_sendspace and
tcp_recvspace was increased in the kernel from 2048 to 4096, things
would improve. So I did this:
% adb -w /vmunix
tcp_sendspace?W 0x1000
tcp_recvspace?W 0x1000
^D
%
(well, I actually didn't do it that way, but the effect was similar)
rebooted, and tried again (the dump size had since grown to 106Mb).
Rdump said it would take 6h10min (!), so no improvement.
Some time ago we had a 1/2" tape drive on the Sun-3, and we tested
rdump from the MicroVAX, and the tape streamed! (Said to be impossible
in the doc, because the tape controller couldn't do byte swapping.) It
took some 17 minutes (or something near that) to fill a 2400ft reel
from the MicroVAX(!).
So my big question is, what is wrong in this setup?? What makes rdump
one way take extremely long time, while rdump the other goes so fast?
Why didn't the fix work?
I should also mention that I tried using the (undocumented -- at least:
used to be undocumented) "b" key to rdump, but using something other
than the default blocking factor to rdump (eg. 32 or 64) made the
connection to the remote machine be lost. I have previously run rdump
from the MicroVAX to a Sun-2/120 (under a past condition of shortage of
TK-50 cartridges) with a blocking factor of 126, and all worked just
fine.
Please respond by mail (also?) since delivery of Sun-Spots to this site
is somewhat unreliable at the moment.
-------
E-Mail: <h_eidnes%vax.runit.unit.uninett@nta-vax.arpa>
H}vard Eidnes (or TeXish: H\aa vard Eidnes)
Division of Computer Science
Norwegian Institute of Technology
<Generic disclaimer>
------------------------------
Date: Thu, 30 Oct 86 12:13:59 est
From: burdvax!starner@seismo.CSS.GOV (Mark L. Starner)
Subject: Bug in 3.2 /lib/ccom (1)
There apears to be a bug in the 3.2 (and 3.1) C compiler that manifests
itself when trying to compile the Berkeley version of ditroff. An example
of what happens is apparent when you try to troff one of the Sun manual
pages. The headers and footers of the page come out all pressed against each
other on the left hand side of the page.
ie:
CHGRP(1)USERCOMMANDSCHGRP(1)
as oppposed to:
CHGRP(1) USER COMMANDS CHGRP(1)
I replaced /lib/ccom with the Sun 3.0 version and it worked like
it is suppsed to -- if I replace /lib/ccom with either the
Sun 3.1 or Sun 3.2 /lib/ccom, it breaks.
So the bug appears in the Sun 3.2 release of the compiler.
Note that it compiles fine, no errors -- it just doesn't produce
the correct ditroff output.
It was later discovered that the bug is related to casting. This Program
demonstrates the bug:
main()
{
int i,j;
i = 0xffffffff;
j = 0xefffffff;
printf("(short)%#x == (short)%#x, right?\n",i,j);
if((short)i == (short)j)
printf("Right! Lower 16 bits are equal\n");
else
printf("Wrong! Lower 16 bits are not equal\n");
}
The 3.0 Compiler (and Vax compiler) says that they are equal....
the 3.1 and 3.2 compilers say that the lower 16 bits are not equal.
It also manifests itself if you cast both to chars, unsigned short, etc...
So if you notice unusual behaviour after compiling something under 3.2
look for something like this.
I have contacted Sun about this, but they didn't seem to think it
was a problem, since they do not support berkeley ditroff!!!!
I would assume their C compiler should correctly support the C language.
Mark Starner (215) 648-7382
System Development Corp.
Paoli, PA
------------------------------
Date: Thu, 30 Oct 86 22:53:03 -0800
From: mk@aero2.ARPA
Subject: Common Lisp 1.2 GCs infinitely on Sun3s with fpa
We are running Version 1.2 of Sun Common Lisp on 3/160s, and have found
that on a machine with an FPA, lisp will garbage collect endlessly once
the compiler is invoked. This problem has been reported to Sun, and is
being worked on by Sun and Lucid.
------------------------------
Date: Thursday, 30 October 1986 10:08:18
From: RE103%CAM.PHX%UK.AC.CAM.ENG-ICF@ac.uk
(RE103%CAM.PHX@UK.AC.CAM.ENG-ICF)
Subject: Problems with f77?
I have encountered two problems involving f77 on our SUN3-52M.
(1) On moderate-sized programs, compilation invoking the optimizer (-O flag)
does not work properly. After several minutes, a core file is returned
which has the size of the remaining disk space. The same code will compile
properly without the -O flag. Why does the optimizer appear to get tied
up sometimes?
(2) A program functioning properly which has been compiled without the
-O flag will fail if compiled with the -O option. Some arrays have zeroes
randomly appearing in them which leads to the failure.
Has anyone encountered these situations or are there any suggestions as
to what's likely happening here?
Richard Eckman
Dept. of Physical Chemistry, Univ. of Cambridge
BITNET/EARN: RE103%CAM.PHX@AC.UK
ARPA: RE103%CAM.PHX@UCL-CS.ARPA
------------------------------
Date: Thu 30 Oct 86 06:54:42-PST
From: Bob Knight <KNIGHT@SRI-NIC.ARPA>
Subject: Sun 2 monitor problem?
Hi - my wife's SUN has developed a problem that is temperature related.
When cold, the monitor "blurs" (ie. appears to lose some kind of sync).
The problem disappears when the temperature goes up. Has anyone seen
this and does anyone have a cure?
Please e-mail to either this address or to "myrtle!holly"@tsca.istc.sri.com.
Thanks in advance,
Bob
------------------------------
Date: Mon, 27 Oct 86 12:06:48 EST
From: Jon Hull <hull%buffalo.csnet@CSNET-RELAY.ARPA>
Subject: Eikonix digitizing camera on a Sun-3 with VME bus?
We are going to interface an Eikonix model 850 CCD digitizing
camera with a Sun-3/VME system.
Several alternatives are possible, none of which are too easy.
Has anyone else out there done this already?
If so, please let me know.
Thanks very much in advance,
Jon Hull
Department of Computer Science
SUNY at Buffalo
716-636-3195 716-636-3191
hull%buffalo-cs@CSNET-RELAY.ARPA
hull@buffalo.CSNET
------------------------------
Date: Tue, 28 Oct 86 16:46:38 est
From: schatz%bambi@mouton.bellcore.com
Subject: videotaping Sun workstations?
Has anyone discovered a good method for taking videotapes of Suns ?
I've just completed a videotape of software running on a Sun 3/160C
workstation and was particularly disconcerted by the flashing "beat".
On the videotape, there appears to be a white line moving continuously
down the screen, which flashes in the closeups. It is caused by an
incompatibility in the scan rates between the NTSC camera (60 Hz) and
the Sun screen (66 Hz). In VHS copies of the videotape, this difference
is uncomfortably close to some internal brain frequency.
The ideal solution would be a Sun graphics board with 60 Hz output.
If this came with SunWindows software, we could run our programs
unchanged and connect the new board to a 60 Hz color monitor for filming.
My impression is that there are some boards which do this used
internally at Sun. Does anyone know how to obtain one?
Another solution would be a conversion box which took the RGB plugs
from the graphics board as input and output 66 Hz for the monitor AND
60 Hz for the camera. Any leads to these or other solutions would be
greatly appreciated. Thanks.
bruce schatz
schatz@bellcore.com
(decvax,ihnp4,ucbvax)!bellcore!schatz
------------------------------
Date: Tue, 28 Oct 86 12:33:27 -0100
From: mcvax!inria!shapiro@seismo.CSS.GOV (Marc Shapiro)
Subject: Sun-3 hardcopy to LaserWriter (request)?
Does anybody have or know of a program to print a Sun-3 screen
dump to a LaserWriter? Thanks.
------------------------------
Date: Thu, 30 Oct 86 14:09:44 cst
From: texsun!uokmax!ken@sun.UUCP (Kenneth A. Smith)
Subject: Sun 2 Workstation monitor 35 meters from CPU?
On occasion we have the need to be able to use the monitor, keyboard, and
mouse from a Sun 2 Workstation at up to 35 meters from the CPU card cage.
The monitor (Sun 19 inch monochrome bit-mapped display) has been tested
at 10 meters and works fine, but at 35 meters the image on the monitor is
very "fuzzy" and the keyboard does not seem to work at all. The information
that I have gotten out of our local Sun sales office is that 10 meters is
the limit. Does anyone know of special cables and/or "blackbox(s)" that
could help out.
Kenneth A. Smith ...ihnp4!okstate!uokmax!ken
Software Consultant ...sun!texsun!uokmax!ken
Computer Aided Engineering Lab
University of Oklahoma
202 W. Boyd, Rm 107
Norman, Oklahoma 73019
------------------------------
Date: Mon, 3 Nov 86 10:20 EST
From: Ed Fox <"VTOPUS::FOX%vpi.vt.edu"@CSNET-RELAY.ARPA>
Subject: disks for SUN?
I administer a SUN-2/170 which has the 380M Eagle drive. We need more disk
space, but it does not have to be very fast. We would welcome comments on
the feasibility of:
* buying another Eagle and hooking it up ourselves (where can we get one?)
* buying some type of optical disk drive with a SCSI interface (I have
a quote from Optotech for $5000 to cover a 200M WORM drive) and get
some gear from SUN (what?) and drivers from someone (who?)
* getting some other newer drive for the SUN and somehow interfacing it
Thank you for your comments!
- Ed Fox (BITNET: foxea@vtvax3 or fox@vtcs1; CSNET:fox@vt;
Internet:fox%vt@csnet-relay.arpa; UUCP:seismo!vtisr1!fox)
Dr. Edward A. Fox; Dept. of Computer Science
Virginia Tech, Blacksburg VA 24061; (703) 961-5113 or 6931
------------------------------
Date: Tue, 4 Nov 86 02:15:48 MST
From: hi!kurt@hc.dspo.gov (Kurt Zeilenga)
Subject: adding an ASCII console?
I would like to add an ascii terminal to our SUN 3/160 Color system.
I tried reprogramming the prom, but could figure out anyway
sort of write a device driver to operate the color monitor
as a terminal.
I then resorted to renaming /dev/console to /dev/ttyc and /dev/ttya
to /dev/console. This had the effect of getting most of the system
error messages onto the ascii terminals, but kernal errors (of course)
still showed up on the color monitor.
Has anyone got both a graphics monitor and an ascii console on a system?
Any bright ideas, pointers, etc? Your help is greatly appreciated.
- Kurt Zeilenga
zeilenga@hc.dspo.gov
------------------------------
Date: Sat, 25 Oct 86 16:49:57 -0100
From: Havard Eidnes <H_Eidnes%vax.runit.unit.uninett@tor.ARPA>
Subject: Diffs for RCS on Suns?
I remember (quite) some time ago seeing on Sun-Spots corrections
for RCS to make it runnable on SUNs, by (among other things?)
removing dereferencing of NULL pointers. At the time I didn't
think I would have any use for them, but have later come to think
otherwise. So: would anyone please give me a pointer to where the
diffs can be fetched? Anonymous FTP address will do.
Thank you.
-------
E-Mail: <h_eidnes%vax.runit.unit.uninett@nta-vax.arpa>
H}vard Eidnes (or TeXish: H\aa vard Eidnes)
Div. of Computer Science
Norwegian Institute of Technology
<Generic disclaimer>
------------------------------
Date: Thu, 30 Oct 86 17:05:48 pst
From: dcdwest!phb@sdcsvax.ucsd.edu (Peter H. Berens)
Subject: anyone have a "newstool"?
Has anyone created a "newstool" for the SUN? It would seem that the
interface provided by "mailtool" would be quite nice for reading news
and provide all the advantages of rn, vn, and vnews all in one
package. If someone has done this or is thinking about doing this,
it would be nice to hear about it.
Pete Berens
Apunix
UUCP: sdcsvax!apunix!phb
------------------------------
Date: Tue, 28 Oct 86 20:54:08 EST
From: Matt Landau <mlandau@Diamond.BBN.COM>
Subject: Sun 3.0 Make and VPATH?
I've noticed that the /bin/make supplied with SunOS 3.0 seems to be based on
a System V augmented version of make that includes MAKEFLAGS and other
non-BSD features. Although the manual page doesn't mention it, invoking
strings on the binary reveals that the VPATH variable is at least present in
the code. However, it doesn't seem to work. Does anyone know if it's
*supposed* to work in 3.0? If not, does anyone have a hacked 4.2/4.3 make
that knows about VPATH that they'd be willing to share?
--
Matt Landau BBN Laboratories, Inc.
mlandau@diamond.bbn.com 10 Moulton Street, Cambridge MA 02238
...seismo!diamond.bbn.com!mlandau (617) 497-2429
"Go away, or Cerebus is going to strip-mine your face."
------------------------------
Date: Fri, 31 Oct 86 15:47:23 pst
From: klee@ads.ARPA (Ken Lee)
Subject: maps for Sun?
The Oct., 1986 issue of *PC World* has a review of 3 nice map display
and manipulation packages for the IBM PC. Does anyone know of a similar
package for the Sun? I'm interested in political outline maps and zoom,
pan, and overlay manipulation. Thanks in advance!
Ken Lee
klee@ads-unix.arpa
------------------------------
Date: Mon, 3 Nov 86 11:50:17 pst
From: white@ee.UCLA.EDU (Joseph White)
Subject: HPGL to Postscript?
Hello.
I am looking for a program to translate HPGL (Hewlett-Packard
Graphics Language) into Postscript format. I appreciate any
leads you can give me.
Thank you.
Joe White
Electrical Engineering Dept. UCLA
white@ee.ucla.edu
------------------------------
Date: Thu, 30 Oct 86 18:16:57 gmt
From: David England <de%computing.lancaster.ac.uk@Cs.Ucl.AC.UK>
Subject: Next release of Sun software -- NeWS?
Could someone confirm/deny some rumors I've heard about the next
release of Sun stuff apparently called SunNEWS. i.e. it includes
a PostScript interpreter to draw PS on the screen. suntools and pixrects are
out to be replaced by ??? There will be a SunView compatability layer for
the "old" software. Any info would be appreciated.
Dave uucp: ...!mcvax!ukc!dcl-cs!de
arpa: de%lancs.comp@ucl-cs
------------------------------
Date: Tue, 4 Nov 86 09:22:02 EST
From: jqj@gvax.cs.cornell.edu (J Q Johnson)
Subject: NFS future enhancements?
With SUN NFS rapidly becomming an (the?) industry standard for distributed
file systems, it becomes increasingly interesting to ask what enhancements
to NFS are planned or likely in the future. SUN has at various times
indicated an intention of providing record locking and support for swapping
through NFS; in one document SUN claims to be "considering implementation
of ... replicated data."
What distributed file system features do sophisticated users see as
important -- what features would you like to see added to NFS or to NFS
implementations?
As examples of such advanced features, consider location independent naming
and file replication. Location independent naming in general seems like it
would be very hard to add to an NFS framework, but perhaps NFS is powerful
enough to at least support enough location transparency for some types of
replication.
Replication is something that I'd dearly love to have, at least for failure
recovery. If a file server goes down, I still want to be able to get at my
files from my diskless workstation! Full replication (with serialization)
would be desirable, but disk shadowing with automatic remounting of a backup
copy of my files would probably be adequate for many purposes.
I'm sure you can think of other things for a wish list. Now the key
question: is anyone working on such extensions to SUN NFS?
------------------------------