rif@RICE.EDU (Vicky Riffle) (07/14/87)
SUN-SPOTS DIGEST Monday, 6 July 1987 Volume 5 : Issue 22
Today's Topics:
Re: xy450/xy451 failure modes
Re: multiple SunCore/SunView windows
Re: Dynamic SunView objects generation
Re: 68881s
Mounting /usr/spool/mail remotely on a SUN network . . . (long)
newer (bug fixed) 4.3bsd tcp for Sun OS 3.3 available
Breaking into Suns
sun/vax restore under 3.2
press release - SUN RE-PRICES DOS CO-PROCESSOR FOR TECHNICAL PC MARKET
press release - SUN AND SCHLUMBERGER JOIN IN AI VENTURES
using low-resolution printers?
Ada compilers for the Sun ?
how many sun-2 clients per sun-3 fileserver?
maintaining passwd file?
File-descriptors in 3.x ?
Time measurement on UNIX?
Multitech Modem help?
extending video cable on Sun-3/260 HM - problems?
CSC Wren IIIs?
------------------------------------------------------------------------
Date: Fri, 26 Jun 87 12:35:31 PDT
From: jeff@tc.fluke.com (Jeff Stearns)
Subject: Re: xy450/xy451 failure modes
In Sun-Spots Digest, v5n20, Jim Guyton writes (and I edit here):
|
| We've been running a lot of Sun-2's and 3's with Xylogic 450/451's and
| Eagles/Super-Eagles.
|
| Over the years we've had at least three different controller boards fail on
| us in such a way that the failure went UNDETECTED by the device driver.
|
| ... Nothing to indicate the data wasn't being written/read correctly
| other than the fact that Unix slowly (or not so slowly) trashes your
| filesystems and ND clients go down with VGETU panics. After a while the
| server crashes due to freeing free inode or something similar.
|
| Each time replacing the controller fixed the problem. The failures have
| been on three different file-servers, in two different machine rooms.
| Both 450's and 451's.
|
| Query: I've not heard of anyone else having this problem with their
| controller boards. Are we alone?
|
| -- Jim Guyton guyton@rand-unix.arpa
Sounds to me like you're running up against the performance limits of the
Xylogics 450/451 controllers. At this point, they'll sometimes deliver a
block of zeros rather than the data you asked 'em to read. There is apparently
no way to know when this has happened, so the Sun device driver does not
report any error back to the user. It just hands you that block of zeros.
I've personally seen this bug crash machines at my site on the order of
one hundred times (the details are too horrifying to relate in this note).
I have also spoken with other administrators who have suffered this problem
as well. I can emphatically state that you're not alone.
The newly-published Sun bug reports finally acknowledge this long-standing
problem in a somewhat discrete manner.
I know of only one workaround - decrease the instantaneous load on your
disk controller. For us, that means one drive per controller. If you feel
that extra controllers should be provided at no cost to you, you may wish
to make those opinions known to your Sun reps. (You *have* discussed this
problem with them, haven't you?)
--
Jeff Stearns 206-356-5064 new: jeff@tc.fluke.COM
John Fluke Mfg. Co. old: uw-beaver!fluke!jeff
P.O. Box C9090 Everett WA 98206 or: allegra!fluke!jeff
------------------------------
Date: 22 Jun 1987 16:26
From: Hans.Tallis@ml.ri.cmu.edu (Hans Tallis)
Subject: Re: multiple SunCore/SunView windows
I've had the same problem, and the answer is to punt the WINDOW_GFX
hack, which only works the very first time. It is only to be used by
'naive' programs, though I agree, the SunCore documentation is quite
lacking in telling what to do if you want to write a world-wise
program. Basically, you have to fill enough of the vwsurf fields
for SunCore's initialize_view_surface to find the correct canvas to
work with. initialize_view_surface will then fill in whatever else is
missing in the vwsurf structure.
Here are some comments and some code which should help quite
a bit; I'm extracting from a running C program on a Sun 3/260 with
GP/GB. In the coments I reference a few yet-untried ideas I had; as
soon as I got one working, I went on to other things.
N.B. This is a rough extraction, but you should get the idea.
-----------------
static struct vwdata { /* our own structure */
Boolean vwinuse;
View *vwptr;
struct vwsurf vwsurface;/* vwsurf is SunCore-defined */
Boolean vwsurfaceinitialized;
Frame vwframe;
Canvas vwcanvas;
VectorType globalViewPoint;
} ViewArray[MAXNVIEWS];
...
/*
* Create a SunView canvas and encompassing frame.
*/
ViewArray[index].vwframe =
window_create(0, FRAME,
FRAME_LABEL, v->name,
FRAME_NO_CONFIRM, TRUE,
FRAME_SHOW_LABEL, TRUE,
WIN_HEIGHT, v->screenHeight,
WIN_WIDTH, v->screenWidth,
WIN_X, v->xPos,
WIN_Y, v->yPos,
WIN_SHOW, FALSE,
0);
/*
* interpose in front of the frames destroy event handler. We do not
* replace or eliminate the regular client (agent?); rather we just want
* to see the event before the client does.
*/
notify_interpose_destroy_func(ViewArray[index].vwframe, my_notice_destroy);
/* create a canvas */
ViewArray[index].vwcanvas =
window_create(ViewArray[index].vwframe, CANVAS,
CANVAS_RETAINED, FALSE, /* too memory expensive */
CANVAS_AUTO_EXPAND, TRUE, /* these two to have it track
* the parent frame size
* automatically */
CANVAS_AUTO_SHRINK, TRUE,
CANVAS_FIXED_IMAGE, FALSE, /* canvas size changes
* require a total
* repaint */
CANVAS_REPAINT_PROC, RepaintCanvas,
CANVAS_RESIZE_PROC, ResizeCanvas,
0);
/*
* actually bring up the window to be visible
*/
window_set(ViewArray[index].vwframe, WIN_SHOW, TRUE, 0);
/*
* set up WINDOW_GFX environment variable. This is for the sake of
* get_view_surface. get_view_surface wants to find an appropriate
* physical device and then translate that into the corresponding device
* driver. For a Sun3/260 with Graphics Processor, and in a SunTools
* environment, this is gp1pixwindd(). We could just have assigned the
* vwsurface.dd slot directly, but get_view_surface is more general
* purpose. It also assigns the .screenname slot, which on the Sun
* described is /dev/fb. Check out Appendix B of the SunCore Reference
* Manual. get_view_surface is a SunCore function for use explicitly
* (exclusively?) when running inside a SunTools window.
*/
/*
* Inside SunTools, SunCore likes to create 'Graphics Tools' as the
* surface on which to draw. In fact, unless you specifically tell it not
* to do this, or get lucky (see below), this is what will happen.
* Unfortunately, created Graphics Tools just end up in the middle of the
* screen, a not too satisfactory solution if you want nice placement of
* your window. There are three ways I can imagine of getting SunCore to
* work in the proper window: (1) The first time we use
* initialize_view_surface, you can explicitly set the environment
* variable WINDOW_GFX from the name-translated fd of your
* already-created canvas, and SunCore will find it correctly; thus no
* new Graphics Tool will be created. Unfortunately, this only works the
* first time. (2) Do not create a window, but let SunCore create a
* Graphics Tool automatically, as is its wont, and then grab that window
* and start manipulating it: set the label, size, and location. I have
* not actually tried this. (3) Try setting explicitly as many of the
* vwsurf structure parameters as you can, and hope SunTools will be
* satisfied with these and will not try to create a Graphics Tool.
*
* It appears now that option (3) is getting us somewhere: SunCore is
* picking up on the created canvas.
*/
fd = (int) window_get(ViewArray[index].vwcanvas, WIN_FD, 0);
win_fdtoname(fd, name); /* translate fd to corresponding device name */
/* we_setgfxwindow(name); */
/*
* Find the physical device driver routine. This is for SunCore. It sets
* vwsurface.dd, which must be set before calling
* initialize_view_surface, or SunCore will shit.
*/
if (get_view_surface(&(ViewArray[index].vwsurface), FALSE)) {
if (debug) {
report_most_recent_error(&error_number);
print_error("graphics:InitializeView: SunCore error after get_view_surface?",
error_number);
}
exit(1);
}
/*
* Set up to have all windows share same color map.
*/
ViewArray[index].vwsurface.cmapsize = MAXCOLORS;
sprintf(ViewArray[index].vwsurface.cmapname, "CM_%D", getpid());
/*
* Set some of the vwsurf structure fields to make sure SunCore finds the
* correct canvas to work with.
*/
strcpy(ViewArray[index].vwsurface.windowname, name);
ViewArray[index].vwsurface.windowfd = fd;
/*
* initialize view surface. This is the first SunCore call for this view
* surface; it fills in what is blank in the vwsurf structure. This call
* sets vwsurface.screenname, .windowname, .windowfd, and .instance.
* Across calls on the same machine, screenname should remain constant,
* while windowname, windowfd, instance should be unique(?)
*/
if (initialize_view_surface(&(ViewArray[index].vwsurface), TRUE)) {
if (debug) {
report_most_recent_error(&error_number);
print_error("graphics:InitializeView: SunCore error after initialize_view_surface?",
error_number);
}
exit(1);
}
ViewArray[index].vwsurfaceinitialized = TRUE;
if (select_view_surface(&(ViewArray[index].vwsurface))) {
if (debug) {
report_most_recent_error(&error_number);
print_error("graphics:InitializeView: SunCore error after select_view_surface?",
error_number);
}
exit(1);
}
* explicit dispatch
*/
(void) notify_dispatch();
if (deselect_view_surface(&(ViewArray[index].vwsurface))) {
if (debug) {
report_most_recent_error(&error_number);
print_error("graphics:InitializeView: SunCore error after deselect_view_surface?",
error_number);
}
exit(1);
}
----------------
Other warnings: SunCore doesn't work easily with multiple surfaces.
For example, delete_all_retained_segments works on _all_ segments, not
just those for the currently selected view. I think it also helps to
create view-specific segment id's, since it's possible for one currently
selected view to trash the segments of another.
Also: I'm having lots of Repaint/Resize Canvas problems: it seems the
interaction between SunView and SunCore isn't completely smoothed over.
For example, I had the idea that whenever ResizeCanvas gets called, so
would RepaintCanvas, though it hasn't worked that way for me.
One last gripe: I am getting weird filled-polygon clipping problems
with this configuration. I don't know if this is a SunCore, or perhaps
a SunCore/SunView interaction problem.
If anyone has workarounds or hints for these problems, I'd appreciate
mail.
Hope this helped, Hans.Tallis@ml.ri.cmu.edu
------------------------------
Date: Mon, 22 Jun 87 16:33:28
From: mcvax!idec.stc.co.uk!anjo@seismo.css.gov (Anjo Anjewierden)
Subject: Re: Dynamic SunView objects generation
> Is it possible to create SunView subwindows and windows dynamicly ? > And if the answer is YES, how this may be implemented.
I figured this out about 1.5 years back (for a pre-release of SunView 3.0).
It still works under 3.2, although by now there may be easier ways of
doing it. The secret is manipulating the WIN_SHOW attributes:
base_frame = window_create( 0, FRAME,
... any other arguments
0, );
window_main_loop( baseFrame );
/* For each frame you want to create afterwards: */
new_frame = window_create( baseFrame, FRAME,
WIN_SHOW, FALSE,
... any other arguments
0, );
/* for each subwindow in the frame: */
new_sw = window_create( new_frame, TEXTSW,
WIN_SHOW, TRUE,
... any other arguments
0, );
window_fit( new_frame );
window_set( new_frame,
WIN_SHOW, TRUE,
0 );
Anjo Anjewierden,
University of Amsterdam,
...!mcvax!swivax!anjo.
P.S. I'm using this in a system of more than 600 pages source code.
It would take me some time to dig out the relevant bits if you
want the REAL code.
------------------------------
Date: Tue, 23 Jun 87 12:07:19 EDT
From: umix!itivax!lokkur!scs@rutgers.edu (Steve Simmons)
Subject: Re: 68881s
We had (have) some very early Sun 3/50s which did not come with
68881s. Sun offered to upgrade our systems for an absolutely
huge price, which we declined. Sun (local office) told us that
there were problems matching the 68881s to the 68020 [[we're
software people -- you can lead us on]] and you couldn't just
stick one in. We looked at the price of a 68881 and decided
trying a couple was worth it.
At this point we upgraded 40+ machines, with zero problems.
Steve Simmons
Applicon, Ann Arbor, MI.
ihnp4!itivax!lokkur!scs
------------------------------
Date: 27 Jun 87 15:53:13 GMT
From: elsie!ncifcrf!randy@seismo.css.gov (Randy Smith)
Subject: Mounting /usr/spool/mail remotely on a SUN network . . . (long)
I've recently put in the effort (banging on contacts at sun,
asking other people with source many questions, and experimenting)
to figure out why SUN does not recommend that one remotely mount
/usr/spool/mail and how it might be accomplished if one is
determined enough to ignore the recommendation of the manufacturer
(not that that describes any of the people on this net :-}). I
finally got it working and recently wrote up an outline of what I
learned and what I did for a friend of mine, which I thought I would
also post to help out other people who might be trying to do the
same thing. I'm running SUN OS 3.2 with 7 machines (3 with disks
and 4 without). I'll be happy to field any questions (that I can)
about what follows. It mostly my work, though I wouldn't have been
able to accomplish what I did without the help of my contacts at sun
(who have requested anonymousity).
-- Randy Smith
seismo!elsie!ncifcrf!randy
Anyway. The reason that it's not easy to set up a system where
/usr/spool/mail is remotely shared among several machines (for the
sake of simplicity I'll refer to this group of machines as being a
"mail domain") is that root access is not propagated over NFS. This
means that when someone (read 'sendmail' or '/bin/mail') trys to
deliver a mail message on a system which has /usr/spool/mail
remotely mounted, it fails because sendmail and /bin/mail run setuid
to root and hence has no special access to any of the files in
/usr/spool/mail. It is NOT (as some scurilous rumors have
suggested) because sendmail has locking conflicts over the network;
sendmail and the other mailing agents (/bin/mail and /usr/ucb/mail)
use a create-error-if-file-exists locking mechanism in
/usr/spool/mail which works even over NFS (sendmail uses flock() in
accessing the /usr/lib/aliases database I am told). Now it is
possible to set up the sun network to allow root access over NFS,
but it is undocumented and not really recommended. SUN may document
this for 4.0, but then again, they might not. The way around which
SUN recomends if pressed extremely hard, and which I have
implemented is to disallow *delivery* of mail on any machine but the
one from which /usr/spool/mail is remotely mounted, thus removing
the problems that happen when sendmail is setuid root. Instead, the
configuration files are written to send any local mail to the main
mail server for that mailer domain. The only thing that one need
worry about then is the fact that /bin/mail is a mail reader as well
as a mail deliverer and runs setuid root (sendmail uses it to send
local mail). However, if it is run by a user as a mail reader (I
don't know why anyone would with /usr/ucb/mail around, but users are
strange) it does a setuid(getuid()) and everything is fine. The
users can read their mail with no problem since they are doing it as
themselves.
That's the sketch of the problem; here's a step by step
description (note: This is from memory so if something I say here
doesn't feel right to you, DON'T do it. Ask me what the hell I
mean. Obviously, the same thing goes if I'm being so confusing as
to be indecipherable.) Note that throughout this when I say
/usr/spool/mail I may mean /private/usr/spool/mail depending on how
your ND configuration is set up.
1) First of all, make a copy in your home directory tree (or
somewhere else; just don't edit it in place) of the
sendmail.cf currently being run on all of the nodes in your
mail domain aside from the aside from the mail server.
Edit it to send local mail to the server (This is fairly
simple; whereever the mailer to use is specified as #local,
you substitute #ether). Following is the section of my
sendmail.subsidary.cf file which I modified. The second
line was commented out and replaced by the fourth line.
Note that the user (specified by $:) includes the host name
of the mail server; this is because when sendmail receives
a mail message from TCP/IP addressed to a user without a
hostname by default it adds the hostname of the *sender*,
which can cause real problems because the mail server then
forwards it straight back to that node and they have a
quick tennis volley before the mail gets dropped on the
floor. In the following fragment $M is the TCP/IP mailer and
$R is the name of the mail server.
# everything else is a local name
#R$+ $#local $:$1 local names
#However, we are now forwarding all local mail to the mailhost
#@$M put in to force keeping it there rather than sending it back.
R$+ $#$M $@$R $:$1<@$R>
Test this mod with sendmail in address rewrite test mode
very hard before you install it!!! Make sure it does
what you want it to do!
2) A friend of mine makes a modification (as above) to the
server's sendmail.cf also to catch any mail headed for the
clients and deliver it on the server (establish a class
with all client names in it and rewrite stuff addressed to
the client to deliver locally). I don't bother; I've got
cycles to burn (the mail takes two extra hops if you don't
do this; to the client and back to the server) and I don't
want to maintain Yet Another Network Database inside or
around the server sendmail.cf.
3) Make sure your mail system on your mail domain is going to
be quiet for the time it'll take you to do the rest of
this. (This may involve locking incoming uucp and TCP/IP
mail and keeping users off the machines or some
form/combination of this).
3) Arrange to copy all users mail spool files in all of the
various /usr/spool/mail directories on all of the various
machines on the network over to your mail server. Make
sure you get the protections and ownerships right when they
get there (protection 600, owner the individual user, group
their login group).
4) Delete the original copies of the spool files on all the
machines which aren't mail servers (I'd recommend you
postpone this step for a few days; it'll make it easier to
go back to your old way of doing things).
5) Setup the remote mount of /usr/spool/mail in all of the
clients /etc/fstabs (rw, soft). Note that you want to
specify the actual directories here, not the symbolic
links, so that if you are mounting from an ND server to an
ND client, you go from /private/usr/spool/mail to
/private/usr/spool/mail. The reason I suggest soft is that
I believe (I haven't tried this and I probably should) that
if the mail server is down an attempt to read mail on the
clients will fail rather than hang (either with the true
NFS error message, or with a no such file or directory
error).
6) Do those remote mounts.
7) Copy the new version of your client (and possibly server)
sendmail.cf files into place on all client machines. (Make
backups of your old config files). If you use frozen
configuration files (sendmail.bz or something), recreate
them from your new ascii files. Kill and restart all
sendmail demons on all machines.
8) Edit your network wide alias database to comment out all of
the aliases you have for each individual user. Make sure
to propagate it over yellow pages. If you don't do this
right, you'll get the tennis syndrome again.
8) Test the fucker. (PMF) Suggested tests: Local mail sent on
server, local mail sent on client, mail from client to
server, mail from server to client, mail from one client to
another, incoming uucp mail ('mail
uucplinkedhost!yourhost!you'). I found about three bugs
1/2 hr. before I absolutely had to leave and had to decide
whether to go forward or back in my installation. Not
pleasant. (One was forgetting to kill the aliases,
one was forgetting to kill the sendmail demons, and one was
redirecting mail from the clients to just mailhost, user
instead of just mailhost, user@mailhost.) Leave some time
for this step and make sure you understand the what and the
why of everything you've done up above.
9) Take off whatever locks you had on mail.
10) You're done; have a beer.
Like I say, if you do want to try this and have any questions,
send me a note. If you have any comments on my outline, I'd also be
interested in hearing about them. Other than that, you're on your
own. Good luck!
-- Randy Smith
--
Randy Smith @ NCI Supercomputer Facility
c/o PRI, Inc.
PO Box B, Bldng. 430 Phone: (301) 698-5660
Frederick, MD 21701 Uucp: ...!seismo!elsie!ncifcrf!randy
------------------------------
Date: Sat, 27 Jun 87 13:26:31 PDT
From: van@lbl-csam.arpa (Van Jacobson)
Subject: newer (bug fixed) 4.3bsd tcp for Sun OS 3.3 available
Bill Nowicki of Sun kindly sent me a long list of bug fixes for our
Sun version of the 4.3bsd tcp code. I think I've incorporated all
his fixes in a new version. At the same time, Mike Karels of Berkeley
fixed four or five minor bugs in the 4.3 code. I've incorporated
those fixes as well.
Also, you may have noticed that the retransmit timer code was almost
completely broken in the previous version. We have been using the
new timer algorithm I described on the tcp-ip list a few weeks ago.
Although the new algorithm has been working well in several weeks
of tests at LBL, I didn't want to pass out experimental code. I
tried to back-fit the original timer code and blew it. It looks
like the new timer algorithm is about to go into 4.3bsd so we've
left it in the new version of the Sun code.
The new code is compressed tarchive 4.3tcp4sun3.3.tar.Z available
via anonymous ftp from lbl-rtsg.arpa. Note that this code is for
Sun OS 3.3. As Bill Nowicki has pointed out, you *DON'T want to
USE IT WITH Sun OS 3.4*: 3.4 already contains the 4.3bsd tcp code
and, since 3.4 has most of the 4.3 icmp fixes as well, several
features that we've ifdef'd out are enabled in Sun's 3.4.
- Van
------------------------------
Date: Thu, 25 Jun 87 11:23:30 edt
From: white%cs.unc.edu@relay.cs.net (Brian T. White)
Subject: Breaking into Suns
We at the University of North Carolina Computer Science Department
recently found that an intruder had gotten onto our systems. He did
this by remotely logging in to several of our servers as sysdiag,
selecting the first option to the sysdiag menu, and obtaining a
root shell. Using this shell, he edited /etc/passwd, giving himself
the login name "intres" (short for "interested") with a uid of 0.
Initially, he did not put in a password for intres, so we had an
unpassworded root available to anyone who happened to look at
/etc/passwd and note the significance of the intres entry.
Fortunately, no damage was done (that we know of). We were able
to determine the intruder's identity, and we notified appropriate
authorities.
The source of the problem is as follows: the Sun setup tapes come
with a standard version of /etc/passwd which contains an unpassworded
login line for sysdiag:
sysdiag::0:1:System Diagnostic:/stand/sysdiag:/stand/sysdiag/sysdiag
The reason for having this line is to allow Sun support personnel to
run /stand/sysdiag/sysdiag without having to know a password.
To prevent intrusions like the one above, one should either remove the
sysdiag line or edit it to:
sysdiag:*:0:1:System Diagnostic:/stand/sysdiag:/stand/sysdiag/sysdiag
Then, to run sysdiag, you can come up single-user and edit out the
asterisk. Alternatively, you can replace the asterisk with the
encrypted version of a known password, so that sysdiag will have to
present a password to get on your system. You will then have to
tell any Sun support personnel the sysdiag password before they can
run the program.
I heartily recommend modifying the sysdiag line in the standard version
of /etc/passwd to make it impossible for any unauthorized people to use
sysdiag to get root privileges on your system.
Brian White
------------------------------
Date: Thu, 25 Jun 87 12:42:43 PDT
From: sklower@renoir.berkeley.edu (Keith Sklower)
Subject: sun/vax restore under 3.2
It is possible to take the 4.3 source to restore, change only the
Makefile, include some additional files from 4.3, compile the
resulting program on a sun under 3.2, and have it restore from
sun or vax tapes. Code was put into the vax version to deal
with the inverse problem -- restore sun or CCI tapes on vaxen.
Here is the diff to the Makefile:
9c9
< CFLAGS= -O
---
> CFLAGS= -O -I.
11c11,12
< OBJS= main.o interactive.o restore.o dirs.o symtab.o utilities.o
---
> OBJS= main.o interactive.o restore.o dirs.o symtab.o utilities.o \
> opendir.o telldir.o seekdir.o readdir.o
Copy 4.3:/usr/src/lib/libc/gen/{open,tell,seek,read}dir.c to ``.''
Make a subdirectory ``sys''. Copy 4.3:/usr/include/sys/dir.h to sys.
Make a file sys/inode.h containing the following 3 lines:
#include "/usr/include/sys/time.h"
#include "/usr/include/sys/vnode.h"
#include "/usr/include/ufs/inode.h"
Symbolically link the following to sys: /usr/include/ufs/{fs,fsdir}.h
There is a bug which prevents interactive mode from working:
% diff interactive.c{,.org}
401d400
< struct entry *ep;
407,408c406
< ep = lookupname(arg);
< single.fnum = ep ? ep->e_ino : 0;
---
> single.fnum = lookupname(arg)->e_ino;
However, all the other functions of restore seem to work just fine.
------------------------------
Date: Thu, 2 Jul 87 09:34:20 PDT
From: marleen@sun.com (Marleen Martin McDaniel)
Subject: press release - SUN RE-PRICES DOS CO-PROCESSOR FOR TECHNICAL PC MARKET
SUN RE-PRICES DOS CO-PROCESSOR FOR TECHNICAL PC MARKET
BILLERICA, MA -- July 1, 1987 -- Sun Microsystems today underscored its
commitment to attract the technical PC user by lowering the price of
the SunIPC, Sun's Integrated Personal Computer, and Ethernet access
software from $2,990 to $1,990. The new price of the SunIPC makes the
combination of DOS and UNIX on a Sun workstation even more
attractive to the emerging technical PC marketplace. It further
demonstrates Sun's commitment to provide a leadership DOS compatibility
solution on its workstations.
The SunIPC is a co-processor board and software that run DOS
applications in a window on a Sun workstation. It allows Sun
workstation users to operate their technical applications and still
have access to the breadth of PC productivity software. It also
provides a natural bridge for those users moving from PCs to technical
workstations. Sun workstations run the SunOS operating system, a
converged version of UNIX System V and 4.2BSD UNIX.
"Reducing the SunIPC price is part of a strategic thrust to expand our
business into the technical PC market," said Barry James Folsom, vice
president and general manager of Sun's East Coast Division. "It
emphasizes how important an integrated UNIX/DOS solution is for the
low-end, technical workstation user. With the SunIPC, users can move
up from a PC to a powerful Sun workstation and take their DOS
applications with them. The SunIPC, combined with Sun's PC-NFS
networking software, which allows users to connect existing PCs to Sun
workstations, is the strongest PC compatibility offering in the
industry."
The SunIPC is a full PC/AT-compatible personal computer on a VME option
board for a Sun workstation or server. The SunIPC allows a DOS window
with full PC graphics capabilities to be brought up on a Sun
workstation for DOS applications. The SunIPC uses network resources
such as disks and printers for DOS applications, and provides utilities
for transporting data between DOS and UNIX applications.
The base-level SunIPC configuration now includes Ethernet access, which
allows any workstation on the network to access and use any SunIPC
installed on the network, turning the SunIPC into a flexible
network-shared resource. A SunIPC can be directly installed in a Sun
workstation that has VME slots, or several SunIPCs can be installed in
a Sun file server, and then used over Ethernet by less expensive
diskless workstations. Sun is the only workstation vendor to offer
this capability.
The SunIPC uses the PC-NFS networking software for file access,
which makes it fully compatible with heterogeneous Network File System
(NFS) networks that may contain any combination of Sun
workstations, PCs and PC-compatibles using PC-NFS, and
computers/servers from any of more than 100 institutions supporting
NFS.
The SunIPC and Ethernet access software are available immediately for
$1,990 (U.S. list). Volume discounts are available.
Additional information will be sent to Sales and Marketing shortly.
Product marketing contact: Andy Nilssen, East Coast Division (617) 671-0360
Press contact: Lorrie Duval (415) 691-7533
------------------------------
Date: Thu, 2 Jul 87 09:33:27 PDT
From: marleen@sun.com (Marleen Martin McDaniel)
Subject: press release - SUN AND SCHLUMBERGER JOIN IN AI VENTURES
SUN AND SCHLUMBERGER JOIN IN AI VENTURES
Companies Form Technical Partnership for AI Development Schlumberger
Selects Sun Workstations for Expert System Development
MOUNTAIN VIEW, CA -- July 1, 1987 -- Sun Microsystems and Schlumberger
Computer-Aided Systems announced today the signing of a joint
technology agreement under which the two companies will exchange
artificial intelligence software technology.
Sun also announced that Schlumberger has placed a new system order for
the development of expert systems. The order is part of an existing
volume purchase agreement signed by the two companies in 1985.
Under the joint technology agreement, Sun and Schlumberger will
cooperate in the development of artificial intelligence software, and
will move the resulting technology to Sun's general-purpose
workstations for inclusion in future Sun symbolic computing and AI
products. Schlumberger also expects to incorporate some of the
resulting technology in future products.
The agreement includes Sun's licensing of object-oriented programming
and artificial intelligence technology tools originally developed by
Schlumberger research organizations for dedicated-AI workstations.
"These agreements signal a strong relationship between Sun and
Schlumberger in the common pursuit of artificial intelligence
technology," said Jim Davis, director of marketing for Sun's Software
Products Division. "Schlumberger's reputation as a leading AI
developer is strong evidence that Sun's general-purpose workstations,
servers, and networking and operating system software are ideal for AI
development and delivery."
Reid Smith, program manager, knowledge-based computer-aided
engineering, at Schlumberger Palo Alto Research, said, "Schlumberger
has been developing its expertise in AI since 1978 using its own tools,
developed for dedicated-AI workstations. General-purpose workstation
technology offers the potential for improvements in AI system
development, and we believe Sun is well-suited to meet our development
needs. Both companies agree on the importance of the AI marketplace,
and both are devoting substantial resources to develop technology and
capitalize on market opportunities."
Other Schlumberger organizations will also use Sun-3 workstations with
the Sun Common Lisp programming language as expert system development
platforms. Schlumberger, whose selection of Sun workstations signals
its commitment to the UNIX operating system, is currently using Sun
workstations for a variety of applications, including computer-aided
design and engineering, automated testing, scientific research, and
technical publishing.
The Wireline, Seismic & Testing Group in North America is evaluating
4-MIPS Sun-3/260 color workstations, servers, and Sun Common Lisp as
expert system development platforms for interpretation engineering.
This expert system will help geologists search for oil.
Schlumberger, Ltd., is a multinational, high-technology company with
businesses in oilfield services, measurement and controls, and
computer-aided technology. The Computer-Aided Systems Group of
Schlumberger offers a broad array of products, including computer-aided
engineering (CAE) systems, automatic test equipment (ATE), computer
graphics, and a full range of pen and electro-static plotters.
Sun's AI portfolio of expert system toolkits, languages, and
programming tools currently numbers more than 40 products from such
companies as Inference Corp., IntelliCorp, Teknowledge, the Carnegie
Group, Reasoning Systems, and Natural Language Incorporated. Sales of
Sun products for artificial intelligence applications accounted for
about 6% of Sun's revenues of $348.6 million in the first three
quarters of fiscal 1987, ended March 27, 1987.
Press contact: Sun Microsystems Press Relations Lorrie Duval (415) 691-7533
Schlumberger Computer-Aided Systems Ronnie Barnes or Gary Green (408) 720-7740
------------------------------
Date: 25 Jun 87 17:16:42 GMT
From: stc-auts!kak@seismo.css.gov (Kris Kugel)
Subject: using low-resolution printers?
Well, we have Okidata 192's comming out of our ears. These have
a basic resolution of 72 dots/inch, possibly some way of getting
denser images, possibly some way of increasing the blackness of
the printed dots.
I'm trying to figure out ways of printing out graphics images,
say, nxn bitmaps, or plot(5) output, to print images generated
on our Sun system or my PC6300+. If I've gotta write utilities
for this, I need more basic knowledge on the theory of scaling,
(shrinking/expanding images & translating resolutions) etc.
I don't have any prior background in graphics, and this is the
first time I'd be playing with graphics applications if I attempt
to use the Oki's for graphics.
SO, first, the quick and dirty fix question: Does anyone know
what existing things I can use to:
map an image to another image (scaling, altering resolution)
filter plot output for an okidata
print sun pixrects on an okidata
And, second, if these things don't exist, what do I need to know to
write such things, and how difficult are they to write?
Yours for theory and practice,
Kris Kugel
{hao,nbires,ihnp4}!stcvax!stc-auts!kak
{hao,nbires,wldrdg}!hicntry!kak
------------------------------
Date: Sat, 27 Jun 87 12:01:06 PST
From: myers@sdcsvax.ucsd.edu (Margaret Myers)
Subject: Ada compilers for the Sun ?
I would like information on any Ada compilers available for
Sun (3) systems. If you know of please give me some details
via e-mail.
Thanks in advance,
Margaret
------------------------------
Date: Sat, 27 Jun 87 17:35:23 edt
From: allegra!mp@seismo.css.gov (Mark Plotnick)
Subject: how many sun-2 clients per sun-3 fileserver?
Because of the relatively long MTTR of Sun-2 fileservers (up to 2
months), we're thinking of taking the ones that aren't running 2.0 or
1.4, tossing everything but the disks, and replacing them with
Sun-3/180's or 280's. Since I'd like to reduce machine-room floor
space as well, I would like to know if a Sun-3 fileserver can handle
more clients than a Sun-2 fileserver. Most of our Sun-2 clients are 2
meg, all are diskless, have 3com ethernet boards, and the owners who
run 3.0 and beyond typically use nothing more than perfmon, clocktool,
lockscreen, and multiple shelltools running rlogin to Vaxes or Sun-3's.
The owners don't expect much in the way of performance when running
large programs.
We currently put 10 to 15 clients on each 4-meg Sun-2/150 or /170
fileserver, with 2 xy450 or xy451 controllers each driving 1 eagle
disk. I'm hoping for a 2-to-1 compression, and I'm aware that the nd
driver will need to be modified to support more than 20 clients.
Mark Plotnick
allegra!mp
------------------------------
Date: Mon, 29 Jun 87 16:13:38 EDT
From: johncw%csri.toronto.edu@relay.cs.net (Johnny Chee-Wah)
Subject: maintaining passwd file?
How do you maintain password file in a heterogeneous environment for a
couple thousand users. I am interested in finding out the approach that
other sites have taken. I remember someone mentioned something at the BOF
in Pheonix???
Scenerio
- mixture of sun (3.2) and other machines (mainly vaxes) running a version
of 4.x BSD UNIX.
- there may be some users that are not allowed to log in to some machines.
- there is lots of accounts that are created and deleted at a time.
- users may not have same home directories?
Some questions that I could think of:
a) login name selections?
b) password creation and deletion?
c) If using YP on the suns, are there any problems with yp? :-)
d) How does one get his/her password change? Does it get changed on
all machines?
--
Johnny Chee-Wah johncw@csri.toronto.edu (CSNet,UUCP,Bitnet)
Computer Systems Research Institute
University of Toronto johncw@csri.toronto.cdn (EAN)
Canada M5S 1A4 {seismo,watmath}!csri.toronto.edu!johncw
------------------------------
Date: Mon, 29 Jun 87 13:42:25
From: mcvax!swivax!anjo@seismo.css.gov (Anjo Anjewierden)
Subject: File-descriptors in 3.x ?
Does anybody know how many file-descriptors there are in Sun OS 3.3/3.4.
The 30 file-descriptors per process is a real problem when developing
large systems under SunView (3.2) and we would like to know whether new
releases will alleviate this problem.
Anjo Anjewierden
University of Amsterdam
anjo@swivax.uucp
------------------------------
Date: 30 Jun 87 10:40:37 GMT
From: prlb2!kulcs!alain@seismo.css.gov (Alain Callebaut)
Subject: Time measurement on UNIX?
Some people at the Department of Psychology of our university work
on a project around visual perception. They would like to use a SUN 3/50
to generate images and to display them for a given time interval.
The image generation and presentation could be done by using memory
pixrects. Control of the display duration however, is a problem : the
required durations are typically around some 100 ms. I did some tests, using
an interval timer of 100 ms, in a loop of 100 times. Using getrusage()
the durations had an average under estimation of about 1.5 %.
This is too high ! So the question is : is there a more accurate time control
facility than interval timers ? Would it help a lot if the machine was run
in single user mode ?
All responses (preferably via e-mail) are appreciated.
Alain Callebaut
Dept. of Computer Science UUCP mcvax!prlb2!kulcs!alain
K. U. Leuven Belgium
------------------------------
Date: 30 Jun 87 22:59:42 GMT
From: elijah!tarsa@seismo.css.gov (Greg Tarsa)
Subject: Multitech Modem help?
I recently bought a MultiTech Modem MultiModem HC at an auction. No
documentation. I will be ordering a manual for it as soon as I can,
but in the meantime, is there anyone who might be able to tell me
how the internal switches should be set for operations in a SUN 2/120?
It may be broken, but I can't know until I know I have it configured
correctly.
Direct mail to {decuac,decvax}!elijah!tarsa if possible. I could use help
as soon as I can get it.
Thanks,
Greg
--
Tarsa Software Consulting
33 Seabee Street
Bedford, NH 03102
(603)668-8349 {decuac,decvax}!elijah!tarsa
------------------------------
Date: Tue 30 Jun 87 15:42:32
From: MANSFIEL%EMBL.BITNET@wiscvm.wisc.edu (Naill Mansfield)
Subject: extending video cable on Sun-3/260 HM - problems?
We have extended the cable to the hi-res monitor on our 3/260 to about 11
metres. (To be precise, we made up a new cable that long; our local Sun
office said they could not supply a long cable).
It works but isn't perfect: some characters show up a bit washed out, and in
Tektool, diagonal lines are almost invisible and vertical ones are very faint.
Has anyone else done a successful extension? How?
Thanks in advance,
Niall
------------------------------
Date: Tue, 23 Jun 87 13:33:21 EDT
From: ulysses!heh@ucbvax.berkeley.edu (Harlan Husmann)
Subject: CSC Wren IIIs?
I'd like to hear from anyone who has used CDC Wren IIIs on Sun as
local storage. The specific disk I'm interested in is a Wren III,
182MB, ESDI. I have the following questions but I'd like to hear from
anyone about their experiences:
1. Will the Wren III work with Sun's software? In particular, can
I format it on the Sun?
2. If I can't format it, how hard is it to change their software
(we have a source lic.) and what needs to be changed?
3. Are their other CDC SCSIs that work in a Sun "as shipped"?
Any help and discussion on this topic will be greatly appreciated.
Thanks.
Harlan Husmann
{ucbvax,vax135,ihnp4}!ulysses!heh
(201)582-4834 (collect is fine)
------------------------------
End of SUN-Spots Digest
***********************