Sun-Spots-Request@Rice.edu (William LeFebvre) (09/30/88)
SUN-SPOTS DIGEST Wednesday, 28 September 1988 Volume 6 : Issue 242
Today's Topics:
Re: .cshrc vs .login (2)
Re: Suntools shutting down incorrectly
Re: lots of users on a Sun
Re: Information on TAAC board
Re: Spurious "Your have new mail." msgs
Resolved: Spurious "You have new mail." msgs
Sun Users Group tape
Pascal Compiler problems with SUN 4 under 3.4 UNIX
Parity memory?
Send contributions to: sun-spots@rice.edu
Send subscription add/delete requests to: sun-spots-request@rice.edu
Bitnet readers can subscribe directly with the CMS command:
TELL LISTSERV AT RICE SUBSCRIBE SUNSPOTS My Full Name
Recent backissues are available via anonymous FTP from "titan.rice.edu".
For volume X, issue Y, "get sun-spots/vXnY". They are also accessible
through the archive server: mail the request "send sun-spots vXnY" to
"archive-server@rice.edu" or mail the word "help" to the same address
for more information.
----------------------------------------------------------------------
Date: Mon, 26 Sep 88 10:04:20 -0400
From: malis@cc5.bbn.com
Subject: Re: .cshrc vs .login (1)
>Could someone explain (or point me to a document that explains) the
>rationale for what should go in a .cshrc file vs. a .login file?
Chip,
Your .login should contain terminal settings (tset and stty) and all
enviroment settings (setenv), plus anything else you want to execute at
login time only (uptime, etc.).
Your .cshrc should contain everything that you need for every csh you
start. This includes setting local variables (path, cdpatch, history,
umask, prompt, etc.), declaring aliases, and anything else you want
executed when you start a shell.
Andy
------------------------------
Date: Mon, 26 Sep 88 10:10:56 PDT
From: vsi1!lmb@ames.arc.nasa.gov (Larry Blair)
Subject: Re: .cshrc vs .login (2)
There are two reasons for having a .login file in addition to the .cshrc
file. One is to reduce the overhead involved in starting subshells, and
the other is to allow certain commands to be executed only by the login
shell.
In general, all global variables ("setenv") should be set in the .login,
since these values will be passed to all child processes. Local csh
variables ("set") and aliases must be set in the .cshrc, since these are
not passed down.
Since the .cshrc is "sourced" before the .login, it is possible to have
different values for variables in the login shell than in subshells. An
example of this is having a different prompt for the login shell. Many
people "set ignoreeof" in their .login, so that they can't <cntrl>-d out
of their session, but can <cntrl>-d out of subshells. Another popular
.login only command is "tset".
By using the "if ( $?prompt )" syntax in your .cshrc, it is possible to
differentiate initialization of interactive shells from non-interactive
subshells, further reducing the startup overhead of the latter.
--
Larry Blair ames!vsi1!lmb lmb%vsi1@ames.arc.nasa.gov
------------------------------
Date: Mon, 26 Sep 88 08:18:58 MDT
From: topologix!skywise!devin@boulder.colorado.edu (Devin Hooker)
Subject: Re: Suntools shutting down incorrectly
ufnmr!ufnmr_1!gareth@bikini.cis.ufl.edu (Gareth J. Barker) writes:
>
> We have a commercially written application which runs under Suntools and
> uses multiple windows, etc. Recently when the application exited
> (normally) it left an 'image' of all it's open windows on the screen.
...
> Question:
> Is this likely to have been caused by a bug in our application program, a
> glitch in Suntools, something else?
As a suntools programmer I have found that if a window is destroyed
incorrectly, this sort of thing will happen when you exit the program.
This could probably be called a bug in Sunview, but it can be worked
around - so the application program has a bug (incorrect workaround, I
guess...)
Devin Hooker
Software Engineer
4860 Ward Rd.
Denver, Co. 80033
(303) 421-7700
Cleanliness is next to impossible.
------------------------------
Date: Sun, 25 Sep 88 09:47:50 edt
From: Barry Shein <encore!xenna!bzs@talcott.harvard.edu>
Subject: Re: lots of users on a Sun
>4. Barry Shein at Boston uses Suns as big student timesharing machines,
>and reports no problems.
>
>-mark
Correction, we used Suns for faculty and grad type machines and Encores
for "big student timesharing machines" (as well as others, Vaxen, IBM370,
etc.)
That's important, the Suns worked very well in that environment where one
tends to get a lot of folks logged in all day but intermittant activity
from most as phones ring and other distractions come and go (ie. people
who tend to work from their offices.)
For example, 3 Sun3/180s each with 16MB and 2 Eagles handled most of the
Math and CS faculty very nicely with typically 16 users logged into each
(from dumb terminals) and several diskless nodes serving off them. That's
more or less the configuration of BU-CS today (BU-CS itself is now a 280
with an extra CDC disk and handles all the diskless nodes.) All
directories are cross-mounted on all Suns so it doesn't matter to a user
which one s/he logs into. We used similar set-ups in Chemistry, Biology
and Information Technology (and other places) with similar success
although the CS/MATH cluster is probably the closest to what is being
referred to above.
The undergraduate teaching machines in CS and Engineering, however, are
Encores. Undergraduates have a different behavior pattern that I think
would be a little harder to serve off of Suns as time-sharers in that
environment (eg. they work from public clusters so they tend to get on and
edit/compile/debug furiously, I think with 16+ users like that on a 3/180
you'd tend to see the context switching knees rather quickly.)
It all depends on what you perceive your community as needing. One
important reason to purchase Sun "time-sharers" was to be able to provide
an easy migration path for faculty and grads to diskless and/or dataless
Sun workstations (that is, the servers were just there, plug and play)
which worked very nicely. I suppose with the exit of ND that's becoming a
more open question (so to speak.)
-Barry Shein, ||Encore||
------------------------------
Date: Sun, 25 Sep 88 21:16:32 EDT
From: "Ian S. Small" <ian@dgp.toronto.edu>
Subject: Re: Information on TAAC board
As of SIGGraph 88, there were at least 50 (a conservative number) TAAC-1's
out in the field; I know first-hand of TAACs at at least four different
sites. Concerning the shipping date for production versions, I find it
hard to believe that Sun is not shipping production versions yet. The
last I heard, production had already switched from Raleigh to Mountain
View, and that things were rolling along. The recent mail I have received
from Raleigh concerning the replacement of our beta-board set with a
production release seemed to indicate that I could expect this to happen
in the next month or two, leading me to believe that production is already
fully tooled up, since our board set was not due to be replaced until
approximately three months after full production started.
As far as the TAAC-1 is concerned, we have had beta versions of the board
set for about seven months now (I believe our current beta version is what
constitutes the production version, as far as I know). In terms of the
time to delivery, we placed our order with Trancept Systems shortly after
NCGA '87, BEFORE they were bought our by Sun, so have no helpful knowledge
or experience to contribute on that front.
As a lab involved in pure research in computer graphics, interaction and
music, we have found the TAAC-1 to be an excellent product; our work
causes us to stress the board set and its accompanying software in ways it
was never really meant to work, and we are frequently pleasantly surprised
by the things which it can do. The generality of the TAAC-1's
architecture allows us to do things in the way in which we want to do
them, rather than restricting us to using software or techniques specified
by the manufacturer. The speed of the system is remarkable: on the right
kind of application, tune the code correctly and you can blow a Sun-4 (or
a MIPS box) right out the door, as some (independently conducted)
benchmarks given at a SIGGraph 88 panel session have showed convincingly.
To be fair, programming the board can occasionally be frustrating,
especially when you are trying to squeeze some more ooomph out of it and
something peculiar starts happening because you've messed up the bitslice
timing somewhere along the line, but when was the last time you used a
very specialized high performance machine without some occasional
frustration? If you're content with medium-level performance, you can
stay within the bounds of reason in C, and escape most of the arcane
problems which make the board fun to use. As a research tool, we are
sufficiently pleased with the product to try to rustle up funding to buy a
second TAAC-1 system. As far as people building large image processing or
image synthesis applications on the TAAC-1, I would suggest you contact
Sun Raleigh directly, who will be able to provide you with more
information.
As impressive as the hardware and software are, however, even more so are
the people producing and supporting the product in Raleigh, North
Carolina. At a time when our site in general is somewhat unhappy with Sun
and Sun's new attitudes (witness the Ciprico business), we have come
across a segment of Sun which has yet to disappoint us; they are
responsive, helpful, and everything else you could ask for from a vendor.
Questions and/or bugs are handled quickly, suggestions considered and even
adopted sometimes (when was the last time you saw that from Sun?), and our
occasional rantings and ravings waited out patiently, and acted on
immediately. The last time I complained about the impenetrable nature of
a set of procedure calls supported by the system, they told me that the
problems had been fixed in the new software release, which they could send
me immediately, but that the new software release required some
board-level mods, and that shipping the new board could take a bit longer.
I had the new software and manuals overnight, and the new board set the
day after that. Anyone with any experience of getting computer materials
(hardware or software) over the border from the US to Canada knows that
this is no mean feat, and requires a lot of attention on the part of the
shipper.
I believe that these general attitudes (both regarding the product and the
people) are shared by many TAAC-1 users; most of the problems that other
people have encountered with the product which I have heard of stem from
other parts of the Sun empire being involved.
Ian Small
Lab Manager
Dynamic Graphics Project, Computer Systems Research Institute
University of Toronto
(416) 978-5473
------------------------------
Date: Mon, 26 Sep 88 07:38:08 EDT
From: fritzson@prc.unisys.com
Subject: Re: Spurious "Your have new mail." msgs
>Several newer users to our system (Sun 3/160 + 19 3/50 + 1 3/60) are
>seeing (or have seen) notification of new mail without actually receiving
>any mail. As far as we can tell, they are not losing any mail; so, it
>seems to be only an annoyance. Older users on the system don't appear to
>have this problem.
This is so obvious that I hate to suggest it, but I have seen several
people pass right by it.
Often new users copy their ".cshrc" files from older users and then
customize them. If they don't put their name in
set mail = (30 /usr/spool/mail/<name>)
they will receive notification when the old user receives mail. But of
course, they won't have any new mail themselves. Depending on how much
mail the users involved actually receive it can look just like "spurious
new mail messages".
-Rich Fritzson
ARPA: fritzson@prc.unisys.com
UUCP: {sdcrdcf,psuvax1,cbmvax}!burdvax!fritzson
------------------------------
Date: Mon, 26 Sep 88 15:41:42 EDT
From: csrobe@work6.icase.edu (Charles S. [Chip] Roberson)
Subject: Resolved: Spurious "You have new mail." msgs
Thanks to Liz Allen-Mitchell and Rich Fritzson who pointed me to the
answer. It appears that our adduser script (which gives new users .login
and .cshrc files) had a small bug in it. New users were given .login
files with the following line in it:
set mail=(/usr/spool/mail/$1)
which to most users didn't appear obviously wrong, though perhaps a bit
suspicious. The net result was that these users were being notfied
anytime /usr/spool/mail was modified (i.e. whenever new mail arrived at
their machine).
The fix was to change the $1 to $USER (or the user's userid). Apparently,
there is another situation that might cause this problem, but it is seems
quite rare and is so convoluted that I don't think I could explain it
properly.
cheers,
-c
------------------------------
Date: Mon, 26 Sep 88 08:56:35 PDT
From: chaos%gojira.Berkeley.EDU@jade.berkeley.edu
Subject: Sun Users Group tape
Are the items on the SUG tapes publically available?
In particular I would like to get the
>The 1987 Sun Users Group tape contains a program to convert Macintosh
> fonts to Sun fonts (look in sunview/suntroff/LaserWriterFonts on the
> tape).
code recently mentioned.
Jim Crutchfield
Physics, UCB
(415) 642-1287
------------------------------
Date: Thu, 15 Sep 88 17:49 N
From: <EAJUAN@EBRUPC51.BITNET>
Subject: Pascal Compiler problems with SUN 4 under 3.4 UNIX
I would greatly appreciate that somebody could answer some of the
following questions. I do not know how good is Sun service on other
countries, but here in Spain it is DISASTROUS and they are of no help at
all to solve these stupid problems.
First question :
--------------
Here there is a trace of a work session with a SUN 4-260C with
the 3.4 version of UNIX :
aries{juan}37: cat error.p
program error (input,output);
type dummy = record
x : real
end;
var ind : integer;
vec : array [0..5] of dummy;
begin
ind := 2;
vec[ind].x := 0.0; (* <--- here is line 12 *)
end.
aries{juan}38: pc error.p
error.p, line 12: compiler error: expression causes compiler loop:
try simplifying
Do somebody know why Pascal compiler crashes ? This program is
correctly compiled on VMS as well as on a SUN 3-260HR under
the 3.2 version of UNIX.
Second question :
---------------
Do somebody know why when compiling the program illustrating
the use of SunCore from Fortran (the one drawing a martini
glass) on a SUN 4-260C with 3.4 UNIX the compiler crashes
and I get the following error message :
ERROR : pixwindd() is used as a variable
The same program is correctly compiled and executed on a
SUN 3/260HR with the 3.2 version of UNIX. The C version of
this program is correctly compiled and executed on our SUN 4-260C.
Thanks to everybody.
Joan Ilari (eajuan%ebrupc51@cunyvm.cuny.edu)
P.D. NEXT TIME I WILL PROGRAM ONLY IN "C"
------------------------------
Date: Mon, 26 Sep 88 10:47 EDT
From: "Eugene C. Libardi, Jr." <AIDEL%UMAECS.BITNET@mitvma.mit.edu>
Subject: Parity memory?
I have heard many bits and pieces about Parity memory for the Sun 3/60.
Most of it has been good. We have been using Clearpoint for 2 years now
and have no complaints. We haven't used their simms yet but we have 4 and
8 Meg boards in all of our 3/140s and 3/110s. They ship within a week,
guarantee their boards for life, and will get you a new board if you need
one in 24 hours. We did have one board go, but had another the following
day. Other than that - no problems.
We are about to buy additional memory for our 3/60s and want to get the
most bang for the buck without giving up reliability and support. Does
anybody have any bad stories to tell about Parity or Clearpoint (or any
other 3rd party memory vendor for that matter)? Good stories? Horror
stories? Any pointers to other 3rd party vendors we would be interested
in? Current prices would be nice if possible.
Also, could someone tell me how to get in touch with Parity? All I have so
far is their name!
Thanks.
Please reply directly to me and I'll summarize if there is interest.
- Gene Libardi Internet: aidel@ecs.umass.edu
Mechanical Design Automation Lab or
Mech. Eng. Dept. aidel@umaecs.bitnet
Univ of Mass Bitnet: aidel@umaecs
Amherst, MA 01003 Tel: (413) 545-3599
------------------------------
End of SUN-Spots Digest
***********************