Sun-Spots-Request@rice.EDU (William LeFebvre) (01/15/88)
SUN-SPOTS DIGEST Thursday, 14 January 1988 Volume 6 : Issue 3
Today's Topics:
Re: Spreadsheets for Sun
Solution for disappearing disk labels
Solution to font problems in MonthTool
How to mail between Suns and Lisp machines
Print rasterfiles on HP-devices
stty problem
Address for US Industries?
Small SCSI Disks -- Early Report On Availability (LONG)
----------------------------------------------------------------------
Date: 18 Dec 87 19:44:30 GMT
From: bob@aargh.cis.ohio-state.edu (Bob Sutterfield)
Subject: Re: Spreadsheets for Sun
NeWS comes with a nice interface to sc, the spreadsheet calculator that
went around the net a while back. It takes advantage of the mouse,
windows, etc. in a fairly nice way. I have no idea how "user compatible"
it is with the commercially-available spreadsheets, though, nor how it
compares function-by-function with them for power, flexibility, etc.,
since I have never used a commercial spreadsheet.
Bob Sutterfield, Department of Computer and Information Science
The Ohio State University; 2036 Neil Ave. Columbus OH USA 43210-1277
bob@ohio-state.{arpa,csnet} or ...!cbosgd!osu-cis!bob
soon: bob@cis.ohio-state.edu
------------------------------
Date: Fri, 18 Dec 87 08:59:09 EST
From: dcornutt%murphy@gswd-vms.gould.com (Dave Cornutt)
Subject: Solution for disappearing disk labels
The disappearing disk label mystery is solved! The problem was that the
affected disks were configured with a swap partition beginning at cylinder
0. The disk label is stored somewhere in the first eight sectors of
cylinder 0 of each disk, and paging/swapping operations were wiping it
out. It doesn't happen all of the time because the partition is a
secondary swap partition, and whether or not it is used depends on system
load and the size of the primary swap partition.
The reason it's okay to have a file system there is because BSD file
systems set aside the first eight sectors of the first cylinder of the
file system as an area for boot programs. Sun has the primary boot code
in ROM, so they used part of that area for the disk label (you need an
area that you can read without having to know the disk geometry, and the
only area that really qualifies is the first few sectors of cylinder 0
head 0). However, the page and swap code doesn't know about the disk
label, and so if that area gets used, it will overwrite the label. With a
swap partition con- figured at cylinder 0, I was able to trash the label
every time by running sysdiag and selecting the virtual memory test. The
same thing can happen if you use cylinder 0 as part of a raw data
partition (this is actually worse, because when the label is restored, it
will overwrite some of your data). Try setting up a partition at cyl 0,
and dd something into it, and you will trash the label every time. (Note:
I also tried to wipe out the label using the write test in diag, but that
didn't work. I guess diag knows about the label, and restores it
automatically after the test.)
The cure is to either use cylinder 0 as part of a file system, or let it
lay dormant. If you want to start your disk with a swap or raw data
partition, create a one-cylinder "a" parititon at cyl 0, just so you
remember later why it isn't being used, and start your swap or data
partition at cyl 1. Note that it is not necessary to create a file system
on this "a" partition -- just don't swap or write over it.
Just for anyone that didn't know: in case your disk label does get
trashed, it can be easily restored by running diag and doing a "verify"
command. It will tell you that there is no label, and ask you if you want
to search for backup labels. Answer yes, and it will find a backup label
and restore the primary label. For this to work, you must know what type
of disk you have, and if it is a non-supported disk, you must be able to
tell diag about its geometry, so that it can find the backup labels (which
I assume are stored in the bad-block replacement area).
Although my original note specified SCSI disks, this problem is not
confined to any class of disks; it's true of any disk connected to a Sun.
I've gotten reports of people having the same problem with SMD disks which
had swap partitions beginning at cyl 0. (We don't have any SMD disks
configured like this, which made me think the problem was limited to SCSI
disks.) I don't really consider this a bug, since there doesn't appear to
be any other place to put the label, and the problem is so easily worked
around if you know what it is. However, Sun should point this out in the
installation manuals.
Thanks and a tip of the baseball cap to:
Steve D. Miller <brillig.umd.edu!steve>
Mike Pearlman <rice.edu!canuck>
Edward Morgan <space.mit.edu!ehm>
Jeff Kitson <kestrel.ARPA!jeff>
John Foderaro <ucbarpa.Berkeley.EDU!franz!frisky!jkf>
Brad Eltman <Sun.COM!brade>
Dave Cornutt, Gould Computer Systems, Ft. Lauderdale, FL
[Ignore header, mail to these addresses]
UUCP: ...!{sun,pur-ee,brl-bmd,uunet,bcopen,rb-dc1}!gould!dcornutt
or ...!{ucf-cs,allegra,codas,hcx1}!novavax!gould!dcornutt
ARPA: dcornutt@gswd-vms.arpa
"The opinions expressed herein are not necessarily those of my employer,
not necessarily mine, and probably not necessary."
------------------------------
Date: Fri, 18 Dec 87 22:41:49 PST
From: Brent Chapman <capmkt!brent@cogsci.berkeley.edu>
Subject: Solution to font problems in MonthTool
3.4 (I don't know about 3.2, and don't have access to a 3.2 system to test
it) ignores the WIN_FONT parameter in a window_create() call for some damn
dumb reason; the fact that it is ignored, but not the reason, is
documented in the fine print in the back of the SunView Programmer's
Manual.
Anyway, the fix is to do a
window_set(notesDsply, WIN_FONT, notesFont, 0);
after the window_create() call for notesDsply. This works.
-Brent
--
Brent Chapman Capital Market Technology, Inc.
Senior Programmer/Analyst 1995 University Ave., Suite 390
{lll-tis,ucbvax!cogsci}!capmkt!brent Berkeley, CA 94704
capmkt!brent@{lll-tis.arpa,cogsci.berkeley.edu} Phone: 415/540-6400
[[ Thanks also to Steve Schlaifer at jpl.nasa.gov for a similar
suggestion. --wnl ]]
------------------------------
Date: Tue, 22 Dec 87 09:05:21 PST
From: trwrb!smpvax1!sbb@ucbvax.berkeley.edu
Subject: How to mail between Suns and Lisp machines
The problem is that in a normal sendmail.cf file, the TCP mailer is set up
to talk to another UNIX mailer. The SMTP protocol it speaks is slightly
different from the SMTP standard, in that the lines of text that it sends
to the receiver are terminated with LF only, whereas the standard, and
hence the Symbolics, expects CRLF as termination. The trick here is to
make a copy of the mailer description for the Ether mailer and modify it
to specify the proper line termination, by adding "E=\r\n", thus:
Mtcp, P=[IPC], F=msDFMuCX, S=11, R=21, A=IPC $h, E=\r\n
This ensures that lines are terminated with CRLF. The only remaining
trick is to have Ruleset 0 distinguish between mail bound for Lisp
machines and mail for UNIX machines and have Lisp machine mail resolve to
the TCP mailer. This is documented in the Sun Sendmail appendix, but look
for "Eol" instead of just "E" (as I did at first), since the single
character specifications in the mailer definition line are just
abbreviations for the full names.
[[ In my humble opinion, the "slightly different" Unix SMTP "standard" is
wrong, Wrong, WRONG!! RFC 821 clearly states that all commands (and
probably all data lines as well) are to be terminated with a carriage
return and a line feed. This should be considered a bug and Sun should
fix their SMTP handler. Either that or they should stop saying that it is
SMTP. But that's just my humble opinion. --wnl ]]
Many thanks to all who responded to my mail!!!
Steve Byrne ...ucbvax!trwrb!smpvax1!sbb
Inference Corp. (213) 417-7997
5300 W. Century Blvd.
Los Angeles, CA 90045
[[ Thanks to everyone who sent in similar suggestions. --wnl ]]
------------------------------
Date: Mon, 21 Dec 87 09:41:10 +0100
From: mcvax!cogpsi!tom@uunet.uu.net (Tom Vijlbrief)
Subject: Print rasterfiles on HP-devices
I have written a filter which prints Sun rasterfiles on a HP Laserjet or
Quietjet. (The thinkjet should work too).
Perhaps you could place it in your archive.
A manual page is included in the shar file.
==============================================================================
Tom Vijlbrief
TNO Institute for Perception
P.O. Box 23 Phone: +31 34 63 14 44
3769 DE Soesterberg E-mail: cogpsi!tom@mcvax.cwi.nl
The Netherlands uunet!mcvax!cogpsi!tom
==============================================================================
[[ It has been placed in the archives as "sun-source/prraster.shar". It
can be retrieved via anonymous FTP from the host "titan.rice.edu" or via
the archive server with "send sun-source prraster.shar". For more
information about the archive server, send a mail message containing the
word "help" to the address "archive-server@rice.edu". --wnl ]]
------------------------------
Date: 17 Dec 87 02:48:26 GMT
From: sun!sunncal!laic!darin@decwrl.dec.com (Darin Johnson)
Subject: stty problem
I have a user logging in to my Sun from a vt100-type terminal on a VMS
machine (via sunlink-dni).
For some reason, "stty all" shows that the terminal has 48 rows and 84
columns. A tset has been done, and a printenv shows the correct values
for TERMCAP and TERM. I can get the problem fixed with "stty rows 24"
etc. (undocumented in the man pages) Is there any way to have the columns
and rows set correctly without having to do a lot of hand holding for each
user that wants to log in this way?
[[ Setting both values to 0 makes all termcap-based programs use the old
ways to get those values (TERMCAP then /etc/termcap). --wnl ]]
------------------------------
Date: Fri, 18 Dec 1987 14:38:25 LCL
From: Gareth J. Barker <GJBARKER%UFFSC.BITNET@cunyvm.cuny.edu>
Subject: Address for US Industries?
In 'v5n71' Alan Broder mentioned a company called U.S. Industries. Does
anyone have a contact address for them?
Thanks,
Gareth J. Barker,
Dept. Radiology, Phone : (904) 392-3087
College of Medicine,
Box J-374,
JHMHC,
University of Florida,
Gainesville,
FL 32610. Bitnet : GJBARKER@UFFSC
------------------------------
Date: 16 Dec 87 21:20:54 EST (Wed)
From: citi!dwon!lokkur!scs@rutgers.edu (Steve Simmons)
Subject: Small SCSI Disks -- Early Report On Availability (LONG)
From the way my mailbox has begun overflowing recently, there is a hell of
a lot of pent-up demand out there for cheap disks to go onto Sun
workstations (ie, non-server disks). The last month or so I've been
throwing the weight of Schlumberger around (we could buy GM, but who'd
want to?) in a search for cheap SCSI disks. Judging from all the mail I'm
getting the word has out that I'm doing this. I was planning on posting
the relevant details when it all settled, but keeping up with the
questions is driving me nuts. OK, I surrender! I will henceforth post to
sun-spots every few weeks so people will know what's up.
[[ This message was long enough that I considered archiving it and letting
interested people retrieve it themselves. But if Steve's comment about
his mailbox is any indication, this topic has wide enough interest to
justify including the message in a digest. Those of you who are not
interested in this topic can ignore the remainder of the digest---this is
the last message. --wnl ]]
Here's the history of the thing:
We have about 10 3/50s per file server, all in swap state (these suckers
get *used*) that absolutely destroy file server performance. (Our total
network is about 140 Sun nodes, plus a number of VMS/VAXen.) Proposed
solution: put the root space, swap space, and whatever else we can fit
onto tapeless disk boxes on the workstations. Have the file servers do
*nothing* except serve user files (ie, no ND). Under 3.4OS the root
partition plus our particular set of /usr comes to 46Mb. Add 24Mb of
swap/tmp, and 70Mb became our target. After some discussion with
engineers at Sun they agreed we'd probably see significant overall
performance improvements. So the operant question was could we get disks
cheap enough?
[An aside -- our particular needs may not match yours. We have old
3/160s with 800Mb slow CDC disks and Xylogics 450 controllers. To really
speed things up would cost us about $20,000 per server (buy double eagles
and different controllers).]
[Aside #2: How would we format/load/maintain these? Easier than you
think. Get a 2x140Mb shoebox with cartridge tape. Format the second disk
to be an exact image of what you want on the tapeless units, with
hostnames, etc, set up to be nice memorable nonsense names. Yes, that
will waste space on the second disk. BFD. Attach the tapeless disk on
the daisy chain, format and partition. Do disk-to-disk copy to load it.
Run a script that prompts for hostid, inet address, all that stuff, and
sedits the files on the target disk. Takes a long time measured by the
clock, but very little hands-on. Minor software upgrades (3.2 -> 3.3 ->
3.4) across the network late at night. Do it by installing the upgrade
files on the server, then writing a script so each workstation upgrades
from there. Maintainance: keep 2-3 extra units as "hot spares". One goes
down? Walk up with a new hot spare, run the sedit script, and walk away.
Take the bad one back where your tape drive is. All of this comes to a
lot of front-end scriptwriting, then relatively low maintainance -- no
more ongoing work than we do now on our servers/ND partitions.]
In looking through raw hardware costs, I came up with an estimate saying
the "best possible" price for capacity/speed equivalent to the 70Mb Sun
shoebox disk (no tape) was $1200. Our Sun representative blanched. The
hardware engineer was carefully bland. We asked for a special quote for
100 tapeless units from Sun, and didn't get one. So off we went to the
market.
After some investigation, we found *no* vendors who were directly
targeting the low end disks for Sun. Lots of folks are pushing large SCSI
disks -- I believe we saw numbers up to the 280Mb range for SCSI. Not
appropriate: we want *small* disks.
A normal human being (me) would have given up. My boss ordered me not to
("If you can tell me they should cost $1200, you should be able to find
some.") OK, put up or shut up.
There are two tracks I'm pursuing, both of which look promising.
First, we are looking at prepackaged SCSI disks which are intended for
machines other than Sun. Far and away the most fruitful so far are those
targeted for the Macintosh II. All of these use some funky Macconnecter
on the outside, but the manufacturers assure me there are standard 50-pin
ribbon cables inside. When the first units arrive we'll open them up,
change the connecter, and try to format/run them. The POs went out the
door last week, so basic tests should be done by mid-January. Why so
long? We've got other work to do, too! ;-)
Good points to this approach:
1. These suckers are *cheap*. One drive we've ordered is $1300.00
for 80 meg unformatted, the other is $1400.00 for 90 unformatted.
Both these prices are for quantity one retail.
2. These have *very* small footprints -- usually designed to be
exactly the same as a Mac.
3. It's all off the shelf.
Bad points:
1. The vendors thus far have been zero help. They have not answered
questions about transfer rates, sectoring, hard drive manufacturer,
etc, etc. "It's a Mac disk -- what else do you need to know?" A
lot, actually.
2. Once you open it up, change the connecters, and cable it to
something else, forget service and warrantees. Better be ready
to service it yourself, and ghod only knows what's in those boxes.
3. We'll have to put a lot of technition time into changing the
connecters, plus buy the connecters and cables (go price a 50-pin
shielded cable sometime. Whew!)
[An aside: The thought of using these disks on something else besides a
Mac has never occured to those guys. Only one vendor had the wit to ask
if there were a lot of Sun computers in the world. Another said "When did
someone start making Mac clones?" Sigh. ]
Second, we are taking some firm specs directly to disk houses and saying
"How much to make 1/50/100 of X?" In this case X is a 70 Mb (formatted)
Micropolis drive with imbedded SCSI interface, cable, enclosure, power
supply, 50-pin (Sun-style) connecter, daisy-chainable. This has yielded
some wildly varying numbers. One firm quoted $3800.00, another $1900.00.
For the same hardware. Can you guess which one we'll buy an evaluation
unit from?
Good points:
1. We get exactly what we want functionally.
2. We point the vendor into a marketplace where he can sell to lots
of other folks besides us. This will hopefully make him think
kindly of us when he gets rich. :-)
3. We get something where we know *exactly* what every part is,
and get as close as possible to exact Sun compatibility.
Bad points:
1. Pricing.
2. Since it's (potentially) a one-shot, 3 or 4 years from now we
could own a lot of orphans. This isn't a major concern for us,
but might be for other folks.
3. We have to do our own service.
My own opinion is to go with approach 2 in spite of the price, but that'll
be up to higher management. Anyway, that's where our research stands so
far. Expect an update from me in about a month.
Now, on to some other things that have turned up while this was going on:
One guy had a disgustingly good idea. He is buying a dead IBM-PC/AT
chassis. All he wants is the enclosure and power supply. He's going to
put a CDC WrenIV drive into it, and use it as a shoebox. Sounds perfectly
reasonable to me. [But try finding 100 dead PC/ATs.] If he keeps me
posted, I'll pass it on.
A number of folks are looking at putting SMD or ESDI controllers into a
3/110, 3/75, or 3/140. They would then drive various higher capacity
drives that way. At first blush it sounds real good. But some
interesting issues are surfacing:
The power supplies on those models are not real heavy-duty. One vendor
was asked to certify that their ESDI controller would not overload a 3/110
with motherboard + 8meg ram expansion. The vendor called Sun, talked it
over, and cancelled the quote. Since a 140 is a 110 with a different
motherboard, I'd assume the same risk applies there. Since a 75 is even
older technology, it feels even shakier. I have *no* hard data on what
the power supply is rated for or what the motherboard draws. You're on
your own. But let me know if you find out.
Many many folks have told me Sun will support ESDI directly "real soon
now". Nobody knows what that means. Reconfigurable SCSI drivers for
3/[56]0? Parasite boards on a 3/60? ESDI boards in 3/[12][568]0
backplane? ESDI boards that reside in a 1[14]0 card cage but get their
power externally? It's all vapor so far -- Sun sayeth nothing on this
topic.
One person wrote and asked if I knew of a source for a standalone
cartridge tape unit. No, but it sounds like the sort of thing that surely
exists. You can certianly get one from the Mac houses. Probably all you
need to do is swap connecters and set the SCSI address.
Another guy is talking about just replacing his old 70Mb drives with
WrenIVs. If he keeps me posted on the results of this I'll pass that info
on as well. Also, if *you* do something like this, remember that a lot
(all?) of Sun shoeboxes actually have ST-506 drives and an Interphase
ST-506<=>SCSI converter card. Should you then have a 70Mb ST-506 drive
laying around that I could put in my unix-pc... *grin* ...at a reasonable
price, of course!
Steve Simmons
Schlumberger CAD/CAM
Ann Arbor, MI.
------------------------------
End of SUN-Spots Digest
***********************