github.com/PDP-10.its
1
0
Fork 0
mirror of https://github.com/PDP-10/its.git synced 2026-02-13 03:23:58 +00:00
Code Issues Releases Wiki Activity

Various ITS documentation files.

Browse Source
This commit is contained in:
Lars Brinkhoff
2018-05-13 20:21:37 +02:00
parent 69544b3832
commit 61b0dd1dfa
8 changed files with 8855 additions and 1 deletions
Download Patch File Download Diff File Expand all files Collapse all files

13
doc/emacs/-read-.-this- Normal file
View File

@@ -0,0 +1,13 @@
The files TS > are the dumped copies of EMACS. There need only be two of them.
The file TECMAC <number> is the current versions of TECMAC for the
TECO version <number>. Please do not delete any of them.
Files TCM<number> <number> are dumped versions of TECMAC. Please
keep 2 for each distinct FN1.
Finally, the files [PURE] <number> are the sharable copies of the
EMACS library. THEY MUST NOT BE REAPED UNLESS YOU KNOW WHAT USES THEM.
Each TCMnnn file, each TECMAC nnn file, and each TS nn file, uses
the [PURE] file which is the most recent [PURE] file written
before it (the TS, TECMAC or TCMnnn file) was written.
If you don't understand this, don't delete ANY [PURE] file.
I (RMS) take good care of flushing any garbage I can find in
this directory, so you need not attend to it.

31
doc/inquir/-user-.-note- Normal file
View File

@@ -0,0 +1,31 @@
This is the file directory for user information
LSR1 LOCK is used by INQUIR to prevent more than one INQUPD from trying
to update the data base at once. The data base is locked when
LSR1 LOCK is open for writing.
LSR1 > is the most recent valid copy of the INQUIR data base.
Do not alter that file with anything but INQUIR unless you
know what you are doing.
LSR1 NEW is a new version being written.
LSR1 OLD and LSR1 OLDOLD are the next 2 older versions.
LSR1 2, if it exists, means that an INQUPD crashed while renaming
versions.
However, the situation is under control and will be cleaned up
automatically by INQUPD the next time it runs.
.UPD1. and .UPD1$ files are updates sent by INQUIR, but not yet stuck
into the LSR1 file.
INQUIR UPDATE is an archive of all the INQUIR updates done. WHen it
gets large, rename it to OUPDAT >. Only a few months of OUPDAT
files need be kept around.
ULIST > files are output from the INQUIR command ULIST. It is OK
to delete them if they are more than a few days old, since they are
easy to regenerate.
SETMSN is a program run by the default .DDT. (INIT) file. It
sets the user's msname according to the FILE DIRECTORIES item in his
INQUIR entry.

82
doc/inquir/lsr1.doc Normal file
View File

@@ -0,0 +1,82 @@
-*-Text-*-
This file describes the format of the new LSR1 user data base.
Note that a standard library, SYSENG;LSRTNS >, exists for
referencing this data base. Use it!
The file header:
HDRSID==0 ; wd 0 SIXBIT /LSR1!!/
HDRDAT==1 ; wd 1 Date of compilation as sixbit YYMMDD
HDRTIM==2 ; wd 2 Time of compilation as sixbit HHMMSS
HDRUNM==3 ; wd 3 Address in file of UNAME table.
HDRLNM==4 ; wd 4 Address in file LASTNAME table.
HDRDAT==5 ; wd 5 Address in file of start of data area.
; The data area must start on a page boundary,
; and it must be the last thing in the file.
;....
The UNAME table:
wd 0 Number of entries in this table,
followed by entries, one per page of data area,
each containing the UNAME of the first data area
entry which begins on that page.
The LASTNAME table:
wd 0 Number of entries in this table,
followed by entries, in order by last name
Each entry looks like this:
rh addr in file of entry
lh addr in file of Last-name string
The lastname strings are word-aligned upper-case ASCIZ strings,
and they follow the LASTNAME table.
The data area:
It starts on a page boundary. It is made up of consecutive entries,
in order by UNAME, each looking like this:
LDACNT==0 ; entry wd 0 lh
; the number of words in the entry,
; including this one.
; entry wd 0 rh -1
followed by unaligned ASCIZ strings, one per item, separated
only by the single ^@ that ends the ASCIZ. The strings are associated
with their meanings according to their numerical position in the entry.
The entire entry is then padded to a word boundary with nulls.
Note that the low bit is set in the count-words of entries
and not in any other words of the data area.
The entries are sorted in ascii order, which is NOT the same
as the order obtained by arithmetically sorting the SIXBIT unames.
The end of the data area is marked by ,,-1, which
is tantamount to an entry 0 words long.
That word is also the last word of the file.
The standard symbols for all the items are these:
I$==,-1
I$UNAM==0 ;UNAME
I$NAME==1 ;FULL NAME
I$NICK==2 ;NICKNAME
I$SSN==3 ;SOC SEC #.
I$MITA==4 ;MIT ADDRESS
I$MITT==5 ;MIT TELEPHONE NUMBER
I$HOMA==6 ;HOME ADDRESS
I$HOMT==7 ;HOME TELEPHONE NUMBER
I$SUPR==10 ;SUPERVISOR(S)
I$PROJ==11 ;PROJECT
I$DIR==12 ;FILE DIR NAMES
I$AUTH==13 ;AUTHORIZATION
I$GRP==14 ;GROUP AFFILIATION
I$REL==15 ;RELATION TO GROUP
I$BRTH==16 ;BIRTHDAY
I$REM==17 ;REMARKS
I$NETA==20 ;NETWORK ADDRESS
I$ALTR==21 ;USER &TIME OF LAST ALTERATION
I$MACH==22 ;I.T.S.'S TO BE KNOWN ON.

7906
doc/mudman/muddle.order Normal file
View File

File diff suppressed because it is too large Load Diff

713
doc/sysdoc/peek.bugs Executable file
View File

@@ -0,0 +1,713 @@
Date: Fri, 5 May 89 14:14:14 EDT
From: Devon Sean McCullough <DEVON@AI.AI.MIT.EDU>
To: BUG-PEEK@AI.AI.MIT.EDU
Message-ID: <591317.890505.DEVON@AI.AI.MIT.EDU>
watching the comsat stats file with 1C, it said
MPV; DSKTY3+1>>ILDB B,A B/ 0,,65 a/ 350700,,32000
d/ 134
p/ c,,pdl+2
pdl+2/ cam dsktlp+2
pdl+1/ cam disk+23
pdl/ cam beg8+1

Date: Sun, 20 Mar 88 13:48:17 EST
From: Devon Sean McCullough <DEVON@AI.AI.MIT.EDU>
To: BUG-PEEK@AI.AI.MIT.EDU
Message-ID: <344793.880320.DEVON@AI.AI.MIT.EDU>
I was sitting in 0C watching COMSAT and I got
MPV; 11772>>ILDB 2,1 2/ 151 1/ AOS 16,32000
with no apparent provocation. A day or so ago I got MPV right on
the heels of a **MORE** (not --more-- which was strange) but I
didn't notice where. 31777 seems to be the last word of the buffer
being monitored.

Received: from XX.LCS.MIT.EDU (CHAOS 2420) by AI.AI.MIT.EDU 21 Jan 87 00:29:12 EST
Date: Wed, 21 Jan 1987 00:25 EST
Message-ID: <SRA.12272592709.BABYL@XX.LCS.MIT.EDU>
From: Rob Austein <SRA@XX.LCS.MIT.EDU>
To: Alan Bawden <ALAN@AI.AI.MIT.EDU>
Cc: BUG-COMSAT@AI.AI.MIT.EDU, BUG-PEEK@AI.AI.MIT.EDU, JTW@AI.AI.MIT.EDU
Subject: PEEK shouldn't ever PCLSR anyone
In-reply-to: Msg of 18 Jan 1987 22:51-EST from Alan Bawden <ALAN@AI.AI.MIT.EDU>
Date: Sunday, 18 January 1987 22:51-EST
From: Alan Bawden <ALAN@AI.AI.MIT.EDU>
In the case of the DQ device screw, I don't really understand why PEEK
PCLSRing the -server- would cause any kind of deadlock to be broken.
Not that surprising. Remember that DQ: is a very strange file. In
particular, see the code that uses register Y in OUTPUT and BOJINT to
avoid hanging forever at the SIOT in OUTPUT. I would not be surprised
if that code was intimately involved in this bug, I doubt anybody has
ever tried to make a JOB device do anything this twisted before.

Date: Sun, 18 Jan 87 22:51:43 EST
From: Alan Bawden <ALAN@AI.AI.MIT.EDU>
Subject: PEEK shouldn't ever PCLSR anyone
To: BUG-COMSAT@AI.AI.MIT.EDU, BUG-PEEK@AI.AI.MIT.EDU
cc: JTW@AI.AI.MIT.EDU
Message-ID: <141778.870118.ALAN@AI.AI.MIT.EDU>
I just found two obvious places in PEEK that would cause a job to get
PCLSR'd.
The first would PCLSR any job that PEEK suspected might be a MUDDLE job (it
had some test involving the contents of the job's accumulators). Despite
the comment that threatened to "BREAK THE NECK OF THE ASSHOLE WHO REMOVES
ANY CODE HERE WITHOUT CONSULTING ME AND OBTAINING PERMISSION", I removed
it.
The second would PCLSR any job that PEEK suspected might be an interesting
job device server. Any job whose JNAME started with the three characters
"JOB" would be PCLSR'd when PEEK went into "C" mode because PEEK used
.IOT's on the USR: device to probe around in its memory (to see if it was
an MLDEV, or other device server it knows about). I fixed this to use
memory mapping instead.
In the case of the DQ device screw, I don't really understand why PEEK
PCLSRing the -server- would cause any kind of deadlock to be broken. But
in any case, now there is a good chance that the next time COMSAT and DQ
get into this state, the mere act of discovering the lossage in PEEK (by
going into "C" mode to read the STATS file) will not cause the lossage to
vanish. Perhaps we will be able to find the problem now.

Received: from AI.AI.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 13 MAY 86 12:43:22 EDT
Date: Tue, 13 May 86 12:44:25 EDT
From: Alan Bawden <ALAN@AI.AI.MIT.EDU>
To: ZVONA@MC.LCS.MIT.EDU
cc: BUG-PEEK@MC.LCS.MIT.EDU
In-reply-to: Msg of Mon 12 May 86 20:15:40 EDT from David Chapman <ZVONA at MC.LCS.MIT.EDU>
Message-ID: <[AI.AI.MIT.EDU].38227.860513.ALAN>
Date: Mon, 12 May 86 20:15:40 EDT
From: David Chapman <ZVONA at MC.LCS.MIT.EDU>
BUG-PEEK is currently archived in MC:RMS;. Should it live in AI:RMS;?
Some other directory on AI? Some altogether different place?
Probably it should go into AI:SYSDOC;.

Date: Mon, 12 May 86 20:15:40 EDT
From: David Chapman <ZVONA@MC.LCS.MIT.EDU>
To: BUG-PEEK@MC.LCS.MIT.EDU, KS-ITS@MC.LCS.MIT.EDU
cc: ZVONA@MC.LCS.MIT.EDU
Message-ID: <[MC.LCS.MIT.EDU].911011.860512.ZVONA>
BUG-PEEK is currently archived in MC:RMS;. Should it live in AI:RMS;?
Some other directory on AI? Some altogether different place?

Date: Tue, 4 Mar 86 18:15:40 EST
From: Alan Bawden <ALAN@MC.LCS.MIT.EDU>
Subject: "W" mode sorting
To: BUG-PEEK@MC.LCS.MIT.EDU
cc: MOON@MC.LCS.MIT.EDU
Message-ID: <[MC.LCS.MIT.EDU].838752.860304.ALAN>
The Internet Routing table ("W" mode) sorting-by-age feature doesn't seem
to be functioning properly on AI right now. Perhaps this is because
currently AI has entries that are more than 5 days old?

Date: Mon, 3 Mar 86 02:12:36 EST
From: Alan Bawden <ALAN@MC.LCS.MIT.EDU>
Subject: " mode in PEEK
To: BUG-ITS@MC.LCS.MIT.EDU, BUG-PEEK@MC.LCS.MIT.EDU
Message-ID: <[MC.LCS.MIT.EDU].836305.860303.ALAN>
I added a new mode to PEEK for printing the contents of the system message
buffer. (Type a doublequote to get it.) This is especially useful for
looking at crash dumps. While I was at it I added a few features to crash
dump mode itself. For a good example try (on AI):
:PEEK <CRASH;IMP NXM
and after looking at the crash dump display, type " to see some more
interesting error messages.

Received: from XX.LCS.MIT.EDU by MC.LCS.MIT.EDU 5 Jan 86 12:36:54 EST
Date: Sun, 5 Jan 1986 12:32 EST
Message-ID: <SRA.12172848298.BABYL@XX.LCS.MIT.EDU>
From: Rob Austein <SRA@XX.LCS.MIT.EDU>
To: Chris Lindblad <CJL@OZ.AI.MIT.EDU>
Cc: Alan Bawden <ALAN@MC.LCS.MIT.EDU>, BUG-HOSTS3@MC.LCS.MIT.EDU,
BUG-PEEK@MC.LCS.MIT.EDU, BUG-RANDOM-PROGRAM@MC.LCS.MIT.EDU,
GUMBY@MC.LCS.MIT.EDU, namecallers@MC.LCS.MIT.EDU
Subject: Ick!
In-reply-to: Msg of 2 Jan 1986 14:33-EST from Chris Lindblad <CJL@OZ.AI.MIT.EDU>
(Oh bleep, let's put this on namecallers and get it over with already).
From: Chris Lindblad <CJL@OZ.AI.MIT.EDU>
Alan points out that when generating the hosts3 table, you only have to
be compatible with people who have been using the hosts3 table.
Not quite. Eg, JIS has MIT-OA.MIT.EDU as the IN-ADDR translation for
18.10.0.79, so if anybody out there is still using the old cannonical
name algorithm (name->address->name) they will think that is OA's
primary name, thus will include it in mail headers, thus people using
HOSTS3.BIN should be able to recognize it to avoid barfing on replies.
This is probably not as much of a problem for AI as for LCS because of
the relative numbers of TCP/IP machines.
There are bugs in your algorithm anyway. You are taking the name MITAI
and generating MIT-MITAI.ARPA, which was never in any domain. (The arpa
domain only contained the primary names of hosts).
Mea culpa.
I really think it is silly to be genrating all these names. Just because
JIS was lazy, and made names like mit-foo.mit.edu shouldn't be a reason
for us to clutter our host tables with them. I suggest that as soon as
possible, we eliminate references to the mit.edu domain. The longer
they're there, the harder it will be to take them out, and there's no
better time to make changes like this than during IAP.
Agreed. I never intended that all that cruft be there permenantly,
just for transition to try to keep the world from falling apart too
badly too fast. IAP does seem like a good time to punt it.
Over the next year, more than 100 hosts will be added to the host table.
We better start making each entry more compact if we expect it to keep
working. Alan says that we have only two pages left.
Right, but the key point is that HOSTS3 isn't going to work much
longer. One of two things will happen: (1) the NIC table will no
longer be anything like exhaustive, in which case the table is
incomplete, or (2) the NIC table will grow to the point where it is
completely unusable. My guess is that we will end up with a
HOSTS3.BIN that contains info for MIT, and Chaos-only machines will
either have to grok domains or just start blindly sending mail to some
forwarder if the address is unrecognized. Eventually HOSTS3 may
become identical with HOST3C if/when chaos machines grok domains, but
that's not for a while yet.
For the AI host table. I would be happy if you didn't generate any
names, and I specify all the names I want.
Ok. Nag me if you don't hear about this in the next few days.

Received: from OZ.AI.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 2 JAN 86 14:41:23 EST
Date: Thu, 2 Jan 1986 14:33 EST
Message-ID: <CJL.12172083807.BABYL@MIT-OZ>
From: Chris Lindblad <CJL@OZ.AI.MIT.EDU>
To: Rob Austein <SRA@XX.LCS.MIT.EDU>
Cc: Alan Bawden <ALAN@MC.LCS.MIT.EDU>, BUG-HOSTS3@MC.LCS.MIT.EDU,
BUG-PEEK@MC.LCS.MIT.EDU, BUG-RANDOM-PROGRAM@MC.LCS.MIT.EDU,
GUMBY@MC.LCS.MIT.EDU
Subject: Ick!
In-reply-to: Msg of 2 Jan 1986 13:52-EST from Rob Austein <SRA at MIT-XX>
Date: Thursday, 2 January 1986 13:52-EST
From: Rob Austein <SRA at MIT-XX>
The problem is that all of those names are in somebody or another's
domain space at the present time. JIS has been advertising things
like MIT-AI.MIT.EDU, etc. The way things are set up currently you can
punt this cruft, but only a on a per-domain basis (ie, for all of
AI.MIT.EDU). If you (primarily CJL) want to do this, fine, tell me,
I'll do it. But you should think about it first, since people really
have been using some of those stupid names.
Some thoughts on this.
Alan points out that when generating the hosts3 table, you only have to
be compatible with people who have been using the hosts3 table.
There are bugs in your algorithm anyway. You are taking the name MITAI
and generating MIT-MITAI.ARPA, which was never in any domain. (The arpa
domain only contained the primary names of hosts).
I really think it is silly to be genrating all these names. Just because
JIS was lazy, and made names like mit-foo.mit.edu shouldn't be a reason
for us to clutter our host tables with them. I suggest that as soon as
possible, we eliminate references to the mit.edu domain. The longer
they're there, the harder it will be to take them out, and there's no
better time to make changes like this than during IAP.
Over the next year, more than 100 hosts will be added to the host table.
We better start making each entry more compact if we expect it to keep
working. Alan says that we have only two pages left.
For the AI host table. I would be happy if you didn't generate any
names, and I specify all the names I want.

Received: from XX.LCS.MIT.EDU by MC.LCS.MIT.EDU 2 Jan 86 13:50:05 EST
Date: Thu, 2 Jan 1986 13:52 EST
Message-ID: <SRA.12172076316.BABYL@XX.LCS.MIT.EDU>
From: Rob Austein <SRA@XX.LCS.MIT.EDU>
To: Alan Bawden <ALAN@MC.LCS.MIT.EDU>
Cc: BUG-HOSTS3@MC.LCS.MIT.EDU, BUG-PEEK@MC.LCS.MIT.EDU,
BUG-RANDOM-PROGRAM@MC.LCS.MIT.EDU, GUMBY@MC.LCS.MIT.EDU,
SRA@XX.LCS.MIT.EDU, cjl@OZ.AI.MIT.EDU
Subject: Ick!
In-reply-to: Msg of 1 Jan 1986 02:41-EST from Alan Bawden <ALAN@MC.LCS.MIT.EDU>
The problem is that all of those names are in somebody or another's
domain space at the present time. JIS has been advertising things
like MIT-AI.MIT.EDU, etc. The way things are set up currently you can
punt this cruft, but only a on a per-domain basis (ie, for all of
AI.MIT.EDU). If you (primarily CJL) want to do this, fine, tell me,
I'll do it. But you should think about it first, since people really
have been using some of those stupid names.

Date: Wed, 1 Jan 86 02:41:38 EST
From: Alan Bawden <ALAN@MC.LCS.MIT.EDU>
Subject: Ick!
To: BUG-PEEK@MC.LCS.MIT.EDU, BUG-RANDOM-PROGRAM@MC.LCS.MIT.EDU,
BUG-HOSTS3@MC.LCS.MIT.EDU, SRA@MC.LCS.MIT.EDU
cc: GUMBY@MC.LCS.MIT.EDU
Message-ID: <[MC.LCS.MIT.EDU].770028.860101.ALAN>
Ugh, bletch! Yuck! I just had to go and shuffle the memory layout in
(*gag*) PEEK because the HOSTS3 table has grown to be so huge that PEEK has
trouble keeping both it and ITS mapped in at the same time. (Gumby, this
is what caused that PEEK bug you discovered the other day.) If HOSTS3 gets
to be another -two- ITS blocks long, it is going to take some serious
thinking to keep PEEK working. Presumably there are other programs out
there that, like PEEK, simply were not designed with a 73 block host table
in mind.
I notice that the current host table contains shitloads of totally
ridiculous host names. A particularly bad example is AI which has the
names:
AI.AI.MIT.EDU
AI
AI.MIT.EDU
MIT-AI
MIT-AI.ARPA
MIT-AI.MIT.EDU
MIT-MITAI
MIT-MITAI.ARPA
MIT-MITAI.MIT.EDU
MITAI
MITAI.AI.MIT.EDU
MITAI.MIT.EDU
Might I suggest eliminating any name that starts with "MIT-" and ends
".MIT.EDU"? (Also in the case of AI, I think we can do without the nicname
"MITAI" (without hyphen) and its derivatives.)

Date: Tue, 24 Dec 85 00:58:14 EST
From: "Pandora B. Berman" <CENT@MC.LCS.MIT.EDU>
Subject: total=out= inf.
To: BUG-PEEK@MC.LCS.MIT.EDU
Message-ID: <[MC.LCS.MIT.EDU].765406.851224.CENT>
there's a problem between the Normal mode of P and any other, at least, any
other i usually use. when i start a PEEK, the Total= and Out= figures at the
screen top are small and fit in their alloted spaces. however, if i switch
to some other display (look at some particular job or channel, or the help
display) and then back to N, these two numbers balloon to 10 or 12 or so
figures long, and the Status column info goes all to hell.

Date: Thu, 19 Dec 85 21:31:35 EST
From: David Vinayak Wallace <GUMBY@MC.LCS.MIT.EDU>
Subject: weird display
To: BUG-PEEK@MC.LCS.MIT.EDU
Message-ID: <[MC.LCS.MIT.EDU].761687.851219.GUMBY>
Well MBECK was right; I finally was able to duplicate his bug. It's
tricky; only seems ta appear if started w/jcl. The symptom is the
runnable total and out columns have about 18 digits each, which
suggest the uuo which prints them out is somehow bashed. Trumm
appears to have a reasonable value in it.
I dunno.

Date: Thu, 19 Dec 85 18:04:06 EST
From: David Vinayak Wallace <GUMBY@MC.LCS.MIT.EDU>
Subject: Strange-looking numbers
To: MBECK@MC.LCS.MIT.EDU
cc: BUG-PEEK@MC.LCS.MIT.EDU
In-reply-to: Msg of Wed 18 Dec 85 21:43:27 EST from Mark E. Becker <MBECK at MC.LCS.MIT.EDU>
Message-ID: <[MC.LCS.MIT.EDU].761316.851219.GUMBY>
Date: Wed, 18 Dec 85 21:43:27 EST
From: Mark E. Becker <MBECK at MC.LCS.MIT.EDU>
Was using Peek 593 when noticed some rather strange-looking numbers
for "Runnable Total" and "Out".
What do you mean by "strange-looking numbers?" I can't duplicate this.

Date: Wed, 18 Dec 85 21:43:27 EST
From: "Mark E. Becker" <MBECK@MC.LCS.MIT.EDU>
To: BUG-PEEK@MC.LCS.MIT.EDU
cc: MBECK@MC.LCS.MIT.EDU
Message-ID: <[MC.LCS.MIT.EDU].760171.851218.MBECK>
Was using Peek 593 when noticed some rather strange-looking numbers
for "Runnable Total" and "Out". This was after the first display had
been output... The JCL was :P 57J 8Z .
Regards,
Mark

Date: Fri, 13 Dec 85 16:02:11 EST
From: "Christopher C. Stacy" <CSTACY@MIT-MC.ARPA>
Subject: [macrakis: Supdup lossage]
To: BUG-PEEK@MIT-MC.ARPA
Message-ID: <[MIT-MC.ARPA].753036.851213.CSTACY>
Date: Thu, 5 Dec 85 00:08:11 EST
From: macrakis at harvard.HARVARD.EDU (Stavros Macrakis)
To: bug-supdup at mit-mc.arpa, ddl at harvard.HARVARD.EDU
Re: Supdup lossage
In supdup'ing from Harvard (Unix 4.3) to Mit-MC, everything seems to work
perfectly until I try to run Peek. In particular, if I type ahead the
Peek command (e.g. `P^KJ'), it hangs up. The only way I seem to be able
to get out of this state is to quit (^^q) the supdup and reconnect.
Actually, now that I do the test, it appears that even without typeahead,
Peek's interrupt characters (commands) never get through. -- p^K ... wait
for end of display (space worrks fine at end of screen) ... q [hangs up].
The input characters do seem to be buffered up somewhere, because when
you type ^Z when it's hung up and before you quit, when you reconnect,
the peek has been ^Z'd.

Date: Mon, 2 Dec 85 17:58:51 EST
From: "J. Noel Chiappa" <JNC@MIT-MC.ARPA>
Subject: A display
To: BUG-PEEK@MIT-MC.ARPA
cc: JNC@MIT-MC.ARPA
Message-ID: <[MIT-MC.ARPA].738887.851202.JNC>
Any change of moving the STY list to a separate display?
These days that list is pretty long, and over a slow network
link it's annoying to have to plought through the whole thing
to see the TCP connection list.

Date: Tue, 6 Aug 85 06:26:44 EDT
From: Ken Harrenstien <KLH@MIT-MC.ARPA>
Subject: PEEK "bug" fixed
To: CSTACY@MIT-MC.ARPA
cc: BUG-PEEK@MIT-MC.ARPA, BUG-CRTSTY@MIT-MC.ARPA
Message-ID: <[MIT-MC.ARPA].602153.850806.KLH>
Date: Thu, 9 May 85 00:12:55 EST
From: Christopher C. Stacy <CSTACY@MIT-MC>
In-reply-to: Msg of Wed 8 May 85 06:33:43 EST from Ken Harrenstien <KLH>
I still can't reproduce anything close to the the behaviour you
described.
Date: Wed, 8 May 85 06:33:43 EST
From: Ken Harrenstien <KLH>
To: CSTACY
cc: KLH, BUG-PEEK
Here is how to tickle the PEEK bug. Connect to MC from somewhere
else on the Arpanet. Say ":P A". PEEK will clear the screen, and
then do nothing.
OK, I found the problem. It turns out to be in CRTSTY when acting as
a SUPDUP user program (CTN). By using IPLIST (like using a howitzer on a
housefly) I found that PEEK was sending %TDORS, and ITS was waiting
for the remote site to respond with the appropriate Intelligent Terminal
Protocol sequence (^\ ^P <V> <H>, which reports the cursor position)
before allowing PEEK to do anything else! Since CTN was not responding
with that sequence until the user typed some input (due to a spazz
by whoever wrote the %TDORS handling code), the effect was that whenever
any ITS program did a .RESET TYOC, all output would stop until the user
became impatient... as it happens, PEEK does such a reset every time
any character is typed at it.
I have merged the fix into the SYSENG source of CRTSTY.

Date: Fri, 10 May 85 17:58:29 EST
From: Christopher C. Stacy <CSTACY@MIT-MC>
To: KLH@MIT-MC
cc: BUG-PEEK@MIT-MC
In-reply-to: Msg of Thu 9 May 85 20:49:01 EST from Ken Harrenstien <KLH>
Message-ID: <[MIT-MC].495962.850510.CSTACY>
Date: Thu, 9 May 85 20:49:01 EST
From: Ken Harrenstien <KLH>
To: BUG-PEEK
This time I said :P A and nothing whatsoever hapened.
I ctl-Z'd and found I was at loc 22001, executing an .IOT 14,15
with the value "A in 15. I thought the problem might be TCP related
but this seems more unlikely. CSTACY, maybe you should try
logging in as something else?
Something is obviously screwing you, but I still can't duplicate it.
The previous tests were conducted under a variety of UNAMEs.
Here are the gory details of my latest attempt.
I logged into MC over 1200 baud dialup, and did :TN NIC and logged in
over there. I ran @TELNET MC and NIC connected me to MC where I
received a DDT and did not log in (having made arrangements with PWORD
for this earlier). I typed ":P A". I got the same results as
yesterday -- PEEK worked.
I flushed all my connections back to MC and typed ":TN NIC". I logged
into NIC and did "@TELNET MC". NIC connected me to MC and I logged in
as a normal user without any init file. I typed ":P A", and PEEK
worked. I typed "J" and it worked; I used "X" to gun myself down.
Maybe somehow the problem is terminal-type specific.
Does it happen to you if you don't run TCTYP?

Date: Thu, 9 May 85 20:49:01 EST
From: Ken Harrenstien <KLH@MIT-MC>
To: BUG-PEEK@MIT-MC
Message-ID: <[MIT-MC].494254.850509.KLH>
This time I said :P A and nothing whatsoever hapened.
I ctl-Z'd and found I was at loc 22001, executing an .IOT 14,15
with the value "A in 15. I thought the problem might be TCP related
but this seems more unlikely. CSTACY, maybe you should try
logging in as something else?

Date: Thu, 9 May 85 00:12:55 EST
From: Christopher C. Stacy <CSTACY@MIT-MC>
Subject: can't reproduce bug
To: KLH@MIT-MC
cc: BUG-PEEK@MIT-MC
In-reply-to: Msg of Wed 8 May 85 06:33:43 EST from Ken Harrenstien <KLH>
Message-ID: <[MIT-MC].492640.850509.CSTACY>
I still can't reproduce anything close to the the behaviour you
described.
Date: Wed, 8 May 85 06:33:43 EST
From: Ken Harrenstien <KLH>
To: CSTACY
cc: KLH, BUG-PEEK
Here is how to tickle the PEEK bug. Connect to MC from somewhere
else on the Arpanet. Say ":P A". PEEK will clear the screen, and
then do nothing.
I did some tests from various net hosts (using TELNET to get to the
remote site, and their TELNET to get to MC.) I invoked PEEK with
":PEEK", and ":P A", and excersized the A,J,N,Z, and X commands.
I tried several of these tests 2 or 3 times.
1. PEEK works normally over LispM or MINITS Chaosnet SUPDUP.
2. Over a MINITS Chaosnet TELNET connection, PEEK works normally,
except that it does not update the display automatically.
PEEK starts up, displays whatever it is supposed to *twice*,
and then just sits there, and you have to type another command,
or use SPACE or Z. I think it is supposed to be a feature that
there is a long (infinite?) initial sleep time when the
console is a printing terminal. All the commands seem to work.
It is a bug that on a printing terminal it does the initial
display twice.
3. I tested PEEK TNing to MC from SCORE, being a Datamedia
terminal. PEEK worked normally.
4. From BRL-BMD as a printing terminal, the sucky TCP connection
was almost unbearably slow, but PEEK seemed to behave the same
as on a MINITS Chaos TELNET connection.
5. From SRI-NIC as a printing terminal, PEEK seemed to behave the
same as on a MINITS Chaos TELNET connection. BTW, the thing
which it echoes at ":P A" is an "A" (folowed by the correct
display.)
6. As a final test, I came in from SRI-NIC and :TCTYP DM2500.
I typed ":P A". It echoed "A", paused for 1 second, and
gave me one normal ARPAnet display. After 20 seconds it
updated it. I typed "J", and it did. I used the "X"
command to gun myself down.
Beats me to death.

Date: Wed, 8 May 85 06:33:43 EST
From: Ken Harrenstien <KLH@MIT-MC>
To: CSTACY@MIT-MC
cc: KLH@MIT-MC, BUG-PEEK@MIT-MC
Message-ID: <[MIT-MC].491306.850508.KLH>
Here is how to tickle the PEEK bug. Connect to MC from somewhere
else on the Arpanet. Say ":P A". PEEK will clear the screen, and
then do nothing. That's right, nothing. Eventually you will get
impatient, and type a space. Bang! Suddenly there is a flash
of something echoed too quickly to see (^A?), and the PEEK "A" display
appears. As far as X and Y go, nothing will happen. I don't know if
all this is something net-specific, but if it is it should be flushed.
Possibly the JCL handling is messed up?
It seems to be solidly repeatable.

Date: Tue, 7 May 85 19:19:52 EST
From: Christopher C. Stacy <CSTACY@MIT-MC>
To: KLH@MIT-MC
cc: BUG-PEEK@MIT-MC
In-reply-to: Msg of Tue 7 May 85 17:33:21 EST from Ken Harrenstien <KLH>
Message-ID: <[MIT-MC].490642.850507.CSTACY>
When I run PEEK, it automatically displays things for me. The X and Y
commands work fine for me. Glancing at a source compare of the latest
PEEK with the version from 1983, the only changes I see are where
people have installed some meter modes for some network stuff.
However, there is a very old bug which bites me sometimes, where PEEK
apparently does not turn its interrupts on or something. When it gets
to a **MORE** break, it hangs (and the prompt is wrong so the more
handler has clearly not gone off.) I think that in this mode, no
characters typed do anything. Somebody should track this down
someday, but it is sporadic and has been happenning for years.
Are you thinking of this latter bug, or are you claiming that PEEK is
completely broken? It normally works fine for me many times each day.

Date: Tue, 7 May 85 17:33:21 EST
From: Ken Harrenstien <KLH@MIT-MC>
To: BUG-PEEK@MIT-MC
Message-ID: <[MIT-MC].490459.850507.KLH>
For a few months now I've noticed that PEEK has been broken. I
wasn't quite sure whether to believe it at first, but now I'm
relatively sure. The problem is that PEEK does not go ahead and
show things on its own -- you hae to type a space or something to force
output, it seems. For certain commands like X and Y it simply does
not work or do anything. Now, I grant this may hae happened because of
someone's idea of "new improved featurefulness" but I find it annoying.

Date: 26 January 1985 02:39-EST
From: Christopher C. Stacy <CSTACY @ MIT-MC>
To: BUG-FINGER @ MIT-MC, BUG-PEEK @ MIT-MC
cc: ALAN @ MIT-MC
Does not mention when system is being debugged unless users are not allowed on.

Date: 13 January 1985 01:37-EST
From: Christopher C. Stacy <CSTACY @ MIT-MC>
To: HDT @ MIT-MC
cc: BUG-PEEK @ MIT-MC
First, you could just re-own the wholine job with :JOB WHOLIN
and then :KILL it, rather than using PEEK. I don't know why
PEEK behaves the way you describe, but someone can look at it
someday I guess.

Date: 13 January 1985 01:30-EST
From: Howard D. Trachtman <HDT @ MIT-MC>
To: BUG-PEEK @ MIT-MC
cc: HDT @ MIT-MC
I had a detached tree which I was trying to kill in peek.
I couldn't kill it. Basically I just wanted to get rid of
my wholin which was disowned and screwing me. number, etg. 32Y
offered to kill my entire tree (two hactr*'s) and I thought this
was a bug. I got rid of some useless jobs so that if it actually
went and killed the tree off I could live also. But they still wouldn't
got away. 5 minutes later, the system console printed that
it killed my hour old detached job. If this is at all interesting,
I can provide some more info, but I don't want to bore you all otherwise.

Date: 22 December 1984 04:32-EST
From: Pandora B. Berman <CENT @ MIT-MC>
Subject: PEEK down warning broken
To: BUG-PEEK @ MIT-MC
cc: BUG-FOO @ MIT-MC
P pretends it is warning you that the system is being taken down. however,
the warning code is fukt. the warning (in the J display, at least) looks like
System going down in <timeA> (<timeB>)
where <timeA> is supposedly the remaining increment until the actual <timeB>
occurs. you'd expect that <timeB> would remain constant and <timeA> would
decrement to 0. what really happens, though, is <timeA> remains constant
(and doesn't jibe with the down warnings produced at top level), and <timeB>
increments to fit <timeA>!! please fix.

Date: 25 August 1984 16:16-EDT
From: David A. Moon <MOON @ MIT-MC>
To: BUG-PEEK @ MIT-MC
Needs to be fixed to work when the amount of free memory in the header
runs into four digits (!!)

Date: 18 March 1984 21:40-EST
From: Jon Solomon <JSOL @ MIT-MC>
To: BUG-PEEK @ MIT-MC
Sigh, every time I peek at the comsat stats file it gives me
an :$MPV not handled$ error and punts. This time after perhaps
two screenfuls. I'm on a vt100 running in vt52 mode, and I have
had this happen on vt100s running vt100 mode, and H19s.
--jsol

Date: 15 November 1983 19:04 EST
From: Alan Bawden <ALAN @ MIT-MC>
Subject: E
To: BUG-PEEK @ MIT-MC
Is there documentation anywhere for the "E" command?

Date: 28 October 1983 06:56 EDT
From: David Vinayak Wallace <GUMBY @ MIT-MC>
To: BUG-PEEK @ MIT-MC
How come the down time message is so fukt?

Date: 21 October 1983 16:47 EDT
From: Jeffrey P. Golden <JPG @ MIT-MC>
To: BUG-PEEK @ MIT-MC
Someone should fix the "System going down in" message in PEEK.
The times it gives are preposterous.

Date: 19 July 1983 03:10 EDT
From: Jeffrey P. Golden <JPG @ MIT-MC>
To: BUG-PEEK @ MIT-MC
When I use LOCK to take the system down, it used to say
'System going down in 15:00' or whatever.
Now it says:
'System going down in 3:06:21:21 ( 3:09:28:44)'
These huge mysterious numbers are not very helpful.

Date: 9 July 1983 06:46 EDT
From: Christopher C. Stacy <CSTACY @ MIT-MC>
Subject: [ELLEN: forwarded]
To: BUG-PEEK @ MIT-MC
Date: 07/08/83 03:46:40
From: ELLEN
To: CSTACY
cc: ELLEN
wierd Peek...
Peek seems not only to not allow you to type a space to redisplay
during an "O", but it also sometimes gets into a state where a space
will not do anything, no how... I can identify this state because
the "More" at the bottom will be
**More**
instead of
--More--
I regret that at this instant I cannot tell you how to produce this
state. But I suspect it might be related to hopping in and out of
PEEK repeatedly... as I sometimes do... then one time I suddenly
notice this wierdness...
I consider this highly wierd, and am sending this to you, to forward
as you please, since I believe it was you who last modified PEEK.
Cheers.

gsb@MIT-ML (Sent by TAR@MIT-ML) 05/08/83 00:56:23
To: (BUG PEEK) at MIT-ML
If i type ahead stuff at peek (like i do
peek
jjjjjjjjjjjjjjjjjj
)
then i can make it use **MORE** rather than --More--.
This is especially amusing because in **MORE** in peek, the two things
which do not work are space and rubout.


20
doc/system/-read-.-this- Normal file
View File

@@ -0,0 +1,20 @@
This directory contains the files which are assembled to produce the system, ITS.
ITS Main part of system
IMP ARPA Network
ITSDEV Miscellaneous devices
ITSDIS E&S display
ITSMSP Message slurper
MTAPE Macrotape
UTAPE Microtape
TS3TTY Terminal service
TTYTYP Terminal type definitions
WHOVAR Wholine variables in TV-11
TV TV service (runs in 11)
DISK Disk service and file system
FSDEFS Machine-independent file system definitions
DC10 Systems Concepts DC10 disk control definitions
RP10 DEC RP10 disk control definitions
RH10 DEC RH10 disk control definitions
TIME Real (wall clock) time routines

89
doc/xfont/kst.format Normal file
View File

@@ -0,0 +1,89 @@
M.I.T. FONT FILES: THE KST FORMAT
Each KST font file (usually has "KST" as its second filename)
has the following general format, regardless of type style or size:
a two-word header ("word" means 36-bit PDP-10 word)
an arbitrary number of character blocks (up to 128.), of a
variable number of words each
an end-of-file flag, the number -1 (77777777777777777777 octal)
(however, there have always been two such flags at the end
of all KST font files, and should continue that way).
THE HEADER
The first word is the "KSTID", which is ignored by all programs
at M.I.T. It is normally zero. The second word contains the Column
Position Adjust (CPA), which is 0 for all of our files, the baseline
(BL) of the font, and the height (HT) of the font. Arrangment is as
0 8 9 17 18 35
------------------------------------------
| CPA | BL | HT |
------------------------------------------
The height is the total number of scan lines required by any character
in the font, and is the number of scan lines contained in each
character block which follows. The basseline gives the number of scan
lines ABOVE the baseline for every character in the font.
THE CHARACTER BLOCK
Each character block has a three-word header. The first word is a
1, which serves as a convenient separator between character blocks.
[This is because only the high 32. bits of each raster word are used,
with the low 4 being zero.] The second word contains the left kern
(LK) for the character, and the Ascii code:
0 17 18 35
------------------------------------------
| LK | Ascii char code |
------------------------------------------
The third word contains the raster width (RW) for the character, and
its character width (CW):
0 17 18 35
------------------------------------------
| RW | CW |
------------------------------------------
The left kern gives the number of units (XGP points) to start the
actual raster display to the LEFT of the current character position.
A negative number means to start the raster to the right of the
current position abs(LK) units. The raster width gives the number
of bits which occur in each line of the following raster array for
the character. The character width is the number of units to advance
the current position after the character is printed. NOTE: CW is not
measured from where the raster actually is placed, but from the
current character position; that is, the LK is totally ignored when
advancing the current position. This means that, in general,
adjusting the left kern of a character requires changing its CW as
well.
After this three-word header comes the actual raster display.
There are HT lines, each of RW bits. The bits are grouped into 8-bit
bytes, with four bytes per PDP-10 word. The low 4 bits of each word
in the raster display MUST be zero. The bytes in each word correspond
left to right with bits from the raster matrix (that is, bytes are
used left to right in printing each line of the character). However,
within each byte the bits are REVERSED, so are used right to left
within the byte. This is an artifact of the way the bytes are shipped
to the PDP-11 running the XGP. If RW is not a multiple of 8 bits,
the remaining bits in the last byte of each scan line are zero. Each
scan line begins on a new 8-bit byte. After the last scan line,
remaining bytes in the word are zero.
The next word after the last scan line will be either a 1,
signalling the next character block, or -1 for the end-of-file
(followed by another -1).
NOTES
* The order of the character blocks within the file is not significant
(that is, they don't have to be in "alphabetical" order).
* The low order bits in each raster display word must be zero; unused
bits in scan line raster must be zero.
* Not all 128. Ascii characters need to be defined in the file.
* Each raster display must have HT lines, even if those below the
baseline are zero (unlike the AST files in this respect).