Ron Heiby (The Moderator) <unix-request@cbosgd.UUCP> (04/02/85)
Unix Technical Digest Tue, 2 Apr 85 Volume 1 : Issue 39
Today's Topics:
a few Ultrix questions
Daylight Saving Time???
Need help with 4.2 Socket Communications
Q: How to preserve process state across logout/login?
VAX 750 rev 7 u-code patch
----------------------------------------------------------------------
Date: 1 Apr 85 18:13:22 GMT
From: mp@allegra.UUCP (Mark Plotnick)
Subject: a few Ultrix questions
We're getting an 8600, and currently plan to get Ultrix, too.
I have a couple questions for current Ultrix users.
- someone on the arpanet Symbolics Users Group mailing list mentioned
that Chaosnet does not work under Ultrix (or BRL-UNIX), evidently because
of some bug fixes or code restructuring. Is anyone successfully running
Chaosnet under Ultrix? (we do have ip/tcp on our lisp machines, but they
still need chaosnet for some boot phases, and the interaction of Symbolics
tcp with UNIX is less than perfect, and unsupported).
- several people in our lab report a rumor that Ultrix has been de-tuned to
make VMS look better. Can someone who has run both 4.2BSD and Ultrix on
the same machine comment on this?
Mark Plotnick
allegra!mp
------------------------------
Date: 27 Mar 85 11:00:47 GMT
From: jmrm%eng-dsl.cam@UCL-CS.ARPA (James Matheson)
Subject: Daylight Saving Time???
Leif Samuelsson writes
> Well, it seems that all 4.2BSD machines in Europe went on
> DST a week too early this year.
> ...
> Any other suggestions?
Yes, do the daylight saving time decision in a utility which calls
settimeofday() to set the timezone information appropriately. This could
be called from cron on the days when the changes occur (in England this
is the subject of annual legislation and hence not suitable to compile in);
the current value can be saved for the same utility to read and set on
reboot. The current ctime() scheme seems to make very poor use of the
flexibility provided by the timezone info in {gs}ettimeofday().
------------------------------
Date: 31 Mar 85 22:08:03 GMT
From: mason@utcsri.UUCP (Dave Mason)
Subject: Need help with 4.2 Socket Communications
I am attempting to use the 4.2 Sockets communication system.
I am trying to use DATAGRAM sockets in the Unix domain and am having
some problems. The server looks like:
s = socket(...
bind(s,...
...
if (recvfrom(s,buf,buflen,0,&from,&fromlen)<0) ...
... process the data ...
if (sendto(s,buf,buflen,0,&from,fromlen)<0) {
perror(...
abort
}
the client looks like:
sc = socket(...
connect(sc,...
if (send(s,...
if (recv(s,...
The message gets sent properly and received by the server, but the
sendto fails with the ENOTSOCK claiming that the socket s is no longer
a socket. Could someone explain to me (by mail please, I can no longer
find the time to read net.unix-wizards) why this would be, and what I
can do about it.
Thanks ../Dave
--
Usenet: {Most well-connected sites}!utcsri!mason
Dave Mason, U. Toronto CSRI
CSNET: mason@Toronto
ARPA: mason%Toronto@CSNet-Relay
------------------------------
Date: 29 Mar 85 21:29:32 GMT
From: throopw@rtp47.UUCP (Wayne Throop)
Subject: Q: How to preserve process state across logout/login?
> I use a network analysis program that takes 1.5 HOURS(!) of cpu time
> ...
> Restriction: I can't dink with the source...
> ...
> Michael L. Begeman Microelectronics and Computer Technology Corp
There are two solutions that occur to me. Both mean leaving the program
running in the background, with connections left so that you can connect to it
later. One method (by far the simpler one) is applicable under System V.
It goes like this:
To get the program rolling:
$ /etc/mknod in p
$ /etc/mknod out p
$ nohup {your-command-line} <in >out 2>&1 &
$ nohup sleep 40000 </dev/null >in 2>&1 &
$ cat out &
$ cat >in
You are now talking to your program. Now, you can wait until the
program has gotten to a stable state (no IO going on), and then
logout. To get re-connected to the program when you login,
$ cat out &
$ cat >in
To send EOF to the program, kill the sleep-ing process and the
"cat >in" process. The other processes will come down gracefully.
I have tested this method on a System V system with "cat" taking
the place of {your-command-line}.
The equivalent solution for BSD4.2 is more complicated. Using sockets instead
of fifos implies that you must either modify your program to use connect
instead of open, or you must write a program to mediate the connection to
the socket. SO: the Berkeley method means writing two programs:
- One to fork off {your-command-line}, create and bind a socket (so
that it can be found after logout/login), and use select to
transfer a datastream from the socket to a pair of pipes that
connect to the {your-command-line} process.
- The other program connects to the bound socket, and uses select
to transfer a datastream from the terminal to this socket.
I call these programs "create interactive demon", and
"connect to interactive demon". I propose these interfaces
(since I don't actually have these written).
int_dem {socket-name} {command-line}
con_dem {socket-name}
With these two programs, the scenario under Berkeley becomes
% int_dem foo {your-command-line}
After which you can either use con_dem immediately, or log out
and use con_dem after a subsequent login:
% con_dem foo
The behavior of these programs on encountering EOF on a pipe or
a socket is left as an excersize for the implementor. BTW, if anybody
here comes up with the code for these programs, I'll post them.
--
Wayne Throopw at Data General, RTP, NC
<the-known-world>!mcnc!rti-sel!rtp47!throopw
------------------------------
Date: 29 Mar 85 23:45:12 GMT
From: george@weitek.UUCP (George White)
Subject: VAX 750 rev 7 u-code patch
We have just had our VAX 750 upgraded to the latest and greatest
hardware revision level (level 7). One particularly inconvenient
aspect of this, is the requirement of loading the diagnostic monitor
from a cartridge tape to insure that the new microcode gets loaded
after any powerfail. This makes auto-reboot on power fail useless.
Apparently, this new microcode is a patch in the tlb fault handling
routines which can be loaded from the disk at boot time (at least
under VMS there is a procedure for loading this from disk).
My question is if there is any known way to load this microcode patch
from a disk file under 4.2BSD ? I have a cartridge tape with the
binary image of the microcode patch as released by DEC (It is probably
written in a foreign language (VMS) and is undoubtably useless), and
the diagnostic monitor (an Files-11 file system structure on a cartridge
tape - known useless). The patch also exists in file form on the
diagnostic monitor tape.
Network and/or mail answers would be greatly appreciated. My mail
address is: decwrl!turtlevax!weitek!george
George White
Weitek Corp.
------------------------------
End of Unix Technical Digest
******************************
--
Ronald W. Heiby / ihnp4!{wnuxa!heiby|wnuxb!netnews}
AT&T Information Systems, Inc.
Lisle, IL (CU-D21)