From KLOTZ at MIT-MC  Tue Nov 22 14:25:04 2016
From: KLOTZ at MIT-MC (Leigh L. Klotz)
Date: February 18 1983  22:05-EST
Subject: No subject
In-Reply-To: Msg of 18 Feb 1983 20:34 EST from J. Eliot B. Moss <EBM at MIT-MC>
Message-ID: <mailman.99.1479821105.4695.its@nocrew.org>

Gregor and I noticed this from cadr-20, which was a good site.  Maybe
someone broke the password system recently?
Leigh.

From KLOTZ at MIT-MC  Tue Nov 22 14:25:04 2016
From: KLOTZ at MIT-MC (Leigh L. Klotz)
Date: January 23 1983  22:51-EST
Subject: con't...
In-Reply-To: The message of 23 Jan 1983 21:45 EST from Alan Bawden <ALAN>
Message-ID: <mailman.130.1479821105.4695.its@nocrew.org>

Happy birthday...

From MOON  Tue Nov 22 14:25:04 2016
From: MOON (MOON)
Date: January 16 1983  16:28-EST
Subject: not exactly about Supdup windows on color screen
In-Reply-To: The message of 16 Jan 1983 12:35-EST from David C. Plummer <DCP at SCRC-TENEX>
Message-ID: <mailman.138.1479821105.4695.its@nocrew.org>

What ITS expects is for typing a character in the last column of a line to
leave the cursor in that column, and for line feeding off the last line
of the screen to scroll by the number of lines specified in the terminal
characteristics (ITS won't use this unless the user says to use scroll
mode).

Thus the -only- way to move the cursor from one line to the next is via
line feed (or %TDCRL or cursor-positioning).  The terminal is required
not to have any "intelligent" features where it secretly moves the cursor.
I assume the Lisp machine Supdup is blowing it.

From PGS  Tue Nov 22 14:25:04 2016
From: PGS (PGS)
Date: November 20 1982  18:45-EST
Subject: MASTER mode screwing up TTY handling, but good!
In-Reply-To: The message of 20 Nov 1982  02:42-EST from Ed Schwalenberg <ED at MIT-MC>
Message-ID: <mailman.197.1479821106.4695.its@nocrew.org>

I don't know, but when I tried MASTER mode once, it didn't look to me like
TTY handling was screwed.  It looked like the DDT just wasn't getting much of
any CPU time.

From PGS  Tue Nov 22 14:25:04 2016
From: PGS (PGS)
Date: October 13 1982  05:31-EDT
Subject: No subject
Message-ID: <mailman.236.1479821107.4695.its@nocrew.org>

AI is being backed up these days, and its disks seem fairly stable.  The
processor hardware is not currently flaking out, although we have no idea how
long that will last.  When I connect to it, often in the daytime, I am usually
the only user using it.  If we do indeed reconnect AI to the Chaosnet, then
it'll make a pretty good mail computer, so I see no reason not to leave
BUG-RANDOM-PROGRAM on it.

Something we should take note of here is that Eric Ostrom, in his capacity as
AI Lab Facilities Coordinator or some fancy title, has tracked down a KL Model
A CPU (a la MC) that is being sold for $7500, supposedly in working order.  The
idea is to provide a machine of MC's power to AI lab members who prefer ITS to
Twenex.  If we bought one it would probably go where AI is now, both physically
and spiritually (including network ports).  Extra space would need to be
allotted for memory; presumably 921 (Marty's office) would go away.

Everyone who would like to see AI have a KL Model A running ITS should send a
message to the effect to Eric at ee (not at OZ, where he doesn't read his mail),
and CC it to PHW.  Something strong along the lines of "I understand you're
considering getting a KL to run ITS, well, do," is probably appropriate.
-------


From bogus@does.not.exist.com  Tue Nov 22 14:25:04 2016
From: bogus@does.not.exist.com ()
Date: Tue, 22 Nov 2016 13:25:04 -0000
Subject: No subject
Message-ID: <mailman.255.1479821108.4695.its@nocrew.org>

dcp, alan at MIT-MC (Sent by DCP at MIT-MC) 09/25/82 03:56:43 Re:  What is the value of L??
To: (BUG ITS) at MIT-MC

    On MC ITS 1278, right now!!

    sys^K
    l= 134007

    What!!!!  This causes :VV to break, but that's a minor detail at
    this point.  I loaded @ ITS and @ NITS into a job and L was 1000
    as expected.  I guess somebody decided to take a walk through the
    in core symbol table.  LUBLK is still 1000 (thank god, otherwise
    PEEK would also be broken). 

    (On ML and DM it's 742, and AI is 745.)

Fixed in the running system (without knowing (or finding) where
the symbol table is in memory).

From GUMBYatMIT-MC  Tue Nov 22 14:25:04 2016
From: GUMBYatMIT-MC (David Vinayak Wallace)
Date: September 22 1982  23:21-EDT (Wednesday)
Subject: Whither XGP?
Message-ID: <mailman.259.1479821108.4695.its@nocrew.org>

does the versacrock support KST fonts? I know it can't support
tj6-style XGP files. Plummer said he would try to do it if he could
find documentation on XGP-format files. i tried to find this a couple
of years ago when I wanted to generate them with the lisp machine, but
nobody knew where any sort of real documentation was. The best I could
do was discuss scan format with RWK.
With respect to "state of the art" ... are there really any equivalent
printers (i.e. 200 dots to the inch)?
-------


From PGS  Tue Nov 22 14:25:04 2016
From: PGS (PGS)
Date: September 22 1982  15:39-EDT
Subject: Whither XGP?
Message-ID: <mailman.260.1479821108.4695.its@nocrew.org>

Frankly, now that we have the Versatek on the seventh floor working, and there
is the possibility of getting Canon laser printers, I think we should throw the
XGP and associated hardware out, or give it away, or whatever.  Re-interfacing
it would take more people-hours than we can afford these days, and if we were
going to spend them anyway, we might as well get something closer to
state-of-the-art out of it.
-------


From KLOTZ  Tue Nov 22 14:25:04 2016
From: KLOTZ (KLOTZ)
Date: September 22 1982  14:10-EDT
Subject: Whither XGP?
Message-ID: <mailman.261.1479821108.4695.its@nocrew.org>

I suggest we give the XGP to Concourse, if we are allowed to.
-------


From DLW  Tue Nov 22 14:25:04 2016
From: DLW (DLW)
Date: September 22 1982  07:42-EDT
Subject: Whither XGP?
Message-ID: <mailman.263.1479821108.4695.its@nocrew.org>

ML talks to the Chaosnet directly, with a PDP-10 Chaosnet interface.
There are no PDP-11s on ML.

The XGP talks to its through the 10/11 interface, which is a broken
and one-of-a-kind beast.  It would be a great, great deal of work
to interface the XGP in any other fashion.
-------


From GUMBYatMIT-MC  Tue Nov 22 14:25:04 2016
From: GUMBYatMIT-MC (David Vinayak Wallace)
Date: September 21 1982  18:16-EDT (Tuesday)
Subject: Whither XGP?
Message-ID: <mailman.264.1479821108.4695.its@nocrew.org>

How does ML talk to the Chaosnet? Does it use a 10/11 interface?
A number of people have been screwed (including everybody in 6.001)
because the XGP vanished. Would it be possible to put the XGP on
either ML or MC, at least until large fixed-width fonts exist for
either the dover or whatever new hardware we get?
-------


From cent  Tue Nov 22 14:25:04 2016
From: cent (cent)
Date: August 28 1982  02:40-EDT
Subject: ai problems & bughalts
Message-ID: <mailman.282.1479821108.4695.its@nocrew.org>

chris, leaving yellow-pad notes on the ai system console is better than
nothing as a way to indicate what its particular brokenness is, but
ignores the problem that the note might fall off. please record the 
brokenness state in the ai system logbook, so other people will know
what's going on (also for a semi-permanent record -- lossage like the
disk breaking needs to become part of general memory). thx.
-------

From PGS  Tue Nov 22 14:25:04 2016
From: PGS (PGS)
Date: August 23 1982  08:52-EDT
Subject: H19 emulators, and lossage and ANSI mode
Message-ID: <mailman.284.1479821108.4695.its@nocrew.org>

In implementing multiple insert/delete line for H19's, I used ANSI mode because
it was the only way to get it (as I imagine you know if you wrote an emulator).
This is what CRTSTY does.  Looks to me like there are two possibilities; a new
terminal type could be implemented (call it HDS or whatever) that would output
only HDS codes, or a bit could be defined to say don't do multiple operations.
I guess I'll do one of them when I get back.  If anyone thinks one way is more
tasteful than the other, let me know.  I lean towards a separate type because
it's easier to do :TCTYP HDS than :TCTYP H19 NO MULTIPLE (or worse yet, specify
the bits).
-------

From PGS  Tue Nov 22 14:25:04 2016
From: PGS (PGS)
Date: August 14 1982  14:47-EDT
Subject: crufty lossage (of characters, perhaps)
Message-ID: <mailman.289.1479821108.4695.its@nocrew.org>

    Date: Friday, 13 August 1982  02:03-EDT
    From: David A. Moon <MOON>
    Re:   crufty lossage (of characters, perhaps)

    :TCTYP ? will tell you about the PADDED option, which is probably what you need.

Actually, I was losing completely, not knowing about needing to have the local
end in image mode.  But I became unwedged eventually.
-------


From PGS  Tue Nov 22 14:25:04 2016
From: PGS (PGS)
Date: August 10 1982  20:48-EDT
Subject: No subject
Message-ID: <mailman.292.1479821108.4695.its@nocrew.org>

    RZ at MIT-MC 08/10/82 16:40:36
    I'm using one of the old ann arbors (it doesn't even have n-key rollover).
    With the new ITS there are several problems which I can't really explain.
    First, inside mail I am unable to type a rubout or C-Z.  A rubout seems to
    turn into a C-W since the previous word always gets deleted.  C-Z's don't
    do anything.  THis is not true when talking to DDT or EMACS.  Lock seems to
    idicate that that the right codes are being sent.

    Second, when I logout the DDT seems to revert to the same mode that MAIL
    and SEND are in.  As a consequence, I can't log back in.

Since most of the Ann Arbors at the lab are new, and have meta keys, Ann Arbors
are initialized with +%TPMTA.  Older Ann Arbors, like yours, don't have meta
keys.  Looks like ^Z and rubout are being read as meta-^Z and meta-rubout.
If you do
:TCTYP AAA -%TPMTA
you should win.
-------

From TERZOP  Tue Nov 22 14:25:04 2016
From: TERZOP (TERZOP)
Date: August 1 1982  06:07-EDT
Subject: AI's demise?   
Message-ID: <mailman.299.1479821108.4695.its@nocrew.org>


 Date: Saturday, 31 July 1982  00:24-EDT
    From: KLOTZ at MIT-AI
    To:   bug-its at ai
    cc:   vision at ai
    Re:   AI's demise?

    What is going to happen to the XGP when AI finally quits working?

    Is the vision group going to get something to use for their lispm plots?

    Leigh.


Hopefully SOMEONE will get a Cannon lazer printer or the equivalent,
at which time a celebration for all can be held in the middle of Tech
Square, the highlight of which will be the burial of the XGP ten feet
under.
-------

From KLOTZ  Tue Nov 22 14:25:04 2016
From: KLOTZ (KLOTZ)
Date: July 31 1982  00:24-EDT
Subject: AI's demise?
Message-ID: <mailman.301.1479821108.4695.its@nocrew.org>

What is going to happen to the XGP when AI finally quits working?

Is the vision group going to get something to use for their lispm plots?

Leigh.
-------

From GREN  Tue Nov 22 14:25:04 2016
From: GREN (GREN)
Date: July 14 1982  00:45-EDT
Subject: [MP: ITS question]
Message-ID: <mailman.311.1479821109.4695.its@nocrew.org>

Date: July 10 1982  21:37-EDT
From: Mark Plotnick <MP at MIT-XX>
To:   gren at MIT-MC
Re:   ITS question

I hear you're an ITS expert.  Could you tell me what this piece
of code attempts to do?  My intuition tell me that it's trying
to figure out what tty number your console tty is at, but there
must be easier ways to do this.
	  .OPEN CH,[SIXBIT /  #TTY/]
           .VALUE
          .SUSET [<.RIOC+CH>,,T]
          LDB N,[220600,,T]

	Mark

I thought that bits 3.1-3.6 were the error code, set on non-skip
.CALLs.  What is N getting?

			--gren
-------

From RICHatMIT-AI  Tue Nov 22 14:25:04 2016
From: RICHatMIT-AI (Charles Rich)
Date: July 12 1982  16:02-EDT (Monday)
Subject: No subject
Message-ID: <mailman.312.1479821109.4695.its@nocrew.org>

How do I get supdup (:OZ) on AI to use SAIL characters on
AI TV's?  (note: I have done :tctype sail before starting
the supdup).
-------

From bogus@does.not.exist.com  Tue Nov 22 14:25:04 2016
From: bogus@does.not.exist.com ()
Date: Tue, 22 Nov 2016 13:25:04 -0000
Subject: No subject
Message-ID: <mailman.329.1479821109.4695.its@nocrew.org>

MOON5 at MIT-MC 06/16/82 15:49:09 Re: vandalism
To: (BUG ITS) at MIT-MC
I removed the garbage that someone not logged-in on some other
ITS edited into the MC:SYS;SYSTEM MAIL.  This is the second time
today I believe.

From KLOTZ  Tue Nov 22 14:25:04 2016
From: KLOTZ (KLOTZ)
Date: May 7 1982  18:15-EDT
Subject: ITS Message Header on net.
Message-ID: <mailman.354.1479821109.4695.its@nocrew.org>

I received the following message at BBNG.  It has an ITS-style
header.

I believe the local twenex inserted the first two lines.

Mail-from: MIT-AI
Received-Date: 7-May-82 0244-EDT
Date: 07 May 1982 00:00
From: PGS at MIT-AI
To: klotz at BBNG
Does this stuff work?  (I mean a qsend from AI).
  <rest of body omitted for brevity>
^_

From MOON  Tue Nov 22 14:25:04 2016
From: MOON (MOON)
Date: March 22 1982  02:25-EST
Subject: No subject
Message-ID: <mailman.399.1479821110.4695.its@nocrew.org>

    Date: 18 March 1982 16:11-EST
    From: David C. Plummer <DCP at MIT-MC>
    To: BUG-ITS at MIT-MC, BUG-SUPDUP at MIT-MC, rsl at MIT-MULTICS

    Suppose I have an AAA terminal that is capable of generating a
    META bit.  Suppose further that it is connected to a terminal
    concentrator that will talk SUPDUP to ITS.  Since it is SUPDUP, I
    am supposed to use the intelligent terminal protocol.  Therefore,
    the TTYOPT bits I think I should send include
	    %TOFCI  OFF  (can't do full character input)
	    %TPMTA  ON   (does have a hardware META bit)
	    %TPCBS  ON   (using ITP)

%TPMTA means that bit 7 is the meta bit.
You don't have to use ITP to be Supdup, but if you do use ITP you
have to send the 12-bit character set, not the 8-bit character set,
and thus you can't use %TPMTA.
Probably you want to have %TOFCI off but still send characters with
the %TXMTA bit.

    Now, sombody comes along and types META-A.  This has a code of
    301 (200+101).  Now as I understand it, ITP is only a mechanism
    for transmitting bytes, and does not assume the 5 bucky bits that
    are part of %TOFCI.  
No.  ITS is a mechanism for inputting the internal ITS 12-bit character
set "directly" rather than going through the conversion from 8-bit
"ascii" characters.

			 Therefore when it gets reassembled on ITS,
    it gets assembled as 301.  This is fine until the TYI normalizer
    gets to it, and says, "Oh, this is %TXCTL+A" and converts it into
    a ^A.  Well, does that mean I should change a 301 into a 1101
    (%TXMTA+A) before sending it?  NOW, how does EMACS handle this?
    If I connected by a modem and sent META-A, would ITS convert this
    from 301 into 1101 when it puts it in the input buffer?  What is
    the consistent model?  How does EMACS deal with this?  and Should
    the TYI 7-bit normalizer look at %TOFCI before it goes around
    looking for TOP, CONTROL and META bits? 
EMACS doesn't handle any of this.  It sees only the 12-bit character set.

From Guy.Steele  Tue Nov 22 14:25:04 2016
From: Guy.Steele (Guy.Steele)
Date: 4 March 1982 1604-EST (Thursday)
Subject: hardware/microcode mod
In-Reply-To: Christopher C. Stacy's message of 4 Mar 82 02:06-EST
Message-ID: <mailman.414.1479821111.4695.its@nocrew.org>

I assume that the new instruction JFFL (Jump if Find Free Lispmachine)
is equivalent to JUMP (Do Not Jump)!
--Guy

From bogus@does.not.exist.com  Tue Nov 22 14:25:04 2016
From: bogus@does.not.exist.com ()
Date: Tue, 22 Nov 2016 13:25:04 -0000
Subject: No subject
Message-ID: <mailman.417.1479821111.4695.its@nocrew.org>

MOON5 at MIT-MC 03/03/82 02:43:26 Re: Hitting CALL on one TV hangs all of them
To: cstacy at MIT-AI
CC: (BUG ITS) at MIT-MC
Upon reflection, I think you are probably being faked out by the fact
that when the system is brought up (on AI) the system job goes catatonic
for a minute or two trying to type out "ITS IN OPERATION" on all the
TK-10 terminals that aren't there.  Then after the available 1 or 2
job slots get used up, you can't create any jobs until the system job
comes back and processes the request to create more job slots.  The
right solution to this is to reassemble the system with TK10P turned
off; unfortunately this will renumber all the terminals, and absolute
tty numbers are known in several places.  NAMDRG knows the number of
the free-screen TV.  DMNSTR knows the number of the xgp console.  The
TTYTYP file knows the numbers of all the terminals; NAME and NAMDRG
read this in when purified or something.

From bogus@does.not.exist.com  Tue Nov 22 14:25:04 2016
From: bogus@does.not.exist.com ()
Date: Tue, 22 Nov 2016 13:25:04 -0000
Subject: No subject
Message-ID: <mailman.443.1479821111.4695.its@nocrew.org>

MOON5 at MIT-MC 01/13/82 16:37:57 Re: one-proceed broken on MC
To: (BUG ITS) at MIT-MC
This was caused by some unidentified cretin copying the file SYS:ATSIGN DDT
from some other machine onto MC.  The proper procedure is to load up
SYSBIN;DDT BIN and start it at PURIFY.  Don't let it happen again!
(And maybe someone can fix DDT to print a warning if it is not on the
machine and ITS version it is purified for reason.  The reasons why it
should print a warning rather than dying should be obvious.)

From mike at BRL  Tue Nov 22 14:25:04 2016
From: mike at BRL (Michael Muuss)
Date: 18 Dec 81 3:59:26-EST (Fri)
Subject: :HISTORY Lossage on DMS
Message-ID: <mailman.468.1479821111.4695.its@nocrew.org>

I ran this on DMS before I realized that BRL-BMD has probably not been
added to the host tables yet.  However, the result was sufficiently
spectacular that I figured somebody would like to hear.
			Cheers!
			 -Mike
---------------------------------------

*:history brl-bmd

*ERROR*
DANGEROUS-INTERRUPT-NOT-HANDLED
MPV!-INTERRUPTS
#WORD *310000634117*
LISTENING-AT-LEVEL 2 PROCESS 1
^S
:KILL
*

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


From KERNSatMIT-ALCATOR  Tue Nov 22 14:25:04 2016
From: KERNSatMIT-ALCATOR (Robert W. Kerns)
Date: 5-DEC-1981 16:02:44.12
Subject: DDT Pseudo-1138
Message-ID: <mailman.478.1479821112.4695.its@nocrew.org>

Please undo your installation.  You have re-installed a large set of bugs,
since there were a lot of patches made to 1138.  I'll talk to you about getting
the HSNAME stuff in.


From Guy.Steele  Tue Nov 22 14:25:04 2016
From: Guy.Steele (Guy.Steele)
Date: 6 October 1981 1808-EDT (Tuesday)
Subject: > name conventions
In-Reply-To: Ken Harrenstien's message of 6 Oct 81 16:52-EST
Message-ID: <06Oct81 180837 GS70@CMU-10A>

Ideas about making ">" do the right thing seem to pop up about
twice a year for a last five or six years.  No one seems to have
gotten sufficiently excited about it to grovel through the ITS
file directory code, though.  (I think it was a major triumph
when it was reorganized so that directories were kept sorted instead
of re-sorting each time one was opened in ASCII mode; and another
when directory GC was grossly sped up so it didn't take time
n^3.  I doubt the code has been touched in ten years except for those
(actually, it probably has, but not significantly).)
Anyone else know anything about this?
--Guy

From Guy.Steele  Tue Nov 22 14:25:04 2016
From: Guy.Steele (Guy.Steele)
Date: September 10 1981 1402-EDT (Thursday)
Subject: PDP-10 binary search trick
Message-ID: <10Sep81 140255 GS70@CMU-10A>

Does anyone know who invented the incredibly tight PDP-10 code
for doing a binary search, which looks something like:
	SETZ INDEX,
REPEAT N,[
	CAML ITEM,TABLE+1_<N-.RPCNT-1>(INDEX)
	 ADDI INDEX,1_<N-.RPCNT-1>
]
	CAME ITEM,TABLE(I)
	 JRST NOTFOUND
?  I'm trying to track down some history.
--Thanks,
  Guy


From Guy.Steele  Tue Nov 22 14:25:04 2016
From: Guy.Steele (Guy.Steele)
Date: 8 June 1981 1011-EDT (Monday)
Subject: Cleaning up my old directories
Message-ID: <08Jun81 101127 GS70@CMU-10A>

Dear everyone,
   I would like to undertake the task of grossly reaping my old ITS
directories, first weeding through them a shipping good stuff to CMU.
(Chuck Rich is after me to free up a few directories.)  Before I can
do this I need to get many files back from tape.  Would someone be
willing to help in this endeavor?
   On AI I need all files for directories GLS, TGQ, QUUX, and QX
from tapes GFR9, GFR10, GFR11, 140, and 1407.
   On MC I need all files for directories GLS, QUUX, and QX
from tapes GFR24, GFR25, GFR26, GFR27, and GFR28.
   Within a day or two of the reappearance of these files I can
flush them all again and free up several directories.
Thanks,
   Guy

From mclureatSRI-UNIX  Tue Nov 22 14:25:04 2016
From: mclureatSRI-UNIX (Stuart Mclure Cracraft)
Date: Mar 19 1981 at 0318-PST
Subject: roll mode
Message-ID: <mailman.660.1479821116.4695.its@nocrew.org>

If I telnet into mc, do :tctyp dm (which turns off roll
mode on my datamedia), and then logout, ITS fails
to turn roll mode back on.



From SHRAGE  Tue Nov 22 14:25:04 2016
From: SHRAGE ( Jeffrey Shrager)
Date: Mar 15 1981 (Sunday) 2100-EDT
Subject: Typing a ":"
Message-ID: <mailman.664.1479821116.4695.its@nocrew.org>

I might have bugged this before.  I recall thinking that I should do so about
three weeks ago.  If not... here goes:

When you are at DDT's "*" prompt, you cannot backspace and fix a missing ":".
That is, for example, I begin typing a command and the realize that it should
have had a colon before it.  If I backspace (rubout) to the beginning and
enter the colon then retype the command it does not realize that the colon
is there and errors saying "you must type a colon..."

If I bugged this before forgive me.  My mind must be going.
-- JEff


From Guy.Steele  Tue Nov 22 14:25:04 2016
From: Guy.Steele (Guy.Steele)
Date: January 29 1981 1658-EST (Thursday)
Subject: Page ahead
Message-ID: <29Jan81 165842 GS70@CMU-10A>

I did some detective work.  Get onto an ITS and try
	:DOC USET PAGRAN
and	:DOC USET PAGAHD

From Guy.Steele  Tue Nov 22 14:25:04 2016
From: Guy.Steele (Guy.Steele)
Date: January 18 1981 2332-EST (Sunday)
Subject: Transcribing COM links
In-Reply-To: gnu@MIT-ML's message of 18 Jan 81 02:53-EST
Message-ID: <18Jan81 233212 GS70@CMU-10A>

Presumably one could write a cross between FIDO and the SPY feature of LOCK
as follows:  have a program that runs as a demon (so it wakes up when
the system is brought up).  Once every couple of seconds it wakes up
and scans the system TTY tables for COM links much as PEEK might.
(Or JEDGAR -- this hack involves bits of sixteen other programs!)
When one is found, then it uses the SPY device to gobble the
characters and appenbd them to a file.  If you're hairy enough you
can transcribe several at once.
This is not an offer to write the hack -- I have no time.  I'm just outlining
the technical possibilities.  I will, however, remark that there may be
a difference of kind rather than degree between random spying on other
terminals and systematic transcription of people's conversations.  It
probably should not be done without at least a system message (which you
see whenever you log in) to the effect that such monitoring is in progress.
--Guy


From Guy.Steele  Tue Nov 22 14:25:04 2016
From: Guy.Steele (Guy.Steele)
Date: January 15 1981 0110-EST (Thursday)
Subject: system hanging on disk...
In-Reply-To: Earl A. Killian's message of 14 Jan 81 21:09-EST
Message-ID: <15Jan81 011000 GS70@CMU-10A>

Or you could dynamically allocate disk channels... installing it
would be a great new source of bugs.  Hasn't been very much activity
on the BUG-ITS mailing list lately anyway...
--Q


From Guy.Steele  Tue Nov 22 14:25:04 2016
From: Guy.Steele (Guy.Steele)
Date: January 12 1981 1412-EST (Monday)
Subject: File name > >
In-Reply-To: KMP@MIT-MC's message of 11 Jan 81 23:09-EST
Message-ID: <12Jan81 141206 GS70@CMU-10A>

Actually, I thought you weresupposed to get some kind of open
error message like "bad file name" if both FN1 and FN2 were one
of > or <.


From CPRatMIT-EECS  Tue Nov 22 14:25:04 2016
From: CPRatMIT-EECS (Chris Ryland)
Date: November 3 1980  12:40-EST
Subject: buffer hogging
Message-ID: <mailman.749.1479821118.4695.its@nocrew.org>

It seems to me (from my travels with ESC V) that the Plasma TV system
often lets buffers sit unused after people log out from MC; MC takes
quite a while to close the connection, and even after that, Plasma
takes a while to free the buffer.  Both of these should be shortened,
so that logging out---without logging back in nearly
immediately---frees up the buffer.


From WESTFW  Tue Nov 22 14:25:04 2016
From: WESTFW (William Westfield)
Date: Apr 14 1980 (Monday) 2358-EDT
Subject: :F  SEEMS TO BE MESSED UP
Message-ID: <mailman.843.1479821120.4695.its@nocrew.org>

IF YOU DO JUST A :F, THINGS WORK PROPERLY, BUT IF YOU DO SOMETHING LIKE
:F BILLW
IT GOES INTO WHAT APPEARS TO BE AN INFINITE LOOP, IN WHICH IT KEEPS
REOUTPUTTING THE TTY OUTPUT BUFFERS (?). I THINK :FINGER STILL WORKS
PROPERLY.
BILLW



From bogus@does.not.exist.com  Tue Nov 22 14:25:04 2016
From: bogus@does.not.exist.com ()
Date: Tue, 22 Nov 2016 13:25:04 -0000
Subject: No subject
Message-ID: <mailman.881.1479821121.4695.its@nocrew.org>

ED and ALAN and 42TLNT TELSER at MIT-MC (Sent by ALAN at MIT-MC) 02/28/80 03:02:19 Re: .FLT1 and 2
To: (BUG ITS) at MIT-MC
These seem to be initialized to %pibrk and 0 on MC and
not initialized elsewhere.  Elsewhere, in fact, they seem
to contain the UNAME and JNAME of the last job to .LOGOUT
of that job slot (?!?!?)
What are these, anyway?  They aren't documented anywhere.
Looking in the system also seems to comfirm that these values
are used for COMPLETELY RANDOM stuff like the RENAME case of
.MLINK ((??!!??!!??))

From bogus@does.not.exist.com  Tue Nov 22 14:25:04 2016
From: bogus@does.not.exist.com ()
Date: Tue, 22 Nov 2016 13:25:04 -0000
Subject: No subject
Message-ID: <mailman.926.1479821122.4695.its@nocrew.org>

pae at MIT-MC (Sent by ___043 at MIT-MC) 10/21/79 15:02:33
To: (BUG ITS) at MIT-MC
mctty^f does not work when you are on mc.

From OTTO  Tue Nov 22 14:25:04 2016
From: OTTO (George Otto)
Date: Oct 16 1979 (Tuesday) 1457-EDT
Subject: Solution to previously reported C100 problems.
Message-ID: <mailman.929.1479821122.4695.its@nocrew.org>

As RWK at MIT first suggested, the problem with C100 screen control turned
out to be caused by the local host, Wharton, eagerly removing ^L's from
its ARPAnet transmissions before sending them on the the terminal.
Thus the problem in entirly local.
   My appologies for even HINTING that ITS could have a bug in it, and
many thanks for the help I received in tracking this problem down.
 
                                           George Otto


From OTTO  Tue Nov 22 14:25:04 2016
From: OTTO (George Otto)
Date: Oct 16 1979 (Tuesday) 0446-EDT
Subject: Possible solution to errors in C100 support.
Message-ID: <mailman.932.1479821122.4695.its@nocrew.org>

   In order to examine why the :CLEAR command was not clearing the
screen of my CONCEPT APL, I put the terminal into transparent mode
in order to examine the characters ITS was sending down the line
in response to that command. The octal sequence was as follows:
 
   015 015 012 177 033 023 177 012 012 012 012
                             012 012 012 012 177 177 177 177 177 177

Among other things you should notice that there is not a single "clear
screen" (^L, FF, 014) in the entire transmission! Instead we have some
carraige returns (^M, CR, 015), some line feeds (^J, LF, 012), a single
"clear to end of line/field" ($ ^S, ESC DC3, 033 023), and some random
padding characters (DEL, 177).
   If all the routines in ITS send this same sequence thinking it is
going to clear a screen instead of just move the cursor down 9 lines,
this may explain the problems I encountered earlier.
   I am using the CONCEPT Reference Manual (DN1300-7808-1) and the
CONCEPT Reference Card (DN1300-7810) as my documentation for this
analysis, both from Human Designed Systems, Inc., 3700 Market Street,
Philadelphia, Pa. 19104.


From OTTO  Tue Nov 22 14:25:04 2016
From: OTTO (George Otto)
Date: Oct 15 1979 (Monday) 2341-EDT
Subject: Possible errors in C100 support/additional information
Message-ID: <mailman.933.1479821122.4695.its@nocrew.org>

   I have tried the solution of indicating the speed of my terminal,
with no luck. Increasing the speed to 600, 1200, and finally 9600
did not change the behavior at all; in all cases the previously
reported errors occurred. Some additional information may be in order:
 
1) The :CLEAR command does not clear the screen, but only up-spaces
   about 10 lines,
2) The characters which are shipped out to my terminal in response
   to the "TCTYP C100" command switch my terminal over to the APL
   character set, which I must immediatly reset to make any sense
   of the transmissions,
3) My terminal is a CONCEPT APL, which, as far as anybody knows, is
   controlled identically to the CONCEPT 100. Local programs which
   use cursor homing, screen clearing, cursor addressing, and line
   insertion and deletion all work with no difficulty using the
   standard CONCEPT computer-issued command set.
 
If I can provide more information, please let me know.
 
                                               George Otto



From OTTO  Tue Nov 22 14:25:04 2016
From: OTTO (George Otto)
Date: Oct 15 1979 (Monday) 2337-EDT
Subject: Possible errors in C100 support/additional information.
Message-ID: <mailman.934.1479821122.4695.its@nocrew.org>

   I have tried the solution of indicating the speed of my terminal,
with no luck. Increasing the speed to 600, 1200, and finally 9600
did not change the behavior at all; in all cases the previously
reported errors occurred. Some additional information may be in order:
 
1) The :CLEAR command does not clear the screen, but only up-spaces
   about 10 lines,
2) The characters which are shipped out to my terminal in response
   to the "TCTYP C100" command switch my terminal over to the APL
   character set, which I must immediatly reset to make any sense
   of the transmissions,
3) My terminal is a CONCEPT APL, which, as far as anybody knows, is
   controlled identically to the CONCEPT 100. Local programs which
   use cursor homing, screen clearing, cursor addressing, and line
   insertion and deletion all work with no difficulty using the
   standard CONCEPT computer-issued command set.
 
If I can provide more information, please let me know.
 
                                               George Otto



From OTTO  Tue Nov 22 14:25:04 2016
From: OTTO (George Otto)
Date: Oct 15 1979 (Monday) 2256-EDT
Subject: Possible errors in C100 support/padding solution
Message-ID: <mailman.935.1479821122.4695.its@nocrew.org>

I will try that solution, but keep in mind that I am operating at 300
buad now.
                                         George Otto


From OTTO  Tue Nov 22 14:25:04 2016
From: OTTO (George Otto)
Date: Oct 15 1979 (Monday) 2115-EDT
Subject: Possible errors in C100 terminal support
Message-ID: <mailman.936.1479821122.4695.its@nocrew.org>

   I am a new user on the ARPAnet and a new user on the MIT-AI
computer. I have used INFO for the past several days, using a
CONCEPT 100 terminal identified via a "TCTYP C100" command.
My reason for sending this note is that the screen control on my
terminal has been somewhat messy. I do not know if this is due
to a mistake in screen control or in the INFO program, so I thought
I'd simply describe the problem and let you sort it out.
   When I give a command such as "INFO INTRO" the display proceeds
as if on a regular TTY, i.e., the information is "painted" on the
screen line by line, scrolling the terminal when the cursor hits the
bottom line of the display. This usually results in "INFO docu-
mentation reader" line being left on the LAST line of the display
screen instead of in its usual place two lines above that. This
causes problems later when the screen is being overwritten, because
some display lines which are blank simply do a linefeed over the
previous text, leaving it on the screen along with the newer display.
Needless to say, these garbage lines make understanding of the new
display somewhat difficult.
   Once, and this happened on a redisplay request (^L) as well, the
scrolling operation was proceeding as described above when the cursor
jumped into the middle of the screen and continued from there. This
left a very confusing screen as a result.
   I think that a fair number of these problems could be removed if
the screen could be cleared once in awhile. This would remove possible 
garbage lines and also position the screen from the top down instead
of from the bottom up, thus putting everything where it was expected 
right off the bat. As it is, the screen is NEVER cleared.
   If there is anything you would like me to try on my terminal to help
identify what is going on more specifically, just let me know.

                                          George Otto
                                          (OTTO at WHARTON)



From bogus@does.not.exist.com  Tue Nov 22 14:25:04 2016
From: bogus@does.not.exist.com ()
Date: Tue, 22 Nov 2016 13:25:04 -0000
Subject: No subject
Message-ID: <mailman.948.1479821122.4695.its@nocrew.org>

Sheldon Furst <FURST at BBN-TENEXB>@MIT-MC (Sent by ___065 at MIT-MC) 09/30/79 19:33:28
To: (BUG ITS) at MIT-MC
[This is Sheldon Furst (FURST)]

I connected to MC, did not log in, and typed "furst$
" and got
the response "This person's mail is forwarded to CHNL NOT OPEN (newline)
Bad file = ^Q : ^Q ; ^Q ^Q".  Tried it again, and got a "Fork disconnected"
or something like that, then a console free message.

I don't presume this is SUPPOSED to happen, is it?

-- Sheldon


From bogus@does.not.exist.com  Tue Nov 22 14:25:04 2016
From: bogus@does.not.exist.com ()
Date: Tue, 22 Nov 2016 13:25:04 -0000
Subject: No subject
Message-ID: <mailman.999.1479821123.4695.its@nocrew.org>


From dab at mit-borax  Tue Nov 22 14:25:04 2016
From: dab at mit-borax (David A. Bridgham)
Date: Sep 13 1984 1615-EDT (Thursday)
Subject: supdup
Message-ID: <8409132015.AA03676@mit-borax.ARPA>

	I recently wrote a supdup server for VAX UNIX running on TCP.
This is currently running on MIT-BORAX.  To test it I would supdup in
from lisp machines or CCC.  This forwards through MC with no problem.
However, from MC if I type ":supdup borax" it sits for a while and says
that the connection timed out without getting established.  Could anyone
help?  Thanks.
						Dave

From MOON  Tue Nov 22 14:25:04 2016
From: MOON (MOON)
Date: October 29 1983  16:02-EDT
Subject: ITS wedgeding
In-Reply-To: The message of 29 Oct 1983 01:52-EDT from Christopher C. Stacy <CStacy at MIT-MC>
Message-ID: <mailman.1294.1479821132.4695.its@nocrew.org>

Oh by the way, I forgot to mention about the job that had two disk
channels open, where one was to "RAT;".  The mode printed by Peek C
mode for that channel was "RU", meaning that it was reading a
directory ("UFD").  Probably this channel really belonged to some
other job and peek was confused.

From MOON  Tue Nov 22 14:25:04 2016
From: MOON (MOON)
Date: October 29 1983  15:59-EDT
Subject: ITS wedgeding
In-Reply-To: The message of 29 Oct 1983 01:52-EDT from Christopher C. Stacy <CStacy at MIT-MC>
Message-ID: <mailman.1295.1479821132.4695.its@nocrew.org>

    Date: Saturday, 29 October 1983, 01:52-EDT
    From: Christopher C. Stacy <CStacy at MIT-MC>
    Subject: ITS wedgeding
    To: BUG-ITS at MIT-MC
    Cc: TAFT at MIT-MC, KMP at MIT-MC, KLH at SRI-NIC, Moon at SCRC-TENEX,
        ELLEN at MIT-MC, JPG at MIT-MC, GSB at MIT-MC

       TAFT at MIT-MC 10/28/83 14:31:11 Re:  Crash of 10/28 14:27
Subject:  Crash of 10/28 14:27
       MC was catatonic, but running.  Though jobs could be logged in, no
       response to anything other than ^G could be obtained.  I checked
       around that this was really the case and then stopped it.


    MC was also merrily printing lots of my little "Warning: <out of this
    or that>" messages every chance it got.

    In ITS 1353, crash file CRASH;ITS LOWCOR, SYSjob 88, Core 71, Net 24,
    IMP 338, Chaos 255, INet 96, NCP 5, TCP 256, TCPbuf 53, on MIT-MC:

    There is definitely something weird going on here.
    Of the 50 disk channels, none are free.  
    There is no more free low core (for making file or network buffers.)

    There are about 37 ___nnn CHAOS and 22 ___nnn TCP jobs trying to boot.
    They are in LOAD or OPEN, trying to read ATSIGN CHAOS or ATSIGN TCP,
    respectively. They all have read 0% of their file.

      We can look at a representative wedged server job: user idx 101.
    ___101 TCP, is blocked inside a LOAD call:  NLOADD+6/ SKIPG QSFBS(A)  A/ 40
    I don't entirely grok this disk code yet, but from the channel state
    (%QALBK) and mode (READ/USER DATA), and the comment where he blocks,
    it looks like he is waiting for the file channel to receive a buffer
    with the first page of the TCPSER file.

    Also, there may also be something weird file-wise with this particular job.
    Unlike the others, I think it has two (QUSR idx) channels:  17 and 40.
    According to PEEK, he is also opened RAT; (no file name), which I
    guess accounts for channel 17.   But, huh? What? Why?

      Now, the TCP situation shows that there can be up to 180. packet
    buffers, of which zero are free out of a total zero allocated.

    I checked in XBUSER and friends.
    There is only one TCP frob around, and he's not doing a whole lot:
    TCP index 21, which has no associated job, is in "CLSACK" for SRI-CSL.  
    Has received FIN for input, State is "Last ACK".
    User channel state:  (input) Foreign host RESET, retransmit timeout (output).
    The close reason is:  Closed by user, Closed by foreign host.

    This is (I think) reasonable, but does not account for all those other TCP servers!


    1. WHAT ARE ALL THOSE NETWORK SERVER JOBS DOING WITHOUT ANY 
       NETWORK CONNECTIONS?  Is it that the connections went away 
       before the jobs had a chance to get started, or what?
       What are all these jobs for, anyway?

They have to load their programs before they can open their network
connection.  The incoming RFC (SYN in the TCP case) that started these
jobs probably timed out and was rejected before you dumped the system,
hence no trace of it was left.  If they're trying to load the ATSIGN xxx
program (rather than the actual server) that means they haven't even
yet queried the system's RFC (SYN) queue to find out what contact name
(port number) they are supposed to serve.

The system is supposed to filter out duplicate RFCs and SYNs, so if that's
working each of those jobs was created by a separate user attempt to connect.
Of course if they block forever in the LOAD system call, once created they
will never go away.

    2. WHERE DID ALL THE LOW CORE GO?  
       This seems to be the reason those server jobs can't get going.

The lack of low core is indeed the reason the servers can't get going; they
can't get a buffer to use to read their disk files they're trying to load.
Even in PDUMP format the first page of the file has to be read into low core
to find out what pages are to be loaded.

One reason for lack of low core is bloatage of directories.  I've been meaning
to make a straightfoward but not totally simple fix to allow directories to
be stored anywhere in core, but haven't got around to it.  I guess you should
bug me about this periodically.

However, in this case that isn't the problem: there are only 9 pages of
directories (DSKUDR in Peek M mode) plus 7 pages of disk buffers.  I looked
around at the MEMBLT and MEMPNT tables.  A lot of the low core pages are
just user pages of job 100, a worthless TEX job.  See the large comment
a few lines below SWPOPG; evidently the system keeps trying to swap
out more and more pages to get some low memory, but keeps swapping out
the wrong jobs.

The right fix is to make it specifically swap out pages in "low" memory
(as counted by LMEMFR) in this case, or else to put the core shuffler
back in to move those pages to "high" memory.  Maybe I'll look into this
in a few days when I get time.

    3. I heard that typein was echoing very slowly for users during this
       wedged period.  I wonder if this was true, it was it true for local
       consoles as well as STYs?  I don't really understand why this should
       be, in either case.  When the system is running out of core, I have
       usually been able to do SYS$J (provided there was a channel for me
       to .OPEN on USR:) and look around.

Lack of low core could not affect echoing on local terminals, and would only
affect echoing on network terminals if there wasn't enough core to make
network packet buffers.  Of course maybe the users were confused and
what they really meant was that their programs were busted.

From CSTACY at MIT-OZ  Tue Nov 22 14:25:04 2016
From: CSTACY at MIT-OZ (Christopher Stacy)
Date: Monday, September 12, 1983 5:40AM-EDT
Subject: TOPS-20 usage of "TCP" protocol
Message-ID: <mailman.1334.1479821133.4695.its@nocrew.org>

Programs which gateway through the TCP byte-stream gateways (ie., the
"ARPA" CHAOSnet protocol, currently served only by ITS hosts on both
nets), they should tell what sort of gatewaying is going on.

Users cannot tell how they are getting from point A to point B - all
they see is a virtual network where everything is magically connected
by various secret means.  If they were told what means was being
employed to connect them with remote hosts on other networks, they
would stand a chance of figuring out what was losing when the
"gateway" did not work.

BTW, probably the CHAOSNET "TCP" protocol user to get a byte stream
should be made an available (optionally included, requires CHAOS
support routines) call in the NETWRK packages (on all systems).  It
could take remote host address and port, and an AOBJN-style pointer to
a table of gateway server addresses.  When the DEC interface for IP
comes out, and NETWRK will need rewriting anyway, would be a good time
to do this.

Chris

From MARTY at MIT-OZ  Tue Nov 22 14:25:04 2016
From: MARTY at MIT-OZ (Martin David Connor)
Date: Thursday, July 28, 1983 3:19AM-EDT
Subject: CFTPing from ITS
Message-ID: <mailman.1355.1479821134.4695.its@nocrew.org>


I now find that supplying a non-existent username to LOGIN
when CFTPing to MC or ML now hangs indefinitely.
I discovered this when running a batch job that CFTPs and
logs in as OZHOST.

This used to work.  Was there a change to the file server on MC?


From MOON  Tue Nov 22 14:25:04 2016
From: MOON (MOON)
Date: June 2 1983  15:59-EDT
Subject: No subject
In-Reply-To: The message of 2 Jun 1983 07:57-EDT from Patrick Sobalvarro <PGS@MIT-OZ>
Message-ID: <mailman.1379.1479821134.4695.its@nocrew.org>

    Date: Thursday, 2 June 1983, 07:57-EDT
    From: Patrick Sobalvarro <PGS at MIT-OZ>

    If I read the file MC: AR1: PGS; PKGDCL > into a Zwei buffer, I get 4 nulls at
    the end.  I don't see these in Emacs.  If I delete the nulls and write the file
    and read it again, they're back.  With nulls, the file has 115 characters in
    it.

I believe this is a bug in the ARC: device; it stores file lengths in words
rather than in characters.  Emacs deletes all sorts of characters at the ends
of files in order to get around bugs like this, but the ITS file server is
not as careful (or not as willing to cover up for the deficiencies of other
programs).

From MOON  Tue Nov 22 14:25:04 2016
From: MOON (MOON)
Date: May 5 1983  15:02-EDT
Subject: STLGET
In-Reply-To: The message of 5 May 1983 04:01-EDT from Christopher C. Stacy <CStacy at MIT-MC>
Message-ID: <mailman.1402.1479821135.4695.its@nocrew.org>

Well I guess it wouldn't hurt to make STLGET return a fifth value,
although probably all the programs that call it look in the memory of
the user whose index is the 4th value anyway.

From bogus@does.not.exist.com  Tue Nov 22 14:25:04 2016
From: bogus@does.not.exist.com ()
Date: Tue, 22 Nov 2016 13:25:04 -0000
Subject: No subject
Message-ID: <mailman.1415.1479821135.4695.its@nocrew.org>


From bogus@does.not.exist.com  Tue Nov 22 14:25:04 2016
From: bogus@does.not.exist.com ()
Date: Tue, 22 Nov 2016 13:25:04 -0000
Subject: No subject
Message-ID: <mailman.1461.1479821150.4695.its@nocrew.org>


From bogus@does.not.exist.com  Tue Nov 22 14:25:04 2016
From: bogus@does.not.exist.com ()
Date: Tue, 22 Nov 2016 13:25:04 -0000
Subject: No subject
Message-ID: <mailman.1462.1479821159.4695.its@nocrew.org>