Sun-Spots-Request@RICE.EDU (William LeFebvre) (08/22/88)
SUN-SPOTS DIGEST Friday, 19 August 1988 Volume 6 : Issue 191
Today's Topics:
Re: How do I get internal *and* external SCSI on a 3/260 w/ 3.4
Re: Linked or LCD Display of Sun 3/150's?
Re: Sun peripheral policy and multi-architecture product lines
Re: cmdtool (CONSOLE) keeps dying in SunOs 4.0
Re: make has a problem with "make makefile"
Re: window_dump?
Screen saver for 4.0
3.x /etc/init SIGHUP bug fixed
GNU newsletter address
screenblank problems
How can I make a /dev/enable device for the cgfour enable plane?
Graphics under Sunos 4.0?
"get_socket: UNIX buffered is 0"?
NQS queueing system for Unix?
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, 15 Aug 88 16:45:45 MDT
From: roberts%studguppy@lanl.gov (Doug Roberts @ Los Alamos National Laboratory)
Subject: Re: How do I get internal *and* external SCSI on a 3/260 w/ 3.4
> From: petsche@demon.siemens.com (Tom Petsche)
> The question: Does anybody know where I can get a SCSI controller for a
> 3/260 that can handle both internal and external SCSI devices?
Yes. Sun part number 501-1170, 3X2 Adaptor with SCSI. It's a spares part,
list price $1,340. We use it on our Sun 3/260's (running 3.5) that have
both an internal 1/4 inch tape and external CDC Wren-IV drives. The
existing SCSI card comes out & the 501-1170 takes it's place in slot 7.
--Doug
Douglas Roberts
Los Alamos National Laboratory
(505)667-4569
dzzr@lanl.gov
------------------------------
Date: Fri, 12 Aug 88 21:19:36 BST
From: Ian Phillipps <mcvax!camcon.co.uk!igp@uunet.uu.net>
Subject: Re: Linked or LCD Display of Sun 3/150's?
Reference: v6n167
> 2) technology that will send the display from one screen (eg instructor's
> monitor) to 5 or 10 other screens (eg students' monitors). I know that
while true
do rsh $1 -e screendump | screenload
sleep $2
done
A bit of a kludge, but it works, and is free! Something a bit cleverer
could reduce the ethernet traffic if you have lots of screens.
------------------------------
Date: 16 Aug 88 03:21:05 GMT
From: phri!roy@philabs.philips.com (Roy Smith)
Subject: Re: Sun peripheral policy and multi-architecture product lines
ultra!shj@ames.arc.nasa.gov (Steve Jay) asks:
> 2) do you really think Sun is going to continue to produce machines with
> three (680x0, 386, and SPARC) non-compatible architectures?
Why not? I can think of lots of reasons to do so:
1) It's a really neat trick.
2) It keeps you on your toes; if you can manage to make your code run on a
68k, a 386, and a SPARC, chances are pretty good that it'll run on
whatever nifty chip comes along next year. By enforcing discipline now,
it becomes easier and faster to jump on whatever bandwagon looks most
attractive in the future.
3) Keeps your old customers happy. Don't say that people don't care what
CPU you have. You better believe that all those people who paid good
money for those 68k application binary licenses care. Ditto for those
people with (gag, choke) MS-DOS applications they want to be able to run
along side Unix.
On another topic, hedrick@athos.rutgers.edu (Charles Hedrick) says:
> Recently we have been finding Sun's approach to disk controllers
> increasingly frustrating.
And goes on to rant and rave about Sun's incredibly brain-damaged policy
on third-party peripherals. Face it Charles, just as DEC is becoming
IBMish, Sun is becoming DECish. Doesn't this crap about not releasing
boot prom info remind you of the "VAX BI"? Used to be that if you wanted
to build some widget for a pdp-11 or vax, you just cracked open your bus
handbook and read the Unibus specs. Now you gotta pay DEC some ungodly
amount of money to license their BI technology. Sure seems like Sun is
going down the same road.
Roy Smith, System Administrator
Public Health Research Institute
{allegra,philabs,cmcl2,rutgers}!phri!roy -or- phri!roy@uunet.uu.net
"The connector is the network"
[[ Normally I don't include quotes from signatures, but that last one was
just too funny to edit out. --wnl ]]
------------------------------
Date: Tue, 16 Aug 88 08:46:51 EDT
From: <@williams.edu:erm@cc.williams.edu>
Subject: Re: cmdtool (CONSOLE) keeps dying in SunOs 4.0
We've had similar problems, and Sun is very interested. Please call Sun
and let them know what sort of hardware you're running, if the
disappearing cmdtools leave core files, etc. You want to talk to the
graphics support group, and mention bug numbers 1010675 and 1009056.
A suggested temporary (possible) fix is to recompile cmdtool with the
-Bstatic option. The problem has been sufficiently intermittent here that
we haven't yet done this.
Also, if you're on an old 3/50 there's a hardware bug which may be the
culprit. Call Sun and ask about ECO # 3051.
Evan R. Moore
Williams College Computer Center
erm@cc.williams.edu
------------------------------
Date: Fri, 12 Aug 88 16:44:34 BST
From: Ian Phillipps <mcvax!camcon.co.uk!igp@uunet.uu.net>
Subject: Re: make has a problem with "make makefile"
Reference: v6n167
> make does something I do not understand:
Join the club! I have been fighting this problem also, but with the added
complication that I have do makes on two machines, with different make
programs. (Sun 3/260 with 3.5 Sunpro, and Sun 4/110 with kludged 3.2).
I tried your example; a kludge is to
cp {Mm}akefile
make
The makefile wins over the Makefile, and the Make happens.
More useful, your example works on 3.2 make: put /usr/sunpro/3.2 in your
path and try again. I have tried it, and it works. If your system manager
has deleted this, ask for it back!
(My own present problems are all to do with SCCS. Both makes claim to
understand but 3.2 has numerous problems with it, notably "making" a
source file which requires no processing except for the "sccs get". Sunpro
does this fine, but 3.2 claims it doesn't know how to make the missing
files, even although it will fetch them if they require further
processing. I've tried putting "true" as a method of compilation -
although not, admittedly, echo "hello hairyface" - without success.)
I shall be attempting some sort of X on Sun shortly, so I'd be glad of any
bale-outs you may have. I have a virgin X11.2 tape, browsed only.
UUCP: igp@camcon.co.uk | Cambridge Consultants Ltd | Ian Phillipps
or: igp@camcon.uucp | Science Park, Milton Road |-----------------
Phone: +44 223 358855 | Cambridge CB4 4DW, England |
------------------------------
Date: Mon, 15 Aug 88 15:00:26 MDT
From: texsun!sunpeaks!denali!bill@sun.com (Bill Meine [Sun Central ASE])
Subject: Re: window_dump?
Funny you should mention it... Here is a piece of code I wrote a LONG
time ago to give a dump of the visible pixels of any window. The argument
is the window device name (e.g. /dev/win3) whose pixels you wish to dump.
If no argument is specified, an attempt is made to use the WINDOW_GFX
environment variable, which for terminal emulator windows is the inner
text subwindow. It still runs on my 4.0 monochrome system, but I have not
done extensive testing on other configurations lately. Consider this as
an example, as I will not be maintaining any enhancements.
-Bill Meine
Sun Microsystems
/*
* Dump visible portions of window to the standard output. Bill Meine
*
* To 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) /* I shouldn't have to check this...dumb,dumb */
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 /* The whole colormap?!!...oh, well */
{
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);
}
------------------------------
Date: Wed, 20 Jul 88 11:00:37 CDT
From: clyde@emx.utexas.edu (Head UNIX Hacquer)
Subject: Screen saver for 4.0
>From the README:
This is a 'screen saver' setup for SunOS 4.0.
Only one special program is needed now, since Sun uses the 4.3BSD
form of init/getty/ttytab. What is needed is a special getty entry
for the console, and the assoicated programs to be that special getty.
This has been sufficently generalized now that a screensaver (graphics or
a mere screen blanker) could be run on ANY tty (via ttytab).
In fact, this should work on ANY 4.3BSD system also.
-Clyde Hoover
clyde@emx.utexas.edu
[[ The program has been placed in the archives under "sun-source". It is
called "screensaver.shar" and it is 6365 bytes long. It can be retrieved
via anonymous FTP from the host "titan.rice.edu" or via the archive
server. For more information about the archive server, send a mail
message containing the word "help" to the address
"archive-server@rice.edu". --wnl ]]
------------------------------
Date: Mon, 15 Aug 88 17:36:48 EDT
From: geoff@utstat.toronto.edu
Subject: 3.x /etc/init SIGHUP bug fixed
I have the fixed the bug in Sun's /etc/init which prevented programs from
being killed when a dial-in connection dropped and which caused some
programs, such as S and kermit, to loop forever. Sun's init didn't reset
SIGHUP to SIG_DFL in the child process that runs /etc/rc, thus programs
started from /etc/rc, such as inetd, inherited SIGHUP set to SIG_IGN, as
did its children (e.g. in.rlogind) and their children (e.g. login shells)
and their children (e.g. S).
This bug appears to be fixed in 4.0.
*** init.c.old Sun Aug 14 18:03:54 1988
--- init.c Sun Aug 14 18:03:54 1988
***************
*** 255,260
(void) open("/", O_RDONLY);
dup2(0, 1);
dup2(0, 2);
if (oldhowto & RB_SINGLE)
execl(shell, shell, runc, (char *)0);
else
--- 255,261 -----
(void) open("/", O_RDONLY);
dup2(0, 1);
dup2(0, 2);
! (void) signal(SIGHUP, SIG_DFL);
if (oldhowto & RB_SINGLE)
execl(shell, shell, runc, (char *)0);
else
Now we are back to where we were under V7 on the 11/70, after looking for
this bug for two years, on and off. Grump.
Geoff Collyer utzoo!utstat!geoff, utstat.toronto.{edu,cdn}!geoff
------------------------------
Date: Mon, 15 Aug 88 18:04:34 EDT
From: tower@bu-it.bu.edu (Leonard H. Tower Jr.)
Subject: GNU newsletter address
To: Free Software Foundation
675 Mass Ave
Cambridge, MA 02139
USA
Copies of the GNUs BULLetin may be requested from that address. A
self-addressed stamped envelope is appreciated.
e-mail questions to: gnu@prep.ai.mit.edu
enjoy -len
------------------------------
Date: Mon, 15 Aug 88 15:06:01 EDT
From: Kevin R. Underriner <kevinu%wash@rand-unix.arpa>
Subject: screenblank problems
I too have had various screenblank problems, under 3.4 and 3.5. I have
been able to ascertain the following:
- the screen going dark and not restoring is sometimes due to the
screenblank process dying (for no apparent reason), and other times
it just wont restore at all.
- Solution: In both cases, start up a new screenblank on the blanked
machine from a remote machine and then kill all screenblank processes.
The machines giving us the problem are 2 3/50s with a bwtwo and a 3/160
with a cgfour. The problem seems to recur on the above machines whenever
screenblank is run, so I don't run it on them. Anyone else?
Kevin R. Underriner
kevinu%wash@rand-unix.arpa
The RAND Corporation
2100 M Street NW
Washington, DC 20037
------------------------------
Date: Tue, 16 Aug 88 00:02:51 EDT
From: Don Hopkins <don@brillig.umd.edu>
Subject: How can I make a /dev/enable device for the cgfour enable plane?
I'd like to be able to use the cgfour enable plane on a Sun 4/110 like any
other monochrome framebuffer. Is there some magic major/minor pair I get
give to mknod, or does the device driver have to be hacked?
Here's how things are set up right now:
dot# ls -lg /dev/*fb* /dev/*cg* /dev/*bw*
crw-rw-rw- 1 root staff 27, 0 Jun 21 02:27 /dev/bwtwo
crw-rw-rw- 1 root staff 39, 0 Jul 7 05:29 /dev/cgfour0
crw-rw-rw- 1 root staff 22, 0 Jun 20 17:33 /dev/fb
dot#
/dev/bwtwo is the overlay plane, and /dev/fb and /dev/cgfour0 both address
the 8 bit color framebuffer. (Or at least that's what I get when I give
that name to createdevice in NeWS.) I'd like to make a device whose name I
can pass to createdevice that will give me the enable plane as a
monochrome canvas. (I won't admit what I want to use this for...)
-Don
------------------------------
Date: Mon, 15 Aug 88 17:16:18 CDT
From: "Rich Winkel" <MATHPG1@UMCVMB.BITNET>
Subject: Graphics under Sunos 4.0?
I have some (I hope) elementary questions:
In an arbitrary selection of 256 colors from the available pallette of
256**3, many combinations of R G & B are indistinguishable, even when the
color values vary greatly. Are there simple techniques for generating
large selections of RGB combinations that are guaranteed to be
distinguishable, and cover an 'interesting' range of colors? Ideally, I'd
like a function (R,G,B)=F(t) such that the distinguishability of F(t1) and
F(t2) is somehow 'proportional' to t1-t2.
Is there a way to get the exact dimensions (in pixels) of the viewport in
Suncore? We're interested in plotting fractals, but Suncore seems more
oriented towards CAD and such. Should we be using Pixrect? Any examples
of pixel-oriented plotting would be greatly appreciated.
Thanks for any help!
Rich Winkel (MATHPG1@UMCVMB.MISSOURI.EDU)
------------------------------
Date: Mon, 15 Aug 88 21:51:40 PDT
From: Jonathan Eisenhamer <jon@mira.astro.ucla.edu>
Subject: "get_socket: UNIX buffered is 0"?
To All Spots,
Another addition to the list of system error messages that have no
explanation. What does it mean when the system says:
get_socket: UNIX buffered is 0
Summary of responses will be posted (if necessary).
Thanks for your time,
Jonathan Eisenhamer
mira.astro.ucla.edu (128.97.64.198)
------------------------------
Date: 15 Aug 88 22:20:23 GMT
From: News system owner ID <news@bbn.com>
Subject: NQS queueing system for Unix?
I'd be interested in hearing from any sites on the Usenet that have had
experiences, good and/or bad, with the NQS software package.
NQS is a Unix based queueing system originally developed for NASA as a
more powerful substitute for the MDQS queueing protocol. It is available
through NASA's software distribution center, COSMIC, located at U. of
Georgia.
A group at BBN Labs is currently evaluating this package as an alternative
to MDQS and would be pleased to get feedback from other sites using it.
responses to cbarry@bbn.com or phone (617) 873-3071.
Chris Barry
------------------------------
End of SUN-Spots Digest
***********************