Sun-Spots-Request@RICE.EDU (William LeFebvre) (08/23/88)
SUN-SPOTS DIGEST Sunday, 21 August 1988 Volume 6 : Issue 194
Today's Topics:
Re: SUN at SIGGRAPH '88 (Monitor Madness)
Re: window_dump
bug in 3.0 (and later?) putc macro in stdio.h
Sun-4 fp %g bug to be fixed
Cartridge tape formats and sizes (/dev/rst0 versus /dev/rst8)
SLIP on SunOS4.0?
Unix Domain sockets crash Sun OS 3.?
386i on second-source ethernet card?
group access to directories?
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: Thu, 18 Aug 88 10:06:53 -0400
From: John F. Fowler <jffowler@icarus.cns.syr.edu>
Subject: Re: SUN at SIGGRAPH '88 (Monitor Madness)
At SUN's booth at SIGGRAPH '88 I also noticed something that could be
interpreted as either good or bad news.
Almost all of the demonstration units in their booth used the 19" Sony
GDM-1950 monitor instead of a Hitachi monitor. The Sony's picture quality
and construction is so much better than the Hitachi that it is like night
and day.
We are a self-maintenance customer and have discovered the Hitachi monitor
to be a real black hole for money. We had a Hitachi authorized service
person come in and inspect our units and he claims that out of our 20 or
so units 3 of them have shot picture tubes, and they are less than a year
old. For every color machine that offers it we now order the 16" color
monitor which is the Sony GDM-1650. It is a beautiful unit that we have
no problems with at all.
I spoke to a Catalyst 3rd party vendor about the 19" Sony who has their
software ported to the 4/110TC; their understanding was that SUN was going
to start shipping the 19" Sony on certain selected models such as the TC.
We recently took delivery on a 4/260C, which is a very expensive machine,
and it came in with a 19" Hitachi. For demonstration purposes we often
will switch the monitor with a 16", which is a much better monitor but it
is not offered as a purchase option on the 2xx machines.
I spoke to Sony OEM about the 16" and 19" monitors, and they told me that
they were "in negotiations" on the 19" monitor. The 16" and 19" monitors
that Sony provides to SUN are modified in some way such that they are
unique. I was curious as to whether I could order 2xx machines as a
server, order an appropriate frame buffer from spares, and get a 19"
monitor from a Sony distributor. Or, buy 16" monitors and replace the 19"
when they break. Appears not, unless these "modifications" are a red
herring.
The SIGGRAPH '88 demo was a little disturbing ... unless SUN is going to
starting SHIPPING all those machines with 19" Sony monitors it is somewhat
iffy to SHOW them that way. I pity the customer that orders a
workstation based on what they saw at SIGGRAPH and opens the box and finds
the Hitachi monitor.
Open questions to SUN: What is the status of shipping the Sony 19" as a
standard or extra-cost option? How about making available information
such that self-maintainers can pursue their own monitors like in the PC
and Mac world? What is SUN's experience with the 19" Hitachi?
John Fowler
Syracuse University
Computing and Network Services Internet: jffowler@icarus.cns.syr.edu
Machinery Hall Bitnet: oprjff@suvm
Syracuse, NY 13244-1260 USA AT&T: (315) 423-2861
------------------------------
Date: Thu, 18 Aug 88 07:53:31 MDT
From: sutton%olin@lanl.gov (John Sutton)
Subject: Re: window_dump
There is a program that dumps a specified window. It was written by Bill
Meine of Sun Microsystems in Denver and published in Winter 86 issue of
README. It does the job but one must guess what /dev/win# to dump if you
are issuing the command from a window other than the one to be dumped. We
have used it but we find the dumpregion program more useable.
Attached is the what appeared in Vol. 1 No. 6 README.
/tech/hints
Bill Meine
Sun Microsystems, Inc.
Here is a little piece of code that dumps the visible portion of any
active window (or if not given, looks for WINDOW_GFX in the environment).
It works for monochrome and color windows. The rasterfile is directed to
the standard output.
You can print the screendump using 'windump | lpr -v', if your printer has
a 'vf' printfilter for print rasterfiles (the Sun User Group donated
software tape has such printfilters for the HP LaserJet and the Epson). If
you have a Sun LaserWriter you can scale and rotate the image using the
options provided by the pssun(1L) filter before piping to lpr.
[you can also use prraster, psraster, rastoimp, rfquic2, etc. from the rice
archive server - jgs]
______________________________________________________________________
/*
* Windump.c
* Dumps visible portions of window to standard output.
* Bill Meine, Sun Microsystems, Inc.
*
* Compile: cc -O -o windump windump.c -lsunwindow -lpixrect
*/
#include <stdio.h>
#include <sys/file.h>
#include <sunwindow/window_hs.h>
main (argc, argv)
int argc;
char *argv[];
{
char win_name [WIN_NAMESIZE];
if (argc == 1)
{
if (we_getgfxwindow (win_name) == 0)
dump_win (win_name);
else
fprintf (stderr, "Couldn't find graphics window in environment.\n");
}
else if (argc == 2)
dump_win (argv[1]);
else
fprintf (stderr, "Usage: %s [window_dev]\n", argv[0]);
}
dump_win (win_name)
char *win_name;
{
int fd;
struct pixwin *pw;
struct rect r;
struct pixrect *out_pr;
unsigned char red[256], green[256], blue[256];
colormap_t cmt;
if (( fd = open (win_name, O_RDWR, 0)) != -1)
{
if ((pw =pw_open (fd)) != (struct pixwin *) NULL)
{
win_getsize (fd, &r);
out_pr = mem_create (r.r_width, r.r_height,
pw->pw_clipdata->pwcd_prmulti->pr_depth);
pr_rop (out_pr, 0, 0, r.r_width, r.r_height,
PIX_CLR, NULL, 0, 0);
pw_lock (pw, &r);
pw_read (out_pr, 0, 0, r.r_width, r.r_height,
PIX_SRC, pw, 0, 0);
if (pw->pw_clipdata->pwcd_prmulti->pr_depth >1)
pw_getcolormap(pw, 0, 256, red, green, blue);
pw_unlock (pw);
if (pw->pw_clipdata->pwcd_prmulti->pr_depth == 1)
{
cmt.type = RMT_NONE;
cmt.length = 0;
}
else
{
cmt.type = RMT_EQUAL_RGB;
cmt.length = 256;
cmt.map[0] = red;
cmt.map[1] = green;
cmt.map[2] = blue;
}
if (pr_dump (out_pr, stdout, &cmt, RT_STANDARD, 0)
== PIX_ERR)
fprintf (stderr,
"Error while dumping pixrect.\n");
pw_close (pw);
pr_destroy (out_pr);
}
else
fprintf (stderr, "Couldn't open pixwin.\n");
close (fd);
}
else
fprintf (stderr, "Couldn;t open window '%s'\n", win_name);
}
______________________________________________________________________
Hope this is useful.
John Sutton
Los Alamos Nat'l Lab
(sutton@olin.lanl.gov)
------------------------------
Date: Wed, 17 Aug 88 22:07:13 EDT
From: geoff@utstat.toronto.edu
Subject: bug in 3.0 (and later?) putc macro in stdio.h
This is an ancient 4BSD bug that I reported to net.bugs.4bsd and possibly
UCB years ago (1984?). "putchar('\377')" on a Sun 3 returns -1 instead of
0377. (If Sun's cat command bothered to check the return values of
putchar (in case a disk filled up, say), Sun would have noticed this long
ago, probably while running lint, which uses cat to concatenate binary
files.)
Here's a fix:
34c34,35
< #define putc(x,p) (--(p)->_cnt>=0? ((int)(*(p)->_ptr++=(unsigned)(x))):_flsbuf((unsigned)(x),p))
---
> #define putc(x,p) (--(p)->_cnt >= 0? ((unsigned char)(*(p)->_ptr++ = (x))): \
> _flsbuf((unsigned char)(x), p))
This is fixed in 4.0 and apparently in 3.5; I don't know which (earlier?)
release fixed it.
Geoff Collyer utzoo!utstat!geoff, utstat.toronto.{edu,cdn}!geoff
------------------------------
Date: Thu, 18 Aug 88 11:04:39 EDT
From: Dan Franklin <dan@wilma.bbn.com>
Subject: Sun-4 fp %g bug to be fixed
In a previous message I mentioned that one of the problems we had with our
Sun-4 port was that all floating-point numbers between 0 and 1 printed
without an initial zero in %g format. That is, "0.1" was printed as ".1".
This broke a lot of our test scripts.
My complaint on sun-spots elicited this reply. I thought it had been sent
to sun-spots as well as me, but apparently not.
------- Forwarded Message
> Date: Wed, 3 Aug 88 07:38:58 PDT
> From: dgh@Sun.COM (David Hough)
> To: dan@wilma.bbn.com
> Subject: ".1" vs "0.1"
>
> This is supposed to be fixed in SunOS 4.1.
------- End of Forwarded Message
I'd also like to apologize for the remark I made about this bug which
unjustifiably insulted AT&T. This problem had nothing to do with System V
and AT&T at all.
Dan Franklin
------------------------------
Date: Thu, 18 Aug 88 02:56:03 PDT
From: hoptoad.UUCP!gnu@cgl.ucsf.edu (John Gilmore)
Subject: Cartridge tape formats and sizes (/dev/rst0 versus /dev/rst8)
There seems to be massive confusion about cartridge tapes. It's really
simple combinations of three different parameters.
There are two variants of the mechanical tape drive -- 4-track and
9-track. The tracks are used like on an 8-track audio tape (run all the
way down the tape on one track, then mechanically slide the head up or
down and do another pass of the tape.) The 9-track version can store
9/4ths as much data as the 4-track version. The 9-track version will read
4-track tapes but the tapes it writes can be marginal for reading on
4-track machines, because the tracks are thinner. Mostly they work.
There are two variants of the tapes themselves. One is 450 feet long
(DC300XL style) and the other is 600 feet long (DC600A style). They use
different magnetic coatings because the tape has to be thinner to fit 600
feet into a cartridge. Some older tape drives can only read/write the 450
foot tapes because their heads can't cope with the new magnetic coatings.
There is a sense hole on the cartridge (up near the write protect tab)
that lets the newer drives figure out how to set up the head for this
particular tape. The actual end-of-tape sensing is done with small holes
punched in the tape itself, detected with an LED, a mirror in the
cartridge, and a photocell, so that works fine for either tape length.
There are two variants of the bit format that controllers record on the
tape. One is called QIC-11, the other is QIC-24. QIC-11 is the original
Archive format (Archive Corp. started the whole 1/4" streaming cartridge
business). When a standards committee got a hold of it, they changed it
(of course) to QIC-24. In both cases, the tape contains 512-byte blocks
of data with small headers on them. For QIC-11, the block number in the
header is 8 bits; for QIC-24, the number is 24 bits. That is essentially
the only difference between the two. It was changed because in unusual
error recovery situations it's possible for the tape to move more than 256
blocks (at 90 inches per second and 8000 bits per inch, things go by
quickly -- think about it) and the controller could lose track of where it
was on the tape. Both formats hold the same amount of data on a given
tape.
If you make up a table of this stuff, you start seeing some familiar
numbers:
Tape 450' 600'
Drive
4-track 20MB [no such drives used in Suns]
9-track 45MB 60MB
The hardware takes care of 4-track/9-track and tape size issues, so all
you have to specify in software is whether you want QIC-11 or QIC-24
formatting. /dev/rst0 is QIC-11 and /dev/rst8 is QIC-24. I linked them
to /dev/rst.qic11 and /dev/rst.qic24 so I could just do it without looking
it up.
I believe Sun should have made the tape driver software attempt to read
tapes in both QIC-11 and QIC-24 format, like reel-to-reel tape drives
which will read whatever density you throw at them. They didn't,
unfortunately, so if you try to read a tape that's in the other format, it
looks like a totally empty tape (you get a "no data" error). Just rewind
and try again with the other format. If you get "no data" in both
formats, you really have a blank tape (or one recorded in yet some other
random format).
There are a few other manufacturers who use QIC-24 tape drives; the IBM
PC/RT is one. Apollos may be another, I'm not sure. Very few of the IBM
PC 1/4" tape drives use QIC-24; they all went off in different directions.
I don't know of any current production machines that use QIC-11 only; it's
obsolete.
Sun used to make all their distribution cartridges in 4-track, QIC-11
format on 450 foot tapes [20MB], since they can be read by all Suns.
Starting with SunOS 4.0, they are now making Sun-4 tapes in QIC-24 on
9-track, 600 ft tapes [60MB] which reduces the number of tapes by a factor
of 3. I am not sure whether Sun-3 tapes have been switched, though I
think all Sun-3's can read 60MB QIC-24 tapes unless they were upgraded
from Sun-2's. However, older boot PROMs can't boot from a QIC-24 tape
(they never ask the tape controller to try QIC-24 mode, and it's too dumb
to do it itself), which is why you may need a boot PROM upgrade from Sun
Tech Support to boot SunOS 4.0 from 1/4" tape.
[I wrote the 'ar' driver for 1/4" tape on Sun-1's -- my first Unix driver,
and it was really bad -- and maintained the boot code for tape drives
through the first Sun-3's.]
John Gilmore
------------------------------
Date: 17 Aug 88 22:41:23 GMT
From: jar@jessica.stanford.edu (Janine Roeth)
Subject: SLIP on SunOS4.0?
Has anyone installed SLIP code on a SunOS 4.0 system? Was it the archived
slip code on titan.rice.edu under slip.shar?
Looking at that slip.shar, it is for generic 4.2 and Suns running 3.x.
Since there doesn't seem to be any documented support in the SunOS 4.0
distribution I was hoping to use this code.
If possible, please reply to jar@jessica.stanford.edu.
thanks,
Janine Roeth
Academic Information Resources
Stanford University
------------------------------
Date: Wed, 17 Aug 88 23:29:47 MDT
From: pag@hao.ucar.edu (Peter Gross)
Subject: Unix Domain sockets crash Sun OS 3.?
I have two relatively simple programs (server and client) that test Unix
Domain sockets, which will crash any Sun (3 or 4, haven't tried a 2)
running Sun OS 3.2 or Sun OS 3.5. It appears that when an AF_UNIX socket
is closed and unlinked when there is unread data in it, goodbye system!
The programs run properly on any Sun OS 4.0 I have tested (so far, a Sun
4/280 and a Sun 3/60).
If, by some tiny chance, this hasn't been discussed before I will
supply the source to the offending programs.
--peter gross
pag@hao.ucar.edu
[[ Actually, I can't find any articles on this in volume 5 or 6, but I
know the bug exists (someone here pointed it out to me and some others
sometime last year. --wnl ]]
------------------------------
Date: Thu, 18 Aug 88 01:30:33 -0400
From: Steve Elias <eli@spdcc.com>
Subject: 386i on second-source ethernet card?
does anyone have any experience running a Sun 386i with a typical PC
ethernet card ??? i know it's an ugly question... i'm wondering about
compatibility with 3com 3+, in particular. my local rep says that the
3com drivers have hard coded timing loops which can't deal with real
multitasking... has anyone tried something like this ?
also... how does a 386i deal with "not-nice" PC programs which like to
hog the CPU during serial port transfers and lock up the machine if
seriously interrupted ?
steve elias
------------------------------
Date: 17 Aug 88 21:21:28 GMT
From: hpda!sun!megatest!djones@uunet.uu.net (Dave Jones)
Subject: group access to directories?
I have been trying, without any success, to create a group, and then to
create a directory in which the members of the group have all access
privileges to files.
Has anyone done this, and if so how? (The obvious attempts are
fruitless.)
I've about decided that the thing to do is to create a phantom user, let
members of the group "su" to that uid when they need to update the
directory.
-- Dave J.
[[ I don't mean to be insulting, but how can this be hard? Make sure
everyone in the group is listed correctly in /etc/group, or make sure
they all have the correct login group in /etc/passwd. Create the
directory, owned by whoever with the correct group ownership. "chmod" the
directory to have all the group bits on (mode 775 or 770 are good enough)
and there you go. The only other stumbling block is making sure that
person B in the group can overwrite a file originally written by person A.
For this you have to make sure that both people's "umask" is set to 2
instead of 22 (the default). A umask of 22 will result in the group write
bit being off for every file that is created. --wnl ]]
------------------------------
End of SUN-Spots Digest
***********************