Sun-Spots Digest, v6n93

William LeFebvre Sun-Spots-Request at RICE.EDU
Thu May 19 14:43:05 AEST 1988


SUN-SPOTS DIGEST          Wednesday, 18 May 1988       Volume 6 : Issue 93

Today's Topics:
                           SUNOS 4.0 IS HERE!!
                Re: Raster ==> TeX (or LaTeX) for figures?
                            Re: SUNLINK Users
                               Re: make bug
                  Re: MAXUSERS > 12 in SunOS 3.2 and 3.4
                    find(1) bug in 3.4; sun has a fix
                  Visual Performance Of VT-100 Emulator
        TrailBlazer+/ALM-2 interaction with Ethernet on Sun 3/280
                  Running 4.0 clients from a 3.5 server?
                        ld and a.out in SunOS 4.0?
                             silo overflow???
      Plea for information on Sun to 68K Modula-2 cross-compilation.

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: Wed, 18 May 88 15:14:51 PDT
From: Steve Blair <ascway.UUCP!scb at spar-20.spar.slb.com>
Subject: SUNOS 4.0 IS HERE!!

I just got a MONSTER loaded into my dolly:

SUNOS 4.0

Will be loading the FCS version onto my machine(3/110-12 141mb/60mb) and
will send info as to how's it going. Others should do the same, because
from the look of the manuals, we're going to be SWAMPING ~wnl~ with
questions for postings.  [[ Spiffy.  Just spiffy...  --wnl ]]

A disturbing side note is as follows:
1) Unbundled s/w means you'd better get the stuff ordered now(i.e. NeWS, lisp
   f77vms, etc)
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.
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.

Spend a lot of time reviewing these manuals. I have and am still reading
them. If you don't, there's no right to complain to Sun about problems.
If You've had the chance to read them and the "Read This First" that's
shipped with the tapes you may be o.k.

steve blair
Schlumberger Technology Corp.
Austin, Texas
uucp: sun!texsun!austsun!ascway!scb

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

Date:    17 May 88  9:16 +0100
From:    Igor Metz <metz at iam.unibe.ch>
Subject: Re: Raster ==> TeX (or LaTeX) for figures?

wnl responded:
  > [[ How do these rumors get started?  There is no builtin support for
  > bitmaps in TeX.  Any bitmap inclusing technique will depend on what
  > \special directives the DVI converter supports....But there is no
  > standard way of accomplishing this.  --wnl ]]

There is a standard way for bitmap inclusion! See:
Knuth, D.E : Fonts for digital halftones. TUGboat, Vol 8 , No 2, July 87,
  p. 135ff
Clark, A.F.: Halftone output from TeX. TUGboat, Vol 8, No 3, Nov 87, p.270ff

(TUGboat is the TeX users group newsletter).

Regards,

Igor Metz                    X400: metz at iam.unibe.ch
Institut fuer Informatik     ARPA: metz%iam.unibe.ch at relay.cs.net
und angewandte Mathematik    UUCP: ..!uunet!mcvax!iam.unibe.ch!metz
Universitaet Bern
Switzerland		     Phone: (+31) 65 49 02

[[ Well, okay, I guess you're right.  But you have to have the halftone
fonts to make it work.  Admittedly that's just a METAFONT away...  It
would also be hard to pick up one of those DVI files and get it to work at
a different site.  Not impossible, just difficult.  Let's stop talking
about this...  this is for TeXHax.  Unless someone has a rasterfile to GF
converter...  --wnl ]]

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

Date:    Tue, 17 May 88 06:43:16 PDT
From:    carrs at trout.nosc.mil (Stephen M. Carr)
Subject: Re: SUNLINK Users

Forwarded mail follows:

Date:    Mon, 16 May 88 20:24:35 GMT
From: Jeff Beard <quintus!jbeard at unix.sri.com>

pte900 at csc.anu.OZ.AU (Peter Elford) writes:
> Has anyone got some experience with the SUNlink product that makes a SUN
> 3/160 look like a local controller to an IBM/MVS host and hence provides a
> TCP/IP gateway to the IBM host for other TCP/IP machines on the same network
> as the SUN ?...

We use SUNlink for access to TSO & VM access with both interactive and ftp
services.

Product is stable and useful.  The FTP operation requires a host session
(ie: user logged on), but that's the nature of LU2 3270 emulation.  It
will allow multiple sessions (unique Host user_id's however) to/from the
Sun workstation, and with windows, you can FTP in one and still edit from
another(assuming you've got two log ons).

wish list:

FTP multiple files with one command.

        This gets to be a pain for large file set transfers in either
        direction.


The EBCDIC/ASCII/EBCDIC translation provided fails on the characters

        []{}\n

which limits the internal translator.

The tty to 3270 mappings get a bit involved, but it's managable.

We solved the FTP & translation issues by using our own GLUE.c program and
doing the translation ourselves from the SUN side.  The FTP was executed
without translation.  On the IBM Host, we UNGLUE the inbound stream based
on an internal header "*** <file.ext> ***".  The Unix file.ext is mapped
on the HOST as (MVS)?ddname=file"FN.FT=file.ext

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

Date:    Tue, 17 May 88 09:52:51 EDT
From:    Matt Landau <mlandau at diamond.bbn.com>
Subject: Re: make bug

It looks like you're using the "enhanced" version of make that comes as
part of the SunPro package.  This make has a lot of nice features, and a
number of nasty bugs.  One of the bugs is that you cannot make a target
named "makefile" or "Makefile".

I've sent a bug report on this to Sun.  I don't know if it's fixed in
SunOS 4.0 or not.

 Matt Landau
 mlandau at bbn.com

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

Date:    Mon, 16 May 88 17:23:31 mdt
From:    era at scdpyr.ucar.edu (Ed Arnold)
Subject: Re: MAXUSERS > 12 in SunOS 3.2 and 3.4

In v6n80, Robert Bruner writes:
 >I've used MAXUSERS = 16 in both 3.2 and 3.4 with no problems.  (Also in
 >SunOS 3.5)

Under 3.3, we found that MAXUSERS *greater than* 16 causes kernels that
won't run.  Since we couldn't upgrade to 3.5 immediately, we found that
editing param.c after running config to boost the necessary parms (esp.
NPROC, MAXUPRC, ntext) was a workable solution.

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

Date:    17 May 88 02:13:58 GMT
From:    tekbspa!tss!joe at uunet.uu.net (Joe Angelo)
Subject: find(1) bug in 3.4; sun has a fix

We noticed a bug in find(1) when accessing NFS files... when an NFS file
(directory) was at mode 000, find(1) would properly report that the file
wasn't accessable. However, find(1) continued to report that error message
for any subsequent directory (note: not subordinate directories as one
would expect!); further-more, find(1) would stop dead at the next NFS
mount point. 

For example:

	mount sys1:/usr/sys1 /usr/sys1
	mount sys2:/usr/sys2 /usr/sys2
	chmod 0 /usr/sys1/deaddir

	find /usr/sys1 /usr/sys2 -type d -print
	.
.	.
	/usr/sys1/sys
	/usr/sys1/sys/conf
	/usr/sys1/adm
	.
	.
	/usr/sys1/deaddir: permission denied
	/usr/sys1/nextdir: permission denied
	/usr/sys1/nextdir2: permission denied
	.
	.more errors
	.
	<END: without reporting /usr/sys2 files!>

Sun sent me a new find(1) which worked (thanx!). I doubt that I can email
this program, since it is Sun's property; however, you might want to
contact the Sun-hotline (uunet!sun!hotline) and ask for it. I wish I knew
the SON, but, sorry, I don't. 

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

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

Date:    Mon, 16 May 88 12:40:05 EDT
From:    umix!lokkur!scs at rutgers.edu (Steve Simmons)
Subject: Visual Performance Of VT-100 Emulator

We've recently been comparing the performance of the PD vt-100 emulator
and Sun's emulator they supply with their DNA package Sun's is much much
faster at high baud rates.  We've done all kinds of mucking about with
vtem and got only marginally better results.  Any suggestions?  We've
already profiled vtem intensively and found it spends most of it's time in
write.  We cut the writes by an order of magnitude, and got less than 1%
improvement in response speed.  Any hints?

Steve Simmons
Schlumberger CAD/CAM
scs at applga.uucp

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

Date:    Mon, 16 May 88 17:01:53 PDT
From:    dplatt at coherent.com (Dave Platt)
Subject: TrailBlazer+/ALM-2 interaction with Ethernet on Sun 3/280

Weekend before last, I came into work on Saturday to help our site's
hardware/net guru ("Madame Server") reconfigure our thin Ethernet.  We'd
been having a slow but steady increase in the number of Ethernet errors...
typically output errors on our Sun 3/280 file server and input errors on
the 3/50 and 3/60 workstations.  The error rate had increased to somewhere
in the .1-.2% range, and was beginning to cause occasional problems
especially during periods of heavy net usage (NFS glomming, heavy paging
by diskless 3/50 workstations, and "dump workstation file systems to the
server's tape drive" sessions).  We had replaced the server's thinnet
transceiver (a Cabletron ST-500) to no avail.

We knew that our thinnet wasn't installed entirely "according to Hoyle";
the cables snaked through the ceiling in a couple of areas (getting out of
the server room and into the workstation bullpen), and were hung down
along the "spine" of our workstation area next to 120-volt power strips.
We weren't sure whether the primary problem was interference from
fluorescent lights, interference from the power-strips, bad cables, or
what;  Madame Server decided to tear down the entire workstation-spine
portion of the net and rebuilt it one piece at a time, with the cables
strung up on the top of the cubicles, well away from any 120-volt power.

We started by detaching the all of the workstations save for one diskful
3/60, and then loading down the net with a set of "spray" and "rcp"
scripts.  Sun's "traffictool" indicated 20-30% saturation on the net...  a
good deal higher than we see during any but the highest levels of
real-life activity.  Few, if any errors were to be seen.

At this point, I asked Madame Server if I should power off our Telebit
TrailBlazer modem in order to keep off-site UUCP activity from skewing our
test results or loading down our server's CPU;  she agreed.  I cut the
modem's power, and M.S. said "Whoops... we just got 16 errors in 10
seconds!".  I waited a few seconds, powered the modem back on, and then
off again... and we got another 17 errors!  This proved to be a highly
repeatable phenomenon... powering the modem off generated a rapid burst of
Ethernet output errors whenever the net was under a substantial load from
the server.

As an experiment, I disconnected the modem from its port on our ALM-2
16-line serial board, and plugged it into port A on the server's CPU
board.  I then reconfigured the /etc/ttys file to enable dialin on CPU
port A, kicked /etc/init, and tried the power-on/power-off sequence again.
Lo and behold, the errors did not recur!

My working hypothesis at this point is that powering off the modem
generates a burst of activity on the serial port; I'm not sure whether
it's a spurt of garbage data on the RD line, or whether DSR or CD is
hopping up and down, or whether it's something else entirely.  Whatever it
is, I believe that it causes the ALM-2 board to begin generating a swarm
of interrupts and/or grabbing the VMEbus for DMA input... and, in either
case, is somehow locking out or interfering with the Ethernet interface.
The same level of serial-port activity doesn't seem to cause problems if
the modem is attached directly to port A on the CPU board.

Based on a very limited set of observations, I believe that uucp I/O
between the modem and the ALM-2 board does not in and of itself cause
Ethernet errors under these conditions.  I suspect, however, that the
dropping-and-raising of DTR and/or CD that occurs at the beginning and/or
end of a uucp session may cause such errors to occur.  I could well be
wrong about either or both of these hypotheses... I haven't done enough
experiments to be sure.

At this point, we've decided to leave the TrailBlazer connected to CPU
port A... it eliminates one source of Ethernet errors under some
conditions, and the CPU seems to be able to ingest 19200-baud data from
the modem much more efficiently (~ 30% of the processor when connected to
CPU port A, vs.  ~ 60% when connected to the ALM-2).  We've also moved our
hardwired link to "aimt" to the CPU-board serial ports (port B) for the
same set of reasons.  Our 2400-baud dialup modems will remain on the
ALM-2, as there's no place else to put them.  I haven't yet experimented
to see whether power-cycling these modems also causes errors under
heavy-net-load conditions.

I don't know whether this situation is a design problem in the ALM-2
(excessive VMEbus/interrupt activity), a glitch in the TrailBlazer Plus
(swarms of garbage during power-off... a death-rattle? ;-), a software
problem in the Sun's ALM-2 interface code, or a phase-of-moon problem.  If
anybody else out there has seen similar happenings, I'd really like to
hear about it!

[After several hours of reconfiguring and testing our net, we seem to have
nailed the other sources of packet-errors.  Restringing the cables along
the tops of the workstation partitions helped, as did finding and
replacing one cable that had a sloppily-attached connector, and another
that looked as if it has been attacked by a rabid hair stylist armed with
a curling iron.  We didn't have to restring the portion of the cable that
goes through the ceiling and past several fluorescent lights... apparently
that wasn't the problem.  Happiness is a clean network!]

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

Date:    Tue, 17 May 88 7:42 BST
From:    Piete Brooks <pb%computer-lab.cambridge.ac.uk at nss.cs.ucl.ac.uk>
Subject: Running 4.0 clients from a 3.5 server?

After hearing all the real nice things that SunOS 4.0 does, I'd like to
get a copy running ASAP.  The problem is that we need SUNLINK X.25 on our
server, which we have been told will not be available for some time yet,
so it has to stay on 3.5.

At our local SUG meeting we were told that Sun does not support a 4.0
client off a 3.5 server [ I am really looking forward to the ease of
running mixed releases when 4.x is running ] but I got the impression that
it might work.  [ diskless clients would be nice, but diskfull would do ]

Has anyone tried it ? Anyone contemplating it ?  I guess the major
upheaval would be all the directory renaming.

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

Date:    Tue, 17 May 88 10:17:54 PDT
From:    stevo at jane.jpl.nasa.gov (Steve Groom)
Subject: ld and a.out in SunOS 4.0?

Does anybody know what ld and the a.out format will look like in future
releases of SunOS?  Will it be changing to look more like SYSV?

I am doing a bunch of cross-compiling for exotic systems that need things
loaded at different places in memory.  BSD's ld has always been terrible
at this sort of thing, while the SYSV ld has had all sorts of very useful
features that make it much more flexibile.

We used to be able to get by with the the BSD a.out format, but alas, the
day is upon us where things are becoming too complicated for BSD's ld and
a.out to handle.  I have used every trick I know short of writing my own
loader to make things work.

I would appreciate reasonably informed comments and suggestions.

thanks-
-steve

Steve Groom, MS 168-522, Jet Propulsion Laboratory, Pasadena, CA 91109
Internet: stevo at elroy.jpl.nasa.gov   UUCP: {ames,cit-vax}!elroy!stevo

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

Date:    17 May 88 03:28:35 GMT
From:    Educational Software <edusoft at mv03.ecf>
Subject: silo overflow???

HELP!!! What is a "silo" and why would it overflow?!? This may seem like a
very broad question, but I can't find anything regarding this in any of
our sun manuals and our console just had a screen full of "silo overflow"
errors.  Any ideas? How can I fix it? Any correct information however
general would be appreciated.

Thanks...
Rick...

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

Date:    Tue, 17 May 88 15:59:12 EST
From:    munnari!barnard.cs.anu.oz.au!daw at uunet.uu.net (David Wanless)
Subject: Plea for information on Sun to 68K Modula-2 cross-compilation.

Does anybody out there have any information on software for Modula-2
cross-compilation from Suns to generic 68K boards ?  We are looking for
software of commercial quality.  Any information would be much
appreciated.  Thanks in advance.

David Wanless,
Australian National University,
Canberra Australia.
daw at anucsd.oz

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

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



More information about the Comp.sys.sun mailing list