Sun-Spots-Request@Rice.edu (William LeFebvre) (09/08/88)
SUN-SPOTS DIGEST Wednesday, 7 September 1988 Volume 6 : Issue 221
Today's Topics:
Re: Notification on receiving new mail (2)
Free PostScript previewer
Notice to Sun4 driver writers
Bug in SunOS 3.5 Pascal Compiler (pc)
tcsh problems on Sun
tcsh, also mail notification
Problems with file locking under 3.4
Getting multicast ethernet packets in the driver?
Informix on a Sun?
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: Wed, 7 Sep 88 18:12:01 BST
From: Richard Tobin <richard%aiai.edinburgh.ac.uk@nss.cs.ucl.ac.uk>
Subject: Re: Notification on receiving new mail (1)
> Unfortunately, the "comsat" program is started
> by "inetd" deamon only on the machine to which the mail is directed.
You can hack around this, if you really want the asynchronous mail
notification. Sendmail sends a datagram to the comsat port each time some
mail arrives. If you
(a) arrange to have a process listening on that port (instead of comsat)
which will copy the packet to some other port on all the machines
you want notified, and
(b) have comsat listen on that other port,
then you'll get what you want. Below is a program to do the copying.
(Note: I just hacked this up. It seems to work, but no guarantees.)
Change /etc/servers on each machine to run this program instead of comsat,
and to run comsat if it gets a datagram on a port called real-comsat.
Define the port real-comsat in /etc/services to be some unused udp port.
Put a list of hosts to be notified in /etc/biff-hosts. Make the yp
version of services. Kill and restart inetd on each machine. Wait for
some mail...
/*
* super-comsat
*
* Copyright Richard Tobin 1988. You may redistribute this program freely
* provided this comment remains intact.
*
* Problem - all mail is received on a server, but users would like to be
* biffed on whichever machine they're logged on to.
*
* Solution - have inetd run this program instead of comsat when it gets
* a datagram on 512/udp. It will broadcast the datagram to some other port
* on all relevant machines. Then we have the real comsat listen on that
* port.
*/
#include <stdio.h>
#include <sys/types.h>
#include <sys/socket.h>
#include <netinet/in.h>
#include <netdb.h>
main() /* no args - it's run from inetd with */
{ /* stdin connected to socket */
int s, msglen;
char msg[255], buf[256];
struct servent *service;
FILE *host_list;
msglen = recv(0, msg, sizeof(msg), 0);
if(msglen < 0)
{
perror("super-comsat: recv");
exit(1);
}
close(0);
s = socket(AF_INET, SOCK_DGRAM, PF_UNSPEC);
service = getservbyname("real-comsat", (char *)0);
host_list = fopen("/etc/biff-hosts", "r");
if(host_list == NULL)
{
perror("super-comsat: /etc/biff-hosts");
exit(1);
}
while(fgets(buf, sizeof(buf), host_list))
{
struct hostent *host;
struct sockaddr_in to;
if(buf[0] == '#') continue;
buf[strlen(buf)-1] = '\0';
host=gethostbyname(buf);
if(host)
{
bzero((char *)&to, sizeof(to));
bcopy(host->h_addr, (char *)&to.sin_addr, host->h_length);
to.sin_family = host->h_addrtype;
to.sin_port = service->s_port;
if(sendto(s, msg, msglen, 0, &to, sizeof(to)) < 0)
{
perror("super-comsat: sendto");
exit(1);
}
}
}
exit(0);
}
------------------------------
Date: 7 Sep 88 17:56:35 GMT
From: mkhaw@teknowledge-vaxc.arpa (Mike Khaw)
Subject: Re: Notification on receiving new mail (2)
Reference: v6n219
> ...it would be nice to have some sort of mail watcher tool that
> would notify you when /usr/spool/mail/<user> changed. To my knowledge,
> no such program exists.... --wnl ]]
Isn't the "faces" program in sun-sources just such a mail watcher?
[[ I don't see a program called "faces" anywhere in the sun-source
archives. Is it hiding as part of another package? --wnl ]]
Mike Khaw
--
internet: mkhaw@teknowledge.arpa
uucp: {uunet|sun|ucbvax|decwrl|uw-beaver}!mkhaw%teknowledge.arpa
hardcopy: Teknowledge Inc, 1850 Embarcadero Rd, POB 10119, Palo Alto, CA 94303
------------------------------
Date: Wed, 7 Sep 88 13:48:45 BST
From: mcvax!inf.rl.ac.uk!caag@uunet.uu.net
Subject: Free PostScript previewer
Here are extracts from a number of announcements that I have made to the
info-postscript mailing list and Usenet over the last nine months:
__________
This is to announce a freely available implementation of the PostScript
page description language. It is available to all, but not for inclusion
into products without prior licencing from us.
It is a complete implementation with the exception of save and restore and
readonly and executeonly. Thick lines, dashed lines, setscreen,
settransfer, definefont, etc, are all fully implemented. We have used it
locally to preview ditroff documents, for example.
It has a small device specific module with a defined interface to aid
portability and the rest of the code runs unchanged on suns, perqs,
whitechapels, vaxen and pyramids (among others). It has run on SunOS,
PNX, 42NIX, System V, BSD 4.2 and Ultrix (among others).
Currently the only major driver uses a portable graphics library (called
WW) which runs on suns, whitechapels and perqs, but is available freely
only to UK academics. A couple of weeks work may thus be necessary to
write a driver for each display for people who are not. WW is available to
UK academics from RAL.
__________
A driver for Sunview has since been posted, which draws postscript in a
window rather than straight on the display. Terry Weissman wrote a driver
for X11 which appeared in comp.sources.bugs.
__________
My PostScript previewer was posted to comp.sources.unix on Usenet before
Christmas '87. Unfortunately, I let it out with a makefile set up to use
WW. If you 'make pixrect sunPS', it makes a version for sun displays
which writes straight on the frame buffer. The distribution is not really
set up for zero-thought building - this is free s/w after all!
In the US, the interpreter can be FTPed from:
mimsy.umd.edu (Milnet East coast)
and
parcvax.xerox.com (Arpanet, west coast).
called:
PSPreviewer.tar.Z (compressed tar format).
Ftpable copies are available in England from the Shareware sites:
uk.ac.ukc|University of Kent at Canterbury Computer Lab:
address=info-server@ukc.ac.uk:mode=automatic:type=1
__________
SunOS 4.0 has appeared since it was posted. two trivial modifications are
necessary to make it work on 4.0:
In fill.c, "infinity" needs to be replaced by "Infinity" wherever it
occurs. In image.c, "log2" needs to be replaced by "logtwo" wherever it
occurs. These names clash with new 4.0 names.
__________
Name: Crispin Goswell Informatics Department
Usenet:{... | mcvax}!ukc!rlinf!caag Rutherford Appleton Lab
JANET: caag@uk.ac.rl.inf Chilton, Didcot
ARPA: caag%inf.rl.ac.uk@nss.cs.ucl.ac.uk Oxon OX11 0QX, UK
------------------------------
Date: Wed, 7 Sep 88 09:24:14 PDT
From: stevo@jane.jpl.nasa.gov (Steve Groom)
Subject: Notice to Sun4 driver writers
In the SunOS kernel, there are two different concepts of interrupt
priorities. One is the bus priority (the priority a devices uses to
generate an interrupt on the bus), and and the other the CPU priority (the
interrupt level of the CPU).
The bus priority of a device is specified in the kernel configuration
file. The config utility, when it generates some tables (see ioconf.c),
converts the bus priority specified in the file to the corresponding CPU
priority, which is stored in the table. The value in this table can then
be used as an argument to the pritospl() macro, which converts a CPU
priority into an appropriate argument to splx() (used to set the current
CPU priority) by shifting it over.
For VME Suns, bus priorities are in the range 0-7. For 680x0, CPU
priorities are also in the range 0-7. For SPARC (Sun4), CPU priorities
are 0-15.
The problem is this. On Sun4's, config converts the bus priority to a CPU
priority by doubling it. pritospl() also converts it. So when you use
pritospl() on the value in the table, the conversion has been done twice.
Using pritospl() on the value from the table is a perfectly legitimate
thing to try and do, and is done in the examples in the driver manual.
So, either config or pritospl is messed up.
Example: Device with bus priority 4, listed in the table as 8. Problem:
pritospl(8) doesn't work, because SPARC only looks at the low 4-bits of
the priority. So when you say splx(pritospl(8)), it sets the CPU priority
to 0, not 8. Not quite what was intended.
I won't say how long I went on trying to figure out how I was getting
interrupts in the middle of my "uninterruptible" critical sections.
Luckily, pritospl is a macro (defined in psl.h), so you can #undef it
and re- #define it in your code. The bad version of pritospl() looks
like this:
#define pritospl(n) ((n) << 9)
And this is how it should look:
#define pritospl(n) ((n) << 8)
This bug applies to Sys4-3.2 *and* SunOS 4.0 (Sun4).
When I reported it to Sun, they told me they already knew about it, bug
#1012397, and it will be fixed in 4.1.
How did Sun ever write a Sun4 driver that worked with this kind of bug?
And they didn't find it when they did 4.0? Oooh, that's bad.
-steve
------------------------------
Date: Wed, 7 Sep 88 09:59:21 PDT
From: frame!troy!drf@sun.com (David Fuchs)
Subject: Bug in SunOS 3.5 Pascal Compiler (pc)
Sorry to "argue...about this behavior on [a] street corner", but a careful
reading of the ANSI Pascal spec reveals that the program as given is NOT
in error, and pc is wrong when it reports a run-time failure.
Specifically, the "from" and "to" values of a for-loop are indeed allowed
to be out-of-range with respect to the for-loop variable, just as long as
they have values that don't cause the loop contents to be executed. The
"from" and "to" values are considered full integers, and are only
range-checked against the loop variable AFTER they have been compared as
full integers and the loop been skipped if "from>to" (or "to>from" for
DOWNTO). We can agree that we don't like this, and that we think it's
silly, and even that many compilers don't get it right, but it IS the
definition of Pascal for-loops.
-David Fuchs (who has been caused a fair bit of pain by this feature)
------------------------------
Date: Wed, 7 Sep 88 11:08:27 CDT
From: Joe Ramey <ramey@mips.csc.ti.com>
Subject: tcsh problems on Sun
You might try compiling the tcsh (or 4.3bsd csh) with VFORK undefined.
Vfork behaves differently under SunOS 4.0 (and perhaps earlier releases)
than does 4.2 or 4.3 BSD with respect to signal handling. If, after the
vfork, the child process calls changes a signal handler (via a call to
signal), the signal handler is changed for the parent also! This doesn't
happen under Ultrix 2.2 (on a VAX) or 4.3bsd on a MIPS. Here is a sample
program that demonstrates the difference.
#include <signal.h>
#include <stdio.h>
void childhandler();
void parenthandler();
main()
{
int pid;
signal(SIGINT, parenthandler);
fprintf(stderr, "doing fork...\n");
if ((pid = fork()) == 0)
{
signal(SIGINT, childhandler);
_exit(0);
}
else
{
while(wait(0) != pid);
kill(getpid(), SIGINT);
}
signal(SIGINT, parenthandler);
fprintf(stderr, "doing vfork...\n");
if ((pid = vfork()) == 0)
{
signal(SIGINT, childhandler);
_exit(0);
}
else
{
while(wait(0) != pid);
kill(getpid(), SIGINT);
}
exit(0);
}
void childhandler()
{
fprintf(stderr, "in childhandler\n");
}
void parenthandler()
{
fprintf(stderr, "in parenthandler\n");
}
__________
On a Sun this prints:
doing fork...
in parenthandler
doing vfork...
in childhandler
while on the 4.3 or Ultrix machines it prints
doing fork...
in parenthandler
doing vfork...
in parenthandler
Joe Ramey
TI Computer Science Center
------------------------------
Date: Wed, 7 Sep 88 12:44:41 EDT
From: Vick Khera <khera@cs.duke.edu>
Subject: tcsh, also mail notification
I have a working version of tcsh running on both sun3's and sun4's with no
real problems. i applied the patches to 4.3 BSD csh sources and had only
four failures from patch. one of them was a REALLY big addition that i
think patch couldn't deal with properly. the others were trivial one
liners.
in other news...
i have a tool that monitors /usr/spool/mail/$user every 60 seconds and
changes it's icon to reflect that mail is present. it is part of a larger
mail processing tool i am writing called mhtool (based on mh) that i could
strip it out of if people really want it. i have a small problem with
mhtool in that when i create a new window to run an editor in, it core
dumps. i have no idea why since the exact same code will work properly in
another program. any clues? this happens in SunOS 3.3, 3.4, and 3.5.
vick.
ARPA: khera@cs.duke.edu Department of Computer Science
CSNET: khera@duke Duke University
UUCP: decvax!duke!khera Durham, NC 27706
------------------------------
Date: Wed, 7 Sep 88 15:19:12 EDT
From: davidra@helios.tn.cornell.edu
Subject: Problems with file locking under 3.4
The file-locking system calls do not work as advertised in SunOs 3.4.
The setup: We have servers X0 and Y0 and diskless nodes X1,X2,... that get
their root partitions from X0 and Y1,Y2,... that get their roots from Y0.
To repeat: Set a lock on diskless machine X1 (served by X0) using either
lockf(3) or fcntl(2). Staying on machine X1, again use either lockf(3) or
fcntl(2) to test the lock.
lockf() with the F_TEST flag is supposed to return -1 (which it does) and
set errno to EAGAIN, indicating the presence of a lock. Instead, it sets
it to EACCES (this is not serious, since I can use EACCES as well as
EAGAIN to tell me that a lock is present.) fcntl() behaves properly.
Keeping the lock on machine X1, log in to server X0 to test the lock. It
works just as on X1.
Now log in to any machine that isn't the server (X0) and isn't the machine
from which the lock was established (X1). Both lockf() and fcntl()
indicate the absence of a lock, even though the lockd(8) is supposedly
running. This happens whichever machine is the new machine's server.
David Rabson
Laboratory of Atomic and Solid State Physics
Cornell University
davidra@helios.tn.cornell.edu
------------------------------
Date: Wed, 7 Sep 88 09:48:12 MDT
From: Charles Shub <cdash@boulder.colorado.edu>
Subject: Getting multicast ethernet packets in the driver?
sorry, I cant help you with your problem, but maybe you can help me with
mine. I want to have an ie card pass multicast packets up to the driver.
What do i have to do to the card (probably in the reset routine in the
driver) to get it to do that? Sun customer support has been totally
unhelpful. As a back up, can i set the card to promiscuous mode?
thanks...
cdash aka cdash@boulder.Colorado.EDU -or- ..!{ncar|nbires}!boulder!cdash
------------------------------
Date: Wed, 7 Sep 88 13:58:07 EDT
From: arnold@mathcs.emory.edu (Arnold D. Robbins {EUCC})
Subject: Informix on a Sun?
I am interested in hearing from anyone running the Informix relational
database software, and/or any SQL sort of product from Informix, on Sun
hardware. In particular, if you are running it on a Sun 4 under SunOS
4.0, I'd like to hear from you.
Things I need to know:
1. Sun hardware base (only Sun 3? Sun 3 and Sun 4?)
2. Sun software base (only 3.x? 4.0 scheduled for when? 4.0 now?)
3. Does it work "well"?
a) How bug-free is it?
b) How big (or small) a resource hog is it?
Basically, there is a group within our University who have been running
Informix on a dedicated 680x0 based Unix system, and who've been told to
move. They've come to us, as the central computing resource, and are
looking into our supplying Informix for them. We are planning to migrate
to a Sun 4 (if I can get our !@#$%^&* disks working, but I've gone over
that before), so that's why I'm more interested in finding out if Sun
versions of Informix exist.
We would be running it on a machine that will also be carrying our
time-sharing load, so please take that into consideration.
Thanks In Advance,
Arnold Robbins
Emory University Computing Center
+1 404 727-7636
DOMAIN: arnold@emory.edu (finally!)
UUCP: { decvax, gatech, skeeve }!emory!arnold
BITNET: arnold@emoryu1
------------------------------
End of SUN-Spots Digest
***********************