Sun-Spots-Request@Rice.edu (Vicky Riffle) (09/10/86)
SUN-SPOTS DIGEST Wednesday, 10 September 1986 Volume 4 : Issue 28
Todays Topics:
Eagle <-> Sun cable warning
RCS on Suns
TeX and BIBTEX problems on Sun-3 (3)
GB is not CA
Some results with the Sun 3/160-FPA
Making a case for the Sun-100 keyboard
Serial Line IP on Suns
M100 fix
Solutions to SunCore/SunView color map problems when using color
CGI graphics -- device parameters?
Xerox on Sun networks?
Computer intensive campuses?
Problem with vertical lines in pr_vector()?
Sharing /usr/spool/mail on NFS?
How do I get 7 MB of RAM to work on a Multibus Sun?
Alternative memory expansion boards for Suns?
ie0: no carrier?
Suns as timesharing computers?
Help with GNU Emacs on a SUN-3 (unexec.c)?
Help on NIT needed...?
------------------------------------------------------------------------
Date: 27 Aug 1986 2025-PDT (Wednesday)
From: Lance Berc <lance@pescadero.stanford.edu>
Subject: Eagle <-> Sun cable warning
** Important when hooking a third party Eagle to a Sun **
The flat data cable that comes out the back of the Eagle has 26 pins,
but the bulkhead connector that Sun uses has 25 pins. Pin one on the
Eagle side (a ground) does not go through. The ribbon cable in the
connector should be shifted over one pin so that wire one (often the
one with the red stripe) is connected to pin two. The DB-25 end that
plugs into the Sun (or the bulkhead) is normal (wire one to pin one).
This does not apply if you are going straight from the disk drive to
the controller avoiding all of the intermediate cable nonsense.
lance berc
distributed systems group
stanford
-----------------------------
Date: Wed, 27 Aug 86 23:03:35 cdt
From: franklin%pp@mcc.com (Maurice T. Franklin)
Subject: RCS on Suns
Some time ago, I said I had ported Vax sources for RCS to a Sun.
Since I have had some requests, here are the diffs. As you can see, the
changes are fairly trivial, just got to find 'em! At that time I also
asked if anybody had RCS working on Sun-3's, since I had a file that put
rdiff into an infinite loop. However, since I have not been able to duplicate
this problem with other files, I'm not sure if anything is actually wrong.
So, I claim that these diffs will work on a Sun-3 as well, but would be very
interested if anybody can get it to fail.
Maurice T. Franklin, MCC
ARPA Internet: franklin%pp@mcc.com
UUCP: {gatech,ihnp4,seismo,ucbvax}!sally!im4u!milano!mcc-pp!franklin
-------------
Common subdirectories: rcs.vax.orig/doc and /usr/local/src/rcs/doc
Common subdirectories: rcs.vax.orig/man and /usr/local/src/rcs/man
Common subdirectories: rcs.vax.orig/src and /usr/local/src/rcs/src
Common subdirectories: rcs.vax.orig/man/man1 and /usr/local/src/rcs/man/man1
Common subdirectories: rcs.vax.orig/man/man5 and /usr/local/src/rcs/man/man5
diff -r rcs.vax.orig/man/man1/Makefile /usr/local/src/rcs/man/man1/Makefile
1c1
< DEST = $(DESTDIR)/usr/man/mann
---
> DEST = $(DESTDIR)/usr/man/manl
26c26
< @for i in $(SRCS); do cp $$i $(DEST)/`basename $$i .1`.n; done
---
> @for i in $(SRCS); do cp $$i $(DEST)/`basename $$i .1`.l; done
Common subdirectories: rcs.vax.orig/src/rcs and /usr/local/src/rcs/src/rcs
Common subdirectories: rcs.vax.orig/src/rdiff and /usr/local/src/rcs/src/rdiff
Common subdirectories: rcs.vax.orig/src/rdiff3 and /usr/local/src/rcs/src/rdiff3
diff -r rcs.vax.orig/src/rdiff/Makefile /usr/local/src/rcs/src/rdiff/Makefile
1c1
< # Note: RCS uses /usr/new/lib/rdiff and /usr/lib/diffh
---
> # Note: RCS uses /usr/lib/rdiff and /usr/lib/diffh
3c3
< CFLAGS = -O -DDIFF='"${DIFF}"' -DDIFFH='"${DIFFH}"' -DPR='"${PR}"' -d2
---
> CFLAGS = -O -DDIFF='"${DIFF}"' -DDIFFH='"${DIFFH}"' -DPR='"${PR}"'
5c5
< DEST = /usr/new/lib
---
> DEST = /usr/lib
50a51,52
> @rm /usr/local/bin/rdiff
> @ln -s /usr/lib/rdiff /usr/local/bin
diff -r rcs.vax.orig/src/rdiff/diff.h /usr/local/src/rcs/src/rdiff/diff.h
12a13
> char _sobuf[BUFSIZ]; /* Had to add this...should be in C library; franklin */
diff -r rcs.vax.orig/src/rdiff3/Makefile /usr/local/src/rcs/src/rdiff3/Makefile
1c1
< # Note: merge uses /usr/new/lib/rdiff3
---
> # Note: merge uses /usr/lib/rdiff3
3c3
< CFLAGS = -O -d2
---
> CFLAGS = -O
5c5
< DEST = /usr/new/lib
---
> DEST = /usr/lib
42a43,44
> @rm /usr/local/bin/rdiff3
> @ln -s /usr/lib/rdiff3 /usr/local/bin
-----------------------------
Date: Thu, 28 Aug 86 09:34:17 PDT
From: rusty@weyl.Berkeley.EDU (Rusty Wright)
Subject: TeX and BIBTEX problems on Sun-3 (1)
The only thing that I remember having to do to bring up the latest
Unix TeX distribution was to remove the -J flag from the Makefiles and
find a working undump for the suns. What changes (that required a week
of your time) did you make?
I was very unhappy with your message since it gives the impression
that the Unix TeX distribution is slipshod and poorly put together.
Rick Furuta, Pierre Mackay, and other people have put a lot of their
own time into the Unix TeX distribution so that the rest of us could
enjoy the use of the TeX system. While the distribution may not be
perfect, I'd hardly call it a "real mess".
I'm repeatedly dissapointed with people that publicly berate or
criticize the work done by others, apparently unaware of proper public
behavior or good manners. This type of behavior is even less
commendable when the work being criticized was done out of someone's
generosity and the results have been put in the public domain.
If you find bugs or problems in some software, there are ways of
informing the right person without resorting to public mud-slinging.
-----------------------------
Date: Fri, 29 Aug 86 10:43:59 -0100
From: mcvax!inria!chorus-carmen!shapiro@seismo.CSS.GOV (Marc Shapiro)
Subject: TeX and BIBTEX problems on Sun-3 (2)
From rusty@weyl.berkeley.edu:
The only thing that I remember having to do to bring up the latest
Unix TeX distribution was to remove the -J flag from the Makefiles and
find a working undump for the suns. What changes (that required a week
of your time) did you make?
Yes, those are the 2 main problems. The -J problem was hard to track down.
There was an 'undump' for the Sun-3 on the net but I didn't know it at
the time and wasted some time on that.
Generally speaking I'd say that the problem is no so much with the programs
themselves but with the comments and the directory organization. I won't go
into the details but there are many misleading and contradicting 'READ-ME'
files. The actual hierarchy was not that announced in the files. The
top directory is based on a non-standard Pascal compiler. No explanation on
how to bootstrap on a non-Vax machine (i.e. delete all binaries and all .p
files except =TeXware/tangle.p; compile tangle; touch tangle.ch and then
do a make).
I was very unhappy with your message since it gives the impression
that the Unix TeX distribution is slipshod and poorly put together.
Rick Furuta, Pierre Mackay, and other people have put a lot of their
own time into the Unix TeX distribution so that the rest of us could
enjoy the use of the TeX system. While the distribution may not be
perfect, I'd hardly call it a "real mess".
I understand. I did not mean to flame. I just pointed out that running TeX
on a Sun takes more work than just typing 'make'.
I'm repeatedly dissapointed with people that publicly berate or
criticize the work done by others, apparently unaware of proper public
behavior or good manners. This type of behavior is even less
commendable when the work being criticized was done out of someone's
generosity and the results have been put in the public domain.
Again, I did not intend to flame or hurt anybody's feelings. I just responded
to someone who publicly stated his problems. I offered to save other people's
time by sending a Sun tape.
The people at U. of Washington tell me they are aware of these problems and
have fixed the current distribution tape.
-----------------------------
Date: 29 Aug 1986 1712-PDT (Friday)
From: trwrb!trwspp!spp2!hull@ucbvax.Berkeley.EDU (D. L. Hull)
Subject: TeX under release 3.0 (3)
I saw that some people had TeX running on their Sun 3s. I'm glad to hear
it, but the problems that we've heard about with TeX on Suns running
Release 3.0 only appear when you generate the code for a 68010 machine.
I have the TeX distribution running on the Sun 3, and once I fixed the
undump program for ZMAGIC files and got rid of the -J option to the loader
I had no problem. However, the same distribution, compiled on a Sun 2 under
Release 3.0, does not run correctly. There must be a problem either with the
68010 version of the pascal compiler or with the 68010 pascal libraries.
I hope this clarifies matters.
- David
-----------------------------
Date: Fri, 29 Aug 86 11:20:00 -0100
From: mcvax!inria!shapiro@seismo.CSS.GOV (Marc Shapiro)
Subject: GB is not CA
From gdw@ssl-macc.co.uk (Manchester, GB):
>Recently, I upgraded a Sun-2/50 from Rel2.0 to Rel3.0. This Sun is on a single
>ethernet network with 14 other Suns, (all running Rel2.0). Ever since, we've
>not been able to get /usr/ucb/rdate functioning correctly -- when supplied with
>the name of another host, the date returned is exactly 9 hours behind, whereas
>all other Suns get the correct date. Any ideas ??
I suspect the problem is simply that you have not configured in the right
time zone (via config). The date and time are stored internally
as Univeral Time, and all programs such as ls or date convert this into
the local time using the configured time zone. If all your Suns don't have
the same idea of the local zone, they will be converting the external date
(which is probably the same for all) into a different internal representation.
Apparently, this is the represntation rdate uses.
Suns are delivered with the California time zone by default, which is 9
hours away from the UK. They also carry US-style daylight savings time
correction, which is 4 weeks off from the one in use in Europe.
I had a bad experience with a server and clients with different time zones.
The clients had inconsistent views of the /pub directory.
I think Sun should fix this, e.g. by exchanging time zone info at boot time.
-----------------------------
Date: Fri, 29 Aug 86 16:50:16 pdt
From: Mark K. Seager <seager@lll-lcc.ARPA>
Subject: Some results with the Sun 3/160-FPA
They FINALLY installed the FPA board in my Sun 3/160 yesterday.
The thing really screams. The first thing I ran was the infamous
Livermore Loops (a code with 24 nasty little Do loops used in
benchmarking vectorizing fortrash compilers on supercomputers) and
got some amazing results. The following is the actual output
from MFLOP for vector loops with mean vector length of 471 and
compiled with f77 -O -fpa:
KERNEL FLOPS MICROSEC MFLOP/SEC SPAN WEIGHT SUM
------ ----- -------- --------- ---- ------ ---
1 0.3503e+06 0.3400e+06 1.0304 1001 1.00 0.511465469000e+05
2 0.2600e+06 0.3800e+06 0.6841 101 1.00 0.515036011000e+03
3 0.1802e+06 0.1800e+06 1.0010 1001 1.00 0.100074396000e+02
4 0.1682e+06 0.2800e+06 0.6006 1001 1.00 0.599925637000e+00
5 0.2000e+06 0.3800e+06 0.5263 1001 1.00 0.454891406000e+04
6 0.1210e+06 0.3200e+06 0.3780 64 1.00 0.523039670000e+13
7 0.6368e+06 0.5200e+06 1.2246 995 1.00 0.610425742000e+05
8 0.7128e+06 0.1440e+07 0.4950 100 1.00 0.150131344000e+06
9 0.6181e+06 0.8400e+06 0.7359 101 1.00 0.118944688000e+06
10 0.3091e+06 0.7800e+06 0.3962 101 1.00 0.731039219000e+05
11 0.1100e+06 0.3200e+06 0.3438 1001 1.00 0.334293220000e+08
12 0.1199e+06 0.3400e+06 0.3526 1000 1.00 0.782310962000e-04
13 0.1613e+06 0.2360e+07 0.0683 64 1.00 0.405708928000e+10
14 0.2202e+06 0.9400e+06 0.2343 1001 1.00 0.108535420000e+08
15 0.1650e+06 0.5000e+06 0.3300 101 1.00 0.394382656000e+05
16 0.1325e+06 0.3800e+06 0.3487 75 1.00 0.283260000000e+05
17 0.3181e+06 0.5000e+06 0.6363 101 1.00 0.111466187000e+04
18 0.4356e+06 0.7800e+06 0.5585 100 1.00 0.516570703000e+05
19 0.2363e+06 0.4600e+06 0.5138 101 1.00 0.542192139000e+03
20 0.2600e+06 0.3000e+06 0.8667 1000 1.00 0.303951860000e+08
21 0.1263e+07 0.3600e+07 0.3507 101 1.00 0.828957950000e+07
22 0.1889e+06 0.2800e+06 0.6745 101 1.00 0.293861725000e+03
23 0.4356e+06 0.7200e+06 0.6050 100 1.00 0.354991836000e+05
24 0.5000e+05 0.1800e+06 0.2778 1001 1.00 0.500000000000e+03
------ ----- -------- --------- ---- ------ ---
MFLOPS RANGE = 0.0683 TO 1.2246 Mega-Flops/Sec.
HARMONIC MEAN = 0.3812 Mega-Flops/Sec.
MEDIAN RATE = 0.5263 Mega-Flops/Sec.
MEDIAN DEV. = 0.2095 Mega-Flops/Sec.
AVERAGE RATE = 0.5514 Mega-Flops/Sec.
STANDARD DEV. = 0.2696 Mega-Flops/Sec.
Note that loop seven actually got over 1.22 MFlops!!!!! Yes folks
thats MEGAFLOPS !!!! For some comparisons the following is the
summary for the same loops on a Vax 785 with FPA running Unix 4.2 Bsd:
MFLOPS RANGE = 0.0465 TO 0.3899 Mega-Flops/Sec.
HARMONIC MEAN = 0.1570 Mega-Flops/Sec.
MEDIAN RATE = 0.1935 Mega-Flops/Sec.
MEDIAN DEV. = 0.0723 Mega-Flops/Sec.
AVERAGE RATE = 0.2014 Mega-Flops/Sec.
STANDARD DEV. = 0.0858 Mega-Flops/Sec.
Which gives the Sun 3/160-FPA a harmonic mean of 2.43 (=.3812/.1570)
times faster than the Vax 785. This is very impressive.
Another benchmark I like to run is a 50x50 matrix matrix multiply.
Here are some results for a code written in C run on everything I can
get my hands on (including a Cray-1S, yes we have a C compiler on the
Cray's):
* Machine Complier Kflops Time Size (bytes)
* Cray-1S newcc o=i(V0.344) 2275.00 0.11 111500
* 2091.00 0.12
* Cray-1S cc (V0.316b) 1809.00 0.14 111500
* 1678.00 0.15
* Sequent B8K(10) cc -i 602.41
* 426.72
* Sun 3/160 cc -O -ffpa 315.79 0.79 49152
* 277.57 0.89
* Vax 785/FPA tcc -O4 198.68 1.26
* 189.17 1.31 12288
* Pyramid 90x cc -OG 198.68 1.26 22528
* 133.78 1.85
* Pyramid 90x cc -O 179.64 1.39 22528
* 103.48 2.39
* Sun 3/MC68881 cc -O -f68881 81.78 32768
* 116.47
* Sequent B8K(1) cc -i 60.46
* 42.64
* Sun 2/FPA cc -O 17.14
* 15.87
* Sun 3 cc -O -fsoft 15.54
* 14.47
* IBM-PC/8087 Microsoft V3.0 12.37
* 10.10
* Sun 2 cc -O 5.59
* 5.34
Some things to note: 1) the Cray C compiler is not yet up to
vectorizing these loops. When it is the MFlop rate should be
around 12 or so, 2) the Sequent B8k(10) was a run made in parallel
with 10 processors, 3) my IPM-PC is just a pain, vanilla 4.77Mhz
model and it still beat a Sun 2 using software emulated floating
point ;->.
If you have any comments on these benchmarks (or would like
to get ya hands on them send mail to seager@lll-crg.Arpa. Also, if
you have any other !!!-*-short-*-!!! FLOATING POINT intensive
benchmark(s) you think would be interesting to the net community
send it to me and some day I'll try to run it.
-----------------------------
Date: Thu, 28 Aug 86 15:19:00 PDT
From: hoptoad.uucp!cfcl!rdm@sun.UUCP (Rich Morin)
Subject: Making a case for the Sun-100 keyboard.
It is possible to purchase a plastic replacement case for the (heavy,
large) Sun-100 VT-100 style keyboard. If enough folks are interested,
we might be able to set up a mass purchase and save some money. (The
vendor would also like that better.) Contact me if interested, at:
Rich Morin (415) 994-6860 ..!ucsfcgl!hoptoad!cfcl!rdm
In any case (heh-heh), the contact for the vendor is:
Ms. Leslie Durling (509) 927-5504
Key Tronic Corp.
P.O. Box 14687
Spokane, WA 99214
(509) 928-8000
The needed parts are:
plastic enclosure 44-00202-002 (see below)
bail block & leg 44-00193-000 2 @ 1.50 3.00
45-00057-002
associated screws 47-00290-000 4 @ 0.05 0.20
metal base plate 49-01540-000 (see below)
associated screws 47-00055-006 4 @ 0.05 0.20
associated screws 47-00096-002 4 @ 0.05 0.20
associated washers 47-00381-003 4 @ 0.05 0.20
rubber feet 48-00559-001 2 @ 0.05 0.10
====
3.90
The enclosure and base plate are priced by quantity:
quantity encl. base e + b total
-------- ----- ---- ----- -----
1 - 9 38.66 + 9.50 = 48.16 +3.90= 52.06
10 - 24 28.99 + 7.50 = 36.49 +3.90= 40.39
25 - up 24.16 + 6.00 = 30.16 +3.90= 34.06
Send a check with your order (including sales tax if you are in CA
or WA), shipping costs are COD. Normal delivery is 6 weeks ARO.
-----------------------------
Date: 01 Sep 86 16:23:12 EDT (Mon)
From: Mark Weiser <mark@markshome.cs.umd.edu>
Subject: Serial Line IP on Suns
I installed this under sun 2.0 and 3.0 operating systems. It did require
some changes from Rick Adams original code, and another change or two for 3.0
to accomodate Sun fixing some, but not all, the bugs in their handling
of socket ioctl's. The version I now use looks like the 4.3 version,
but without the fancy mbuf handling.
I am happy to mail this code to people, provided Rick does not mind.
-mark
-----------------------------
Date: 3 September 1986 1509-PDT (Wednesday)
From: wargo@nprdc.arpa (Dave Wargo)
Subject: M100 fix
Sun Microsystems model 100U will at times have a problem with the
Philips monitor (M17P114H/2101).
The problem shows up as white horizontal lines at the top of the
screen and possibly white shakey lines at the bottom of the screen.
To fix this problem I replaced C413 with a 2.2uf 160v electrolytic cap
and C416 with a 220uf 35v electrolytic cap.
Dave Wargo
ucbvax!sdcsvax!sdics:wargo
-----------------------------
Date: Thu, 28 Aug 86 14:04:22 cdt
From: wca@ngp.UTEXAS.EDU (William C. Anderson)
Subject: Solutions to SunCore/SunView color map problems when using color
In the SunSpots of 8/27/86, there were two requests for help on color Suns.
I believe that I can enlighten the SunSpots readers who are interested in
color and the Sun concept of colormap segments.
====== Problems with color map in SunCore ======
> Date: Thu, 21 Aug 86 15:02:14 edt
> From: allegra!phri!roy@seismo.CSS.GOV (Roy Smith)
> Subject: Problems with color map in SunCore?
>
> I'm trying to figure out how to get color output using SunCore on
> my 3/160C (with GP/GB), but I'm not getting anywhere.
< Roy goes on to give sample code and explain the problem >
The fix is easy: one must specify the size of the colormap segment
before one calls initialize_view_surface (). In Roy's case, his code
sets the colormap size to the default size (probably 0, which is reset
to 2, see below) and then just honks along as usual. His code should
be changed to read:
.
.
ncolors = sizeof (red) / sizeof (*red);
printf ("%d colors\n", ncolors);
/* ADD THE NEXT LINE (see text below for info on limitations) */
vwsurf.cmapsize = ncolors;
initialize_core (DYNAMICC, NOINPUT, TWOD);
initialize_view_surface (&vwsurf, FALSE);
select_view_surface (&vwsurf);
.
.
Once you have set the size of the colormap segment with the
initialize_view_surface () call, then you can change its RGB
contents to anything you want with define_color_indices () (as
Roy does in his code). As far as I know (from perusing the
SunCore source code), there is no way to reset the *size*
of a vwsurf colormap once it is initialized.
Roy also notes that:
> I have, at various times tried stuff like "vwsurf.cmapsize = 5;",
> but that has produced either no or strange results, depending on
> when I do it. I'm sure that can't be what you're supposed to
> do anyway -- seems terribly unportable to me.
Yep, that will lose big. Unportable it may be, but everyone should
note well the following limitation of Sun colormap segments:
***************************************************************
* CMS SIZES MUST BE A POWER OF 2 BETWEEN 2 AND 256, INCLUSIVE *
***************************************************************
Some of the documentation on this is in Appendix B of the SunCore manual
("SunCore View Surfaces"; see section entitled "View Surface Specification
for Window Devices") . I hope that this fixes the problem, Roy.
====== SunView problems when using color ======
> Date: Mon, 25 Aug 86 10:48 EDT
> From: HOUSE%williams.csnet@CSNET-RELAY.ARPA (Donald H House)
> Subject: SunView problems when using color
>
> We are currently attempting to develop applications under 4.2
> on a 3/160c without a graphics processor. Our problem concerns
> the use of user-defined colormaps within the SunView pixwindows
> environment.
>
> We define the colormap through the "pw_setcmsname" and
> "pw_putcolormap" routines as described in the Beta draft
> (10/11/85) and rev. A (2/17/86) of the SunView Programmer's
> Guide. Our colormaps are designed specifically after the
> example set forward in the /usr/include/sunwindows/cms_rgb.h
> file. The applications consist of a FRAME containing a CANVAS
> and a PANEL. Changes are made to the colormap of the Pixwin
> of the CANVAS (as accessed through the canvas_pixwin() macro).
< Donald goes on to explain some problems he is having >
Here I can only offer a guess which is based on my experiences while
developing an interactive colormap editor under SunView. I'll start
by quoting the SunView Programmer's Guide (Chapter 7 - Imaging Facilities:
Pixwins, page 87, last paragraph):
While one can have multiple pixwins with in (sic) a window, the
the colormap of that window is shared between all pixwins of that
window. Thus, trying to use a separate colormap for each pix-
win will lead to confusion and is not supported.
Evidently the kernel wants only one colormap segment per (Frame) window.
Although there are cases where a tool can apparently have more than one
colormap (e.g. running a color demo in a gfxtool or shelltool), this is
really the case of a *blanket* window having a different cms. When you
are using SunView, you are really using not only the pixwin mechanism but
also the tiling facility described in the SunView System Programmer's
Guide, and I suspect that the tile facility is the reason that SunView
tools are limited to one colormap segment.
In any case, I had similar problems (bad imaging but no core dumps) in
the tool I built. They were resolved by setting the cmsname of *all*
windows in the tool to the same cmsname. This is an unfortunate limit-
ation of SunView, but it seemed to be workable in my case. It seemed
to me that the colormap segment of the Frame tended to override the
colormap segment of its subwindows, so that if you had a monochrome
Frame and subwindows with other colormap names, when the subwindows
were updated, exceptionally funky things happened. When you reset
your colormap(s), you will probably want to call wmgr_refreshwindow()
with the file descriptor of your Frame to get an immediate update.
I hope that this solves Donald's problem.
======
By the way, I do have a functioning version of my interactive colormap
editor (ColorMapTool) running. It allows a user to select the colormap
of any window on the screen (by clicking the mouse over it), then allows
the user to select any color out of that colormap and mix the RGB values
in that color with sliders. OK, OK, I *know* that it is a toy, but if
you have a color Sun, it's a great toy. If there are any SunSpots
readers out there who would like to get ColorMapTool, drop me a line.
However, be forwarned: if I get too many requests, I'll just mail the
code to the Sun User Group or (even simpler) put it in a public FTP
area on one of our machines here at the University of Texas. Also, it
was built under Sun 3.0 with SunView - no other software releases will
work.
Cheers, and sorry that this got to be so long,
William Anderson - the University of Texas Computation Center
-----------------------------
Date: 29 Aug 1986 09:17-EDT
From: Douglas.Reece@ius1.cs.cmu.edu
Subject: CGI graphics -- device parameters
I am writing an application program using the SunCGI package and I'm
having difficulty getting the view surface descriptor to behave as
described in the manual. I am trying to change some parameters in the
structure Cvwsurf before I open a view surface, in order to change the
color map, etc. I have found that if I try to set .flags and .ptr (in
the Cvwsurf structure), I get an ENOWSTYP error when I call open_vws.
If I try to set .cmapsize or .retained, the values are ignored
(cmapsize always stays = 8). Is there something that needs to be done
besides, e.g.
Cvwsurf device;
Cint name;
NORMAL_VWSURF(device, CG2DD);
device.cmapsize= 256;
open_vws(&name, &device);
in order to open a surface with a color map
size of 256?
I have also found that the function hard_reset() does not clear
my view surfaces or reset the color map. Why not?
One final problem: When I use suntools (and device CGPIXWINDD),
closing cgi returns the window to the state it was in before my
graphics program was started. When I am not using suntools, however,
the color map seems to be permanently changed after the graphics
program, so that the screen is left in funny colors. If I run another
program to change the color map back to normal, the screen flashes but
stays in the wrong color map when the program exits. How can I reset
the color map?
Doug Reece
Carnegie-Mellon University
dreece@ius1.cs.cmu.edu
-----------------------------
Date: Tue, 26 Aug 86 15:25:18 BST
From: Ewgorc@Cs.Ucl.AC.UK
Subject: Xerox on Sun networks
Any of you out there with Xerox 1100s might have seen this message on
the bug-1100 board but since I'm desperate for a solution, I shall
repeat my question.
I am currently working on a Xerox 1108 which has an ethernet link
to a net of Sun IIIs. The Suns use a Sun/Apple LaserWriter for
producing copy and this relies on the files being in PostScript
form. The 1108 however, uses a format called Interpress and I am
trying to find a way of overcoming this diffence and printing Xerox
files on the Sun/Apple printer.
Any advice or leads about this or other Sun/Xerox networking matters
would be gratefully recieved.
Many thanks,
John Connors
Information Technology Research Unit
B.P. Research Centre
Sunbury-on-Thames
U.K.
-----------------------------
Date: Thu, 28 Aug 86 13:20:34 CST
From: munnari!augean.oz!ncapon@seismo.CSS.GOV (Dr. Capon)
Subject: Computer intensive campuses
This message is being sent to several groups. I apologize to those who see it
twice.
i am seeking to establish contacts with people concerned with planning for
computer intensive campuses. (alias, `workstations for every student')
My interest ranges from the technical through the managerial to the academic
outcomes.
Our setting is a state-funded University of 10000 students. The current PC
to student ratio is about 1 to 20, but we want to raise that as soon as
possible. It is likely that many institutions will have the same problems
of costs, benefits, impacts on network resources etc, and we would benefit
from discussions. Some institutions are more advanced down this road than
we are, and I would like to talk to them particularly.
It may be that the people I want to contact are not direct users of the
groups I am using; I would appreciate it if readers would pass on the
message or send me suggestions.
Please reply via electronic mail as in the header. Otherwise via AIR
mail (necessary) to
I.N. Capon
Vice Chancellors Office
University of Adelaide
North Terrace
Adelaide
South Australia 5000
Thank you for your help.
-----------------------------
Date: Thu, 28 Aug 86 9:52:29 EDT
From: Jim Berets <jberets@BBN-VAX.ARPA>
Subject: Problem with vertical lines in pr_vector()
I'm glad to hear someone else is experiencing problems similar to us.
We are trying to build a graphics application under 3.0 on a Sun 3/160c
as well. When using pr_vector() to draw a vertical vector in a window,
a vector drawn in one direction (upward) will appear correctly, while
one drawn in the opposite direction (downward) will put garbage all
over the screen (both within and outside the window). We do not get
the core dump as mentioned in an earlier message pertaining to similar
behavior with pw_vector(), and also the problem appears to occur when
drawing in the opposite direction. As far as I can tell, the garbage
appears as a replication of existing display areas. If for example, a
clocktool is running in the upper right corner of the screen, a
fragment of a second (enlarged) clocktool will appear AND BE UPDATED
after drawing the offending vertical vector. The length of the
vertical vector that will cause this problem seems to vary with the
size of the window into which it is being drawn - but not in a linear
way. Any help with this would be greatly appreciated.
Jim Berets
<jberets@vax.bbn.com>
-----------------------------
Date: Thu, 21 Aug 86 16:38:12 EDT
From: seismo!rochester!srs!matt@soma.UUCP (Matt Goheen)
Subject: Sharing /usr/spool/mail on NFS?
Does anyone see any problems with sharing /usr/spool/mail among
a bunch of networked Suns? We have several employees that shift
systems quite often and we're sick of changing the /usr/lib/aliases
to send mail to the correct system every time they make a temporary
move. Mounting /usr/spool/mail on all the systems would allow you
to read/receive your mail on any system. Anything I might be
overlooking? What about /usr/spool/mqueue? I'm assuming it won't
be used as mail will always be locally delivered. What about if
the system that actually serves the /usr/spool/mail file system is
down (I guess I could try this myself)? Thoughts/Comments?
Matt Goheen
{seismo,allegra}!rochester!srs!matt
-----------------------------
Date: Thu, 28 Aug 86 15:22:37 PDT
From: hoptoad.uucp!cfcl!rdm@sun.UUCP (Rich Morin)
Subject: How do I get 7 MB of RAM to work on a Multibus Sun?
Why won't 7 MB work on a Multibus Sun?
I have been talking to the folks at LCF Int'l. about their Multibus
memory boards. They say that different Sun configurations vary in
reliability, and that there seems to be a sensitivity to noise and/or
temperature on the Sun-2 CPU board.
In any case, they have successfully run a variety of memory config-
urations on assorted Suns, ranging from one through six MB. They
know that eight MB won't work, since Sun has appropriated that range
of addresses for the video. What they don't know is why seven MB
doesn't work, either.
I have heard a rumor that there is an (undocumented, of course)
option that one can put into the configuration file to solve this.
Does anybody have specific information on this?
Rich Morin (415) 994-6860
Canta Forda Computer Laboratory ..!ucsfcgl!hoptoad!cfcl!rdm
P.O. Box 1488
Pacifica, CA 94044
-----------------------------
Date: Wed, 3 Sep 86 12:11:52 EDT
From: Jon Hull <hull%buffalo.csnet@CSNET-RELAY.ARPA>
Subject: Alternative memory expansion boards for Suns?
Does anyone know of a vendor that supplies memory expansion boards for Sun-3's?
Sun charges $6000 for 4 megabytes. This seems a little over priced and thus
offers an obvious market for an enterprising company.
If you have any information on this topic, please respond to:
hull@buffalo.CSNET
hull%buffalo@CSNET-RELAY.ARPA
Thanks,
Jon Hull
-----------------------------
Date: Fri, 5 Sep 86 12:29:20 EDT
From: dms@HERMES.AI.MIT.EDU (David M. Siegel)
Subject: ie0: no carrier
We get this printout on our consoles fairly often. We're running with
Sun 3/75s, 3/160s, and 3/180s; they all give the "ie0: no carrier"
message" at least 30 times a day. I can't detect anything wrong with
the network, and the Suns do not fail in any particular way, it's just
that the printout makes people think something is wrong.
Does anyone else get such an error?
-Dave
-----------------------------
From: zemon@felix.UUCP (Art Zemon)
Date: 05 Sep 86 09:21:57 PDT (Fri)
Subject: Suns as timesharing computers?
The price/performance ratio of the faster Suns compares *very* favorably to
the VAX 11/78x computers. Since we have outgrown our pair of VAXen (a 780
and a 785) I'm trying to decide where to go for more horsepower.
Do you use Suns for general purpose timesharing? I. e., do you hook up a
bunch of alphanumeric terminals and no graphics monitors? If you do, how to
you feel about the arrangement? How many terminals per CPU? How do you
have your file system arranged? And so on....
Written responses would be fine, either here or via electronic mail. What
I would appreciate most, however, would be a phone call so I can discuss
this with you. I can be reached at (714)966-2344 after 9:00am PDT.
By way of background, my current computing system consists of a VAX 11/780
and a VAX 11/785, 144 terminal ports, and about 60 users concurrently logged
in during the day. I have a total of 2 gigabytes of disk storage
(8 drives) divided between the machines. The load is about 50% software
developement and 50% mixed electronic mail, documentation, spreadsheet, etc.
I also have five Avalon coprocessors (NS 32016 with 1 Mb of memory) helping to
pull the wagon.
-----------------------------
Date: Thu, 28 Aug 86 16:02:39 edt
From: decvax!raster!mark@ucbvax.Berkeley.EDU (Mark Miller)
Subject: Help with GNU Emacs on a SUN-3 (unexec.c)?
This problem has probably been posted before, but we just
got a Sun-3 and I'm trying to port GNU Emacs to it. Unfortunately,
the a.out format for the Sun-3 is different than it's predecessors
and I am unable to run the 'dump-emacs' function which will
create the runable version of emacs with all of the correct
packages loaded. Could someone in net.land possibly mail me
a copy of their hacked-up unexec.c (where the guts of dump-emacs live)
or, failing that, some instructions on what to muck with. It's
probably a fairly easy hack, but I'd rather not spend a day or so
finding that out.
Thanx
Mark S. Miller
Raster Technologies, Inc.
-----------------------------
Date: Thu, 4 Sep 86 10:40:40 bst
From: "David T. Coffield" <david%computing.lancaster.ac.uk@Cs.Ucl.AC.UK>
Subject: Help on NIT needed...?
Has anyone successfully used the NIT protocol on Sun Release 3.0
to dump the headers of all packets that go by on their Ethernet?
We can dump data from the ie0 interface to a file and by looking
through it, in hex format, and with the help of the Internet spec,
we can identify the start of real packets. Problem is they seem to
be "randomly" positioned throughout the file.
"nit collects incoming packets into chunks..." so I suspect a "recv"
returns a chunk and you then have to fish around in the chunk for
all the packets. How can we do this?
The manual page for NIT has to be one of the worst ever written so if
anyone can offer any hints, code snippets, ... they'd be very much appreciated.
Thanks for tuning in.
David.
--
uucp: ...!mcvax!ukc!dcl-cs!david post: Department of Computing
arpa: david%lancs.comp@ucl.cs University of Lancaster, UK
janet: david@uk.ac.lancs.comp phone: +44 524 65201 x 4599
-----------------------------
End of SUN-Spots Digest
***********************