Sun-Spots Digest, v6n245

[William LeFebvre]

SUN-SPOTS DIGEST         Saturday, 1 October 1988     Volume 6 : Issue 245

Today's Topics:
                   Re: fcntl/lockf locking under 4.0 (2)
                           Re: vms to sun mail
                      Re: gnuemacs keyboard bindings
                Re: wiring questions (weiss and schwartz)
                  Re: Changing Shared Memory Limitations
                      Re: Interpreting ID PROM info
                   The Horrible 4/110 killing program!
               saving space in the clients' root filesystem
                      followup on csh/execve problem
                      serious bugs in 4.0 rpc.lockd
                            kermit for sun 4?
                       fileservers 4/280 vs. 3/280?
                             Termcap CX4107?
                     ALM-2 and hardware flow control?

Send contributions to:  sun-spots at rice.edu
Send subscription add/delete requests to:  sun-spots-request at 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 at rice.edu" or mail the word "help" to the same address
for more information.

----------------------------------------------------------------------

Date:    Tue, 27 Sep 88 11:14:59 +1000
From:    Craig Bishop <munnari!lupus.cc.deakin.oz.au!craig at uunet.uu.net>
Subject: Re: fcntl/lockf locking under 4.0 (1)

We have had similar problems, Sun looked at the problem then sent us new
binaries for rpc.lockd for both our server which is a 3/280 and our client
which is a 4/110.  These should fix your problems.

Temporarily you can log on to the client then rlogin to the server kill
the rpc.lockd and rpc.statd then immediately shutdown the client and
reboot it. Things should work until either the client or the server
crashes.

It sounds wierd but it was the only way we could get it to work.

Craig Bishop    ARPA:   craig%lupus.cc.deakin.oz.au at uunet.uu.net
    		UUCP:   ...!uunet!munnari!lupus.cc.deakin.oz!craig

------------------------------

Date:    Wed, 28 Sep 88 15:02:18 EDT
From:    Dan Franklin <dan at wilma.bbn.com>
Subject: Re: fcntl/lockf locking under 4.0 (2)

We have problems with hanging fcntl() calls under SunOS 3.5.  I'm
disappointed to hear that 4.0 doesn't fix them.

Not only do processes calling fcntl() and lockf() hang if either the local
or remote rpc.lockd daemon is dead, but you can't even kill them once
they're hung!  Presumably they hang in the kernel exit code trying to free
the locks on all the file descriptors as they're closed.

The problem is particularly bad for us because we have Vaxes running
Ultrix 2.[02], which don't have a locking daemon.  So things ALWAYS hang
when we try to do anything with a file on the Vax.

As a temporary work-around we switched to using flock(), so at least
multiple invocations of our program on the same workstation will
cooperate.  We plan to change our code to try using fcntl(), but if it
hangs, abandon it and switch to flock() for that file descriptor.

	Dan Franklin

------------------------------

Date:    Tue, 27 Sep 88 09:03:42 CDT
From:    "Dave Marquardt" <davem at gonzo.eta.com>
Subject: Re: vms to sun mail

In article <1917 at kalliope.rice.edu> you write:
>We are attempting to find a way to send mail from our VAXs (VAXEN?) to our
>SUN workstations....

Check out PMDF for VMS.  The contact person is NED at YMIR.BITNET.  PMDF
supports a number of different methods of sending and receiving mail,
including a couple of different DECnet methods.

	Dave

------------------------------

Date:    Tue, 27 Sep 88 15:05:44 BST
From:    P.C. Sutton <pcs%MARVIN.BRAD.AC.UK at cunyvm.cuny.edu>
Subject: Re: gnuemacs keyboard bindings

Andrew Gerber asks:
> How would one set up a .emacs file to bind the sun keyboard arrow keys
> ([C [A [B [D) to move the cursor around in Emacs?

This is very simple. The routine below does this. You can put this in your
.emacs file, however it will then be loaded even if you use a different
terminal type.  To ensure that it is only run when you are using a
workstation, put it in a file called `term/sun' somewhere in the emacs
load-path.  (This assumes that your workstation has its TERMINAL
enviroment variable set to `sun'). You can set the load path either within
emacs (change the variable `load-path') or by setting the enviroment
varible EMACSLOADPATH to include the path to the `term' directory.

You can look all this up in the emacs info service, under
customization.

Hope this is helpful.

Paul Sutton            | JANET: pcs at uk.ac.bradford.marvin
Universty Of Bradford
__________

;; Binds arrow keys sun workstation to move cursor

(global-unset-key "\M-[")
(define-key global-map "\M-[A" 'previous-line)
(define-key global-map "\M-[B" 'next-line)
(define-key global-map "\M-[D" 'backward-char)
(define-key global-map "\M-[C" 'forward-char)

------------------------------

Date:    27 Sep 88 04:13:01 GMT
From:    phri!roy at philabs.philips.com (Roy Smith)
Subject: Re: wiring questions (weiss and schwartz)

Eric Ole Barber <mcvax!nw.stl.stc.co.uk!sizex at uunet.uu.net> said:
> I don't think 'live' and 'neutral' would apply in the U.S. since both
> pins are 55V with respect to ground

Say what!?  (or should that be "Say Watt!?" :-)) Live and neutral most
certainly do apply in the US.  The white wire is neutral, the black, blue,
or red wire is hot.  Green, if it exists, is ground.  You should see a
nominal 115V between hot and neutral.  The neutral is tied to ground
*somewhere*, perhaps at the service entrance to your building.  At a
typical wall outlet, you'll see some potential difference between ground
and neutral, but if you see much more than perhaps 5-10 volts, I'd be
surprised.  To be sure, if you see 55 volts between neutral and ground,
something is seriously wrong and you should immediately call a qualified
electrician to correct the problem.
--
Roy Smith, System Administrator
Public Health Research Institute
{allegra,philabs,cmcl2,rutgers}!phri!roy -or- phri!roy at uunet.uu.net

------------------------------

Date:    Tue, 27 Sep 88 09:10:05 PDT
From:    weiser.pa at xerox.com
Subject: Re: Changing Shared Memory Limitations

"I would like to share 4M of data space between processes. However, the
system has limits on the amount of space it will allow (~100K)."

Under SunOS 4.0 the only limitation I have found is 500MB.  Under 3.x, you
will need to rebuild the kernel with some new constants in the config
file.  I added the following to my configs:

options         SHMPOOL=8096    # max number of shared kbytes, total
options		SHMSEG=64	# max shared segments per process

Hope this helps.

-mark

------------------------------

Date:    23 Sep 88 16:11:22 GMT
From:    step!number1!perl at philabs.philips.com (Robert Perlberg)
Subject: Re: Interpreting ID PROM info

On my machine, hostid returns 12005496.  According to your article, it's
telling me that my serial number is 5496.  The serial number on the case
of my machine is 725E2616.  I tried converting 5496 hex to decimal and got
21654.  What's the deal?

Robert Perlberg
Dean Witter Reynolds Inc., New York
phri!{dasys1 | philabs | manhat}!step!perl

------------------------------

Date:    Tue, 27 Sep 88 13:43:07 PDT
From:    Darrell long <darrell at midgard.ucsc.edu>
Subject: The Horrible 4/110 killing program!

We have found that mixing library types is a bad thing to do on a 4/110.
The following is the shortest program that demonstrates this problem.  If
we run it we get a "watchdog reset" and the system is down.

I would be interested in hearing if the same happens on other systems
running SunOS 4.0.  We know that on a 4/260 it only results ina
segmentation fault.

Regards, DL
-- cut --
#
# Feed to sh and stand well back.
#
cat >a.c <<XX
main()
{
printf("dfgdfgdfg\n");
}
XX
cc -c a.c
ld -e start -Bsymbolic a.o /lib/crt0.o -Bstatic -lc
a.out

------------------------------

Date:    Tue, 27 Sep 88 10:29:16 CDT
From:    maeder at symcom.math.uiuc.edu
Subject: saving space in the clients' root filesystem

I have seen some discussion about using one root file system for
several clients under 4.0 in the last few weeks, involving terrible
hacks. While in the good old 3.x days I myself was rather eager to
modify the standard distribution I have now decided to leave it alone
as much as possible. Doing all those updates was just a pain. 4.0 is
much nicer for sysadmins anyway.  Nevertheless I found an easy way of
saving a lot of disk space on these root filesystems.

Basically you do a normal installation with all the client's roots under
/export/root/hostname. Observe that on the server all these root
directories are in the same filesystem. You can therefore use HARD links
for all files that are the same! This is the case for all identical vmunix
files and saves about 600kB per client.  The others that save a lot are
the binaries in the sbin dirctory saving another 270kB (Don't try to make
a hard link for sbin itself...). The rest of the files is not worth
linking (most of them are different anyway. The main idea of 4.0 is to
have only host specific files in /)

A typical (with empty /tmp and /var) root contains about 1.3MB. But all
our 8 clients together use up only 3.2MB.

To do this let suninstall do a normal install of all clients and then go
into each of the root directories except the first one, delete vmunix and
link it:

	ln ../first/vmunix .

the go into the sbin subdirectory, delete all the binaries and link them
in the same way.

In this way you can still have different vmunix files for different
clients if you need.

Another interesting effect of 4.0 is that now all the clients share the
empty space in the root partition. In my example the 8 3/50 clients have a
total of about 8MB available on their root filesystem.  Each one of them
sees the total and can use it for spooling large files etc. On the
negative side, if one client decides to fill up /tmp then all clients
hang. I wonder whether there is a way to prevent this.

Happy hacking,

Roman Maeder
Univ. of Illinois,
Department of Mathematics
and
Center for Supercomputing Research and Development

------------------------------

Date:    Tue, 27 Sep 88 15:20:02 EDT
From:    schwartz at shire.cs.psu.edu (Scott Schwartz)
Subject: followup on csh/execve problem

Some time ago I reported (to Sun and to sun-spots) the fact that the
c-shell does not behave as documented by its man page with respect to the
maximum length of argument lists.

Shortly after that posting appeared in sun-spots, I received mail from a
knowledgeable insider that basically said they knew about this problem.
When they expanded the kernel's maximum value for argument lists they
discovered that there was a bug in the c-shell (segmentation faults, or
some such thing.)  Rather than fix the shell, they simply retained the pre
4.0 limit.  /bin/sh, on the other hand, gets it right.

Recently I received the (terse) official response from Sun on this issue.
Their offical claim is that the csh restricts the length of argument lists
for "compatablility".

Compatablility???  With what?  System V?  BSD? Then why did you change the
kernel and the other shells?  Give us a break!  Hey, look, if you want
compatability, why not ship a real UUCP with SunOS??

------------------------------

Date:    Thu, 29 Sep 88 13:37:45 -0500
From:    abe at mace.cc.purdue.edu (Vic Abell)
Subject: serious bugs in 4.0 rpc.lockd

Here is more information on the 4.0 fcntl/lock bugs I reported previously.

1) If a client or its rpc.lockd crash, the client rpc.lockd cannot
   regain contact with its server rpc.lockd.  The server receives request
   from the client but gets an RPC error when it tries to reply.  The
   client processes using fcntl or lockf hang and cannot be killed.
   However, if both the client and server rpc.lockd processes are killed,
   the server rpc.lockd is restarted, then the client rpc.lockd is
   restarted, the client fcntl/lockf processes resume.

2) Client locks on the same are propagated to the clients, but the lock
   test commands fail between clients.  A fcntl(F_GETLK) call always
   returns F_UNLCK, and lockf(fd, F_TEST, size) always returns zero.
   However, a client without the lock IS blocked if it attempts to set it
   - fcntl(F_SETLK) and lockf(F_LOCK/F_TLOCK) return -1.

3) When fcntl and lock return -1 upon sensing a blocked lock, errno is set
   to EACCESS, not EAGAIN, as documented.

4) Clients and their server do not share locking information properly.
   The clients do send the lock requests to the server for files shared
   via NFS, but the server does not recognize that it already has the same
   lock set for a server process.  The server rpc.lockd does, as noted in
   2, recognize lock conflicts on the same file when clients make the
   requests.

The state of record locking in 4.0 is appalling.  These bugs make it unusable.

Vic Abell

------------------------------

Date:    27 Sep 88 03:18:20 GMT
From:    dave at wucs1.wustl.edu (David T Mitchell III)
Subject: kermit for sun 4?

Help!  Does anyone have a version of kermit which works for the sun 4/280,
running sun os 4.0?

I tried porting one from our vax with no luck.  seems to not receive the
acknowledgement when trying to send.

thanks,

dave				dave at wucs1.wustl.edu

------------------------------

Date:    Wed, 28 Sep 88 17:50:59 EDT
From:    warsaw at cme-durer.arpa (Barry A. Warsaw)
Subject: fileservers 4/280 vs. 3/280?

[[ I got this note in a digest as soon as I could.  Hope it's not too
late...  --wnl ]]

I'm currently using a 3/280S as a fileserver for a ~20 node ethernet, with
6 diskless clients, 4 standalones and the rest dataless nodes (all
Sun-3's).  This fileserver also runs various server processes such as
laserwriter and color printer service, CASE tools, Framemaker and HOL's
(Ada, etc.) as well as the normal nd, nfs, mail type stuff.

We've gotten to a point where we've filled both our 575 Mb drives and we'd
like to expand our system.  Instead of just sticking another disk drive on
the 3/280 (say a 892 Mb drive), we want to go ahead and purchase a second
fileserver and split many of the duties between the two servers.  My
question is this: would it be more advantagous to get a 4/280 server to
handle things like diskless clients, printer service and the like, and
devote the current 3/280 to nfs service, or will the mixing of
architectures (the 4 would be the only non-sun 3 on our network) be more
of a hassle than its worth?   And does the 4/280 buy us much in terms of
the kinds of processing I'll be doing with it?

In other words, if you could get a 280S with an 892 Mb drive and 32 Mb of
RAM to fit in the network described above, would you buy a Sun-3 or Sun-4
and why?

Two notes:

1) all our 3's are running Sun OS3.5 with no plans in the near future to
upgrade to 4.0.  Will this also cause problems?

2) one of our main consideration is that we provide room to expand our
diskless client force.  My gut feeling is that the 6 diskless nodes
currently hanging off of our 3/280 are about all that system can handle,
due mainly to processing power and not disk space limitations.

Since I need answers to these questions asap, I'd appreciate it if you
could e-mail your responses.  I'll summarise and post the results.

Thanks very much,

-Barry

NAME: Barry A. Warsaw                USMAIL: National Institute of Standards
TELE: (301) 975-3460                         and Technology (formerly NBS)
UUCP: {...}!uunet!cme-durer!warsaw           Rm. B-124, Bldg. 220
ARPA: warsaw at cme-durer.arpa                  Gaithersburg, MD 20899

------------------------------

Date:    Mon, 26 Sep 88 23:04:32 CDT
From:    "Rich Winkel" <MATHPG1 at UMCVMB.BITNET>
Subject: Termcap CX4107?

Does anyone have a termcap entry for a Tektronics CX4107?

Thanks,
Rich Winkel
(MATHPG1 at UMCVMB.MISSOURI.EDU)

------------------------------

Date:    Tue, 27 Sep 88 16:38:32 +0200
From:    mcvax!tut.fi!vjk at uunet.uu.net
Subject: ALM-2 and hardware flow control?
Reference: v6n230

> ...Of course the whole problem could be that the
> broadband modems EIA flow control does not work as claimed.

Are you sure that your ALM-2 does hardware flow control. None of ALM or
mcp manuals tells anything about flow control, and I NEED IT.

Vesa

------------------------------

End of SUN-Spots Digest
***********************