Sun-Spots-Request@RICE.EDU (William LeFebvre) (08/18/88)
SUN-SPOTS DIGEST Wednesday, 17 August 1988 Volume 6 : Issue 189
Today's Topics:
Re: Formatting a non-Sun SCSI disk
Re: Sun video to VCR
Re: Photographic Output Devices
Re: XON/XOFF for printers
Re: 4.0 Sunview question: "alert mouse" cursor color
final solution to everlasting which(1) troubles
CORE, a summary
Undocumented features of the automounter
8mm tape drives
4.0 multi-file system dumps to one tape (bug)
Project Management Tools?
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: 12 Aug 88 02:36:47 GMT
From: "P. Glassenbury" <@relay.cs.net:pete@cantuar.uucp>
Subject: Re: Formatting a non-Sun SCSI disk
Torsten Beyer <unido!bilbo.irb!tb@uunet.uu.net> says:
>
> By the way, has anyone outhere tried to format a non SUN SCSI disk (330Mb
> drive in our case) using SunOS4.0 format (under MUNIX) ??...
We had a Micropolis 1558 (380 Mb, 1224 cyl total) ESDI drive on an Emulex
MD21 controller, talking to a Sun 3/60 via SCSI. Trying to format it
under SunOS 3.5 wouldn't work (lots of errors about not being able to
write cylinder 1225, reasonable enough :-). However, it did format and
scan OK after reducing the sectors/track by one from the the value that
3.5 diag recommends (from 35 to 34, I think). Has anyone else tried
getting a Micropolis 1558 to go on Suns? I'm not sure if we are doing
something wrong or 3.5 diag is broke. BTW, was your drive a Micropolis
1578 (380 Mb, on-disc SCSI interface)? We want one, and have been told
they are unavailable due to production problems.
Hope this helps.
tony@cantuar.uucp OR ..!{watmath,munnari,mcvax,vuwcomp}!cantuar!tony
NZ Phone: Office +64 3 667001 ext. 6354 or 6362 Home +64 3 897913
NZ Post: Computer Science Dept., University of Canterbury
Private Bag, Christchurch, New Zealand.
------------------------------
Date: 11 Aug 88 19:13:00 GMT
From: step!number1!perl@philabs.philips.com (Robert Perlberg)
Subject: Re: Sun video to VCR
> Does anyone have any experience capturing the video output from a Sun
> workstation to video tape? Our training staff would love to be able to
> incorporate actual video displays from a Sun into training videos we produce.
The following is reprinted without permission (do you really think they'd
mind?) from the Summer 1988 edition of SunTechnology (doesn't everybody
get this?):
RGB/Videolink converts Sun's high-resolution RGB or grayscale graphics to
standard composite (NTSC) video in real time. It accepts Sun's
full-screen display signal; performs line and pixel averaging, sync
generation, and encoding; and outputs composite (NTSC) video. The
RGB/Videolink has a full set of user options, including aspect-ratio
correction, color-bar generation, and freeze frame. Other features
include full color, (8 bits per channel), image enhancement through
anti-aliasing, and internal sync generation.
RGB Technology
3684 Hastings Court
Lafayette, CA 94549
(415) 284-4330
Flame-retardent bits: I have no experience with this product or the
company. This is not an endorsement. Celebrity voices impersonated.
Robert Perlberg
Dean Witter Reynolds Inc., New York
phri!{dasys1 | philabs | manhat}!step!perl
------------------------------
Date: Thu, 11 Aug 88 23:44:06 EDT
From: System Operator <root@space.mit.edu>
Subject: Re: Photographic Output Devices
High line-rate video printers are *expensive*, so I don't think that you
are going to find a $2K machine that will accept the Sun signal. (Let us
know if you do!) The cheaper machines only work for PCs or non-interlaced
high res monitors.
We use the Dunn/LogE Multicolor video printer. It cost about $7K and, last
time I looked, it was still the *only* one that could handle the Sun's 70
Khz line rate. It is easy to set up and use, easy to change film backs,
and has lasted well. However, it doesn't have quite the resolution of the
Sun monitors, and is poor at reproducing a solid white background.
Our previous experience was with the Matrix 3000 (also expensive) --
tricky to set up and keep calibrated, poor resolution, but good at
reproducing black-on-white. Ya pays ya money, and takes ya choice.
If your Sun sits on a high-speed network, think about pooling your
resources and buying a digital camera, e.g. Matrix PCR or QCR. Set it up
as a spooled printer, and pipe the output of "screendump" into "lpr".
Simple, but requires an unusual degree of collaboration.
------------------------------
Date: Sat, 13 Aug 88 10:09:46 EDT
From: attcan!utzoo!henry@uunet.uu.net
Subject: Re: XON/XOFF for printers
>My question is: Are sun serial ports set up to hndle XON/XOFF
>normally? ...
Assuming your printer daemon isn't setting them into some strange mode,
there should be no problem. We use XON/XOFF with our LaserJets and never
had any problem. I'd look for parity problems in particular -- maybe your
XOFFs are not getting recognized.
Henry Spencer @ U of Toronto Zoology
uunet!attcan!utzoo!henry henry@zoo.toronto.edu
------------------------------
Date: 11 Aug 88 18:45:41 GMT
From: step!number1!perl@philabs.philips.com (Robert Perlberg)
Subject: Re: 4.0 Sunview question: "alert mouse" cursor color
This sounds like a reasonable feature to me. When a dialog box is up, you
can't do anything with the mouse cursor anyway. You can't continue in any
window until you hit a mouse button. So, since the position of the cursor
is irrelevant, they just get it out of your way so you aren't confused
into thinking that it's position is going to affect anything.
Robert Perlberg
Dean Witter Reynolds Inc., New York
phri!{dasys1 | philabs | manhat}!step!perl
[[ It's been a few days since I've used the new SunView, but I recall
being able to move the mouse to select one of two choices. The mouse came
up over the "default" choice, but I did have the option of selecting the
alternative choice with the mouse. Not all "dialog boxes" have more than
one choice, but some of them do! --wnl ]]
------------------------------
Date: 11 Aug 88 23:46:54 GMT
From: Maarten Litmaath <mcvax!cs.vu.nl!maart@uunet.uu.net>
Subject: final solution to everlasting which(1) troubles
The last few weeks the subject
/usr/ucb/which + .cshrc = misery
has been discussed a lot, including a .cshrc hack like
if ($?prompt) then
... interactive stuff ...
else
... shell script stuff ...
endif
The REAL cause of all trouble with which(1) is its shell script nature:
- it's slooooooooow
- it doesn't give a true picture of one's aliases, it won't discover
aliases which haven't been set in .cshrc, yet will display aliases
which have been unset in between
The solution is to make which(1) an executable and feed it the current alias
list, like:
alias which alias \| /usr/local/bin/which -i
The source of this executable (which will work in sh too) + man page have
been posted to comp.sources.misc recently. Email if you missed it and
you're unable to reach the archive server.
Maarten Litmaath @ Free U Amsterdam:
maart@cs.vu.nl, mcvax!botter!maart
------------------------------
Date: Fri, 12 Aug 88 18:37:31 +0200
From: unido!DFVLRGO1.BITNET!TS36@uunet.uu.net
Subject: CORE, a summary
> Those of you out there using SUNCORE.
> The other day I reported a bug in the SUNCORE software (It is possible
> to set colors in a shaded polygon using GP. it is not possible to do
> that without GP. )
I promised to summarize, here it is: There is one guy who is quite happy
with CORE even though he had some bugs. (has@COMP.LANCS.AC.UK). Others
gave up because of bad documentation, they just hate it (names known to
the author). particular color graphics show bugs. Unfortunately two people
who reported bugs gave up long time ago so that they did not rember
exactly.there are reports on: bugs with input, mouse,keyboard bugs
concerning clipping with GP-board bug when clearing views Some claim
certain CORE functions to be 'completely disfunctional'.
In order to keep it short: I got about 10 or twelve replies. Thanks to all
of you. I did not answer to everybody directly because I lost some mails,
sorry. It seems to me that there is no great enthusiasm about using CORE.
But my german SUN support got an email from on of the graphic support
people at SUN in the US saying that they accepted my bug to be a real bug
and they work to fix that. (This happens after half a year of quarrel with
the local support people). I hope for a fix in a reasonable umount of
time. I learned to be patient.
Why I would like to stick to CORE:
CORE comes with 3.5 (no additional costs)
CORE is reasonable fast.
I have a bunch of software using CORE
PHIGS is new (maybe even more bugs)
they charge me more than 7000DM (equivalent about $4000) per cpu
for PHIGS in germany
PHIGS is reported to be slower than CORE I tried GKS of several vendors ,
all slow with bugs
schorsch pagendarm
TS36@dfvlrgo1.bitnet
german aerospace research establishment
(DFVLR)
3400 goettingen
voice: w.germany 551/709/2407
------------------------------
Date: Fri, 12 Aug 88 14:37:41 EDT
From: Alexander Dupuy <dupuy@columbia.edu>
Subject: Undocumented features of the automounter
We are in the process of bringing up and integrating with our network a
Sun-4 running 4.0. Once, after having to restart ypserv manually, I
started getting complaints from ypserv about not being able to find the
maps "site.bynet" and "mountopts.bysitepair".
With a little help from strings(1) I was able to discover that the
automounter was querying these databases whenever the builtin map "-hosts"
was used. I have tried just about all the reasonable possibilities for
these databases I could, using the hints I was able to glean with strings,
but nothing seems to have any effect on the autmount options.
So if anyone out there has source (or infinite patience to adb the
automounter and figure out what it's doing) and can tell me what the real
true meaning of these obscure maps is, I would greatly appreciate it.
One of the reasons I'm interested in this is that we still have a number
of Sun-2s with 3Com ethernet boards, which need special mounting options
(rsize, wsize) to prevent NFS errors with Sun-3s and -4s. Without some
way to specify mount options on a host-pair basis, the "-net" map is not
that useful to us.
Given the names of the YP maps, though, I have a sinking feeling that the
mount options are only for communication between different networks (and
perhaps not even subnets).
@alex
------------------------------
Date: Fri, 12 Aug 88 11:57:29 EDT
From: sally.cs.utexas.edu!harvard!srs!matt@cs.utexas.edu
Subject: 8mm tape drives
Someone ("tore@ifi.uio.no") asked me about how I came to use the values
that I use for tape length and density (90000 feet, 1600 bpi) for the 8mm
tape drives we have. Since I can't seem to get mail back to him, I
thought I might as well send it to Sun-Spots.
We are using 90 minute tapes. From the data sheet we have from Delta
Micro, the length of a 90 min. tape is 270 feet. I used the following
calculations (the 0.429 and 150 are from the same data sheet):
270 feet * 12 inches/foot 150 inches/second (effective)
------------------------- * ----------------------------- =
0.429 inches/sec. (real) 12 inches/foot
94405 effective tape feet.
>From that, I rounded down to 90000 feet. Now, since the data sheet says
that a 90 min tape holds 1750 Mb, we can do the following:
1750 Mb/tape * 1024 Kb/Mb * 1024 bytes/Kb
----------------------------------------- = 1619 bpi
94405 feet/tape * 12 inches/foot
I rounded that down to 1600 bpi. Using 90000 and 1600 gives a total
capacity of 1647.9 Mb per 90 min. tape, which is a good conservative
estimate. Unfortunately, it turns out to not be quite conservative
enough. Here are some tests I ran here on our various tape drives:
8mm reel cart
--- ---- ----
time (sec) 6660 416 616
data (Kb) 1576071 169596 20034
rate (Kb/sec) 236.6 407.6 32.5
tape count 1 9.29 78.67
tape cost ($) ~7 ~180 ~2280
The "tape count" is the number of tapes it takes to hold as much as one
8mm tape. The tests were made by a little program that just writes blocks
as fast as it can. I think I used a blocking factor of 126 for all of
them, but I may have used something less on the 1/2" drive.
If you think about it, these drives really are recording at a density of
around 1600 bpi (since the effective tape speed is 150 ips) using very
thin diagonal tracks . I guess the next step is to up the density to 6400
(or 6250) on these tracks and quadruple the storage capacity.
My original article asked how to speed up dumps over the network. Nobody
has sent me any tips on this, so I am living with what we have, and
enjoying the convenience of being able to dump our entire 1.2 Gb disk
system to one little tape.
Matt Goheen
uucp: {rutgers,ames}!rochester!srs!matt
real-nets: matt@srs.uucp OR matt%srs.uucp@harvard.harvard.edu
------------------------------
Date: Fri, 12 Aug 88 12:04:02 MDT
From: ciocc!root@cinelli.UUCP
Subject: 4.0 multi-file system dumps to one tape (bug)
There seems to be a bug in the SUN OS 4.0 SCSI tape device driver
associated with the no-rewind option used in the dump program. When
specifying the no-rewind option in the dump script for the device that you
are writing to (ie., /dev/nrst8) the driver writes two eof markers at the
end of the dump. Dumping other files to the tape may occur successfully
however the problem occurs when trying to read back data from the tape.
When two eof markers are encountered the device concludes that you are at
the end of tape. Reading the first file dumped to the tape is fine,
however, trying to read subsequent files written after the two eof markers
results in I/O errors. (there may be a way to forward the tape past these
markers, however I've tried may things without success).
There is a work-around in order to accomplish successful multi-file system
dumps to one tape.
instead of the script...
dump 1ucf /dev/nrst8 /dev/xy0a #first partition to dump
dump 1ucf /dev/nrst8 /dev/xy0d #second partition
...
use something like...
dump 1ucf /dev/rst8 /dev/xy0a
mt -f /dev/nrst8 fsf 1 #position tape after first partition
dump 1ucf /dev/rst8 /dev/xy0d
mt -f /dev/nrst8 fsf 2
...
I havn't tested this thoroughly, yet it seems to work. The bug is
documented by Sun aand has a reference number of 1011942. The fix is
scheduled to be released with SunOS 4.0.1. but must be aasked for.
good luck dumping,
B. Gammel internet path - gammel@handel.colostate.edu
uucp - ...decwrl!hplabs!hpfcla!handel!gammel
------------------------------
Date: Fri, 12 Aug 88 19:19:17 BST
From: kquinlan%edg.cv.co.uk@me.brunel.ac.uk (Kevin Quinlan)
Subject: Project Management Tools?
Does anyone out there know of a good project management system that runs
on the Sun workstation.
I would be particularly interested in hearing of any systems that use the
graphics capabilities of the Sun and allow output to a range of print or
plot devices.
[[ Please mail replies directly to Mr. Quinlan. He has informed me that
he will summarize if the interest is sufficient. --wnl ]]
Kevin Quinlan, Computervision, Penn St, Amersham, HP7 0PX, UK
{decvax,sun}!cvbnet!cvb!cvedg!kquinlan +44 494 714771 x 269
kquinlan%edg.cv.co.uk@me.brunel.ac.uk
------------------------------
End of SUN-Spots Digest
***********************