Pat_McGregor@UM.CC.UMICH.EDU (07/29/88)
This message was forwarded to the Postmasters at The University
of Michigan due to a problem with our name server. It's possible
that some or all or you may have already received this message,
but we wanted to forward it on to you in case your copy got
eaten.
---(Forwarded from: mtv@umix.cc.umich.edu, Dated: Tue, 26 Jul 88 17:41:32 EDT)---
Return-path: <mtv@umix.cc.umich.edu>
Received: from umix.cc.umich.edu by um.cc.umich.edu via UMnet; Tue, 26 Jul 88 17:29:48 EDT
Received: by umix.cc.umich.edu id AA02505; Tue, 26 Jul 88 17:41:32 EDT
Date: Tue, 26 Jul 88 17:41:32 EDT
From: mtv@umix.cc.umich.edu
Message-Id: <8807262141.AA02505@umix.cc.umich.edu>
To: postmaster@um.cc.umich.edu
Received: by umix.cc.umich.edu (5.54/umix-2.0)
id AA11369; Tue, 26 Jul 88 11:55:52 EDT
Received: from umix.cc.umich.edu by mailrus.cc.umich.edu (5.59/1.0)
id AA01360; Tue, 26 Jul 88 11:44:41 EDT
Date: Tue, 26 Jul 88 11:44:41 EDT
>From: Mailer-Daemon@mailrus.cc.umich.edu (Mail Delivery Subsystem)
Subject: Returned mail: Host unknown
Message-Id: <8807261544.AA01360@mailrus.cc.umich.edu>
To: <Mailer-Daemon@umix.cc.umich.edu>
----- Transcript of session follows -----
550 mailgw.cc.umich.edu.internet... 550 Host unknown
550 <rees@mailgw.cc.umich.edu>... Host unknown
----- Unsent message follows -----
Received: from umix.cc.umich.edu by mailrus.cc.umich.edu (5.59/1.0)
id AA01358; Tue, 26 Jul 88 11:44:41 EDT
Received: by umix.cc.umich.edu (5.54/umix-2.0)
id AA11277; Tue, 26 Jul 88 11:50:47 EDT
Date: Tue, 26 Jul 88 11:50:47 EDT
>From: Mailer-Daemon@umix.cc.umich.edu (Mail Delivery Subsystem)
Subject: Returned mail: Remote protocol error
Message-Id: <8807261550.AA11277@umix.cc.umich.edu>
To: <rees@a.cc.umich.edu>
----- Transcript of session follows -----
>>> MAIL From:<rees@a.cc.umich.edu>
<<< 554 rewrite: cannot prescan canonical hostname:
554 post-apollo@ucbvax.berkeley.edu... Remote protocol error: Bad file number
----- Unsent message follows -----
Received: by umix.cc.umich.edu (5.54/umix-2.0)
id AA11275; Tue, 26 Jul 88 11:50:47 EDT
Received: by a.cc.umich.edu (5.59/1.0)
id AA01293; Tue, 26 Jul 88 11:31:51 EDT
>From: rees@a.cc.umich.edu (Jim Rees)
Message-Id: <8807261531.AA01293@a.cc.umich.edu>
Date: Tue, 26 Jul 88 11:16:15 EDT
Subject: Re: Calendar sync
To: mcdonald@loki.hac.com
Cc: apollo@umix.cc.umich.edu
Reply-To: rees@caen.engin.umich.edu (Jim Rees)
In-Reply-To: mcdonald@loki.hac.com, Mon, 25 Jul 88 15:47:15 pdt
Does anyone know of a good way to keep all
the calendars on an apollo network in sync?
I do not want to shut down a node to rest the
onboard clock. I would like to, from one node,
start a job that hops from node to node to
set the clock to the correct time.
At sr10, you can reset the node time without shutting down. If you don't
have sr10, you can't. I think you can get a daemon that synchronizes
clocks for you. If not, it would be pretty easy to write. You need
one or more central nodes, preferably with a WWV clock, running a time
of day server. There's an RFC out on this (don't know the number).
There is nothing worse than seeing a network where
one node thinks it is 8:00 am PST July 25, 1988
and another thinks it is 9:00 pm PDT July 21, 1988.
The timezone is a little trickier. It's stored in a completely separate
way. Unfortunately, I think you still need to shut down to change the
timezone, even at sr10. This is a lot better than Unix in the old days,
which required you to recompile all your programs to change the timezone.
-------Pat_McGregor@UM.CC.UMICH.EDU (09/21/88)
Due to a hardware error, this message got stuck here at U-M and
forwarded to the postmasters. I'm not certain it made it out to
the rest of the mailing group: I apologize if you are seeing a
duplicate.
Pat McGregor for the U-M postmasters
---(Forwarded from: mtv@mailgw.cc.umich.edu, Dated: Mon, 19 Sep 88 12:48:06 EDT)---
Return-path: <mtv@mailgw.cc.umich.edu>
Received: from umix.cc.umich.edu by um.cc.umich.edu via UMnet; Mon, 19 Sep 88 14:49:56 EDT
Received: by umix.cc.umich.edu id AA02256; Mon, 19 Sep 88 12:48:24 EDT
Received: by mailgw.cc.umich.edu id AA23336; Mon, 19 Sep 88 12:48:06 EDT
Date: Mon, 19 Sep 88 12:48:06 EDT
From: mtv@mailgw.cc.umich.edu
Message-Id: <8809191648.AA23336@mailgw.cc.umich.edu>
To: postmaster@um.cc.umich.edu
Return-Path: Mailer-Daemon@umix.cc.umich.edu
Received: from umix.cc.umich.edu by mailgw.cc.umich.edu (5.59/1.0)
id AA29246; Thu, 1 Sep 88 15:55:01 EDT
Received: by umix.cc.umich.edu (5.54/umix-2.0)
id AA02869; Thu, 1 Sep 88 16:14:27 EDT
Date: Thu, 1 Sep 88 16:14:27 EDT
>From: Mailer-Daemon@umix.cc.umich.edu (Mail Delivery Subsystem)
Subject: Returned mail: Unable to deliver mail
Message-Id: <8809012014.AA02869@umix.cc.umich.edu>
To: <Mailer-Daemon@mailgw.cc.umich.edu>
----- Transcript of session follows -----
554 putbody: write error
----- Unsent message follows -----
Received: by umix.cc.umich.edu (5.54/umix-2.0)
id AA02181; Thu, 1 Sep 88 15:31:42 EDT
Received: by mailgw.cc.umich.edu (5.59/1.0)
id AB28750; Thu, 1 Sep 88 15:06:16 EDT
Date: Thu, 1 Sep 88 15:06:16 EDT
>From: Mailer-Daemon@mailgw.cc.umich.edu (Mail Delivery Subsystem)
Subject: Returned mail: Deferred: Connection timed out during user open with imax.eng.uiowa.edu
Message-Id: <8809011906.AB28750@mailgw.cc.umich.edu>
To: <apollo-request@umix.cc.umich.edu>
To: <apollo-request@umix.cc.umich.edu>
----- Transcript of session follows -----
>>> RCPT To:<hi-apollo@CIM-VAX.HONEYWELL.COM>
<<< 550 Addressee unknown
550 <hi-apollo@hi-multics.arpa>... User unknown
421 imax.eng.uiowa.edu.internet... Deferred: Connection timed out during user open with imax.eng.uiowa.edu
----- Unsent message follows -----
Received: from umix.cc.umich.edu by mailgw.cc.umich.edu (5.59/1.0)
id AA27595; Thu, 1 Sep 88 11:52:07 EDT
Received: by umix.cc.umich.edu (5.54/umix-2.0)
id AA26795; Thu, 1 Sep 88 10:39:14 EDT
Received: by umix.cc.umich.edu (5.54/umix-2.0)
id AA26789; Thu, 1 Sep 88 10:39:01 EDT
Received: by ucbvax.Berkeley.EDU (5.59/1.31)
id AA20404; Thu, 1 Sep 88 07:07:06 PDT
Received: from USENET by ucbvax.Berkeley.EDU with netnews
for apollo-arpa@umix.cc.umich.edu (apollo@umix.cc.umich.edu)
(contact usenet@ucbvax.Berkeley.EDU if you have questions)
Date: 1 Sep 88 12:58:35 GMT
>From: casey@CS.UCLA.EDU
Organization: UCLA
Subject: Don't understand how objects are loaded into memory ...
Message-Id: <15689@shemp.CS.UCLA.EDU>
Sender: apollo-request@umix.cc.umich.edu
To: apollo@umix.cc.umich.edu
Ok, I just don't understand what's going on here. If I do an nm(1)
against an object, it tells me that the variable XXXfoo has been assigned
location 0. When I start up dbx against the object (and run it telling
it to stop in main so I can look at things), dbx says that the address of
XXXfoo (&XXXfoo) is now 0xac5e0. I can deal with that. Things just get
mapping into memory when an object is loaded. And when I use /com/debug
-smap, it tells me about this mapping.
So that's cool. Now I continue executing up to the fault in xmh that
I'm trying to track down. Now when I ask it to print out the addresses
of variables, it gives me random values. It's almost as if the debugger
itself has become corrupted. The values aren't consistent in any way.
Two variables which used to be adjacent to each other are now indicated as
being 16Kb apart.
The question that comes to my mind here is as follows: when I look at
the contents of the address first given for variable when I stopped it in
main, it has the right value at the fault, even though dbx is now telling
me that the variable has a different address. I had thought that the
variable was getting trashed, but now it appears not. Could it be that
the processes mapping is being corrupted?
I guess my next attempt will be to try to cross process debug this so
that the debugger itself doesn't get clobbered.
Casey