Sun-Spots-Request@RICE.EDU (Vicky Riffle) (10/01/86)
SUN-SPOTS DIGEST Wednesday, 1 October 1986 Volume 4 : Issue 29
Today's Topics:
SUG Conference
Call for attendees/moderators/panel members for SIG and BOF sessions
Sun rasterfile to Impress
SunView in color and screen dump to Imagen
vt100tool for the Sun-3 running Version 3.0
TeX under release 3.0
TeX sun2/3.0 & sun3/3.1 core dumps
Sharing /usr/spool/mail on NFS (5)
SUN as timesharing machine
NIT explained
RCS on Suns
GB is not CA
ie0: no carrier (3)
Alternative Memory Boards (2)
Graphics for C-Prolog on the SUN
SUN printf (cc or awk) bug
Removable disks for Suns?
Full Screen Mous-ing?
Abort Sequence on Sun?
How do I use -background in suntools ?
NFS between Sun 100's and Sun 3's?
Xylogics 451's?
Large DBMS on Sun workstations?
Is the procedure call convention documented?
SUN3 disk controller specifics?
IMP Interface for Sun 3?
RHS of shoebox?
3/75 upgrade question?
A query about hardware emulator on a Unix system?
160c vs 260c?
Kermit problems on 3.0?
Compiling for 68010 on Sun-3?
HP plotter on SUN-3?
General purpose I/O card for SUN3 workstations?
SUN 3/160 graphics on film?
Floating Point Library Functions Query?
------------------------------------------------------------------------
Date: Sun, 7 Sep 86 22:04:35 PDT
From: rice!meltzer@sun.UUCP (Sandy Meltzer)
Subject: SUG Conference
WHO - The Sun User Group (SUG)
WHAT - Fourth Annual Technical Conference and Exhibit
WHEN - October 6-8
WHERE - Washington D.C. (Hyatt Regency - Crystal City)
WHY - Exhibit:
100 Sun Workstations and third-party "Catalyst"
vendors demonstrating their most advanced products.
Technical Conference:
Three days of technical workshops (presentations and
open discussions with Sun engineers - including Bill Joy),
vendor and user application talks, special interest group
discussions covering today's most interesting applications and
topics, and user donated software exchange.
HOW - Contact the Sun User Group - International Office
This year's conference will be our biggest and best. Come join Sun
users from around the world to disseminate information about Sun
Workstations, Sun Products, and related software.
We want to encourage all Sun users to attend and participate in the
Sun User Group conference. The registration fee is so LOW it's hard
to say no.
For more information, call Sanford "Sandy" Meltzer, Executive Director,
or Dave Howard, Group Administrator, at (415) 691-7490.
-----------------------------
Date: Mon, 15 Sep 86 17:47:27 PDT
From: hoptoad.uucp!cfcl!rdm@sun.UUCP (Rich Morin)
Subject: Call for attendees/moderators/panel members for SIG and BOF sessions
Call for attendees / moderators / panel members for SIG and BOF sessions
As you may be aware, the Sun User Group (SUG) is having its Fourth Annual
Technical Conference and Exhibit on October 6-8 in Washington D.C. (Hyatt
Regency - Crystal City). More details on the conference can be obtained
from the user group office (415-691-7490).
You are probably not aware that the user group board rescheduled major
parts of the conference to allow room for extended SIG and BOF sessions.
In addition, a "Feedback to Sun" session has been scheduled, with time
for summary statements from the SIGs and BOFs.
Any attendee is free to schedule a BOF, subject to availability of space.
In any case, a broad range of topics is already scheduled, including both
technical and political issues:
AI / Robotics . Biotech . C . Computer integrated manufacturing
Customer service concerns . Earth science . Electrical engineering
Equipment obsolescence - product life cycle . FORTRAN . High speed
networks . Image processing and graphics . Local and international
SUG chapters . Mechanical engineering . OEM Council . Operating
systems . PASCAL . PC's and the Sun Workstation . Software
compatibility . Supercomputers . University Council . Workstation
maintenance
THE PROBLEM, however, is that attendees, moderators, and panelists are
needed to make these sessions work. Sun will certainly supply folks to
help out, but we need users, too. Please contact Sandy Meltzer at the
user group office if you are interested in running or being on a panel.
If you can't reach him (Quite possible, he is VERY busy right now.),
feel free to contact me:
Rich Morin (415) 994-6860 ..!hoptoad!cfcl!rdm
-----------------------------
Date: Thu, 4 Sep 86 21:00:41 pdt
From: hplabs!seismo!csuf.ARPA!davstoy!dav@ucbvax.Berkeley.EDU
Subject: Sun rasterfile to Impress
I have a program which converts rasterfiles to impress (i.e.
screendumps to Imagen printers). It properly handles 1 and 8 bit
rasterfiles, and automatically centers, rotates, and magnifies
(for 1 bit) and can label the page (doesn't work yet in all modes).
As this program belongs to my employer, I can't make it pubdom,
but I will consider trades or begging for copies (binary available
too).
===============================================================================
David L. Markowitz
Real Time Trekker
Rockwell International (Where Science Gets Down To Busyness)
...!ucbvax!trwrb\
...!sdcsvax!ucivax!csuf!davstoy!dav
...!hplabs!felix/
-----------------------------
Date: Tue, 9 Sep 86 14:45:48 CDT
From: Michael Begeman <begeman@mcc.com>
Subject: SunView in color and screen dump to Imagen
Regarding:
> From: HOUSE%williams.csnet@CSNET-RELAY.ARPA
> Subject: SunView problems when using color
>
> Under most circumstances there are no problems. However, certain calls to
> the Pixrect drawing routines result in a variety of seemingly unexplainable
> errors: e.g. on an 800x800 canvas a long vertical line (550+ pixels) drawn
> with pw_vector() will be displayed properly when drawn "downward" but
> will cause a core dump when drawn "upward". Other problems include system
> hanging, improper returns from procedures, shifted graphic displays, etc.
> The debugger seems to indicate that the system stack is getting clobbered.
We found the same thing, and called Sun. They said it was a known bug and
sent us a tape with a new libpixrect.a on it. Problem is solved. We had
to return the tape. I suggest you contact Sun Software support.
Regarding:
> From: Rick Adams <rick@seismo.CSS.GOV>
> Subject: sun screen copy to imagen?
>
> Does anyone have a program to convert a sun screen dump to
> something suitable for printing on an Imagen Laser Printer.
I have a program called sunimp which I pulled off of net.sources
over a year ago. It converts a B/W rasterfile to impress format.
I wrote a program which compresses a color rasterfile to the B/W
format (I called it c2bw - color to black & white). With these
commands, one can print a screendump on one's imagen by:
screendump | c2bw | sunimp | lpr -v
If you can't find sunimp locally, let me know.
--
Of all the things I've lost, I miss my mind the most.
Michael L. Begeman Microelectronics and Computer Technology Corp
Software Technology Program Austin (where the sun always shines) Texas
uucp: {seismo, harvard, gatech, pyramid}!ut-sally!im4u!milano!begeman
arpa: begeman@mcc.com
-----------------------------
Date: Tue, 9 Sep 86 18:20:55 EDT
From: Edward L. Lafferty <ell%linus@mitre-bedford.ARPA>
Subject: vt100tool for the Sun-3 running Version 3.0
I have received many messages from people who are running Version 3 on
Sun-3 stations requesting vt100tool for that configuration. I have
replied to many of these as follows but I would like to make that
reply available to the wider group of sun users:
I will do a source language port to Version 3.0 when I receive the
source code for the libraries. Until then I have made a binary port
using sun-2 libraries and include files which runs on a sun-3 running
version 3. Unfortunately it is a fairly large file 400K approx. and
the mod.sources moderator does not want to clutter up the system with
it. (I can't disagree with that position.) So I have opened up a host
with anonymous FTP capability for those who can access it.
ftp mitre-b-ed (192.12.120.58)
login: anonymous
password: anonymous
get (any or all of the following files)
pub/vt100tool.Z (uncompress it at your site with uncompress)
pub/README
pub/vttest.c
pub/vt100tool.c (I have made a few small changes to this to make
it work correctly if the user has changed the default font
size)
Note to those who have old versions:
One user found a bug in the main emulator which makes it messy to use
with VMS edit. I have fixed this in the above version. You may want to
re-FTP it now. For those still running Version 2 if you want the
changes please let me know. I will put the source diffs into a file
and either mail them to you or let you ftp them to yourself if you
can.
Regards,
Ed
External: Internal Mail addresses at MITRE:
<ell@mitre-bedford.ARPA> <ell@mbunix>
<ell@linus.UUCP> <ell@linus>
<ell@mbvm>
-----------------------------
Date: Thu, 11 Sep 86 07:41:47 CDT
From: William LeFebvre <phil@titan.rice.edu>
Subject: TeX under release 3.0
>Marc Shapiro says:
> Generally speaking I'd say that the problem is not 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).
We just received a TeX 2.0 distribution here at Rice. There are now
shell files called 4.2-setup, SUN-setup, 4.3-setup, etc. that do "the
correct thing". You must realize the position that Washington is in at
this time. When we got the Unix-TeX 1.0 distribution, everything was
well organized and installing it was as easy as following the
instructions. TeX 2.0 (the program) was just finalized and released a
few months ago. There were two very severe and fundamental changes
made to TeX. (1) The "am" fonts were abandoned in favor of the "cm"
fonts, and (2) the "PXL" format font files were abandoned in favor of
the new (and more compact) "GF" format font files. The first change
was rather easy to cope with: the major change is in the macros. But
the second change, although it doesn't affect TeX much, has a direct
impact on ALL the programs that convert DVI format to some native
printer language (such as imPress or postscript). There was also a
change to the directory layout and the directory names (a much needed
one, at that). So now, the people at Washington are having to divide
their time between updating the README files and other documentation
and converting the drivers that come with the distribution so that they
can read "GF" files. There are only so many hours in a day, and these
people are not being paid for their efforts.
I know what it is like to be a "graduate student hacker droid", since I
have been one for three years (and I was an "undergraduate student
hacker droid" for two years before that). There comes a time when you
realize you have been putting all your time and effort into programming
and support and none of it into research. GIVE THESE PEOPLE A BREAK,
will you? All you get from Stanford when you ask for TeX is enough to
get TeX itself running (the web source to TeX and the programs to make
the web source into an executable). Stanford has no driver programs
and none of the contributed stuff that the Unix-TeX distribution has.
The Unix community owes a great debt to the people at Washington who
maintain Unix-TeX. It has saved countless man-hours of duplicated
effort at many Unix sites across the country (and probably the world,
as well). Right now, the people at Washington have their hands full
trying to put the Unix-TeX distribution back in to one coherent whole.
You must have gotten a distribution tape from them right after they got
TeX 2.0. As time progresses, the distribution has been getting better.
I am continually amazed at people that obtain public domain software
for little more than a song ($75 in this case, and that includes a
mag tape), and then complain publically that it is a "real mess". In
general, I have discovered that "you get what you pay for". BUT, I
think that TeX is the exception to that rule, and I think that any time
spent on my part to get TeX working is time well spent.
Enough of this. This is sun-spots. Let's get back to talking about
Suns.
>D. L. Hull says:
> ...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.
Yes, I have come across something similar while trying to make a 68010
version of metafont. After tinkering with this some, I have decided
that the -m68010 flag to the pc compiler does not produce correct code.
Here is a summary of my experiences with this:
compiled on linked on (executable is) works?
68010 68010 68010 no
68020 68010 68020 yes
68010 68020 68010 no
68020 68020 68020 yes
I even tried compiling it without optimization. That seemed to have no
effect on the results. There is definitely a problem here, and I think
it is with the code generator.
William LeFebvre
Department of Computer Science
Rice University
<phil@Rice.edu>
-----------------------------
Date: Mon 22 Sep 86 16:41:40-PDT
From: Pierre MacKay <MACKAY@WASHINGTON.ARPA>
Subject: TeX sun2/3.0 & sun3/3.1 core dumps
The following forwarded message suggests problems with some
aspect of pascal or its libraries in SUN3 version 3.1. Any comments?
The problem with SUN2 on 3.0 still remains. Bent at dartmouth traced
the first part of it to a bad compilation of arrays with very large
bounds, but it is still unknown whether that is the only problem.
TeX is indeed a good benchmark, (except, of course for floating point,
which it uses, but only trivially.)
Pierre
---------------
Return-Path: <ephemeral.ai!rayan%ai.toronto.edu@CSNET-RELAY.ARPA>
Received: from CSNET-RELAY.ARPA by WASHINGTON.ARPA with TCP; Fri 19 Sep 86 00:41:10-PDT
Received: from toronto by csnet-relay.csnet id ac15828; 19 Sep 86 2:21 EDT
Received: from ephemeral.ai.toronto.edu by ai.toronto.edu id AA09272; Fri, 19 Sep 86 01:55:02 edt
Received: by ephemeral.ai.toronto.edu id AA04213; Fri, 19 Sep 86 02:03:22 EDT
Message-Id: <8609190603.AA04213@ephemeral.ai.toronto.edu>
Date: 19 Sep 86 02:03:18 EDT (Fri)
From: Rayan Zachariassen <rayan%ai.toronto.edu@CSNET-RELAY.ARPA>
To: mackay@WASHINGTON.ARPA
Subject: Re: TeX sun2/3.0 & sun3/3.1 core dumps (prologue)
In-Reply-To: Your message of 18 Sep 86 15:27:29 EDT (Thu).
Well, I did some head-scratching and sleuthing; first I tried bringing
pascal compiler passes etc back to state at 3.0 release, which supposedly
works. That didn't help. I then traced down the core dump problem I mentioned
in the previous message. It occurred due to a bug in the subscript range
checking code emitted by pc. Would you consider removing the (*$C+*)
compiler directives from initex.p (by changing dist_initex.ch I assume) ?
With a correct pascal implementation, it only serves to slow down tex -- a
very bugfree program...
Anyway, I removed that compiler directive and recompiled initex normally
(this is on sun3/3.0) and it all seems to work. Now, the only program that
the pascal compiler uses that I hadn't restored to 3.0 state, is /usr/lib/f1
(part of fortran I think). So, I suspect that is the culprit (though who
knows...).
Then I tried compiling on a sun2/3.0. initex hangs when reading in plain.tex.
Grrr. TeX should be a test program for every pascal compiler being built!
Maybe this is fixed in sun2/3.1, but alas we don't have that tape. Sigh...
Hope you enjoyed my monologue.
Regards,
rayan
-------
-----------------------------
Date: Thu, 11 Sep 86 10:54:43 EDT
From: Alexander Dupuy <dupuy%amsterdam@columbia.edu>
Subject: Sharing /usr/spool/mail on NFS? (1)
It is possible to share /usr/spool/mail over NFS. Here at columbia,
/usr/spool/mail is only shared within each cluster (nd server and diskless
clients) since mail is considered important enough that it not be dependent on
a single central server. If the nd server for a diskless client is down, the
client's mail would be inaccessible anyhow.
Unless you run with the "root over the net" patch to the kernel, (we don't)
you will need to modify /bin/mail, since it is setuid root. Rough luck for
those without source, I know. You will also need to make /usr/spool/mail group
writable, with /bin/mail setgid to the same group. Alternately, you could just
make /usr/spool/mail world writable, at the risk of allowing anyone to delete
your mailbox. Here's our setup:
-rwsrwsr-x 1 root daemon 57344 Feb 15 1986 /bin/mail*
drwxrwxr-x 2 root daemon 512 Sep 11 09:55 /usr/spool/mail/
Here are the diffs for the patch to /bin/mail; we cheat, and set our effective
user id to the owner of the destination mailbox.
*** mail.c.orig Tue Apr 8 18:32:39 1986
--- mail.c Tue Feb 18 18:01:18 1986
***************
*** 637,640
struct hostent *hp = NULL;
struct servent *sp = NULL;
for(p=name; *p!='!'&&*p!='^' &&*p!='\0'; p++)
--- 637,641 -----
struct hostent *hp = NULL;
struct servent *sp = NULL;
+ int realuser;
for(p=name; *p!='!'&&*p!='^' &&*p!='\0'; p++)
***************
*** 654,657
if (!safefile(file))
return(0);
lock(file);
malf = fopen(file, "a");
--- 655,660 -----
if (!safefile(file))
return(0);
+ realuser = getuid();
+ setreuid(0,pw->pw_uid);
lock(file);
malf = fopen(file, "a");
***************
*** 656,660
lock(file);
malf = fopen(file, "a");
- umask(mask);
if (malf == NULL) {
unlock();
--- 659,662 -----
lock(file);
malf = fopen(file, "a");
if (malf == NULL) {
unlock();
***************
*** 660,663
unlock();
fprintf(stdout, "mail: cannot append to %s\n", file);
return(0);
}
--- 662,667 -----
unlock();
fprintf(stdout, "mail: cannot append to %s\n", file);
+ setuid(0);
+ setreuid(realuser,0);
return(0);
}
***************
*** 662,665
return(0);
}
chown(file, pw->pw_uid, pw->pw_gid);
{
--- 666,672 -----
return(0);
}
+ setuid(0);
+ setreuid(realuser,0);
+ umask(mask);
chown(file, pw->pw_uid, pw->pw_gid);
{
***************
*** 680,683
close(f);
}
unlock();
return(1);
--- 687,691 -----
close(f);
}
+ setreuid(0,pw->pw_uid);
unlock();
setuid(0);
***************
*** 681,684
}
unlock();
return(1);
}
--- 689,694 -----
setreuid(0,pw->pw_uid);
unlock();
+ setuid(0);
+ setreuid(realuser,0);
return(1);
}
-----------------------------
Date: Sat, 13 Sep 86 15:34:35 EDT
From: Matt Landau <mlandau@Diamond.BBN.COM>
Subject: Sharing /usr/spool/mail on NFS (2)
>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.
We've been doing something similar with a a cluster of 8 Suns for
about 6 months. Our machines share a /u3 filesystem and each machine
symbolically links /usr/spool/mail to /u3/mail, which seems to work
fine. I don't see any reason you couldn't directly share one machine's
/usr/spool/mail, though. (But be careful, since on NFS machines it's
normally a link to /private/usr/spool/mail, and you have to remove this
link before you can share it.)
You DON'T want to share /usr/spool/mqueue, since that's where the
background sendmail daemon picks up queued mail - on our machines,
each host delivers its own mail (but they all claim to be the same
host, so the outside world doesn't know the difference) and maintains
its own mqueue.
--
Matt Landau BBN Laboratories, Inc.
mlandau@diamond.bbn.com 10 Moulton Street, Cambridge MA 02238
...harvard!diamond.bbn.com!mlandau (617) 497-2429
-----------------------------
Date: Wed, 17 Sep 86 08:56:04 EDT
From: ted@braggvax.arpa
Subject: Sharing /usr/spool/mail on NFS (3)
I'm not sure what locking scheme is used on /usr/spool/mail, but if it
is flock(2), you could run into trouble since that won't work on an NFS
filesystem. We have just installed the MH6.5 Post Office Protocol on
our suns. So far it looks like it is working well. All mail is centralized
on one main host (a vax in our case, but it could be a sun). Whenever
the user does an inc, the mail is fetched from the POP machine into his
inbox folder (which is presumably on an NFS filesystem) so that no sun
is better than another for reading mail. There is the added plus that you
no longer need to run sendmail on anything but the mail host. The drawbacks
are that all your users need to use MH, and certain things will probably
break (we haven't tracked them all down, but they would include mail
notification of saved editor files, calendar etc).
Ted Nolan
ted@braggvax (our POP host)
-----------------------------
Date: Thu, 18 Sep 86 10:04:50 -0200
From: mcvax!daimi!pederch@seismo.CSS.GOV (Peder Chr. N|rgaard)
Subject: Sharing /usr/spool/mail on NFS (4)
Yes, there are a few problems, but none that can't be solved.
Our site is a university with lots of students sharing a few
Suns, so we can't have mail and news setup for each student
on a fixed client workstation.
First problem is that the standard setup from SMI is to have
the private link setup at /usr/spool -> /private/usr/spool.
To have some spool directories shared and others not, you'll
have to delete that link, create a real /usr/spool directory,
fill it with links to all the things that have to be private
(lpd.lock, printer spool directories, uucp directory etc)
and with real /usr/spool/mail (and /usr/spool/news) directory.
Then you must fix the /etc/rc file on the server so that it
doesn't delete the /usr/spool/lpd.lock at boot time - otherwise
it will just delete the link and cause the entire printer spool
system to stop on the clients.
Now you can start mounting. This is my /etc/fstab on a host
called jupiter (with its own disk) using host daimi as mail, news
and tex server:
/dev/xy0a / 4.2 rw 1 1
/dev/xy0f /pub.MC68020 4.2 rw 1 3
/dev/xy0h /usr.MC68020 4.2 rw 1 4
/dev/xy0d /usr.MC68020/jupiter 4.2 rw 1 2
daimi:/usr.MC68010/spool/mail /usr.MC68020/spool/mail nfs rw 0 0
daimi:/usr.MC68010/spool/news /usr.MC68020/spool/news nfs ro 0 0
daimi:/usr.MC68010/lib/news /usr.MC68020/lib/news nfs ro 0 0
daimi:/usr.MC68010/lib/tex /usr.MC68020/lib/tex nfs ro 0 0
These changes makes it possible to read and manage incoming mail
perfectly transparently. To make outgoing mail work we use another
trick: whatever mail front-end you are using, it will eventually
send you mail through /usr/lib/sendmail. To have this run on the
mailhost only we fake this program for /usr/lib/sendmail on all
clients:
-------------------------------------------------------------
#define RSH "/usr/ucb/rsh"
#define MAILHOST "daimi"
#define SENDMAIL "/usr/lib/sendmail"
extern char *malloc();
extern char *calloc();
static int word(ch) register char ch; {
switch (ch) {
case '&' : case '|' : case ';' :
case '<' : case '>' : case '(' : case ')' :
case '{' : case '}' : case '[' : case ']' :
case ' ' : case '\n': case '\\':
case '\'': case '"' : case '`' :
case '#' : case '%' : case '!' : case '^' :
case '?' : case '*' : case '~' : case '$' : return(1);
default : return(0);
}
}
static int overhead(av) char *av; {
register int i, j;
for (i = j = 0; av[ i ]; i++)
if (word(av[ i ])) j++;
return(i + j);
}
static char *arg(source) char *source; {
char *str; register int i, j;
if ((str = malloc(overhead(source))) == (char *) 0)
exit(1);
for (i = j = 0; source[ i ]; i++, j++) {
if (word(source[ i ]))
str[ j++ ] = '\\';
str[ j ] = source[ i ];
}
str[ j ] = 0;
return(str);
}
main(ac, av) char **av; {
char **argv; int i;
if ((argv = (char **)calloc(ac + 3, sizeof argv)) != (char **) 0) {
argv[ 0 ] = "rsh";
argv[ 1 ] = MAILHOST;
argv[ 2 ] = SENDMAIL;
for (i = 1; i < ac; i++)
argv[ i + 2 ] = arg(av[ i ]);
argv[ i + 2 ] = (char *) 0;
execv(RSH, argv);
}
exit(1);
}
------------------------------------------------------------------------
(The program was written in a jiffy by one of our students, but as he
forgot to comment it, I don't know exactly what it does, except for
feeding the input and the switches to a sendmail on the mailhost).
----------------------------------------------------------------------
This gives the extra advantage that the From: lines in outgoing mail
holds only the name 'daimi' which both our site name and the name
of the mailhost machine.
To have Pnews running on clients, just change the call of inews
to a remote shell call of inews on the newshost machine and setup
the correct site name manually.
Oh, and then we don't use the sendmail.cf provided by SMI. It
seems to contain a lot of complicated stuff to handle local mail
on the Ethernet - and that is perfectly unnecessary with the setup
described here.
I think that was all. Please don't flame me if I have forgotten
to describe one or two hacks. It works for us, and if something
is missing in the description, you are bound to discover it.
Of course the system doesn't like it at all if the mailhost is
unavailable. We haven't got around to fix it yet, but if the mailhost
is down while the news and mail directories are mounted on a client,
that client will hang on logins, call of mail and news frontends and
the like.
Good luck. Peder Chr. N|rgaard
-----------------------------
Date: Thu, 18 Sep 86 13:03:16 edt
From: cdx39!jc%rclex.UUCP@harvard.HARVARD.EDU
Subject: Sharing /usr/spool/mail on NFS (5)
> 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.
Sounds like a real good idea, and I'd be surprised if there
were any sort of problem. You get parallel access to this
directory even on a single system. If you watch closely enough,
you will eventually spot rmail(1) creating a lockfile in this
directory. It should work exactly the same on NFS. You will
have to arrange to set users' $mail shell variables to point
into the directory, but that should be all the hacking needed..
-----------------------------
Date: 11 Sep 86 13:32:20 PDT
From: deutsch.PA@Xerox.COM
Subject: SUN as timesharing machine
At CodeSmith Technology, we are running Sun-3/160s as 3-user timesharing
systems with two Wyse character terminals. Response is very
satisfactory, even with only 4 Meg of memory, as long as no one is doing
something demanding like running the tape drive.
-----------------------------
Date: Thu, 11 Sep 86 11:56:19 PDT
From: glenn@Sun.COM (Glenn C. Skinner)
Subject: NIT explained
"David T. Coffield" <david%computing.lancaster.ac.uk@Cs.Ucl.AC.UK>
expressed confusion about deciphering the information obtained by
reading from a NIT socket. The following commentary may be helpful.
Here's an explanation of the nit_ioc fields.
nioc_bufspace: This field governs the amount of kernel socket buffer
space to reserve for data that will appear on the read side of the
NIT socket. This field's effect is pretty much the same as that of
the 4.3bsd SO_RCVBUF setsockopt call, except that the amount of
space requested is internally rounded up to a multiple of MCLBYTES
(1024). Most NIT applications work best with a large value (say
32768).
nioc_chunksize: NIT is a message-oriented protocol. The chunksize
parameter controls what the maximum message size is. As packets
arrive, they are gathered together until the timeout expires (see
below) or until adding the next packet would make the aggregate
size (taking NIT headers and alignment into account) exceed
chunksize. Each chunk is delivered separately through the socket
interface. Alignment, as discussed below, is done chunk-by-chunk;
that is, the contents of each chunk are aligned without reference
to previous chunks. A good value for this parameter is large enough
to hold several incoming packets (or prefixes -- see nioc_snaplen).
For example, the etherfind program uses 2048.
nioc_typetomatch: NIT provides a primitive packet filtering
mechanism. When the typetomatch field is set to something other
than NT_NOTYPES or NT_ALLTYPES, only packets whose Ethernet type
field equals this field are passed through the socket. Note that
the filtering mechanism assumes that the associated interface is
an Ethernet interface.
nioc_snaplen: At most the first snaplen bytes of each packet,
including the link-level header, are passed through.
nioc_bufalign and nioc_bufoffset: When a packet is added to a chunk,
it is added following a NIT header, that gives timestamp and
length information and the current NIT state. The bufalign and
buffoffset parameters control how much space is skipped before
starting the NIT header. The rule is that the header starts at
the next place that is bufoffset bytes past an bufalign boundary
with respect to the beginning of the chunk. Once the NIT header
is in place, the packet itself appears immediately beyond it, with
no intervening gap. The intent of these fields is to allow the
programmer to force each packet of a chunk to appear at a
convenient alignment boundary.
nioc_timeout: The maximum time to spend gathering a chunk before
delivering whatever has accumulated to the NIT socket. This value
is meaningful only if the NF_TIMEOUT flag is set in the nioc_flags
field.
nioc_flags: The NF_PROMISC flag bit forces the underlying network
interface into promiscuous mode, so that all packets on the net
are candidates for capture, regardless of whether or not they are
addressed to the local host. The NF_BUSY flag is valid when
getting the NIT state and indicates that there is data available
in the socket.
The interface described above is provisional and will change in the
future. This is because we're unhappy with parts of the interface
(notably the filtering and alignment mechanisms) and plan to make them
more useful and/or less difficult to use.
To make all of this a bit more concrete, here's a code fragment from
the etherfind program. This is the part that reads from the NIT socket
and loops through each packet embedded in the chunk the read returns.
It assumes that nioc_bufalign == sizeof (int) and that nioc_bufoffset
== 0.
-- Glenn Skinner, SMI
-------- code fragment start -----------------------------------
refill_buffer:
while ((cc = read(if_fd, buf, sizeof (buf))) > 0) {
register unsigned char *bp, *bufstop;
struct nit_hdr *nh;
int datalen;
/*
* Loop through each packet. The increment expression
* rounds up to the next int boundary past the end of
* the previous packet.
*/
bufstop = buf + cc;
for (bp = buf; bp < bufstop;
bp += ((sizeof(struct nit_hdr)+datalen+sizeof(int)-1)
& ~(sizeof (int)-1))) {
nh = (struct nit_hdr *)bp;
sp = (struct sample *)(bp + sizeof(*nh));
switch (nh->nh_state) {
case NIT_CATCH:
datalen = nh->nh_datalen;
break;
case NIT_SEQNO:
case NIT_NOMBUF:
case NIT_NOCLUSTER:
case NIT_NOSPACE:
datalen = 0;
continue;
default:
fprintf(stderr,
"bad nit state %d\n", nh->nh_state);
goto refill_buffer;
}
/* Process the packet whose start is in *sp... */
}
}
---------code fragment end -------------------------------------
-----------------------------
Date: Fri, 12 Sep 86 00:31:20 PDT
From: guy%gorodish@Sun.COM (Guy Harris)
Subject: RCS on Suns
> Since I have had some requests, here are the diffs. As you can see, the
> changes are fairly trivial, just got to find 'em!
I see no change here to prevent RCS from dereferencing a null pointer. The
"rcs" command has a bug in that it tries to dereference a null pointer.
Here is a fix to "rcs.c". Line numbers are *not* exact.
***************
*** 987,993 ****
dummy.nextlock=next=Locks;
trail = &dummy;
while (next!=nil) {
! numr = strcmp(num, next->delta->num);
if ((whor=strcmp(who,next->login))==0 &&
(num==nil || numr==0))
break; /* found a lock */
--- 987,994 ----
dummy.nextlock=next=Locks;
trail = &dummy;
while (next!=nil) {
! if (num!=nil)
! numr = strcmp(num, next->delta->num);
if ((whor=strcmp(who,next->login))==0 &&
(num==nil || numr==0))
break; /* found a lock */
Note: I found this long before I came to Sun; there are *many* machines,
operating systems, and C implementations out there that forbid dereferencing
null pointers.
> char _sobuf[BUFSIZ]; /* Had to add this...should be in C library; franklin */
Why should it? It's not documented anywhere; dependng on undocumented
features that you "know" are there is very dangerous. Sun UNIX "malloc"s
all buffers, even those for standard output and error, rather than using
static buffers of a fixed size that is less than the file system block size.
-----------------------------
Date: Fri, 12 Sep 86 00:21:43 PDT
From: guy@Sun.COM (Guy Harris)
Subject: GB is not CA
> 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.
Depends on where they get the external date. Normally, it's synthesized
from the modification time of the root file system, which provides the year,
and the time-of-day clock, which provides the second within the year. The
former should always be in Universal Time, so once it's set correctly it
should continue to be set correctly. The trick is the *first* setting -
namely, the one when the system is brought up on the miniroot. When the
system first comes up, there should be a way to set the time zone
information, which would be done before setting the current time.
Unfortunately, there isn't. What you should probably do is boot the first
configured kernel (configured with the correct time zone) single-user, and
set the date all over again.
> Apparently, this is the represntation rdate uses.
Almost. Actually, "rdate" uses the date representation of the Internet Time
Protocol, as specified in RFC 868; this is the number of seconds since
January 1, 1900, 00:00 GMT, i.e. 70 years before the origin of UNIX time.
The two coordinate systems differ only by a translation
> 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.
The "Installing UNIX on the Sun Workstation" discusses setting the time
zone, somewhat in passing, under "General System Description Lines" in
chapter 7, "Configuring the System Kernel" - at least the 3.0 version does.
> I think Sun should fix this, e.g. by exchanging time zone info at boot time.
We'd like to handle time zones completely differently in some future major
release, using the code developed by Arthur Olson at the National Institute
of Health in the US. The kernel will only know about time zones for the
benefit of old programs; programs built with the new version will read a
table of starting and ending times for DST from a file. There is a compiler
that turns a file in a reasonably readable format into this table file; it
should be general enough to handle whatever variations national politicians
throw at you.
There can be a number of table files, and the one named "localtime" will be
the default. Thus, if the directory containing these files is shared via
NFS, all clients will get the same time zone as their server by default.
(Perhaps it might be useful to provide it as a Yellow Pages map instead.)
Berkeley would like to drop this code into 4.4BSD; it is considered public
domain by the author (obviously, "ctime" isn't public domain, but the public
domain code can be merged into "ctime"), so it may appear in other UNIX
systems. The library routines it adds are being proposed to the IEEE 1003.1
standards committee, so it may end up becoming standard for UNIX systems.
-----------------------------
From: Robert Stroud <robert%cheviot.newcastle.ac.uk@Cs.Ucl.AC.UK>
Date: Fri, 19 Sep 86 16:36:49 gmt
Subject: ie0: no carrier (1)
Unfortunately the ie(4) manual page doesn't have a DIAGNOSTICS section. The
other ethernet interface manual pages are more helpful, especially le(4),
and suggest that this problem is caused by a faulty transceiver cable.
Sure enough, when we had a whole spate of these messages a couple of months
ago, they went away when we replaced the transceiver cable. (We also got
ethernet jammed messages for the same reason).
Last week, the messages came back, together with an even stranger symptom
which was apparently unrelated. Although our SUN could talk quite happily
to VAXes and MG-1s, any packets it sent to a Perq (1 or 2) were rejected
with CRC errors! This despite the fact that our trusty Spidermonitor said
that nothing was wrong. We wondered if this might be some sort of mismatch
between the SUN's 3Com 802.3 transceiver and the Perq's 3Com Xerox 1
transceiver, although intercommunication had worked before, and our
ethermonitor used an old 3Com box as well. In the end, after we had
swapped the transceiver cable on the SUN again (probably back to the
original cable!), and waggled it around a bit, everything started to
work again - the Perqs talked to the SUNs, and the ie0 messages haven't
been seen since.
Needless to say, this was a rather unsatisfactory outcome, and I would
be grateful if anyone can shed more light on what might have been happening.
However, it has been my experience that most weird Ethernet faults are due
to flakey transceiver cable connections, and the wobbly slide connector
specified by the 802.3 standard does not help matters.
Robert Stroud,
Computing Laboratory,
University of Newcastle upon Tyne.
ARPA robert%cheviot.newcastle@cs.ucl.ac.uk (or @ucl-cs.ARPA)
UUCP ...!ukc!cheviot!robert
JANET robert@newcastle.cheviot
-----------------------------
Date: Mon, 15 Sep 86 08:43:53 -0500
From: edelheit@mitre.ARPA
Subject: ie0: no carrier (2)
David - I get that and some other nfs msgs on my 2/50 fairly
frequently all the time. When I asked about the msgs, I was told not
to worry about it; that it happens all the time.
Regards,
Jeffrey A. Edelheit (edelheit@mitre.arpa)
The MITRE Corporation, 1820 Dolley Madison Blvd.
McLean, VA 22102 (703) 883-7586
-----------------------------
Date: Tue, 23 Sep 86 15:28:07 -0100
From: Antony Williams <asw%vax-d.rutherford.ac.uk@Cs.Ucl.AC.UK>
Subject: ie0: no carrier (3)
I have seen these messages also, but not as frequently
as dms@hermes.ai.mit.edu reported. We run a mixture
of 3/75, 3/120, 3/160, 3/180 and a few sun 2/50 and 2/120.
It seems to be the discless 3/75 machines which report the
error. Mine gives typically one such message some time during
the night. I have also seen "ethernet jammed", "nfs server
not responding", and "nd server not responding" messages.
These can and do occur when the server machine is up and
running, but of course it may be temporarily too busy.
My favorite message in the console window is
sun: terminal is too dumb
which is emitted by several of our shells which try to do
command line editing, and can't because the console is a
cmdtool rather than a shelltool, and doesn't support
cursor movements etc.
---------------------------------------------------------------------------
Tony Williams |Informatics Division
UK JANET: asw@uk.ac.rl.vd |Rutherford Appleton Lab
Usenet: {... | mcvax}!ukc!rlvd!asw |Chilton, Didcot
ARPAnet: asw%vd.rl.ac.uk@ucl-cs.arpa |Oxon OX11 0QX, UK
-----------------------------
Date: Mon, 15 Sep 86 08:39:01 -0500
From: edelheit@mitre.ARPA
Subject: Alternative Memory Boards (1)
Jon - Helios Systems (nee LCF Intl.) sells both VME and Multimbus memory
for the Sun. I know the VME memory is for the Sun 2, but may be useable
in the Sun 3; or they may have a product out soon.
Norb Witt is one of the primary people to talk to at Helios. Helios'
address and phone # is:
Helios Systems, Inc.
P.O. Box 41203
San Jose, CA 95160
408-356-0271
Regards,
Jeffrey A. Edelheit (edelheit@mitre.arpa)
The MITRE Corporation, 1820 Dolley Madison Blvd.
McLean, VA 22102 (703) 883-7586
-----------------------------
Date: Mon, 29 Sep 86 18:09:09 PDT
From: hoptoad.uucp!cfcl!rdm@sun.UUCP (Rich Morin)
Subject: Alternative memory boards (2)
Alternatives to Sun memory boards
I know of two firms (other than Sun) that are currently making memory
boards for Suns. I am only including quantity one prices here, for
brevity. Both firms offer assorted discounts for quantity, etc. As
this is a VERY volatile market, I would suggest that all prices be
checked before any purchase decision is made.
The oldest firm is LCF International, whose sales arm is Sales One:
Sales One
50 Airport Pkwy., #64
San Jose, CA 95110
(408) 947-1266
Their current prices are as follows:
Multibus: 3/75, 3/160, 3/180
DM2-1 1 MB $500 DM3-4 4 MB $3300
DM2-2 2 MB $1000 DM3-8 8 MB $5500
DM2-3 3 MB $1500 DM3-12 12 MB $7700
DM2-4 4 MB $2000 DM3-16 16 MB $9900
LCF has been around for a while, and their boards have an extensive
(and generally good) track record. (Sun's flaky memory interface on
the Multibus makes ANY add-on memory a problem, even for Sun...) In
any case, LCF has an unlimited warranty (as in Craftsman tools, Zippo
lighters, etc.) for their boards. In addition, they give full credit
for trade-in of old LCF boards on the purchase of new ones(!)
A newer firm, Helios, has recently spun off from LCF. Their boards
may well be just as good as LCF's, or even better. They also give a
lifetime warranty, but have no similar trade-in policy. Their Sun-3
VME memory boards are shipping, but they don't (quite) have the Sun-2
boards on the market yet.
Helios Systems, Inc.
P.O. Box 41203
San Jose, CA 95160
(408) 268-2078
Their current Multibus prices are as follows:
MSM-2 2 MB $975
MSM-3 3 MB $1475
MSM-4 4 MB $1975
Their VME prices (Sun-2 avail. mid-Oct.) are as follows:
2/50, 2/130, 2/160 3/75, 3/160, 3/180
MSJ-2 2 MB $1750 MSV-4 4 MB $2800
MSJ-4 4 MB $2800 MSV-8 8 MB $4500
MSJ-6 6 MB $3700
-----------------------------
Date: Tue, 16 Sep 86 15:18:20 pdt
From: Barry Brachman <brachman%ubc.csnet@CSNET-RELAY.ARPA>
Subject: Graphics for C-Prolog on the SUN
I'm posting to net.sources a package called gprolog that lets you call graphics
routines in the SunCore library from C-Prolog.
GProlog runs on both the SUN 2 and SUN 3 (4.2BSD Releases 2.3/3.0).
The distribution includes:
- diffs to be applied to C-Prolog 1.5
- code that implements the interface between Prolog and SunCore
- a user's manual
- three puny demos
To run gprolog you'll need:
- Larry Wall's (great!) patch program (or a lot of patience)
- the unaltered source to C-Prolog version 1.5
- a SUN 2 or SUN 3 with a console (i.e., bit mapped display),
the SunCore library and preferably suntools (does everybody get
SunCore and suntools?)
-----
Barry Brachman
Dept. of Computer Science
Univ. of British Columbia
Vancouver, B.C. V6T 1W5
.. {ihnp4!alberta, uw-beaver}!ubc-vision!ubc-cs!brachman
brachman@cs.ubc.cdn
brachman%ubc.csnet@csnet-relay.arpa
brachman@ubc.csnet
-----------------------------
Date: 25 Sep 86 22:01:23 GMT
From: rick@seismo.css.gov (Rick Adams)
Subject: SUN printf (cc or awk) bug
There is a bug in the SUN implementation of printf (cc or awk). It has been
around for years and I am reporting it now cause I've stopped
assuming it will be discovered and fixed for the next release.
basicly, a printf conversion specification like %06.3f produces the same
output as %6.3f , %02d works as it should, so a work around is possible.
try this code on your sun and non sun (works on our VAX and Celerity):
main()
{
printf("%02d %06.2f\n",1,2.2);
}
or
echo 1 2.2 | awk '{printf("%02d %06.2f\n",$1,$2)}'
seismo!tiberio
Michael Anthony Tiberio
Center for Seismic Studies
-----------------------------
Date: Thu, 11 Sep 86 18:04:22 EDT
From: Steve M. Burinsky <smb@mimsy.umd.edu>
Subject: Removable disks for Suns?
I need the fastest, biggest, and cheapest removable disks available that
I can hang off my Sun. Does anyone know if such things exist?
Thanks in advance,
Steve
-----------------------------
Date: Wed, 10 Sep 86 08:39:53 edt
From: "Ian G. Batten at The University of Birmingham" <CCAse3-1%multics.computer-centre.birmingham.ac.uk@CSNET-RELAY.ARPA>
Subject: Full Screen Mous-ing?
Acknowledge-To: "Ian G. Batten" <CCAse3-1@UK.AC.BIRMINGHAM.COMPUTER-CENTRE.MULTICS>
Date: Tue, 9 Sep 86 17:49+0100
I want to write a tool that will allow me to selectivly dump part of the
screen as a pixrect. I'd like to be able to type "dump", then mark an
area of the screen by dragging a rectangle, then have it dumped out.
The problem is how to (i) get the mouse events without setting up a
frame to receive the events and (ii) draw the rectangle over window
boundaries without doing anything horrible. I've tried most of the
things in the "SunView Programmers' Manual" and I'd rather not delve
into "System Programmers' Manual" unless I have to.
Parenthetically, has it been noted that the documentation for
"canvas_event" is wrong? It takes a window handle and an event, not an
event. That's p72, "SunView Programmers'":
event_in_canvas_space = canvas_event (window, event);
Ian G. Batten, Research Associate, ICAI Project,
Department of Computer Science,
University of Birmingham,
PO Box 363,
BIRMINGHAM, England.
Phone: +44 21 472 1301 Extension 3198.
JANET: CCAse3-1 at UK.AC.BHAM.MULTICS
ARPA: CCAse3-1 at UK.AC.BHAM.MULTICS via CSNET-RELAY.ARPA
BITNET: CCAse3-1 at MULTICS.BHAM.AC.UK via UKACRL.BITNET
UUCP: CCAse3-1 at UK.AC.BHAM.MULTICS via UKC.UUCP
(=> ...!decvax!mcvax!ukc)
-----------------------------
Date: Thu, 11 Sep 86 23:23:27 EDT
From: Ken Mandelberg <km%emory.csnet@CSNET-RELAY.ARPA>
Subject: Abort Sequence on Sun?
Is there any way to disable the keyboard abort sequence on a Sun 3?
We would like to keep one in a semi-public area, and the prospect of
tampering is bothersome.
Ken Mandelberg
Emory University
Dept of Math and CS
Atlanta, Ga 30322
{akgua,sb1,gatech,decvax}!emory!km USENET
km@emory CSNET
km.emory@csnet-relay ARPANET
-----------------------------
Date: Thu, 11 Sep 86 16:34:54 bst
From: Robin Boswell <robin%aiva.edinburgh.ac.uk@Cs.Ucl.AC.UK>
Subject: How do I use -background in suntools ?
I remember reading in an earlier digest about an undocumented feature
of suntools for the SUN3 whereby
suntools -background <file>
caused <file> to appear in the background, rather than the usual grey,
white or black.
I haven't been able to get this to work, presumably because my <file>
has been of the wrong format. Can someone please tell me the exact
format required?
Thank you,
Robin Boswell
robin%uk.ac.edinburgh.aiva@ucl-cs.arpa
-----------------------------
Date: Thu, 11 Sep 86 12:55:50 EDT
From: Matt Landau <mlandau@Diamond.BBN.COM>
Subject: NFS between Sun 100's and Sun 3's?
I have a Sun 3/160 (Unix 3.0) and a Sun 150U (Unix 2.2), both with disks and
each a fileserver for other workstations of its own CPU type, that are
trying to share files via NFS. The 150U is having problems trying to copy
large files from a remote filesystem to a local one -- if the files are
reasonably small, things work fine; but if the files are very large (e.g.,
1.5 megabytes), the 150 complains that the Sun 3 server is not responding.
I've tried having the 150 mount the Sun 3's filesystems with smaller than
normal read and write buffer sizes (rsize = wsize = 2048), but this doesn't
seem to help. Any suggestions?
--
Matt Landau BBN Laboratories, Inc.
mlandau@diamond.bbn.com 10 Moulton Street, Cambridge MA 02238
...harvard!diamond.bbn.com!mlandau (617) 497-2429
-----------------------------
Date: 09 Sep 86 21:39:22 PDT (Tue)
From: Dave Truesdell <davet%tp4@rand-unix.ARPA>
Subject: Xylogics 451's?
Does anybody out there know the proper way to configure a Xylogics 451
controller for a Sun-3/180? Ours were shipped without any documentation.
It seems to work, except for a message at boot time, about using 20-bit
addressing. However, I've been having some problems with the system
hanging, while doing file I/O. When the '451 gets swapped with another
systems '450, the problem goes away. (It still warns about using 20-bit
addressing.)
I want to see if the configuration is at fault, before I go claiming that
I have a bad board.
By The Way, "diag" doesn't report any errors. None...
David A. Truesdell
The Rand Corporation
ARPAnet:
davet%tp4@rand-unix
UUCP/usenet:
{hermix,hollywood,litvax,trwrb,ttidca,vortex}!randvax!davet
-----------------------------
Date: 17 Sep 86 09:19:06 PDT (Wednesday)
From: Pugh.ES@Xerox.COM
Subject: Large DBMS on Sun workstations?
I am interested in gathering user feedback on large commercially
available DBMS that run on SUNs. By large I am looking at 100K to 1M
entries. Please send responses to me and I will summarize for the
digest if requested.
/Eric
-----------------------------
Date: Thu, 18 Sep 86 09:58:13 -0200
From: mcvax!daimi!pederch@seismo.CSS.GOV (Peder Chr. N|rgaard)
Subject: Is the procedure call convention documented?
Writing a compiler, we have encountered the problem, that we
don't know the exact procedure call convention shared between
C, Fortran, Pascal and a lot of other languages implemented on
SUNs. That is, which registers are guaranteed to be unchanged
by any call of a procedure following the convention? We can make
some qualified guesses by compiling a lot of different C routines,
but an exact definition would be nice.
Thank you in advance.
Peder Chr. N|rgaard, Aarhus University, Denmark
-----------------------------
Date: Thu, 18 Sep 86 13:42:08 edt
From: Brian Sullivan <sullivan%wanginst.edu@CSNET-RELAY.ARPA>
Subject: SUN3 disk controller specifics?
One of my main uses for a SUN-3 workstation will be the development of
database software. I am therefore interested in learning about certain
performance and failure characteristics of disks and controllers that
are available for SUN-3 workstation. Some of the information of interest
includes the following:
1. What sector sizes do the controllers support? Can this be set by
the user?
2. What is the range of file block sizes that are supported?
3. Do the controllers support "scatter/gather". That is, can the
controller handle a read/write command on a block such that
the block on disk does not consist of contiguous sectors, and
the buffer in memory does not consist of contiguous sector-sized
units? Do the disk drivers exploit this facility?
4. What form a checksum protection is provided for disk blocks?
Does it protect the contents of the block? Does it protect the block's
address? Does the upper limit on sector size (see (1) above) include
the checksum bits?
I expect that this information will NOT be readily available.
However, if someone would identify the documents and/or people from
which/whom the information can be got, I'm willing to spend some time
in actually figuring out the details.
Brian M. Sullivan sullivan@wanginst (Csnet)
Wang Institute of Graduate Studies decvax!wanginst!sullivan (UUCP)
Tyng Road, Tyngsboro, MA 01879 (617) 649-9731
-----------------------------
Date: Wed, 17 Sep 86 09:08:53 PDT
From: John Bruner <jdb@s1-c.arpa>
Subject: IMP Interface for Sun 3?
I am interested in the availability of IMP (ARPANET/MILNET) interfaces
for Sun 3's. Ideally, the interface would plug directly into the
Sun backplane and would include a Sun 3.0 device driver; however, I'd
be interested in hearing about any VME-bus device (we can always use
an adapter card, and if necessary I can write or adapt the device
driver).
Presently our local network is connected to MILNET through two
VAX 11/750's. Our need for a Sun IMP interface isn't critical (we
don't plan to get rid of the VAXes in the forseeable future), but
in the long term we'd like to gateway through a Sun.
--
John Bruner (S-1 Project, Lawrence Livermore National Laboratory)
MILNET: jdb@mordor [jdb@s1-c.ARPA] (415) 422-0758
UUCP: ...!ucbvax!decwrl!mordor!jdb ...!seismo!mordor!jdb
-----------------------------
Date: Thu, 18 Sep 86 23:13:57 EDT
From: Mark Weiser <mark@brillig.umd.edu>
Subject: RHS of shoebox?
The mass storage installation guide for shoeboxes warns to only run
them vertically on their left sides, never their right. Which
side IS the right side? Is the proper orientation with the Sun logo
at the top, or at the bottom?
-mark
-----------------------------
Date: Thu, 18 Sep 86 23:10:19 EDT
From: Mark Weiser <mark@brillig.umd.edu>
Subject: 3/75 upgrade question?
I have a 4M 3/75 with a shoebox. I would like to upgrade it to 8M. If I buy
the 3/75 4M expansion board from Sun, I presume this board
has a place for a SCSI adapter? Do I then just remove the
SCSI adaptor from my 75's current blank adaptor (in the upper slot
of the 75) and put it on the memory expansion board? And is this
as easy as just plugging it in?
-mark
-----------------------------
Date: 18 Sep 1986 15:32:49-EDT
From: prindle@NADC
Subject: A query about hardware emulator on a Unix system?
Greetings,
I would like to enlist the aid of this net-newsgroup community in exploring
a potential hardware approach to upgrading a programming support enviroment.
We are also looking at strictly software approaches, but these currently
appear to have a high risk.
Requirements for the hardware approach:
a. A micro-programmable co-processor board which would interface directly with
a high speed, state-of-the-art, computer which primarily runs a variant of
Unix (preferrably System V, 4.x-BSD, or a happy marriage of the two).
This board would be capable of emulating the instruction set architecture
of a fairly primitive 30 bit militarized computer, specifically a Sperry
(Univac) model CP-901/CP-642B. I/O channel instructions within this ISA
would be converted, by the board, into interrupt requests to be honored by
the main processor and the Unix system. The board would directly access
a block of host computer virtual memory space (allocated by the Unix system)
as the emulated computer's memory. The emulator could be multiprogrammed
under control of the main processor and the Unix system: i.e. it could be
stopped or started at any time by the main processor, any and all of it's
registers would be readable or writable by the main processor, and the DMA
memory mapping may be altered by the main processor.
- or -
b. A high speed, state-of-the-art, dual or multi-processor computer, running
Unix as above, in which one or more of the processors could be micro-
programmed to emulate the CP-901/CP-642B ISA as above, and dedicated to
that task, with the remaining processor(s) running the Unix system.
The goal is to run existing CP-901/CP-642B hosted support tools and some
application programs with a substantial throughput improvement over a system
which utilizes a physical CP-901/CP-642B computer. The bottlenecks in such a
system are the physical computer resource itself (which, because it is loosly
coupled to the host computer, cannot be effectively multiprogrammed), and the
I/O channels which provide the only data paths in or out of the physical
computer. A tightly coupled co-processor, sharing memory with the host
computer and with the ability for the host computer to intervene in it's
execution, eliminates these bottlenecks. Since, additionally, state-of-the-art
hardware would be handling the CP-901/CP-642B emulation, as contrasted with the
antiquated (and militarized) hardware of the physical computer, it is reasonable
to expect at least a tenfold improvement in throughput (with a single
co-processor vs. using a single physical computer).
Possible candidates for the host computer are a Sun III, Dec 8600 or VAX 11/785,
AT&T 3B series, or anything else which might meet the above requirements.
I would appreciate any information which anyone might have about the existence
of such a system or a similar system which may have been implemented; as well as
any thoughts about the feasibility or potential efficiency of such a system.
Please netmail any reply directly to me, as I do not subscribe to all these
newsgroups.
Sincerely,
Frank Prindle
Naval Air Development Center
Warminster, Pa. 18974
Milnet: Prindle@NADC.arpa
-----------------------------
Date: Sat, 20 Sep 86 14:07:26 -0500
From: mex107@mitre.ARPA
Subject: 160c vs 260c?
I began to order a Sun 3/160c with a few extra memory boards, 140MB disk and
some other goodies, but my friendly neighborhood salesman convinced me to get
a 260c, a little less memory and a 2x bigger disk (this for AI applications).
Giving up a few of the goodies (nothing crucial) and the price was about the
same.
Query: Anyone have experience with a 260c yet? Any incompatibilities with
a 160c? Thanks for the help.
Mike Leavitt <mex107@mitre.arpa>
-----------------------------
Date: Mon, 22 Sep 86 20:00 EDT
From: HUDGENS%FSU.MFENET@LLL-MFE.ARPA
Subject: Kermit problems on 3.0?
We have a mixed system of sun2/50s, sun3/50s, and sun2/170s.
and are currently running version 3.0 on one file-server
and version 2.0 on the other. Uxkermit runns well on the
version 2.0 machine, but hangs in server mode on the version
3.0 machines. All other conditions are (apparently)
identical. In both cases, the same identical code
was compiled on the respective machines. HAs anyone
ever had similar problems? (or fixes?)
Jim hudgens
-----------------------------
Date: 23 Sep 1986 13:04-EDT
From: Mike.Blackwell@rover.ri.cmu.edu
Subject: Compiling for 68010 on Sun-3?
I know this already went by a few months ago, but it seems that the
archives don't go back quite far enough. So... Could somebody please
tell me the magic undocumented switch to get cc to produce code for a
68010? Please reply directly to me. Thanks much!
-m- (mkb@rover.ri.cmu.edu)
-----------------------------
Date: Thu, 25 Sep 86 19:30:37 edt
From: gihill%thunder.waterloo.edu@CSNET-RELAY.ARPA
Subject: HP plotter on SUN-3?
We have a Hewlett-Packard model 7475A plotter that we would like
to attach to a SUN-3 machine. Amoung other things, it would be used
to print screen images on the Sun workstation. We have no software
for this device however. Can someone send us:
1. A /etc/printcap entry
2. A device driver that would run on a SUN-3.
Thanks for any help.
-----------------------------
Date: Thu, 11 Sep 86 10:16:29 PDT
From: hansen (Paul Hansen)
Subject: General purpose I/O card for SUN3 workstations?
Having called SUN several times and gotten into the infinite loop:
"hold/wait/re-route-to-marketing/re-route-to-switch-board/disconnect/ ..."
I thought it would be faster to ask:
Does anyone out there have any experience with building custom
interfaces to SUN3 workstations? That would presume some sort of
general purpose bit-banger I/O card that plugs on the VME bus with
(hopefully) device driver software. Does SUN or some 3rd party offer
any help in doing this? ie, documentation, etc?
Any advice would be appreciated.
-Paul-
-----------------------------
Date: Thu, 18 Sep 86 15:41:08 edt
From: kish@caip.rutgers.edu (Bill Kish)
Subject: SUN 3/160 graphics on film?
Does anyone have experience with capturing SUN 3/160 graphics on film, VHS, or
Beta ? Does anyone have suggestions on who sells RGB to NTSC encoders and/or
a piece of hardware that will perform "scan conversion" whereby 1/2 of the
detail of the 1152 pixel line can be captured ?
-Bill Kish
-----------------------------
Date: Sun, 21 Sep 86 20:20:20 -0100
From: "Michael Schmidt" <unido!pbinfo!michael@seismo.CSS.GOV>
Subject: Floating Point Library Functions Query?
I need some informations (or hints, how to get them) about
floating point operations on the SUN.
Which functions are available, where do they expect the
parameters and where do they deliver the result?
Michael Schmidt
UUCP: ...!seismo!unido!pbinfo!michael | Post: Michael Schmidt
or michael@pbinfo.UUCP | Universitaet-GH Paderborn
| FB 17 - Informatik
CSNET: michael%pbinfo.uucp@Germany.CSNET | Warburger Str. 100
| D-4790 Paderborn
ARPA: michael%pbinfo.uucp@seismo.css.gov | West Germany
-----------------------------
End of SUN-Spots Digest
***********************