From ALAN at MIT-MC.ARPA Sat Aug 31 18:36:41 1985
From: ALAN at MIT-MC.ARPA (Alan Bawden)
Date: Aug 31 85 12:36:41 EDT
Subject: Feature
In-Reply-To: Msg of Sat 31 Aug 85 03:57:02 EDT from Devon S. McCullough
Message-ID:
Date: Sat, 31 Aug 85 03:57:02 EDT
From: Devon S. McCullough
To: BUG-DDT at MC
I snarfed an emacs from a hactro and tried to do G
"no start address" I don't know if this is a DDT bug or an ITS bug.
It isn't exactly anybody's bug. The start address of a program is treated
just like the symbol table. It is stored in binary files for the benefit
of people who load, start, and/or debug the program, but it is not kept
anywhere in the job itself. ITS doesn't concern itself with where you
think a job should be restarted.
Now it -is- a little inconvenient that there is no way to go from a random
job you find floating around the system back to its binary to find its
symbols and starting address. So let me float a few suggestions through
the air and see if anybody thinks they are a good idea:
(1) Add a user variable that would contain a starting address. This would
cover the common case that Devon complained about. (Happens to me all
the time too.)
(2) Add four user variables that would contain the filename of the binary
for the this job. This would enable symbols to be found as well as the
start address.
(3) Add a user variable that contains the address of a block in the job's
address space, in some extensible format we design later, that contains
all kinds of information. Like a vector of start addresses, filenames
of binary files, etc.
(4) Since (3) requires cooperation from the job itself, but (1) covers the
most common case, we could do both. One user variable containing a
start address and one containing the address of a block of information
(or zero if the job doesn't have one). Note that these are both 18 bit
quantities, so this really only adds an extra word to every set of job
variables.
A problem with (3) and (4) is that the new info-block user variable seems
somehow redundant with the existing use of the left half of .40ADDR. The
16.-word block addressed by LH(.40ADDR) is currently only used for
temporary hacking by a job's superior; perhaps there is some way to combine
the two? Perhaps one of the words addressed by RH(.40ADDR) can be the
info-block pointer if the job sets some bit in .OPTION?
I guess I'm in favor of at least (1) if not some variant of (4).
From GSB at MIT-MC.ARPA Mon Aug 19 08:50:42 1985
From: GSB at MIT-MC.ARPA (Glenn S. Burke)
Date: Aug 19 85 02:50:42 EDT
Subject: "dialup line disconnected, detached job #75, usr:gsb hactrn"
Message-ID:
Date: Sat, 17 Aug 85 22:30:43 EDT
From: Alan Bawden
Date: Fri, 16 Aug 85 17:06:59 EDT
From: Glenn S. Burke
I take it this was what you found printed on the system console?
Yes. I had received a 'toplevel interrupt, tree detached' message.
My hactrn was not stopped however.
From ALAN at MIT-MC.ARPA Sun Aug 18 04:30:43 1985
From: ALAN at MIT-MC.ARPA (Alan Bawden)
Date: Aug 17 85 22:30:43 EDT
Subject: "dialup line disconnected, detached job #75, usr:gsb hactrn"
In-Reply-To: Msg of Fri 16 Aug 85 17:06:59 EDT from Glenn S. Burke
Message-ID:
Date: Fri, 16 Aug 85 17:06:59 EDT
From: Glenn S. Burke
Re: "dialup line disconnected, detached job #75, usr:gsb hactrn"
I take it this was what you found printed on the system console?
huh? If it was disconnected why did i not have to request further service
from the ROLM feature?
That's pretty wierd all right. ITS should never do that unless you are on
a tty line with %TYMDM set, and only T01 and T03 through T17 have that set in
the current ITS. That bit -used- to be set for the Rolm lines, but that is
no longer the case because MC wasn't finding out about hangups. Perhaps
there is something more fundamentally wrong with the hangup detection code?
From GSB at MIT-MC.ARPA Fri Aug 16 23:06:59 1985
From: GSB at MIT-MC.ARPA (Glenn S. Burke)
Date: Aug 16 85 17:06:59 EDT
Subject: "dialup line disconnected, detached job #75, usr:gsb hactrn"
Message-ID:
huh? If it was disconnected why did i not have to request further service
from the ROLM feature?
From ALAN at MIT-MC.ARPA Fri Aug 16 18:34:08 1985
From: ALAN at MIT-MC.ARPA (Alan Bawden)
Date: Aug 16 85 12:34:08 EDT
Subject: SOPEN
In-Reply-To: Msg of Mon 12 Aug 85 21:43:31 EDT from Gail Zacharias
Message-ID:
Date: Mon, 12 Aug 85 21:43:31 EDT
From: Gail Zacharias
If I give SOPEN the string "DSK: GZ; GZ OMAIL ", it opens DSK:GZ;GZ
REMIND instead.
SOPEN parsed the string as "DSK:GZ;GZ >" since the trailing space fooled it
into thinking that OMAIL was supposed to be another first filename. I
fixed this problem in the source, I'll test it some time soon. (I also
documented the fact that SOPEN defaults the device to "DSK" the second
filename to ">" and the sname to the job's current sname.)
From ED at MIT-MC.ARPA Tue Aug 13 18:33:18 1985
From: ED at MIT-MC.ARPA (Ed Schwalenberg)
Date: Aug 13 85 12:33:18 EDT
Subject: MC TTY13
Message-ID:
MC's TTY13 dialup is in a state where it recognizes carrier-detect and ^Z to
mean "create a PWORD", but no typeout gets to the output buffer (according to
OS), much less to the terminal. Gunning down the PWORD doesn't even produce
a console free message.
From CSTACY at MIT-MC.ARPA Tue Aug 13 12:28:39 1985
From: CSTACY at MIT-MC.ARPA (Christopher C. Stacy)
Date: Aug 13 85 06:28:39 EDT
Subject: "TTY msg from " should read "TTY msg from @"
In-Reply-To: Msg of Mon 12 Aug 85 23:33:11 EDT from Devon S. McCullough
Message-ID:
Date: Mon, 12 Aug 85 23:33:11 EDT
From: Devon S. McCullough
To: BUG-ITS at MIT-MC.ARPA
Re: "TTY msg from " should read "TTY msg from @"
TTY msg from LLL-CRG.ARPA:
bandy at lll-crg " should read "TTY msg from @"
Message-ID:
TTY msg from LLL-CRG.ARPA:
bandy at lll-crg
rcpt to:
data
this is a send
.
quit
ya see, mc is throwing away the data in the "send from". i don't
throw away the data. mc is the only site on teh whole internet
that supports sends that throws away that return-path data.
so bitch at the smtp/sender maintainers there...
From GZ at MIT-MC.ARPA Tue Aug 13 03:43:31 1985
From: GZ at MIT-MC.ARPA (Gail Zacharias)
Date: Aug 12 85 21:43:31 EDT
Subject: SOPEN
Message-ID:
If I give SOPEN the string "DSK: GZ; GZ OMAIL ", it opens DSK:GZ;GZ REMIND
instead.
From GUMBY at MIT-MC.ARPA Wed Aug 7 22:30:56 1985
From: GUMBY at MIT-MC.ARPA (David Vinayak Wallace)
Date: Wed, 7 Aug 85 16:30:56 EDT
Subject: AI net connection loses
In-Reply-To: Msg of Tue 6 Aug 85 08:38:46 EDT from Alan Bawden
Message-ID:
Date: Tue, 6 Aug 85 08:38:46 EDT
From: Alan Bawden
Date: Tue, 6 Aug 85 06:51:19 EDT
From: David Vinayak Wallace
Why can't NET in LOCK reset AI's chaosnet interface? Or am I confused?
You are totally confused. When the hardware breaks, what do you expect the
software to do? (It doesn't look to me like the problem is specific to AI
anyway, it looks more like subnet 6 is broken somehow.)
It wasn't clear to me from her message what had lost. And anyway,
frequently when the hardware gets wedged resetting it causes it to
start working again. From her description of the symptoms I guessed
that perhaps something like that was happening.
From ALAN at MIT-MC.ARPA Tue Aug 6 14:38:46 1985
From: ALAN at MIT-MC.ARPA (Alan Bawden)
Date: Tue, 6 Aug 85 08:38:46 EDT
Subject: AI net connection loses
In-Reply-To: Msg of Tue 6 Aug 85 06:51:19 EDT from David Vinayak Wallace
Message-ID:
Date: Tue, 6 Aug 85 06:51:19 EDT
From: David Vinayak Wallace
Why can't NET in LOCK reset AI's chaosnet interface? Or am I confused?
You are totally confused. When the hardware breaks, what do you expect the
software to do? (It doesn't look to me like the problem is specific to AI
anyway, it looks more like subnet 6 is broken somehow.)
From GUMBY at MIT-MC.ARPA Tue Aug 6 12:51:19 1985
From: GUMBY at MIT-MC.ARPA (David Vinayak Wallace)
Date: Tue, 6 Aug 85 06:51:19 EDT
Subject: AI net connection loses
In-Reply-To: Msg of Tue 6 Aug 85 05:04:47 EDT from Pandora B. Berman
Message-ID:
Why can't NET in LOCK reset AI's chaosnet interface? Or am I confused?
From CENT at MIT-MC.ARPA Tue Aug 6 11:04:47 1985
From: CENT at MIT-MC.ARPA (Pandora B. Berman)
Date: Tue, 6 Aug 85 05:04:47 EDT
Subject: AI net connection loses
Message-ID:
this morning i was using MC on my terminal. around 04:30 or so response
got very slow, then a few minutes ceased altogether. AI had lost its
net connection again, so i couldn't talk to MC, OZ, or anything else.
someone please fix -- i can't work well with no terminal.
From JNC at MIT-MC.ARPA Mon Aug 5 19:43:26 1985
From: JNC at MIT-MC.ARPA (J. Noel Chiappa)
Date: Mon, 5 Aug 85 13:43:26 EDT
Subject: Grumble, Don't-Reap is no sticky
Message-ID:
I set the 'don't reap' bit on certain mailing list
address list files (e.g. for MIT-IP-PEOPLE), since they don't
get modified a lot and would otherwise have the potential
to go offline (e.g. if the Trident controller breaks).
However, if you modify the file and write it back out
the 'don't reap' bit gets cleared! This is a lose...
Noel