Consolidate license copies

[its.git] / sysdoc / its.obugs0

Copyright (c) 1999 Massachusetts Institute of Technology

This program is free software; you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
the Free Software Foundation; either version 3 of the License, or (at
your option) any later version.

This program is distributed in the hope that it will be useful, but
WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
General Public License for more details.

You should have received a copy of the GNU General Public License
along with this program; if not, write to the Free Software
Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
------------------------------

Date: Friday, 29 April 1983, 00:33-EDT
From: Christopher C. Stacy <CStacy at MIT-MC>
To: David C. Plummer <DCP at MIT-MC>
Cc: BUG-ITS at MIT-MC, ian at MIT-OZ
In-reply-to: The message of 28 Apr 83 16:59-EDT from David C. Plummer <DCP at MIT-MC>

    Date: 28 April 1983 16:59 EDT
    From: David C. Plummer <DCP @ MIT-MC>
    It's cheating.  Terminal-0-F  @Rutgers, c-Break, chaos:conn-list
    shows that the contact name the LispM is using is NAME @rutgers.

Aha.  Except that SYSTEM-T RUTGERS connects to MC and then gets
me to RUTGERS ok.  It also works for SCORE.
\1f
Date: 28 Apr 1983  17:43 EDT (Thu)
From: Ian Macky <Ian@MIT-OZ>
To:   David C. Plummer <DCP@MIT-MC>
Cc:   BUG-ITS@MIT-MC
Subject: ARPA server
In-reply-to: Msg of 28 Apr 1983 17:13 EDT from David C. Plummer <DCP at MIT-MC>

Ah, OK, thanks much -- All it needed was for me to send a NL after
the connection was established.
\1f
Date: 28 April 1983 17:13 EDT
From: David C. Plummer <DCP @ MIT-MC>
Subject: ARPA server
To: Ian @ MIT-OZ
cc: DCP @ MIT-MC, BUG-ITS @ MIT-MC

I figured it out.  You aren't following the protocol of the TCP
NAME server.  Connecting isn't enough.  After you connect, you
must then give the JCL.  Try :chtn mc\eTCP rutgers 117 (the caps
are important).  When it opens the connection, type return.
\1f
Date: 28 April 1983 16:59 EDT
From: David C. Plummer <DCP @ MIT-MC>
To: CSTACY @ MIT-MC
cc: DCP @ MIT-MC, BUG-ITS @ MIT-MC, ian @ MIT-OZ

    Date: 27 April 1983 21:41 EDT
    From: Christopher C. Stacy <CSTACY @ MIT-MC>

    If I go to a LispM and finger RUTGERS, it connects to MC and I
    get a Finger listing from RUTGERS.  I can also TELNET from a
    LispM to SCORE.  So, I think the ARPA server works.

It's cheating.  Terminal-0-F  @Rutgers, c-Break, chaos:conn-list
shows that the contact name the LispM is using is NAME @rutgers.
\1f
Date: 27 April 1983 21:41 EDT
From: Christopher C. Stacy <CSTACY @ MIT-MC>
To: DCP @ MIT-MC, ian @ MIT-OZ
cc: BUG-ITS @ MIT-MC


If I go to a LispM and finger RUTGERS, it connects to MC and I
get a Finger listing from RUTGERS.  I can also TELNET from a
LispM to SCORE.  So, I think the ARPA server works.

\1f
Date: 27 Apr 1983  20:22 EDT (Wed)
From: Ian Macky <Ian@MIT-OZ>
To:   David C. Plummer <DCP@MIT-MC>
Cc:   BUG-ITS@MIT-MC
Subject: ARPA server
In-reply-to: Msg of 11 Apr 1983 06:39 EST from David C. Plummer <DCP at MIT-MC>

The ARPA server still doesn't work.  If I go to MC and do F @RUTGERS
then I get a Rutgers Finger display.  If, from OZ, I connect to the
ARPA server with "RUTGERS 117" then I never get the stuff.  What it
was doing a few seconds ago was just hanging... I waited a minute or
so (on several occasions) but never got any response.  Usually there's
a "Failed to TCP connect" message, and sometimes a "Timed-out" and
other similar things, but it has never once worked.
\1f
Date: Wednesday, 27 April 1983, 08:24-EDT
From: Christopher Stacy <CStacy@MIT-OZ>
Subject: SYS:
To: BUG-ITS@MIT-MC
Cc: ALAN@MIT-MC, DEVON@MIT-MC
In-reply-to: The message of 27 Apr 83 05:24-EDT from Alan Bawden <ALAN at MIT-MC>

I have an idea for implementing Twenex-like logical names on ITS.
The main feature which I want from logical names is search paths,
so that COM: and SYS: and others could be made to do the right thing.

The jobdev mechanism could be used as-is for this feature, but I dont
want the overhead of a jobdev and the slowness of doing the IOTs
multiple times.  

My idea for getting around this is a to extend JOBRET so that there is
a way for the BDH to tell the system: "I am going away now. Disconnect
the user from me and retry the OPEN call using these args I am giving
you."  Once this kind of JOBRET is done, the BDH's BOJ: channel is
closed and he should logout or reuse.  There will probably want to be
some restrictions (like maybe: the BDH must not have .IOTed anything
yet) based on internal implementation details.

With this feature, a user could open the FOO: device, which would
start a BDH.  The BDH would do a JOBCAL and find out the OPEN
parameters.  Then the BDH does its thing to figure out where the user
really wants to be OPEN to, and does a JOBRET to pass control back to
ITS for retrying the OPEN call. 

I am willing to implement this in ITS, and maybe put some kind of
interface on it for users (so they dont have to write their own BDH's
whenever they want to make a logical name).

Thoughts?

\1f
Date: 27 April 1983 11:04 EDT
From: David C. Plummer <DCP @ MIT-MC>
Subject: SYS:
To: CStacy @ MIT-OZ
cc: BUG-ITS @ MIT-MC, ALAN @ MIT-MC, DEVON @ MIT-MC


    I am willing to implement this in ITS, and maybe put some kind of
    interface on it for users (so they dont have to write their own BDH's
    whenever they want to make a logical name).

    Thoughts?

As I recall, you threatened to do this for the sake of things
like HS: as well.  Anyway, one possibility is to have users
translate FOO:*;* * to LOGICL:*;* *.  The LOGICL device could
open DSK:hsname;xuname LOGICL to find an ascii file containing
lines of LOGICAL-DEVICE &REST PATHS, where PATHS can contain *s
for when to default to the field from the open call.  You would
have to be careful to make sure loops don't happen (e.g., foo: ->
bar: -> foo: ...).  Perhaps you can use LINK-DEPTH-EXCEEDED...
To appease people like me who already have 6 translations, you
may have to up the translation table size if you decide to use
this method.
\1f
Date: Wednesday, 27 April 1983, 08:41-EDT
From: Christopher Stacy <CStacy at MIT-OZ>
Subject: SYS:
To: BUG-ITS at MC
Cc: ALAN at MC, DEVON at MC
In-reply-to: The message of 27 Apr 83 05:24-EDT from Alan Bawden <ALAN at MIT-MC>

I have an idea for implementing Twenex-like logical names on ITS.
The main feature which I want from logical names is search paths,
so that COM: and SYS: and others could be made to do the right thing.

The jobdev mechanism could be used as-is for this feature, but I dont
want the overhead of a jobdev and the slowness of doing the IOTs
multiple times.  

My idea for getting around this is a to extend JOBRET so that there is
a way for the BDH to tell the system: "I am going away now. Disconnect
the user from me and retry the OPEN call using these args I am giving
you."  Once this kind of JOBRET is done, the BDH's BOJ: channel is
closed and he should logout or reuse.  There will probably want to be
some restrictions (like maybe: the BDH must not have .IOTed anything
yet) based on internal implementation details.

With this feature, a user could open the FOO: device, which would
start a BDH.  The BDH would do a JOBCAL and find out the OPEN
parameters.  Then the BDH does its thing to figure out where the user
really wants to be OPEN to, and does a JOBRET to pass control back to
ITS for retrying the OPEN call. 

I am willing to implement this in ITS, and maybe put some kind of
interface on it for users (so they dont have to write their own BDH's
whenever they want to make a logical name).

Thoughts?

\1f
Date: 27 April 1983 05:24 EDT
From: Alan Bawden <ALAN @ MIT-MC>
Subject:  SYS:
To: DEVON @ MIT-MC
cc: BUG-ITS @ MIT-MC
In-reply-to: Msg of 27 Apr 1983 02:36 EDT from Devon S. McCullough <DEVON>

    Date: 27 April 1983 02:36 EDT
    From: Devon S. McCullough <DEVON>
    Why doesn't SYS: look in the overflow directories SYS1; SYS2; SYS3;
    prray tell?

I thought about this some more, and I talked it over with Moon, and it
appears that the answer is:  For no good reason.

There are some red herring issues like:  What should happen if you try to
read the binary directory listing from SYS:.FILE. (DIR)?  And:  What
exactly should happen if you open SYS:FOO > for writing?  But it appears
that a perfectly good answer to most of those objections is:  Well what
makes you think that the SYS: device should behave at all like the DSK:
device anyway?  (Why should it have a binary directory, and why should you
be able to write to it.)

There would be the compatibility problem with current programs that use
SYS: as a synonym for DSK:SYS;, but they could all be trivially fixed.
Think of al the places that implement the SYS;, SYS1;, ... search
themselves currently...

(Now, can somebody think of something clever for the COM: device to do?)
\1f
Date: 27 April 1983 02:36 EDT
From: Devon S. McCullough <DEVON @ MIT-MC>
To: BUG-ITS @ MIT-MC

Why doesn't SYS: look in the overflow directories SYS1; SYS2; SYS3; prray tell?
\1f
Date: 27 April 1983 01:20 EDT
From: Alan Bawden <ALAN @ MIT-MC>
Subject:  CRASH;CRASH QSKCH
To: KLH @ MIT-MC
cc: BUG-ITS @ MIT-MC, CSTACY @ MIT-MC
In-reply-to: Msg of 26 Apr 1983 09:33 EDT from Ken Harrenstien <KLH>

    Date: 26 April 1983 09:33 EDT
    From: Ken Harrenstien <KLH>
    Note, by the way, that this has been with us for a long time; there
    are simply too many processes trying to run, and the present design of
    ITS imposes some limits which cannot be avoided without doing clever
    things like mapping buffers in and out of exec address space.  Both
    CHAOS and TCP code are also liable to wild runaway use of buffers if
    the net hardware burps.

Has anyone thought seriously about mapping buffers?  (I appreciate that I
have just said a mouthful.)
\1f
Date: 26 April 1983 13:05 EDT
From: Richard Mark Soley <SOLEY @ MIT-MC>
Subject:  CRASH;QSKCH
To: CSTACY @ MIT-MC
cc: BUG-ITS @ MIT-MC, JPG @ MIT-MC, TY @ MIT-MC
In-reply-to: Msg of 26 Apr 1983 05:56 EDT from Christopher C. Stacy <CSTACY>

    Date: 26 April 1983 05:56 EDT
    From: Christopher C. Stacy <CSTACY>
    To:   TY, SOLEY
    cc:   BUG-ITS, JPG
    Re:   CRASH;QSKCH

    Did ITS crash, or did you stop it?  All that is on the console
    is "Warn  KLDCP" --that is, ITS did not print any crash message
    and it looked like it was just halted in its tracks.  In particular,
    I dont see the PC or anything printed anywhere.

ITS didn't crash, we stopped it.  No-one was getting any response at all.

        -- Richard
\1f
Date: 26 April 1983 09:33 EDT
From: Ken Harrenstien <KLH @ MIT-MC>
Subject: CRASH;CRASH QSKCH
To: JPG @ MIT-MC
cc: CSTACY @ MIT-MC, BUG-ITS @ MIT-MC

Looking at this crash with PEEK's autopsy mode reveals that sure
enough the system was out of low memory, because there were tons
of disk channels open.  

Note, by the way, that this has been with us for a long time; there
are simply too many processes trying to run, and the present design of
ITS imposes some limits which cannot be avoided without doing clever
things like mapping buffers in and out of exec address space.  Both
CHAOS and TCP code are also liable to wild runaway use of buffers if
the net hardware burps.

What is interesting is that one TEX job had 9 disk channels open, 7
of them to the same file!  There was another TEX running too, tho not
as hoggish.  And there were several ATSIGN CHAOS jobs scattered
around; these invariably seem to litter up the system whenever it
gets wedged (cause or effect?)
\1f
Date: 26 April 1983 07:01 EDT
From: Christopher C. Stacy <CSTACY @ MIT-MC>
Subject:  Translations
To: ALAN @ MIT-MC
cc: BUG-DDT @ MIT-MC, PGW @ MIT-XX, BUG-its @ MIT-ML
In-reply-to: Msg of 23 Apr 1983 16:23 EST from Alan Bawden <ALAN>


DDT now uses an unlikely SNAME when it creates inferiors, to help
prevent naive users from translating themselves into problems.


\1f
Date: 26 April 1983 05:56 EDT
From: Christopher C. Stacy <CSTACY @ MIT-MC>
Subject: CRASH;QSKCH
To: TY @ MIT-MC, SOLEY @ MIT-MC
cc: BUG-ITS @ MIT-MC, JPG @ MIT-MC


Did ITS crash, or did you stop it?  All that is on the console
is "Warn  KLDCP" --that is, ITS did not print any crash message
and it looked like it was just halted in its tracks.  In particular,
I dont see the PC or anything printed anywhere.

The messages it was printing were to tell you that the load on the
system was too high (in the sense that there were no disk channels).
That is why the system no doubt looked wedged to users.

Btw, I fixed ITS so that it will only print those warning messages
every thirty seconds, so it wil not overflow the console buffer
(which is what the SYS MSGS LOST means.   Maybe it should say
SYS MSGS LOTS instead...)

\1f
Date: 26 April 1983 05:17 EDT
From: Christopher C. Stacy <CSTACY @ MIT-MC>
To: BUG-ITS @ MIT-MC

Now ITS only does running out of resource checks if it has not done
one in the last thirty seconds.  This is to avoid deluging the system
console with messages like "Warning: Inadequate space in low core LMEMFR/2".
\1f
Date: Tuesday, 26 April 1983, 00:37-EDT
From: Christopher C. Stacy <CStacy at MIT-MC>
Subject: FileComputer
To: PSZ at MIT-ML, HDT at MIT-OZ
Cc: BUG-ITS at MIT-ML
In-reply-to: The message of 24 Apr 83 14:11-EDT from Peter Szolovits <PSZ at MIT-ML>

There are two different, incompatible file systems on CADR-27.  
If you want to use what I believe is called the "FS" filesystem, you
need to use CFTP.  If you use the "FC" filesystem (written by RMS) you
can use either CFTP or just the FC: device.

I just typed :LISTF FC:CSTACY; on MC, and it listed my directory for me. 
What do you think is wrong?

Cheers,
Chris


\1f
Date: 25 April 1983 18:18 EDT
From: Jeffrey P. Golden <JPG @ MIT-MC>
To: CSTACY @ MIT-MC
cc: BUG-ITS @ MIT-MC

Please check out CRASH;CRASH QSKCH.
What happened is the system console began printing out pages and pages 
of "Warning: No free qsk channels.
    n SYS MSGS LOST"
and then it crashed in some way, hence the CRASH dump.  (I was not here 
at the time, I am just transmitting the contents of the log book to you 
so you can check this out.)
\1f
Date: 25 April 1983 04:13 EDT
From: David C. Plummer <DCP @ MIT-MC>
Subject: ASSLIS is such a kludge!
To: ALAN @ MIT-MC
cc: BUG-ITS @ MIT-MC, BUG-LISP @ MIT-MC

    Date: 24 April 1983 18:31 EST
    From: Alan Bawden <ALAN @ MIT-MC>

    File deletion is supposed to work on the core-link, and I distinctly
    remember that in the (recent) past it HAS worked (DCP might remember
    otherwise?).

I don't remember if it is supposed to or not.

    If anyone wants a few cheap laughs (and can read Midas), they should take a
    look at MC:L;ASSLIS >.  It's certainly the kludgiest program I've seen in a
    long time.

I thought I could read Midas, but I have a hard time reading that thing.
\1f
Date: 24 April 1983 18:31 EST
From: Alan Bawden <ALAN @ MIT-MC>
Subject:  ASSLIS is such a kludge!
To: BUG-ITS @ MIT-MC
cc: BUG-LISP @ MIT-MC

CLU:.FILE. (DIR) currently lists:

 LISP   MIDAS  BARQIO CLOSED->        HACTRN
 FOO    MIDAS  BARQIO CLOSED->        HACTRN
 L      MIDAS  BARQIO CLOSED->        HACTRN
 L      MIDAS  FOOQIO CLOSED->        HACTRN

The reason it says "  HACTRN" is that it used to say "ALAN HACTRN" until I
logged out that job.  Before that all four entries were in CLOSED->CLOSED
state and I tried to delete tham using \ f in DDT.  Instead of deleting them
it seems to have decided I wanted to USE them.  I checked, and DDT did not
still have any CLx channels.  I guess these will stay here until MC crashes
next.

File deletion is supposed to work on the core-link, and I distinctly
remember that in the (recent) past it HAS worked (DCP might remember
otherwise?).

If anyone wants a few cheap laughs (and can read Midas), they should take a
look at MC:L;ASSLIS >.  It's certainly the kludgiest program I've seen in a
long time.
\1f
Date: 24 April 1983 13:11 EST
From: Peter Szolovits <PSZ @ MIT-ML>
Subject:  FileComputer
To: HDT @ MIT-OZ
cc: BUG-ITS @ MIT-ML
In-reply-to: Msg of 24 Apr 1983  01:49 EST (Sun) from Howard D. Trachtman <HDT at MIT-OZ>

    Date: 24 Apr 1983  01:49 EST (Sun)
    From: Howard D. Trachtman <HDT at MIT-OZ>
    To:   PSZ at MIT-OZ
    Re:   FileComputer

    I'm not sure what happened to the fc device as accesable from ITS.
    I do know that cftp will work.

    Try :cftp fc
    login psz
    dir fc:psz;

    and you should see your files.  The fc: is needed as the filecomputer
    supports two different file systems.

Indeed you are right.  Therefore the FC: device in ITS is broken.  Could
someone fix it?

\1f
Date: Sunday, 24 April 1983, 01:51-EST
From: David A. Moon <Moon at MIT-MC>
Subject: Running out of low core
To: Christopher C. Stacy <CSTACY at MIT-MC>
Cc: BUG-ITS at MIT-MC
In-reply-to: The message of 19 Apr 83 21:17-EST from Christopher C. Stacy <CSTACY at MIT-MC>

    Date: 19 April 1983 21:17 EST
    From: Christopher C. Stacy <CSTACY @ MIT-MC>
    The check for running out of low core I put in goes off quite alot,
    and frequently overflows the system console message buffer. Usually
    when this goes off, it means that the system appears wedged to users.
    Do you suppose there could be a bug in the system with someone not
    returning some flavor of buffer space at the right time?

More likely there is just isn't enough address space for all the disk
buffers, disk directories, chaos buffers, tcp buffers, core link buffers,
and everything else.  Isn't it the case that if you wait a while and
kill all jobs with open files the space always comes back eventually?
\1f
Date: 23 April 1983 16:23 EST
From: Alan Bawden <ALAN @ MIT-MC>
Subject:  Translations
To: PGW @ MIT-XX
cc: BUG-DDT @ MIT-MC, BUG-its @ MIT-ML
In-reply-to: Msg of 23 Apr 1983 1328-EST from Paul G. Weiss <PGW at MIT-XX>

    Date: 23 Apr 1983 1328-EST
    From: Paul G. Weiss <PGW at MIT-XX>
    To:   bug-its at MIT-ML
    Re:   Translations

      ...

    What follows is a wallpaper file so you can better understand what I mean:

    ------------------------------------------------
    *\e\14 arch;* *,ar1:inna;* *
      ...
    *:find arch;
     INFERIOR-CREATION FAILED? \e\eu:BYE
    \16  INFERIOR-CREATION FAILED?:INPUSH  \e\e1u

This is because translating *:ARCH;* * => AR1:INNA;* * will cause
translations to happen for devices other than DSK: (like USR:, which is why
DDT can't create any inferior jobs).  You should create the following two
translations instead:

 DSK:ARCH;* * => AR1:INNA;* *
 ML:ARCH;* * => AR1:INNA;* *    ;or whatever ITS you are using.

(I have CC'd this to BUG-DDT beacuse I presume DDT could be more robust
than this by supplying some unlikely-to-be-translated directory name
whenever it tries to use the USR: device.  I checked, and DDT currently
doesn't supply an SNAME when opening USR:, which just begs to shaft people
like this.)

\1f
Date: 23 Apr 1983 1328-EST
From: Paul G. Weiss <PGW@MIT-XX>
Subject: Translations
To: bug-its@MIT-ML

In order to get around the problem of TEX not accepting device names for
input files, I have been using file translations.  In particular, I do

\e\14 arch;* *,ar1:inna;* *

and use the "pseudo-directory" ARCH; to refer to stuff inside the archive.
This works fine for TEX.

The problem is that it causes other things to go awry, namely, when I try
to do 

        :FIND ARCH;

it gives me a strange error.
It also keeps me from logging out with \e\eu since it tries and fails to run
:BYE.  I must log out with \e\e1u (or remove the translation).

What follows is a wallpaper file so you can better understand what I mean:

------------------------------------------------
*\e\14 arch;* *,ar1:inna;* *
*arch\ 6ML  INNA   AR1    6.045J
Free files = 175, Wasted Words = 0
  0   H1     1      1  02/02/83 16:55:58
  0   H10    1      3  03/10/83 18:23:21
  0   H12    2      1  03/08/83 16:42:41
  0   H13    6      1  03/09/83 10:16:47
  0   H14    4      1  03/10/83 19:38:01
  0   H15    6      1  03/10/83 22:32:47
  0   H16    2      1  03/17/83 12:46:21
  0   H17    2      1  03/29/83 15:33:57
  0   H18    13     1  04/04/83 10:29:40
  0   H19    1      4  04/07/83 22:28:43
  0   H2     10     1  02/02/83 16:56:00
  0   H20    1      2  04/07/83 22:29:43
  0   H21    5      2  04/08/83 10:37:00
  0   H23    2      1  04/13/83 16:02:52
  0   H24    3      1  04/14/83 15:50:58
  0   H25    2      1  04/20/83 17:13:16
  0   H26    2      1  04/23/83 12:38:10
  0   H26A   1      1  04/20/83 17:02:45
  0   H26B   1      2  04/21/83 16:43:30
  0   H26C   1      1  04/21/83 16:26:47
  0   H26D   1      2  04/21/83 16:27:02
  0   H26E   1      3  04/21/83 16:27:23
  0   H26F   1      3  04/21/83 16:58:04
  0   H3     23     1  02/07/83 16:43:30
  0   H4     5      1  02/07/83 18:07:10
  0   H6     1      1  02/14/83 19:10:38
  0   H7     1      2  03/10/83 18:22:44
  0   H8     11     1  02/24/83 15:27:48
  0   H9     1      2  03/10/83 18:22:57

*:find arch;
 INFERIOR-CREATION FAILED? \e\eu:BYE
\16  INFERIOR-CREATION FAILED?:INPUSH  \e\e1u
-----------------------------------------
-------

\1f
Received: from SCRC-BLACKSTONE by SCRC-TENEX with CHAOS; Fri 22-Apr-83 11:27:24-EST
Date: Friday, 22 April 1983, 11:23-EST
From: Robert W. Kerns <RWK@SCRC-TENEX>
To: Christopher C. Stacy <CSTACY@MIT-MC>
Cc: BUG-ITS@MIT-MC
In-reply-to: The message of 19 Apr 83 21:17-EST from Christopher C. Stacy <CSTACY at MIT-MC>

    Date: 19 April 1983 21:17 EST
    From: Christopher C. Stacy <CSTACY @ MIT-MC>
    The check for running out of low core I put in goes off quite alot,
    and frequently overflows the system console message buffer. Usually
    when this goes off, it means that the system appears wedged to users.
    Do you suppose there could be a bug in the system with someone not
    returning some flavor of buffer space at the right time?

I am of the opinion this problem has been with us for years.
\1f
Date: 22 April 1983 08:21 EST
From: Christopher C. Stacy <CSTACY @ MIT-MC>
To: BUG-ITS @ MIT-MC


AI's processor is *fucked*.  I turned it off.  Maybe it will start
randomly working again when I turn it back on, probably tomorrow or
the next day.
\1f
Date: Friday, 22 April 1983, 07:58-EST
From: Christopher Stacy <CStacy at MIT-OZ>
Subject: MC is now the bug host.
To: BUG-ITS at MC, BUG-MAIL at MC

COMSAT now uses MC as the "bug host".  I changed all the appropriate
mailing lists, and installed the latest COMSAT on all four machines.
I put the following in the MC:NAMES > file:

;;; MC is now the default BUG host.  
;;; If a program exists on all machines, its BUG list normally
;;; only needs to be on MC.
;;;
;;; The reasons to define a BUG- name on some ITS besides MC include:
;;; o  The program is not used on MC.
;;; o  The program is mainly used on the other ITS, and most of 
;;;        the maintainers are there, and there is an entry 
;;;        on MC which forwards to the apporpriate machine.
;;; o  In the absence of such reasons, define it on MC only.
;;;
;;; If a message is sent from some other ITS to a bug list which is not
;;; defined, it will be forwarded here.  If the bug list is not defined
;;; here, the message will be sent instead to BUG-RANDOM-PROGRAM.

Chris
\1f
Date: 20 April 1983 01:44 EST
From: David C. Plummer <DCP @ MIT-MC>
Subject: [Forwarded: COMSAT, Re: [Forwarded: Hank.Walker@CMU-CS-VLSI, Re: Mailer problems]]
To: BUG-ITS @ MIT-MC

Date: 15 April 1983 08:51 EST
From: David C. Plummer <DCP @ MIT-MC>
Subject: [Forwarded: Hank.Walker@CMU-CS-VLSI, Re: Mailer problems]
To: BUG-MAIL @ MIT-MC

More info.  I notice bug-mail is still on AI.  Should this be changed?
                 ------------------------------
Date: Thursday, 14 April 1983 21:15:03 EST
From: Hank.Walker@CMU-CS-VLSI
To: David C.Plummer <DCP@MIT-MC>
Subject: Mailer problems
Message-ID: <1983.4.15.2.10.27.Hank.Walker@CMU-CS-VLSI>

It is probably not the UNIX mailer that is causing the problems.  Mail
messages from MIT go to CMU-CS-A.  If it is TCP mail, it is shipped
to the CMU-CS-PT VAX over the Ethernet, which translates the stuff into
NCP, and sends it back to CMUA where it is delivered to me.  That mail is
then autoforwarded to me at CMU-CS-VLSI, where I live, even though INFO-COBOL
has my CMU-CS-A mailing address.  So the mail is delivered directly 
to CMU-CS-A, which is a KL10 running TOPS-10, rather than to a UNIX machine.
I have no troubles receiving mail from any other site on the net to either
CMU-CS-VLSI directly or to CMU-CS-VLSI, which communicates with the ARPAnet
over an Ethernet gateway.
\1f
Date: 20 April 1983 01:44 EST
From: David C. Plummer <DCP @ MIT-MC>
Subject: [Forwarded: COMSAT, Re: [Forwarded: Hank.Walker@CMU-CS-VLSI, Re: Infinite mail messages]]
To: BUG-ITS @ MIT-MC

I originally sent this to BUG-MAIL@MC, which tried to go to AI,
which is down.  Perhaps somebody should find an AI backup tape,
and get NAMES > (carefully) and get the more important BUG lists
over to MC?  There is a followup to this message coming soon...
                 ------------------------------
Date: 14 April 1983 21:04 EST
From: David C. Plummer <DCP @ MIT-MC>
Subject: [Forwarded: Hank.Walker@CMU-CS-VLSI, Re: Infinite mail messages]
To: BUG-MAIL @ MIT-MC
cc: Hank.Walker @ CMU-CS-A

Forwarding complaint about the MC mailer.  Following are some
parts of the MC mail stats file.  Other ditties of information:
Other messages to CMU-CS-A get through successfully.  The ones I
saw happened to be small messages.  Could this be the Unix
braindeath that insists on completely delivering messages
(instead of queuing) before it gives a completion reply?  If so,
the product of number of recipients by the length of the message
is a roungh indication of the length of time it will take to
deliver the message.  If things are sufficiently slow, MC will
correctly timeout.  If this is true, I would have to say it is
the Unix mail server that is broken.

    Date: Thursday, 14 April 1983 20:51:27 EST
    From: Hank.Walker@CMU-CS-VLSI
    To: David C.Plummer <DCP@MIT-MC>
    Subject: Infinite mail messages
    Message-ID: <1983.4.15.1.49.7.Hank.Walker@CMU-CS-VLSI>

    Would you please refrain from sending messages to INFO-COBOL until your
    mailer is fixed.  I realize that it is not your fault, but quite frankly I
    am tired of receiving anywhere from 2 to 10 messages from anyone who sends
    mail originating at MIT, particularly mail that I've already seen before.
    Lean on your system manager, or charge him a quarter for every duplicated
    mail message that your system emits.

195935    ICP->CMU-CS-A(SMTP)
195939          XTO->Bob.Walker
195939          XTO->David.Nichols
195940          XTO->Dill
195940          XTO->Everhart
195940          XTO->gail.kaiser
195941          XTO->Hank.Walker
195941          XTO->Highnam
195942          XTO->Kazar
195942          XTO->Lamb
195943          XTO->Lehman
195943          XTO->muller@CMU-CS-GANDALF
195943          XTO->Provan
195944          XTO->Rudy.Nedved
195944          XTO->Sherman
195945          XTO->Shipman
195945          XTO->Shrager
195945          TEXT->
200048  NO COMPLETION REPLY, R=10
200503  Queued: <[MIT-MC].635105> for CMU-CS-A

202005  Attempting to send messages queued to host CMU-CS-A
202005    ICP->CMU-CS-A(SMTP)
202008  QID=<[MIT-MC].635105>
202009          XTO->Bob.Walker
202009          XTO->David.Nichols
202010          XTO->Dill
202010          XTO->Everhart
202011          XTO->gail.kaiser
202011          XTO->Hank.Walker
202012          XTO->Highnam
202013          XTO->Kazar
202013          XTO->Lamb
202014          XTO->Lehman
202014          XTO->muller@CMU-CS-GANDALF
202015          XTO->Provan
202015          XTO->Rudy.Nedved
202016          XTO->Sherman
202016          XTO->Shipman
202017          XTO->Shrager
202017          TEXT->
202120  NO COMPLETION REPLY, R=10
\1f
DCP@MIT-ML 04/19/83 22:13:15
To: (BUG its) at MIT-MC
Has anybody changed the ATTY/DTTY code recently.  It's probably
pure coincidence, but MC has crashed on me several times
just after sending me a message.  Perhaps that's just a bad
time to reference a disk?

\1f
Date: 19 April 1983 21:18 EST
From: Christopher C. Stacy <CSTACY @ MIT-MC>
To: BUG-ITS @ MIT-MC


In XITS on MC, I patched out the LMEMFR check bug message for the moment.
\1f
Date: 19 April 1983 21:17 EST
From: Christopher C. Stacy <CSTACY @ MIT-MC>
To: BUG-ITS @ MIT-MC


The check for running out of low core I put in goes off quite alot,
and frequently overflows the system console message buffer. Usually
when this goes off, it means that the system appears wedged to users.
Do you suppose there could be a bug in the system with someone not
returning some flavor of buffer space at the right time?

\1f
Date: 16 April 1983 04:36 EST
From: Christopher C. Stacy <CSTACY @ MIT-MC>
To: BUG-ITS @ MIT-MC

ITS 1336 (XITS on MC) has additional warning messages for no
free disk channels and no free job slots, to go with the no
free low core warning. This junk seems to work.
\1f
Date: 16 April 1983 02:52 EST
From: Christopher C. Stacy <CSTACY @ MIT-MC>
Subject: crash info
To: BUG-ITS @ MIT-MC
cc: ELLEN @ MIT-MC, JPG @ MIT-MC

ITS now print warning when the amount of exec free space
gets too low.  This is to make it easier to walk over to the
console and guess why the machine is wedged.  Also put a bug
message in the RH10 QINTE code where it has been dying all day,
so it prints the disk number and offending controller bits.

ITS 1334 installed on MC as XITS.
If trouble, revert to NITS.
\1f
Date: 16 April 1983 01:17 EST
From: Christopher C. Stacy <CSTACY @ MIT-MC>
Subject: hardware trouble
To: BUG-ITS @ MIT-MC
cc: ELLEN @ MIT-MC, JPG @ MIT-MC, GSB @ MIT-MC


MC is having bad hardware trouble.  
ITS died several times today with disk hardware errors. 
This was at QINTE+45, where it checks some random ctrl bits (and the
comment reads "worse than unsafe".)  I think this was on unit #0.
Just now the system came down because the -11 timed out waiting on the
KL.  Earlier today it came down becuase there were too many parity
errors.  Yesterday and the day before the -11 died, and had to be
power cycled to get to work again.
\1f
Date: 13 April 1983 19:56 EST
From: Ken Harrenstien <KLH @ MIT-MC>
Subject: ML doesn't like to talk to the Symbolics ethernet (and any future new subnets)
To: Moon @ SCRC-TENEX
cc: BUG-ITS @ MIT-MC, cmb @ SCRC-VIXEN, bug-lispm @ SCRC-TENEX

The last ML ITS was assembled in middle of March, plenty of time for your
NSUBNT change to take effect.  I checked it out just now, and found
that you modified the CHAOS source on SYSTEM; rather than SYSHAK; which
is where all of the recent TCP/IP work has been happening.  So I just
now bumped up NSUBNT to 100. in the SYSHAK version (the only change you
made) and someone will have to assemble a new ML ITS sometime.

I guess now that things are obviously working, SYSHAK should be merged back
into SYSTEM, so I will do that eventually.
\1f
Received: from SCRC-DALMATIAN by SCRC-TENEX with CHAOS; Wed 13-Apr-83 19:36:59-EST
Date: Wednesday, 13 April 1983, 19:38-EST
From: David A. Moon <Moon@SCRC-TENEX>
Subject: ML doesn't like to talk to the Symbolics ethernet (and any future new subnets)
To: bug-its@MIT-MC
Cc: cmb@SCRC-VIXEN, bug-lispm@SCRC-TENEX

Note the date on the second enclosed message.  I guess if this continues
for another two months I'll find the time to do it myself.

    Date: Wednesday, 13 April 1983, 19:18-EST
    From: Clark M. Baker <cmb at SCRC-VIXEN>
    Subject: (load "ml:router;pi >") never works from a 3600 at Symbolics
    To: BUG-LISPM at SCRC-TENEX
    
    I haven't been able to load files from ML onto a 3600 at Symbolics.
    However, ML is up.  I can load files from ML onto a LM-2 at Symbolics.
    I can load files from ML onto MIT-PI.  What is happening?
    
    
    Date: 21 February 1983 20:49 EST
    From: David A. Moon <MOON5 @ MIT-MC>
    Subject:  ML
    To: BUG-ITS @ MIT-MC
    
    I made NSUBNT (number of Chaosnet subnets) be a more reasonable size.
    ML (the only ITS machine that does its own Chaosnet routing) should
    get a reassembled ITS when convenient.
    
    
\1f
Received: from SCRC-MYSTIC by SCRC-TENEX with CHAOS; Wed 13-Apr-83 19:34:50-EST
Date: Wednesday, 13 April 1983, 19:36-EST
From: David C. Plummer <DCP@SCRC-TENEX>
Subject: (load "ml:router;pi >") never works from a 3600 at Symbolics
To: cmb@SCRC-VIXEN, BUG-LISPM@SCRC-TENEX, BUG-ITS@MIT-MC
In-reply-to: The message of 13 Apr 83 19:18-EST from Clark M. Baker <cmb at SCRC-VIXEN>

    Date: Wednesday, 13 April 1983, 19:18-EST
    From: Clark M. Baker <cmb at SCRC-VIXEN>

    I haven't been able to load files from ML onto a 3600 at Symbolics.
    However, ML is up.  I can load files from ML onto a LM-2 at Symbolics.
    I can load files from ML onto MIT-PI.  What is happening?
I'll betchya ML's routing table isn't big enough.  This has been CC'ed
to BUG-ITS so somebody will be annoyed it is in they're mailbox and fix
it (maybe me the next time I'm on MC).
\1f
Date: 11 April 1983 06:39 EST
From: David C. Plummer <DCP @ MIT-MC>
Subject: ARPA server
To: Ian @ MIT-OZ
cc: BUG-ITS @ MIT-MC

    Date: 10 Apr 1983 1954-EST
    From: Ian Macky <Ian@MIT-OZ>

    Is this ever going to work again?  Would be nice to get Arpa FINGERs and
    such things from us Chaos-only ("we'll be up in THREE weeks, for sure")
    sites.
    -------
It should work.  Try @<DCP>DUP AI TCP.  If you want the rest of
the world to respond to FINGER, you will have to convince them to
convert the NCP finger program to TCP, and also make sure
whatever user program you are using contacts the correct socket
number (I think the ARPA server wants it in octal, but i can't
remember).
\1f
Date: 10 Apr 1983 1954-EST
From: Ian Macky <Ian@MIT-OZ>
Subject: ARPA server
To: Bug-ITS@MIT-MC

Is this ever going to work again?  Would be nice to get Arpa FINGERs and
such things from us Chaos-only ("we'll be up in THREE weeks, for sure")
sites.
-------
\1f
Date: 7 April 1983 23:13 EST
From: David C. Plummer <DCP @ MIT-MC>
To: ALAN @ MIT-MC
cc: BUG-ITS @ MIT-MC

    Date: 7 April 1983 17:26 EST
    From: Alan Bawden <ALAN @ MIT-MC>

    DIRHNG^F acts pretty graceless.  Actually I can imagine that DIRHNG could
    reasonably display an informative directory.
...of what jobs have what directories open on the DIRHNG device.
If you need a test case, the Versatec spooler always has one open
on .glpr..  
\1f
Date: 7 April 1983 17:26 EST
From: Alan Bawden <ALAN @ MIT-MC>
To: BUG-ITS @ MIT-MC

DIRHNG^F acts pretty graceless.  Actually I can imagine that DIRHNG could
reasonably display an informative directory.
\1f
CSTACY@MIT-AI 04/05/83 11:58:45
To: (BUG ITS) at MIT-AI
In ITS 1332, on MIT-AI:

ITS crashed with the message  PKT: Freeing packet still in use!
Dumped to AI:CRASH;ITS FREPKT

\1f
Date: Tue, 5 Apr 1983  04:45 EST
From: Leigh L. Klotz <KLOTZ@MIT-OZ>
To:   Edjik <NCP.EG%U-GSB-HOW@SU-SCORE>
Cc:   BUG-ITS@MIT-MC, BUG-MIDAS%OZ@MIT-MC, BUG-MIDAS@MIT-MC, BUG-OZ@MIT-MC,
      KLH@MIT-MC
Subject: Gross OZ lossage
In-reply-to: Msg of Mon 4 Apr 83 11:41:35-PST from Edjik <NCP.EGK at SU-GSB-HOW at SU-SCORE>

KLH knows more about midas than most people, including you.  Please keep
your nitbrained views to yourself.
\1f
Date: 5 April 1983 01:43 EST
From: Alan Bawden <ALAN @ MIT-MC>
Subject:  Gross OZ lossage
To: MARTY @ MIT-OZ
cc: BUG-ITS @ MIT-MC, BUG-MIDAS @ MIT-MC, BUG-OZ @ MIT-MC, DCP @ MIT-MC,
    KLH @ MIT-MC
In-reply-to: Msg of 4 Apr 1983  23:19 EST (Mon) from Martin David Connor <MARTY at MIT-OZ>

What is all this flaming horseshit in my mailbox?!?!  Is there anyone who
will argue that it was correct that there were TWO BUG-MIDAS mailing lists?
No.  Have we fixed that?  Yes.  (Thank you Ian.)

Now is there somebody out there who can actually claim to be maintaining
MIDAS to a greater extent than KLH?  If so, then lets hear from them.  If
not, then everyone shut the hell up.
\1f
Date: 5 April 1983 00:57 EST
From: David C. Plummer <DCP @ MIT-MC>
Subject: Gross 8 inch spikes in various people's heads
To: MARTY @ MIT-OZ
cc: BUG-ITS @ MIT-MC, BUG-MIDAS @ MIT-MC, BUG-OZ @ MIT-MC, KLH @ MIT-MC,
    BUG-MIDAS @ MIT-OZ

And you, Mr. Conner, have as much to learn as I.

Reactionary is not bullshit.  Go read a history book someday and
notice how progress is often achieved by reactionaries and their
ideas.

As for the local history of OZ, there were several people willing
(and eager) to help in creating another ITS.  Moon was willing to
hack microcode and oversee changes needed to the system (e.g.,
for disk support) which I was willing to help with.  As I recall,
you were against the idea of ITS on OZ.  Several other people
attended the Wars of Futility where it was decided to run 20X.
These people warned about all the features that 20X was lacking
and many of the problems it had.  But the wars were futile; the
decision was out of our hands.

So now our only recourse is to sit back and be little brats about
the whole thing.  "Nah, nah, I told you so..."  I, for one, am
proud to be one of these brats.

    For god's sake bring up a machine because it is the Right Thing, not
    because you hate another machine so much.
Wrong.  Both are often true.  In fact, this is how TWENEX was
developed. The history told to me was that BBN disliked Bots-10 so
much they went off and wrote TENEX.  DEC started seeing the light
and bought it from them and made it work on a 20.
                                                Learn from the mistakes of
    another attempt, ...
If TWENEX only could.

    Plummer, ... until you learn to work FOR A GOAL instead of
    AGAINST AN ALTERNATIVE you will be counterproductive to the
    causes you Support.  
Goal: Help build better Lisp Machines.  I think I am working for
this goal.  Goal: help MIT when I have the time.  I think I do a
fair job here.  Goal: convince people they lost completely when
they decided to run TWENEX on OZ.  Perhaps this is a subconsious
goal.  How actively I work toward it is not clear.  I would hope
to think I keep such discussions among (ITS) friends except when
something blatant happens.  If you didn't blindly defend the
obvious problems, OZ would probably be a lot nicer.

    Penny, I already know I will regret sending this, because so many
    minds are already closed, but I had to try.  Forgive me.
Mine is closed just enough so that spikes cannot penetrate.  I
know who does the real TWENEX development at MIT, and they have
often responded to the requests of others for (ITS-like)
features.  I hope they also understand the spirit in which I
write these flames.

Marty, you earned your second spike.
\1f
Date: 4 Apr 1983  23:19 EST (Mon)
From: Martin David Connor <MARTY@MIT-OZ>
To:   David C. Plummer <DCP@MIT-MC>
Cc:   "NCP.EGK@SU-GSB-HOW"@SU-SCORE, BUG-ITS@MIT-MC, BUG-MIDAS@MIT-MC,
      BUG-MIDAS@MIT-OZ, BUG-OZ@MIT-MC, KLH@MIT-MC
Subject: Gross ITS lossage
In-reply-to: Msg of 4 Apr 1983 21:40 EST from David C. Plummer <DCP at MIT-MC>


Dogma, Plain and simple will be the downfall of ITS.
It contains the ideas and talent to be great, but lacks the tolerance
of other ideas that will see it wither and die.

Most of what I have heard out of the ITS people is REACTIONARY
bullshit.  A system is just a system, and the thing I can't understand
is why people that could design such beauty and generality can't
quietly bide their time until they get the hardware and then create
another system to show the world what is meant by winning.
I would be proud to help bring up a new ITS, I would be proud to help
bring up another 20, but not in a reationary spirit.
But rather for the love of the hack.

For god's sake bring up a machine because it is the Right Thing, not
because you hate another machine so much.  Learn from the mistakes of
another attempt, but don't be driven by hate and arrogance.

Plummer, you may be able to hack 98% of the world into the ground, but
until you learn to work FOR A GOAL instead of AGAINST AND ALTERNATIVE
you will be counterproductive to the causes you support.

Penny, I already know I will regret sending this, because so many
minds are already closed, but I had to try.  Forgive me.

\1f
Date: 4 April 1983 21:40 EST
From: David C. Plummer <DCP @ MIT-MC>
Subject: Re: Gross OZ lossage
To: "NCP.EGK@SU-GSB-HOW" @ SU-SCORE
cc: KLH @ MIT-MC, BUG-OZ @ MIT-MC, BUG-ITS @ MIT-MC, BUG-MIDAS @ MIT-MC,
    BUG-MIDAS @ MIT-OZ

OZ is the successor to AI in hardware but not in spirit.  I hope
every program you use that was derived from ITS or is assembled
in MIDAS breaks.  I sometimes wish TOPS-20 were orificially
shovable...
\1f
Received: from GSB-HOW with Pup; Mon 4 Apr 83 11:42:17-PST
Date: Mon 4 Apr 83 11:41:35-PST
From: Edjik <NCP.EGK@SU-GSB-HOW at SU-SCORE>
Subject: Re: Gross OZ lossage
To: KLH@MIT-MC
cc: BUG-OZ@MIT-MC, BUG-ITS@MIT-MC, BUG-MIDAS@MIT-MC, BUG-MIDAS%OZ@MIT-MC
In-Reply-To: Your message of Mon 4 Apr 83 13:53:00-PST

Gosh, I wonder just how many people on the 6 mailing lists that KLH
shotgunned his msg to really give a ff about where the MIDAS sources
live.  Probably damn few.  Oz is the successor to AI.  Moving mailing
lists and sources of system programs to it from AI seems natural to me.
Since KLH got the msg Ian sent, he still is on the new offical list at
oz, so why gripe?  His talk of "sacrilege" conjures up images of the
inquisition.  Is KLH the defender of the ITS faith?  Probably KLH's main
gripe is that he hates TOPS-20 and is pissed at having to goto a TOPS-20
site to look at the sources.  If he uses it for TOPS-20 and 10X
software, why does he need it on ITS?

I hope the people in charge of the MIDAS mailing list and sources
do the appropriate thing in response to KLH's flame, ie. ignore it.

-- Edjik
-------
\1f
Date: 4 Apr 1983  15:31 EST (Mon)
From: Ian Macky <Ian@MIT-OZ>
To:   Ken Harrenstien <KLH@MIT-MC>
Cc:   BUG-ITS@MIT-MC, BUG-MAIL@MIT-MC, bug-mail@MIT-OZ, BUG-MIDAS@MIT-MC,
      BUG-OZ@MIT-MC
Subject: Gross OZ lossage
In-reply-to: Msg of 4 Apr 1983 13:53 EST from Ken Harrenstien <KLH at MIT-MC>

Hmm.  Since you obviously have strong feelings about this, and since
that mailing list was screwed up by their being two parallel versions
(one on OZ and one on AI), I have done as you asked (insisted) and
merged the two and put the now official list on MC, with appropriate
pointers all around.
\1f
Date: 4 April 1983 13:53 EST
From: Ken Harrenstien <KLH @ MIT-MC>
Subject: Gross OZ lossage
To: BUG-MAIL @ MIT-MC, BUG-OZ @ MIT-MC, BUG-MIDAS @ MIT-MC,
    BUG-ITS @ MIT-MC, bug-midas @ MIT-OZ, bug-mail @ MIT-OZ

I just got a message at SRI-NIC which IAN sent to BUG-MIDAS at OZ.
This implies that OZ has a BUG-MIDAS mailing list, and furthermore
that this list is NOT the same as the official list on AI.

This reminds me of the BUG-ATSIGN lossage.

I consider myself one of those people who now and then maintain MIDAS.
For the list to be moved without notice is reprehensible.  For it to
not be on an ITS is sacrilege.  I must insist that either AI or MC
be the official home of MIDAS sources and mailing lists.  This
should probably apply to all ITS developed software.  Since I was the
person who did the TENEX/TOPS-20 conversion for MIDAS, and regularly
use it for 10X/20X software, you can hardly say my viewpoint is
wedged.
\1f
Date: 4 April 1983 10:26 EST
From: Gail Zacharias <GZ @ MIT-MC>
Subject:  [JMSK: forwarded]
To: BUG-ITS @ MIT-MC

Date: 04/03/83 10:19:53
From: JMSK

SOMETHING VERRY WEird yust happened. I logged in as usual, the initfile ast
me if I was on an H-19 to which I responded, as usual, in the affirmative,
as usual. Now , if you've been following my exploits with the SUPERROM, you
will recall that I keep my terminal in VT-100 mode, and let my INITfile change
it to an H-19 when I log in (wait, it gets better). Well today, for the first
time, I noticed my MODELINE said:

                IWASA VT100 VT100

and I was verrrry impressed !  I mean somehow ITS, with nothing in my Initfile
to tell it, figured out that my terminal WAS A VT-100 (get it ?

                I WAS A VT-100          !!!!!   )

THEN I GOT SUSPICIOUS, so I did a USERS, and discoverd:
Yukizaku IWASA  logged in thru a CRTSTY VT100 !!!!!!!!!!!
The funny thing is, that's all my modeline shows !!! not MY job, even now, 
but IWASA VT100 !!!!!!!!!!!!!!!!!!!!!!!!! (in HANG state)

        weird, huh ?
\1f
Date:  3 Apr 1983 1502-EST
From: P. David Lebling <PDL@MIT-XX>
Subject: Re: ARC device directories
To: CSTACY@MIT-MC, BUG-ITS@MIT-MC
In-Reply-To: Your message of 19-Mar-83 2245-EST

DIRED (not EMACS DIRED) and FIND depend on it.
-------
\1f
Date: 3 April 1983 01:59 EST
From: Steven A. Swernofsky <SASW @ MIT-MC>
To: BUG-ITS @ MIT-MC

The annoying 15-second (?) pause in output has returned!  -- Steve
\1f
Date: 1 April 1983 02:13 EST
From: Christopher C. Stacy <CSTACY @ MIT-MC>
Subject:  take paws off keys and wait
To: ALAN @ MIT-MC
cc: BUG-ITS @ MIT-MC, JSPEAR @ MIT-AI

    Date: 1 April 1983 01:04 EST
    From: Alan Bawden <ALAN>
    To:   JSPEAR at MIT-AI
    cc:   BUG-ITS at MIT-AI
    Re:   take paws off keys and wait

        JSPEAR@MIT-AI 04/01/83 00:21:35
        To: (BUG ITS) at MIT-AI
        :FINGER seems to respond with 'No users' when there are AI users,
        and :FINGER UNAME gives last logout time even if UNAME is currently 
        on the system.

I put up a new ITS where the main source version number had not changed,
and forgot to dump out some of the random programs.
\1f
Date: 1 April 1983 01:04 EST
From: Alan Bawden <ALAN @ MIT-MC>
Subject:  take paws off keys and wait
To: JSPEAR @ MIT-AI
cc: BUG-ITS @ MIT-AI
In-reply-to: Msg of 04/01/83 00:21:35 from JSPEAR@MIT-AI

    JSPEAR@MIT-AI 04/01/83 00:21:35
    To: (BUG ITS) at MIT-AI
    :FINGER seems to respond with 'No users' when there are AI users,
    and :FINGER UNAME gives last logout time even if UNAME is currently on the
    system.

I dumped out a new finger on AI which seems to have fixed the problem.  I
never did find out just what was damaged about the old one..

\1f
JSPEAR@MIT-AI 04/01/83 00:21:35
To: (BUG ITS) at MIT-AI
:FINGER seems to respond with 'No users' when there are AI users,
and :FINGER UNAME gives last logout time even if UNAME is currently on the
system.

\1f
Date: 31 March 1983 02:27 EST
From: Christopher C. Stacy <CSTACY @ MIT-MC>
To: BUG-ITS @ MIT-MC
cc: GSB @ MIT-MC, ELLEN @ MIT-MC, JPG @ MIT-MC

AI, MC, and DM are running the latest version of ITS 1332.
I reshuffled the version names and cards: NITS is what you
want, and ITS is older.  XITS is mostly GCd and not what you want.
I'll do this for ML tonite or tomorrow.  AI and DM have some more
STYs (number doubled on DM).  Also, latest COMSAT is installed
all around.
\1f
Date: 31 March 1983 00:01 EST
From: Christopher C. Stacy <CSTACY @ MIT-MC>
To: BUG-ITS @ MIT-MC

Increased number of STYs on AI and DM.
\1f
Date: 29 March 1983 00:10 EST
From: David A. Moon <MOON @ MIT-MC>
Subject:  MLSLV bug
To: RWK @ MIT-MC
cc: BUG-ITS @ MIT-MC

    Date: 28 March 1983 21:14 EST
    From: Robert W. Kerns <RWK @ MIT-MC>
    To: BUG-ITS @ MIT-MC

    There are some MLSLV's on MC which are spending much of their time in WHYINT,
    and eating lots of CPU.  Presumably they should be killing themselves, as
    part of network error handling or something.

I fixed this, killed the jobs, and installed the new version everywhere.
There were actually several bugs.
\1f
Date: 29 March 1983 00:09 EST
From: David A. Moon <MOON @ MIT-MC>
To: BUG-ITS @ MIT-MC

I gunned down about 5 arc devices that were hung in BOJSO with
their creator (an FTP server) no longer in existence.
\1f
Date: 28 March 1983 21:14 EST
From: Robert W. Kerns <RWK @ MIT-MC>
To: BUG-ITS @ MIT-MC

There are some MLSLV's on MC which are spending much of their time in WHYINT,
and eating lots of CPU.  Presumably they should be killing themselves, as
part of network error handling or something.
\1f
Date: 28 March 1983 21:05 EST
From: Robert W. Kerns <RWK @ MIT-MC>
To: BUG-ITS @ MIT-MC

I just found a detached 340C23 CHAOS job which appears to have gotten
an ILOPR because it couldn't set its JNAME to MAIL, since
there already seemed to be a job with that name.  It doesn't
look like ot checks for this possibility at all, but given
that both the chaos address and job number parts of the UNAME
are truncated, it should certainly have some strategy for dealing
with this, like AOSing the UNAME or JNAME or something.
\1f
Date: Wednesday, 23 March 1983, 23:49-EST
From: Robert W. Kerns <RWK at SCRC-TENEX>
Subject: thought for the day
To: George J. Carrette <GJC at MIT-MC>
Cc: BUG-ITS at MIT-MC
In-reply-to: The message of 22 Mar 83 01:15-EST from George J. Carrette <GJC at MIT-MC>

    Date: 22 March 1983 01:15 EST
    From: George J. Carrette <GJC @ MIT-MC>
    Taking a word frequency analysis of SYSENG;HOSTS >, we get the top ten
    "words" as:

    (522. HOST) (276. SERVER) (231. USER) (226. LISPM) (222. CHAOS) (205. PDP) 
    (171. MIT) (157. UNIX) (102. VAX) (100. TAC) 

Out of curiosity, I measured (88. SCRC^_SCH^_SPA).  I guess we won't make the
top ten until sometime this summer.

This argues for domains, of course.
\1f
ZOMBIE@MIT-AI 03/22/83 14:48:23
To: (BUG ITS) at MIT-AI
AI will not accept MC or ML as devices although it does make supdup
connections. Just thought someone might like to know...
Sean

\1f
Date: 22 March 1983 01:15 EST
From: George J. Carrette <GJC @ MIT-MC>
Subject: thought for the day
To: BUG-ITS @ MIT-MC

Taking a word frequency analysis of SYSENG;HOSTS >, we get the top ten
"words" as:

(522. HOST) (276. SERVER) (231. USER) (226. LISPM) (222. CHAOS) (205. PDP) 
(171. MIT) (157. UNIX) (102. VAX) (100. TAC) 

\1f
Date: 21 March 1983 06:24 EST
From: Christopher C. Stacy <CSTACY @ MIT-MC>
To: BUG-ITS @ MIT-MC

New PEEK and DDT installed on all four machines.
\1f
CSTACY@MIT-AI 03/21/83 02:59:59 Re: AI uptime
To: (BUG ITS) at MIT-AI
I am gonna have to bring it down to install the latest ITS version,
so before I do...

Today is Monday, the 21st of March, 1983.
AI ITS 1325 has run for 16 days, 3 minutes, 11 seconds.
System last revivde 15 days, 20 hours, 54 minutes, 59 seconds ago.

\1f
Date: 19 March 1983 22:56 EST
From: David A. Moon <moon @ MIT-MC>
Sender: ALAN @ MIT-MC
Subject: job device wedged on MC
To: BUG-ITS @ MIT-MC

The created job was in JOBREU, hung at NJBREU+4 waiting for JBCG
to clear.  Previously it had pclsred from NJBRU1+7.  The creator
was hung in OPEN, at JBFLS, presumably trying to reuse it.  Pclsring
the creator caused it to start a new device job and the old one
to go away.  Looks to me like just an inherent race in the code,
although there were multiple jobs trying to use the same AI: device.
Maybe I'll look at the code more some other time.
\1f
Date: 19 March 1983 22:45 EST
From: Christopher C. Stacy <CSTACY @ MIT-MC>
Subject: ARC device directories
To: BUG-ITS @ MIT-MC

What programs (other than ARCDEV) depend on understanding
the binary representation of the internal directory?
\1f
Date: 18 March 1983 12:33 EST
From: Ken Harrenstien <KLH @ MIT-MC>
Subject: INQUIR vs DDT
To: CSTACY @ MIT-MC
cc: BUG-ITS @ MIT-MC, BUG-DDT @ MIT-MC, BUG-INQUIR @ MIT-MC,
    RWK @ SCRC-TENEX

    Fixed in DDT.1430, installed on MC.

    I think what was going on was that it was failing to map in the
    database (probably out of file channels to open it with, since a
    broken TARAKA DVRSPL had them all).

No, actually it was failing because the LSR1 file was smashed for
real.  I don't know why, but it was definitely munged.  I fixed by
copying the old version back over.

    DDT's LSRMAP now has an error return.  All of it's callers seemed
    to be interested in finding out someone's HSNAME; I made them do
    something reasonable to fake it.

That's the right thing from user prog viewpoint, since LSRMAP could fail
no matter how cleverly it tries to find a good version.  It should try
harder, though.
\1f
Date: 18 March 1983 05:11 EST
From: Christopher C. Stacy <CSTACY @ MIT-MC>
Subject: MLDEV
To: BUG-ITS @ MIT-MC

I reassembled the latest MLDEV on MC.
I think it wasnt using HOSTS3 or something, since it wasnt
doing anything useful.  I think it works now; so I installed it.
\1f
Date: Friday, 18 March 1983, 04:40-EST
From: Christopher C. Stacy <CStacy at MIT-MC>
Subject: INQUIR vs DDT
To: Robert W. Kerns <RWK at SCRC-TENEX>
Cc: Ken Harrenstien <KLH at MIT-MC>, BUG-INQUIR at MIT-MC,
    BUG-ITS at MIT-MC, BUG-DDT at MIT-MC
In-reply-to: The message of 18 Mar 83 00:48-EST from Robert W. Kerns <RWK at SCRC-TENEX>

    Date: Friday, 18 March 1983, 00:48-EST
    From: Robert W. Kerns <RWK at SCRC-TENEX>
        Date: 16 March 1983 18:36 EST
        From: Ken Harrenstien <KLH @ MIT-MC>
        I think it is really bad for DDT to refuse to work just because it can't
        look up a name in INQUIR.  This is just too much dependence; if we cant
        get a DDT to work then we are shafted, but good.
    DDT isn't supposed to not work in any serious way if the INQUIR
    database is trashed.  It shouldn't lose any more seriously than
    failing to find your home directory.  If it won't let you log in,
    that's a bug.  The only other probable loser I can think of is :PRMAIL.
    I don't think that not working is serious.

Fixed in DDT.1430, installed on MC.

I think what was going on was that it was failing to map in the
database (probably out of file channels to open it with, since a
broken TARAKA DVRSPL had them all).

DDT's LSRMAP now has an error return.  All of it's callers seemed
to be interested in finding out someone's HSNAME; I made them do
something reasonable to fake it.
\1f
Date: Friday, 18 March 1983, 00:48-EST
From: Robert W. Kerns <RWK at SCRC-TENEX>
Subject: INQUIR vs DDT
To: Ken Harrenstien <KLH at MIT-MC>
Cc: BUG-INQUIR at MIT-MC, BUG-ITS at MIT-MC, BUG-DDT at MIT-MC
In-reply-to: The message of 16 Mar 83 18:36-EST from Ken Harrenstien <KLH at MIT-MC>

    Date: 16 March 1983 18:36 EST
    From: Ken Harrenstien <KLH @ MIT-MC>
    I think it is really bad for DDT to refuse to work just because it can't
    look up a name in INQUIR.  This is just too much dependence; if we cant
    get a DDT to work then we are shafted, but good.
DDT isn't supposed to not work in any serious way if the INQUIR
database is trashed.  It shouldn't lose any more seriously than
failing to find your home directory.  If it won't let you log in,
that's a bug.  The only other probable loser I can think of is :PRMAIL.
I don't think that not working is serious.
\1f
Date: 16 March 1983 18:36 EST
From: Ken Harrenstien <KLH @ MIT-MC>
To: BUG-INQUIR @ MIT-MC, BUG-ITS @ MIT-MC, BUG-DDT @ MIT-MC

Considering how many things break totally when the INQUIR data base is
corrupted, I would suggest that LSRTNS try to map in LSR1 OLD (ie previous
version or versions) if it runs into problems with the standard file.
Furthermore, INQUPD should try to make sure the existing file is OK before
it renames it to LSR1 OLD.

I think it is really bad for DDT to refuse to work just because it can't
look up a name in INQUIR.  This is just too much dependence; if we cant
get a DDT to work then we are shafted, but good.
\1f
Date: Wednesday, 16 March 1983, 15:30-EST
From: Christopher C. Stacy <CStacy at MIT-MC>
Subject: DIR device
To: John G. Aspinall <JGA at MIT-MC>
Cc: BUG-ITS at MIT-MC
In-reply-to: The message of 16 Mar 83 13:31-EST from John G. Aspinall <JGA at MIT-MC>

    Date: 16 March 1983 13:31 EST
    From: John G. Aspinall <JGA @ MIT-MC>
    The DIR device seems to be permanently getting device-full errors.

    This happens from emacs dired and from various flavours of top level
    invocation - ie DIR:CDATE UP , DIR:RDATE DOWN, etc.

MC is probably permanently overloaded, and has no job slots for
the device handlers for DIR: ....it works fine for me when there
are available job slots.
\1f
Date: 16 March 1983 13:31 EST
From: John G. Aspinall <JGA @ MIT-MC>
Subject: DIR device
To: BUG-ITS @ MIT-MC

The DIR device seems to be permanently getting device-full errors.

This happens from emacs dired and from various flavours of top level
invocation - ie DIR:CDATE UP , DIR:RDATE DOWN, etc.
\1f
Date: 13 March 1983 06:43 EST
From: Alan Bawden <ALAN @ MIT-MC>
Subject:  TTYFLS problem
To: BUG-ITS @ MIT-MC
cc: BUG-EMACS @ MIT-MC, CSTACY @ MIT-MC, KMP @ MIT-MC

TTYFLS, with it's single control bit set to 0, simply sets %TXIGN in the
character in question.  Unfortunately this causes .LISTEN to lie about the
availability of input characters.  

Since EMACS won't redisplay if it thinks there are characters to be read,
this is one way to cause an EMACS to fail to redisplay when proceeded.  I
don't think this exact screw can explain the mysterious "CStacy's lossage".
Few programs probably use TTYFLS and even fewer with that control bit set
to 0.  But perhaps something else can cause .LISTEN to lie?  (Does the
MODLIN package do anything bizare?)
\1f
Date: 13 March 1983 06:36 EST
From: Ken Harrenstien <KLH @ MIT-MC>
Subject: New TELNET installed
To: BUG-ITS @ MIT-MC, BUG-TELNET @ MIT-MC

I installed a new TELNET which fixes some throughput problems.
In particular, one should not become hung waiting for typein to
reach the remote host, and thus output will continue to be
displayed and it should always be possible to break into command
mode.
\1f
Date: 9 March 1983 17:17 EST
From: David A. Moon <MOON @ MIT-MC>
Subject:  .CALL 0, [ not SETZ ]
To: KLH @ MIT-MC
cc: BUG-ITS @ MIT-MC

    Date: 8 March 1983 15:39 EST
    From: Ken Harrenstien <KLH @ MIT-MC>

    Is it the right thing that .CALLs which point to a non-SETZ word
    get an ILOPR instead of failing to skip?

This is left over from about ten years ago, I believe, when that
was going to be used for some kind of dynamic linking of subroutines.
However, it is probably still right for it to ILOPR.
\1f
Date: 9 March 1983 03:54 EST
From: Ken Harrenstien <KLH @ MIT-MC>
Subject: New ITS
To: CSTACY @ MIT-MC, ELLEN @ MIT-MC, JPG @ MIT-MC, TY @ MIT-MC,
    DCP @ MIT-MC, moon @ SCRC-TENEX
cc: KLH @ MIT-MC, BUG-ITS @ MIT-MC

New XITS (1329) installed on MC.  Old XITS renamed to ITS.  There is
no NITS.  This version has a subtle change in SALV; SALV now starts at
212000 instead of 200000, in order to make room for extra ITS code!
.;SALV 306BIN is the version that has this relocation hacked; SALV BIN
still points to the old version.  All future ITSes generated for MC must
use SALV 306 or higher.

This version of ITS tries to implement TCP URGENT handling for
direct-connected STYs.  I haven't tested it yet.  All the known
patches have also been incorporated; if I missed any we'll probably
know about it pretty soon.  The most important change is basically
the one to SALV, since the 200000 address has always been hard-wired
that way and there may conceivably be some ancient software that
is in for a rude shock.  There are no plans to change this for
the KA ITSes at the moment.
\1f
Date: 8 March 1983 22:54 EST
From: Alan Bawden <ALAN @ MIT-MC>
Subject:  ILOPR?
To: DCP @ MIT-MC, KLH @ MIT-MC, BUG-ITS @ MIT-MC
In-reply-to: The message of 8 Mar 1983 20:44 EST from David C. Plummer <DCP>

I was about to point out that there is already an error code for one
variety of malformed .CALL, %ENSCL (illegal system call name).  Except I
find that the following:

        .CALL [SETZ ? SIXBIT /FOOBAR/ ? %CLERR,,1 ? SETZ 2]

Fails to skip, yet also fails to load 1 with any error code (it does not
even clear it.)  The left half of .IOS 0 is loaded with %ENSCL however, so
is is possible to find out the error if you look hard enough.  I'll bet the
idea is that if the first two words in a call block don't clearly identify
it as such, then ITS has no business looking at the next word and using it
to trash some other random location in the user's address space.

Now that is all fine and good if the instruction following the .CALL is a
.LOSE, since DDT will be able to figure it all out, but if instead there
was a JRST to a error reporting routine, I'll bet total randomness would
result from using the garbage left in 1 as an error code.  I guess I have
never been so unlucky as to misspell the name of a system call in a .CALL
that I was planning on handling the errors from myself.  I would argue that
THIS case should be made an ILOPR as well!

Another kind of malformed call block, namely one that doesn't terminate
with a word with bit 4.9 on, generates %ETMRG (too many arguments).  Since
this error is NOT a function of which call was named in the call block, it
really can only be interpreted as meaning "malformed call block".  However
it seems that ITS thinks that such call blocks are well-formed enough to
actually risk storing the error code in any supplied error parameter.
Since convention is to write error parameters at the beginning of a call
block, I think this is reasonable.

Funny, when I started this message I was planning on agreeing with KLH, but
I seem to have convinced myself that DCP is right.
\1f
Date: 8 March 1983 20:44 EST
From: David C. Plummer <DCP @ MIT-MC>
To: KLH @ MIT-MC
cc: BUG-ITS @ MIT-MC

I think ILOPRing is the right thing.  One argument is to
enumerate the common system calls and observe the effect of
changing it.  My first impression is a change would cause subtle
bugs, especially during debugging (where I'd insist on ILOPR if I
programmed it incorrectly).  Another argument is philosophy:
non-SKIP means failure to perform the desired operation.  ILOPR
means failure to perform the desired instruction.  You can't have
an operation before you have an instruction.
\1f
Date: 8 March 1983 18:18 EST
From: Christopher C. Stacy <CSTACY @ MIT-MC>
Subject: for installation
To: BUG-ITS @ MIT-MC

New PEEK on all machines in SYSBIN;PEEK 565BIN.
\1f
Date: 8 March 1983 15:39 EST
From: Ken Harrenstien <KLH @ MIT-MC>
To: BUG-ITS @ MIT-MC

Is it the right thing that .CALLs which point to a non-SETZ word
get an ILOPR instead of failing to skip?  Currently the only
thing which uses .CALL 0, is the symbolic system call frob, and
presumably if any new secondary dispatch is invented for it (ie
something other than SETZ as 1st word pointed at) it could also
be made the sort of call that skipped on success.

(this came up because a botched net server had a bad .CALL arg and
was ILOPR'ing instead of getting a failure return which would have
cleaned up the resulting mess)
\1f
Date: 7 March 1983 04:18 EST
From: David A. Moon <MOON @ MIT-MC>
Subject: Autospeed dialups and system crashes
To: ED @ MIT-MC
cc: BUG-ITS @ MIT-MC

    Date: 7 February 1983 00:37 EST
    From: Ed Schwalenberg <ED @ MIT-MC>
    Subject: Autospeed dialups and system crashes
    To: BUG-ITS @ MIT-MC

    If MC goes down and comes back up, and I've patiently remained dialled
    up while it was down, it typically types out 30 or so "x" characters and
    then just stays wedged, probably waiting for 300 baud input as opposed to
    1200 baud which is what I normally use.  I guess optimal behavior would be
    for the 11 to remember the baud rate and tell the 10 when it comes back up,
    while suboptimal behavior would be to flush the 11's input buffer and then
    retry autospeeding.  Lousy behavior would be to hang up on the user.  But
    the current behavior is just about pessimal.
I don't know why it does this, since autospeeding and baud rates and all
of that are entirely inside the 11; the 10 has nothing to do with it.
But maybe someone gratuitously reloaded the 11, or maybe KLDCP did a Unibus
reset or something??  Also I'm pretty sure the baud rate is set to 1200
when the program is first loaded, before autospeeding.  I remember that
a couple of years ago I tried to debug this and couldn't.
\1f
Date: 7 March 1983 02:59 EST
From: David A. Moon <MOON @ MIT-MC>
Subject: terminal question
To: GZ @ MIT-MC
cc: BUG-ITS @ MIT-MC

    Date: 5 March 1983 22:43 EST
    From: Gail Zacharias <GZ @ MIT-MC>

    Is there anyway I can tell ITS to send parity bit high always (on dialup line).
    I'm getting a lot of framing errors and I figure this might help.
On MC only, you can set all these parameters with :LSPEED.  You want
to turn on extra stop-bit, and then presumably set the character length
one bit shorter to compensate.
\1f
Date: 5 March 1983 22:43 EST
From: Gail Zacharias <GZ @ MIT-MC>
Subject: terminal question
To: BUG-ITS @ MIT-MC

Is there anyway I can tell ITS to send parity bit high always (on dialup line).
I'm getting a lot of framing errors and I figure this might help.
\1f
Date: 5 March 1983 00:44 EST
From: Christopher C. Stacy <CSTACY @ MIT-MC>
Subject:  AHA!
To: KMP @ MIT-MC
cc: ALAN @ MIT-MC, DCP @ MIT-MC, KLOTZ @ MIT-MC, BUG-ITS @ MIT-MC


When I use my Emacs init, Emacs does not redisplay after I type a
character after a %PIATY interrupt.  Things seem to work fine if I
remove MODLIN from my init.  Is it likely this will get fixed?  I
think MODLIN is spiffy, but I really hate having to refresh my own
screen under these circumstances.
\1f
Date: 4 March 1983 02:16 EST
From: Christopher C. Stacy <CSTACY @ MIT-MC>
To: BUG-ITS @ MIT-MC, BUG-EMACS @ MIT-MC
cc: MOON @ SCRC-TENEX


Hey, it looks to me like EMACS forgot to know to redisplay when I type
something after my screen has been bashed (got-back-the-tty interrupt).
Did someone break TECO, or ECHOIN, or am I hallucinating?
\1f
Date: 26 February 1983 20:29 EST
From: Michael A. Bloom <MCB @ MIT-MC>
To: BUG-ITS @ MIT-MC

I just connected to DM through the arpanet, and got a DDT instead of a PWORD.
\1f
Date: Thursday, 24 February 1983, 22:41-EST
From: David C. Plummer <DCP at SCRC-TENEX>
Subject: Those mythical chaos BRD packets
To: network at scrc, bug-lispm at oz, bug-its at mc, bug-twenex at xx,
    chaos-ncp-people at mc, bug-minits at mc, unix-chaos at vx,
    mit-in-people at mc

I implemented chaos BRD packets in MINITS today.  They seem to work.

I also hacked some code for the Lisp Machine to actually test it, but it's
just as gross and ugly as the rest of the current LispM chaos
implementation. 
\1f
Date: 22 February 1983 10:24 EST
From: Christopher C. Stacy <CSTACY @ MIT-MC>
To: BUG-ITS @ MIT-MC

slightly less crockish WHOJ installed on MC, ML, and AI.
Bugs to me.
\1f
Date: 21 February 1983 20:49 EST
From: David A. Moon <MOON5 @ MIT-MC>
Subject:  ML
To: BUG-ITS @ MIT-MC

I made NSUBNT (number of Chaosnet subnets) be a more reasonable size.
ML (the only ITS machine that does its own Chaosnet routing) should
get a reassembled ITS when convenient.
\1f
Date: 19 February 1983 20:11 EST
From: Christopher C. Stacy <CSTACY @ MIT-MC>
Subject:  [KLH: forwarded]
To: BUG-ITS @ MIT-MC
cc: ELLEN @ MIT-MC, BUG-PWORD @ MIT-MC, KLOTZ @ MIT-MC, GREGOR @ MIT-MC


I see KLH already fixed the safe site problem by reassembling
PWORD, so now it uses the same NETWRK goodies as TELSER.
\1f
Date: 19 February 1983 20:07 EST
From: Christopher C. Stacy <CSTACY @ MIT-MC>
To: EBM @ MIT-MC
cc: BUG-ITS @ MIT-MC
In-reply-to: The message of 18 Feb 1983 20:34 EST from J. Eliot B. Moss <EBM>

    Date: 18 February 1983 20:34 EST
    From: J. Eliot B. Moss <EBM>
    To:   BUG-ITS

    I CHTN'ed from XX and had MC request my password ... has the interface
    changed or is something screwy going on?  I thought logins from other
    MIT machines did not require passwords ...

TELSER apparently has a bug putting the host address where PWORD can
see it, (or maybe PWORD needs to see a different format host address).
I will look at and fix this in a moment.
\1f
Date: 19 February 1983 15:47 EST
From: Kent M. Pitman <KMP @ MIT-MC>
Subject:  MC crashing
To: BUG-ITS @ MIT-MC, JPG @ MIT-MC, ELLEN @ MIT-MC

MC was down this morning when I came in. Someone cold booted it and it only
lasted a few minutes. He was in the midst of cold booting it when I came in
to look at it just now, so I finished the booting. Next time it crashes, I'll
try to poke a bit at the state and provide some debugging info. I posted
a system message (in SYS;SYSTEM MAIL) warning that the system was being 
unreliable. If it stays up for a while, someone might want to remove that 
message. --kmp
\1f
Date: 19 February 1983 15:22 EST
From: Tom Knight <TK @ MIT-MC>
To: BUG-ITS @ MIT-MC

MC would not boot from disk this afternoon, because it was hung, probably
at PI level 3, shlunking unit 1 back and forth.  Apparently booting
with the boot switch is incapable of stopping the processor???  Eventually,
by turning off unit 1, I got the machine to crash, and it then booted.  This
seems less than elegant as a way of solving the problem.
\1f
Date: Friday, 18 February 1983  22:05-EST
Sender: KLOTZ @ MIT-OZ
From: Leigh L. Klotz <KLOTZ @ MIT-MC>
To:   J. Eliot B. Moss <EBM @ MIT-MC>
Cc:   BUG-ITS @ MIT-MC
In-reply-to: Msg of 18 Feb 1983 20:34 EST from J. Eliot B. Moss <EBM at MIT-MC>

Gregor and I noticed this from cadr-20, which was a good site.  Maybe
someone broke the password system recently?
Leigh.
\1f
Date: 18 February 1983 20:34 EST
From: J. Eliot B. Moss <EBM @ MIT-MC>
To: BUG-ITS @ MIT-MC

I CHTN'ed from XX and had MC request my password ... has the interface
changed or is something screwy going on?  I thought logins from other
MIT machines did not require passwords ...
\1f
Date: 18 February 1983 08:16 EST
From: Ken Harrenstien <KLH @ MIT-MC>
Subject: NETWRK and friends use HOSTS3 now
To: BUG-ITS @ MIT-MC, BUG-TELNET @ MIT-MC, BUG-PEEK @ MIT-MC,
    BUG-NETWRK @ MIT-MC, BUG-MAIL @ MIT-MC, BUG-FTP @ MIT-MC

I decided to do a little work on credit tonight.

SYSENG;HOSTS XFILE now generates SYSBIN;HOSTS3 BIN as well.  This is the
        new Internet host table and it is intended to become the standard.
        Both HOSTS1 and HOSTS2 will eventually go away.
SYSENG;NETWRK has a new switch, $$HSTS3, that tells the routines to use
        HOSTS3 instead of HOSTS2.  Also, the host number parser has
        been taught how to understand the new 4-octet syntax, as
        in "10.3.0.44" which is MC.
TELNET has been modified to use the NETWRK routines (HOSTNM and
        SYMGET and friends).  As a result, TELNET uses HOSTS3 and
        no longer needs HOSTS1.  Hurray!!!!!!!!!!!!!!!!
        This of course implies that TELNET parses anything NETWRK does.
        The big question: is there ANY other software that still depends
        on HOSTS1??  I am going to flush that table VERY soon.
HOST (alias HSTLOK) has likewise been modified for HOSTS3.
TELSER also uses HOSTS3.
PEEK now uses HOSTS3.
COMSAT now uses ...
QMAIL now ...
FTPS now ...
FTPU ...                (All on MC only for the moment)

Not a bad night's work.  Ka-ching!

There are still a number of programs that need to have $$HST3 turned
on.  The only thing you need to be careful of is references to NW$BYT
and NW%ARP or NW%CHS; it is better to use the GETNET macro than
NW$BYT.  The file format itself is almost the same; only the format
of host and net addresses is different.  Note that ITS will understand
either HOSTS2 or HOSTS3 format, using either NCP or TCP, so there is
no need to retain HOSTS2 even if you are keeping NCP code around for
posterity (which I recommend, by the way).
        As you upgrade, try to add a note to NETWRK pointing at your
software, (see the first page) so that eventually we will have a handy
list of things that use NETWRK and which will need to be reviewed in
the event of future changes.

--Ken
\1f
Date: 16 February 1983 21:04 EST
From: Christopher C. Stacy <CSTACY @ MIT-MC>
To: BUG-ITS @ MIT-MC

Hack :WHOJ installed on all ITSs now.
\1f
Date: 16 February 1983 08:27 EST
From: Ken Harrenstien <KLH @ MIT-MC>
Subject: New PEEK on MC
To: BUG-PEEK @ MIT-MC, BUG-ITS @ MIT-MC
cc: RWK @ MIT-MC, HIC @ MIT-MC, EJS @ MIT-MC, RL @ MIT-MC, RLB @ MIT-MC,
    EBM @ MIT-MC

I have installed another new PEEK on MC for testing.
One feature of this version is that it does away with the stupid
internal table that gave certain people (who are CC'd above) J mode
by default.  Those people who cannot type :P J can just type :PJ
or PJ^K, if they establish the necessary link to SYS;TS PEEK.

A more interesting feature is the ability to PEEK at ITS crash dumps.
This must be invoked as JCL, to wit ":PEEK < filename".  For example,
        :P <CRASH;ITS BLOWN
This will grovel for a while and then put you into an "autopsy mode"
(command char is "<") which doesn't have much useful info at the
moment, but most of the other modes will then show you what ITS
was doing at the moment it crashed.  Rather entertaining...

A feature of interest only to PEEK hackers is that the code has
undergone a lot of facelifting.
\1f
Date: 16 February 1983 03:54 EST
From: Christopher C. Stacy <CSTACY @ MIT-MC>
Subject: I know this is a crock
To: BUG-ITS @ MIT-MC
cc: BUG-TALK @ MIT-MC


There is now a crock version of TALK  (WHOJ & friends)
installed on MC and AI.  If no one complains to much
I will install it on ML and DM later on.

This is not an RSEXEC frob at all, but a quick
dirty hack based on the MLSLV (it reads TTY:).

When I get a chance, I will convert TALK and IEC to
work with TCP, but this was driving me crazy so I
wrote this interim crock.

Chris
\1f
Date: 15 February 1983 07:18 EST
From: Ken Harrenstien <KLH @ MIT-MC>
To: BUG-ITS @ MIT-MC

I just noticed that the :DOC for RFNAME doesn't mention that
it can take a 3rd argument which is a BP to place to deposit an
ASCIZ filename string.
\1f
Date: 13 February 1983 19:13 EST
From: Kent M. Pitman <KMP @ MIT-MC>
Subject:  Can somebody answer this?
To: BUG-ITS @ MIT-MC

Date: 12 February 1983 15:02 mst
From: Schauble.HDSA at M.PCO.LISD.HIS
To:   KMP
Re:   ITS archive files
Received: from M.PCO.LISD.HIS by MIT-MULTICS.ARPA dial; 12-Feb-1983 17:03:33-est

I'm looking for a way to transfer ITS archive files to Multics and have
them arrive as Multics archives files. I recall that someone once wrote
a program to do this. Do you perchange know anything about it?

If not, do you have any documentation on the archive file format so that
I can write one? I have no problem transfering a binary image of the ITS
file, I just need to decode it.

          Thanks,
          Paul
\1f
Date: 13 February 1983 12:04 EST
From: Ken Harrenstien <KLH @ MIT-MC>
To: BUG-PEEK @ MIT-MC, BUG-ITS @ MIT-MC

New peek written to SYS;TS PEEK on MC only.
If no bugs surface after a few days, it can be copied to other systems.
\1f
CSTACY@MIT-AI 02/11/83 14:07:04
To: (BUG ITS) at MIT-AI
AI now has config options set for no 10-11 frobs such as the Chaosnet.
This seems to work, I am typing this from it.
I finished installing the MLDEV stuff here.

\1f
Date: 10 February 1983 06:54 EST
From: David C. Plummer <DCP @ MIT-MC>
Subject: TCP NAME user/server
To: BUG-ITS @ MIT-MC, BUG-NAME @ MIT-MC, BUG-TCP @ MIT-MC
cc: DCP @ MIT-MC, CSTACY @ MIT-MC, KLH @ MIT-MC, CENT @ MIT-ML

Let's see if I can remember everything I just did.

For MC:

I linked DEVICE;JOBDEV AI to the same thing DEVICE;JOBDEV DM
points to (SYSBIN;MLDEV BIN).  This caused AI to appear as a
device.  ML's and DM's DEVICE directories are consistent (and
hopefully have the correct programs).

For AI:

I installed the TCP NAME user/server program.  :F @AI from MC now
works.  :F @MC from AI does not because AI tries to use the
chaosnet!!??!!.  The host table on AI says it is arpanet only,
but apparently the system still has chaos code assembled in.  
:F @DM from AI does work.

I tried to make sure the user ITS JOBDEVs were correct.  MC:...
doesn't work, again because it tries to use the chaosnet.  DM:
does work though.

CSTACY, you should revise AI's greeting message (about MLSLV
services), clean up any mess I may have left around, and perhaps
assemble AI without chaosnet code (if that is the right thing).
\1f
Date: 7 February 1983 13:00 EST
From: Christopher C. Stacy <CSTACY @ MIT-MC>
To: BUG-ITS @ MIT-MC

there is now a kludge in NETWRK for $$TCP inserters
who bomb into ANALYZ, cuz I was getting bored with ISE0.
I (or someone) should write a real TCP analyzer frob for it sometime.
\1f
CENT@MIT-ML 02/07/83 01:37:39 Re: TCP NAME user/server
To: DCP at MIT-MC
CC: (BUG ITS) at MIT-ML, (BUG NAME) at MIT-ML, (BUG TCP) at MIT-ML
CC: KLH at MIT-MC
    Date: 6 February 1983 04:09 EST
    From: David C. Plummer <DCP @ MIT-MC>
    Subject:  TCP NAME user/server
    To: KLH @ MIT-MC
    cc: BUG-ITS @ MIT-MC, BUG-NAME @ MIT-MC, BUG-TCP @ MIT-MC

    I made the ITS name user and name server work under TCP.  I made some
    spazzes, and there was a NCP/TCP difference causing a little more
    lossage.
    ....
    I installed and pdumped this on MC, ML and DM (what's going on with
    AI?).  I tested it between MC and DM (both directions) and ML and DM
    (both directions).  Source is back in SYSEN2; (whence it came).

ai was down with minor disk lossage. please try installing now..
\1f
Date: 7 February 1983 00:37 EST
From: Ed Schwalenberg <ED @ MIT-MC>
Subject: Autospeed dialups and system crashes
To: BUG-ITS @ MIT-MC

If MC goes down and comes back up, and I've patiently remained dialled
up while it was down, it typically types out 30 or so "x" characters and
then just stays wedged, probably waiting for 300 baud input as opposed to
1200 baud which is what I normally use.  I guess optimal behavior would be
for the 11 to remember the baud rate and tell the 10 when it comes back up,
while suboptimal behavior would be to flush the 11's input buffer and then
retry autospeeding.  Lousy behavior would be to hang up on the user.  But
the current behavior is just about pessimal.
Obviously this is low-priority, though if somebody was to volunteer to fix
the symptom by simply having MC never go down I'm sure they'd get a penny
from JM.  I'd be willing to give them a quarter, myself!
\1f
Date: 6 February 1983 04:09 EST
From: David C. Plummer <DCP @ MIT-MC>
Subject:  TCP NAME user/server
To: KLH @ MIT-MC
cc: BUG-ITS @ MIT-MC, BUG-NAME @ MIT-MC, BUG-TCP @ MIT-MC

I made the ITS name user and name server work under TCP.  I made
some spazzes, and there was a NCP/TCP difference causing a little
more lossage.

Spazz 1: I completely blew it when doing the NETBLK for the LSN.
  I gave it %NSRFS as the wait state.  A lot of good that does!!
Spazz 2: I didn't know that a NETBLK for the LSN would probably
  return the new state as %NSRFC.  There is another NETBLK
  waiting for it to go out of %NSRFC.
Spazz 3: The /i switch (use IP/TCP) simply could not work.  There
  is a comment to this effect in the code.  Basically, :f /i@dm
  passes the /i on to DM, and :f @dm/i throws the /i away (this
  is conjecture, but seems to fit the data).  Therefore, it
  always uses TCP over the arpanet.

Difference: NCP didn't need a FORCE done to send the JCL to the
  other host?  I know TCP does, but there was now such call in
  the program.  There is now!

I installed and pdumped this on MC, ML and DM (what's going on
with AI?).  I tested it between MC and DM (both directions) and
ML and DM (both directions).  Source is back in SYSEN2; (whence it
came).

Ken, I know several people complained that ITS thought it had a
TCP NAME server but it never worked.  Could you ask them to try
again?  Thanks.
\1f
Date: 6 February 1983 02:48 EST
From: David C. Plummer <DCP @ MIT-MC>
To: BUG-ITS @ MIT-MC, BUG-TCP @ MIT-MC

The CHAOS ARPA server now behaves as follows:

Contact name TCP  tries to establish a  TCP connection
Contact name NCP  tries to establish an NCP connection, even
                  though it should never succeed.
Contact name ARPA tries to establish a  TCP connection.  If it
                  times out (15 seconds), then it tries an NCP
                  connection.

Auxiliary connections may work again, using the network protocol
that the primary connection is using.
\1f
Date: 1 February 1983 00:53 EST
From: David A. Moon <MOON @ MIT-MC>
To: BUG-ITS @ MIT-MC

Noticing that there was no CHAOS-TCP gateway on ML, I put one there.
I didn't bother testing it.
\1f
Date: 31 January 1983 18:07 EST
From: Richard Brenner <ASB @ MIT-MC>
To: BUG-ITS @ MIT-MC
cc: ASB @ MIT-MC, JPG @ MIT-MC

  JPG@MIT-MC 01/31/83 17:56:21 Re: Job A wants the TTY
  To: ASB at MIT-MC
  CC: JPG at MIT-MC
     ASB@MIT-MC 01/31/83 17:23:03 Re: Job A wants the TTY
     Recently there has been a change in the way that the user is notified
     that a proceeded Macsyma needs the tty.
     Formerly, notification would be issued only once while in another Macsyma,
     but it now appears that this occurs whenever a file is loaded.  To see
     this new behavior, start up a Macsyma, then after you get a (C1)
     ^Z it and ^P it.
     Then start a second Macsyma, and try something like
     INTEGRATE(X,X,0,1);
     I have not tried OA^K.
     I prefer the old behavior.
  This printout is done by ITS, not by MACSYMA, so we have no control 
  over it.  It happens whenever the job needs to go up to top-level for 
  something which may very well happen while a file is being loaded. 
  I'm not convinced there's been any change here, but if there has, it's 
  an ITS issue, not a MACSYMA issue.
\1f
Date: 31 January 1983 12:02 EST
From: Christopher C. Stacy <CSTACY @ MIT-MC>
Subject:  broken?
To: CENT @ MIT-ML
cc: BUG-ITS @ MIT-ML, BUG-PEEK @ MIT-ML
In-reply-to: The message of 01/30/83 00:28:08 from CENT at MIT-ML


AI (and some other machines probably) have a slighlyt buggy version of
PEEK.  Copy MC:SYSBIN;PEEK > to the machine, and load up a job
with it. Type $G and it will install itself.  Ill do this if I get a
chance today.



\1f
HDT@MIT-ML 01/31/83 00:35:39
To: (BUG ITS) at MIT-ML
How can I get its typeout into a wall paper?
 (ie. the functionality of twenex's photo)
\1f
DCP@MIT-MC 01/30/83 13:22:25
To: rms at MIT-ML
CC: (BUG ITS) at MIT-ML
    rms@MIT-ML (Sent by ___014@MIT-ML) 01/29/83 17:48:54
    TELNET on a Lispm gets no response from the TCP server on ML or MC
    trying to go to CMUA
    even though ML is up and can successfully finger CMUA.

It works for me, although the output from CMU is completely
garbaged.  Are you sure you are connecting to TCP and not to
ARPA?

\1f
CENT@MIT-ML 01/30/83 00:28:08 Re: broken?
To: (BUG ITS) at MIT-ML, (BUG PEEK) at MIT-ML
:p on AI seems to be broken. when i try to kill a job, the display changes
from whatever before to show that job, but doesn't ask GUN THIS JOB?. i
think the problem is not that it thinks it has asked this and is waiting
for an answer (typing y does not seem to do anything).  i do give an
argument, so it isn't that, unless . is broken in some fashion. :p on ML
behaves properly, so perhaps the version on AI is bad somehow?
\1f
Date: 29 January 1983 21:11 EST
From: David A. Moon <MOON @ MIT-MC>
To: BUG-ITS @ MIT-MC

ML-device service between ML and MC now uses Chaosnet.
Relink DEVICE;JOBDEV ML/MC if there are any fatal problems.  Let
me know if there are any problems.

Making links does not work across this.  I don't think it worked
the old way either, unless it was patched in the binary and not
fixed in the source.  I'll probably fix this tomorrow (the two
ends don't seem to agree on what the protocol is for sending over
the arguments to the MLINK system call)
\1f
Date: 29 January 1983 20:43 EST
From: Steven A. Swernofsky <SASW @ MIT-MC>
Subject:  mail from 1200400006
To: BUG-ITS @ MIT-MC, BUG-MAIL @ MIT-MC
cc: SASW @ MIT-MC

I have been receiving messages which read
    "You have net mail from 1200400006:"
followed by the normal message which indicates the receipt of mail.  I
think this is wrong.  Is it?

-- Steve
\1f
Date: 29 January 1983 20:29 EST
From: David A. Moon <MOON @ MIT-MC>
Subject: MLSLV...
To: ELLEN @ MIT-MC
cc: BUG-ITS @ MIT-MC, BUG-TCP @ MIT-MC

There do seem to be lots of cases of things like MLSLV's that think
their connection is open, but the foreign host doesn't know about
that connection, and JOB.nn's (MLDEV's) that have an open connection
and no owner anymore.  Note that neither program has been changed.
Probably the advent of TCP has made the NCP implementation in the
IMPs more unreliable?

The Chaosnet version of the ML device certainly won't have these
problems, and the TCP version shouldn't, so when they're installed
things should look up.  I guess I'll go ahead and install the
Chaosnet version between ML and MC now.
\1f
rms@MIT-ML (Sent by ___014@MIT-ML) 01/29/83 17:48:54
To: (BUG ITS) at MIT-ML
TELNET on a Lispm gets no response from the TCP server on ML or MC
trying to go to CMUA
even though ML is up and can successfully finger CMUA.

\1f
Date: 29 January 1983 01:41 EST
From: V. Ellen Golden <ELLEN @ MIT-MC>
Subject: MLSLV...
To: BUG-ITS @ MIT-MC
cc: BUG-TCP @ MIT-MC

There seems to be a pattern developing of MLSLVs opening connections
and then lying around.  In some cases this may be due to a system down,
but shouldn't it time out?

At this moment there are three such, all from ML or AI.  ML and AI are
both up now.
\1f
Date: 28 Jan 1983 1624-EST
From: S. W. Galley <SWG@MIT-XX>
Subject: Re: con't...
To: ALAN@MIT-MC
cc: BUG-ITS@MIT-MC
In-Reply-To: Your message of 23-Jan-83 2145-EST

Don't panic!  DM is now running COMSAT, and I have converted
the birthday-greeting program suitably -- it's independent of COMSYS.
-------
\1f
Date: 27 Jan 1983 1056-EST
From: P. David Lebling <PDL@MIT-XX>
To: CStacy@MIT-MC, ALAN@MIT-MC
cc: BUG-ITS@MIT-MC
In-Reply-To: Your message of 25-Jan-83 1528-EST

Comsat has been launched on DM.  What I have done to (temporarily)
deal with COMSYS is to convince it that all net mail gates through
MIT-DMS (which will send it via Comsat, since FTP produces .MAIL.
files).  Eventually, stuff which produces Comsys request files should
be changed by whomever is responsible for them.

In any case, DM now is running a fully compatible Comsat, and Comsys
is only run by hand periodically (by me).

        Dave
-------
\1f
Date: 25 January 1983 23:35 EST
From: Ken Harrenstien <KLH @ MIT-MC>
Subject: TCP for PEEK
To: BUG-TCP @ MIT-MC, BUG-PEEK @ MIT-MC, BUG-ITS @ MIT-MC

PEEK on MC has had some TCP connection status display stuff added.
It is not very elegant but should suffice for a while.
\1f
Date: 25 January 1983 15:28 EST
From: Christopher C. Stacy <CStacy @ MIT-MC>
To: ALAN @ MIT-MC
cc: BUG-ITS @ MIT-MC
In-reply-to: The message of 23 Jan 83 21:45-EST from Alan Bawden <ALAN at MIT-MC>

Apparently no one wants to hack TCP for COMSYS in the old Muddle
it runs in.  I installed a ready-to-launch COMSAT on DM a while
back, and I think PDL and company are going to start running it
before February.  I'll do something about birthday messages.
\1f
Date: Sunday, 23 January 1983  22:51-EST
Sender: KLOTZ @ MIT-OZ
From: Leigh L. Klotz <KLOTZ @ MIT-MC>
To:   Alan Bawden <ALAN @ MIT-OZ>
Cc:   BUG-ITS @ MIT-MC
Subject: con't...
In-reply-to: The message of 23 Jan 1983 21:45 EST from Alan Bawden <ALAN>

Happy birthday...
\1f
Date: 23 January 1983 21:45 EST
From: Alan Bawden <ALAN @ MIT-MC>
Subject: con't...
To: BUG-ITS @ MIT-MC

I noticed this because I missed my yearly birthday greeting message
from COMSYS.  Clearly if COMSYS is going away, we need a crash program
to move this functionality to some other program!
\1f
Date: 23 January 1983 21:41 EST
From: Alan Bawden <ALAN @ MIT-MC>
Subject: COMSYS?
To: BUG-ITS @ MIT-MC

So just what is the story with mailers on DM?  Someone has sort of
installed COMSAT there, except it isn't running.  COMSYS isn't running
either, and there is a small queue of messages on the COMSYS directory
waiting to be sent.  I suppose the fact that DM is running a pre-TCP
version of ITS might have something to do with all this...
\1f
Date: 21 January 1983 10:51 EST
From: Ken Harrenstien <KLH @ MIT-MC>
To: BUG-ITS @ MIT-MC

If ITS system mem (LMEMFR) is zero for more than a few seconds, a system
console message should be printed so that it's more obvious why things
are losing.  MC has been skirting this (and falling victim to it) dangerously
often lately during peak load.
\1f
Date: 20 January 1983 03:28 EST
From: Tom Knight <TK @ MIT-MC>
To: BUG-ITS @ MIT-MC

MC was catatonic tonight with the sysjob hung on the core job.
I took a dump, crash corrq.  It was stopped with key 0.
The microcode had to be reloaded before I could get the system
to load, which might be related.
\1f
Date: 19 January 1983 15:27 EST
From: Christopher C. Stacy <CSTACY @ MIT-MC>
To: mhk @ MIT-ML
cc: BUG-ITS @ MIT-MC

AI crashed with a parity error.
\1f
MHK@MIT-ML 01/19/83 11:08:23
To: (BUG ITS) at MIT-ML
I was just on AI about 15 mins. ago.  I think it may have crashed on
me while I was trying to look at the following problem:
:f @its bought me:
[
ERROR;  10107>>PUSHJ 17,13251

Since your DDT lokks quite different from ours, and I don't know
your calls very well, I didn't get very far and then the machine went away.

\1f
CENT@MIT-ML 01/17/83 03:04:05 Re: its bugs
To: DCP at MIT-MC
CC: (BUG ITS) at MIT-MC
    Date: 14 January 1983 14:13-EST
    From: David C. Plummer <DCP @ MIT-MC>

    Where are the old bug reports?  MC;SYSTEM;ITS BUGS only goes back
    to 7/25/81.  At first glance, the file on AI is not any better.

AI:SYSTEM;ITS OBUGS goes back to 1 June 79..
\1f
Date: Sunday, 16 January 1983  16:28-EST
From: MOON at SCRC-TENEX
To:   David C. Plummer <DCP at SCRC-TENEX>
Cc:   bug-its at MIT-MC, BUG-LISPM at MIT-OZ, bug-minits at MIT-MC,
      bug-supdup at MIT-MC, bug-twenex at MIT-XX at MIT-MC,
      Henry at MIT-OZ, unix-chaos at MIT-VAX
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>

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.
\1f
Date: 16 January 1983 13:46 EST
From: David C. Plummer <DCP @ MIT-MC>
Subject: Supdup windows on color screen
To: DCP @ SCRC-TENEX
cc: BUG-ITS @ MIT-MC, BUG-MINITS @ MIT-MC, BUG-SUPDUP @ MIT-MC,
    unix-chaos @ MIT-VAX, BUG-LISPM @ MIT-OZ, Henry @ MIT-OZ,
    bug-twenex @ MIT-XX

OOPS.  The complete paragraph from page 3, the first part of
which is just as vital as the second:

The TCMXH variable specifies the line width in number of characters.  This
value is one less  than the screen width  (ITS indicates line overflow  by
outputting an exclamation  point at  the end  of the  display line  before
moving to the  next line).  Note:  the terminal must  not do an  automatic
CRLF when a  character is  printed in the  rightmost column.   If this  is
unavoidable, the user SUPDUP must decrement the width it sends by one.
\1f
Date: Sunday, 16 January 1983, 12:35-EST
From: David C. Plummer <DCP at SCRC-TENEX>
Subject: Supdup windows on color screen
To: BUG-LISPM at MIT-OZ, bug-its at MIT-MC, bug-twenex at MIT-XX,
    bug-minits at MIT-MC, unix-chaos at MIT-VAX, bug-supdup at MIT-MC
Cc: Henry at MIT-OZ
In-reply-to: The message of 15 Jan 83 23:43-EST from Henry Lieberman <Henry at MIT-OZ>

Sorry if you get this 6 times because of all the mailing lists, but this
problem exists in many places, and should really be resolved on a global
scale.
                     ------------------------------
What we need to do is document what ITS expects to see for line width,
and what it expects the terminal to do when you try and type something
on the last line (stick versus wrap).  We should then make sure each
user implementation and the non-ITS servers strictly obey this.  (If you
read the SUPDUP RFC [a copy in MC:DCP2;RFC SUPDUP], you will find the
following, which I think is sufficient for everybody to check their
programs.

[Page 2]
The SUPDUP protocol originated as the internal protocol used between parts
of ITS, and between ITS and "intelligent" terminals.  Over the network,  a
user host acts like an intelligent terminal programmed for ITS.

[later in Page 2]
Because this is also the internals of ITS, the right to change it any time
if necessary to provide new features  is reserved by MIT.

[Page 3]
Note:  the terminal must not do an automatic CRLF when a character is
printed in the rightmost column.  If this is unavoidable, the user
SUPDUP must decrement the width it sends by one.
\1f
Date: 14 January 1983 21:37-EST
From: David C. Plummer <DCP @ MIT-MC>
To: BUG-ITS @ MIT-MC

MC was found catatonic tonight.  Taft says this is a recurring
phenomena.  The symptoms were: extrememly long wait to get a
chaos supdup connection (if at all).  STATUS answered
immediately, however.  ^Z from the console keybaord and the VT52
took a long time to respond.  After that, loading a file looked
like it was doomed to failure (though if I waited long enough, it
may have loaded).  SYS^F, SYS1^F, .TEMP.^F all failed to give me
a directory listing.  It's been a long time since I've played at
the console, so CRASH;011483 LOOP may or may not contain anything
useful.  warm boot reload worked.
\1f
Date: 14 January 1983 14:13-EST
From: David C. Plummer <DCP @ MIT-MC>
To: BUG-ITS @ MIT-MC

Where are the old bug reports?  MC;SYSTEM;ITS BUGS only goes back
to 7/25/81.  At first glance, the file on AI is not any better.
\1f
Date: 14 January 1983 14:05-EST
From: David C. Plummer <DCP @ MIT-MC>
Subject: IOT control bits
To: ALAN @ MIT-MC
cc: BUG-ITS @ MIT-MC, GSB @ MIT-MC

I think I noticed this 2 years ago, and I though Moon fixed it.
Oh well.  I discovered it by trying to turn a DDT display channel
into super-image-output by toggling both bits.  Great way to send
ARDS pictures to your friends...
\1f
Date: 14 January 1983 02:57-EST
From: Alan Bawden <ALAN @ MIT-MC>
Subject:  IOT control bits
To: BUG-ITS @ MIT-MC
cc: GSB @ MIT-MC

This doesn't work as advertized:

        .call [setz ? sixbit /iot/
                [%tipek,,ttyich]
                setzm t]

While this does:

        .call [setz ? sixbit /iot/
                %clbit,,%tipek
                movei ttyich
                setzm t]

We could just fix the documentation of the IOT call to not claim that the
left half of the first argument is XORed with the control bits...
\1f
Date: 13 Jan 1983 1432-EST
From: CSTACY at MIT-DMS (Christopher C. Stacy)
To: bug-its at MIT-DMS
Message-id: <[MIT-DMS].254621>

There is a hacked PEEK which is patched around the init problem in
my directory on DM; I linked SYS;TS PEEK to it for the moment, until
PEEK gets fixed.


\1f
Date: 13 January 1983 13:20-EST
From: Christopher C. Stacy <CSTACY @ MIT-MC>
To: BUG-ITS @ MIT-MC

In ITS 1317 or higher on DM only, PEEK blows up trying purify
itself.  It dies trying to get a page at INITA.
\1f
Date: 13 January 1983 07:59-EST
From: David C. Plummer <DCP @ MIT-MC>
To: BUG-ITS @ MIT-MC
cc: DEVON @ MIT-MC

I updated .INFO.;ITS .CALLS and .INFO.;ITS TTYVAR to reflect the
fact that TTYOPT bit 1.3 is indeed in use, and is
        1.3     %TPRSC  This tty can do region scrolling.
As defined in SYSTEM;BITS >.
\1f
Date: 13 January 1983 06:38-EST
From: Devon S. McCullough <DEVON @ MIT-MC>
Subject:  supdup for personal computers
To: DCP @ MIT-MC
cc: BUG-ITS @ MIT-MC, GRUPP @ MIT-MC
In-reply-to: The message of 13 Jan 1983 04:46-EST from David C. Plummer <DCP @ MIT-MC>


What I am trying to convey is, that we need a way to tell ITS to send
%TDQOT's argument without sending the %TDQOT itself, even when the
TCTYP is SOFTWARE, so that programs can use %TDQOT to talk funny
protocols without the necessity of changing TCTYP to PRINTING and back.


Inventing something like :TCTYP SUPDUP would work for dialups but not
for network connections, because network servers currently assume that
any %TDORS byte sent as output was caused by an output reset (they
have no way of telling whether this is so) and do the equivalent of an
output reset for telnet or whatever.  If the user wants to actually
send a %TDORS byte as data it must be quoted, as in %TDQOT %TDORS.

This means that a network server talking to a TAC with :TCTYP SOFT
must see the %TDQOT's, but only send the argument, not the %TDQOT.
On the other hand, a server talking to another SUPDUP serving host
does indeed want to pass along %TDQOT's uncensored.

By the way, the current (losing) TCP server recognises %TDORS but not
%TDQOT, so that funny microcomputer programs LMODEM and SLOSTY which
have long worked with NCP are now broken under TCP.
\1f
Date: 13 January 1983 04:46-EST
From: David C. Plummer <DCP @ MIT-MC>
Subject: supdup for personal computers
To: DEVON @ MIT-MC
cc: BUG-ITS @ MIT-MC

    Date: 13 January 1983 01:51-EST
    From: Devon S. McCullough <DEVON @ MIT-MC>

    TTYOPT bit 1.3 seems to be available.  Let's call it %TPQOT and simply
    have network servers look at this bit to decide whether %TDQOT should
    be sent or not, instead of checking for TCTYP=%TNSFW as is done now.
I don't understand your problem, and that won't work anyway.  My
understanding of the ITS terminal system is that characters are
translated as they are pulled out of the ITS terminal buffer.  If
the terminal type is software, then no translation is done.
Because you are on a software terminal ITS will not look at
anything (including %TDQOT) and therefore just send it out.
Also, this translation is probably done before the implemention
of STYNET sees the character, so "have network servers look" will
do no good.  The net result is that what you send to a
super image output channel that is %TNSFW is exacly what the
other end (terminal or STY) will see.  You do get raw 8bit
strings.
\1f
Date: 13 January 1983 01:51-EST
From: Devon S. McCullough <DEVON @ MIT-MC>
Subject:  supdup for personal computers
To: GJC @ MIT-MC
cc: BUG-ITS @ MIT-MC
In-reply-to: The message of 12 Jan 1983 12:45-EST from George J. Carrette <GJC @ MIT-MC>

I've been using SUPDUP on 8080 and 6502 personal computers to access
ITS for years now, started using data compression about a year ago.
My program SLOSTY is a modified PTY which does a simple Huffman code.
I was planning to move up to fractional bits and other hairy codings,
but lost interest when I quit logging in via the ARPAnet.

Not being able to output arbitrary 8-bit strings defeats the whole
purpose of doing data compression.  It *IS* possible to output 8-bit
strings from ITS, but it requires the ugly kludge of setting TCTYP to
PRINTING in order for %TDQOT and %TDORS to work properly, restoring
the original TCTYP when done.

TTYOPT bit 1.3 seems to be available.  Let's call it %TPQOT and simply
have network servers look at this bit to decide whether %TDQOT should
be sent or not, instead of checking for TCTYP=%TNSFW as is done now.
\1f
CSTACY@MIT-AI 01/13/83 01:18:34
To: (BUG ITS) at MIT-AI
AI is back up now.

\1f
Date: 13 January 1983 00:12-EST
From: Christopher C. Stacy <CSTACY @ MIT-MC>
To: BUG-ITS @ MIT-MC

MC seemed to be wedged: I could not login at the console or from my
FILE job. Some other file job did get on tho, but I still coldnt get
anything out of the terminal. I paused the system and I think the
SYS job was running.  I continued it, and it went into a very tight
loop.  This time SW0 didnt work. I got into DDT and found that U was
zero.  Dumped to CRASH2;LOOOP SYS and reloaded XITS.
\1f
Date: 12 January 1983 12:45-EST
From: George J. Carrette <GJC @ MIT-MC>
Subject: supdup for personal computers
To: DEVON @ MIT-MC
cc: BUG-ITS @ MIT-MC

Do you actually have this and the datacompression implemented? On
what machines?

By the way, you should not really need to send arbitrary eight-bit-strings
just because you are doing data-compression. Certainly it is more
convenient if you do, but you can certainly encode the information
in whatever arbitrary characters that are available.

\1f
Date: 11 January 1983 20:59-EST
From: Devon S. McCullough <DEVON @ MIT-MC>
To: BUG-ITS @ MIT-MC
cc: DEVON @ MIT-MC, GRUPP @ MIT-MC, RWH @ MIT-MC
In-reply-to: The message of 01/10/83 18:22:27 from GSB@MIT-ML

In order to support data-compression and other non-SUPDUP protocols
peculiar to personal computers, we need to be able to output ARBITRARY
EIGHT BIT STRINGS to the user.  ITS currently does this in a grossly
crappy way, using %TDQOT in Super-Image output mode.  Since this is
the ONLY mechanism for doing this, it shouldn't interact with the
user's TCTYP, but it does.  Users with terminals that happen to
understand %TD codes get screwed because ITS does not simply send
%TDQOT's argument, it sends the %TDQOT as well.  This is no good.

There should be a +%TPSUP bit analogous to %TPTEL to say you are
talking to a SUPDUP connection.  Programs that check TCTYP=%TNSFW now
should look at this bit instead.  
\1f
Date: 11 January 1983 18:54-EST
From: David A. Moon <MOON @ MIT-MC>
Subject:  RFNAME bug
To: BUG-ITS @ MIT-MC

    Date: 10 January 1983 17:46-EST
    From: David A. Moon <MOON @ MIT-MC>
    To: BUG-ITS @ MIT-MC

    RFNAME on another job's channel clobbers that job's UUAC
    (via CHNDCD via NRFNM1) without pclsring the job, probably
    causing it to go off and do weird things.
Fixed in the source (SYSHAK;ITS)
\1f
Date: 10 Jan 1983 1658-EST
From: SWG at MIT-DMS (S. W. Galley)
To: bug-its at MIT-DMS
Subject: SYSTEM CLOBBERED
Message-id: <[MIT-DMS].254428>

DM has been getting a lot of these lately, e.g.

SYSTEM CLOBBERED BETWEEN 144467 AND 112110 XOR= 350231,,746375 ! 07:10:02
 76277 71061 56520 40711 163616 115205 54000 152343 30356 113152 176000 27310 2104 50054 116051 127647 121075 61070 170210 123760 42430 16237 13201 134467 174067 166377 36562 56473 13506 152102 42527 121674 141177 131607 43454 61376

What do all those numbers mean?  Where is the problem?

\1f
Date: 11 January 1983 01:32-EST
From: Christopher C. Stacy <CSTACY @ MIT-MC>
Subject: AI is down
To: BUG-ITS @ MIT-MC

AI is sick.  It runs sometimes for a while, with random jobs
getting random parity errors.  Sometimes the system gets an
exec mode parity error.   Just now it got KA: APR ERROR IN NULL JOB.
\1f
Date: 10 January 1983 17:46-EST
From: David A. Moon <MOON @ MIT-MC>
To: BUG-ITS @ MIT-MC

RFNAME on another job's channel clobbers that job's UUAC
(via CHNDCD via NRFNM1) without pclsring the job, probably
causing it to go off and do weird things.
\1f
Date: 10 Jan 1983 1248-EST
From: SWG at MIT-DMS (S. W. Galley)
To: KLH at MIT-DMS, BUG-ITS at MIT-DMS
Subject: DM crash at 12:30
Message-id: <[MIT-DMS].254414>

Job #9 was looping thru all PC values, apparently.
PI 3 in progress, PI 1 request, no clock interrrupts, no EXEC mode.
Dumped in DM:CRASH;JOB9 LOOP.

\1f
Date: 10 Jan 1983 1247-EST
From: SWG at MIT-DMS (S. W. Galley)
To: KLH at MIT-DMS, BUG-ITS at MIT-DMS
Subject: DM crash
Message-id: <[MIT-DMS].254413>

... at 11:00 at UQL5A+15.  Dumped in DM:CRASH;UQL5A +15.

\1f
Date: 10 January 1983 04:09-EST
From: RWK, CSTACY @ MIT-MC
Sender: CSTACY @ MIT-MC
Subject: DDT on MC
To: BUG-ITS @ MIT-MC


There is no (known) reason why we should not be running the
latest DDT, which RWK thinks has all the needed patches and
no other changes from the last correctly installed one.

(Well, there was one set of bogus changes...  sigh --RWK)

Anyway, we debugged them, and installed them (MC only).
I had thought CSTACY was going to install DDT from the
sources some months ago, apparently he thought I was.
So we did.
\1f
Date: 10 January 1983 01:56-EST
From: Christopher C. Stacy <CSTACY @ MIT-MC>
Subject: DDT on MC
To: BUG-ITS @ MIT-MC
cc: JPG @ MIT-MC


The DDT installed on MC was an old one which did not have
the fix for the old :REAP command bug.  Not understanding
quite why this version was installed, I re-installed the
DDT from SYSBIN;DDT BIN.  This version has the fix.

RWK thinks the source for DDT has all the patches, but I noticed
it didnt have the :REAP fix, so I put that into the source.
\1f
Date: 10 January 1983 00:27-EST
From: Herb Lin <LIN @ MIT-MC>
To: VUG-ITS @ MIT-MC, BUG-ITS @ MIT-MC

can some system wizard tell me the format of tapes written on MC?
density, block size, all that kind of stuff?  i need to know
for a machine to which I would like to move some MC files by tape.

tnx.
\1f
Date: 9 January 1983 07:47-EST
From: David C. Plummer <DCP @ MIT-MC>
Sender: DCP0 @ MIT-MC
To: BUG-CSTACY @ MIT-MC
cc: BUG-ITS @ MIT-MC

I'm trying to run the syseng;hosts xfile, and when it tries to ftp to sail, it looks like
the NETBLK timeout is around 4 minutes when it starts.  Is this really necessary?
\1f
Date: 8 January 1983 14:30-EST
From: David C. Plummer <DCP @ MIT-MC>
Subject: user/server times
To: CSTACY @ MIT-MC
cc: BUG-ITS @ MIT-MC

I fixed the source of :TIMES (in tcp;) to only wait 10 seconds
instead of 30 for the TCP connection to open/fail.  I thought you
could just use NETBLK...   
\1f
Date: 7 January 1983 23:20-EST
From: Christopher C. Stacy <CSTACY @ MIT-MC>
Subject: user/server times
To: BUG-ITS @ MIT-MC

I converted the :TIMES program along with the TIMSRV.  The TIMES
program has two run time switches called NCPTRY and TCPTRY.  It
defaultly tries both protocols and tells you which it won with.
Tested and installed on MC.
\1f
Date: 7 January 1983 20:24-EST
From: Christopher C. Stacy <CSTACY @ MIT-MC>
Subject: TIMSRV converted (big deal!)
To: BUG-ITS @ MIT-MC

I converted the time server (socket 45) for TCP as well as NCP.
It is installed on MC and works with NCP (we dont have a TCP user
to try it with yet.)   Source is TCP;TIMSRV.

Chris
\1f
Date: 3 Jan 1983 1554-EST
From: SWG at MIT-DMS (S. W. Galley)
To: KLH at MIT-DMS
Cc: bug-its at MIT-DMS
Subject: DM crash
Message-id: <[MIT-DMS].254017>

ITS 1312 crashed at 14:20 when SWPOPG was called with A/ 6.
I dumped it to DM:CRASH;SWPOPG A/6.


\1f
Date: 3 January 1983 15:06-EST
From: David A. Moon <MOON @ MIT-MC>
To: CSTACY @ MIT-MC
cc: BUG-ITS @ MIT-MC

    Date: 3 January 1983 00:26-EST
    From: Christopher C. Stacy <CSTACY @ MIT-MC>
    To: BUG-ITS @ MIT-MC

    In ITS 1315 on AI and ML, shutting the system down doesnt seem to work
    all the time.   I get the ITS NOT IN OPERATION message, but then it
    seems to go back to normal timesharing and you never get the SHUTDOWN
    COMPLETE message.  The pager lights look like it is running normal
    timesharing, although you can't login, and the data lights show only
    the SYS job getting run.
It doesn't shut down until various things are complete, such as all jobs
gunned down and the not in operation message typed out on all terminals.
Find the place that does the shutdown complete bug pause and see what
it was waiting for.  It could be that someone installed a daemon job
with OPTLIV that fails to finish itself up and go away.
\1f
Date: 3 January 1983 14:57-EST
From: David C. Plummer <DCP @ MIT-MC>
To: BUG-ITS @ MIT-MC

Now that ITS has TCP, would it be feasible to hack
the dover spooler to use the TCP route if the CHAOS route
appears to be down? I don't know all the addressing issues,
but if this is something that should be done, I'll help
look into it.
\1f
Date: 3 January 1983 00:26-EST
From: Christopher C. Stacy <CSTACY @ MIT-MC>
To: BUG-ITS @ MIT-MC

In ITS 1315 on AI and ML, shutting the system down doesnt seem to work
all the time.   I get the ITS NOT IN OPERATION message, but then it
seems to go back to normal timesharing and you never get the SHUTDOWN
COMPLETE message.  The pager lights look like it is running normal
timesharing, although you can't login, and the data lights show only
the SYS job getting run.
\1f
Date: Friday, 31 December 1982, 10:38-EST
From: David A. Moon <Moon at SCRC>
Sender: jek at SCRC-VIXEN
Subject: Chaosnet FILE server
To: BUG-TENEX at SCRC, BUG-TWENEX at XX, BUG-ITS at MC

I have installed new versions of the FILE server on EE,ML,MC,OZ,SCRC,SPEECH,XX.
Sources are on MC,OZ,SCRC,XX.  Please let me know if there are any problems.
The 20X version can be deinstalled by deleting SYSTEM:CHAOS.FILE.497.  The
ITS version can be deinstalled by copying MC:DEVICE;CHAOS OFILE to DSK:DEVICE;
CHAOS FILE.
\1f
Date: Wednesday, 29 December 1982, 23:36-EST
From: David A. Moon <Moon at SCRC-POINTER>
Subject: Chaosnet FILE server
To: BUG-TENEX at SCRC-POINTER, BUG-TWENEX at XX, BUG-ITS at MC

I have installed new versions of the FILE server on EE,ML,MC,OZ,SCRC,SPEECH,XX.
Sources are on MC,OZ,SCRC,XX.  Please let me know if there are any problems.
The 20X version can be deinstalled by deleting SYSTEM:CHAOS.FILE.497.  The
ITS version can be deinstalled by copying MC:DEVICE;CHAOS OFILE to DSK:DEVICE;
CHAOS FILE.
\1f
Date: 29 December 1982 23:41-EST
From: Ken Harrenstien <KLH @ MIT-MC>
Subject: Flow control in STYNET
To: BUG-ITS @ MIT-MC

After thinking about it for a while, I agree with Moon and you will
find that the TCP STYNET similarly lacks flow control on input.  This
not only provides the best approximation to being directly connected, but
also is by far the simplest way to avoid having things get hung up.
I don't see any point in "fixing" this, unless we also worry about
trying to fix direct and dialed-in TTY lines.  Note that the intelligent
terminal protocol does allow the terminal to hack flow control and make
sure that stuff gets to ITS (or whatever program) properly.

I guess you could compare this Alto lossage with someone trying to
play back a recording of modem tones into a MC dialup and expecting
ITS to exert flow control!
\1f
Date: 29 December 1982 23:33-EST
From: Ed Schwalenberg <ED @ MIT-MC>
Subject: STYNET connections from CHAOS net lacking flow control
To: BUG-ITS @ MIT-MC

A while ago someone complained to me that he was losing attempting to edit
a file on his Alto or something and then piss out the file as a command to
an ITS.  His symptom sounded like TTY input buffer overflow, i.e., the echoed
output was missing chunks, and had feeps instead.

I see that KLH just discovered that in Chaos STYNET, there is no flow control,
and Moon comments that it's only a problem with line-at-a-time input.  This
gives rise to two questions:  Is it similarly a problem with Arpa STYNET, and
is it worth fixing so that intelligent terminals and hosts can shove script
files across the network and have them work as expected?
\1f
Date: 24 December 1982 12:34-EST
From: Stavros M. Macrakis <MACRAK @ MIT-MC>
Subject: T1061 screwups
To: BUG-ITS @ MIT-MC
cc: KLH @ MIT-MC

Bug was on this end.  Sorry.
\1f
CENT@MIT-ML 12/19/82 23:02:10 Re: ai lossage
To: (BUG ITS) at MIT-ML
ai keeps halting. i keep continuing it.
\1f
Date: 11 December 1982 14:12-EST
From: Ken Harrenstien <KLH at MIT-MC>
To: BUG-ITS at MIT-MC, BUG-DDT at MIT-MC

It is kind of painful that DDT doesn't repurify itself or anything
when a new system is brought up.  Every other program now knows how
to do this.  I don't necessarily advocate that DDT actually dump
itself to SYS;ATSIGN DDT (a little dangerous since so much stuff
depends on that), but at least it ought to be able to re-set whatever
variables or stuff it has to, to compensate for running under a
new system version.  A little slower on startup, but at least not
fatal (as so many poor lusers are finding).  It definitely DOES keep
some people from logging in.
\1f
Date: 11 December 1982 02:44-EST
From: Jeffrey P. Golden <JPG at MIT-MC>
To: BUG-ITS at MIT-MC

MC:SYSTEM;ITS 1279 and ITS 1281 were the same!  So I deleted the 
former and linked it to the latter.
\1f
Date:  8 Dec 1982 2058-EST
From: Robert W. Kerns <RWK at SCRC-TENEX>
Subject: Re: bogus uptime record
To: SWG at MIT-DMS, BUG-ITS at MIT-MC
cc: KFL at MIT-AI, RWK at SCRC-TENEX
In-Reply-To: <[MIT-DMS].251798>

That's nothing.  Once when someone set the time wrong on MC, I claimed
to have been up for 2 years straight.  I felt much better when that was
straightened out, believe you me!
-------
\1f
Date: 8 Dec 1982 0942-EST
From: SWG at MIT-DMS (S. W. Galley)
To: BUG-ITS at MIT-MC
Cc: KFL at MIT-AI
In-reply-to: Message of 07 Dec 82 at 0439 EST by CStacy@MIT-MC
Subject: bogus uptime record
Message-id: <[MIT-DMS].251798>

For the same reason, DM claimed to have been up for about 300 days!

\1f
Date: Tuesday, 7 December 1982, 23:09-PST
From: David C. Plummer <DCP at SCRC-TENEX>
Subject: Re: SUPDUP TTYSMT
To: Barry Margolin at MIT-MULTICS, rsl at SCRC-TENEX
Cc: DCP at MIT-MC, BUG-ITS at MIT-MC, BUG-TWENEX at MIT-MC,
    BUG-SUPDUP at MIT-MC, BUG-LISPM at MIT-MC
In-reply-to: The message of 7 Dec 82 18:31-PST from Barry Margolin at MIT-MULTICS

    Return-Path: <Margolin@MIT-MULTICS.ARPA>
    Date:  7 December 1982 21:31 est
    From:  Barry Margolin at MIT-MULTICS
    Subject:  Re: SUPDUP TTYSMT
    To:  Richard Lamson <rsl at SCRC-TENEX>
    cc:  David C. Plummer <DCP at MIT-MC>, BUG-ITS at MIT-MC, 
         BUG-TWENEX at MIT-MC, BUG-SUPDUP at MIT-MC, 
         BUG-LISPM at MIT-MC
    In-Reply-To:  Message of 7 December 1982 21:23 est from Richard Lamson

    The TTYSMT variable already has other non-graphics information in it.
    It has information about local-editing and line-saving capability, I
    believe.
Indeed true.  To determine if the terminal supports supdup graphics you
test the BIT in ttysmt which is for that purpose; it is incorrect to
test the entire variable against zero.
\1f
Return-Path: <Margolin@MIT-MULTICS.ARPA>
Date:  7 December 1982 21:31 est
From:  Barry Margolin at MIT-MULTICS
Subject:  Re: SUPDUP TTYSMT
To:  Richard Lamson <rsl at SCRC-TENEX>
cc:  David C. Plummer <DCP at MIT-MC>, BUG-ITS at MIT-MC, 
     BUG-TWENEX at MIT-MC, BUG-SUPDUP at MIT-MC, 
     BUG-LISPM at MIT-MC
In-Reply-To:  Message of 7 December 1982 21:23 est from Richard Lamson

The TTYSMT variable already has other non-graphics information in it.
It has information about local-editing and line-saving capability, I
believe.
\1f
Date: Tuesday, 7 December 1982, 12:23-PST
From: Richard Lamson <rsl at SCRC-TENEX>
Subject: SUPDUP TTYSMT
To: David C. Plummer <DCP at MIT-MC>
Cc: BUG-ITS at MIT-MC, BUG-TWENEX at MIT-MC, BUG-SUPDUP at MIT-MC,
    BUG-LISPM at MIT-MC
In-reply-to: The message of 6 Dec 82 07:10-PST from Bernard S. Greenberg <BSG at SCRC-TENEX>

    Date: 4 December 1982 21:42-EST
    From: David C. Plummer <DCP at MIT-MC>
    To: BUG-ITS at MIT-MC, BUG-TWENEX at MIT-MC, BUG-SUPDUP at MIT-MC,
        BUG-LISPM at MIT-MC

    New field in the right half of the SUPDUP TTYSMT (TTY Smarts or
    graphics variable).

    DEFSYM      %TRTIM==003700
    DEFSYM      $TRTIM==060500  ;5 BIT FIELD WHICH IS THE SIGNED OFFSET FROM GMT
                            ;MINUS #o20; A VALUE OF ZERO MEANS DON'T
                            ;KNOW, DON'T CARE, OR USER PROGRAM HASN'T
                            ;IMPLEMENTED IT YET
Yoiks!  I was under them impression that TTYSMT was always going to be
reserved for graphics information only.  That is, a graphics server
would always be able to tell that the device didn't support graphics if
TTYSMT was zero.  Are you sure this is what you want to do, rather than
create a new user variable?

-- Richard
\1f
Date: 7 December 1982 11:21-EST
From: Christopher C. Stacy <CSTACY at MIT-MC>
To: BUG-ITS at MIT-MC


ITS 1283 is now running as NITS on AI.
ITS 1279 is called "ITS" on that machine.
\1f
Date: 7 December 1982 04:39-EST
From: Christopher C. Stacy <CStacy at MIT-MC>
To: BUG-ITS at MIT-MC, KFL at MIT-AI
In-reply-to: The message of 6 Dec 82 18:58-EST from KFL at MIT-AI

    KFL@MIT-AI 12/06/82 18:58:07
      Why does AI claim to have been up for 195 days?  "Surpassing all
    previous uptime records"?
                                                            ...Keith

Because the system time was wrong for a few minutes when it
first came up the other day.
\1f
CENT@MIT-ML 12/07/82 00:33:00 Re: ai up?
To: KFL at MIT-AI
CC: (BUG its) at MIT-MC
    KFL@MIT-AI 12/06/82 18:58:07
    To: (BUG its) at MIT-MC
      Why does AI claim to have been up for 195 days?  "Surpassing all
    previous uptime records"?  
i think it got confused during being brought up after the power
shutdown this past sunday, or maybe shortly thereafter. don't know how
though. the claim is wildly wrong.  cstacy, did you bring ai up?  do
you know anything more about this?
\1f
KFL@MIT-AI 12/06/82 18:58:07
To: (BUG its) at MIT-MC
CC: kfl at MIT-MC
  Why does AI claim to have been up for 195 days?  "Surpassing all
previous uptime records"?
                                                        ...Keith
\1f
Date: 5 December 1982 02:41-EST
From: David C. Plummer <DCP at MIT-MC>
To: uc.mp at MIT-EECS, jtw at MIT-SPEECH
cc: BUG-ITS at MIT-MC, BUG-TWENEX at MIT-MC, BUG-SUPDUP at MIT-MC,
    BUG-LISPM at MIT-MC

OK, OK.  For all of you who were wondering why in hell I did
this, I'll tell you.

Symbolics has imprisoned me in sunny southern California for 3
weeks.  I still log into MC occaisionally which isn't too
difficult since we do happen to be on the chaosnet.  If any of
you have ever seen me hacking on MC, my prompt that DDT prints
out has an amazing amount of junk in it.  One of those items is
the time.  Unfortunately, it is eastern time, not pacific time.
Sooo... ALAN and I started making joking comments to each other
about time zone correction in prompts, and this is what happened.

I don't know how many of us bug-its, bug-twenex, bug-supdup or
bug-lispm are going to take this seriously, but if I find some
spare time I may make local modifications to this LISPM and hack
my prompt code accordingly.  I will probably get around to
putting it in the KTVs and MINITS systems at some point in time.
\1f
Date: 4 December 1982 21:42-EST
From: David C. Plummer <DCP at MIT-MC>
To: BUG-ITS at MIT-MC, BUG-TWENEX at MIT-MC, BUG-SUPDUP at MIT-MC,
    BUG-LISPM at MIT-MC

New field in the right half of the SUPDUP TTYSMT (TTY Smarts or
graphics variable).

DEFSYM  %TRTIM==003700
DEFSYM  $TRTIM==060500  ;5 BIT FIELD WHICH IS THE SIGNED OFFSET FROM GMT
                        ;MINUS #o20; A VALUE OF ZERO MEANS DON'T
                        ;KNOW, DON'T CARE, OR USER PROGRAM HASN'T
                        ;IMPLEMENTED IT YET
\1f
Date: 30 November 1982 02:06-EST
From: Christopher C. Stacy <CSTACY at MIT-AI>
Subject: AI KA Inquire database
To: BUG-ITS at MIT-AI, (*MSG *AI) at MIT-AI

The Inquire database on AI was apparently smashed by a hardware
failure, and has been restored from about a week ago.  If you made
any modifications in the past week or two, you might want to check
to see if they were lost.  You can check by doing :WHOIS you@AI
from an ARPAnet ITS.


\1f
Date: 28 November 1982 07:45-EST
From: Christopher C. Stacy <CSTACY at MIT-MC>
Subject:  SYSMSG illoping - whats this all about
To: KMP at MIT-MC
cc: BUG-ITS at MIT-MC


It needed to be repurified, which I just did.  I guess I will make it
figure that out itself in the future.
\1f
Date: 27 November 1982 11:43-EST
From: Frank J. Wancho <FJW at MIT-MC>
Subject:  ARnn Structure
To: BUG-ITS at MIT-MC

The obvious answer to this query below would be to ignore the question
and simply tell him to use the ARnn:CPM;fn1 fn2 construct in FTP.
However, he is the first "outsider" to ask an intelligent question
about the actual structure of ARChive files.  Is there online
documentation or can someone create such info that I can send him?  I
believe such info would be valuable to other sites wishing to FTP an
entire ARChive file and *then* break it into its component files...

--Frank
--------------------

Date: 25 Nov 1982 2020-PST
From: Jorge Phillips <JP at SU-AI>
Re:   cpm; directory 

Hi,

I hadn't accessed the CPM; directory at [MC] for a LOOONG time and
just found out that the directory's format has changed completely. I
tried ftp'ng one of the ARnn files (ARnn NSTAR) and found out that it
consists of sections of text and sections of control and non-printing
characters (apparently code, or file structure info). Do I need a
special program to access the contents of these files? Could you give
me some hints of the format and contents of the ARxx files?

Thanks for any help you can give.

-jp
\1f
Date: 24 November 1982 19:14-EST
From: Ed Schwalenberg <ED at MIT-MC>
Subject: Great idea for program
To: ALAN at MIT-MC
cc: BUG-ITS at MIT-MC, BUG-RANDOM-PROGRAM at MIT-MC

What I wanted is a program that would do the calls in itself, assuming that
this was to be used for simple stuff like my example.  However, it would
be useful to be able to do it in another arbitrary inferior, so I applaud
your proposed extension.
\1f
Date: 24 November 1982 04:10-EST
From: Alan Bawden <ALAN at MIT-MC>
Subject:  Great idea for program
To: ED at MIT-MC
cc: BUG-ITS at MIT-MC, BUG-RANDOM-PROGRAM at MIT-MC

One way to write this tool would be to use the SYSCALL function in MacLisp.

Actually there is a problem that a lot of system calls have side effects on
specific jobs.  (Like the :IOPEN kludge opens a channel \in the current
job/.)  What you REALLY want then is a DDT command that does what you said,
but in the current job.  [The idea is to replace the sequence of commands
that usually starts by typing "J<alt>J 100/.CALL 200<tab>" with something
like "J<alt>J :DOCALL" right?]
\1f
Date: 24 November 1982 03:25-EST
From: David C. Plummer <DCP at MIT-MC>
Subject: Great idea for program
To: ED at MIT-MC
cc: BUG-ITS at MIT-MC, BUG-RANDOM-PROGRAM at MIT-MC

Interesting idea, but I don't think I'd say great.

    (This idea comes from having spent a ridiculous amount of time trying to
    find out the TTYSMT variable of a tty.)

That's easy: SYS^K TTYSMT+<ttynum>/

It's also in CNSGET, and I think it may be in TTYVAR (even though
:CALL doesn'tdocument it).
\1f
Date: 24 November 1982 03:13-EST
From: Ed Schwalenberg <ed at MIT-MC>
Sender: HDT at MIT-MC
Subject: Great idea for program
To: BUG-ITS at MIT-MC, BUG-RANDOM-PROGRAM at MIT-MC

:DOCALL prompts for a system call name, prints the relevant documentation
from ITS .CALLS, and prompts the user for the arguments to the call, with
special magical abilities to cons up <TTY>, <JOB>, etc. type args, or open
channels in the fashion of :IOPEN.  It then executes the call, and types
out the values for you, or types out the error code if it failed to work.
(This idea comes from having spent a ridiculous amount of time trying to
find out the TTYSMT variable of a tty.)
\1f
Date: 23 November 1982 20:37-EST
From: Ken Harrenstien <KLH at MIT-MC>
To: BUG-ITS at MIT-MC

I installed a new KSC;HOSTS2 BIN compiler.  If problems ae experienced
with the current SYSBIN;HOSTS2 >, then use KSC;HOSTS2 OBIN.
\1f
Date: Monday, 22 November 1982, 03:27-EST
From: Richard M. Stallman <RMS at MIT-OZ>
To: KLH at MIT-MC, EAK at MIT-MC
Cc: BUG-ITS at MIT-MC

I used to keep the source for any one program on only one machine.
It used to cause continual lossage to have any file in two places.
It's up to the people working on ITS, and maybe you can make it work out,
but don't assume things will work with multiple copies of sources
unless you are very careful.
\1f
Date: 21 Nov 1982 2231-EST
From: KLOTZ at MIT-OZ at MIT-MC
Subject: dover
To: bug-its at MIT-OZ at MIT-MC

Maybe there should be a program to hack the dover status
so people don't have to go read .dovr.;%dover broken which
tells them to create a file called .dovr.;.dovr. notice,
which is different from .dovr.;.dovr.;broken, which they
need to create too, but then have to gun the server (if
they can figure out what the user name is)...

ELLEN told me that when the dover goes down people still
queue things on MC and gobble up disk space.  Few people
know how (or take the trouble to) stop the server on MC,
possibly because it's so complicated.

Leigh.
-------


\1f
Date: 21 November 1982 02:43-EST
From: Ed Schwalenberg <ED at MIT-MC>
Subject: Re: MASTER mode screwing up TTY handling, but good!
To: RWK at SCRC-TENEX
cc: PGS at MIT-MC, BUG-ITS at MIT-MC

While I guess I can see that the superior would get no cycles at all,
that still doesn't explain the wedgitude of the STY's.  DCP and I had
fun for hours, trying to figure out how to unscrew things without being
able to log in.  I finally got it unwedged by halting and continuing
AI, but had to walk over to Tech Sq. to do it, which is cheating...
\1f
Date: 20 Nov 1982 1925-EST
From: Robert W. Kerns <RWK at SCRC-TENEX>
Subject: Re: MASTER mode screwing up TTY handling, but good!
To: PGS at MIT-MC, ED at MIT-MC
cc: BUG-ITS at MIT-MC, RWK at SCRC-TENEX
In-Reply-To: Your message of 20-Nov-82 1855-EST

PGS is right.  Other jobs in the same tree receive no CPU time while the
master-mode job is running.  If it waits for I/O or pages, then they may
get a quantum now and then.  I noticed this years ago and learned to be
careful.  Play with antisocial toys, and you'll get your fingers burnt!
-------
\1f
Date: Saturday, 20 November 1982  18:45-EST
Sender: PGS at MIT-OZ
From: PGS at MIT-MC
To:   Ed Schwalenberg <ED at MIT-MC>
Cc:   BUG-ITS at MIT-MC
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>

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.
\1f
Date: 20 Nov 1982 1313-EST
From: Robert W. Kerns <RWK at SCRC-TENEX>
Subject: Re: Feature
To: KLH at MIT-MC, BUG-ITS at MIT-MC
cc: RWK at SCRC-TENEX
In-Reply-To: Your message of 20-Nov-82 1253-EST

Sounds like an excellent idea.  Terminal 0 and/or whatever terminal
is the system console should probably be left alone, hardwired, though.

Perhaps this can be done by a demon loaded at startup, which simply
uses a special system call to copy the info?  Perhaps this call should
only work once, and then enable non-system-console terminals, and cause
the ITS IN OPERATION message to be printed when it is done.  This would
prevent clobbering terminals already in use.  Alternatively, it could
be careful and ignore terminals which are in use.  This would minimize
the amount of EXEC code and debugging.
-------
\1f
Date: 20 November 1982 12:41-EST
From: Ken Harrenstien <KLH at MIT-MC>
Subject: Feature
To: BUG-ITS at MIT-MC
cc: KLH at MIT-MC

ITS should probably read a binary parameter file on startup to
initialize its TTY tables rather than having them built in.
This table can be maintained by a simple utility program that
grovels over a source file, like HOSTSn does for HOSTS >.
The network code will need to do something similar in order to
initialize its gateway tables.
If no objections, I may go ahead and do this.
\1f
Date: 20 November 1982 02:42-EST
From: Ed Schwalenberg <ED at MIT-MC>
Subject: MASTER mode screwing up TTY handling, but good!
To: BUG-ITS at MIT-MC

I should know better than to frivolously show people MASTER mode, but anyway...
Proceeding a job in Master mode without the TTY causes output on that
TTY to be wedged, in that the <crlf>* that DDT echoes after ^P never happens.
Output from comm links continues to work, however.  Now for the real
killer:  if that tree is then detached, the poor sucker who reowns it gets
wedged, just by reowning it (his HACTRN says :$ Reowned $, then nothing more.)
Stealing MASTER mode away, by grabbing it in another process, results in the
wedged jobs continuing as if nothing had happened.

This was all on MC, just now, version 1283.  I tried to do the same thing on
AI, to determine whether it was KL-specific, and discovered to my horror that
not only does the same bug exist, but it apparantly wedges ALL sty's, since
I was unable to log in again to clean up, being told that All network ports were
in use!  (The original hackery was also via a STY, by the way; from the SIPB
plasma tv, to be specific.)
\1f
Date: 19 November 1982 19:23-EST
From: Richard Brenner <ASB at MIT-MC>
To: BUG-ITS at MIT-MC

When trying to :move a file into an archive that (unknown to me) was
full (no free files), I encountered the error
-CHANNEL NOT OPEN
This message was a little too obscure to be helpful to me, and it took
KLH a few minutes to figure out what was happening.  I clearer error
message would have helped quite a lot.
\1f
Date: 17 November 1982 22:05-EST
From: Ken Harrenstien <KLH at MIT-MC>
To: EAK at MIT-MC
cc: BUG-ITS at MIT-MC

    Date: 17 November 1982 21:00-EST
    From: Earl A. Killian <EAK at MIT-MC>

    I thought that sources were only supposedly to exist on one
    machine so that you never get copies out of sync and need to do
    merging.  Thus, if you copied things from AI to MC, you should
    delete them from AI.

Not necessarily, the main thing is to make it clear where the
canonical source actually lives, normally in a comment at the
start of the source file.  I don't think it would be a good
idea to have any machine (esp AI) totally without sources.
\1f
Date: 17 November 1982 21:00-EST
From: Earl A. Killian <EAK at MIT-MC>
To: CSTACY at MIT-MC
cc: BUG-ITS at MIT-MC

I thought that sources were only supposedly to exist on one
machine so that you never get copies out of sync and need to do
merging.  Thus, if you copied things from AI to MC, you should
delete them from AI.
\1f
Date: 17 November 1982 02:07-EST
From: Ken Harrenstien <KLH at MIT-MC>
Subject: Can't get there from here.
To: DCP at SCRC-TENEX
cc: BUG-ITS at MIT-MC, rp at SCRC-TENEX, rll at SCRC-TENEX

I rebooted the front-end 11 per MOON's instructions about 2 hours ago.
Local terminals were badly wedged, although Chaosnet connections seemd
to be going through okay; it was however complaining periodically that
no more chaosnet buffers were available.  A typical example of wedgedness
is that echo on the VT52 next to the console was at least 20 chars behind
typein, and some typein seemed to be getting lost or at least processed
in random spurts (only when one had pumped enough chars at it would anything
happen).
The rebooting seems to have fixed everything for now.  Moon apparently
thinks that the Dover spooler might have had something to do with
the overall problem, but you'd have to ask him for any details.  Something
was very obviously clobbered in the 11.  Perhaps when the Chaosnet goes
wild, something overflows into the TTY buffers/pointers or otherwise
throws a big wrench into the works?  Pure speculation, I'm not familiar
with it.  It might even be the other way around, that some glitch in
TTY handling (owing to the preponderance of "loose lines" blasting noise
at the front-end) is screwing up not only the TTYs but the Chaosnet.
\1f
Date: Wednesday, 17 November 1982, 01:52-EST
From: David C. Plummer <DCP at SCRC-TENEX>
Subject: Can't get there from here.
To: bug-its at mc
Cc: rp at SCRC-TENEX, rll at SCRC-TENEX

I had a chaos connection to MC die on me tonight.  (RP has complained
that he gets about two per day.)  When it happened to me I did some
quick poking and the MC-IO-11 was not responding to STATUS but other
hosts on subnet one were.  MC is now up (and has been for 14 hours) so
it looks like the 11 crapped.  A couple nights ago TAFT called me for
instructions on how to reload the 11.  Is this flaking out becoming
regular?  Does the person(s) reloading it remember anything special
about the circumstances (11 halted or running, ampex parity, dl10
parity, etc).
\1f
Date: 13 November 1982 20:37-EST
From: Christopher C. Stacy <CStacy at MIT-MC>
To: BUG-ITS at MIT-MC

PEEK automagically purifies and dumps out itself if necessary now.


\1f
Date: 13 November 1982 13:28-EST
From: Ed Schwalenberg <ED at MIT-MC>
Subject: T21 as well...
To: BUG-HARDWARE at MIT-MC
cc: BUG-ITS at MIT-MC

has been silenced.

\1f
Date: 13 November 1982 13:24-EST
From: Ed Schwalenberg <ED at MIT-MC>
Subject: MC T32 emitting continuous garbage.
To: BUG-HARDWARE at MIT-MC
cc: BUG-ITS at MIT-MC

I set the linespeed to 0 to disable T32, which was typing garbage at the
system.  Is there any documentation for LSPEED?  I went blithely ahead
and assumed that it worked like a reasonable program, but it would be
nice to know.  It would be similarly nice if the same programs worked for
all known TTY types, but this is rapidly becoming a dead issue.

\1f
Date: 13 November 1982 23:18-EST
From: Christopher C. Stacy <CStacy at MIT-MC>
To: BUG-ITS at MIT-MC

There were a number of program sources which did not exist or
were out of date on MC.  I brought them up to date from the ones
on AI, putting the overflow in the new SYSEN2; directory.  MC
should now be reagrded as the home of the most recent system
program sources.

I moved the BUG-ITS mailing list to MC, and updated pointers to
it on AI, ML, and DM.  The other bug-random-programs are still
on AI.  A copy of the AI NAMES file is in MC:KSC;AI NAMES.

Chris
\1f
KLH@MIT-MC 11/13/82 01:15:28 Re: another SRCCOM feature
To: (BUG ITS) at MIT-MC, (BUG SRCCOM) at MIT-MC
I hope this isn't bothering BUG-ITS people, but since I developed
this feature to help hack ITS I figure I might as well continue
with the SRCCOM announcements.  I added the /$ switch which
does a binary compare like /# but with the difference that the
files must be executable programs; SRCCOM will create two
inferior processes and load the files into them in order to compare
the two address spaces.  This completely flushes any spurious
diffs due to symbols, MIDAS info, blocking size, or SBLK/PDUMP
format.  Doesn't handle holey processes though; maybe later.

I updated INFO;SRCCOM > on MC.  I'm going to move the canonical
location of SRCCOM to MC, I think.

\1f
Date: 12 November 1982 23:08-EST
From: Christopher C. Stacy <CStacy at MIT-MC>
To: BUG-ITS at MIT-MC

I am adding some features to PEEK which will be useful for
TCP/IP debugging.  I added the trivial "+" mode today, sort of
as practice.  Installed on MC.

\1f
KLH@MIT-MC 11/12/82 13:05:17 Re: Binary compare feature
To: (BUG ITS) at MIT-MC, (BUG SRCCOM) at MIT-MC
I have installed a new SRCCOM on MC with a crude binary compare
feature.  Use switcch /# to compare two files word by word.
Interaction with other switches is likely to kill things.
If nobody (mostly me, I guess) finds problems with it over the
next few days, I'll install it in other places.
Note that two different assemblies of the same sources will not
produce identical binaries, because of the extra info that MIDAS
puts in about who assembled it when.  I'm not sure yet how to
bypass this.

\1f
Date: 11 November 1982 22:22-EST
From: Christopher C. Stacy <CSTACY at MIT-MC>
To: DCP at MIT-MC
cc: BUG-ITS at MIT-MC, KMP at MIT-MC, THREE-MINUTE-HATE at MIT-MC,
    Eric at MIT-EECS


I made a mailing list for discussing some of the random ideas inspired
by DCP's message about ITS on a VAX.  It doesnt have to be just about
VAX ITS, but it prevents message duplication and gets it off BUG-ITS.
Here's what the mailing list looks like now:

(VAX-ITS (EQV-LIST (FILE [DSK:CSTACY;VAXITS ARCHIV])
                         CSTACY DCP PGS ALAN KMP GUMBY DANNY KLH KLOTZ
                         HAL GREGOR CENT ZVONA RMS DEVON))


Feel free to add yourself...

Chris

\1f
Date: 11 November 1982 20:44-EST
From: David C. Plummer <DCP at MIT-MC>
To: KMP at MIT-MC
cc: BUG-ITS at MIT-MC, THREE-MINUTE-HATE at MIT-MC, Eric at MIT-EECS

[[Sorry for the message duplications...]]

    KMP@MIT-MC 11/11/82 17:46:24
    better than teach ITS, you should get a crew together and bring one up.

Unfortuantely that would require the cooperation of the owner(s)
of a machine up on which (garp) to bring it.  Here are the
options I know of:

There are rumors of the AI lab looking for a used -10 (KL
probably) to appease the people who can't stand 20X and would
prefer ITS.  This would be an idea machine.

Bring up ITS on an existing PDP-20.  The only machine this is
feasible on is OZ, and the feasibility of that seems to be
asymptotically approaching zero (unless you want to pull of a
coop some night).  This would also require some microcode
expertise.  Moon obviously comes to mind.  His commitment at
symbolics also comes to mind.

Bring it up on a non-10 architecture.  This would be a lot of
fun.  The obvious choice is a vax.  OK, who has the vax, who has
the time, and who has the money to sponser such a moderate
project?  (Be prepared to be able to answer "What's wrong with
Unix?"  I'm sure each one of us can give some very good answers,
but just be prepared.)

TK actually suggested writing a report on ITS which described its
winnages (.HANG for example) and its lossages (6 character,
non-hierarchical filenames).
\1f
KLH@MIT-MC 11/11/82 08:26:16 Re: Comsat address & NAMES >
To: JPG at MIT-MC
CC: CBF at MIT-MC, (BUG MAIL) at MIT-MC, (BUG ITS) at MIT-MC
If I have some spare time during this TCP hacking, I can look into
this.  The problem is not really that NAMES is so big, but that COMSAT
is so stupid about how it handles the compiled result.  There are at
least three things I can think of right away that would help eliminate
this problem (this does not mean they are easy to do).  For the time
being, keeping NAMES small ought to buy enough time.

\1f
JPG@MIT-MC 11/11/82 05:58:39 Re: Comsat address & NAMES >
To: CBF at MIT-MC
CC: (BUG MAIL) at MIT-MC, (BUG ITS) at MIT-MC
   CBF@MIT-MC 11/07/82 16:23:34 Re:  Comsat address & NAMES >
   To: (BUG MAIL) at MIT-MC, (BUG ITS) at MIT-MC
   CC: JPG at MIT-MC
   It seems that the only solution to the address space problem that avoids
   removing mailing lists right and left is to move the bulk of their
   contents into separate files and put entries in that are only (@FILE ...).
   Anyway, the problem with just going through NAMES > and arbitrarily
   moving mailing lists into files is figuring out where to scatter all these
   lists to.  They presumably each do have individual sponsers, but it is
   quite an effort to encourage each person to remove a mailing list to his own
   directory.  Considering what a bad idea it is to have COMSAT crashing all
   the time, I would therefore suggest that a precious MFD slot be given over
   to this purpose...
I have no objection to this, but I wish to point out that at least recently 
people have been cleaning out the NAMES file to the point where it is now 
just(?) 19 blocks, and COMSAT has been crashing much less frequently. 
Ah, but will this state last?

\1f
KLH@MIT-MC 11/10/82 15:50:51 Re: prev msg
To: (BUG ITS) at MIT-MC
Hmm, there is no longer a MIT-NET-CONNECT list.  I forwarded the
note to MIT-IN-GROUP and MIT-NETWORK-GROUP instead.  Just in case
anyone tries to reply to all recipients...

\1f
KLH@MIT-MC 11/10/82 15:44:32 Re: ITS TCP is coming...
To: (BUG ITS) at MIT-MC, MIT-NET-CONNECT at MIT-MC
I am now officially working on the installation of TCP/IP in ITS.
The ITS sources in MC:SYSTEM; should be considered write-locked
as of today; if you need to make some changes, see me to fold them
in.  Likewise, if you know that these sources are for some reason
NOT the latest stuff, tell me immediately.  Ditto any patches
that haven't yet been put in the source.  If more than a couple of
people are interested in following the progress of this stuff, I
will create a mailing list to keep them posted and possibly to
solicit opinions on certain design issues.
Here we go, folks!

\1f
Date: 9 November 1982 18:38-EST
From: David C. Plummer <DCP at MIT-MC>
To: CSTACY at MIT-MC
cc: BUG-ITS at MIT-MC, Bug-Twenex at MIT-XX

    Date: 9 November 1982 17:40-EST
    From: Christopher C. Stacy <CSTACY at MIT-MC>



    The system ran out of ARPAnet sockets (I think) and would not accept
    incoming TELNET connections. Other sites seemed to think MC had died.
    I looked, and there were about a dozen 054Jnn NETRFC jobs hung in
    CLFSH->XX/RDCLS<-XX. They were all doing a FINISH call at 12527.  I
    gunned most of them down.  I dont know what this frob is for, but ALAN
    looked at the job and thinks it some sort of BOJ handler for something
    to do with the DOVER, like RFC133.

    What was this job, and I wonder why there were all these hung ones?

Yes.  These are wedged XX jobs.  When I frequented MC I would
typically find several in one day.  Either ITS has a bug closing
connections, or XX has the bug (perhaps both).  I don't know NCP
so I don't know if the above state is reasonable.
\1f
Date: 9 November 1982 17:40-EST
From: Christopher C. Stacy <CSTACY at MIT-MC>
To: BUG-ITS at MIT-MC



The system ran out of ARPAnet sockets (I think) and would not accept
incoming TELNET connections. Other sites seemed to think MC had died.
I looked, and there were about a dozen 054Jnn NETRFC jobs hung in
CLFSH->XX/RDCLS<-XX. They were all doing a FINISH call at 12527.  I
gunned most of them down.  I dont know what this frob is for, but ALAN
looked at the job and thinks it some sort of BOJ handler for something
to do with the DOVER, like RFC133.

What was this job, and I wonder why there were all these hung ones?
\1f
CBF@MIT-MC 11/07/82 16:23:34 Re:  Comsat address & NAMES >
To: (BUG MAIL) at MIT-MC, (BUG ITS) at MIT-MC
CC: JPG at MIT-MC
It seems that the only solution to the address space problem that avoids
removing mailing lists right and left is to move the bulk of their
contents into separate files and put entries in that are only (@FILE ...).
I presume an @FILE takes up much less space than several name in a mailing
list.

Anyway, the problem with just going through NAMES > and arbitrarily
moving mailing lists into files is figuring out where to scatter all these
lists to.  They presumably each do have individual sponsers, but it is
quite an effort to encourage each person to remove a mailing list to his own
directory.  Considering what a bad idea it is to have COMSAT crashing all
the time, I would therefore suggest that a precious MFD slot be given over
to this purpose.  The names LISTS seems approriate, and it can store lists
and collect log files for otherwise homeless mailing lists.  This would
also provide a nice central place to look at when some disk storage is
needed (ie. by trimming old log files), which could actually result in
less disk storage being used by log files.

I'm not volunteering to do this quite yet, but if I don't hear any
objections I may create the dir and  start to do this at idle moments when
I'm bored.

\1f
CSTACY@MIT-MC 11/04/82 03:21:10
To: (BUG ITS) at MIT-MC

The pile-driving every few minutes at all hours  outside
Tech Square is apparently the cause of a very gross number
of T-300 failures and problems on the CADRs.  It seems to
be shaking them to death, crashing heads and doing other bad
things.

I noticed that there were quite a few disk errors happenning
on MC tonite. Is it likely that any of these are being caused
by the vibrations from outside?

\1f
KLH@MIT-MC 11/03/82 19:13:57
To: PGS at MIT-ML
CC: (BUG ITS) at MIT-MC
    PGS@MIT-ML 11/03/82 08:59:39
    ML ITS 1278 has been running for 33 days now.  Is this a record?
    (It certainly is on ML).

I think AI holds the record, something like 80 days.  The max uptime
is stored in the creation date of SYS:RECORD TIME on each machine,
starting from 0/0/00.

\1f
PGS@MIT-ML 11/03/82 08:59:39
To: (BUG ITS) at MIT-ML
ML ITS 1278 has been running for 33 days now.  Is this a record?
(It certainly is on ML).

\1f
MP@MIT-MC 11/02/82 14:37:25 Re: size of MC's mailing list file
To: (BUG MAIL) at MIT-MC, (BUG ITS) at MIT-MC
I sent some messages to a few lists that have been dormant for a few
years.  At the very least I hope to cut out some invalid addresses,
and with luck maybe a few lists can be flushed.

There are several lists that don't seem to have a clear maintainer,
(for instance, the chaosnet, bikes, c100-fans, calculators, and
multics-emacs lists); if they were to be moved into some indirect file
in someone's directory, it isn't obvious who that someone should be.
It would be nice to have a nice, non-volatile directory (USERS* and
GUEST* I consider volatile) to put assorted indirect files in.

\1f
MOON@MIT-MC 10/31/82 19:33:49
To: (BUG MAIL) at MIT-MC, (BUG ITS) at MIT-MC
I need to repeat my message saying that there will be no mail service on MC
if the NAMES file is not made smaller.  It is completely filling Comsat's
address space.
\1f
Date: Tuesday, 26 October 1982, 11:27-EDT
From: Patrick Sobalvarro <PGS at MIT-OZ>
Subject: ai down?
To: CENT at MIT-ML, phw at MIT-OZ, eric at MIT-EECS, bug-its at MIT-MC

    CENT@MIT-ML 10/26/82 04:47:18 Re: ai down?
    To: (BUG ITS) at MIT-ML
    i tried to supdup from ml to ai, by saying ai^H. after giving me
    the fallacious run-around about using the arpanet twice (because
    i was using ml from a chaos tip), it reported Host Dead. just to
    check, i tried :supdup ai /a. same result.
    however, ai was up durign this time. i was able to use it from
    its console. someone check this please?

AI wasn't down; in fact, it was running perfectly.  At 4:11 yesterday
afternoon, JNC took AI off the Arpanet to screw with the tips or the tacs or
whatever, and, well, he forgot to plug the boards back in.  When I couldn't get
to it this morning, TY said, "Oh, shit, that must have been Chiappa," and
called him up and got him to fix it.  The AI-10 is the AI Lab's only Arpanet
socket, and lots of people indirect through it to get their net mail to OZ.
Lots of important mailing lists are on AI (including BUG-ITS).  AI's Arpa port
is important to this lab, and I wish there were a less casual attitude about
fucking with it.

\1f
SHAWN@MIT-ML 10/26/82 06:38:45 Re: ":alarm"
To: (BUG ITS) at MIT-ML

Does the ":alarm" command REALLY work? it seems it does
the "wrong" thing for me all the time, (i.e. ":alarm .+00:"
works, and it takes it, not only that, but ":alarm .+01:"
sets for ".+17:23:55" when its 06:36:10am?), anyone
care to explain what I am doing wrong? if anything?

                Thanks
                  -shawn

\1f
CENT@MIT-ML 10/26/82 04:47:18 Re: ai down?
To: (BUG ITS) at MIT-ML
i tried to supdup from ml to ai, by saying ai^H. after giving me
the fallacious run-around about using the arpanet twice (because
i was using ml from a chaos tip), it reported Host Dead. just to
check, i tried :supdup ai /a. same result.
however, ai was up durign this time. i was able to use it from
its console. someone check this please?
\1f
Date: 22 October 1982 03:56-EDT
From: David C. Plummer <DCP at MIT-MC>
Subject: [Forwarded: COMSAT, Re: ]
To: BUG-ITS at MIT-MC

Sorry, I can't spel...
                 ------------------------------
COMSAT@MIT-MC 10/21/82 23:30:41 Re: Msg of Thursday, 21 October 1982 23:27-EDT
To: DCP at MIT-MC
A copy of your message is being returned, because:
"BUT-ITS" at MIT-MC is an unknown recipient.
        Message not sent.
 Failed message follows:
-------
Date: 21 October 1982 23:27-EDT
From: David C. Plummer <DCP at MIT-MC>
To: BUG-OZ at MIT-MC
cc: BUT-ITS at MIT-MC, MT at MIT-MC, ERIC at MIT-MC

There is a theory that part of the OZ wait-30-seconds problem is
that the AI-Chaos-11 does not always have the power to bridge
between subnets 6 and 1.  If chaos sites think that ai-chaos-11
is the best route, when indeed it cannot route, then there will
be a stalling effect until either ai-chaos-11 unwedges or
mc-io-11 becomes the best route.  This could take 15 to
30 seconds depending on how wedged ai-chaos-11 is.

If this is the problem, then I may have improved the situation.
I have modified the program that runs in ai-chaos-11 to give a
higher cost for the cable subnets than mc-io-11.  This should
cause subnet 6 sites to always use mc-io-11 to get to subnet 1
and vice-versa (except of course when mc-io-11 is down, in which
case the routing mechanism will figure out ai-chaos-11 can get
there).  This will take effect at the next reload of ai-chaos-11
(which happens to be down right now meaning no dover service to
chaos sites).

The correct solution, of course, is to put the oz-network-11 on
subnet 6 as well as subnet 1.  This is not happening due to a
lack of hardware (unibus chaos interfaces).

\1f
DCP@MIT-MC 10/21/82 00:09:16
To: (BUG HOST) at MIT-MC, (BUG ITS) at MIT-MC
I modified :HOST so that it now accepts multiple host as
arguments, separated by commas.  E.g.,
        :HOST MC,AI,ML,DM

\1f
MOON@MIT-MC 10/19/82 00:13:43
To: (BUG ITS) at MIT-MC
.;crash chaos is a crash where the system ran out of chaos buffers and
got slow (so I'm told).  All the buffers but one I could find were UNC's from
BAK DOVER to socket 21 (octal) on the Dover Alto.  Perhaps the IO-11 had really
crashed, and that's why it wasn't swallowing the packets.  Perhaps ITS should
notice when the number of packets on DLCXMQ gets large and start throwing them
away.
\1f
Date: 18 Oct 1982 2111-EDT
From: J. Noel Chiappa <JNC at MIT-XX>
Subject: [Ben Littauer <littauer at BBN-UNIX>: Re: TAC/ITS telnet bug?]
To: bug-its at MIT-AI

Mail-from: ARPANET site MIT-MC rcvd at 18-Oct-82 1844-EDT
Date: 18 Oct 1982 18:38:41 EDT (Monday)
From: Ben Littauer <littauer at BBN-UNIX>
Subject: Re: TAC/ITS telnet bug?
In-Reply-to: Your message of 14 Oct 1982 17:23:47 EDT (Thursday)
To: Ben Littauer <littauer at BBN-UNIX>
Cc: moon  at  SCRC-Tenex  at  MIT-MC, EAK @ mit-mc, REM @mit-mc,
    frye at BBN-UNIX, ditmars at BBN-UNIX, herman at BBN-UNIX,
    JNC at mit-mc

Good News! (again)

Well, the last patch wasn't QUITE enough, but we were on the right trail.
REM apparently had his hopes dashed this weekend when SU-TAC continued
displaying THE BUG.

Further testing and reading of spagetti code proved beyond a shadow of
a doubt that the "wedging" occurred when ITS sent the TELNET IAC character
in one message, and followed with the DataMark in the next.  Thumbing
through the coroutines eventually showed that we were returning wrong
in this case.

I have a patch, already in SU-TAC, which will be released to the rest of
the net tomorrow morning.  It still is possible that there is some other
case which causes wedging, so I won't claim that it can't happen again,
but I don't think that it will.  

Sorry for the first false hopes, hope this one works...

                                -ben-


-------
\1f
Date: 16 Oct 1982 1629-EDT
From: J. Noel Chiappa <JNC at MIT-XX>
Subject: [Ben Littauer <littauer at BBN-UNIX>: Re: TAC/ITS telnet bug?]
To: bug-its at MIT-MC

Mail-from: ARPANET site MIT-MC rcvd at 14-Oct-82 1818-EDT
Date: 14 Oct 1982 17:23:47 EDT (Thursday)
From: Ben Littauer <littauer at BBN-UNIX>
Subject: Re: TAC/ITS telnet bug?
In-Reply-to: Your message of 14 Oct 1982 11:26:31 EDT (Thursday)
To: Ben Littauer <littauer at BBN-UNIX>
Cc: moon  at  SCRC-Tenex @ MIT-MC, EAK @ mit-mc, REM @mit-mc, frye at BBN-UNIX,
    ditmars at BBN-UNIX, herman at BBN-UNIX, JNC at mit-mc

Good news!

I found a local ITS afficionado, and with his help I was able 
to get the bug to happen.  I discovered that what was happening
was that the TAC would receive an NCP INS, which TELNET needs
as a signal to start discarding terminal output, but it was
not finding a matching TELNET DataMark in the data stream, 
the signal to STOP discarding terminal output.  The funny thing
was that the symptoms were so intermittent.

Reading the TAC code, I found that if we receive a message 
containing the TELNET intercept character, IAC, in one message,
and the DataMark was the first character of the next message,
then the TAC would fail to see the DataMark.  I have patched
my test TAC and have since been unable to re-create the bug.
I therefore hypothesize that ITS will occasionally send the IAC
in one message and the DataMark in another: can any ITS network
hackers verify or refute this?

ARPANET TACs should have received the patch by tomorrow morning,
so I would greatly appreciate hearing whether there is indeed a
difference.  It is possible that this fix will also cure the
flakiness seen in negotiating TELNET binary mode with the TAC;
anybody who has experienced those difficulties, PLEASE tell me
if there is any change.

I'm sorry this bug has been hanging (no pun intended) around so
long, but I thank you for your patience and perseverence; we
do want to hear about bugs, and we try to fix them as soon as
possible, but the ones that people are finding now are getting
to be the more subtle ones, so they do take longer...

Your friendly neighborhood TAC "wizard".
                    -ben-

-------
\1f
CSTACY, PGS, ELLEN@MIT-MC (Sent by CSTACY@MIT-MC) 10/15/82 15:13:08 Re: for future reference
To: (BUG ITS) at MIT-MC
MC would not come up this afternoon due to some sort of
lossage in the T300 subsystem.  Running CHKR showed
that it couldnt frob the T300s; power cycling unit 3
de-confused it and the system came up ok.

\1f
Date: Wednesday, 13 October 1982  05:31-EDT
Sender: PGS at MIT-OZ
From: PGS at MIT-MC
To:   DCP at MIT-OZ, bug-its at mc
cc:   twenex-haters at MIT-OZ

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@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.
-------

\1f
Date: 10 October 1982 23:52-EDT
From: David A. Moon <MOON at MIT-MC>
To: PGS at MIT-OZ
cc: BUG-ITS at MIT-MC, akr at MIT-OZ

    Date: Sunday, 3 October 1982, 03:10-EDT
    From: Patrick Sobalvarro <PGS at MIT-OZ at MIT-MC>
    To: bug-its at MIT-OZ at MIT-MC
    Cc: akr at MIT-OZ at MIT-MC

    Alex Krymm (our new hardware person) has agreed to take a look at the prints
    for ML's Chaosnet interface and consider building one for AI.

    Questions:
    Is it really worth it?  That is, will this just be a lot of thankless work for
    him?  Or is it comparatively simple?  Is someone who understands the hardware
    well around to answer the occasional question?
I'll be happy to answer questions within the limited amount of time I have
available.

    Would he have to do
    wirewrapping, or do we have wirelists that we can send to Augat?
Of course not.  It would be machine-wrapped.

The only issue is finding documentation on the AI TTL I/O bus plus figuring
out whether it is still there.  It is unlikely to be 100% compatible with
the ML/DM TTL I/O bus, hence the Chaosnet interface would need some small
changes.  If it's not still there it would need to be retrieved from wherever
it went and hooked up again.  I imagine Knight could help with this.
\1f
DCP@MIT-MC 10/10/82 14:19:44
To: (BUG ITS) at MIT-MC
How willing are we to trust AI for mail?  Specifically, should
BUG-<unknown-list-on-MC> go to AI and probably end up in 
BUG-RANDOM-PROGRAM.  Doing the conversion is not a trivial
matter, since there are probably several lists which depend on
this happening and winding up on AI.  Alternatively, AI isn't
doing that much as it is, so maybe that is a good place for the
COMSAT computrons???

\1f
GJC@MIT-MC (Sent by GJC0@MIT-MC) 10/08/82 16:14:19 Re: The second most popular PDP-11 operating system on the NET?
To: DCP at MIT-MC
CC: (BUG ITS) at MIT-MC
According to the FAX I gathered for SYSENG;HOSTS >, using NUMER;HOSTP,
the most popular pdp-11 operating system on the "net" is UNIX, with 64 sites.
The second most popular is MINITS with 27 sites.

\1f
Date: 8 October 1982 00:04-EDT
From: Alan Bawden <ALAN at MIT-MC>
Subject:  GENSYM servers???????
To: GJC at MIT-MC
cc: BUG-ITS at MIT-MC

    Date: 7 October 1982 21:01-EDT
    From: George J. Carrette <GJC>
    Re:   GENSYM servers???????

    yow

You know about the YOW server on CCC?  Give it a try.

\1f
GJC@MIT-MC 10/07/82 21:01:11 Re: GENSYM servers???????
To: ALAN at MIT-MC
CC: (BUG ITS) at MIT-MC
yow
\1f
Date: 7 October 1982 18:07-EDT
From: Alan Bawden <ALAN at MIT-MC>
Subject:  ON MC
To: GJC at MIT-MC, DCP at MIT-MC
cc: BUG-ITS at MIT-MC

    Date: 10/07/82 11:57:18
    From: GJC

    We seem to have a lot of jobs like
    ___*** CHAOS GENSYM  ...... MPV and ILOPR
    since people from Plasma have to lot in I'm going to gun these now.
    Maybe it is intermittent?

I fixed the problem.  When they rejected connections these GENSYM servers were
POPJing off the bottom of the stack which generally caused them to jump into the
accumulators...

\1f
GJC@MIT-MC 10/07/82 11:57:18 Re: ON MC
To: (BUG ITS) at MIT-MC
We seem to have a lot of jobs like
___*** CHAOS GENSYM  ...... MPV and ILOPR
since people from Plasma have to lot in I'm going to gun these now.
Maybe it is intermittent?


\1f
Date: 7 October 1982 06:53-EDT
From: David C. Plummer <DCP at MIT-MC>
Subject: CPI numbers
To: BUG-ITS at MIT-MC, ALAN at MIT-MC, Bug-TWENEX at MIT-XX
cc: cm-i at MIT-OZ

CHAOS EOF packets:

There are two things going on here.  First is that ITS will allow
an EOF packet to be sent that has a non-zero bytelength for the
data field.  I don't think this is right.  Second is that doing a
TWENEX SIN JSYS on a chaos channel which has received an EOF will
give you the bogus data in the EOF before signalling the end of
file.

Case in point: The gensym server on MC originally didn't set the
byte length of the EOF, so twenex would print whatever happened
to be in the packet at the time.  For example,
        @type cha:mc.gensym_foobar
        19EGSNMYF OOAB
instead of just
        19


To Alan and cm-i: The GENSYM server has been fixed to no tickle
either bug.

\1f
Date: Wednesday, 6 October 1982, 06:07-EDT
From: Robert W. Kerns <RWK at SCRC-TENEX>
Subject: archive device overload
To: Alan Bawden <ALAN at MIT-MC>
Cc: BUG-ITS at MIT-MC, BUG-LMODEM at MIT-MC
In-reply-to: The message of 2 Oct 82 16:58-EDT from Alan Bawden <ALAN at MIT-MC>

    Date: 2 October 1982 16:58-EDT
    From: Alan Bawden <ALAN at MIT-MC>
    1) Is it really the case that there can't be more than about 8 jobdevices at
    any one time?  I guess this is reasonable since there usually isn't any more
    than about 4 active at any one time.
Yes.
    2) I hope that the LMODEM program is taking the proper precautions to prevent
    the user from using up infinite channels.  The maintainers should spend a
    minute or two thinking about correctly unwind-protecting their program so that
    this can't happen if they haven't already (in which case they should think
    about possible bugs).

In this case, it isn't LMODEM's problem.  They're staying around after
LMODEM's channels have been closed.

    3) What are archive devices waiting for when they go to sleep?  Normally they
    seem to hang.  These behaved as if they were waiting for a lock to free up.
    (The fact that they all disappeared after I gunned a couple presumably
    indicates that archive devices take the correct actions to insure that locks
    will be unlocked when jobs get killed.)  Is there some sort of deadly embrace
    that is known to happen?

Usually they're waiting for the lock to be freed that is held by
whichever one of them that got the error.  Generally, the error is a
clobbered archive.  It used to be true, may still be true, that having
the archive too large to map would cause it to be permanently broken
in this way.

    4) Since the job on the user end of the job channel had gone away, shouldn't
    the job devices have been told about it?  I don't find anything specific in the
    job device documentation about what happens when the user goes away, but I
    thought that the system simulated a .CLOSE on any channels associated with
    any terminated jobs, but this would have cleaned things up wouldn't it?
    (I just tried this myself, and that seems to be the case...)
Yes, but the ARCHIVE device doesn't allow any of this until it's
gotten the lock.
    5) Perhaps the .SLEEP that the archive device is using (where?) shouldn't be
    forever, but instead it should wake up every five minutes and be sure it still
    has a reason to live.
Something like that.
\1f
Date: Sunday, 3 October 1982, 03:10-EDT
From: Patrick Sobalvarro <PGS at MIT-OZ at MIT-MC>
To: bug-its at MIT-OZ at MIT-MC
Cc: akr at MIT-OZ at MIT-MC

Alex Krymm (our new hardware person) has agreed to take a look at the prints
for ML's Chaosnet interface and consider building one for AI.

Questions:
Is it really worth it?  That is, will this just be a lot of thankless work for
him?  Or is it comparatively simple?  Is someone who understands the hardware
well around to answer the occasional question?  Would he have to do
wirewrapping, or do we have wirelists that we can send to Augat?

\1f
Date: 3 October 1982 02:11-EDT
From: Pandora B. Berman <CENT at MIT-AI>
Subject: Lord of Light reincarnated
To: BUG-ITS at MIT-AI
cc: ALAN at MIT-AI

with advice from moon and much assistance from alan (who did most of
the actual work), Puff-The-Magic namedragon has been copied over from
ML to do namedragonish things like keeping track of logout times.
apparently the LOGOUT TIMES file has not been written to since the
knight tvs were last patched out (presumably Taraka Namdrg wants to
display on them before modifying the file?).

we first considered patching Taraka Namdrg to not try to write out to
the knight tvs, but that proved much too hairy.
\1f
Date: 2 October 1982 16:58-EDT
From: Alan Bawden <ALAN at MIT-MC>
Subject:  archive device overload
To: BUG-ITS at MIT-MC, BUG-LMODEM at MIT-MC

I noticed that my attempts to use the DIR device were reporting DEVICE FULL
errors, and since the system was far from full I deduced that we had run out of
some resource specific to jobdevices.  Sure enough, there were eight or so
sleeping archive devices.  They were all associated with a nonexistant job that
had presumably once been named <uname> LMODEM.  (Although PEEK could have been
mistaken about this if the job number had been recycled, the fact that they
were all using an archive on the CPM directory backs this up.)  I gunned a
couple of them and suddenly the rest disappeared.  I have several questions:

1) Is it really the case that there can't be more than about 8 jobdevices at
any one time?  I guess this is reasonable since there usually isn't any more
than about 4 active at any one time.

2) I hope that the LMODEM program is taking the proper precautions to prevent
the user from using up infinite channels.  The maintainers should spend a
minute or two thinking about correctly unwind-protecting their program so that
this can't happen if they haven't already (in which case they should think
about possible bugs).

3) What are archive devices waiting for when they go to sleep?  Normally they
seem to hang.  These behaved as if they were waiting for a lock to free up.
(The fact that they all disappeared after I gunned a couple presumably
indicates that archive devices take the correct actions to insure that locks
will be unlocked when jobs get killed.)  Is there some sort of deadly embrace
that is known to happen?

4) Since the job on the user end of the job channel had gone away, shouldn't
the job devices have been told about it?  I don't find anything specific in the
job device documentation about what happens when the user goes away, but I
thought that the system simulated a .CLOSE on any channels associated with
any terminated jobs, but this would have cleaned things up wouldn't it?
(I just tried this myself, and that seems to be the case...)

5) Perhaps the .SLEEP that the archive device is using (where?) shouldn't be
forever, but instead it should wake up every five minutes and be sure it still
has a reason to live.
\1f
Date: Saturday, 2 October 1982, 10:31-EDT
From: Robert W. Kerns <RWK at SCRC-TENEX>
Subject: [MINSKY at MIT-OZ: clucftp]
To: Christopher C. Stacy <CStacy at MIT-MC>
Cc: Bug-Twenex at MIT-XX, Bug-ITS at MIT-MC, MINSKY at MIT-OZ
In-reply-to: The message of 2 Oct 82 04:26-EDT from Christopher C. Stacy <CStacy at MIT-MC>

    Date: Saturday, 2 October 1982, 04:26-EDT
    From: Christopher C. Stacy <CStacy at MIT-MC>
    This is reproducable.  Anyone have any ideas why?


    Date: 30 Sep 1982 0032-EDT
    From: MINSKY at MIT-OZ
    Subject: clucftp
    To: cstacy at MIT-OZ
    cc: minsky at MIT-OZ

    When I use "get" to MC, it complains "bad format packet recieived".
    It used to work.  Has anything changed?
Possibly because of the addition of the AUTHOR to the OPEN response?

\1f
Date: Saturday, 2 October 1982, 04:26-EDT
From: Christopher C. Stacy <CStacy at MIT-MC>
Subject: [MINSKY at MIT-OZ: clucftp]
To: Bug-Twenex at XX, Bug-ITS at MC

This is reproducable.  Anyone have any ideas why?


Date: 30 Sep 1982 0032-EDT
From: MINSKY at MIT-OZ
Subject: clucftp
To: cstacy at MIT-OZ
cc: minsky at MIT-OZ

When I use "get" to MC, it complains "bad format packet recieived".
It used to work.  Has anything changed?
-------

\1f
Date: 30 Sep 1982 2002-EDT
From: J. Noel Chiappa <JNC at MIT-XX>
Subject: [Ben Littauer <littauer at BBN-UNIX>: TAC/ITS telnet problems]
To: bug-its at MIT-MC

Mail-from: ARPANET site MIT-MC rcvd at 30-Sep-82 1601-EDT
Date: 30 Sep 1982 15:52:57 EDT (Thursday)
From: Ben Littauer <littauer at BBN-UNIX>
Subject: TAC/ITS telnet problems
To: REM at mit-mc, POURNE at mit-mc, EAK at mit-mc, JNC at mit-mc
Cc: frye at BBN-UNIX, ditmars at BBN-UNIX, clifford at BBN-UNIX, littauer at BBN-UNIX


There has been a lot of traffic recently about this TAC/ITS telnet bug.
There are many misconceptions about what is going on in the TAC, and I
can only assume that much of the speculation I see about what ITS is doing
is also wrong.  I am currently looking into this problem, and trying to
sort out the facts.  It would be helpful if I had a contact at MIT who
could get me access to and account on MIT-MC and who would KNOW what MC
is supposed to do in these funny situations.  Any volunteers?  I expect 
to be doing some investigation during this coming week.  I can be
reached via netmail or at BBN (497-3196).

One major confusion about the TAC relates to its buffer sizes.  The TAC
has static buffering on input and dynamic buffering on output, and both
input and output buffers are relatively small.  The TIP's buffers could
be of any size, depending on the configuration of the machine.  The TAC
does not have, nor will it ever have, 1000 character buffers for 63 
terminals in a 32K word machine...  
                                    -ben-

-------

\1f
Date: 28 Sep 1982 2119-EDT
From: J. Noel Chiappa <JNC at MIT-XX>
Subject: Re: Anyone know why ITS got unfriendly?
To: EAK at MIT-MC, POURNE at MIT-MC
cc: BUG-ITS at MIT-MC, JNC at MIT-XX
In-Reply-To: Your message of 28-Sep-82 2026-EDT

        I'll forward your message to the TAC maintainer, Clifford@BBN-UNIX,
and see what we get back.
-------

\1f
Date: 28 September 1982 20:26-EDT
From: Earl A. Killian <EAK at MIT-MC>
Subject:  Anyone know why ITS got unfriendly?
To: POURNE at MIT-MC
cc: BUG-ITS at MIT-MC

Because the TACs (the new TIP) seem to misimplement to TELNET
protocol.  When ITS tries to flush the data in the network using
the same method that works on TIPs it causes things to come to a
grinding halt.  I suspect someone just removed the code that
attempts to do the flushing as begin better than wedging.

\1f
GJC@MIT-MC 09/27/82 16:57:13
To: (BUG ITS) at MIT-MC
I've noticed a funny intermittent bug from local MC terminals today.
The characters "IOB" sometimes end up in the input stream randomly
when other keys are typed. I've noticed this both on TTY 31 and
on the VT52 near the system consol on the 9'th floor.


\1f
dcp, alan@MIT-MC (Sent by DCP@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).
\1f
Date: 24 September 1982 09:49-EDT
From: Christopher C. Stacy <CSTACY at MIT-MC>
Subject:  ai namedragon
To: CENT at MIT-AI
cc: BUG-ITS at MIT-MC


There being no TV-11 anymore, I retired the name dragon.

\1f
Date: 24 September 1982 04:12-EDT
From: Pandora B. Berman <CENT at MIT-AI>
Subject: ai namedragon
To: BUG-ITS at MIT-AI

for at least the past few weeks, taraka has been consistently hanging onto
whatever verion of lsr1 was lsr1 1 when taraka was started up. that is, 
taraka is NOT checking at intervals for a newer version and releasing the old
one to be deleted. it seems the only way to change tarka's idea of what
is the current version of the database is to gun taraka and start a new one.
this is much less than optimal. please investigate.
\1f
Date: 23 September 1982 03:28-EDT
From: David C. Plummer <DCP at MIT-MC>
Subject: Whither XGP?
To: GUMBY at MIT-MC
cc: PGS at MIT-MC, BUG-ITS at MIT-MC, DLW at MIT-OZ

[Is BUG-ITS the right place for all of this??]

My Versatec spooler understands KST files; it has nothing to do
with the Versatec.  If you read DCP;PRESS ANOUNC you will see
that when the Versatec spooler TRIES to do press files, it
translates the press fonts into somee (hopefully) reasonable XGP
font.

If you are trying to get closer to the state of the art, flush
XGP format files.  In theory (if I turned on XGP file recognition
in the spooler), XGP files produced by R come out correctly, but
XGP files produced by TJ6 or BOLIO (and I think @) cause it to
crash.  This is interesting, becuase the :DOVER program does the
exact opposite (does everything (as far as I can tell) EXCEPT R
produced XGP files).  "Well, why don't you look at :DOVER to see
how it does it?" you might ask.  I did; it is just as
incomprehensible when it comes to XGP files as anything else I've
seen.  
\1f
Date: 22 September 1982  23:21-EDT (Wednesday)
Sender: GUMBY at MIT-OZ
From: David Vinayak Wallace <GUMBY at MIT-MC>
To:   PGS at MIT-MC
Cc:   bug-its at mc, DLW at MIT-OZ
Subject: Whither XGP?

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)?
-------

\1f
Date: Wednesday, 22 September 1982  15:39-EDT
Sender: PGS at MIT-OZ
From: PGS at MIT-MC
To:   David Vinayak Wallace <GUMBY at MIT-OZ>
Cc:   bug-its at mc, DLW at MIT-OZ
Subject: Whither XGP?

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.
-------

\1f
Date: Wednesday, 22 September 1982  14:10-EDT
Sender: KLOTZ at MIT-OZ
From: KLOTZ at MIT-MC
To:   DLW at MIT-OZ
Cc:   bug-its at mc, David Vinayak Wallace <GUMBY at MIT-OZ>
Subject: Whither XGP?

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

\1f
Date: 22 Sep 1982 0948-EDT
From: J. Noel Chiappa <JNC at MIT-XX>
Subject: Re: Whither XGP?
To: GUMBY at MIT-MC, bug-its at MIT-MC
cc: JNC at MIT-XX
In-Reply-To: Your message of 21-Sep-82 1816-EDT

        ML has it's own private direct PDP-10 interface to the CHAOS
net. I don't know if you could plug the XGP-11 into the DL-10 (or the
DTE, if it's a multi-11 one) on MC without buying new hardware, but I
doubt it. In any case, the software would require tons of work, and
I doubt there is anyone at MIT competent to do it. Basically, you're
out of luck.
-------

\1f
Date: Wednesday, 22 September 1982  07:42-EDT
Sender: DLW at MIT-OZ
From: DLW at MIT-MC
To:   David Vinayak Wallace <GUMBY at MIT-MC>
Cc:   bug-its at mc
Subject: Whither XGP?

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.
-------

\1f
Date: 21 September 1982  18:16-EDT (Tuesday)
Sender: GUMBY at MIT-OZ
From: David Vinayak Wallace <GUMBY at MIT-MC>
To:   bug-its at mc
Subject: Whither XGP?

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?
-------

\1f
Devon@MIT-ML 09/10/82 06:12:13 Re: AI's broken Ten-11 interface
To: (BUG ITS) at MIT-ML, TK at MIT-ML
When the Ten-11 interface is enabled, AI goes into an infinite loop
while trying to initialize the Chaos-11's buffers.  The NXM light stays
off when it's running, but it quickly lights up when single-stepping.
This occurs around pc=60477 (T11CK2) with the TV-11 disabled (so it
won't die trying to hack the TV-11).  Single-stepping this loop seems to
show a SETZM instruction skipping.  Perhaps the single-step key is
bouncy, but this instruction is trying to write a zero into the Chaos-11
so it might be related to the Ten-11 failure.  Would someone look at the
crash dump in the file AI:CRASH;TREE TOAD and check this out?  AI is
only available via ARPAnet because it can't talk to the PDP-11's.
\1f
Date: 9 September 1982 01:58-EDT
From: Devon S. McCullough <DEVON at MIT-MC>
To: DCP at MIT-MC
cc: BUG-ITS at MIT-MC, FJW at MIT-MC

    DCP@MIT-MC (Sent by DCP0@MIT-MC) 09/07/82 12:35:41
    To: DEVON at MIT-MC
    CC: (BUG ITS) at MIT-MC
        DEVON@MIT-MC 09/07/82 06:35:11
        One question?  If ITS sends a IAC WILL BINARY to a TIP or
        TAC, does this turn off interpretation of the IAC character
        somehow, so it should no longer be doubled?  That would be
        nasty.

    An IAC is only doubled when a 377 wants to pass all the way
    through the TELNET stream.  This is still the case when a machine
    is in TRANSMIT BINARY. 

    I think there is a big difference of opinion on the intercept
    character issue.  Characcters go from KEYBOARD to COMMAND
    PROCESSOR to TELNET STREAM to FOREIGN TELNET STREAM.  Normally
    the command processor passes through characters to the telnet
    stream, unless the intercept character is typed.  The impression
    from some people I get is that if the TAC goes into TRANSMIT
    BINARY, then the command processor will not trap the intercept
    character.  Well, my opinion is that that is a completely
    cretenous behavior.  TRANSMIT BINARY only has to do with the
    TELNET STREAM, and not the COMMAND PROCESSOR.  If TACS will not
    intercept @ when in TRANSMIT BINARY, then it is in violation of
    the description of TRANSMIT BINARY found in the April 1976
    ARPANET PROTOCOL HANDBOOK.  I doubt it has changed.

There is a difference in opinion.  The command processor is free to
decide when it's appropriate to catch the intercept character and when
it's not, and currently it does the most reasonable thing.

TIP users would be grossly inconvenienced if command characters were
intercepted in binary mode.  Fortunately they aren't.  This issue is
totally outside the scope of the protocol, and I saw no mention of it
in the APRAnet Protocol Handbook - can you give me a page number?
\1f
DCP@MIT-MC (Sent by DCP0@MIT-MC) 09/08/82 01:17:01
To: (BUG DECUUO) at MIT-MC
CC: (BUG ITS) at MIT-MC
Just curious, What is the kludge in DECUUO that requires the
second word of a UNAME entry in the MFD to be zero?? 
\1f
DCP@MIT-MC (Sent by DCP0@MIT-MC) 09/07/82 12:35:41
To: DEVON at MIT-MC
CC: (BUG ITS) at MIT-MC
    DEVON@MIT-MC 09/07/82 06:35:11
    One question?  If ITS sends a IAC WILL BINARY to a TIP or
    TAC, does this turn off interpretation of the IAC character
    somehow, so it should no longer be doubled?  That would be
    nasty.

An IAC is only doubled when a 377 wants to pass all the way
through the TELNET stream.  This is still the case when a machine
is in TRANSMIT BINARY. 

I think there is a big difference of opinion on the intercept
character issue.  Characcters go from KEYBOARD to COMMAND
PROCESSOR to TELNET STREAM to FOREIGN TELNET STREAM.  Normally
the command processor passes through characters to the telnet
stream, unless the intercept character is typed.  The impression
from some people I get is that if the TAC goes into TRANSMIT
BINARY, then the command processor will not trap the intercept
character.  Well, my opinion is that that is a completely
cretenous behavior.  TRANSMIT BINARY only has to do with the
TELNET STREAM, and not the COMMAND PROCESSOR.  If TACS will not
intercept @ when in TRANSMIT BINARY, then it is in violation of
the description of TRANSMIT BINARY found in the April 1976
ARPANET PROTOCOL HANDBOOK.  I doubt it has changed.
\1f
DEVON@MIT-MC 09/07/82 08:01:07
To: (BUG ITS) at MIT-MC
I spent several hours this morning trying to track down a sporadic TAC or TELSER bug
wherein either the TAC gets wedged and refuses to accept binary output when ITS wants
to do so, or else it accepts and TELSER is too wedged to notice the ack from the TAC.

Couldn't duplicate it once the symptoms became clear enough to try to get them on purpose.
Who has done this before?  Is there some interaction or protocol change I'm unaware of?
I'm not sure whether the TAC or TELSER is at fault.  The basic symptom is that I will
send IAC WILL BINARY (I do :imgout 377 373 0 at DDT) and the TRBINF in telser stays zero.
Alternating between WILL and WONT produces no effect either.
\1f
DEVON@MIT-MC 09/07/82 06:35:11
To: (BUG ITS) at MIT-MC
One question?  If ITS sends a IAC WILL BINARY to a TIP or TAC, does this turn off interpretation of the IAC character somehow, so it should no longer be doubled?  That would be nasty.
\1f
Date: 7 September 1982 06:29-EDT
From: Devon S. McCullough <DEVON at MIT-MC>
Subject:  connecting to ITS from an ARPAnet TAC
To: BUG-ITS at MIT-MC
cc: DCP at MIT-MC, FJW at MIT-MC, EB at MIT-OZ

TelSer should always initialize TelNet connections with IAC WILL BINARY.

TCTYP really should try to adjust a TIP or TAC connection when %TPMTA
is called for, maybe by means of a new keyword, like EIGHT or META.
If connected via a TIP/TAC, TCTYP should then issue IAC DO BINARY.

Extensive experiments tonight with USC-TAC show that everything will
work fine if you tell a TAC that ITS is going to transmit binary.

It works well for some people to ask the TIP/TAC to transmit binary,
but this disables @ interception, and will thus screw many TIP/TAC
users.  The only way they'd have to undo this is either hang up and
redial the TIP/TAC, or log out and wait for TelSer's 2 minute timeout.
Since I need this feature to enable my terminal's META key, I have
fixed my login file to do :IMGOUT 377 373 0 and logout to do :IMGOUT
377 376 0 when my TCTYP specifies %TPMTA.  These magic numbers are IAC
DO BINARY and IAC DONT BINARY respectively.

Apropos nothing in particular, the TIP manual claims that if the host
sends 207 <command> ^J to a TIP in OLD TELNET it will work as if the
user had typed @ <command> ^J on his terminal, but it does work on
TACs so I guess New TelNet never evolved a replacement for this
necessary feature, or are they STILL ruinning OLD TELNET???
\1f
Date: 5 September 1982 14:09-EDT
From: David C. Plummer <DCP at MIT-MC>
Subject: MINITS supdup to MC
To: KMP at MIT-MC
cc: PGS at MIT-MC, PGA at MIT-MC, BUG-ITS at MIT-MC,
    BUG-MINITS at MIT-MC

I believe there is a bug-minits mailing list.  Anyway,  

I think MINITS does do the decrement hack necessary for ITS.  I
can not make it fail on my AAA which is connected to a MINITS and
I am SUPDUPing to MC.  I have tried printing files which have
lines lengths greater than that of the terminal and cannot make
it fail.  I suspect the problem is actually the setup modes of
the terminal.  ITS assumes (or enforces in the initial string)
and MINITS assumes (but does not currently have an initial string
to enforce it with) that /terminals/ DO NOT automatically wrap
when a character is displayed on the last column.  This may be a
personal preference, but if you are on an AAA and if the second
bit of setup mode D is on, turn it off and tell me if it still
loses.  If you type S to get out of setup, it will save the
current configuration (and hope you dont have wars over the
proper modes).

\1f
Date: 5 September 1982 01:58-EDT
From: Kent M. Pitman <KMP at MIT-MC>
Subject: MINITS supdup to MC
To: PGS at MIT-MC, PGA at MIT-MC
cc: BUG-ITS at MIT-MC

When Supdup'ing to MC, MINITS (I guess) incorrectly supports over-run lines.
it seems that they don't end up incrementing ITS' notion of what line it's 
on, so at the bottom of the screen, some hardware scrolling happens because
ITS doesn't realize soon enough that it's time to give a --more-- break and 
pop to the top of the screen. this effect is easy to reproduce.
just print a file which has lines longer than the line length and watch what
happens as you reach the bottom of the screen.

\1f
Date: 3 September 1982 21:45-EDT
From: David C. Plummer <DCP at MIT-MC>
To: DEVON at MIT-MC
cc: DCP at MIT-MC, BUG-ITS at MIT-MC

I think you are confused (though it could be me).  DO TRANSMIT
BINARY does not mean the TAC can't trap its escape character, itjust
means it should not do any special processing on the characters.
There is another option I belive for complete binary transmission
which cannot be reverted; I do not think TRANSMIT BINARY is that option.
I gues one of us should check the protocol specification...

\1f
Date: 3 September 1982 21:42-EDT
From: Devon S. McCullough <DEVON at MIT-MC>
To: DCP at MIT-MC
cc: BUG-ITS at MIT-MC

DO TRANSMIT BINARY would screw people who try to close their ITS
connection and reconnect, since in binary mode the TIP (TAC) does not
hack local user commands.  Perhaps the TIP/TAC ressets this when you
close the connection?  It would still be boring to logout and have to
wait until TelSer gets around to closing your connection.

Currently TelSer knows about CR and CRLF and sets your TCTYP in
accordance with the protocol you are sending, so this is no problem.
\1f
DCP@MIT-MC 09/03/82 17:30:31
To: (BUG ITS) at MIT-MC
Is there any reason why ITS should change a %TDFS into a space
on overprinting terminals?  Here is the problem:

I am on an overprinting terminal, SUPDUPing to ITS.  I Telnet
to a system that can't deal with overprinting terminal.  VAX VMS
and I think VAX Unix have this problem.  When using CHTN, I toggle
VT52 emulation mode and tell the VAX I have a vt52 (with perhaps 
a higher screen).  When the foreign system sends an ESCAPE C (or 
whatever it is that goes forward), CHTN tells ITS to go forward.
When ITS is sending to a replacing terminal, it sends %TDFS (I hope),
but for an overprinting terminal (which it still thinks I am in this
case), it sends a space (which unfortunately is now destructive).

\1f
Date:  3 Sep 1982 1213-EDT
From: J. Noel Chiappa <JNC at MIT-XX>
Subject: TelSer
To: DEVON at MIT-MC
cc: BUG-ITS at MIT-MC, JNC at MIT-XX

        Sounds like a good idea to me. Will any ITS wizards out there
speak up if this is unreasonable? Otherwise, I'd say do it.
-------

\1f
DCP@MIT-MC 09/03/82 12:00:23
To: DEVON at MIT-MC
CC: (BUG ITS) at MIT-MC
If TELSER sends WILL TRANSMIT BINARY, then that only allows ITS
to send binary to the TAC.  You also want DO TRANSMIT BINARY
which lets the TAC legally send binary to ITS.  I aggree that
most times there will be no noticiable difference in terminal
handling.  When a user types both RETURN and LINEFEED to
something like DDT, ITS may get marginally confused, but thems
the breaks. 

I do not use TACs.  Somebody that does should try out a new
TELSER on MC or ML some night and see if it works.  Make sure CR,
LF, and CR LF all do what you expect.  Compare with old behavior.

\1f
DEVON@MIT-MC 09/03/82 03:22:06
To: (BUG ITS) at MIT-MC
When TIPs were generally used, the default output mode was (apparently) binary, but now that TACs are in vogue, terminal programs that used to work with TIPs lose, because they are only receiving 7 bits.  Perhaps TelSer should WILL Transmit Binary, which is necessary in some cases and harmless otherwise.
\1f
Date: 30 August 1982 05:48-EDT
From: Christopher C. Stacy <CSTACY at MIT-AI>
Subject: TV
To: BUG-ITS at MIT-AI

seems to drop bits.  My ^C in previous :MAIL echoed as ^B but worked.
\1f
Date: 30 August 1982 05:48-EDT
From: Christopher C. Stacy <CSTACY at MIT-AI>
To: BUG-ITS at MIT-AI

Sometimes when I am using a Knight TV, my screen
gets garbled.  I dont know what part of the TV
system (10,11, or 10/11) is losing.
\1f
Date: Saturday, 28 August 1982  02:40-EDT
To:   cstacy at MIT-OZ
Sender: RPS at MIT-OZ
from:cent
Subject:ai problems & bughalts
cc:   bug-its at MIT-OZ

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.
-------
\1f
Date: 23 August 1982 10:36-EDT
From: Devon S. McCullough <DEVON at MIT-MC>
Subject:  H19 emulators, and lossage and ANSI mode
To: PGS at MIT-MC
cc: BUG-ITS at MIT-OZ

A bit would be cleaner, after all TCTYP can be told that HDS means H19
+ some bit, just as GLASS means PRINTING with some different bits.
\1f
Date: Monday, 23 August 1982  08:52-EDT
Sender: PGS at MIT-OZ
From: PGS at MIT-MC
To:   DEVON at MIT-MC
cc:   BUG-ITS at MIT-OZ
Subject:H19 emulators, and lossage and ANSI mode

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).
-------
\1f
DEVON@MIT-MC (Sent by DEVON7@MIT-MC) 08/20/82 08:10:24
To: (BUG ITS) at MIT-MC
certain h-19 emulators don't support ANSI mode and no longer work with the latest ITS.
short-distance screen scrolling in EMACS still works, but when trying to scroll the
text a long way it just puts trash on the display, and I have to clear the screen (slow)
Since the emulation I'm using is on a micro i suppose I could try to hack some new code,
but the display driver has limited memeory in which to live, because when screen RAM is
mapped in, most user RAM is mapped out to make room for the video.

perhaps TECO can be kludged with some flag saying to insert/delete one at a time?
\1f
Date: 18 Aug 1982 0423-EDT
From: DEVON at MIT-DMS (Devon S. McCullough)
To: BUG-its at MIT-DMS
Subject: BUG => its
Message-id: <[MIT-DMS].241228>

using a TIP, it was never necessary to do @b o s, but now with TAC's it is.
To avoid inconveniencing the user, how can this be done from ITS?


\1f
Date: 16 August 1982 19:52-EDT
From: David C. Plummer <DCP at MIT-MC>
To: REM at MIT-MC
cc: BUG-ITS at MIT-MC, MIT-IN-PEOPLE at MIT-MC

    REM@MIT-MC 08/16/82 09:12:29
    I am getting no echo whatsoever.
    I am typing this blindly.
    I pressed ctrl-S to stop output on second window (screen) of
    a ^R (PRINT), which has been doing this for weeks since the
    SU-TAC was installed.

My theory is that ITS is doing an output reset, which is turning
into a data mark or interrupt process or something in the TELNET
protocol, and that TACs don't understand this.  You will probably
find that ^G will do the same thing.  Has the TELNET protocol
dropped this feature?  Is ITS doing the wrong thing?  Or is this
missing from the implementation of TACs.

Could somebody forward this to the code writers of the TAC
software.  If necessary, I will try and find out what ITS is
doing.  This has also happened to the DAVID-TAC (??) by people
from the NAVY.

\1f
EAK@MIT-ML 08/16/82 15:15:02
To: (BUG ITS) at MIT-ML
I was sittly quitely in :MAIL just now when I got a Console Free message.
I thought someone had gunned me, so I quickly came back and spied on the
system console, which said
NET: RST TIMEOUT HST= 116000  15:08:57
116000 is the host I was coming from.
Some weird network glitch?  I don't know, but I also don't understand
why my tree wasn't detached instead of destroyed.

\1f
REM@MIT-MC 08/16/82 09:12:29
To: (BUG ITS) at MIT-MC
I am getting no echo whatsoever.
I am typing this blindly.
I pressed ctrl-S to stop output on second window (screen) of a ^R (PRINT), which has been doing this for weeks since the SU-TAC was installed.

\1f
Date: Saturday, 14 August 1982  14:47-EDT
Sender: PGS at MIT-OZ
From: PGS at MIT-MC
To: David A. Moon <MOON at MIT-OZ>
Cc: BUG-ITS at MIT-MC, BUG-TELNET at MIT-MC, KLOTZ at MIT-OZ, 
      RMS at MIT-OZ
Subject: crufty lossage (of characters, perhaps)

    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.
-------

\1f
CSTACY@MIT-MC 08/14/82 04:51:39
To: (BUG ITS) at MIT-MC
I installed version 1278 as NITS on MC.
If anything goes wrong, please take a crash dump and boot
from ITS.  Broken terminal support is supposedly fixed.

\1f
Date: 13 August 1982 02:03-EDT
From: David A. Moon <MOON at MIT-MC>
Subject: crufty lossage (of characters, perhaps)
To: PGS at MIT-MC
cc: BUG-TELNET at MIT-MC, BUG-ITS at MIT-MC, RMS at MIT-MC,
    KLOTZ at MIT-MC

:TCTYP ? will tell you about the PADDED option, which is probably what you need.
\1f
Date: Tuesday, 10 August 1982  20:48-EDT
Sender: PGS at MIT-OZ
From: PGS at MIT-MC
To: RZ at MIT-OZ
cc: bug-its at MIT-OZ

    RZ@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.
-------
\1f
Date: 10 August 1982 18:05-EDT
From: Christopher C. Stacy <CSTACY at MIT-MC>
To: BUG-ITS at MIT-MC


I deinstalled the new ITS from MC, since it was crashing the system.
I will look into it (sigh).

\1f
RZ@MIT-MC 08/10/82 16:40:36
To: (BUG ITS) at MIT-MC
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.

\1f
PGS@MIT-MC 08/10/82 07:00:59
To: (BUG ITS) at MIT-MC
ITS 1278 is now installed on ML, AI, and MC.  It contains support for Ann
Arbors, and the code for H19's has been rewritten to include multiple
insert/delete line/char.  TYMPAD has been changed to allow padding with nulls.
H19's are being successfully padded with nulls, but it doesn't help a whole
lot, because the padding for insert/delete operations isn't happening at the
most featureful time imaginable.  I'll fix this when I get back from vacation.

\1f
Date: 8 August 1982 19:56-EDT
From: Patrick G. Sobalvarro <PGS at MIT-MC>
Subject: crufty lossage (of characters, perhaps)
To: BUG-TELNET at MIT-MC, BUG-ITS at MIT-MC
cc: RMS at MIT-MC, KLOTZ at MIT-MC

I'm trying to fix TS3TTY so that H19's are padded with nulls, and can do
multiple insert/delete line, like Ann Arbors do (no more of this weenie weenie
stuff).  I think I'm winning.  But I can't tell.

Why can't I tell?  Well, AI has no H19's hung on it, and it can't pump out the
characters at 9600 baud anyway, and that's when things get critical.  So what I
usually do is go downstairs and connect an H19 to MC, and Telnet over to AI and
do a :TCTYP H19 locally.  And I lose; the padding, or the insert/delete line
stuff, just doesn't seem to work; the terminal gets confused, and outputs
things in random places, and I go back and grovel over the code some more.

But last night I distilled a listing and injected it into my brain, and this
afternoon when I saw that I was losing, I knew damned well that I should be
winning, so I went over to a VT52, and Telnetted from it (on MC) to ML.  Its
terminal type was set to VT52 on both machines, and it exhibited the same sort
of lossage that H19's were exhibiting for me.  RMS suggested that perhaps the
local machine didn't know its speed, so I set that to 9600 in both places, and
it still lost.  In fact, absolute positioning and insert/delete line/character
type things seem to consistently lose through a Telnet.  I believe I remember
hearing this ascribed to VTS when people used to Telnet to XX when it first
came up.

Try this simple experiment: log in on a local terminal on ML, or DM, or MC, or
maybe even AI, although I don't know if it's fast enough to cause the lossage.
Telnet over to another machine (even the one you're on!), do TTY^K, and watch
it go!

\1f
Date: 28 Jul 1982 1132-EDT
From: CSTACY at MIT-DMS (Christopher C. Stacy)
To: bug-its at MIT-DMS
Message-id: <[MIT-DMS].238845>

This system seems to be printing bogus LOGIN and LOGOUT messages.
God knows what else it mightbe doing.


\1f
Date: 31 Jul 1982 1129-EDT
From: SWG at MIT-DMS (S. W. Galley)
To: SWG at MIT-DMS, CSTACY at MIT-DMS
Cc: bug-its at MIT-DMS
In-reply-to: <[MIT-DMS].238845>
Subject: bogus LOGIN & LOGOUT messages
Message-id: <[MIT-DMS].239379>

No doubt it's because TAA patched ITS to record them
for non-TTY trees as well as TTY-controlled ones.

\1f
CSTACY@MIT-MC 08/04/82 17:40:57 Re: sources
To: (BUG ITS) at MIT-MC

I saved the AI sources in SYSTEM, SYSENG, and SYSEN1 onto OZ
for the moment.

\1f
TK@MIT-MC 07/31/82 15:26:29
To: (BUG ITS) at MIT-MC
Just so other people who look at AI don't spin wheels unnecessarily.
AI is currently dropping dead during the instruction following LPMR's
(and possibly other pager related instructions).  There also appears
to be a bad file in the acount directory (cdata or something) which
prevents the system from coming up, but which the salvager seems
incapable of fixing trivially.  I haven't looked at this second problem
very hard.  The following loop will hang the processor:

LMPR
JFCL
JFCL
AOJA .-3

PC stops at lpmr + 2, having fetched and done the fetch cycle (including
PC increment) of the instruction at lmpr + 1.
I probably won't get a chance to look at this further for a few days.
I'd suggest a debugging strategy of using the logic analyzer to locate the
place where the pulse train drops dead.  This might be caused by additional
pulses coming back from the pager.  A likely failure is the TTL-DEC converters
going to the pager.

\1f
Date: Sunday, 1 August 1982  06:07-EDT
Sender: TERZOP at MIT-OZ
From: TERZOP at MIT-MC
To: KLOTZ at MIT-AI
Cc: bug-its at ai, vision at ai
Subject: AI's demise?   


 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.
-------
\1f
Date: 28 July 1982 23:16-EDT
From: Alan Bawden <ALAN at MIT-MC>
Subject:  MC emacs stuck in Kansas
To: TFT at MIT-MC
cc: BUG-MC at MIT-MC, BUG-ITS at MIT-MC

    TFT@MIT-MC 07/27/82 08:31:40 Re: MC emacs stuck in Kansas
    To: (BUG MC) at MIT-MC
    I think this should go to bug-mc, not bug-emacs:

    When I try to use either M-x find file, or C-x-C-f, to get a file from
    Oz, the defaulter gets very confused.  I think it doesn't even know that
    Oz exists! ...

Huh?  Are you complaining that C-X C-F OZ:<DIR>FOO.BAR doesn't work?  (While
you CAN reference files on AI f'rinstance?)  While it IS possible that this
could be made to work it isn't exactly trivial.  Maybe someday someone will
have a hack attack and do it.  This is one of the prices we pay for running
an incompatible timesharing system on OZ rather than an Incompatible
Timesharing System.
\1f
Date: Saturday, 31 July 1982  00:24-EDT
Sender: KLOTZ at MIT-OZ
From: KLOTZ at MIT-AI
To: bug-its at ai
cc: vision at ai
Subject: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.
-------
\1f
Date: 31 July 1982 18:59-EDT
From: Tom Knight <TK at MIT-AI>
To: BUG-ITS at MIT-AI

AI has decided to "work" for the time being.  I.e., Moon and I intimidated it
with scope probes, and it stopped failing.  This is the second unrelated marginal
failure in as many weeks, neither of which has been properly fixed.  Don't count
on it continuing to work.
\1f
MOON@MIT-MC 07/26/82 03:29:39 Re:  AI's problems--TEN-11 software
To: TK at MIT-AI, (BUG ITS) at MIT-AI
For what's worth, I fixed these in the source.  Someone who wanted to be
useful might assemble and install a new system on AI.  I made the Chaosnet
respect TEN11F, which it hadn't heard of, and I made the pointer in the
TV-11 memory get ranged checked in the 2 places it seemed to be used,
causing a bug-halt with an appropriate message if it was wrong.
\1f
Date: 24 Jul 1982 0302-EDT
From: Robert W. Kerns <RWK at SCRC-TENEX at MIT-MC>
Subject: Re: .TEMP.
To: CSTACY at MIT-AI, BUG-ITS at MIT-AI
cc: RWK at SCRC-TENEX at MIT-MC
In-Reply-To: Your message of 24-Jul-82 0243-EDT

TMPKIL is supposed to run, of course, and there is supposed to be a .TEMP.
directory, and there should be a -READ- -THIS- file in the directory that
explains what the directory is for, and it should be reap-protected.  I
believe that TMPKIL explicitly does not delete -READ- -THIS-; the do-not-reap
bit is to discourage people, not programs.
-------

\1f
Date: 23 July 1982 17:01-EDT
From: Christopher C. Stacy <CSTACY at MIT-AI>
Subject: .TEMP.
To: BUG-ITS at MIT-AI


When the system came up after being broken the other day,
I noticed TMPKIL running.  I wasnt sure who/what started it,
so I left it be.
\1f
Date: Friday, 23 July 1982, 13:59-EDT
From: Robert W. Kerns <RWK at SCRC-TENEX at MIT-MC>
Subject: AI:.TEMP.;
To: Rodney A. Brooks <BROOKS at MIT-AI>
Cc: BUG-ITS at MIT-AI, BUG-LISPM at MIT-AI
In-reply-to: The message of 23 Jul 82 09:54-EDT from Rodney A. Brooks <BROOKS at MIT-AI>

    Date: 23 July 1982 09:54-EDT
    From: Rodney A. Brooks <BROOKS at MIT-AI>
    on lispm Terminal-Q complains of the non-existnece of directory AI: .TEMP.;LMSCN >.
    I assume this is either the reslt of recent vandalism or overzealous directory
    reclamation?

Perhaps someone deleted the -READ- -THIS- file, and the program that
reaps that directory (deleting files more than a day old that don't have
the do-not-reap bit and are not -READ- -THIS-) ran, leaving no files
in the directory?

Does AI run that program?  I seem to recall that it's run by PFTHMG
DRAGON on MC.  I think it's called TMPKIL.

\1f
Date: 22 July 1982 07:26-EDT
From: Tom Knight <TK at MIT-AI>
To: BUG-ITS at MIT-AI
cc: TK at MIT-AI

AI's problems, after 2 nights of hacking, turned out to be software [sort-of].
The system was getting page faults referencing NXM exec pages, while PI in progress
on channel 7.  The problem had to do with a location in the TV-11 being the exactly
wrong value to cause the LDB and ADD at SSLCK8+4 or so to produce an address of
one more than the page boundary.  This was compounded and made more difficult to find
by a second bug in which turning off the 10-11 code makes the chaonet clock routine
reference exec NXM, again at clock level, without checking the TEN11F flag.
This happens on calls to T11CHK, which should just popj if TEN11F is disabled.
This problem was eventually debugged with clipleads halting the machine on exec
memory protect failures.
The bugs have not been patched, but the system will presumably "never" get into
that state again.  I'll edit the sources after breakfast.
\1f
MOON@MIT-MC 07/16/82 22:09:18 Re:  disk constipation
To: DCP at MIT-MC
CC: (BUG ITS) at MIT-MC, (BUG MAIL) at MIT-MC
    DCP@MIT-MC 07/16/82 21:25:55
    To: (BUG ITS) at MIT-MC, (BUG MAIL) at MIT-MC
    Is there something wrong with the disk code?  MC constipated for
    quite a while just now, and here is comsat's stats for the time:

        205056  Attempting to send messages queued to host MIT-OZ
        205056    ICP->MIT-OZ...
        205057  QID=<[MIT-MC].317543>
        205057          TO->MARTY
        205059    CMSG  ID=<[MIT-MC].317655> EXP->DCP@354
        211553          TO->DCP

    Notice the 25 minute delay.  The constipation did coincide with
    my typing G inside EMACS RMAIL.  Then again, it could be
    unrelated.  During the constipation, ANYBODY doing an OPEN on a
    disk file would hang, but could be PCLSR'd.

This is usually due to running out of disk channels, and deadlocking
where you have several programs each of which wants a lot of disk channels,
has some, and is waiting for more.  COMPLR and PUB are prime offenders
in this respect since they open many channels and keep them open for
many minutes.  You can look at the variable in the system whose name
is (I think) QFCHN, the number of free disk channels.
\1f
DCP@MIT-MC 07/16/82 21:25:55
To: (BUG ITS) at MIT-MC, (BUG MAIL) at MIT-MC
Is there something wrong with the disk code?  MC constipated for
quite a while just now, and here is comsat's stats for the time:

    205056      Attempting to send messages queued to host MIT-OZ
    205056        ICP->MIT-OZ...
    205057      QID=<[MIT-MC].317543>
    205057              TO->MARTY
    205059        CMSG  ID=<[MIT-MC].317655> EXP->DCP@354
    211553              TO->DCP

Notice the 25 minute delay.  The constipation did coincide with
my typing G inside EMACS RMAIL.  Then again, it could be
unrelated.  During the constipation, ANYBODY doing an OPEN on a
disk file would hang, but could be PCLSR'd.

\1f
Date: 14 July 1982 11:29-EDT
From: David A. Moon <MOON at MIT-MC>
Subject: [MP: ITS question]
To: GREN at MIT-AI
cc: BUG-ITS at MIT-MC, mp at MIT-XX

    Date: Wednesday, 14 July 1982  00:45-EDT
    Sender: GREN at MIT-OZ
    From: GREN at MIT-AI
    To: BUG-ITS at AI
    Subject: [MP: ITS question]

    Date: Saturday, 10 July 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.
That's .IOS.
             What is N getting?
The TTY number.   .SUSET .RCNSL would be a better way.
\1f
Date: Wednesday, 14 July 1982  00:45-EDT
Sender: GREN at MIT-OZ
From: GREN at MIT-AI
To: BUG-ITS at AI
Subject: [MP: ITS question]

Date: Saturday, 10 July 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
-------
\1f
Date: 12 July 1982  16:02-EDT (Monday)
Sender: RICH at MIT-OZ
From: Charles Rich <RICH at MIT-AI>
To: bug-oz at MIT-AI, bug-its at MIT-AI

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).
-------
\1f
Date: 11 July 1982 19:56-EDT
From: David A. Moon <MOON at MIT-MC>
Subject:  .IOC
To: GREN at MIT-MC
cc: BUG-ITS at MIT-MC

It's the same as IOCHNM inside ITS.  You can look at the comments on that.
The right half is an index into internal device tables, and the left half
contains device-dependent bits and fields.  However, the reason it is not
documented is probably that it is not generally useful and only exists for
completeness.

\1f
Date: 11 July 1982 16:07-EDT
From: Christopher C. Stacy <CSTACY at MIT-AI>
To: BUG-ITS at MIT-AI


In ITS 1273, DDT 1388, on AI:

PWORD, MAIL, FINGER, and WHO, were all broken last night for
some reason.  Now they all work.

Did someone fix this stuff, or did it (ummm) fix itself.
\1f
Date: 11 July 1982 05:36-EDT
From: Ian G. Macky <GREN at MIT-MC>
To: BUG-ITS at MIT-MC


The World According to >INFO.;ITS USETS:


.IOC +<n>       +- +-   input/output channel

        The variable .IOC+<n> is the input/output channel
        word for channel <n>, for n between 0 and 17 octal.
        Normally zero for a closed channel.



[This is not horribly informative.  Can anyone tell me what
 exactly is in thess words?  I'll fix the USETS doc once the
 stuff is known... --gren]
\1f
Date: 11 July 1982 01:26-EDT
From: Keith F. Lynch <KFL at MIT-AI>
To: BUG-ITS at MIT-AI

:F  and :FINGER and :WHOIS  all die, with or without jcl. :F gives me
the header line, then XGP, then, immediately on a new line, 
ILOPR; 17770>>0   0/   10400,,500000   0/    10400,,500000
:FINGER and :WHOIS gives similar results. There is no problem with
:U or :UJ or :WHO or :WHOJ.
 :F worked fine about two hours ago.
                                                ...Keith
\1f
Date: 11 July 1982 00:42-EDT
From: Doug Humphrey <DIGEX at MIT-AI>
To: BUG-ITS at MIT-AI

:f and :who are blowing up on me. nothing special I am doing.

:f blows with

ILOPR; 17770>>0

\1f
Date: 10 July 1982 19:38-EDT
From: Christopher C. Stacy <CSTACY at MIT-AI>
Subject:  I answered Guby's FINGER bug report (there was no bug)
To: GUMBY at MIT-AI
cc: BUG-ITS at MIT-AI


\1f
Date: 10 July 1982 19:13-EDT
From: David Vinayak Wallace <GUMBY at MIT-AI>
To: BUG-ITS at MIT-AI

:f %bbnu
hangs forever. Do all sites have finger servers? ITS should time out
intelligently (it certainly does if another ITS is down).
\1f
Date: 5 July 1982 15:09-EDT
From: David Chapman <zvona at MIT-AI>
Sender: ___013 at MIT-AI
To: BUG-ITS at MIT-AI

sys3;ts k is linked to sys3;ts logout which ain't they'.
\1f
Date: 1 July 1982 19:00-EDT
From: Ken Harrenstien <KLH at MIT-AI>
Subject: AI not accepting ARPAnet connections
To: BUG-ITS at MIT-AI, BUG-PWORD at MIT-AI

Hey, what's with this server telnet lossage?  Any attempt to
connect gets me a "ITS being deubbgged, go away" message,
but after two days of this crap I find that I can get in
via CHaos from MC.  I'm pretty pissed, since I've been
trying to get at my mail to process ATSIGN, HOSTS3, and
HEADER-PEOPLE stuff; also, unless I can get in you're
going to lose the disk space that all the digests take
up in my mail.

Would whoever slammed the door please consider that 99% of
network people are okay guys, and deserve a little notice.

While this is being put to rights, how about flushing PWORD
for connections from SRI-NIC?  That used to be set up OK
but someone apparently reset things.  Again I'm irked; I
used to think that friendships counted for something more
than being treated like a total random.
\1f
Date: 30 Jun 1982 1501-EDT
From: Robert P. Krajewski <RPK at MIT-XX>
Subject: XGPSEND
To: EBM at MIT-XX
cc: BUG-OZ at MIT-OZ, BUG-ITS at MIT-AI

[The Twenex program] does not work from XX or OZ.  It can't create a
spooling file.  Have some protocols been changed or something ?  Yes,
people don't use the XGP much, but ...

bob
-------
\1f
Date: 26 June 1982 11:41-EDT
From: Alan Bawden <ALAN at MIT-MC>
To: HDT at MIT-AI
cc: BUG-ITS at MIT-MC

Supdup figures that when you type <break>P you probably don't even want it as
your current job anymore, so it cleverly sets some OTHER job as being current.
That's what it's doing when it valrets <alt>1J to your DDT, it's trying to
select your PREVIOUSLY selected job.  This is why you somtimes get the error
message JOB GONE? when leaving a supdup (the previously selected job has
dissapeared since you started your supdup).

I guess it's somebody's idea of a feature.  I've never found the slightest bit
convienent.

\1f
Date: 25 June 1982 22:24-EDT
From: Howie Daniel Trachtman <HDT at MIT-AI>
To: BUG-ITS at MIT-AI
cc: HDT at MIT-AI

  This is minor, but I just thought you might like to know.
I had a supdup to oz which I typed <break>p to get back to ai`s ddt.

I then later had to :mc for something...
  Then I did a <break>p to get back to AI, and sent someone a message, and
did not start up any jobs.  However, when I did a :contin I got my oz job.
  Am I seeing things, or is this a bug?
BTW, my mc job was still around afterwards.

--Howard--
\1f
GJC@MIT-MC 06/22/82 23:31:39 Re: the strangest thing
To: (BUG ITS) at MIT-MC
I was running :CHTN HTJR, a vax running VMS. On the Vax I ran a program
which does a lot of I/O displaying information like a PEEK program
(it was a peek type program) and taking character input at interrupt level.
I ran this peek program looking at itself, and low and behold the CHTN
was too busy or something to listen very well, even to the CHTN break
character. That is, I found I could not break out of CHTN nor get
any response from the VAX which just kept outputing characters.
I then hung up the phone and redialed MC.
Being brave, I then did :UJOB GJC HACTRO and :SNARF CHTN.
The CHTN and the DDT then seemed to have control of the TTY at
the *same* time, DDT getting characters only once in a while
with the CHTN doing lots of output to my TTY. I then HUNG UP the phone
again, and sent this bug note.

Later... It seems I can reproduce this condition at will.

\1f
MOON@MIT-MC 06/19/82 20:25:44 Re: MC:.MAIL.;NAMES > is too large
To: (BUG ITS) at MIT-MC, (BUG MAIL) at MIT-MC
MC:.MAIL.;NAMES > is too large.  It is causing the mailer to run out of address
space frequently.  If you read the file, a great deal of it looks like pure trash.
I removed a few obviously obsolete entries; others should do the same.  It may
be necessary to remove some of the large mailing lsts into separate files
(using @FILE).  It would also be desirable to remove the personal entries for
people who no longer exist; I don't know if there is a reliable way to tell whether
someone no longer exists.  I also personally feel that the full-name entries at
the end of the file are worthless and should be flushed, although others may disagree.
\1f
Date: 17 June 1982 21:55-EDT
From: David Chapman <ZVONA at MIT-AI>
To: BUG-ITS at MIT-AI

It seems that the msgs times was reset sometime last night.
Everyone says that they had to read all the old messages again.
\1f
Date: 17 June 1982 20:21-EDT
From: Mark J. Dulcey <Dulcey at MIT-AI>
To: BUG-ITS at MIT-AI, BUG-BOLIO at MIT-AI, BUG-LISP at MIT-AI

I corrected a bug in the file AI: LMIO1; RFONTW >, and installed the
changes on the Lisp Machine.  However, I know that these functions are
also used by other folks (not on the Lisp Machine), so I thought I'd let
you know so you can recompile and load the new FASL files.
\1f
MOON5@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.
\1f
DCP@MIT-MC 06/14/82 11:52:49
To: RICH at MIT-MC
CC: (BUG ITS) at MIT-MC
    RICH@MIT-MC 06/14/82 10:35:45
    Will it be possible soon to have OZ: as a device from ITS
    like MC:, etc.

Not without a good deal of hacking.  They are different operating
systems, and OZ is not on the ARPAnet, which is what the infamous
MLDEV uses.  The standard ITS 6 character DIR, FN1 and FN2 will
not map well to a twenex file system, and not many programs
implement RMS's string open system call to get around this
problem.

\1f
DCP@MIT-MC 06/14/82 11:52:49
To: RICH at MIT-MC
CC: (BUG ITS) at MIT-MC
    RICH@MIT-MC 06/14/82 10:35:45
    Will it be possible soon to have OZ: as a device from ITS
    like MC:, etc.

Not without a good deal of hacking.  They are different operating
systems, and OZ is not on the ARPAnet, which is what the infamous
MLDEV uses.  The standard ITS 6 character DIR, FN1 and FN2 will
not map well to a twenex file system, and not many programs
implement RMS's string open system call to get around this
problem.

\1f
Date: Monday, 14 June 1982, 14:30-EDT
From: Christopher C. Stacy <CStacy at MIT-AI>
To: RICH at MIT-MC
Cc: BUG-ITS at MIT-MC

    RICH@MIT-MC 06/14/82 10:35:45
    To: (BUG ITS) at MIT-MC
    Will it be possible soon to have OZ: as a device from ITS
    like MC:, etc.
        

As I explained when we were deciding what operating system to
run, TOPS-20 doesn't have any facility for doing this sort of
thing.  It is a major task to write it into the guts of the
Tops-20 monitor.  I (or someone) will probably be working on it
in the near future, but it is likely to take a while.

Chris


\1f
MOON@MIT-MC 06/14/82 15:42:31 Re:  OZ: device
To: RICH at MIT-MC
CC: (BUG ITS) at MIT-MC
    RICH@MIT-MC 06/14/82 10:35:45
    To: (BUG ITS) at MIT-MC
    Will it be possible soon to have OZ: as a device from ITS
    like MC:, etc.

It's possible but unlikely.  The problem is that the inter-ITS
devices simply relay system calls from the remote machine to the foreign
machine.  20X has, of course, different system calls, and not all
the ITS system calls map simply into 20X system calls.  There is also
the issue of incompatible file name lengths and syntax.

On the other hand, since it was done for the FC: it can probably be
done for OZ also assuming someone is available to do the work.
If the FC: device used the standard file access protocol that 20X
already supports, it would have been trivial to extend it into an OZ:
device.  Since it uses a private protocol instead, either that protocol
will have to be implemented on TOPS-20 or an entirely new job-device
program will have to be written.
\1f
RICH@MIT-MC 06/14/82 10:35:45
To: (BUG ITS) at MIT-MC
Will it be possible soon to have OZ: as a device from ITS
like MC:, etc.
        
\1f
MCB@MIT-MC 06/11/82 21:20:13
To: (BUG ITS) at MIT-MC
I was just looking for some tip info and noticed that .info.;tip manual
on MC appears to have been clobbered sometime early this morning.

\1f
Date: 8 June 1982 18:07-EDT
From: David Vinayak Wallace <GUMBY at MIT-AI>
To: BUG-ITS at MIT-AI
cc: BUG-EMACS at MIT-AI

When I am in emacs on a AAA and I get a send while the screen is redisplaying,
part of the buffer is displayed under the mode line.
\1f
Date: 8 June 1982 12:30-EDT
From: Martin David Connor <MARTY at MIT-AI>
To: BUG-ITS at MIT-AI, USER-A at MIT-AI


I found not one, but wo bogus copies of OCTPUS on the
SYS directories.  One was 35 blocks long, and would not
BINPRT. The other was small, and unrecognizable.

Please keep your eyes open for this bogosity, because people
are using these to log in and do damage.  Thanks.

Marty

\1f
Date: Wednesday, 2 June 1982, 07:26-EDT
From: Robert W. Kerns <RWK at SCRC-TENEX>
Subject: 2-character escape sequences getting broken up
To: David A. Moon <Moon at SCRC-TENEX>
Cc: bug-its at MIT-AI
In-reply-to: The message of 27 May 82 03:00-EDT from David A. Moon <Moon at SCRC-TENEX>


    Date: Thursday, 27 May 1982, 03:00-EDT
    From: David A. Moon <Moon at SCRC-TENEX>
    DDT could avoid this by doing its interrupt-level typeout
    (e.g. of sends) on a separate I/O channel.
DDT doesn't do interrupt-level typeout.  DDT gets interrupted and goes
off and does other typeout, via the HAKKAH kludge.  I think the problem
is with ECHOED (at ITS interrupt level) typeout anyway, not with DDT's
typeout.
\1f
Date: 3 Jun 1982 1225-EDT
From: PDL at MIT-DMS (P. David Lebling)
To: MEYER at MIT-DMS
Cc: BUG-ITS at MIT-DMS, BUG-EMACS at MIT-DMS
Subject: M-X DIRED$MEYER;AR9:
Message-id: <[MIT-DMS].233727>

I was finally able to reproduce the problem, but it went away after
a while.  I have to assume that the problem is with EMACS, because
even when it was losing in EMACS saying :PRINT DIRAR9:NAME1 UP worked
in DDT.  Alternatively it may be a funny timing problem with the
archive or dir device.  In any case, I am CCing this to BUG-ITS and
BUG-EMACS in the hope that someone can help.

For those who are hearing about this problem for the first time,
in EMACS, M-X DIRED$MEYER;AR9: (and other archives, on DM) often
gets FILE LOCKED? errors.  It seems to always go away eventually, but
eventually return.  Could this be a JOBREU lossage with one of those
devices not reiniting properly?

        Dave


\1f
Date: Saturday, 29 May 1982, 23:27-EDT
From: Robert W. Kerns <RWK at SCRC-TENEX>
Subject: WHARTON
To: GSB at MIT-ML
Cc: bug-comsat at MIT-AI, bug-its at MIT-AI
In-reply-to: The message of 29 May 82 17:29-EDT from GSB at MIT-ML

    From: GSB@MIT-ML
    Date: 05/29/82 17:29:23
    GSB@MIT-ML 05/29/82 17:29:23
    Is wharton no longer on the arpanet, or is the host table trashed?
    It's in the arpanet-bboards list, but it took me a bit to track this
    down because comsat issued no diagnostic for a "TO:(BBOARD WHARTON)", just
    sent it to bboard locally (which is a dumb thing to do).

Wharton is off the arpanet due to administrative fuckup of some sort or
another.  They'll be back someday (at different address) when it all
gets straightened out.
\1f
DCP@MIT-MC 05/29/82 20:00:29
To: GSB at MIT-ML
CC: (BUG COMSAT) at MIT-ML, (BUG ITS) at MIT-ML
:host WHARTON
Lookup failed.

So, it is not in the host table on MC.  

CAH tells me that WHARTON punted the ARPAnet, or the other way
around.  Politics, or something like that. 


\1f
GSB@MIT-ML 05/29/82 17:29:23
To: (BUG COMSAT) at MIT-ML
CC: (BUG ITS) at MIT-ML
Is wharton no longer on the arpanet, or is the host table trashed?
It's in the arpanet-bboards list, but it took me a bit to track this
down because comsat issued no diagnostic for a "TO:(BBOARD WHARTON)", just
sent it to bboard locally (which is a dumb thing to do).

\1f
Date: 29 May 1982 15:05-EDT
From: Leonard N. Foner <FONER at MIT-AI>
To: BUG-ITS at MIT-AI

Something appears wrong with the way certain host names are
being displayed by FINGER.  While most of the lines printed
out are fine, FINGER is consistently showing these lines wrong:
FONER  T  Leonard N. Foner       F           T43  #27: At home
GYRO   A  Scott W. Layson        HACTRN    7.T44 Net site  (Chaos)

As you can see, the hostnames (in my case, MIT-TIP...  I don't know
about Scott) are not being displayed.  I dunno what's wrong.

Ciao.

                                                <LNF>
\1f
Date: Thursday, 27 May 1982, 03:00-EDT
From: David A. Moon <Moon at SCRC-TENEX>
Subject: 2-character escape sequences getting broken up
To: rwk at SCRC-TENEX
Cc: bug-its at MIT-AI

DDT could avoid this by doing its interrupt-level typeout
(e.g. of sends) on a separate I/O channel.
\1f
Date: Thursday, 27 May 1982, 02:18-EDT
From: Robert W. Kerns <RWK at SCRC-TENEX>
Subject: Illegal chr after control P
To: Michael Travers <MT at MIT-AI>
Cc: BUG-ITS at MIT-AI
In-reply-to: The message of 27 May 82 01:18-EDT from Michael Travers <MT at MIT-AI>

    Date: 27 May 1982 01:18-EDT
    From: Michael Travers <MT at MIT-AI>
    I was SUPDUPing to AI from XX.  While reading my mail with $^A I typed
    a space to a --More-- break.  It spat out:

    TTY: MT;     - ILLEGAL CHR AFTER CNTRL P ON TTY DISPLAY

    I can't reproduce this as nothing at all out of the ordinary was being
    done.  I did notice that there was new mail in my mail file that I had
    not seen a notification for; perhaps it was trying to print it when it
    got the error.
This is the usual screw with two-character escape sequences getting
asynchronous typeout intervening between them.
\1f
Date: 27 May 1982 01:18-EDT
From: Michael Travers <MT at MIT-AI>
To: BUG-ITS at MIT-AI

I was SUPDUPing to AI from XX.  While reading my mail with $^A I typed
a space to a --More-- break.  It spat out:

TTY: MT;     - ILLEGAL CHR AFTER CNTRL P ON TTY DISPLAY

I can't reproduce this as nothing at all out of the ordinary was being
done.  I did notice that there was new mail in my mail file that I had
not seen a notification for; perhaps it was trying to print it when it
got the error.
\1f
CSTACY@MIT-MC 05/22/82 22:20:21 Re: hung TVs
To: (BUG ITS) at MIT-MC
On AI, sometimes when you get a TV by hitting call, you get
wedged in TTYI.  It looks like the person get blocked at TYI1+20.
I dont know anything about that part of the system yet.

\1f
Date: 19 May 1982 1233-EDT
From: J. Noel Chiappa <JNC at MIT-XX>
To: CAMCAD at MIT-MC
cc: JNC at MIT-XX, bug-mail at MIT-AI, bug-its at MIT-AI, ellen at MIT-XX

        I doubt that ITS will ever implement InterNet, and I see no signs
of them implementing SMTP. In the meantime, you can get mail from ITS
to InterNet sites by sending mail to "person%final_host"@forwarder_host;
I am told that the ISI sites provide such a forwarding arrangement; others,
closer to MIT, should be appearing shortly.
-------
\1f
Date: 18 May 1982 21:29-EDT
From: David C. Plummer <DCP at MIT-MC>
To: BUG-ITS at MIT-MC, BUGDDT at MIT-MC, JPG at MIT-MC, ELLEN at MIT-MC,
    MERMAN at MIT-MC

I don't know if anybody else has checked recently, but all four
SYS directories are at least 95% full.  Should we try to clear
some out, or go to SYS4; (gack). 

\1f
DCP@MIT-MC 05/17/82 11:35:15
To: (BUG ITS) at MIT-MC
I replied to GJC (it was a user's (perhaps not his own) .MASK variable).

\1f
GJC@MIT-MC 05/17/82 02:30:57
To: (BUG ITS) at MIT-MC
Saw a funny thing on the system consol today:

223616/ 204202,,321560  204202,721560  STEVER  02:10:17

anybody know what that location might be?


\1f
Date: 15 May 1982 03:20-EDT
From: David A. Moon <MOON at MIT-MC>
Subject: MC mem D
To: ELLEN at MIT-MC
cc: BUG-ITS at MIT-MC

The problem with memory D is massive trauma to its electrical outlet
under the floor, and its plug.  The plastic is melted and somewhat
burned.  I left the floor pulled up and the plug unplugged so you
can see it.  I don't know whether this is due to a fault of mem D
itself, however I saw no evidence of burned wiring inside its power
control.  Neither the circuit breaker on mem D nor the one on the wall
is blown.  This will need the attention of some sort of electrician.

By the way, could you ask whoever is in charge not to block off maintenance
access to the MC machine?  I shoved the offending desk out into the main
passageway where it will cause a massacre if there is a fire--hopefully
this will ensure that it gets moved to someplace reasonable soon
(not shoved back in front of the machine where it blocks off the memory
doors).
\1f
Date: 12 May 1982 18:49-EDT
From: David Vinayak Wallace <GUMBY at MIT-AI>
To: BUG-ITS at MIT-AI

:f ken
PARERR; 14603>>TDNN 4,(5)   4/   1   50000/   TLZN 14,45602
\1f
Date: 11 May 1982 08:26-EDT
From: Martin David Connor <MARTY at MIT-AI>
Subject: GFR25
To: BUG-ITS at MIT-AI


Whoever did GFR 25 seems to have reaped the wrong files.

Since some twit opened all the files on the system on 2 April,
reference date was no good for reaping on.

The XGP login init was reaped, along with a couple other files.

Whoever did it, please fix it. Thanks.

Marty

\1f
Date: Friday, 7 May 1982  18:15-EDT
From: KLOTZ at BBNG
To:   bug-its at ai
cc:   pgs at BBNG
Subject:ITS Message Header on net.

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
PGS@MIT-AI 05/07/82 01:37:54
To: klotz at BBNG
Does this stuff work?  (I mean a qsend from AI).
  <rest of body omitted for brevity>
^_
\1f
Date:  7 May 1982 0947-EDT
From: S. W. Galley <SWG at MIT-XX>
Subject: strange ITS crash
To: bug-its at MIT-AI

I just now reloaded DM ITS after it was hung in user mode,
but with the parity-stop and run lights on.  I dumped it
to DM:CRASH;COMSYS >, because the light for job #5 (COMSYS COMSYS)
was lit.
PC/ 725717, parity buffer/ 0, pager mem addr/ 1,,337717 (in ARM-10),
parity error light off!
-------
\1f
Date: 6 May 1982 03:38-EDT
From: Patrick G. Sobalvarro <PGS at MIT-AI>
To: BUG-ITS at MIT-AI

I answered NEVES's question.
\1f
NEVES@MIT-MC 05/05/82 20:03:19
To: (BUG ITS) at MIT-MC
SIGH...
HOW DOES ONE GET A FILE FROM A CHAOSNET SITE SUCH AS SPEECH TO
MIT-MC WHILE ON THE MIT-MC END?   THE CFTP PROGRAM ON ITS
DOESN'T SEEM TO BE THE APPROPRIATE THING TO USE BECAUSE IT
DOESN'T ALLOW ONE TO LOGIN TO THE OTHER MACHINE.  -DAVE

\1f
Date: 4 May 1982 20:21-EDT
From: Christopher C. Stacy <CSTACY at MIT-AI>
Subject: weird!
To: BUG-COMSAT at MIT-AI
cc: BUG-ITS at MIT-AI


In COMSAT 380, ITS 1273, on MIT-AI:

COMSAT was not properly delivering mail to GUMBY.  The stats log says
the mail was delivered, and he got CLI messages saying it had been.
But the mail seems to have gone into a black hole.

I temporarily changed his netaddress to MC; receiving mail on another
host seems to work fine.  I wonder how many other people have been
losing mail, and how this could be happenning?

\1f
MOON@MIT-MC 05/02/82 01:55:58 Re:  JOB: device
To: ALAN at MIT-MC
CC: (BUG ITS) at MIT-MC
    ALAN@MIT-MC 04/30/82 01:38:18
    To: (BUG ITS) at MIT-MC
    Why does opening the JOB device with a non-existant file specified cause a job
    device handler creation/destruction loop?  Is this bizare behavior necessary to
    enable some debugging hack?  (Like where you write the file to be loaded after
    starting up the user??)  Or is this a bug and the thing should return some
    reasonable error code instead?
It might be that the bootstrap loader for the job has to fit in the AC's and
doesn't have enough locations left to signal an error -- maybe it does a .LOGOUT
thinking that will make ITS signal an error for it, but someone broke ITS to
reload the job instead?  Just a theory.
\1f
ALAN@MIT-MC 04/30/82 01:38:18
To: (BUG ITS) at MIT-MC
Why does opening the JOB device with a non-existant file specified cause a job
device handler creation/destruction loop?  Is this bizare behavior necessary to
enable some debugging hack?  (Like where you write the file to be loaded after
starting up the user??)  Or is this a bug and the thing should return some
reasonable error code instead?
\1f
ELLEN@MIT-MC 04/27/82 04:36:57 Re: Changing the default for :find
To: (BUG ITS) at MIT-MC
CC: GJC at MIT-MC
GJC didn't exactly explain it, but a better way to state the desired
change to the FIND program is, 

<hsname> should be assumed for directory unless another directory
specification is given, or *; is indicated.  

I think that covers it, is it possible?  Thanks.

\1f
GJC@MIT-MC 04/26/82 17:15:25
To: (BUG ITS) at MIT-MC
I think it would be a good thing to change the DEFAULT filename used by FIND.
The reason is that many people on the "USERS" type directories use find
to find their files, and these people invariably type something like
:FIND FOO*** therefore they end up searching the entire filesystem. In many
cases they aren't fully aware that they have been put on some directory
USERS7 lets say, so FIND is their only reasonable tool for listing the
files they own. Furthermore, if somebody does want to search the entire
filesystem, (perhaps not such a rare thing to do back in the days of ITS
when the FIND program was written) I think it reasonable to make the
person type something like :FIND ******;FOO.


\1f
DEVON@MIT-MC 04/25/82 00:51:44
To: (BUG ITS) at MIT-MC
is the Control-P Eye display code legit?
Rumor sez that ^P I x outputs x in image
mode, but I get weird cursor pos errors.
\1f
Date: Saturday, 24 April 1982, 20:46-EST
From: David Vinayak Wallace <GUMBY at MIT-AI>
Subject: Access from DC area
To: Bug-its at MIT-AI
Cc: info-cobol at MIT-AI

    Date: 23 Apr 1982 0809-EST
    From: PALLEN at MIT-DMS (Peter Allen)
    To: Bug-its at MIT-AI
    Subject: Access from DC area
    Message-id: <[MIT-DMS].230024>

      Hello!
         Is it my imagination but have you people turned off access from the Dc are


...WOW! Precognition!
\1f
Date: 23 Apr 1982 0809-EST
From: PALLEN at MIT-DMS (Peter Allen)
To: Bug-its at MIT-AI
Subject: Access from DC area
Message-id: <[MIT-DMS].230024>

  Hello!
     Is it my imagination but have you people turned off access from the Dc are

\1f
Date: 22 April 1982 19:43-EST
From: Leigh L. Klotz <KLOTZ at MIT-AI>
To: BUG-PWORD at MIT-AI
cc: BUG-ITS at MIT-AI

On ai's pword, in :send, with an h19 or printing ttyps (at least),
tab echoes as ^I, and rubout doesn't back up over carriage
returns, although it deletes characters (as shown by ctrl-l).

Who broke this?
Leigh.
\1f
Date: 20 Apr 1982 1054-EST
From: Robert W. Kerns <RWK at SCRC-TENEX>
To: MARTY at MIT-AI, BUG-ITS at MIT-AI
cc: RWK at SCRC-TENEX
In-Reply-To: Your message of 20-Apr-82 0105-EST

This happens when you have enabled DDT to search directories recently
looked at, and one of the directorys you recently looked at doesn't
exist (locally).  DDT is telling you the actual error it got.  ITS
is telling you what was wrong with what DDT gave it.  DDT shouldn't
be putting things on its list of recent directories without verifying
that they exist, but I'm in no hurry to fix this very occasional
minor annoyance.
-------
\1f
Date: 20 April 1982 00:37-EST
From: Martin David Connor <MARTY at MIT-AI>
To: BUG-ITS at MIT-AI

Doing :o gives the error message "NON-EXISTENT DIRECTORY"
should it not say file not found or something more informative?

Marty

\1f
Date: 19 April 1982 22:39-EST
From: Christopher C. Stacy <CSTACY at MIT-AI>
To: EB at MIT-AI
cc: BUG-ITS at MIT-AI


If you have some files which you urgently want and they're zeroed on
pack 15, why dont you ask for them to be restored by sending mail to
File-Retrieve.

Due to multiple theories about how to proceed, the original
restoration process was somewhat screwed up.  Now, things that arent
asked for specially will get restored as people have time to do so.
\1f
Date: 19 April 1982 22:05-EST
From: Edward Barton <EB at MIT-AI>
To: BUG-ITS at MIT-AI

Is pack 15 ever going to have anything except zeros on it?
\1f
Date: 19 April 1982 02:06-EST
From: Martin David Connor <MARTY at MIT-AI>
Subject: Anatomy of Lossage
To: BUG-ITS at MIT-AI, USER-ACCOUNTS at MIT-AI, AGRE at MIT-AI,
    user-accounts at MIT-MC


I examined the system log, and the lossage of last friday happened
something like this.

1) a user logged in as MINI0, :CHUNAMed to CRETIN, and started to
   play.  First he/she copied DDT to the file sys;z ddt, then copied
   that file to SYS3;TS OCTPUS . This would allow logging in from
   PWORD without a password.

2) CRETIN then logged out, and then ___010 took over. First he/she
   deleted PANDA, then LOCK.  


Account MINI0 has been deleted. As has account CRETIN. The OCTPUS
(camaflaged DDT) has been deleted. LOCK has been reinstalled.
The system is approximately as it was.

Marty

\1f
Date: Friday, 16 April 1982, 01:12-EST
From: David A. Moon <Moon at SCRC-TENEX>
To: Patrick G. Sobalvarro <PGS at MIT-AI>
Cc: BUG-ITS at MIT-AI
In-reply-to: The message of 15 Apr 82 12:49-EST from Patrick G. Sobalvarro <PGS at MIT-AI>

    Date: 15 April 1982 12:49-EST
    From: Patrick G. Sobalvarro <PGS at MIT-AI>
    To: BUG-ITS at MIT-AI

    This morning's crash is on AI:CRASH;1273 CRASH.

    It broke at 137720.  Someone more knowledgeable than me should 
    probably look at it.  Incidentally, 137720 is nowhere near the
    TTY code, as nearly as I can tell.  Memory was acting flakey
    two hours before the crash.

This looks like an instruction failed to execute properly.  The system job
is trying to get rid of a running job in the mistaken impression that its
bit saying that it has done a .LOGOUT and should go away is set.  The bit
is not set and there is no sign that it has been.  (Possibly the job has
already gone away and this is a new job that somehow took its place, since
it looks like it is just starting up.)  There isn't any sign of register U
having been clobbered; it had the same value much earlier in SYSGUN when
DMNPLO was called.

If it was hot in the machine room at the time this crash occurred, it was
most likely a hardware failure.
\1f
Date: 15 April 1982 12:49-EST
From: Patrick G. Sobalvarro <PGS at MIT-AI>
To: BUG-ITS at MIT-AI

This morning's crash is on AI:CRASH;1273 CRASH.

It broke at 137720.  Someone more knowledgeable than me should 
probably look at it.  Incidentally, 137720 is nowhere near the
TTY code, as nearly as I can tell.  Memory was acting flakey
two hours before the crash.
\1f
Date: 14 April 1982 22:02-EST
From: Patrick G. Sobalvarro <PGS at MIT-AI>
To: ZVONA at MIT-AI
cc: DPH at MIT-AI, BUG-ITS at MIT-AI

    Date: Wednesday, 14 April 1982, 16:55-EST
    From: David Chapman <Zvona at MIT-AI>

        There's some bogosity here, but it isn't in ITS.  What you are
        complaining about is not a bug, but a feature. ... the error
        message you got meant that the system was full, and a job slot
        couldn't be found to load the job into.

    Well then the bogosity is that ITS is not smart enough to
    interpret the error that it gets when it can't find a job slot
    for a jobdev job.  I can hardly see that that is a feature.

I'm not sure what you mean by this.  If ITS weren't smart enough to
understand the condition that occurs when it can't find a job slot for
a jobdev job, it wouldn't give you an error message at all.  It would
just blow out.  As it happens, ITS generates a perfectly good error
message when it can't find a job slot for a jobdev job.  In fact, in
the cases you folks were reporting, DDT was even reporting the
condition to the user.  It IS a shame that the error message is the
same as that given when one attempts to write to a full pack.

If the AI lab had decided to continue using ITS, it would have been a
good thing to modernize some of the error messages.  At the time ITS
was first written, they were probably the most informative error
messages around.  Nowadays, however, we have operating systems like
Twenex that give you lowercase error messages, and nothing like the
functionality of job devices.  I can hardly see that this is a
feature.
\1f
Date: 14 April 1982 21:13-EST
From: Alan Bawden <ALAN at MIT-MC>
To: BUG-ITS at MIT-MC, Zvona at MIT-AI
cc: DPH at MIT-MC, PGS at MIT-MC


    Well then the bogosity is that ITS is not smart enough to
    interpret the error that it gets when it can't find a job slot
    for a jobdev job.  I can hardly see that that is a feature.

No, the real problem is that the only mechanism ITS has to communicate the
error to you is that it gets to return one of 47 (octal) error codes.  If we
were designing ITS today we probably wouldn't do things that way, but...

Perhaps a better error code (one that corresponds to a better error message)
could be chosen for this situation.  I forget now just what it is that you DO
get (device full?), but scanning the list I would say that 10 (%ENADV, "DEVICE
NOT AVAILABLE") is nicely ambiguous about exactly why you lost in this
situation (system full).
\1f
Date: 14 April 1982 21:13-EST
From: Alan Bawden <ALAN at MIT-MC>
To: BUG-ITS at MIT-MC, Zvona at MIT-AI
cc: DPH at MIT-MC, PGS at MIT-MC


    Well then the bogosity is that ITS is not smart enough to
    interpret the error that it gets when it can't find a job slot
    for a jobdev job.  I can hardly see that that is a feature.

No, the real problem is that the only mechanism ITS has to communicate the
error to you is that it gets to return one of 47 (octal) error codes.  If we
were designing ITS today we probably wouldn't do things that way, but...

Perhaps a better error code (one that corresponds to a better error message)
could be chosen for this situation.  I forget now just what it is that you DO
get (device full?), but scanning the list I would say that 10 (%ENADV, "DEVICE
NOT AVAILABLE") is nicely ambiguous about exactly why you lost in this
situation (system full).
\1f
Date: Wednesday, 14 April 1982, 16:55-EST
From: David Chapman <Zvona at MIT-AI>
To: PGS at MIT-AI, DPH at MIT-AI
Cc: BUG-ITS at MIT-AI
In-reply-to: The message of 14 Apr 82 16:14-EST from Patrick G. Sobalvarro <PGS at MIT-AI>

    There's some bogosity here, but it isn't in ITS.  What you are complaining
    about is not a bug, but a feature. ... the error message
    you got meant that the system was full, and a job slot couldn't be found to
    load the job into.

Well then the bogosity is that ITS is not smart enough to
interpret the error that it gets when it can't find a job slot
for a jobdev job.  I can hardly see that that is a feature.
\1f
Date: 14 April 1982 16:14-EST
From: Patrick G. Sobalvarro <PGS at MIT-AI>
To: ZVONA at MIT-AI, DPH at MIT-AI
cc: BUG-ITS at MIT-AI

    From: David Chapman <zvona at MIT-AI>
    Sender: DPH at MIT-AI

    mc^K => ERROR: OPEN:  USR: DPH;  - DEVICE FULL
    levitt\e^A => MC: USERS4; LEVITT MAIL - DEVICE FULL

    Obviously there is some fundamental bogosity here.

There's some bogosity here, but it isn't in ITS.  What you are complaining
about is not a bug, but a feature.  ITS has these things called JOBDEVs, or job
devices.  They are what allow you to access files on other machines, get a
pretty printout of the XGP queue, list your directory in various nice formats,
and all sorts of other nice things.

When you attempt to access a device whose name is not recognized by ITS, ITS
loads up a program called ATSIGN DEVICE, which searches for a file called
JOBDEV <device name> on the directory DEVICE;.  If it finds it, it loads it up
and runs it.  If it doesn't find it, it errors out.  However, the error message
you got meant that the system was full, and a job slot couldn't be found to
load the job into.
\1f
Date: 14 April 1982 13:22-EST
From: David Chapman <zvona at MIT-AI>
Sender: DPH at MIT-AI
To: BUG-ITS at MIT-AI

mc^K => ERROR: OPEN:  USR: DPH;  - DEVICE FULL
levitt\e^A => MC: USERS4; LEVITT MAIL - DEVICE FULL

Obviously there is some fundamental bogosity here.
\1f
PGS@MIT-MC 04/11/82 07:04:00
To: MARTY at MIT-MC
CC: (BUG ITS) at MIT-MC
Marty, you recently made a change to TTYTYP >.  When you made your
change, you also added gratuitous spaces before the tty numbers given
as arguments to the TTxxx macros, which made them not assemble
properly.  Please be more careful about this sort of thing if you're
going to modify the sources.

\1f
Date: 10 April 1982 16:02-EST
From: Martin David Connor <MARTY at MIT-AI>
Subject:  OZ Shutdown
To: BUG-ITS at MIT-AI, BUG-OZ at MIT-AI, WIZARDS-OF-OZ at MIT-AI

Between friday night and saturday morning the following events
occured:

- One of the air conditioning package units began to put out   
  70 degree air (50 degrees is normal).

- AI began to get massive amounts of ECC errors. So many that the
  console could not keep up.

I called FIXIT to come and look at the A/C. They came and the
temperature went back down some.

At this point, with the help of RMS and RG I replaced defective chips
in the Stardust memory.

- Early Saturday morning OZ got a memory parity error and shut itself
  down. I am not certain this was caused by excessive heat.

- I decided that there was no point in leaving it powered on with the 
  air conditioning marginal, I powered down OZ.

-----------

What is being done about the A/C problem:

Physical plant claims that the air conditioning is "balanced" with the
idea that the major sources of heat on the 9th floor are ML and DM.
This was once true, and worked. it is no longer good enough.

I am preparing a map of the 9th floor so that they can redistribute
the A/C in a way that makes better sense. My map will be ready Monday
morning, and hopefully they can come in the same day.

-----------

What this means w.r.t. OZ coming up:

DEC may decide to start the 72 acceptance test again because of the
parity error. This could delay our getting the machine.

-----------

Opinion:

Since DEC has only taken 2 weeks so far, I am willing to be patient
and get things done right rather than risk losing AI by making too
fast a move.  

-----------

This is bothersome, but with all of the things that have gone right,
this minor setback is just that, minor.

News as it happens;

Marty

\1f
Date: 9 April 1982 18:05-EST
From: Christopher C. Stacy <CSTACY at MIT-AI>
Subject: bogus ITS version number resolved
To: BUG-ITS at MIT-AI

When I reloaded AI this afternoon, I reassembled ITS so that
the version number went up.  AI now has ITS 1270, which has
PGS's TS3TTY changes in it, as NITS.
(DDT, PEEK, NAME repurified.)
\1f
Date: 8 April 1982 22:19-EST
From: Christopher C. Stacy <CStacy at MIT-AI>
Subject: The :NAME program
To: Moon at SCRC-TENEX
cc: PGS at MIT-AI, AGRE at MIT-AI, BUG-ITS at MIT-AI,
    BUG-NAME at MIT-AI

    Date: Thursday, 8 April 1982, 17:22-EST
    From: David A. Moon <Moon at SCRC-TENEX>
    Subject: The :NAME program
    To: pgs at MIT-AI, agre at MIT-AI, bug-its at MIT-AI, bug-name at MIT-AI

    Did someone do something like copy SYSBIN;NAME BIN to SYS;TS NAME ?  

Looks as though something like that happenned.  I just reinstalled the
binary and pure versions in the right places.
\1f
Date: Thursday, 8 April 1982, 17:22-EST
From: David A. Moon <Moon at SCRC-TENEX>
Subject: The :NAME program
To: pgs at MIT-AI, agre at MIT-AI, bug-its at MIT-AI, bug-name at MIT-AI

The DEBUG switch is *supposed* to be set in SYSBIN;NAME BIN, the output
of assembling NAME.  The file SYS;TS NAME, the output of purifying NAME,
is *not* the same file, does not contain the same stuff, and is not
supposed to have the debug switch set.  It also completely takes care of
installing itself when a new system is put in or it is moved from
machine to machine, as long as DEBUG isn't set to suppress that.

Did someone do something like copy SYSBIN;NAME BIN to SYS;TS NAME ?  It
seems like a real waste for someone (not me) to have gone to a lot of
trouble to make this program install itself automatically if people are
going to go jamming monkey wrenches into the works anyway.
\1f
Date: 8 April 1982 12:11-EST
From: Patrick G. Sobalvarro <PGS at MIT-AI>
Subject: name and finger losing in this morning's ITS
To: AGRE at MIT-AI
cc: BUG-ITS at MIT-AI, BUG-NAME at MIT-AI

NAME was reinitialized because we had a new system this morning, and
someone had left DEBUG set in SYSBIN;NAME BIN, so it didn't kill
itself when it was done.  This is fixed now.

NAME hackers should remember to clear DEBUG when making a new dump, or
we get confused users.
\1f
Date: 8 April 1982 11:15-EST
From: Philip E. Agre <AGRE at MIT-AI>
To: BUG-ITS at MIT-AI

:NAME loses in the ITS that was brought up this morning.  You get
.VAL 0; 252>>.LOGOU   0/   10400,,500000
when it's done.
\1f
Date: 6 April 1982 13:44-EST
From: Leigh L. Klotz <KLOTZ at MIT-AI>
To: DCB at MIT-AI, RZ at MIT-AI, PSZ at MIT-AI, BUG-ITS at MIT-AI
cc: CSTACY at MIT-AI

Ai is having some sort of hardware-like trouble.

It crashes with a BAD PI 2, and then gets wedged so that
STOP/RESET/START gives the same BUGHLT error.  That's
very strange, since it's not even running ITS then.

Anyway, one time when this happened just before ITS
crashed it printed out  777144,,000000  DIRECTORY NTEXLB
TRASHED, or something like that.

The salvager didn't report anything unusual.

Leigh.
\1f
Date:  6 Apr 1982 0952-EST
From: PDL at MIT-XX
To: GJS at MIT-MC, (BUG ITS) at MIT-MC
In-Reply-To: Your message of 6-Apr-82 0107-EST

No it doesn't; you asked it to find all "sav4 *" and script the
results to mc:scheme;.  You must quote the underbar with a ^Q.
-------

\1f
Date: 6 April 1982 01:34-EST
From: Patrick G. Sobalvarro <PGS at MIT-AI>
To: GJS at MIT-MC
cc: BUG-ITS at MIT-AI

    GJS@MIT-MC 04/06/82 01:07:00
    I don't know where this bug should go, but 
    :find mc:scheme;_sav4 *
    goes into an infinite loop.

FIND's JCL syntax is pulling a quick one on you.  "_" means "the thing
that comes before this is an output file specification."  So what
happened was this: FIND looked for all files that matched the pattern
SAV4 * on all directories on MC, and sent the output to SCHEME;FIND
OUTPUT.  Since FIND takes such a long time on MC, and it spends most
of its time doing .OPENs, it looked like it was hanging in one .OPEN.
\1f
GJS@MIT-MC 04/06/82 01:12:50
To: (BUG ITS) at MIT-MC
Sorry about last message -- bug seems to have disappeared after I renamed
_SAV4 6 to FOO 1.  The way it hung was in .OPEN.  When renamed back to
old name, it worked.  Seems to be some kind of disk lossage, but I dunno
how to describe it better.  Perhaps the directory is slightly inconsistent
or something?

\1f
GJS@MIT-MC 04/06/82 01:07:00
To: (BUG ITS) at MIT-MC
I don't know where this bug should go, but 
:find mc:scheme;_sav4 *
goes into an infinite loop.

\1f
Date: 31 March 1982 07:25-EST
From: Glenn S. Burke <GSB at MIT-ML>
Subject: fc lossage?
To: BUG-its at MIT-AI
cc: BUG-LISP at MIT-ML, EB at MIT-ML

    Date: 30 March 1982 19:31-EST
    From: Edward Barton <EB at MIT-AI>

    :lisp
    LISP 2122
    Alloc? n
    *
    (open "fc:eb;ef >")
    MPV; 61322>>.CALL 61641 (RCHST)
----
The MPV does not come from the call, and no words have been written by it.
This does not happen on ML, where apparently no one has been updating
DEVICE;JOBDEV FC for some time.

\1f
Date: Tuesday, 30 March 1982, 03:10-EST
From: Robert W. Kerns <RWK at SCRC-TENEX>
Subject: OPEN
To: Leigh L. Klotz <KLOTZ at MIT-AI>
Cc: BUG-DDT at MIT-AI, BUG-ITS at MIT-AI
In-reply-to: The message of 27 Mar 82 18:05-EST from Leigh L. Klotz <KLOTZ at MIT-AI>


    Date: 27 March 1982 18:05-EST
    From: Leigh L. Klotz <KLOTZ at MIT-AI>
    Shouldn't OPEN on the tty for output cause ddt to ask you to give
    the tty to the job?  It doesn't seem to.
    I first noticed this behavior several months ago with R, which
    would run apparently OK ^P'd, but print out the first error
    message (from processed text) as soon as \eP'd.
    I guess this is because it didn't open the tty until then,
    or something.

    I just ^Z'd a finger and ^P'd it before it had printed out
    the hostname in brackets.  As soon as I \eP'd it, it printed
    that out.  It hadn't asked for the tty.
It always asks for me.  Note that it's not OPEN that should ask
for the TTY, but trying to use it.
\1f
Date: 27 March 1982 18:05-EST
From: Leigh L. Klotz <KLOTZ at MIT-AI>
Subject: OPEN
To: BUG-DDT at MIT-AI
cc: BUG-ITS at MIT-AI

Shouldn't OPEN on the tty for output cause ddt to ask you to give
the tty to the job?  It doesn't seem to.
I first noticed this behavior several months ago with R, which
would run apparently OK ^P'd, but print out the first error
message (from processed text) as soon as \eP'd.
I guess this is because it didn't open the tty until then,
or something.

I just ^Z'd a finger and ^P'd it before it had printed out
the hostname in brackets.  As soon as I \eP'd it, it printed
that out.  It hadn't asked for the tty.

Leigh.
\1f
Date: 27 March 1982 12:03-EST
From: Christopher C. Stacy <CSTACY at MIT-AI>
To: BUG-ITS at MIT-AI

AI now has ITS 1269 as ITS.

The old NITS is named OITS, and there is no NITS or NITS1;
we go back to the canonical naming conventions on this
machine now.

This version has a fix in the RENAMEF call by RMS, which
is not the same as the patch by Moon.

DDT and PEEK were repurified.

Chris
\1f
Date: 27 March 1982 02:39-EST
From: Patrick G. Sobalvarro <PGS at MIT-AI>
To: BUG-ITS at MIT-AI

Explanatory note about my last message - @ NITS1 was trashed in the
crash tonight.  We're running NITS right now.  I was trying to recover
@ NITS1 from backup.
\1f
Date: 27 March 1982 02:37-EST
From: Patrick G. Sobalvarro <PGS at MIT-AI>
To: BUG-ITS at MIT-AI

I just tried to get @ NITS1 off backup; DUMP shows the version of 3/5 on tape
206.  Unfortunately, tape 206 seems not to have any such file on it, although
it has lots of other files on it.  I suspect that this lossage is brought to us
courtesy of the wonderful folks who are always leaving backup tapes strewn
everywhere about the floor; that is, I think the tape I have is mislabelled.

In any case, I think it'll be easier to generate @ NITS1 again than to find the
right tape.  Is there someplace I can find the patches and make them to NITS,
or should I assemble a new ITS?
\1f
WJL@MIT-ML 03/26/82 09:20:37 Re: ttyvar documentation out of date
To: (BUG ITS) at MIT-ML
tctyp also has a number for Z19's thats not in the table -- are there others?
\1f
Date: 22 March 1982 15:42-EST
From: David C. Plummer <DCP at MIT-MC>
To: MOON at SCRC-TENEX
cc: DCP at MIT-MC, BUG-ITS at MIT-MC, rsl at MIT-MULTICS

Small techincal point: The RFC for SUPDUP says that %TPCBS MUST
be on.  Indeed, ITS doesn't care , but other systems may.

So %TPMTA is ONLY used for hard wired terminals?  This is
unfortunate.  For purposes of modularity, I think that ITP should
only be a transport mechanism for 7, 8, or 12 bit characters and
know nothing of the character set it is transporting.  Once thee
character is assembled at the server, the server should look at
%TOFCI and %TPMTA (it doesn't make much sence for both to be on)
and do the system dependent things to the characters.

mumble... It's probaly not worth flaming about, since became an
issue in my terminal concentrator code, and it looks like I will
be using the 12.bit character set anyway...

\1f
Date: Monday, 22 March 1982  02:25-EST
From: MOON at SCRC-TENEX
To:   dcp at mc
cc:   bug-its at mc, bug-supdup at mc, rsl at multics

    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.
\1f
REM@MIT-MC 03/19/82 19:56:39
To: (BUG ITS) at MIT-MC
Hmmm, in the middle of RMAIL typing out some text onto the screen,
it stopped typing. I waited a minute or so but it didn't continue, so
I tried to close network connection but it didn't close, so I RESET the
TIP port and reconnected, but upon attaching to my detached tree after
connect TTYAC4+4>> typed out something about can't get the TTY (which
got overprinted by BUG when I backspaced and it decided to put the cursor
where it should be instead of where it had been) and then entered that
breakpoint (which is also now overtyped). I guess I'll see now if
I can continue my RMAIL any.

\1f
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)
 
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.  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? 

\1f
Date: 18 March 1982 01:47-EDT
From: Edward Barton <EB at MIT-AI>
To: BUG-ITS at MIT-AI

When the system is revived it often happens that the datapoint
controller gets wedged somehow.  The result is that VT52's and
such do not get the revived message, or if the system got reloaded
may not get the message saying the system is in operation.  (I
may be confused about that case.)  Lock's DPK command fixes things
if you manage to figure out that the system is in fact up
even though your VT52 or Ambassador behaves as if it weren't.
Is there some way a DPK could happen automatically when the
system is revived?
\1f
CBF@MIT-MC 03/11/82 12:58:20 Re: your crash dump
To: MOON at MIT-MC
CC: DCP at MIT-MC, CBF at MIT-MC, (BUG ITS) at MIT-MC
The PC is on the system console somplace of course, I think I might even
have written it in the log.

\1f
MOON@MIT-MC 03/09/82 02:41:06 Re: your crash dump
To: DCP at MIT-MC, CBF at MIT-MC
CC: (BUG ITS) at MIT-MC
    DCP@MIT-MC 03/08/82 13:22:48
    To: (BUG ITS) at MIT-MC
    MC was very sick earlier today.  CBF dumped the original problem to
            CRASH WEDGED
Since you don't say what the PC was, it's a bit hard to tell what's going on.
It seems to be actively transferring on both disk controllers, but looping
at UCPRL with interrupts inhibited.  Was the PC written on paper somewhere?
\1f
DCP@MIT-MC 03/08/82 13:22:48
To: (BUG ITS) at MIT-MC
MC was very sick earlier today.  CBF dumped the original problem to
        CRASH WEDGED
Some symptoms: most .OPENs and .IOTs hung.  I could do DCP^F,
DCP2^F .TEMP.^F, but not SYS^F, SYS1^F, or even TTY^F.  This
almost looks like a directory cache problem.  Unit 4 (T-300) got
several errors shortly before this all happened.  Strangness:  I
could run programs that were in my directory (presumably becuase
my directory was cache). 

After several attempts to reload, we succeeded, but we are not
sure what caused it to win.  We cycled all three T-300, power
cycled unit 3, and set IMPUP/0 (thinking it might be the
ARPAnet).  Some combintation of this caused it to come up,
finally. 

\1f
DCP@MIT-MC 03/08/82 13:22:48
To: (BUG ITS) at MIT-MC
MC was very sick earlier today.  CBF dumped the original problem to
        CRASH WEDGED
Some symptoms: most .OPENs and .IOTs hung.  I could do DCP^F,
DCP2^F .TEMP.^F, but not SYS^F, SYS1^F, or even TTY^F.  This
almost looks like a directory cache problem.  Unit 4 (T-300) got
several errors shortly before this all happened.  Strangness:  I
could run programs that were in my directory (presumably becuase
my directory was cache). 

After several attempts to reload, we succeeded, but we are not
sure what caused it to win.  We cycled all three T-300, power
cycled unit 3, and set IMPUP/0 (thinking it might be the
ARPAnet).  Some combintation of this caused it to come up,
finally. 

\1f
HIC@MIT-MC (Sent by HIC0@MIT-MC) 03/07/82 21:03:25
To: (BUG ITS) at MIT-MC
MC's IO-11 was wedged in some unknown fashion.  I reloaded it from home,
and it got fixed.

\1f
HIC@MIT-MC (Sent by HIC0@MIT-MC) 03/07/82 21:08:53
To: (BUG ITS) at MIT-MC
Well, MC's IO-11 crashed again,and I reloaded it again.  Maybe it's a more
organic failure than I thought.

\1f
HIC@MIT-MC (Sent by HIC0@MIT-MC) 03/07/82 21:03:25
To: (BUG ITS) at MIT-MC
MC's IO-11 was wedged in some unknown fashion.  I reloaded it from home,
and it got fixed.

\1f
MOON@MIT-MC 03/05/82 02:46:04
To: (BUG ITS) at MIT-MC
The RFNAME system call is broken such that it trashes random locations
in user memory.  This was killing the mailer on MC, so I patched the running system
and the dump.  Patch is to change NRFNAM+22 from JUMPE Q,POPJ1 to JRST POPJ1.
The bug is that the code assumes that device-dependent RFNAME routines don't
clobber Q.  The one for the Arpanet does.
\1f
dcp@MIT-MC (Sent by HGA@MIT-MC) 03/05/82 01:10:32
To: (BUG ITS) at MIT-MC
I took a quick look, and somebody changed the RFNAME code between ITS 
version 1261 and 1266.  Did this break things?

\1f
dcp@MIT-MC (Sent by HGA@MIT-MC) 03/05/82 01:03:35
To: (BUG ITS) at MIT-MC
RFNAME on some NET: and some CHAOS: channels seems to be broken.  This
started happening within the last week I think.  For an example, pick
an ARPA telser and from PEEK try to look at is variables with the V
command.  This is causing comsat to die at the moment getting a a PURPG
on an RFNAME of a CHAOS channel.

\1f
Date: 4 March 1982 18:45-EST
From: Earl A. Killian <EAK at MIT-MC>
Subject:  hardware/microcode mod
To: CSTACY at MIT-AI
cc: BUG-its at MIT-AI

I thought the Jump in JFFL was what the programmer does if
there's a free Lispm.

\1f
Date:  4 March 1982 1604-EST (Thursday)
From: Guy.Steele at CMU-10A
To: Christopher C. Stacy <CSTACY at MIT-AI> 
Subject:  Re: hardware/microcode mod
CC: bug-its at MIT-AI
In-Reply-To:  Christopher C. Stacy's message of 4 Mar 82 02:06-EST

I assume that the new instruction JFFL (Jump if Find Free Lispmachine)
is equivalent to JUMP (Do Not Jump)!
--Guy
\1f
Date: 4 March 1982 11:43-EST
From: David C. Plummer <DCP at MIT-MC>
Subject: hardware/microcode mod
To: CSTACY at MIT-AI
cc: INFO-COBOL at MIT-MC, BUG-ITS at MIT-AI

:doc instr JFFL

JFFL ac,E       Jump on Find Free LispMachine
skip if at least one free lisp machine matching some description

the value at E contains an AOBJN pointer.  The AOBJN pointer
points to ASCIZ strings in one of two forms:
        <building>-<room>  or CADR-<number>
The star convention is allowed for building and room.  It is not
allowed for the CADR number. 

ac is a pointer to a block of zero words followed by a non-zero
word which will receive an string of 7-bit characters (similar to
JCL passing).  It is suggested that the non-zero word be 1, which
will cause the string to be ASCIZ.  The string returned is a list
of rooms (without stars) or free machines separated by commas.

Example:

        move ac,freeLM
        JFFL ac,[-3,,[ [asciz /NE43-8**/]       ;an 8th floor cadr
                       [asciz /CADR-2/]         ;color
                       [asciz /38-350/]         ;EECS terminal room
                       ]]
         jrst .-1               ;I just gotta have one

freeLM: repeat 10,[ 0 ? ] 1

\1f
Date: 4 March 1982 02:06-EST
From: Christopher C. Stacy <CSTACY at MIT-AI>
Subject: hardware/microcode mod
To: BUG-ITS at MIT-AI


  All ITS machines now have hardware for a new machine instruction:
                 JFFL - Jump if Find Free Lispmachine

\1f
MOON5@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.
\1f
Date: 3 March 1982 01:54-EST
From: James M. Turner <JMTURN at MIT-AI>
Subject: Disk Writes
To: BUG-ITS at MIT-AI

*sigh* Does it try to write even if the pack with the most space is
not enough. Alternately, is there any way to "reserve" the proper amount
of space (again, approximately) so the other can't snarf it?
\1f
MOON@MIT-MC 03/03/82 01:52:34
To: JMTURN at MIT-AI
CC: (BUG ITS) at MIT-MC
    Date: 2 March 1982 23:14-EST
    From: James M. Turner <JMTURN at MIT-AI>
    To: BUG-ITS at MIT-AI

    the fact that various demons (notably INQUIR UPDATE) will try to create
    new files of estimatably size on packs without that much space seems
    unreasonable. Rather than have these programs tie up that time and space
    with unfinished files, why not have them make a rough guess as to the size
    of the file, and pick a pack accordingly. The present setup requires
    some poor hacker to clear off sufficient space for the update.

Files are always written on the pack with the most space.  Unfortunately,
when the file takes a long time to write, someone else can come in and grab
the space before the file finishes being written.
\1f
Date: 2 March 1982 23:14-EST
From: James M. Turner <JMTURN at MIT-AI>
To: BUG-ITS at MIT-AI

the fact that various demons (notably INQUIR UPDATE) will try to create
new files of estimatably size on packs without that much space seems
unreasonable. Rather than have these programs tie up that time and space
with unfinished files, why not have them make a rough guess as to the size
of the file, and pick a pack accordingly. The present setup requires
some poor hacker to clear off sufficient space for the update.
                                        James
\1f
DCP@MIT-MC 02/24/82 21:05:49
To: (BUG ITS) at MIT-MC
I case anybody cares, the reason MC was down memory 200-577 was
that the AMPEX start address switches were set wrong.  My theory
is that when DEC Field Circus re-enabled sector 0 a finger kept
going in the up-right direction and flipped the address switch.
There is now a piece of paper on the inside of the AMPEX door
wich gives a correct setting of the switches.


\1f
CSTACY@MIT-MC 02/24/82 21:53:16
To: MOON at MIT-MC
CC: (BUG ITS) at MIT-MC
I renamed the ITS dumps on MC in the canonical fashion as you suggested.
NITS1 is current, ITS is old.  Next patched ITS should be dumped out as NITS.
Older stuff migrated to OxITS files.  Copy of NITS1 on BACKUP.

Chris

\1f
Date: Wednesday, 24 February 1982, 20:20-EST
From: Robert W. Kerns <RWK at SCRC-TENEX>
Subject: Abnormal LOGOUT TIMES
To: Edward Barton <EB at MIT-AI>
Cc: BUG-ITS at MIT-AI
In-reply-to: The message of 24 Feb 82 17:51-EST from Edward Barton <EB at MIT-AI>

    Date: 24 February 1982 17:51-EST
    From: Edward Barton <EB at MIT-AI>
    To: BUG-ITS at MIT-AI

    Is this peculiar segment of CHANNA;LOGOUT TIMES normal, and
    will it hurt anything?  It seems to have the effect of making
    logout times for people beyond the discontinuity inaccessible
    to :when.

    RJA   01/17/82 01:33:18
    RJD   02/24/82 09:21:18
    RK    02/16/82 02:20:32
     02/19/82 14:16:10
    RLB   01/11/82 23:38:59
    RLL   02/20/82 20:24:08
It's abnormal, delete that line.
\1f
Date: Wednesday, 24 February 1982, 20:15-EST
From: Robert W. Kerns <RWK at SCRC-TENEX>
Subject: MC memory F
To: BUG-ITS at MIT-AI
Cc: MOON at SCRC-TENEX

Could this be related to a power supply dying in that memory?
DEC fixed a power supply after (I think it was) Mem F dropped
dead yesterday.  Ty called me yesterday just as I was about to
go sleep, so I just told him to call DEC instead of looking at
it myself.
\1f
Date: 24 February 1982 17:51-EST
From: Edward Barton <EB at MIT-AI>
To: BUG-ITS at MIT-AI

Is this peculiar segment of CHANNA;LOGOUT TIMES normal, and
will it hurt anything?  It seems to have the effect of making
logout times for people beyond the discontinuity inaccessible
to :when.

RJA   01/17/82 01:33:18
RJD   02/24/82 09:21:18
RK    02/16/82 02:20:32
 02/19/82 14:16:10
RLB   01/11/82 23:38:59
RLL   02/20/82 20:24:08
\1f
MOON@MIT-MC 02/23/82 13:56:58 Re: Status of MC
To: (BUG ITS) at MIT-MC
CRASH;@ FEB22 indicates that bank 7 of mem F is acting up again.
I can't tell which half, but probably this indicates that it was
sheer coincidence that the right half of this bank started working
when DEC fixed it a while back.  If anyone wants to debug this, a
good start would be to swap bank 7 right with bank 6 right and bank
7 left with bank 5 left, then either get it to fail in a diagnostic
or put it back on-line and see what addresses fail.  The map of
physical locations of memory banks is inside the front door of mem A or B.
\1f
Date: 23 February 1982 00:00-EST
From: Daniel L. Weinreb <DLW5 at MIT-AI>
To: CSTACY at MIT-AI
cc: BUG-ITS at MIT-AI

Ed and I just noticed that you left ATSIGN DDT as an SBLK file instead of
as a PDUMP file; it was apparent because the system was so incredibly
slow.  We have fixed it; please be more careful.
\1f
CSTACY@MIT-MC 02/22/82 06:30:47
To: (BUG ITS) at MIT-MC
Installed ITS version 1268 as NITS1, old one is still NITS.
Seems to work. There are no memory patches here.

\1f
Date: 22 February 1982 05:06-EST
From: Christopher C. Stacy <CStacy at MIT-AI>
To: BUG-ITS at MIT-AI

AI is now running ITS 1268, which as dumped as NITS.  The current memory
patches are dumped. The former system version is now called ITS.

Chris
\1f
Date: Friday, 12 February 1982, 12:18-EST
From: David L. Andre <DLA at SCRC-TENEX>
Subject: nulls on ITS
To: MHS at MIT-MC, BUG-LISPM at SCRC-TENEX, BUG-ITS at MIT-AI
Cc: DLA at SCRC-TENEX

    From: MHS@MIT-MC
    Date: 02/11/82 18:53:27
            I tried to DOVER AI:LMWIND;WINDOC PRESS and the file turned out to be a bad
    press file.  Would whoever knows about such things be able to reformat it please? 
This is yet another manifestation of the fact that many if not most
files on 15 consist of nulls.  Is nobody ever going to fix this?
\1f
GZ@MIT-MC 02/05/82 01:09:24
To: (BUG ITS) at MIT-MC
It seems that :tctyp t1061 now turns off more processing, it didn't use to
(in fact today is the first time I noticed it)
\1f
ALAN@MIT-MC 01/31/82 23:35:04
To: (BUG ITS) at MIT-MC
> doesn't work when opening any of the core-link devices.
(who cares!)
\1f
Date: 28 January 1982 20:49-EST
From: Leigh L. Klotz <KLOTZ at MIT-AI>
To: ED at MIT-AI, BUG-ITS at MIT-AI
cc: GJC at MIT-AI

I think putting in the idle time and maybe the commode
bits is a good idea, but I think people use the core
allocation value, especially on MC, where they get unhappy
at the first hint of paging.  I don't know if they use
TTY^F rather than peek, though, so this may not be important.
Leigh.
\1f
Date: 28 January 1982 19:45-EST
From: Ed Schwalenberg <ED at MIT-AI>
Subject: TTY:.FILE. (DIR)
To: BUG-ITS at MIT-AI

How about flushing the totally useless CORE and TOTAL figures
in favor of idle time and perhaps comm mode bits?  This would
cut down greatly on the use of NAME to get the idle time, which
in turn would reduce thrashing due to hacking LSR1 greatly.
\1f
Date: 27 January 1982 12:35-EST
From: Stavros M. Macrakis <MACRAK at MIT-MC>
Subject:  ULSPBR
To: MOON at MIT-MC
cc: BUG-ITS at MIT-MC

Yes, I know it's unfinished; so presumably the variable can be flushed.

\1f
MOON@MIT-MC 01/27/82 04:07:08 Re:  ULSPBR
To: MACRAK at MIT-MC
CC: (BUG ITS) at MIT-MC
It's a feature that GLS never finished.
\1f
MACRAK@MIT-MC 01/26/82 23:42:06
To: (BUG ITS) at MIT-MC
Any special reason for user variable Ulspbr?  I don't think the
"Special Lisp instructions" are ever used... (are they even in the
microcode?) and anyway, .Uset lspbr is commented out.  All that ever
happens is that it's saved and restored.
\1f
Date: 26 January 1982 15:46-EST
From: Stavros M. Macrakis <MACRAK at MIT-MC>
Subject:  Disk delay
To: BUG-ITS at MIT-MC

I tried to print (in ddt) the file Macrak;Scalrp > several times and
it just wouldn't respond.  I then tried it in Teco, where it didn't
respond either, so I ^P'd and looked at the job's Flsins, which was (I
believe this is accurate) Skipe Qsnloc+40 <tab> TRN ; i.e. the
directory was locked.  After about 20 secs, the Teco won.

How could this happen?  I wasn't trying to write, so it presumably wasn't a
directory GC.  I did not try looking at other files, so I don't know if it
had to do with this particular file.

Anyway, a curious incident.  Thought you might like to know.

\1f
Date: 23 January 1982 14:26-EST
From: David Vinayak Wallace <GUMBY at MIT-AI>
To: BUG-ITS at MIT-AI

the file ai:.info.;its locks cantains nothing but nulls.
Perhaps other fies got destroyed in the crash?
\1f
Date: 22 January 1982 01:16-EST
From: Richard M. Stallman <RMS at MIT-AI>
To: BUG-ITS at MIT-AI

AI crashed with QFUD/1 but every QSNUD was nonzero.
\1f
DCP@MIT-MC 01/16/82 12:02:31
To: GREN at MIT-MC
CC: (BUG ITS) at MIT-MC

[See .INFO.;ITS UFD  and SYSTEM;FSDEFS for more info.]

The third word of the UFD is the sixbit of the name of the
directory.  Of the five words in the NAME area that describe the
file, the right half of the fifth word contains the UFD index of
the file author's HSNAME.  This is why the author of some files
is GUESTn or somesuch.  If there were more room in the five word
block, actual sixbit of the author's XUNAME could be stored
there, but...

\1f
GREN@MIT-MC 01/16/82 01:36:13
To: (BUG ITS) at MIT-MC
Just a question, not a bug:  In the UFD, is <author> just an index
into the MFD or something, and *not* 1 word of sixbit... I ask
since an author (sname) that doesn;t exist on one site prints
as -??- or something else equally uninformative...
\1f
MOON5@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.)
\1f
Date: 13 Jan 1982 1643-EST
From: SWG at MIT-DMS (S. W. Galley)
To: Mike at BRL
Cc: BUG-ITS at MIT-AI, Gurus at BRL
In-reply-to: Message of 18 Dec 81 at 0359 EST by mike@BRL
Subject: [Re: :HISTORY Lossage on DMS]
Message-id: <[MIT-DMS].219986>

The bug you reported was caused by an obsolete module -- now updated --
used by the HISTORY program, which translates a host name to its address
by mapping the host table into primary storage: this makes an MPV error
("memory protection violation") less surprising, but no less spectacular!

\1f
ED@MIT-AI 01/13/82 03:21:06 Re: Is one-proceed broken on MC?
To: DCP at MIT-MC
CC: (BUG ITS) at MIT-MC, (BUG DDT) at MIT-MC
There is a well-known long-standing bug in the hardware which will
never be fixed which causes a one-proceed which faults on instruction
fetch to execute the following instruction as well (which may be on a
different page and thus ...).  This is not it.  A much more dramatic
demonstration is simply that \ e and \1e are now abbreviations for \eP.
Emacs complains of PDL overflow when proceeded in this way, which explains
some bizarre behavior when I accidentally typed a \1e the other day.

\1f
DCP@MIT-MC 01/12/82 22:08:27 Re:  Is one-proceed broken on MC?
To: (BUG ITS) at MIT-MC, (BUG DDT) at MIT-MC

On MC running ITS 1249 (11/21/81), and DDT 1388 (always used to work)

:ddt
(no init)
                        :job j
                        100/jfcl
                        100<alt>0g
100>>JFCL               ^N
ILOPR;101>>0  0/  0   0/  0

Well, what can I say?  
It works on AI 1250, DDT 1388.
It works on ML 1256, DDT 1388.
It works on DM 1254, DDT 1388.

I'm pretty sure this was working as little as a week ago.  Has
somebody made a gross patch to the DDT on MC?  Or is our beloved
MC microcode sick?  Or is ITS not doing the right thing with the
microcode? 

\1f
GSB@MIT-ML 01/11/82 14:35:49 Re: ml dialups
To: RSG at MIT-ML, OAF at MIT-ML
CC: (BUG ITS) at MIT-ML
    RSG@MIT-ML 01/11/82 10:34:25
    I don't know exactly who to complain to about this, but it seems that 2 of
    ML's Vadic modems are broken.  (TTY 4 and TTY 32 I think are the numbers
    of the broken ones; TTY 1 and TTY 11 are OK.)

    TTY 4 answers busy when nobody is logged in on it.
    TTY 32 just doesn't answer at all.
----
TTY 4 answers now.  Presumably someone didn't hang up after logging
out or after a crash.  TTY 32's number isn't the same as it used to be
(actually, it now IS the same as it used to be), it has been back to being
6733 for some time.  It answers, although (as i reported some time ago)
when i last tried to use it (at least a week ago) i got lots of garbage.
p.s. ml dialups can be complained about to OAF with CC to me, or to me
and i forward.

\1f
RSG@MIT-ML 01/11/82 10:34:25
To: GSB at MIT-ML, (BUG ITS) at MIT-ML
CC: RSG at MIT-ML
I don't know exactly who to complain to about this, but it seems that 2 of
ML's Vadic modems are broken.  (TTY 4 and TTY 32 I think are the numbers
of the broken ones; TTY 1 and TTY 11 are OK.)

TTY 4 answers busy when nobody is logged in on it.
TTY 32 just doesn't answer at all.

Cheers  --  rsg

\1f
RMS@MIT-AI 01/11/82 01:03:27 Re: Purpg on CBLok Corblk
To: MACRAK at MIT-MC
CC: RWK at MIT-MC, (BUG ITS) at MIT-MC
I will do something reasonable about this situation.


\1f
Date: 10 January 1982 21:15-EST
From: Christopher C. Stacy <CSTACY at MIT-AI>
Subject: where is the DISK listing
To: BUG-ITS at MIT-AI


I frequently borrow the source listings, and if I have one it can
always be found in top of my desk in 926.
\1f
MACRAK@MIT-MC 01/10/82 21:13:51 Re: Purpg on CBLok Corblk
To: RWK at MIT-MC
CC: (BUG ITS) at MIT-MC
100/ setz
101/ $0'corblk$
102/ 1000,,%cblok
103/ 1000,,-1
104/ 400000,,110
110/ -1,,0
.call 100$x

Manages to make page 0 pure (!!??) and get a Purpg error.  All I asked for
was locking the pages in core (%cblok).  I seem to remember my original
example doing something weird with -2,,0 but not -1,,0, but the above will
do for now.

On the other hand, using %cblok+%cbndr+%cbndw works fine.  Perhaps there are
both documentation and code bugs?: some sort of specification of r/w status
is needed?

\1f
RMS@MIT-MC 01/10/82 16:33:46
To: (BUG ITS) at MIT-MC
I just fixed a but whereby TTYSET in a job which doesn't own the tty
can clobber the RH of TTYSTS when the job gets the tty.

\1f
Date: 10 January 1982 15:50-EST
From: Richard M. Stallman <RMS at MIT-AI>
To: BUG-ITS at MIT-AI

Does anyone know where the listing of DISK is?
\1f
Date: 10 January 1982 15:50-EST
From: Richard M. Stallman <RMS at MIT-AI>
To: BUG-ITS at MIT-AI

AI crashed at QCH3+3 because QFCHN was nonzero.  It was 1.
Looking thru the QUSR words, I found that there was indeed a free
channel, which the loop at QCH2 had not found.  Perhaps there is
something that can free a disk channel while QCHSW is locked?
If so, the error check has to be removed or done with interrupts
locked.
\1f
Date: 10 January 1982 13:26-EST
From: Stavros M. Macrakis <MACRAK at MIT-MC>
Subject:  PURPG in CORBLK call (incorrect analysis)
To: RWK at MIT-MC
cc: BUG-ITS at MIT-MC

But none of my pages were pure.
\1f
DCP@MIT-MC 01/10/82 00:43:17 Re:  CHAOS slots on MC
To: (BUG ITS) at MIT-MC
Should the number of CHAOS connections on MC be raised to 64, or
should I CONTINUE to have to gun down (LISP Machine) file servers
(usually about 10) every time the connection table gets
hopelessly full?
\1f
RWK@MIT-MC 01/08/82 08:09:54 Re: PURPG in CORBLK call
To: MACRAK at MIT-MC
CC: (BUG ITS) at MIT-MC
The error is right, it is getting a PURPG error attempting to write back
the updated AOBJN pointer you supplied.  You can't use a literal for an
updated argument!

\1f
MACRAK@MIT-MC 01/07/82 19:45:02
To: (BUG ITS) at MIT-MC
.call [setz?'corblk? %climm,,%cblok ? %climm,,-1 ? setz(%clin) [-2,,0] ]
(in a job with .memt/4000)  gives Purpg.  Now, the call may be wrong (because
of missing arg 5), but Purpg seems like the wrong error to give.  It also
isn't clear from the documentation that arg 5 is needed in this case,
since with arg 3 = [-1,,0], arg 5 is NOT needed.
\1f
Date: 4 January 1982 23:00-EST
From: David L. Andre <DLA at MIT-AI>
To: BUG-ITS at MIT-AI
cc: DLA at MIT-AI

When are the files on pack three going to have real contents again?  I'm
being screwed again and again when the file system thinks that the
contents are there, but I get all zeros.  I'd much rather get an error
"PACK NOT MOUNTED" than get bad data.
\1f
MACRAK@MIT-MC 01/04/82 20:09:31
To: (BUG ITS) at MIT-MC
Is .info.;its corblk needed given its .calls?
\1f
MARTY@MIT-MC 01/04/82 18:12:48
To: (BUG ITS) at MIT-MC

I was wondering if we get a DEC-20 and we use
ITS, if we could call it TWITS?


\1f
MOON@MIT-MC 01/04/82 14:30:02 Re:  AOSG not working with .HANG
To: MACRAK at MIT-MC
CC: (BUG ITS) at MIT-MC
This is fixed in the source; the sense of the skip condition
was backwards because the operands of the instruction were
interchanged.
\1f
MACRAK@MIT-MC 01/04/82 13:19:23
To: (BUG ITS) at MIT-MC
100/ aosg 200
101/ .hang
200/ -5
increments c(200) up to -1, then stops, never skipping!  What's
weirder is that 100/aose 200 only increments 200 once!  And this
is despite all sorts of ^X^P'ing and memory examination which,
one would think, would PClsr all over the place. 
\1f
MOON@MIT-MC 12/29/81 13:06:56 Re:  STY question
To: MACRAK at MIT-MC
CC: (BUG ITS) at MIT-MC
    MACRAK@MIT-MC 12/28/81 19:51:16
    To: (BUG ITS) at MIT-MC
    How do you check if the far end (user) of a STY is waiting for input?

:doc .call styget

It's documented to "probably not work very well".  I don't know whether
or not that is true.
\1f
MACRAK@MIT-MC 12/28/81 19:51:16
To: (BUG ITS) at MIT-MC
How do you check if the far end (user) of a STY is waiting for input?

\1f
JPG@MIT-MC 12/28/81 16:39:38
To: (BUG ITS) at MIT-MC
My apologies for my recent BUG-ITS notes.  I forgot I was logged in as 
JEFFG when I typed X^K, and the error message was not at all helpful 
in this regard.

\1f
JEFFG@MIT-MC 12/28/81 16:19:41 Re: continuation:
To: (BUG ITS) at MIT-MC
Oops: X^K now gives "CAN'T READ DISK FILE".

\1f
JEFFG@MIT-MC 12/28/81 16:18:52
To: (BUG ITS) at MIT-MC
Why does :XFILE JPG;JPG ^Q_X work, but not X^K ?  The latter has always 
done the trick in the past.

\1f
Date:      18 Dec 81 3:59:26-EST (Fri)
From:      Michael Muuss <mike@BRL>
To:        BUG-ITS at Mit-Ai
cc:        Gurus at BRL
Subject:   :HISTORY Lossage on DMS
Via:  BMD70; 18 Dec 81 4:01-EDT

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
*

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

\1f
GSB@MIT-ML 12/16/81 15:44:22
To: (BUG ITS) at MIT-ML
CADR, CADDR, and CADDDR should be synonyms for the SECOND, THIRD, and FOURTH
devices.  Perhaps also there should be an NTH device which is the "last"
one in the sequence, for not-quite-tape archival.

\1f
Date: 15 December 1981 19:21-EST
From: Earl A. Killian <EAK at MIT-MC>
To: DEVON at MIT-ML
cc: BUG-ITS at MIT-ML

    Date: 12/12/81 18:21:15
    From: DEVON at MIT-ML

                                Of course this penalizes a (hypothetical?)
    user with lines of 128 or longer in favor of a user with slow connection,
    but does anyone really want 128. characters on a line?

Yes.

    Date: 12/15/81 03:45:44
    From: DEVON

    What should happen if a multi-character sequence like %TVMV0 gets
    an argument byte valued 214?

It moves to that line/column of course.

                                  Is this to be taken as a %TDORS which
    has already flushed the real argument bytes further up the pipeline?

No.

    Or must every buffer know about such sequences and delay the action
    of a %TDORS until this situation won't arise,

Something like that.

                                                  or do argument bytes
    214 and 215 get quoted by %TDQOT?

No, that's not at all the function of %TDQOT.


\1f
DEVON@MIT-MC 12/15/81 03:45:44 Re: SUPDUP
To: (BUG ITS) at MIT-MC
What should happen if a multi-character sequence like %TVMV0 gets
an argument byte valued 214?  Is this to be taken as a %TDORS which
has already flushed the real argument bytes further up the pipeline?
Or must every buffer know about such sequences and delay the action
of a %TDORS until this situation won't arise, or do argument bytes
214 and 215 get quoted by %TDQOT?
\1f
DEVON@MIT-ML 12/12/81 18:21:15
To: (BUG ITS) at MIT-ML
Another Output-Reset related gripe:

when output characters reach the level where flow control happens,
they are no longer flushable.  This means that during a long listing
I can type ^S (knowing that DDT will eventually shut up ten-twenty
lines later) and before output stops I can use the intelligent
terminal protocol to stop and start output several times, bacause
response speed to flow control is an order of magnitude better
than the response to ^S.

If multi-character %td sequences were forbidden argument bytes >177 then
%tdors would behave more like a genuine out-of-band signal, and maybe
that would make it permissible to flush a buffer without knowing about
multi-character sequences.  Of course this penalizes a (hypothetical?)
user with lines of 128 or longer in favor of a user with slow connection,
but does anyone really want 128. characters on a line?
\1f
MOON@MIT-MC 12/11/81 14:59:30 Re:  When does ITS send %TDMOV ?
To: DEVON at MIT-MC
CC: (BUG ITS) at MIT-MC
When %TOMVU isn't set, thus the terminal needs to know where it's
coming from as well as where it's going to.  This would be the case
on printing terminals.  User-mode programs such as Emacs and Macsyma
may send it in other circurmstances as well.
\1f
DEVON@MIT-MC 12/11/81 02:33:38
To: (BUG ITS) at MIT-MC
when does ITS use %tdmov instead of %tdmv0?

I never recieved (or bothered to implement) %tdmov on my terminal until
just now, while testing a gross kludge that changes my tctyp to printing
momentarily, upon changing it back
I got all %tdmov's for a while.

I'd like to know how to induce ITS to revert to the shorter %tdmv0.
\1f
Date: 6 December 1981 01:31-EST
From: Christopher C. Stacy <CStacy at MIT-AI>
To: ALAN at MIT-MC
cc: CHRIS at MIT-MC, BUG-ITS at MIT-MC, BUG-DDT at MIT-MC,
    DCP at MIT-MC

    ALAN@MIT-MC 12/05/81 16:22:32
    Am I to understand that this means that version 1388 of DDT has ... Pissed off,Alan

No.


\1f
ALAN@MIT-MC 12/05/81 16:42:00
To: (BUG ITS) at MIT-MC
CC: (BUG DDT) at MIT-MC
I reinstalled the old version of ddt
\1f
ALAN@MIT-MC 12/05/81 16:22:32
To: CHRIS at MIT-MC, (BUG ITS) at MIT-MC, (BUG DDT) at MIT-MC
To: DCP at MIT-MC
    DCP@MIT-MC 12/05/81 14:06:07
    To: CHRIS at MIT-AI
    CC: (BUG ITS) at MIT-MC
        CHRIS@MIT-AI 12/05/81 10:33:43

        I reassembled and installed DDT 1388 on MC so that it will use
        the correct new hsname scheme.

        Chris

    Please do not make modifications to existing installed code
    without upping the version number.  Some people's ready messages
    are assembled code and expect certain entrypoints within DDT.
    The loader checks to see if the version has changed, and if so
    does not load the ready message.  

Am I to understand that this means that version 1388 of DDT has a
different mapping from symbols to locations depending on what MACHINE
it is running on?  That is TOTALLY unacceptable and completely
brain-damaged.  What good is a goddamned VERSION NUMBER anyway if you
don't CHANGE it when you change the VERSION!!!
                                Pissed off,
                                        Alan

\1f
Date:  5-DEC-1981 16:02:44.12
From:  Robert W. Kerns <KERNS at MIT-ALCATOR>
Reply-to: RWK at MIT-MC
Subject: DDT Pseudo-1138
To: CHRIS at MIT-MC
Cc: BUG-ITS at MIT-MC

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.

\1f
DCP@MIT-MC 12/05/81 14:06:07
To: CHRIS at MIT-AI
CC: (BUG ITS) at MIT-MC
    CHRIS@MIT-AI 12/05/81 10:33:43

    I reassembled and installed DDT 1388 on MC so that it will use
    the correct new hsname scheme.

    Chris

Please do not make modifications to existing installed code
without upping the version number.  Some people's ready messages
are assembled code and expect certain entrypoints within DDT.
The loader checks to see if the version has changed, and if so
does not load the ready message.  

\1f
CHRIS@MIT-AI 12/05/81 10:33:43
To: (BUG its) at MIT-MC
CC: CSTACY at MIT-AI

I reassembled and installed DDT 1388 on MC so that it will use
the correct new hsname scheme.

Chris


\1f
MOON@MIT-MC 12/02/81 15:20:04 Re: System console
To: CBF at MIT-MC
CC: (BUG ITS) at MIT-MC
I don't think it's easy to make different consoles have different
size buffers.  What information is it that you want to see?
\1f
ELLEN@MIT-MC 12/01/81 16:43:39
To: (BUG ITS) at MIT-MC
On MC, when a new user logs in INQUIR no longer queries him to
fill it out.

\1f
ELLEN@MIT-MC 12/01/81 17:03:45 Re: Previous message about INQUIR
To: (BUG ITS) at MIT-MC
Sorry, never mind, I just realized that someone had deleted the
* LOGIN file on the GUEST0; directory on MC, which is what was
calling INQUIR.

\1f
Date: 1 Dec 1981 1504-EST
From: SWG at MIT-DMS (S. W. Galley)
To: gsb at MIT-DMS
Cc: BUG-its at MIT-DMS
In-reply-to: <[MIT-DMS].216669>
Subject: [Re: BUG => its\efgsb\esdm's]
Message-id: <[MIT-DMS].216742>

I set DM's T00 width to 80. in TTYTYP 238.

\1f
CBF@MIT-MC 11/28/81 19:44:21 Re: System console
To: (BUG ITS) at MIT-MC
With the rate of activity on MC nowadays (actually for a couple of years)
now, I've noticed that spying on the system console (or using :SYSMSG) has
less and less often given me the information I was looking for.
Frequently all one can see is the last 20 seconds of activity.  Anyway,
this is a suggestion that the system console's buffer be made substantially
larger.  If things work the way I guess they do, the only substantial
disadvantage I can think of this having is that output resets on that
terminal when it is being used an an ordinary terminal will take a long
time.

\1f
Date: 22 November 1981 04:00-EST
From: Chris Stacy <CHRIS at MIT-AI>
Subject: last message
To: BUG-ITS at MIT-AI

Foo. I just found out what UNAME is.
\1f
Date: 22 November 1981 03:56-EST
From: Chris Stacy <CHRIS at MIT-AI>
To: BUG-ITS at MIT-AI


ITS crashed in ZUSER2. The UNAME was SYS (USER=0).
Examined some stuff on the TTY and reloaded ITS.
\1f
GSB@MIT-ML 11/20/81 17:26:30
To: (BUG ITS) at MIT-ML
    cstacy@MIT-ML (Sent by ___031@MIT-ML) 11/20/81 11:45:53
    :TIME says ML ITS has run for over 287 days, but
    I know that it was reloaded a few minutes ago.
the second value returned by RQDATE sez the system was brought up in
1983 (or should i interpret that as 1883?).  The time program claims
in the source to not handle uptimes greater than a year, so that
explains why it says 287 days rather than 98 years.

\1f
MOON@MIT-MC 11/19/81 14:58:07 Re:  :REATTA broken
To: DCP at MIT-MC
CC: (BUG ITS) at MIT-MC
I changed the ATTACH system call to call ATTYCI rather than ATTYC2.
A new system ought to get installed on MC soon.

RMS, is this the correct fix?
\1f
DCP@MIT-MC 11/18/81 11:03:38
To: (BUG ITS) at MIT-MC
Has the REATTA symbolic system call been changed (since may or
so)?  Has anybody else not been able to use the :REATTA program?
:REATTA hasn't changed since December 1978, yet I have not been
able to sucessfully use this program for a month (at least).

Specifics: (from a space cadet keyboard over the chaos net)

<CALL>
dcp\e0u
:detach
<CALL>
dcp\e0u
--Attach your detached tree--<RUBOUT>
:reatta dcp/k
        ;;; at this point, nothing happens, but if I hit <CALL>
<CALL>
        ;;; I get another PWORD, so I got detached again!!
dcp\e0u
--You have several detached trees--
--Attach a detached tree--<SPACE>
ERROR: ATTACH: BAD CHANNEL NUMBER
375>>.CALL 1046 (ATTACH)
        ;;; This is :REATTA bombing
:calprt
Arg 1:  3               ;;; JOB channel
Arg 2:  400042          ;;; TTY to attach it to
Control bits: 400000

:ichan 3
USR: DCP HACTRO (uai\10)
                        ;;; looks valid to me.
:vv
DCP    HACTRO     2  DCP;   Det +15:11          ;;; the disowned tree
DCP    HACTRN   ...  DCP;
  ...


I did a little poking:
I can understand why (SYSTEM;ITS)NATTAC calls
(SYSTEM;TS3TTY)ATTYC2 to decode the tty number, but why does
ATTYC2 JRST to ATTYC7 instead of to ATTYC8.  ATTYC7 does not
allow 400000+ttynum but ATTYC8 does (that is the only difference
between the routines).

\1f
DCP@MIT-MC 11/12/81 12:46:39
To: JPG at MIT-MC
CC: (BUG ITS) at MIT-MC, ASB at MIT-MC, GJC at MIT-MC
I did a little poking around and found the following:

There is a mojor difference between TS3TTY 301 and TS#TTY 305.
The majority of the difference seems to be in the ATTY** routines
(the ones that determine if you have the TTY and whether you
should wait for it). 

I tried the the following:
        a^K
        factor(ratsimp((x+y)^12));
        ^Z ^P
now I typed RETURN several times (say 20). After the 10th I got
the message  JOB A WANTS THE TTY.  Macsyma wanted to SIOT.  I
looked at the siot string and it contained %TDMV1 codes among
other things.  When you <alt>P the macsyma you will see that the
cursor goes to just above the JOB A WANTS THE TTY message, NOT
where you left off and NOT where you happened to be.

The culprit:
        RCPOS (Read cursor pos).  In the rearrangement of the
ATTY** routines it appears RCPOS has been changed to allow you to
read the cursor even when you don't have the tty (it used to wait
for the TTY).  Unfortunately, MACSYMA uses this information to
compute %TD codes.

\1f
JPG@MIT-MC 11/12/81 04:41:53
To: (BUG ITS) at MIT-MC
CC: JPG at MIT-MC, ASB at MIT-MC, GJC at MIT-MC
On about 10/29/81 I noticed that MACSYMA was misbehaving when it was 
$Ped after having been ^Zed and ^Ped.  Namely the cursorpos calculation 
was off and it displayed the next expression one or two rows too high.
Just now I showed it to RWK, and as we suspected it was an ITS (TS3TTY) 
problem, we transferred the MACSYMA over to ML which is running an older
ITS (#1230 as opposed to #1244) and tried the same experiment there where 
it ran fine.  The difference was that you get the interrupt for 
"Job wants the TTY" at an earlier point on ML than on MC, namely at 
CRSRP1+4>>.CALL RCPOS (which presumably does the necessary cursorpos 
recalculation) rather than at IFORCE+11>>.CALL SIOT  .  If it is 
relevant, I am on a VT52.  Also, the thing I ask MACSYMA to do is 
FACTOR(RATSIMP((X+Y)^20));  which just uses up some time, so while 
it is computing, I ^Z ^P , and $P when it says "Job wants the TTY".
(Sorry I am so verbose, but I wanted to make sure I included whatever 
info may be necessary.)

\1f
GJC@MIT-MC 11/09/81 11:39:10
To: (BUG ITS) at MIT-MC
Right now there are about 20 NETRFC jobs from MIT-XX, all in the FINISH
state and not doing anything else, but taking up net ports.
I've gunned them down.

\1f
DCP@MIT-MC 11/07/81 20:08:50 Re:  SCML system call
To: (BUG ITS) at MIT-MC, RK at MIT-MC
Why does SCML cause an error when it tries to set the echo area
and it does not have the TTY?  :CALL SCML does not say there are
any errors for this system call.  In fact, the routine ASCML in
SYSTEM;TS3TTY puts the echo area in a magic field with
        DPB B,[$TBECL,,TTYTBL(U)]
Which I guess will get put in the right place when
the job gets .DTTY'd.  But after the DBP it does a POPJ P,
causing an error instead of
        AOS (P)
        POPJ P,
which would appear to be the right thing.

\1f
Date: 6 November 1981 11:47-EST
From: Richard C. Waters <DICK at MIT-AI>
To: BUG-ITS at MIT-AI

dump is broken in a weird way.  if you try to list the files on a tape
on dsk it gives you the error message that the file dsk:wall 1
doesn't exist, and just won't do anything.  

                Dick
\1f
MOON@MIT-MC 10/28/81 19:23:06 Re: Installing TX XTEX
To: DCB at MIT-MC
CC: (BUG INSTALL) at MIT-MC, (BUG ITS) at MIT-MC
This program doesn't work with files longer than 128K words (due to
overflow problems in a halfword).  It should be rewritten, for this
and numerous other reasons.  Volunteers?
\1f
Date: 27 Oct 1981 1518-EST
From: SWG at MIT-DMS (S. W. Galley)
To: MOON at MIT-MC
Cc: (BUG ITS) at MIT-DMS
In-reply-to: Message of 21 Oct 81 at 1502 EDT by MOON@MIT-MC
Subject: [Re: catatonia - ACs/ JRST 4,]
Message-id: <[MIT-DMS].213675>

The PI lights at the time indicated normal states, I believe:
        PI IN PROGRESS [none]
        PI REQUEST [none]
        PI ACTIVE 1-7
        IOB PI REQUEST 2,3,7
Curiously, the parity buffer didn't match the instruction register:
        INSN+MA/  344000,,17 [AOJA 17]
        PAR BUFF/ 354000,,17 [AOSA 17], ODD, STOP
I suppose your theory about some glitch turning off the PI system
is a good one.

\1f
RLB@MIT-MC 10/27/81 02:17:45
To: (BUG ITS) at MIT-MC
MC's T300 lossages of 7pm this evening noted in system log
occurred while I had an Emacs writing lots of blocks to FOURTH:,
like 10000\1a :ew...\e 100<hp>

\1f
Moon@MIT-MC 10/26/81 01:16:09 Re: System crashing works differently
To: (BUG ITS) at MIT-MC
ITS 1243, which has been installed on MC for a week or so now, does its
crashing differently.  Most halts (JRST 4,.) have been replaced with
the new BUG macro, which types a message and goes to DDT.  Documentation
on this macro may be found in the source, where it is defined, near the
front of ITS >.  The BUG macro also replaces the SYSMSG facility.

When this system is installed on other machines, it would be a good idea
to install a new non-timesharing DDT along with it.  Assemble MC:SYSTEM;DDT.
The only change is to enable the feature of typing <alt>P to revive the
system from a non-fatal error to work.  Also install MC:SYS:TS SYSMSG when
and where the new system is installed.
\1f
Date: 25 Oct 1981 2228-EST
From: CSTACY at MIT-DMS (Christopher C. Stacy)
To: BUG-its at MIT-DMS
Subject: BUG => its
Message-id: <[MIT-DMS].213553>


The DOVER program on DM thinks there is a chaosnet here
and tried to use undefined system calls when it cannot
spool to MC. It should just bomb out.


\1f
Date: 23 October 1981 21:57-EDT
From: David A. Moon <MOON at MIT-MC>
Subject: ITS IMP lossage
To: JNC at MIT-XX
cc: BUG-its at MIT-AI, jan at MIT-XX

    Date: 23 Oct 1981 1026-EDT
    From: J. Noel Chiappa <JNC at MIT-XX>
    Subject: ITS IMP lossage
    To: jan at MIT-XX, bug-its at MIT-AI
    cc: JNC at MIT-XX

            When an IMP goes down and is reloaded, ITS does not
    do the right thing in terms of bringing the net back up.
    It's necessary to go do a LOCK/N by hand to bring it up.
This is not actually true.  The time when ITS does not bring it back
up is when it goes down several times in rapid succession (within
30 seconds I think), after which it decides that it must be broken
and leaves it down.
\1f
MOON@MIT-MC 10/21/81 15:02:29 Re: catatonia - ACs/ JRST 4,
To: SWG at MIT-DMS
CC: (BUG ITS) at MIT-DMS
    Date: 21 Oct 1981 1105-EDT
    From: SWG at MIT-DMS (S. W. Galley)
    To: BUG-ITS at MIT-DMS
    Subject: catatonia - ACs/ JRST 4,
    Message-id: <[MIT-DMS].213236>

    Yesterday DM entered a catatonic state: in user mode, only the null job
    running, no response to ^Z or the left-most data switch.
    I stopped it with the STOP key and dumped it to DM:.;CRASH 6089.
    The ACs were clobbered: 0/ JRST 4,325  1-16/ JRST 4,  17=U/ AOJA U.
    XUUOH/ 700000,,STYO+1.  Truly strange!

Those are the correct ACs for the null job.  Everything in the crash dump
looks completely normal.  You didn't say what the PI lights indicated;
perhaps a power surge or static electricity turned off the PI system or
stopped the machine or otherwise made it not take interrupts.


\1f
Date: 23 Oct 1981 1026-EDT
From: J. Noel Chiappa <JNC at MIT-XX>
Subject: ITS IMP lossage
To: jan at MIT-XX, bug-its at MIT-AI
cc: JNC at MIT-XX

        When an IMP goes down and is reloaded, ITS does not
do the right thing in terms of bringing the net back up.
It's necessary to go do a LOCK/N by hand to bring it up.
I'm too burned out to grovel over the code and figure out
what it does do and should do; perhaps someone would like
to tackle this?
-------
\1f
Date: 21 Oct 1981 1105-EDT
From: SWG at MIT-DMS (S. W. Galley)
To: BUG-ITS at MIT-DMS
Subject: catatonia - ACs/ JRST 4,
Message-id: <[MIT-DMS].213236>

Yesterday DM entered a catatonic state: in user mode, only the null job
running, no response to ^Z or the left-most data switch.
I stopped it with the STOP key and dumped it to DM:.;CRASH 6089.
The ACs were clobbered: 0/ JRST 4,325  1-16/ JRST 4,  17=U/ AOJA U.
XUUOH/ 700000,,STYO+1.  Truly strange!

\1f
Date: 14 October 1981 14:31-EDT
From: Mike McMahon <MMCM at MIT-AI>
To: BUG-ITS at MIT-AI

SYSTEM;FSDEFS 36 is broken.  UDBLKS is multiply defined.
\1f
Date: 12 October 1981 20:49-EDT
From: Christopher C. Stacy <CSTACY at MIT-AI>
Subject:  Jobs magically appearing (Robert P. Krajewski <UC.RPK at MIT-EECS>)
To: BUG-ITS at MIT-MC, BUG-PWORD at MIT-MC

I responded to this person.


\1f
Date: 12 Oct 1981 1554-EDT
From: Robert P. Krajewski <UC.RPK at MIT-EECS>
Subject: Jobs magically appearing
To: BUG-ITS at MIT-MC
cc: BUG-PWORD at MIT-MC

When I came over to AI via the CHAOSnet (from MIT-EECS), I decided to list my
jobs BEFORE logging in (for no apparent reason).  This is what I got:

$$v
* CONIVR P 63
  EMACS P 24
  MAIL P 25
  LISP R 5
  FOO - 17
  MACSYM R 34
  PLANER R 45
  DIRECT P 57
  UNIVERSE-SIMULATION W 107
*:version
AI ITS.1223. PWORD.2449.
TTY 42
16. Lusers, Fair Share = 29%

*:time
The time is 15:45:36 EDT.
Today is Monday, the 12th of October, 1981.
AI ITS 1223 has run for 1 day, 15 hours, 45 minutes, 28 seconds.
:KILL
*$$u

AI ITS 1223  Console 42 Free. 15:45:46


The only thing I did before logging in was a finger.  How can this be ?
I noticed that AI PWORD's appearance had changed a little.

bob
-------

\1f
KLOTZ@MIT-MC 10/07/81 06:24:16 Re: --More--
To: (BUG ITS) at MIT-MC
In the past couple of weeks, I've noticed that --more-- breaks have done some
unusual things.  I don't remembere then doing this before, but I'm not sure.

Just now, a proceeded job tried to print out something, while my hactrn was in
the middle of printing a page (of mail, read with \e\ 1).  When the --more--
appeared, it acted as if it got a space immediately and went to the next page.

This was just now on a Vt52 on mc.  Last week, I was using a dissapoint over a
dialup, and every CLI interrupt would cause --more-- to flush.  This may be the
disappoint being random, but it didn't happen any other time.

\13 seems to have a problem with --more--, too.  A couple of times I've typed \13
while in the middle of a page and gotten "--more--\13flushed
" printed out.  This was on a dialup.

Leigh.

\1f
RLB@MIT-MC 10/07/81 00:52:01
To: (BUG ITS) at MIT-MC
I see I dumped the earlier MC crash to .;CORPG0 4
Handwriting in the log doesn't make it to BUG-ITS, does it?

\1f
Date:  6 October 1981 1808-EDT (Tuesday)
From: Guy.Steele at CMU-10A
To: glr at MIT-AI
Subject:  Re: > name conventions
CC: bug-its at MIT-AI
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
\1f
Date: 6 October 1981 17:52-EDT
From: Ken Harrenstien <KLH at MIT-AI>
Subject: > name conventions
To: GLR at MIT-AI
cc: BUG-ITS at MIT-AI

That actually sounds like a good idea.  I don't know if anyone is
still keeping a list of ITS things-to-do, though.
\1f
Date: 6 October 1981 12:04-EDT
From: Jerry Roylance <GLR at MIT-AI>
Subject: > name conventions
To: BUG-ITS at MIT-AI


The naming conventions for an FN1 or FN2 of > could be changed
to allow file extentions and version numbers.

Say my directory has these files:

        DSK:FOO; BAR FASL
        DSK:FOO; BAR LSP123
        DSK:FOO; BAR LSP124
        DSK:FOO; BAR PRESS
        DSK:FOO; BAR TXT256
        DSK:FOO; BAR TXT257
        DSK:FOO; BAR UNFASL

Then file lookup (for read) should work as:

   BAR >       refers to BAR TXT257 (normal)
   BAR TXT>    refers to BAR TXT275
   BAR LSP>    refers to BAR LSP257


                        Jerry
\1f
Date: 4 October 1981 03:10-EDT
From: Christopher C. Stacy <CStacy at MIT-AI>
Subject: Ten/11 Interface seems to be flakey (so, what else is new?)
To: BUG-ITS at MIT-AI
cc: CSTACY at MIT-AI

About midnight, AI stopped with a parity error. When CONTinued,it
would halt again. During this time, the door buzzer was stuck on. 

Cycling the PDP-11 got the door to stop being noisy.
However, I could not get the TVs work on ITS again.

While I was scratching my head, ITS crashed at CHACK1+14.
This is in some CORE code, and the error had something
to do with a pointer to a non-existant luser.

About now, I decided things were probably screwed up enough to
want to reload and try again.  Reloaded. 
When I ran SALVAGER, it found directories out of phase.   
I copied the most recent version to the other packs. This
worked and ITS came back up.

Later, when no one was logged in, I tried to make the system lose
by buzzing the door from a LISPM. ITS halted.

The job which got the parity error was a chaos DOOR server. It was
halted at FROBIT+1, a .SLEEP which comes immediately after an
access to the TEN11 interface.

Since the TEN/11 interface seems pretty broken, I deleted the DOOR
server from the DEVICE directory and put up a system message.

Cheers,
Chris
\1f
RSG@MIT-ML 09/30/81 11:58:24
To: (BUG ITS) at MIT-ML
CC: RSG at MIT-ML
I tried to copy a file from ML to MC.  What got created on the MC directory
is a locked file (multiple copies with the same name and a * in leftmost
column of the directory listing).  The file in question is MC: EF; RSG LISPIN .

... rsg

\1f
Date: 28 September 1981 15:26-EDT
From: David Chapman <Zvona at MIT-AI>
To: BUG-ITS at MIT-AI

I did a pdset on ai since the system seemed to think it was 11/11/81.
Probably some files will have this creation data so maybe users should
be warned in system msg.
\1f
Date: 27 September 1981 17:27-EDT
From: Earl A. Killian <EAK at MIT-MC>
Subject:  [DCP: forwarded]
To: BUG-ITS at MIT-MC

Date: 25 September 1981 23:52-EDT
From: David C. Plummer <DCP>
To:   BUG-CRTSTY

I think this is your fault:

I am on a HEATH19 running under a CRTSTY. It looks like I got the
TTYSMT variable of the last person to use this sty. It would be a
good idea for CRTSTY to set that value to zero (or whatever is
the right thing for the various terminal types) before shoving
the ^Z down it. You should probably do this even if you think it
is ITS's responsibility to set it to zero when the sty gets
opened for the first time.

\1f
Date: 27 September 1981 04:32-EDT
From: Richard M. Stallman <RMS at MIT-AI>
To: BUG-ITS at MIT-AI

My XX job became hung permanently in CHAOSO because its CHSNOS was 0.
The net appeared to be working; I was able to make new connections
to XX and MC.  The connection state was still OPEN, according to PEEK.
The "flag" was 20003.  Ibf, Pbf and Ack were 0; both window sizes were 5.

At the time the problem began, the fair share moved up to 120% and stayed
there for several updates of the who line.  Then it came back to a
legitimate value.

The problem was worse because this happened with SUPDUP at interrupt level
and it would not recognize Break.

Can Moon say what other info to look for if this happens again?
\1f
Date: 22 September 1981 21:51-EDT
From: Ian G. Macky <GREN at MIT-MC>
Subject:  [RLB: jobdev / ITS bug, I guess]
To: BUG-ITS at MIT-MC

Ancient mail from my jobdev munging days, never had any more problems
once I got my act together... probably should have just thrown this away,
but dunno, maybe someone loves bug mail.
-----
Date: 06/17/81 01:11:15
From: RLB
Re:   jobdev / ITS bug, I guess

As best as I can determine, the system crashed doing a JOBRET for your JOB.07
returning whatever to your job FOO. At the point of the crash, the system
is hacking FOO on behalf of JOB.07, and hence requires that FOO be (internally)
stopped.  But FOO was not stopped, which is ostensibly an impossible condition,
do it halted.  I randomly tried continuing at the location after the check,
guessing that only FOO or JOB.07 would be screwed, but I didn't understand
the clock interrupt level logic the system was up to, so it couldn't continue.
I suggest that you try to recover as best you can the circumstances of what
you were doing and the state of the code, and ship it off along with your
munging of this note to BUG-ITS.

\1f
DEFBOB@MIT-MC 09/17/81 20:45:12
To: (BUG SYSTEM) at MIT-MC
I don't know where to send this message so I'll send it here.
    
If a user detaches his tree at 4:00 p.m. with the intention of attaching it a few hours
later, say 8:00, is the tree nevertheless destroyed (?chopped down?) automatically by 
someone between those particular hours or between any other particular hours?

\1f
DEFBOB@MIT-MC 09/17/81 20:40:48
To: (BUG SYSTEM) at MIT-MC

\1f
DCP@MIT-MC 09/15/81 08:53:42 Re: CNSGET symbolic system call extension
To: (BUG ITS) at MIT-MC
CC: CWH at MIT-MC
Now that there are a few places that use SUPDUP Graphics, might
it be the right thing to include the SMARTS (or TTYSMT) variable
in the CNSGET and CNSSET symbolic system calls. It is much easier
to do
        (syscall 7 'cnsget tyo)
and get all the necessary info than to do
        (syscall 1 'ttyvar tyo (car (pnget 'TTYSMT 6)))
to recover the SMARTS variable.

\1f
GJC@MIT-MC 09/13/81 14:33:48
To: (BUG ITS) at MIT-MC
For something really impressive, try :XFILE out of an archive!
Incredibly SLOW, even on MC with fair-share=50%
Almost as impressive is running LMODEM out of an archive.

\1f
Date: 10 September 1981 1402-EDT (Thursday)
From: Guy.Steele at CMU-10A
To: bug-its at MIT-AI, gosper at PARC-MAXC
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

\1f
Date: 8 September 1981 14:54-EDT
From: Jeremy Barkan <BARKAN at MIT-AI>
To: BUG-ITS at MIT-AI
cc: GOLDFARB at MIT-XX


When using :dover, the its can't differeniate between the underscore
in file name and underscore that is the antecedent in the font name
specifier. Does it not quote underscore
\1f
rms@MIT-MC (Sent by ___114@MIT-MC) 08/28/81 04:25:11
To: (BUG ITS) at MIT-MC
MC was hung withMEMFRZ locked bythecore job
which was waiting for the 200000,, bit in an IMSOC6 word to clear.
It was hung for manyminutes.

\1f
KLOTZ@MIT-MC 08/27/81 17:04:27
To: (BUG ITS) at MIT-MC
DISTRIB:  *TS
EXPIRES: 08/31/81 17:01:55
KLOTZ@MIT-MC 08/27/81 17:01:55 Re: AI is down.
The repairman fixed unit 7, but determined that unit 0 was
broken.  ITS cannot be brought up without that unit, so AI
will remain down either until tomorrow when they come back to
fix it, or until someone knowledgegable enough about the
hardware comes around to swap cables.
^_

CSTACY was around when they came to fix the disks.  He said
he fixed 7, so they decided tobring third: back up.  Disk 0
crapped out when they were bringing it up.  All lights on the
disk went out.

He supposedly mumbled something about coming back tomorrow
to replace the "carriage."

Yuk.

\1f
Date: 27 August 1981 17:56-EDT
From: Leigh L. Klotz <KLOTZ at MIT-AI>
To: BUG-ITS at MIT-AI

I called symbolics and found Tom Knight, who came and switched
the cables so that unit 7 is now unit 0.
Leigh.
\1f
Date: 25 August 1981 04:06-EDT
From: David A. Moon <MOON5 at MIT-AI>
To: TK at MIT-AI, BUG-HARDWARE at MIT-AI, BUG-ITS at MIT-AI

The xgp-11 blows its circuit breaker
and makes smoke smell (not visible smoke).  Probably someone should fix it.
\1f
Date: 24 August 1981 19:40-EDT
From: Charles Frankston <CBF at MIT-MC>
Subject: Re: MC
To: JNC at MIT-XX
cc: BUG-its at MIT-AI, BUG-mail at MIT-AI

    Date: 24 Aug 1981 1123-EDT
    From: J. Noel Chiappa <JNC at MIT-XX>
    In-Reply-To: Your message of 23-Aug-81 2242-EDT

        We don't even have a loopback plug for a local interface, so
    it must have been the BBN repairman. Please make sure who's at fault
    before randomly flaming! If you can give me some more info, I will go
    barf at the NCC; they seem to still have not learned that leaving
    loopback plugs on enabled ports is an absolute no-no.
    -------

I didn't send the message to flame.  I was hoping someone would read it
and take appropriate action.  Perhaps the NCC merely had things logically
looped back (can they do that?).  In any event 3/54 (octal) was looped
back for at least an hour prior to my sending the message; probably
several hours in total.  Plenty of time for every host on the net to
unqueue their mail to themselves, rather than to MC.

\1f
Date: 24 Aug 1981 1123-EDT
From: J. Noel Chiappa <JNC at MIT-XX>
Subject: Re: MC
To: CBF at SU-AI, bug-its at MIT-AI, bug-mail at MIT-AI
cc: JNC at MIT-XX
In-Reply-To: Your message of 23-Aug-81 2242-EDT

        We don't even have a loopback plug for a local interface, so
it must have been the BBN repairman. Please make sure who's at fault
before randomly flaming! If you can give me some more info, I will go
barf at the NCC; they seem to still have not learned that leaving
loopback plugs on enabled ports is an absolute no-no.
-------
\1f
Date: 23 August 1981 17:09-EDT
From: J. Noel Chiappa <JNC at MIT-MC>
Subject: IMP cretinosity
To: BUG-ITS at MIT-MC, BUG-TWENEX at MIT-MC
cc: JNC at MIT-MC

        I'd have liked to send this to BUG-ARPANET, but the people
who should get this aren't on that list. Please add yourself if this
sort of stuff concerns you.

        The C/30 got in this bizarro state this afternoon where it was
looping trying to read in its micro-code from the micro-tape. I fixed
it by removing the tape, powering the machine down, reinserting the
tape, powering the machine back on and hitting the master reset button.
        This had the disadvantage that when it is powered off, all the
hosts are turned off in the software, and it needs manual intervention
by the NCC (which the guy on duty forgot to do) to turn them back on. The
error message reported by any attempt to use the net was "Random network
lossage", which sounds like the IMP lost all connection to the outside
world, except that I verified (by looking at the lights) that its
connections were in fact up. So if this happens again....

\1f
Date: 23 Aug 1981 1653-EDT
From: J. Noel Chiappa <JNC at MIT-XX>
To: KLOTZ at MIT-MC, (BUG ITS) at MIT-MC
cc: JNC at MIT-XX
In-Reply-To: Your message of 23-Aug-81 1636-EDT

        It was the IMP.
-------

\1f
Date: 23 Aug 1981 1636-EDT
From: J. Noel Chiappa <JNC at MIT-XX>
To: KLOTZ at MIT-MC, (BUG ITS) at MIT-MC
cc: JNC at MIT-XX
In-Reply-To: Your message of 23-Aug-81 1457-EDT

        Perhaps the IMP was dead? It does die occasionally, you know.
-------

\1f
Date: 23 Aug 1981 1942-PDT
From: Charles Frankston <CBF at SU-AI>
Subject: MC
To:   bug-its at MIT-AI, bug-mail at MIT-AI

Someone has left a loopback plug on the IMP port MC should be plugged into (ie,
port 3 on IMP 54 octal).  This not only results in human confusion but causes
all sorts of problems with mail delivery (including mail loops etc.).  Would
someone please go remove the plug!


\1f
Date: 23 Aug 1981 1942-PDT
From: Charles Frankston <CBF at SU-AI>
Subject: MC
To:   bug-its at MIT-AI, bug-mail at MIT-AI

Someone has left a loopback plug on the IMP port MC should be plugged into (ie,
port 3 on IMP 54 octal).  This not only results in human confusion but causes
all sorts of problems with mail delivery (including mail loops etc.).  Would
someone please go remove the plug!


\1f
Date: 23 August 1981 18:00-EDT
From: J. Noel Chiappa <JNC at MIT-AI>
Subject: IMP dead
To: BUG-ITS at MIT-AI, ELLEN at MIT-AI, JAN at MIT-AI, JPG at MIT-AI,
    BUG-twenex at MIT-MC
cc: JNC at MIT-AI

        The IMP that MC and XX are on is dead. BBN is sending
a repairman, but the guy they are sending is a known turkey.
We'll see. (BTW, this message too I would have liked to send
to BUG-ARPANET@MC. PLease add yourself so I can stop pestering
everyone who doesn't care.)
                Noel
\1f
KLOTZ@MIT-MC 08/23/81 14:57:27
To: (BUG ITS) at MIT-MC
Just a little while ago, with very few users (no arpa users), MC
decided the imp was down.  I had been using the MC: device from
AI succesfully, but then got a device not avail. error.

I deposited SCLNET in supcor.  It got cleared, but the net didn7t
come back up.  I tried the net command in lock, and that didn't work
either.  Then I tried making impup and imptcu get into teh state
where it would try to bring the imp up.  It didn't.  I didn't touch
the hardware.

DCP was around, and couldn7t do anything, either.
Leigh.

\1f
Date: 14 August 1981 06:18-EDT
From: David A. Moon <MOON5 at MIT-AI>
To: BUG-ITS at MIT-AI

INQUIR data base smashed on AI between 8/14/81 02:37:40 and 8/14/81 03:01:11.
INQUIR;LSR1 FUKT is a version which causes the name dragon to die by LSRGET
taking a non-skip-return in its typical non-informative fashion.  I haven't
had enough sleep recently to diagnose it more than this.
\1f
GZ@MIT-MC 08/14/81 05:42:02
To: (BUG ITS) at MIT-MC
I don't know if it matters but the last two or three times the system
crashed, my speed got reset to 300 when it came up (as per :tctyp des).
I'm on T10.

\1f
GJC@MIT-MC 08/14/81 00:54:26
To: (BUG ITS) at MIT-MC
There is a job 
55 037F55 NETRFC CCA AR3SI ? 14 6 0%   REALTM
110 037F55 JOB.07 SYS *10!10 ? DSN  35 34 0% 7:03 PARERR 2

If I try to do 110X from peek it crashes the system, (but the system
is able to revive evidently).

-gjc

\1f
Date: 13 August 1981 18:33-EDT
From: David Chapman <ZVONA at MIT-AI>
To: BUG-ITS at MIT-AI

:ee should get telsup, not telnet.  So presumably should all the other hostname programs.
\1f
Date: 13 August 1981 06:08-EDT
From: Leigh L. Klotz <KLOTZ at MIT-AI>
Subject: AI crash
To: BUG-ITS at MIT-AI

Just now, AI got in some sort of loop.  None of the select-lock lights
were on on any disk drives.  It was running in exec mode, and it looked
like it was looping because the PC didn't look like it was changing
much, but the pager lights were all pretty much half lit.

I looked around for people, and DLA told me that he knew that RG
was not here.

I halted it, and looked at where it halted.  It seemed to be
multiplying some numbers that it got from the TCMXV variable
of tty 40.

I printed out all the ac's, and some tty variables of tty 40 and
near ttys.  Now that I think of it, the routine ended in a popj,
so I guess I should have looked back up the stack to see who called
it and try to see if there was something else important that I could
record about its looping, but I didn't.

I booted it.

Leigh.
\1f
Date: 12 August 1981 14:10-EDT
From: Leigh L. Klotz <KLOTZ at MIT-AI>
Subject: QCHNRT+5
To: BUG-ITS at MIT-AI

AI halted at this location at noon today.  I tried to record
as many significant-looking locations as I could on the console.
It seemed to be that something it expected to be in some saved ac's
somewhere wasn't there.

I waited about 30 minutes before rebooting.  I looked around
and found PDL on dm, but he didn't answer.  I paged RG, but he
wasn't around.

I noticed that RWK had dumped a crash on ai a while back, so I tried
to dump it (since it appeared to be a software problem, as opposed to
the random interrupt yesterday).  I tried to find out how much
free space there was from dskdmp, but couldn't.

I forgot about the memory off being in the low memory, and dskdmp
got an nxm trying to dump.

At this point I wasn't sure if dskdmp was clobbered, so I was going
to reload it from tape when rg showed up and said it was ok just
to restart it.

There is a little information in the log, but most is on the
console.

Leigh.
\1f
Date: 10 August 1981 12:58-EDT
From: Leigh L. Klotz <KLOTZ at MIT-AI>
To: BUG-ITS at MIT-AI

AI halted at QINTE+11 a little while ago.  I looked for someone
who knew what was going on with the recent disk problems, but
no one was around.  I found Stu Galley, and he came up and helped.

The information is in the log.  Regster Q contained 0, but he
didn't know if that meant drive 0 or was irrelevant.  We wrote
down the pack id, sector number, and other information in the
log.

Leigh.
\1f
OAF@MIT-MC 08/10/81 12:25:52
To: (BUG ITS) at MIT-MC
On Sunday morning 8/9/81 at 0900 on MC there were 10 users logged in,
one macsyma, fair share 6%, and stayed that way.  I gunned every
non-logged-in job I could find from peek, including 
        several people's crtsty's (old - idle easily an hour)
        CSTACY's bye (which also was hung) and
        a stack of NETRFCs with REALTM PARITY ERROR listed at extreme
                right.

Then the fair share went to 60% or so.
Did I did the right thing, wrong thing??

Are y'all the right people to inform?

\1f
Date: 9 August 1981 23:04-EDT
From: David W. Payton <PAYT at MIT-AI>
To: BUG-ITS at MIT-AI

Tex on MC seems to be broken.  If you just try to type \input basic, it complains.
Since this works on AI, there must be some problem.  Who should I notify?
\1f
GREN@MIT-MC 08/03/81 00:53:35
To: (BUG ITS) at MIT-MC
CC: FILE-RETRIEVAL at MIT-MC
Would it be ok to load .INFO.;ITS TRANSL back from tape 511?  It was
taken off in '73.  I saw pointers to that file in ITS .CALLS in the
translation hacking part...  Why was the file taken off?  Is the
information in it obsolete?

Danke, --Gren

\1f
Date: 30 July 1981 11:57-EDT
From: David Chapman <ZVONA at MIT-AI>
To: BUG-ZWEI at MIT-AI
cc: BUG-ITS at MIT-AI

The file crash;quinte doffl has a negative creation date and a file author of DICK 
(whereas it was actually just created by RWK with dskdmp.)  :listf can handle this,
but zwei gets an errror parsing a negative date.
\1f
MOON@MIT-MC 07/29/81 00:39:31 Re:  VALID CLEAR OR STORED SET error
To: GREN at MIT-MC
CC: (BUG ITS) at MIT-MC
I wonder why this is not in the documentation (.INFO.;ITS JOB)?

It means that either you tried to JOBRET and the other job was not
waiting for a response, or you tried to JOBGET and the other job was
not asking you to do something.
\1f
Date: 28 July 1981 19:39-EDT
From: Robert W. Kerns <RWK at MIT-MC>
Subject: ITS listings
To: BUG-ITS at MIT-MC

The ITS listings have been reprinted, and are nicely labeled, etc., so we
can stand a chance of finding what we want.  If anybody wants to look at the
chicken scratches on the old ones, they live in a tape box beneath the table
in 926.

The listings for the PDP11 programs (IOELEV, 11DDT, TV) haven't been redone
yet, but will be soon.

\1f
GREN@MIT-MC 07/28/81 01:13:55
To: (BUG ITS) at MIT-MC

In the jobdevice I am debugging via an OJB: I try to pass back via JOBRET
the 5 word block of data requested by a .RCHST.  The JOBRET consistently
pulls a VALID SET OR STORED CLEAR error.  If I instal the jobdev in DEVICE;
and try the exact same thing from there, it flies - No error.

What *IS* this error?  Noone can tell me.

\1f
Date: 27 Jul 1981 0912-EDT
From: DEVON at MIT-DMS (Devon S. McCullough)
To: BUG-its at MIT-DMS
Subject: BUG => its
Message-id: <[MIT-DMS].205130>

DM is outputting in groups af about 32 characters with 2-4 second delay betw\b


\1f
RWK@MIT-MC (Sent by RWK0@MIT-MC) 07/25/81 17:53:11 Re: REM's hangage
To: (BUG ITS) at MIT-MC
CC: REM at MIT-MC
This was the usual problem of getting a SEND via MLSLV and having the
MLSLV drop dead.

\1f
REM@MIT-MC (Sent by ___101@MIT-MC) 07/25/81 17:36:47
To: (BUG ITS) at MIT-MC
I think I have a hung HACTRN.
I was in RMAIL, did a Quit command, it said WRITTEN:  REM;REM RMAIL
then just hung, never coming back to DDT.  I tried ctrl-Z many times
but they just echoed as ^Z and finally filled thebuffer and beeped.
I thought the system had hung so I went away for a half hour then
reconnecte to find my detached job.  I attached to it and found
it still in the sme funny state, ^Z ^Q ^G all just echoed (as
uparrow-Z uparrow-Q and a real live bell respectively) but didn't
abort the job or give a ddt prompt or anything.
I then disconnected again, leaving it detached for yo to look at.

\1f
Date: 25 July 1981 01:40-EDT
From: David A. Moon <MOON5 at MIT-AI>
To: BUG-ITS at MIT-AI

WE TRIED TO WORK ON THE 10/11 INTERFACE BUT COULD NOOTT
GET IT TO FAIL.  IF AI STARTS GETTING PARITY ERRORS TRY SHUTTING
OFF THE XGP SPOOLER AND STEPPING ON ANYONE WHO WANTS TO RUN D OR PW
\1f
Date: 23 July 1981 15:55-EDT
From: David Chapman <ZVONA at MIT-AI>
To: BUG-ITS at MIT-AI, BUG-GMSGS at MIT-AI

running :gmsgs I get a directory full.  Mine isn't.  I assume the problem is
that sys; is 97.7% full and it can't write sys;:msgs times.
\1f
Date: 21 Jul 1981 1211-EDT
From: SWG at MIT-DMS (S. W. Galley)
To: CSTACY at MIT-DMS
Cc: bug-its at MIT-DMS
In-reply-to: <[MIT-DMS].204538>
Subject: [Re: DM stys]
Message-id: <[MIT-DMS].204585>

INQUIR & TTYTYP data have not yet caught up with reality,
but soon they will.

\1f
Date: 21 Jul 1981 1157-EDT
From: PDL at MIT-DMS (P. David Lebling)
To: BUG-ITS at MIT-DMS
Subject: BUG => ITS
Message-id: <[MIT-DMS].204581>

When trying to append to a mail file in a directory that is full
(99+% according to DSKUSE), COMSYS sits spinning its wheels in
+OPEN, using up a much of the machine as there is free.  Is it
possible that writeover mode opens aren't giving DIRECTORY FULL
errors?

\1f
Date: 21 Jul 1981 1037-EDT
From: PDL at MIT-DMS (P. David Lebling)
To: CSTACY at MIT-DMS
Cc: bug-its at MIT-DMS
In-reply-to: Message of 21 Jul 81 at 0009 EDT by CSTACY@MIT-DMS
Subject: [Re: DM stys]
Message-id: <[MIT-DMS].204570>

T05 is the downlink to the Apollos.  The Apollo <-> ITS FTP program
logs in to DM as "MUDDLE".  It says "[not in use]" because no one
has updated the TTYLOC file yet.


\1f
Date: 21 Jul 1981 0009-EDT
From: CSTACY at MIT-DMS (Christopher C. Stacy)
To: bug-its at MIT-DMS
Subject: DM stys
Message-id: <[MIT-DMS].204538>


Why is "MUDDLE" (File Directory Only) logged in on T05
and idle for 13 minutes, with a Console Location of "[not in use]"?



\1f
MOON@MIT-MC 07/13/81 19:57:00
To: WJL at MIT-ML
CC: (BUG ITS) at MIT-MC
    WJL@MIT-ML 07/13/81 09:19:24
    To: (BUG ITS) at MIT-ML
    7/3 I copied a 16 block file from ai to ml using the ai device.  I have since
    found that there were about 20 errors in the resulting file, randomly scattered
    throughout.  All were changes of characters with no apparent consistency e.g.
    " " -> "`", ")" -> "i", "U" -> "M" ...
    Unfortunately, I don't have the original file anymore.
This was a hardware bug with the IMP.  I guess you didn't see the system message
from OAF announcing that it had been fixed, or didn't correlate it with your problem.
\1f
WJL@MIT-ML 07/13/81 09:19:24
To: (BUG ITS) at MIT-ML
7/3 I copied a 16 block file from ai to ml using the ai device.  I have since
found that there were about 20 errors in the resulting file, randomly scattered
throughout.  All were changes of characters with no apparent consistency e.g.
" " -> "`", ")" -> "i", "U" -> "M" ...
Unfortunately, I don't have the original file anymore.
-Bill Long
\1f
Date: Sunday, 12 July 1981, 19:19-EDT
From: Robert W. Kerns <RWK at MIT-MC>
To: REM at MIT-MC
Cc: (BUG ITS) at MIT-MC, EHUANG at MIT-AI
In-reply-to: The message of 12 Jul 81 17:01-EDT from REM at MIT-MC


    REM@MIT-MC 07/12/81 17:01:41
    To: (BUG ITS) at MIT-MC
    CC: EHUANG at MIT-AI
    Darn.  If you type ahead while in an editor (emacs/rmail) while a SEND is
    being typed on your screen, ITS doesn't buffer your input, so yo lose it.
    That means if you're in the middle of typing something and you get a
    flurry of SENDs or one long SEND you HAVE TO stop what you are doing
    until the SENDs are finished, then try to remember what you were doing
    after you've lost your train of thought.  You can't evn finish the
    sentence you are in themiddle of before stopping to look at the SENDs.

This is not true.

However, it is unfortunately true that if you type a control-G during
the printing of a SEND, the control-G will abort out of that printing,
rather than being passed to the program.  It is also true that characters
which are intended to interrupt the program you were typing to will not
cause an interrupt, but will be read as normal interrupt.  This is a DDT
problem that may or may not be possible to fix.

\1f
REM@MIT-MC 07/12/81 17:01:41
To: (BUG ITS) at MIT-MC
CC: EHUANG at MIT-AI
Darn.  If you type ahead while in an editor (emacs/rmail) while a SEND is
being typed on your screen, ITS doesn't buffer your input, so yo lose it.
That means if you're in the middle of typing something and you get a
flurry of SENDs or one long SEND you HAVE TO stop what you are doing
until the SENDs are finished, then try to remember what you were doing
after you've lost your train of thought.  You can't evn finish the
sentence you are in themiddle of before stopping to look at the SENDs.

\1f
Date: 10 Jul 1981 2359-EDT
From: Alyson L. Abramowitz <ECG.RICH.ALA at DEC-MARLBORO>
To: bug-its at MIT-AI
cc: cstacy at MIT-AI, ala at MIT-AI
Subject: Problems with applying for accounts on MIT-AI
Message-ID: <MS"5(1631)"11743046147.16.332.4441 at DEC-MARLBORO>

There appears to be a problem in the program that is run when
a new user applies for an account on MIT-AI. The program asks
the user for his/her Uname, real name, address, and reason for wanting
an account just fine. Unfortunately after it does that it prints
a ")" followed by a carriage return and just hangs there. A CTRL-G
gets one out of that state (and back to DDT), but, unfortunately, it
also looses all the information that the potential user just
entered. 

I watch a potential new tourist do this a couple of times in a row
tonight. He wasn't doing anything obviously wrong and the same thing
happened every time. Can someone check into this?

Thanks.
   --------
\1f
Moon@MIT-MC 07/10/81 21:05:33
To: RMS at MIT-AI
CC: (BUG ITS) at MIT-AI
    Date: 9 July 1981 16:15-EDT
    From: Richard M. Stallman <RMS at MIT-AI>
    To: BUG-ITS at MIT-AI

    There has long been a problem whereby every so often
    a TV gets hung, but gunning or detaching its tree unhangs it.

When I have looked, the cause has always been that the 10/11 interface
spazzed writing into the 11, and so there is a -1 at the place where the
11 thinks the next character from the 10 will come, so the 11 never
processes any more characters.  Since the 10 is careful never to wrap
completely around the buffer, it never comes back and writes over that -1
again, so it stays there forever.  Detaching resets everyone's buffer pointers.

    Today, several TVs were hung and the usual fix did not unhang them.
    I discovered that they were hung becaue their TTOALC words
    contained 100 instead of the -1 that they should have contained.

I hope this was due to the heat.
\1f
Date: 9 July 1981 16:15-EDT
From: Richard M. Stallman <RMS at MIT-AI>
To: BUG-ITS at MIT-AI

There has long been a problem whereby every so often
a TV gets hung, but gunning or detaching its tree unhangs it.

Today, several TVs were hung and the usual fix did not unhang them.
I discovered that they were hung becaue their TTOALC words
contained 100 instead of the -1 that they should have contained.
\1f
Date: 8 July 1981 09:00-EDT
From: Leigh L. Klotz <KLOTZ at MIT-AI>
To: RICH at MIT-AI
cc: BUG-ITS at MIT-AI

The home directory set in inquir, with the FILE option.  With a machine
name (CHURK@AI), it means that the user's home directory will be CHUCK
only on AI.  Without one, it will be that on any machine with a directory
by that name.

The HSNAME program will tell you what the home directory of a particular
user is.

Leigh.
\1f
Date: 8 July 1981 08:46-EDT
From: Charles Rich <RICH at MIT-AI>
Subject: enquiry
To: BUG-ITS at MIT-AI
cc: SIDNER at BBND

Pray tell -- how does one change the home directory (i.e.
where mail files are stored) for someone without a user
directory?  In particular I want to move CANDY from
USERS1; to CHUCK; because USERS1;is too full.  Is there
something I can put in here login file, or can it be
caught even before that?
        Thanks, Chuck.
\1f
FONER@MIT-MC 07/05/81 23:21:12 Re: Flakiness transferring file from AI to MC
To: (BUG ITS) at MIT-MC, (BUG its) at MIT-AI
CC: foner at MIT-AI
I was trying to transfer a file from AI to MC earlier tonight, and the
connection appeared to freeze.  I got the ITS prompt again, but the
file was marked locked (according to FIND) and PEEK C shows it with a
J next to it.

Eventually the file became unlocked, and included both the original
file and many replications of some random cruft from elsewhere on the
disk.  Apparently the ^C was missed, and far more was transferred than
intended.

The file is MC:GUEST1;FONER LOSSAG.  Past around 47% of the way
through starts the peculiar lossage I've described.  Might this have
something to do with AI's IMP flakiness, or is this a genuine problem
with ITS or FTP or whatever really does the transfer?

I don't need an answer for this, really, since I can just retry the
transfer.  But it should probably be reported in case it's part of a
consistent pattern of garbling.

Ciao.

                                                <LNF>

\1f
Date:  5 July 1981 20:37 edt
From:  Margolin at MIT-Multics (Barry Margolin)
Subject:  random bits
Sender:  Margolin.PDO at MIT-Multics
To:  bug-its at MIT-AI

If there is a more appropriate BUG- list, please forward this and let me
know.  Thank you.

AI has been turning on random high-order bits when it outputs accross
the network.  I notice this in netmail I receive from AI and when I
SUPDUP or TELNET to AI.  I am not sure whether this happens over the
CHAOSnet (it happened when I TELNETted from MC to AI, if that helps),
but it certainly happens over the ARPAnet.  It is usually the 100
(octal) bit (spaces turning into tildes is the most common symptom), but
sometimes it is the 200 bit, often turning alphabetics into invalid %TD
codes when I am SUPDUPing.
\1f
Date: 5 July 1981 10:12-EDT
From: Oded Anoaf Feingold <OAF at MIT-MC>
Subject:  AI Arpanet problems
To: MOON5 at MIT-AI
cc: JAN at MIT-MC, BUG-ARPA at MIT-AI, BUG-ITS at MIT-AI,
    control at BBNC, RClifford at BBNC

David, thanks for the bit-level bug report.  But as far as getting things 
done on Sunday goes, don't bother.  The NCC nose that the IMP picks bits
on occasion, that it does so neither at 16 nor 36 (nor any other obvious 
word-length type number) bit intervals, and there is a repair visit 
already scheduled:

Tomorrow (Monday) at 0700 or so I will detach AI's IMP cable and install
a loopback, someone from BBN field service will arrive and repair the
IMP, and only when the IMP runs its own diagnostics will they try anything
with AI back on the net.  I certainly agree there is no reason to touch
ML's IMP cable, or even look crosseyed at it.

Past history:  On Thursday TY took off AI's IMP cable (at the NCC's request)
and they found the problem while running diagnostics.  Apparently the fault
showed up so fast that there was no reason to keep AI off the net for more
than a few minutes - hence virtually no interruption to users.  
        This time the repair procedure may take a few hours/days/millenia/
minutes, and since the IMP will be powered down to change cards, that means
the other IMP 6 hosts will be off the net, as stated in .MSGS.;ARPA DOWN.

[Note for NCC people - the specific errors David Moon spotted are:
        Bits with octal weights 10 and 4 get picked (spurious one). 
        Bit with octal weight 10 gets dropped (spurious zero).
                There may be additional problems.]


Oded
\1f
Date: 5 July 1981 04:07-EDT
From: David A. Moon <MOON5 at MIT-AI>
Subject: AI Arpanet problems (p.s.)
To: BUG-ARPA at MIT-AI
cc: BUG-ITS at MIT-AI

I forgot to say in my previous message that the problems are believed to be
entirely in the host-to-IMP direction.
\1f
Date: 5 July 1981 04:06-EDT
From: David A. Moon <MOON5 at MIT-AI>
Subject: AI Arpanet problems
To: BUG-ARPA at MIT-AI
cc: BUG-ITS at MIT-AI

The problems are in the IMP, not in AI, as can be demonstrated by plugging ML
into AI's IMP port.  Please do not try this experiment yourself!  It took
me over an hour to get ML to work again on its own port after doing this,
because the connectors are quite literally falling apart.  And each time
they are plugged and unplugged they get worse.

The problems with the IMP, in terms of its 16-bit words, are at least the
following.  It's a little hard to tell but I think there may be problems
with some other bits as well (actually I am fairly sure):
Bits with octal weights 10 and 4 get picked (spurious one).
Bit with octal weight 10 gets dropped (spurious zero).

I will try and call up the NCC tomorrow about this, during the daytime, but
it wouldn't hurt for anyone else who is around during the day to call them
first.  The number is 661-0100 and you need to convince them to give you a
hardware guy, preferably Sunday rather than Monday.
\1f
Date: 4 July 1981 21:50-EDT
From: David A. Moon <MOON at MIT-MC>
Subject: not more CHAOS lossage
To: DCP at MIT-MC
cc: BUG-ITS at MIT-MC, CHAOS-NCP-PEOPLE at MIT-MC

    Date: 4`July 1981 1s:43-EDT
    From: David C. Plummer <DCP at MIT-MC>
    Subject:  more CHAOS lossage
    To: BUG-ITS at MIT-MC
    cc: CHAOS-NCP-PEOPLE at MIT-MC

    Sitting on MC, I run :CHATST. Send a RFC to an ITS (AI or MC)
    with contact name STATUS and enough JCL to make the byte count of
    the packet 486. (that's right, 486. also breaks as does 488). It
    does not give me an unrecoverable data error as 489. does, yet it
    tries to send it. Response: what response, there is none. Now do
    it again, but send the 486. byte data length packet to either
    MC-CHAOS-11 or AI-CHAOS-11 and it comes back with the standard
    reply to status.
The STATUS protocol does not accept arguments.  The ITS server for it
happens to implement this restriction and the pdp11 server happens not to.
The number of bytes of arguments is irrelevant.  If you wait long enough
you will get back a "connection refused" reply; the system waits a long
time (2 minutes?) for a server to pick up the queued request before sending
this.  The timeout may be too long.
\1f
Date: 4 July 1981 13:43-EDT
From: David C. Plummer <DCP at MIT-MC>
Subject:  more CHAOS lossage
To: BUG-ITS at MIT-MC
cc: CHAOS-NCP-PEOPLE at MIT-MC


I don't know who is (not) doing the following:

Sitting on MC, I run :CHATST. Send a RFC to an ITS (AI or MC)
with contact name STATUS and enough JCL to make the byte count of
the packet 486. (that's right, 486. also breaks as does 488). It
does not give me an unrecoverable data error as 489. does, yet it
tries to send it. Response: what response, there is none. Now do
it again, but send the 486. byte data length packet to either
MC-CHAOS-11 or AI-CHAOS-11 and it comes back with the standard
reply to status. I looked over the code breifly, looking for
%CPMX(W and C) and I couldn't spot anything off hand. Could be a
fencepost, could be somebody isn't keeping track of something (is
everybody remembering the two header words that the system tacks
on to the packet?). My guess is ITS will send but not receive.

Does anybody ever remembering having problems sending large
packets around and having the conneciton hang? If so, this might
be the reason. 

\1f
Date: 3 July 1981 17:11-EDT
From: Steven T. Kirsch <SK at MIT-MC>
Subject:  The DDT prompt went away a couple of days ago on MC...
To: BUG-ITS at MIT-MC

and never came back.  Is this only on logins over the net?
or a new feature.

Only the prompt after the "if you are a tourist...." message has gone.

\1f
Date: 1 July 1981 23:49-EDT
From: Christopher C. Stacy <CSTACY at MIT-AI>
Subject:  net interface problems?  losing bits
To: BUG-ITS at MIT-AI, pdl at MIT-DMS, eak at MIT-MC


TELNETing in from a foreign TIP this evening, I watched a bunch of
spaces get displayed as "`"s and "~"s. I thought this was a problem
with my terminal (which has never happenned before), but after
reading the other bug reports.....

Chris
\1f
Date: 1 July 1981 22:40-EDT
From: Howard I. Cannon <HIC at MIT-MC>
Subject:  AI Imp Interface
To: BUG-ITS at MIT-MC

I can't reproduce the problem now, so I am going to leave AI on the net for now.  The only
thing I did was to reset the IMP interface on AI with the front panel switch.

\1f
Date: 1 July 1981 20:08-EDT
From: Mike McMahon <MMCM at MIT-AI>
To: BUG-ITS at MIT-AI

I have renamed the server ftp to prevent incoming mail from being garbaged.
\1f
Date: 1 July 1981 19:01-EDT
From: Eugene C. Ciccarelli <ECC at MIT-AI>
Subject: Network interface problems
To: BUG-ITS at MIT-AI

I just got a message (via Chaosnet) from EAK who says AI's
Arpanet interface is garbaging bits, and suggests someone
taking AI off the network temporarily to avoid problems with
misforwarded mail, etc.
\1f
Date: 1 Jul 1981 1522-EDT
From: PDL at MIT-DMS (P. David Lebling)
To: BUG-its at MIT-DMS
Subject: BUG => its
Message-id: <[MIT-DMS].202889>

AI's net interface (possibly?) is losing.  Getting a lot of picked and
dropped bits from MLDEVs pulling files to DM from AI.  This doesn't seem
to happen pulling to DM from MC. (ML is down right now).
        Dave


\1f
Date: 1 July 1981 16:30-EDT
From: Leigh L. Klotz <KLOTZ at MIT-AI>
To: BUG-ITS at MIT-AI

I didn't see PDL's previous note, but MLDEV's on AI seem to be
breaking at LOSE3.  crash;mldev record and crash;mldev 1
are the dump and ac's of one.

Leigh.
\1f
Date: 1 Jul 1981 1525-EDT
From: PDL at MIT-DMS (P. David Lebling)
To: BUG-its at MIT-DMS
Subject: BUG => its
Message-id: <[MIT-DMS].202891>

Typically the aforementioned MLDEVs .VALUE at NTDI+14 with c/ 1000
and d/ 400


\1f
Date: 1 July 1981 14:27-EDT
From: Earl A. Killian <EAK at MIT-AI>
To: BUG-ITS at MIT-AI

I'm telneting from LLL-S1 to AI and I find that on output a large
number of characters output have their bits modified.  In particular,
a large number os spaces have turned into "`"s, i.e. the 100 bit got
turned on.  Also, I've seen ">" turn into "~", ":" into "z", and other
weird things.  This isn't happening to other hosts.
\1f
Date: 30 June 1981 05:21-EDT
From: Leigh L. Klotz <KLOTZ at MIT-MC>
Sender: KLOTZ0 at MIT-MC
Subject: ellen's hactrn
To: BUG-ITS at MIT-MC
cc: KLOTZ at MIT-MC, ELLEN at MIT-MC

The same thing happened to me recently.

There are some tourists on ai who have written this hack which
runs as a disowned job and periodically sends random messages
to the hackee.  [Message from your Terminal]...

Someone tried to do this to me, but the program seems not to
work quite right, or something.  It left me in CLOBI.  I killed
the job and it went away.  I don't know that this is the same thing.

Right now when I try to send to ellen, my hactrn hangs at
the place where it is waiting to send.  I do not know what
failure code the open returned, because she had logged out
by the time I tried to do it again, and the register had
been trashed.  But since it was looping, it must have
been %EFLDIR or %ENAFL.

Her old, bad hactrn was trying to read from CLO: _CLI_;ELLEN HACTRN,
and had it open in .BAI.  I guess this is why my sends to her didn't
work, even though the hactrn which was trying to send to itself
became HACTRO.  That doesn't seem quite right, though.

HCLOB was 0 and HHACK was -1.  I'm not sure why her hactrn was
trying to open itself.

In the process of trying to look back up the stack to see
who had opened this,  I managed to trash the job.  I did a
CTYPE 41 \eX that I meant to do in another job in the hactro,
and of course trashed it.  It dumped itself, but I doubt that's
of any use.

It was trying to do a .IOT on it at FDRCO4, having been called
at FDRCO1+3.  I didn't get any farther.

Leigh.

\1f
ELLEN@MIT-MC 06/30/81 04:05:59
To: (BUG ITS) at MIT-MC
CC: (BUG DDT) at MIT-MC
Three times in succession tonight I have control-Z'd out of an EMACS and
had my DDT hang, typing control-G had no effect.  Typing echoed but
$$V or other commands had no effect.  Upon hanging up (I am on a dialup
line) and reconnecting, leaving my tree detached, I find on looking at
a peek that my HACTRO is in state "*CLOBI" and it says "CLI"
to the right of the "Time PIs" column.  This has not happened to me from
anyplace except exiting EMACS, however the EMACS job appears unaffected,
as I can snarf it from the HACTRO and continue using it.

\1f
Date: 29 June 1981 19:47-EDT
From: Earl A. Killian <EAK at MIT-MC>
Subject:  enquiry
To: RICH at MIT-AI
cc: BUG-ITS at MIT-AI

Use the ALLOC command of the DUMP program.

\1f
Date: 29 June 1981 11:06-EDT
From: Charles Rich <RICH at MIT-AI>
Subject: enquiry
To: BUG-ITS at MIT-AI

I used to know, but now cannot remember and cannot find in the documentation,
the answer to this question:
        How do I allocate a directory to a given device?
Thanks, Chuck.
\1f
MOON@MIT-MC 06/24/81 16:02:01 Re: MC lack of response on the Chaosnet
To: DCP at MIT-AI
CC: (BUG ITS) at MIT-MC
    Date: 24 June 1981 15:32-EDT
    From: David C. Plummer <DCP at MIT-AI>
    To: BUG-ITS at MIT-AI

    I have noticed this in the past, and it is happening again. MC is at
    this moment down. It does not respond to the :TIMES program, nor the
    CTIMES program, nor to attempts to connect. It does however, answer a
    status packet (generated with  :MOON;CHARFC MC STATUS  ). I assume it
    is the 11 that handles the chaos net that is responsible for this. 
Why do you assume that?  It's not true.
                                                                       If
    this is so, could it be fixed? MC should respond to the status for MC,
    and the chaos front end should respond to STATUS only sent to it, not
    to MC also. I realize this may be an efficiency hack, but it is doing
    the wrong thing.
The problem was undoubtedly that there were no free job slots and therefore
server processes could not be created.  The STATUS response is generated
directly by the system rather than by a server process, for exactly this
reason: so that it will always work if the system is up, even when it is
overloaded.
\1f
DCP@MIT-MC 06/24/81 15:38:11
To: (BUG ITS) at MIT-MC
I guess that last bug report is slightly bogus. MC was not down, but it was dead
to the outside world. 

\1f
Date: 24 June 1981 15:32-EDT
From: David C. Plummer <DCP at MIT-AI>
To: BUG-ITS at MIT-AI

I have noticed this in the past, and it is happening again. MC is at
this moment down. It does not respond to the :TIMES program, nor the
CTIMES program, nor to attempts to connect. It does however, answer a
status packet (generated with  :MOON;CHARFC MC STATUS  ). I assume it
is the 11 that handles the chaos net that is responsible for this. If
this is so, could it be fixed? MC should respond to the status for MC,
and the chaos front end should respond to STATUS only sent to it, not
to MC also. I realize this may be an efficiency hack, but it is doing
the wrong thing.
\1f
Date: 24 June 1981 00:55-EDT
From: Steven T. Kirsch <SK at MIT-MC>
Subject:  random clobberage on MC?
To: BUG-ITS at MIT-MC

This could be all in my head, but I noticed two clobberages today that
struck me as a little strange:

The end of SK;SK OBABYL appears to have some lines missing from the
last message.

SK;PASCAL LISP seems to be missing (or transpose and missing)
characters at the end.  You can read this file and see for yourself
(it's only about 10 lines long).  If comparision with the tape dump
(Tape 325, file #95) shows a discrepancy, we are all in a lot of
trouble (since ITS says, and I agree, that the file hasn't been
modified in any normal way since it was dumped).

I could be imagining all this and could have accidently clobbered these files
myself.  I thought I'd bring it up just to be on the safe side.
\1f
Date: 20 June 1981 18:10-EDT
From: Alan Bawden <ALAN at MIT-MC>
Subject: opening the CLI device
To: BUG-ITS at MIT-MC
cc: DCP at MIT-MC

When opening the CLI device fails because the core link already exists
(returning %ENAFL) the target job gets interrupted anyway.
\1f
ALAN@MIT-MC 06/20/81 17:27:14 Re: recent MC crash & .getsys
To: (BUG ITS) at MIT-MC
The recent MC crash where the system died trying to gun a garbage job
tree for me may be even more related to me than that.  

Earlier that evening I discovered that the .getsys uuo was acting
strangely (never mind WHY I discovered that).  It seems that it no
longer works for some of the random sixbit keywords you can give it
(for example: DEVS and NCALLS work, but GETS doesn't (!)).  In the
cases where it doesn't work it has a tendency to trash the two
accumulators involved (aobjn pointer and sixbit key).

Now, I was just going to ignore this all, figuring that nobody uses
the thing anyway, but after talking with Moon it sounds like one of
the garbaged words in the job in question was trashed with one of MY
aobjn pointers from a failing .getsys!

Perhaps it is worth someone's time to look into this.
\1f
RLB@MIT-MC 06/18/81 02:10:15
To: (BUG ITS) at MIT-MC
Recent MC crash dumped as CRASH;CHACK1 14
Halt at CHACK1+14
Notes in the crash log.
Acc U pointed to QCP HACTRP which ALAN says he was trying to gun when 
crash happened.

\1f
Date: 13 June 1981 13:47-EDT
From: David C. Plummer <DCP at MIT-AI>
To: BUG-ITS at MIT-AI, ALAN at MIT-AI

MC has been having problems since about noon today (Saturday). It
revived itself a few dozen times in the course of a couple hours. I
may have been the cause of this. I have been hacking with the CLO:
device this afternoon. Does anybody know if there are any bugs with
this beast? I will refrain from using it until I hear a go ahead. If
you want details on what I was doing with it, just ask.
\1f
Date: 11 June 1981 03:24-EDT
From: David A. Moon <moon5 at MIT-AI>
Subject: Output reset doing weird things on MC tonight
To: sk at MIT-MC
cc: BUG-ITS at MIT-AI

I broke something in the process of fixing another bug.  It's fixed now.
\1f
SK@MIT-MC 06/11/81 01:53:53 Re: last message
To: (BUG ITS) at MIT-MC
re-attaching did work in one case.
\1f
SK@MIT-MC 06/11/81 01:49:51 Re: did something get "fixed" recently?
To: (BUG ITS) at MIT-MC
In logging in through the SAIL tip as usual, I discovered today that
^S'ing the "welcome" message would hang my terminal.  This happened
consistently.  Up till today, I have had no problems ^Sing the message
and I do it almost every time I log in.

Also, typing Q in peek while it attempted to typeout caused me to
hang.

Reowning the detached tree did not make things work (still dead) in
one case, and I forgot what happened in the other case.

In any case, I think I had to close and re-open the connection about 5
times today.

Let me know if you need more info.

\1f
GJC@MIT-MC 06/10/81 09:37:27
To: (BUG ITS) at MIT-MC, (BUG MAIL) at MIT-MC
Some people had their MAIL file on the PACK NOT AVAILABLE disk.
If they recieved any mail since then, what happens is that
instead of COMSAT specially handling the error, it takes
it as FILE-NOT-FOUND and simply creates a new mail file.
People lose their mail.


\1f
JPG@MIT-MC 06/10/81 06:35:24
To: CBF at MIT-MC
CC: (BUG ITS) at MIT-MC
As I have stated many times in the past, I certainly don't care 
whether SECOND: is an RP04 or a T-300.

\1f
Date: 10 Jun 1981 0158-EDT
From: J. Noel Chiappa <JNC at MIT-XX>
Subject: Re: SECOND: device on MC:
To: CBF at MIT-MC, bug-its at MIT-MC
cc: JNC at MIT-XX

        I've been saying that the likelihood of a T-300 control
path failure is low for a while; the observed failure rates at
this time seem to obviate theoretical discussions of the matter.
I only saw that break once, and then it was a matter of switches
wrong, and not anything broken. So saying that the T-300's are
less reliable on those grounds isn't indicated. I have said
that I thought that the reap path ought to have SECOND: somewhere
after THIRD:, but JPG didn't like the idea the last time I
mentioned it.
-------

\1f
CBF@MIT-MC 06/10/81 01:22:01 Re: SECOND: device on MC:
To: MOON at MIT-MC
CC: JPG at MIT-MC, (BUG ITS) at MIT-MC
    MOON@MIT-MC 06/09/81 21:49:20 Re: SECOND: device on MC:
    The two times before this it was a Trident that went down.

Hmm, now that I think about it you're right; but I didn't even notice it.
Clearly my analysis is wrong. The reason I think it is better to have a
Trident be SECOND: (ie. be first to be reaped to) because when a Trident
goes down you get the choice of which Trident you want to leave down.
When pack 13 goes down the way things work now, it is the most recently
modified files that must go away.  With the other scheme there is one,
posible two whole packs of data more recent than the one lost.

\1f
MOON@MIT-MC 06/09/81 21:49:20 Re: SECOND: device on MC:
To: CBF at MIT-MC
CC: JPG at MIT-MC, (BUG ITS) at MIT-MC
The two times before this it was a Trident that went down.
\1f
CBF@MIT-MC 06/09/81 20:38:46 Re: SECOND: device on MC:
To: (BUG ITS) at MIT-MC
CC: JPG at MIT-MC
I think by this time it ought to be clear to all that the likelihood of one
of the RP04's being down probably far exceeds the likelihood of one of the
Trident's being down.  Therefore I don't understand why it is still first
in the migration path.  One could perhaps argue that the Tridents might be
less reliable since a failure of any item in the chain of hardware
connecting the Tridents can bring them both down (DL10, I/O 11, Century
controller), I might suggest that considering the percentage of storage
those devices represent, the system will effectively be useless to most
users anyway.  Therefore I think the only relevant probability to consider
is one Trident drive vs one RP04 going down, and I think its obvious which
is the more reliable of the two.

\1f
Date: 9 June 1981 20:34-EDT
From: David Eppstein <KRONJ at MIT-MC>
Subject:  Indirect cursor addressing
To: BUG-EMACS at MIT-MC, BUG-ITS at MIT-MC

I just checked again. MC has the problem too.

\1f
Date:  8 June 1981 1011-EDT (Monday)
From: Guy.Steele at CMU-10A
To: bug-its at MIT-AI
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
\1f
Date: 7 June 1981 14:20-EDT
From: Christopher C. Stacy <CSTACY at MIT-AI>
To: BUG-ITS at MIT-AI

on AI,

230479. memory errors in 47.4 hours.   (!?!??)

Well, at least ONE memory error, anyway.

Chris
\1f
Date: 4 June 1981 11:39-EDT
From: Maria Simi <MARIA at MIT-AI>
To: BUG-ITS at MIT-AI
cc: MARIA at MIT-AI


Please, somebody do something about the terminal in 939!!!!
The line is broken.
        Thanks, maria.
\1f
Date: 1 June 1981 00:58-EDT
From: Leonard N. Foner <FONER at MIT-AI>
Subject: This is not a bug, but a question to persons unknown
To: BUG-ITS at MIT-AI

I have been occasionally curious as to how the fair share is
determined.  Any theories I nurtured about its being a measure of idle
CPU time or anything of a similar sort were shattered tonight when I
noticed upon login that the fair share was 103%.

My question, of course, is just how this number is determined.  Any
help for this rather pointless question would be well received.

Thanx.

                                                <LNF>
\1f
Date: 24 May 1981 09:47-EDT
From: Robert W. Kerns <RWK at MIT-MC>
Subject: H19
To: Moon at MIT-AI
cc: BUG-ITS at MIT-MC

    Moon@MIT-AI 05/24/81 01:37:31 Re: H19
    To: rwk at MIT-MC
        kmp,bil@MIT-MC (Sent by BIL@MIT-MC) 05/23/81 21:56:03
        To: (BUG ITS) at MIT-MC
        Recently, all the H19's on the 8th floor have been dying on ^S^Q problems
        with insertline/deleteline. These used to work. The change happened maybe
        a week ago? Can it be fixed back or what's up?
        -kmp
    
    Bob, do you know anything about this?  I suppose ITS's idea of the
    padding got broken somehow?

No, Kent is just wrong about it having ever worked at 9600 baud.  There
is some bug in the changes I made for padding H19's with nulls, and I
haven't gotten around to debugging it yet.  In the meantime, use -%TOLID
at 9600 baud.  I suppose :TCTYP should know this.

\1f
kmp,bil@MIT-MC (Sent by BIL@MIT-MC) 05/23/81 21:56:03
To: (BUG ITS) at MIT-MC
Recently, all the H19's on the 8th floor have been dying on ^S^Q problems
with insertline/deleteline. These used to work. The change happened maybe
a week ago? Can it be fixed back or what's up?
-kmp

\1f
Date: 23 May 1981 15:21-EDT
From: David A. Moon <MOON at MIT-MC>
Subject: Chaos connections to Dover losing
To: JNC at MIT-XX
cc: BUG-TWENEX at MIT-MC, BUG-its at MIT-AI

    Date: 23 May 1981 1255-EDT
    From: J. Noel Chiappa <JNC at MIT-XX>

        Something about the latest change in the AI-IO-11 broke
    connections from XX to the Dover.
Actually, those work just fine.  But the DOVERSEND program has a private
Chaosnet server on MC, which I didn't know about it, that it uses to find
out the state of the MC dover spooler and of spruce, which hadn't been
converted and also failed to report back its errors properly.  It's fixed
now.
\1f
Date: 23 May 1981 1255-EDT
From: J. Noel Chiappa <JNC at MIT-XX>
Subject: Chaos connections to Dover losing
To: bug-its at MIT-AI, bug-twenex at MIT-MC
cc: JNC at MIT-XX

        Something about the latest change in the AI-IO-11 broke
connections from XX to the Dover.
-------
\1f
MOON@MIT-MC 05/21/81 20:50:59 Re: Bug fixed
To: (BUG ITS) at MIT-MC
That bug where network servers show up as logged in and looping forever
trying to log in again is a bug in the LOGIN system call introduced by
RWK a few months back and fixed in the source (ITS 1218).
\1f
Date: 20 May 1981 23:07-EDT
From: Mike McMahon <MMcM at MIT-AI>
Subject: Lisp machine gets "file system fucked" trying to read directory from ML:
To: BUG-LISPM at MIT-MC, BUG-ITS at MIT-MC
cc: MMCM at MIT-AI, MOON at MIT-MC

    MOON@MIT-MC 05/20/81 17:17:41 Re:  Lisp machine gets "file system fucked" trying to read directory from ML:
    There must also be a bug in the Lisp machine, that it dies so foully
    when it gets back an ISE0 error from a DIRECTORY operation (the real
    error is a CHNL NOT OPEN IOC error from the SIOT that is slurping in
    the MFD, but the error string reported by the file job says ISE0 for
    some reason, and has what the Lisp machine thinks is the wrong
    transaction ID.)
This failing SIOT symbolic call appears not to set the error code as
asked, so you still get ISE0, although it doesn't bomb out the file
system any more. 
    
    Date: 23 MAR 1981 0139-EST
    From: MMCM at MIT-AI (Mike McMahon)
    When you specify a non-existent directory to the DIRECTORY command,
    you don't get an error until interrupt time.  Probably it should
    fill the first buffer at process level before returning to the
    user.
This now properly gives an error via an asynch mark, however it would
still be better if it would happen sooner.


\1f
Date: 20 May 1981 18:32-EDT
From: Earl A. Killian <EAK at MIT-MC>
Subject:  [KREEN: Babyl Rave]
To: KMP at MIT-MC
cc: BUG-BABYL at MIT-MC, BUG-ITS at MIT-MC

My first guess is that Babyl is eliminating MIT-DM from the
header, except that MIT-DMS is what really occurs in the header,
and so a "S" is left.  This is the result of having DM be the
only ITS machine whose official arpanet host name is not
"MIT-" concatenated with what it returns as its machine name.
Sigh.  I supposed a special conditional is the only way to win.

\1f
MOON@MIT-MC 05/20/81 17:17:41 Re:  Lisp machine gets "file system fucked" trying to read directory from ML:
To: (BUG LISPM) at MIT-MC, (BUG ITS) at MIT-MC
This is caused by a bug in ITS, such that SIOT does not work properly
when reading a binary directory.  MLSLV notices the bug while most
other programs do not, since it tries to read past the end of the
directory.  The bug is fixed in the source (ITS 1216); as a byproduct
the operation will be much faster.  I guess I (or someone) should
install this system on ML soon.  (The Chaosnet is currently broken in
the source, but ML doesn't have a Chaosnet, and only hosts without a
Chaosnet cause the original symptom of the complaint from the Lisp
machine.)

There must also be a bug in the Lisp machine, that it dies so foully
when it gets back an ISE0 error from a DIRECTORY operation (the real
error is a CHNL NOT OPEN IOC error from the SIOT that is slurping in
the MFD, but the error string reported by the file job says ISE0 for
some reason, and has what the Lisp machine thinks is the wrong
transaction ID.)
\1f
Date: 20 May 1981 13:13-EDT
From: Robert W. Kerns <RWK at MIT-MC>
To: EAK at MIT-MC
cc: BUG-DDT at MIT-MC, BUG-ITS at MIT-MC

    Date: 19 MAY 1981 2044-EDT
    From: EAK at MIT-MC (Earl A. Killian)
    To: (BUG DDT) at MIT-MC
    
    Perhaps :REAP FOO should work even if FOO is on an unmounted pack?
    Does ITS provide the ability to do this (ie. open a directory
    entry)?

ITS dooesn't have a way to do this, although it does have bit 1.5
mean just the right thing in the case of links.  Maybe the right
thing is to make this bit work for non-links too?

\1f
Date: 19 May 1981 1506-EDT
From: TAA at MIT-DMS (Timothy A. Anderson)
To: BUG-its at MIT-DMS
Subject: BUG => its
Message-id: <[MIT-DMS].198181>

ITS 1214 seems to work much better with CFHPI+11 changed from
PUSH P,C ? HRLI C,2200 to HRLI C,2200 ? PUSH P,C.  The former
causes UCPRL to be called with just an address, rather than a
byte pointer, and crashes almost immediately.
        -taa

\1f
KLOTZ@MIT-MC 05/18/81 20:08:22
To: (BUG ITS) at MIT-MC
I just got a chnl not open error when trying to write a
file to the ai device from here.  I got some other error
before, which emacs was able to handle, but it cleared
the screen before I saw it.  Attempting to save it again
got the channel not open error.
It might have been directory full.

\1f
MOON@MIT-MC 05/17/81 02:30:37
To: (BUG ITS) at MIT-MC
The AI: device is broken such that trying to write a file when
there is zero free space on any pack causes the slave simply to .logout,
causing an ioc error on the other end (with no error message, just
channel not open) and no dead slave job lying around.  Maybe this isn't
a new bug, I don't know.
\1f
ed@MIT-ML (Sent by GSB@MIT-ML) 05/17/81 01:33:00 Re: record time
To: (BUG ITS) at MIT-ML
MC's record time seems to be 7 months, 23 days, etc.
\1f
MOON@MIT-MC 05/16/81 02:34:29
To: tc at MIT-AI
CC: (BUG ITS) at MIT-MC
The smoke alarm and the temperature alarm behind MC just triggered,
neither of them for any discernible reason.  By the time I was able
to go and look at all the detectors, none of them had their light lit.
So if the building burns down later this morning, you can blame me.
\1f
MOON@MIT-MC 05/14/81 16:30:32
To: RWK at MIT-MC
CC: EAK at MIT-MC, (BUG ITS) at MIT-MC
    Date: 13 May 1981 23:36-EDT
    From: Robert W. Kerns <RWK at MIT-MC>
    To: EAK at MIT-MC
    cc: BUG-ITS at MIT-MC, rich at MIT-AI

        Date: 13 May 1981 23:25-EDT
        From: Earl A. Killian <EAK at MIT-MC>
        To: RWK at MIT-MC
        
        Isn't it supposed to say PACK NOT MOUNTED instead of undefined
        device?

    It does for SECOND:, because knowledge of that pack was wired in before
    the more general scheme was adopted.
Not true.  SECOND is treated the same as the other named packs.

I have fixed the job device handler SYS:ATSIGN DEVICE to return pack
not mounted instead of no such device when an OPEN on a known disk
pack name gets to it.
\1f
Date: 14 May 1981 00:50-EDT
From: Robert W. Kerns <RWK at MIT-MC>
Subject: NO SUCH DEVICE
To: BUG-ITS at MIT-MC, BUG-MAIL at MIT-MC

Here's a good reason to know the names of all the disks even when not
online:

    COMSAT@MIT-AI 05/14/81 00:47:43 Re: Msg of Thursday, 14 May 1981 00:43-EDT
    To: RWK at MIT-MC
    FAILED: (FILE [THIRD:NIS;*SYS MAIL]) at MIT-AI; Couldn't write message to file;
            "THIRD:NIS;*SYS MAIL" - NO SUCH DEVICE
     Failed message follows:
    -------

\1f
Date: 13 May 1981 23:36-EDT
From: Robert W. Kerns <RWK at MIT-MC>
To: EAK at MIT-MC
cc: BUG-ITS at MIT-MC, rich at MIT-AI

    Date: 13 May 1981 23:25-EDT
    From: Earl A. Killian <EAK at MIT-MC>
    To: RWK at MIT-MC
    
    Isn't it supposed to say PACK NOT MOUNTED instead of undefined
    device?

It does for SECOND:, because knowledge of that pack was wired in before
the more general scheme was adopted.  THIRD:, FOURTH:, VISION:, etc. are
known from the name stored in the TUT on the disk, so ITS doesn't know
anything about the pack at all if it's not mounted.  Maybe this info
wants to be included in the CONFIG file as well.

\1f
Date: 13 May 1981 21:22-EDT
From: Robert W. Kerns <RWK at MIT-MC>
To: RICH at MIT-AI
cc: BUG-ITS at MIT-AI

    Date: 13 May 1981 17:37-EDT
    From: Charles Rich <RICH at MIT-AI>
    To: BUG-ITS at MIT-AI
    
    What happened to device THIRD:, it now says undefined device.
    Also I can't write to PK14: either now. (SECOND: still works).

If only you'd noticed the message when you logged in that the
disk drive was down....  I guess it would be a help if people
would also send a message to *AI when this happens, since it is
very easy to overlook SYSTEM MAIL when you log in.

\1f
Date: 13 May 1981 17:37-EDT
From: Charles Rich <RICH at MIT-AI>
To: BUG-ITS at MIT-AI

What happened to device THIRD:, it now says undefined device.
Also I can't write to PK14: either now. (SECOND: still works).
\1f
Date: 10 May 1981 03:55-EDT
From: Charles Frankston <CBF at MIT-MC>
Subject: [RGF: DM2500]
To: FJW at MIT-MC
cc: CBF at MIT-MC, BUG-ITS at MIT-MC, GZ at MIT-MC, MOON at MIT-MC,
    RGF at MIT-MC

    Date: 3 May 1981 00:12-EDT
    From: Frank J. Wancho <FJW at MIT-MC>
        RGF at MIT-MC

    Ok, I suppose the distinction is that since my DM3025A also responds
    to DM2500 codes and that I use :TCTYP DM SCROLL, everything works just
    fine for me.  But, when another tries to emulate a DM2500 and uses the
    same :TCTYP command (effectively), it doesn't scroll except when using
    CRTSTY???  -- I claim again that :TCTYP does it right and the
    documentation in KSC;DM2500 DOC must be either misleading or
    incomplete... or not properly implemented in RGF's emulation or some
    combination...

I explained the problem in detail.  The documentation in KSC;DM2500 DOC is
correct for a real Datamedia.  Your DM3025A does not work the same way.
You like the way it works better, great, tell your friend to make
his work that way.  I don't see what you expect us to do, go around the
country with a soldering iron fixing Datamedias?

\1f
DCP@MIT-MC 05/10/81 00:34:42
To: (BUG ITS) at MIT-MC
Is there a good reason why %PIATY (interrupt word 1, LH bit 4000)
is NOT documented in MC:.INFO.;ITS INTRUP. I think I understand
it well enough to document it, but I would prefer someone who
knows precisely what it does to document it. 

Also, what about all the other bits in the Left Half? Are they
real ntterupts, or just unused bits?

\1f
GJC@MIT-MC 05/09/81 17:23:52
To: (BUG ITS) at MIT-MC
CC: RWK at MIT-MC
I saw a GUMBY JOB.07 SYS with an MPV had been trying to read AR1:USERS2;ELDEFS
could be that his archive is messed up and he doesn't know it?


\1f
RWK@MIT-MC 05/08/81 02:50:56 Re: Recent problems with archives and EMACS libraries
To: (BUG ITS) at MIT-MC
CC: MMCM at MIT-MC, KRONJ at MIT-MC, KMP at MIT-MC, JPG at MIT-MC
CC: LPH at MIT-MC, GJC at MIT-MC, JGA at MIT-MC, ASB at MIT-MC
CC: SGR at MIT-MC, CFFK at MIT-MC, (*MSG *MC) at MIT-MC
These were due to the wrong port being enabled on the ARM-10 (the port
for the DL10 wasn't on).  This has been rectified.

This affected mapping of pages from THIRD: and FOURTH: into memory.  Read-only
pages were not damaged, read/write pages were written back as zero.

*  If you had EMACS libraries that stopped working, they should work now.
*  If you had a program residing on THIRD: or FOURTH: that stopped working,
   it should work now.
*  If you had an archive that stopped working, it is now unusable.  You should
   send a request to FILE-RETRIEVE requesting that it be recovered from tape.
   (Be sure to include the filename!).

We are sorry for any inconvenience.

\1f
Date: 8 May 1981 00:28-EDT
From: David Eppstein <KRONJ at MIT-MC>
To: BUG-ITS at MIT-MC

I have been getting a lot of "DEVICE FULL" errors lately when trying
to read files from archives.

\1f
RLB@MIT-MC 05/07/81 20:22:39
To: (BUG ITS) at MIT-MC
Supposing that the recent ARC device lossage had causes related to the
Emacs lossage KMP etc have noted, I copied DEVICE;DEVICE ARC to MC from AI.
Just before doing so, I $0L'd DEVICE;.FILE. (DIR) and after the copy I
$0Y'd it to DEVICE;.FILE? (DIR)
I don't want to risk trashing MY archives finding out whether the copy
fixed anything, though.

\1f
MMCM@MIT-MC 05/07/81 17:41:09 Re: more file lossage
To: (BUG ITS) at MIT-MC
My EMACS init file, which has not changed in about a year, got broken today.
I renamed the old one to MMCM;MMCM BROKEN, which still gets a LIB error when
you try to load it, and copied over one from AI, which now loads successfully.
The two files are identical, at least when you compare them they are.

\1f
LPH@MIT-MC 05/07/81 14:56:36
To: (BUG ITS) at MIT-MC
the archive device is rather messed up.
i get all sorts of trash appearing in the wasted words and in the number of
blocks in files. some of my archives get UNRECOGNIZABLE file errors when
i try to list them; though i can use emacs to visit the archive itself,
the individual files can't be listed correctly at ddt...
\1f
GJC@MIT-MC 05/07/81 10:14:30
To: (BUG ITS) at MIT-MC
The archive devices on MC are going down in flames the
last few days, resulting in files being forever locked, etc.

\1f
KMP@MIT-MC 05/06/81 23:42:47
To: (BUG ITS) at MIT-MC, ECC at MIT-AI
CC: EB at MIT-AI
Today I noticed several unusual effects which affected Emacs, but which I 
attribute to ITS or hardware lossage.

A dumped Emacs which I had and for which no files it depended on had changed
suddenly stopped working.

Doing M-X Load Library\eVT52\e loaded the SAFETY library for half the afternoon
in any version of Emacs. ECC and I both looked at this and were kinda confused.
:PRINT showed EMACS;VT52 \11:EJ was really not the SAFETY library, so something
was off.

Later I was going to show EB how M-X Load Library\eVT52\e was losing, but it said
that the file was not in library format. This is wierd because it had still not
been altered (since March, 1980).

I just renamed EMACS;VT52 \11:EJ to EMACS;VT52 O\11:EJ and copied in 
EMACS;VT52 \11:EJ and suddenly my dumped Emacs is working again.
M-X Load Library\eVT52\e\e is now working also. A binary comparison of these files
(I opened them in fixnum mode in lisp and did a word-by-word comparison) shows
that they are identical and doing M-X Load Library\eEMACS;VT52 O\11:EJ\e now wins.

I am wondering what kind of lossage could have caused this problem. Any
ideas? Maybe the directory was somehow inconsistent?

-kmp

\1f
Date: 3 May 1981 00:12-EDT
From: Frank J. Wancho <FJW at MIT-MC>
Subject:  [RGF: DM2500]
To: CBF at MIT-MC
cc: BUG-ITS at MIT-MC, FJW at MIT-MC, GZ at MIT-MC, MOON at MIT-MC,
    RGF at MIT-MC

Ok, I suppose the distinction is that since my DM3025A also responds
to DM2500 codes and that I use :TCTYP DM SCROLL, everything works just
fine for me.  But, when another tries to emulate a DM2500 and uses the
same :TCTYP command (effectively), it doesn't scroll except when using
CRTSTY???  -- I claim again that :TCTYP does it right and the
documentation in KSC;DM2500 DOC must be either misleading or
incomplete... or not properly implemented in RGF's emulation or some
combination...

--Frank

\1f
CBF@MIT-MC 05/02/81 20:34:46 Re: [RGF: DM2500]
To: MOON at MIT-MC
CC: FJW at MIT-MC, RGF at MIT-MC, (BUG ITS) at MIT-MC
CC: (BUG CRTSTY) at MIT-MC, GZ at MIT-MC
Unfortunately, a real Datamedia will very easily drop out of roll mode.
Exiting Insert/Delete mode (^X) will also exit roll mode.  On some
models apparently a Master Reset command (^_) will also exit roll mode.

In order to actually use Datamedia hardware scroll features it would be
necessary to always follow each of these commands with an enter roll mode.
This would probably work for TCTYP support.  The reason CRTSTY does not
use this method is because it allows the use of all 80 columns on the
terminal (if a terminal autowraps the way a Datamedia does, you cannot use
the last column with TCTYP support).  If the terminal were to operate in
roll mode all the time, but the ITS user had asked for wrap mode (the
default, as opposed to scroll mode), and were to output a character in the
last column of the last line, the terminal would auto-newline and scroll
irretrievably losing the top line of the screen before CRTSTY could do
anything to compensate.  In fact there would be no way CRTSTY could safely
put a character in that position, short of temporarily exiting roll mode.
I guess it seemed easier to implement scrolling with delete line.

\1f
MOON@MIT-MC 05/02/81 17:28:13 Re: [RGF: DM2500]
To: FJW at MIT-MC, RGF at MIT-MC
CC: (BUG ITS) at MIT-MC, (BUG CRTSTY) at MIT-MC, GZ at MIT-MC
I forgot to say in my previous message that by default ITS will never scroll
but will always wrap around at the bottom of the screen.  If you would prefer
scrolling say :TCTYP SCROLL and then output from most programs will be scrolled.
\1f
MOON@MIT-MC 05/02/81 17:26:44 Re: [RGF: DM2500]
To: FJW at MIT-MC, RGF at MIT-MC
CC: (BUG ITS) at MIT-MC, (BUG CRTSTY) at MIT-MC, GZ at MIT-MC
ITS sends ^M ^J ^W when it wants to go to the next line, which should
scroll if given on the bottom line.  Real datamedias ignore the ^J in this
circumstance, but ITS sends it anyway for the benefit of some simulated
datamedias.  ^W is erase-to-end-of-line of course.

Maybe CRTSTY doesn't send the ^J?

ITS assumes that roll mode is on and that you have set the line length short
enough that the hopeless auto-nl misfeature does not get invoked.  The :tctyp
command does both of these I believe.  You should not implement auto-nl and
not implement lack of roll mode.  What you should do is handle ^M by going
to start of same line, ^J by going down a line and scrolling if that would take
you off the bottom of the screen, both of these unconditionally.  That will
work with ITS but perhaps not with some other programs such as CRTSTY and
WAITS that claim to know about datamedias.  It will also work with TECO
on Tenex and TOPS-20.
\1f
Date: 1 May 1981 03:43-EDT
From: Robert W. Kerns <RWK at MIT-MC>
Subject: mail files
To: dp at MIT-ML
cc: RICHARDSON.ALYSON at MIT-MC, BUG-its at MIT-AI

    Date: 30 Apr 1981 2249-EDT
    From: ALA <METHODS-TOOLS at DEC-MARLBORO>
    To: bug-its at MIT-AI
    cc: richardson.alyson at KL2137
    Reply-to: dp at MIT-ML
    Subject: mail files
    Message-ID: <MS"5(1631)"11724421306.18.515.41914 at DEC-MARLBORO>
    
    My mail file on mit-ai (users0;ala mail) seems to be locked. Can
    someone look into this?
    
    Thanks.
    
            Alyson
            (ala@mit-ai)
       --------

This means one of two things.  One is that it may have already been
deleted, but not yet removed from the directory because someone is
reading it (such as RMAIL).  The other possibility, which isn't likely
in this case, is that the file is still being written, or is being
appended to.

\1f
Date: 1 May 1981 03:22-EDT
From: Frank J. Wancho <FJW at MIT-MC>
Subject:  [RGF: DM2500]
To: BUG-ITS at MIT-MC, BUG-CRTSTY at MIT-MC
cc: FJW at MIT-MC, RGF at MIT-MC, GZ at MIT-MC

Ron is using the documentation found in KSC;DM2500 DOC and GZ's DM2500
emulation code for use on a TRS-80 to emulate a DM2500 on his micro
and it seems that there is a difference in how a DM2500 is scrolled
using TCTYP vs CRTSTY.  (Now, I know there is, but my terminal
emulates a DM2500 too, and I don't use CRTSTY, and it scrolls alright
for me.)  Is there a difference between the description of a DM2500 in
that file and the ITS implementation as far as how scrolling is
handled?  The reason I ask is that I disagree with Ron and believe
that the way ITS does is right and CRTSTY does it awkwardly (nad takes
up an unnecessary job slot in the process.  --Frank
--------------------

Date: 05/01/81 01:34:12
From: RGF
Re:   DM2500

  Frank, I still have problems with the DM2500 when I'm not using
CRTSTY.  The only time I can get a screen scroll is when I'm in
CRTSTY, and it does a scroll by going to top line and issuing a
delete, then going back to bottom line.  Is it possible to have
the "natural" DM2500 (whatever *that* is) do this?
====================

\1f
Date: 30 Apr 1981 2249-EDT
From: ALA <METHODS-TOOLS at DEC-MARLBORO>
To: bug-its at MIT-AI
cc: richardson.alyson at KL2137
Reply-to: dp at MIT-ML
Subject: mail files
Message-ID: <MS"5(1631)"11724421306.18.515.41914 at DEC-MARLBORO>

My mail file on mit-ai (users0;ala mail) seems to be locked. Can
someone look into this?

Thanks.

        Alyson
        (ala@mit-ai)
   --------
\1f
Moon@MIT-MC 04/30/81 04:03:50 Re: THIRD; directory at AI
To: rich at MIT-AI
CC: RWK at MIT-MC, ZVONA at MIT-MC, (BUG ITS) at MIT-MC
Please choose a different name for this directory.  Having a device and a directory
with the same name confuses both people and some programs.
\1f
Date: 29 April 1981 22:43-EST
From: Robert W. Kerns <RWK at MIT-MC>
To: ZVONA at MIT-AI
cc: BUG-ITS at MIT-AI

    Date: 28 April 1981 20:50-EDT
    From: David Chapman <ZVONA at MIT-AI>
    To: BUG-ITS at MIT-AI
    
    there is a bogus directory third;.  i suppose it is bogus since there is no 
    second;.   It is empty.  also confusing.

I don't know who created this losing directory, but I will go upstairs and
try to find out, so I can explain to them why they should not do this.  On
the off chance that it was somebody on this mailing list with a momentary
brain fade, I remind you all once again that directories should not share
the same name as devices if you do not wish to confuse both programs and
people.  I have deleted the link which preserved the directory, so it will
go away the next time the system is brought up.

\1f
Date: 29 April 1981 19:14-EDT
From: Edward Barton <EB at MIT-AI>
To: BUG-ITS at MIT-AI

LNKEDP is in the SYSCTB table, but :CALL LNKEDP doesn't know about it.
\1f
GJC@MIT-MC 04/28/81 23:35:42
To: (BUG ITS) at MIT-MC
CC: RWK at MIT-MC
There is a job on MC uname 500A41 jname ARPA Sname 500A41 status +LOGIN
Chaos network connection to foreing addr PLASMA 15411 with flag F.
it has 15:25:08 (i.e. one hell of a shitload) of cpu time.
I'm just going to gun it as this seems to be a common and reported bug.


\1f
Date: 28 April 1981 20:50-EDT
From: David Chapman <ZVONA at MIT-AI>
To: BUG-ITS at MIT-AI

there is a bogus directory third;.  i suppose it is bogus since there is no 
second;.   It is empty.  also confusing.
\1f
Date: 20 April 1981 20:13-EST
From: David Eppstein <KRONJ at MIT-MC>
To: RWK at MIT-MC
cc: BUG-ITS at MIT-MC, KLOTZ at MIT-MC

        KRONJ@MIT-MC 04/19/81 05:25:08
        To: (BUG ITS) at MIT-MC
        Several problems:

        (2) If I do :COPY AR1:GUEST2;EINIT >,$ it shows the default file as
        AR1:GUEST2;EINIT 90 rather than >. (90 is the current version).  This
        is irritating for copying the file to another Fn1.  If I
        wanted 90 I would have said 90 and not >.

    This is a very useful feature.  It won't hurt you to type a space
    and a '>', and it makes possible retaining version numbers when
    moving files, something which is done very often.

I just found that out when copying my files to a new directory (I was
told my archive was probably at fault for not compacting rather than
ITS, so I got a new one.)

        (3) What happened to :TCTYP H19?

    How should I know?  You haven't said anything about what problem
    you experienced.

It was setting it to Glass,+/- a lot of things.  The problem has been
fixed.

\1f
Date: 20 April 1981 18:24-EST
From: Robert W. Kerns <RWK at MIT-MC>
To: KRONJ at MIT-MC
cc: BUG-ITS at MIT-MC, KLOTZ at MIT-MC

    KRONJ@MIT-MC 04/19/81 05:25:08
    To: (BUG ITS) at MIT-MC
    Several problems:
    
    (2) If I do :COPY AR1:GUEST2;EINIT >,$ it shows the default file as
        AR1:GUEST2;EINIT 90 rather than >. (90 is the current version).  This
        is irritating for copying the file to another Fn1.  If I wanted 90 I
        would have said 90 and not >.

This is a very useful feature.  It won't hurt you to type a space and a '>',
and it makes possible retaining version numbers when moving files, something
which is done very often.

    (3) What happened to :TCTYP H19?

How should I know?  You haven't said anything about what problem you
experienced.

\1f
Date: 20 April 1981 02:38-EST
From: David A. Moon <Moon at MIT-AI>
Subject: New system needed
To: BUG-ITS at MIT-AI

I turned on support for insert/delete characters on C100s in TCTYP.  Evidently
this was premature since the system installed on MC is too old to support it.
MC should get a new system ASAP (the source seems to be OK, it works on ML).
Other machines may need new systems, too.
\1f
KRONJ@MIT-MC 04/19/81 05:29:11
To: (BUG ITS) at MIT-MC
...to continue:
(3) What happened to :TCTYP H19?

Problems (1) and (2) combine nastily: I used to copy EINIT > (my largest file)
to a couple of other FN1s on the archive and then delete them to compact the
archive and save space.  Now it is not only harder to type the :COPY commands,
but the process as a whole instead of saving space leaves me with a huge
archive!  Please fix soon.

P.S. A command to compact archives so I wouldn't have to go through all that
trash would be v. useful.

\1f
KRONJ@MIT-MC 04/19/81 05:25:08
To: (BUG ITS) at MIT-MC
Several problems:

(1) If I delete a large file or two from an archive (say around four blocks)
    it used to compact the archive to 0 wasted words.  Now the wasted words
    just sit there and my archive gets larger and larger (unless this is some
    asynchronous process and by now it has been compacted).

(2) If I do :COPY AR1:GUEST2;EINIT >,$ it shows the default file as
    AR1:GUEST2;EINIT 90 rather than >. (90 is the current version).  This
    is irritating for copying the file to another Fn1.  If I wanted 90 I
    would have said 90 and not >.

(3) What happened to :TCTYP h
\1f
Date: 18 Apr 1981 0337-EST
From: CSTACY at MIT-DMS (Christopher C. Stacy)
To: BUG-its at MIT-DMS
Cc: bug-tctyp at MIT-MC
Subject: BUG => its
Message-id: <[MIT-DMS].194515>

On DM, doing :TCTYP H19
ERROR: CNSSET:  MEANINGLESS ARGS
270>>.CALL 3467 (CNSSET)


This wasnt broken 2 hours ago!


\1f
Date: 15 Apr 1981 1119-EST
From: WJN at MIT-DMS (Wayne J. Noss)
To: BUG-ITS at MIT-DMS
Subject: BUG => ITS
Message-id: <[MIT-DMS].194047>

     If I do AR4$^F just to look at an archive, the file author of the
AR4 file gets set to my hsname.
     I think that, to be meaningful, the author should not be set by
what is (should be) a read-only operation.
                                the WJN

\1f
Date: 13 Apr 1981 1631-PST
From: Mark Crispin <Admin.MRC at SU-SCORE>
Postal-Address: 12155 Edgecliff Place; Los Altos Hills, CA 94022
Stanford-Phone: (415) 497-1407
Subject: Re: My previous message about forced conversion to TCP
To: Moon at MIT-AI, PHW at MIT-AI, av at MIT-DMS, psz at MIT-ML, wam at MIT-ML,
    jm at MIT-MC
cc: (BUG ITS) at MIT-AI
In-Reply-To: Your message of 4-Apr-81 0039-PST

TOPS-20 does have a working TCP TELNET implementation.  I wrote it.

-- Mark --

PS: I agree with you that 1983 is premature for the changeover.
-------
\1f
MOON@MIT-MC 04/13/81 12:06:51 Re: MLDEV broken
To: (BUG ITS) at MIT-MC
Doing DELETE on ML: and AI: from AI seems to have started trying to do
the deletion twice, such that it hangs for a fairly long while then says
file not found.  I didn't try it on any file names with ">" or "<"
in them since that could be dangerous.  I haven't noticed this before today.
\1f
Date: 6 April 1981 23:35-EST
From: Robert W. Kerns <RWK at MIT-MC>
Subject: [GREN at MIT-MC: Forwarded]
To: BUG-ITS at MIT-MC

Date:  6 APR 1981 2304-EST
From: GREN at MIT-MC (Ian G. Macky)
To: (BUG DDT) at MIT-MC


:MOVEing from SYS***; does not make any sort of message on the console.
Was this omission on purpose?  From or to, that is.

----------------
It seems DELEWO doesn't check for being a system directory.

\1f
Date: 6 April 1981 10:51-EST
From: Robert W. Kerns <RWK at MIT-MC>
Subject: This is an ARPAnet problem, but is there any way which ITS can help it?
To: ELLEN at MIT-MC
cc: BUG-MAIL at MIT-MC, BUG-ITS at MIT-MC

    ELLEN@MIT-MC 03/24/81 18:08:46 Re: This is an ARPAnet problem, but is there any way which ITS can help it?
    To: (BUG MAIL) at MIT-MC, (BUG ITS) at MIT-MC
    MILNE@MIT-AI
    Howdy,
            One other
    thing from all of us over in Britian.I am not sure if this is the
    best mail box for this, but perhaps you can pass it on.
    Our link from edinburgh to MIT is very complex, going thourgh
    at least 5 machines before getting to MIT.
    This is then extremely unreliable. very often we get cut
    off by a failure over here, and can't get back to close
    our job. This is a British and ARPA problem,
    but results in us staying logged in when we don't exist.
    I talso seems that these crashes always take place just before
    I finish typing MAIL.
            What is the current thing to kill these jobs?
    Could it be clever and discover we were in MAIL and send the
    partial message for us, perhaps with a message added at the botto 
    bottom?
    Anyway, this is the basic problem, though I'd let you know.
    cheers, Rob Milne, Edinburgh


You should tell them about :REATTACH ... that's what it's for.
Gad, sending the message automagically would be gross.  If the
problem is that their network just crashes totally and they cannot
reconnect for a long period of time, they should be putting lots of
pressure on it's implements to either fix it or go work for the
post office (um, er, oh, so THAT'S the problem...)

\1f
MOON@MIT-MC 04/06/81 02:46:21 Re: Keeping track of system changes
To: (BUG ITS) at MIT-MC
Please log changes to ITS in the file MC:SYSTEM;ITS RECENT.
I have moved this file off of my personal directory.  Just a brief note
will suffice to help keep track of what's going on.  There is a ----
in the file at the point where new changes are supposed to be added.
After that point are a collection of mostly fairly random ideas
about things that could be changed in the future.

It hasn't been updated since Sep 20, 1980, so if you made any changes
worthy of note since then please put them in.

\1f
Date:  4 APR 1981 0406-EST
From: Moon at MIT-AI (David A. Moon)
To: RWK at MIT-MC
CC: (BUG LISPM) at MIT-AI, (BUG ITS) at MIT-AI

    Date: 30 March 1981 19:26-EST
    From: Robert W. Kerns <RWK at MIT-MC>
    Subject: Supdup typeout process
    To: MOON at MIT-MC
    ...    
    But the primary bug I was reporting was that typing
    control-greek-E blowing away the typeout process.
Fixed in the source of TS3TTY !!.  It was echoing as a garbage GT40 control command.
I am not going to fix the GT40 simulator, it would injure my stomach and throat.
\1f
Date:  4 APR 1981 0339-EST
From: Moon at MIT-AI (David A. Moon)
Subject: My previous message about forced conversion to TCP
To: PHW at MIT-AI, av at MIT-DMS, psz at MIT-ML, wam at MIT-ML
To: jm at MIT-MC
CC: (BUG ITS) at MIT-AI

Two or three people at other sites have communicated with me about this.
Apparently not even TOPS-20 actually has working TCP protocols (neither telnet,
nor FTP, nor mail).  The concensus seems to be that the change cannot possibly
happen on most sites by 1983, and hopefully the sites can convince the sponsors to
convince the network management accordingly.  We are not alone in not having
the manpower to make this sort of complex and unnecessary change, it would appear.
\1f
GJC@MIT-MC 04/03/81 17:23:08
To: (BUG ITS) at MIT-MC
CC: (BUG EMACS) at MIT-MC
Typing along in my EMACS, just got an ILLEGAL OPCODE message
and was detached. Very strange, maybe I was being hacked.
Everything working fine now.

\1f
GJC@MIT-MC 03/31/81 08:22:03
To: (BUG ITS) at MIT-MC
CC: GJC at MIT-MC
A job

542C54 CHAOS  54C54     +LOGIN  ?   2   0 55%  14:43:32

just used up 14 hours of MC cpu time doing absolutely nothing.
Maybe this is not a problem, I don't know.


\1f
Moon@MIT-MC 03/30/81 17:04:12 Re: > filename convention
To: WILL at MIT-AI
CC: (BUG ITS) at MIT-AI
    Date: 29 MAR 1981 2249-EST
    From: WILL at MIT-AI (William D Clinger)
    To: (BUG ITS) at MIT-AI
    
            "will;atolia >" refers to "will;atolia demo10" rather than to
    "will;atolia 41".  Is this as it should be?

Well, yes and no.  That's what the ">" convention is defined to do.
I would not care to defend that as the best choice among the possible
definitions of what it should do.
\1f
Moon@MIT-MC 03/30/81 17:01:21 Re: ITS Arpanet system maintenance
To: JM at MIT-MC, av at MIT-DMS, phw at MIT-AI, wam at MIT-ML
To: psz at MIT-ML
CC: (BUG ITS) at MIT-MC, ELLEN at MIT-MC
    ...
    Our next major netwide effort will be to cutover 
    all hosts to the new DOD Standard Protocols by 1 January of 1983.  This 
    is the cutoff date and it will be enforced.
    ...
    Maj. Joe Haughney
    DCA Code 531
    Defense Communications Agency

This is a non-trivial change.  If we are to do it, it will require
approximately one man-year of highly-skilled system programming,
possibly more, and it is unlikely that I will be available for this.  If
I were you, I would start communicating with the sponsors and inform
them that it will be impossible to meet this deadline without extra
funding to hire someone to do it.  I expect that most other hosts that
don't run TOPS-20/TENEX nor Multics are in the same boat.

By the way, unlike the 96-bit leader change which we did 2 or 3 years
ago, this change is of absolutely no benefit to us (unless it really is
enforced, in which case it "benefits" us by allowing us to continue to
use the Arpanet).  The DOD Standard protocols (Internet and TCP) provide
the same functionality as the existing protocols, except with the details
all changed around, and with some additional functionality for AUTODIN II
which is not of much interest to us.

\1f
KMP@MIT-MC (Sent by PIQUE@MIT-MC) 03/30/81 01:04:04 Re: Long input echo delays
To: (BUG ITS) at MIT-MC
I am coming in over a 300baud dialup and I have been experiencing long
echo delays intermittently. eg, in com links, where I assume I am talking
directly to the operating system, sometimes things will hang and then
I will get a burst of 80chars all at once after about a 5 second wait.
On a direct dialup this does not sound `normal', so in case it's a bug
that can be fixed, I figured I would mention it. -kmp

\1f
Date: 29 MAR 1981 2249-EST
From: WILL at MIT-AI (William D Clinger)
To: (BUG ITS) at MIT-AI

        "will;atolia >" refers to "will;atolia demo10" rather than to
"will;atolia 41".  Is this as it should be?
                                Peace, Will
\1f
Date: 26 MAR 1981 2139-EST
From: zemon at MIT-AI (Landon M. Dyer)
Sent-by: ___024 at MIT-AI
To: (BUG ITS) at MIT-AI

         I will be a good Luser and report a small bug I have seen :

        When I log on from NBS-TIP (MITER-TIP, PENT-TIP, etc etc.) the
following stragne thing happens.  ITS will print out the usualy warnings
about tourist usage during the daytime, then :

AI ITS.1197. PWORD.1733.
TTY 43
   /\
   ||
    \\===  ITS will 'hang' about here (the actual position varies
from login to login.)  Typing a space or ^Z will get ITS to continu
printing, though.

        This has been going on for at least a month, possibly two...


                                -Landon-
\1f
Date: 26 MAR 1981 1711-EST
From: RMS at MIT-AI (Richard M. Stallman)
To: GSB at MIT-AI, (BUG ITS) at MIT-AI

I think I have fixed the ECHOIN bug with a patch to make NECHOIN+12 or so
call TYIFL2 instead of UFLS.  TYIFL2 is a new tag which is TYIFLS plus a few.
Refer to the source.  I haven't tried this out.
\1f
ELLEN@MIT-MC 03/24/81 18:08:46 Re: This is an ARPAnet problem, but is there any way which ITS can help it?
To: (BUG MAIL) at MIT-MC, (BUG ITS) at MIT-MC
MILNE@MIT-AI
Howdy,
        One other
thing from all of us over in Britian.I am not sure if this is the
best mail box for this, but perhaps you can pass it on.
Our link from edinburgh to MIT is very complex, going thourgh
at least 5 machines before getting to MIT.
This is then extremely unreliable. very often we get cut
off by a failure over here, and can't get back to close
our job. This is a British and ARPA problem,
but results in us staying logged in when we don't exist.
I talso seems that these crashes always take place just before
I finish typing MAIL.
        What is the current thing to kill these jobs?
Could it be clever and discover we were in MAIL and send the
partial message for us, perhaps with a message added at the botto 
bottom?
Anyway, this is the basic problem, though I'd let you know.
cheers, Rob Milne, Edinburgh


\1f
GSB@MIT-ML 03/21/81 00:06:59 Re: echoin
To: (BUG ITS) at MIT-ML
It seems that ECHOIN does not cause the setting (or clearing or whatever)
of the flag which says that input has been waited for near the bottom
of the screen.  This causes my tty prescan to sometimes be very gross
by causing a --more-- when a character is typed when it is on the last
line of the screen.  I have temporarily patched this by fooling it to
not use echoin for the first character of its input, but a combination
of rubbing out and forced redisplay can make it happen still.

\1f
GJC@MIT-MC 03/20/81 19:05:21
To: (BUG ITS) at MIT-MC
The load on MC in terms of the number of users and the jobs
they are running had not been great for the last few hours.
20 users, fiar share = 67%, 5 macsymas, no TEX's or GLP's
or other core hoggers running. However, system response is
*BAD*, *REALLY* BAD. Long pauses whilegetting i/o in Peek,
echoing slow, you can type ahead maybe ten or so characters.
A rubout might take 3 seconds to happen.

\1f
MOON@MIT-MC 03/20/81 16:30:35 Re: BUG => ITS (net hangage on DM)
To: PDL at MIT-DMS
CC: (BUG ITS) at MIT-MC
I changed the network code around slightly in that system to make it
more robust to the hardware problems MC was having at the time
(which turned out to be a marginal optical isolator in the network
interface).  I don't know anything about the DM network interface,
which is different from all the others.  I thought you already had
a patch in to take out some of the change; did the patch get lost
or is it failing in the presence of the patch?

The changes to the code had to do with deciding when the net was up and
when it was down, and fixed problems where the system would crash if
it went up and down too rapidly.

Maybe you could look at a source compare of the old and new IMP and
SYSJOB files, and give a "second opinion"?
\1f
Date: 20 Mar 1981 1338-EST
From: PDL at MIT-DMS (P. David Lebling)
To: BUG-ITS at MIT-DMS
Subject: BUG => ITS
Message-id: <[MIT-DMS].190788>

Ever since we have been running ITS 1198 on DM, we have every so
often gotten into a state where after a crash the net will not
come up.  When it gets into this state the only way out is to
power cycle the net interface.  I suppose this sounds like a
hardware lossage, but as it started when we installed 1198, I
am suspicious.  Any chance someone knowledgeable could look at
this in the code?
        Dave


\1f
Date: 19 Mar 1981 at 0318-PST
From: Stuart Mclure Cracraft <mclure at SRI-UNIX>
To: bug-its at MC
Subject: roll mode
Sender: mclure at Sri-Unix

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.


\1f
Date: 18 Mar 1981 2041-EST
From: TAA at MIT-DMS (Timothy A. Anderson)
To: RWK at MIT-MC
Cc: (BUG ITS) at MIT-MC, PDL at MIT-MC
In-reply-to: Message of 18 Mar 81 at 2002 EST by RWK@MIT-MC
Message-id: <[MIT-DMS].190561>

If I say J$J, set .pagrange from DDT, then kill J, whoever gets
that job slot next will have .pagrange set (determined by saying
J$J quickly and getting the same job slot...).  This apparently
was the cause of the lossage with inqupd on DM, anyway.
        -taa


\1f
RWK@MIT-MC 03/18/81 20:02:33
To: (BUG ITS) at MIT-MC
CC: TAA at MIT-MC, PDL at MIT-MC
It looks like RMS patched INQUPD to do a .SUSET of .SPAGRANGE
Do you have any evidence other than INQUPD that .SPAGRANGE
isn't being cleared?  Note that in my INQUPD I have here,
.PAGAHEAD is zero, which should mean that the feature is
disabled.  A word search sdoesn't show any .SUSET for turning
it on.

What I see looks more like the standard lossage with the entry
for ______.  What I don't understand is how the current one
got in there.  It's the one introduced by OSI1P (now PST)
on the 7th of March.  I could have sworn I eliminated that
one when it caused the database to lose before.

\1f
Date: 18 Mar 1981 1943-EST
From: TAA at MIT-DMS (Timothy A. Anderson)
To: BUG-its at MIT-DMS
Subject: BUG => its
Message-id: <[MIT-DMS].190555>

In ITS 1198 (on DM), and ITS 1207 (MC), .pagahd and .pagrange have the
amusing property that they are not reset by killing the job they are set
in.  Thus, if I get job 3, set those variables, and kill it, whoever
gets job 3 next will end up with them set.
The bug PDL reported about the death of inqupd on DM seems to be related
to its use of page-ahead:  when we patched out all the appropriate
susets, it ran to completion.  RWK, could this be the cause of your
problems with it on MC?
DM has been exhibiting rather entertaining behavior with respect to the
NSWPGS user variable:  jobs with page-ahead set (due to the leftover
.pagahd and .pagrange from old inqupds) get negative nswpgs with
high frequency.  We've also been observing reasonably random behavior
in certain jobs, perhaps caused by their pages being swapped in at
the wrong place?
        -taa

\1f
Date: 18 Mar 1981 1016-EST
From: PDL at MIT-DMS (P. David Lebling)
To: BUG-ITS at MIT-MC
Subject: Interesting statistics
Message-id: <[MIT-DMS].190487>

PEEKing at a freshly minted INQUPD on DM produces:

DM ITS 1198  Peek 463   03/18/81  09:52:16  Up time = 12:53:26
Memory: Free=26  Runnable Total=182 Out=-91  Users: High=23 Runnable=5
Index Uname Jname Sname     Status   TTY    Core Out %Time    Time PIs
 21 INQUPD INQUPD INQUIR     PAGE    ?       163 -91  11%       11  
Fair Share 35%     Totals:                   163      11%       11
Logout time = 1:26:42 Lost 32%  Idle 0%  Null time = 9:44:28

 Ch Idx Uname  Jname Mode Bks+Wds   Rd%  Pk  File Name
 12  21 INQUPD INQUPD RI    0+0      0%  19  INQUIR; LSR1 LOCK

I watched it get up to 168 in and -238 out before it quit.
        Dave



\1f
CBF@MIT-MC 03/15/81 20:53:32 Re: TS3TTY 281, H19 padding & C100 char insert/delete
To: MOON at MIT-MC
CC: CBF at MIT-MC, (BUG ITS) at MIT-MC
    MOON@MIT-MC 03/15/81 20:23:08 Re: TS3TTY 281, H19 padding & C100 char insert/delete
    You probably didn't read the comments, since RWK changed the padding
    units to be of 1/8's of milliseconds rather than milliseconds in the
    case of Y-position dependent padding.

Nah, RWK didn't do that, I did, and took it into account in the 5ms figure.

\1f
Date: 15 March 1981 21:08-EST
From: Robert W. Kerns <RWK at MIT-MC>
Subject: TS3TTY 281, H19 padding & C100 char insert/delete
To: MOON at MIT-MC
cc: CBF at MIT-MC, BUG-ITS at MIT-MC

    MOON@MIT-MC 03/15/81 20:23:08 Re: TS3TTY 281, H19 padding & C100 char insert/delete
    To: CBF at MIT-MC
    CC: (BUG ITS) at MIT-MC
    You probably didn't read the comments, since RWK changed the padding
    units to be of 1/8's of milliseconds rather than milliseconds in the
    case of Y-position dependent padding.

I didn't do this.  I thought CBF must have done it.  It was done before
I hacked this.

\1f
Date: 15 Mar 1981 (Sunday) 2100-EDT
From: SHRAGE at WHARTON-10 ( Jeffrey Shrager)
Subject: Typing a ":"
To:   bug-its at MIT-AI

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

\1f
MOON@MIT-MC 03/15/81 20:23:08 Re: TS3TTY 281, H19 padding & C100 char insert/delete
To: CBF at MIT-MC
CC: (BUG ITS) at MIT-MC
You probably didn't read the comments, since RWK changed the padding
units to be of 1/8's of milliseconds rather than milliseconds in the
case of Y-position dependent padding.
\1f
CBF@MIT-MC 03/15/81 05:46:47 Re: TS3TTY 281, H19 padding & C100 char insert/delete
To: (BUG ITS) at MIT-MC
In response to RWK's testing of the H19 line insert/delete padding, I have
raised it a little bit in the source.  I probably rounded down where I
should have rounded up in calculating it.  I went to patch it in the running
system on MC, and found a highly ridiculous value of 5 ms of padding per line
moved there.  (I am raising the value from .625 ms per line moved to .75).
Please tell me that this 5ms value is totally random.  If its true, it is not
consistent with other programs which use 18 ms net for each line isnet/delete
done.  I have left the 5ms figure pending clarification.

In the grand tradition of TS3TTY kludges, I have put entries for char
insert/delete in for the C100.  In order to put the the null needed to exit
char insert in the ASCIZ string, I have resorted to 8 bit characters and
used a 200.  As best as I can tell this will be loaded as 8 bits and
deposited as 7 on a Morton and then be caught at the apropriate level
and turned into the kludge thats needed to get a null out on a Morton.
However, if I'm wrong there are two other possible results:
  1) Use of char insert on a C100 on a Morton will result in never
     exiting char insert mode.  This would probably result in rather
     random screen lossage.
  2) It will crash ML? (Does DM have Morton also?)

Whoever brings up the next ITS on these machines should probably test
this immediately to make sure option 2 does not result.  Note that %TOCID
will not be turned on by default for :TCTYP C100 since char insert/delete
only works on new microcode C100s.  If you have an old microcode C100 you
should mail someone like me a set of 4 or 5 2716s depending on whether
you also want a Sail character Prom for the 2nd charset slot.

\1f
moon@MIT-MC (Sent by ___165@MIT-MC) 03/11/81 23:43:18
To: (BUG ITS) at MIT-MC
How come When the GLP spooler wires down its pages in the I/O portion of memory,
they don't get shuffled into high memory?  I thought there was code  for this.  This caused MC
to deadlock.  Maybe there is too much high memory available and it didn't try to swap it out?

\1f
Date: 11 MAR 1981 0728-EST
From: RWK at MIT-AI (Robert W. Kerns)
Subject: LNKEDP
To: (BUG ITS) at MIT-AI

Oh, it's just the entry in SYSCTD not indicating the need to
decode the channel argument.  I'll fix it when MC comes back
up again.
\1f
RWK@MIT-MC 03/11/81 07:08:07
To: (BUG ITS) at MIT-MC
I've just brought up the new ITS on MC.  It seems to be
OK except for a few minor problems:

The padding on H19's for I/D line doesn't seem to work
right in some circumstances.  I'm not sure what's going
on, but it fails whenever EMACS recomputes the window,
resulting in ^S^Q lossage.  But it always seems to work
when I Insert or delete any number of lines manually.

The LNKEDP system call always gives WRONG TYPE DEVICE.
It's not immediately obvious to me just why, from
looking at the source.  (BTW, this was put in the
wrong place, effectivly removing the LOAD system
call by screwing the binary search).  Anyway,
MC is about to go down for PM, so I'll leave this
for later.  As near as I can tell, page-ahead is
winning, or at least isn't causing the system to
lose.  But I haven't tried it on a very loaded system
yet.

\1f
Date: 10 MAR 1981 1911-EST
From: RLB at MIT-MC (Richard L. Bryan)
To: EBM at MIT-MC, MT at MIT-MC
CC: (BUG ITS) at MIT-MC

    GJC@MIT-MC 03/10/81 18:02:59
    On MC now we are getting jobs like 66 420C66 CHAOS DVR +LOGIN?
    which are continuously running and have 3:43:20 cpu time
    on them.


They are trying to log in when already logged in.
The login fails ("CAN'T MODIFY JOB"), the uname is incremented,
and the login is retried. 

\1f
GJC@MIT-MC 03/10/81 18:22:26 Re: last bug note about jobs with unusally long running times.
To: (BUG ITS) at MIT-MC
gosh, I didn't think about the fact that MC has been up
for ten days. 
\1f
GJC@MIT-MC 03/10/81 18:02:59
To: (BUG ITS) at MIT-MC
On MC now we are getting jobs like 66 420C66 CHAOS DVR +LOGIN?
which are continuously running and have 3:43:20 cpu time
on them.

\1f
Date:  7 MAR 1981 1001-EST
From: KLOTZ at MIT-AI (Leigh L. Klotz)
To: (BUG ITS) at MIT-AI

I got a non-rec data err on .teco.;tecord > and just then got
one on .tape5;tape 2626. 

I had gotten one on tecord a week ago but not one since.

Should I get tecord off backup tape?
Leigh.
\1f
Moon@MIT-MC (Sent by ALAN@MIT-MC) 03/06/81 04:38:29
To: (BUG ITS) at MIT-MC
I wonder how come TYONRM+2 got decremented or else got bit 35 turned off?
\1f
Date:  4 MAR 1981 1529-EST
From: KLOTZ at MIT-AI (Leigh L. Klotz)
To: (BUG ITS) at MIT-AI

For at least the past couple of weeks I've been getting random
beeps. (Usually in emacs, but probably because I've spent most
of my time there; it happened last night in maclisp.)
They seem to be cli interrupts, as when I ^Z out of the job it happens
again. But, I have no sends and :ddtsym cliunm is 0. (Should I be
looking at a similar location in emacs?)
It flashes once. I have ..belcnt/1, if that matters.
Leigh.
\1f
Date: 2 March 1981 03:12-EST
From: Ed Schwalenberg <ED at MIT-AI>
Subject: Blast from the past
To: PGS at MIT-AI
cc: BUG-ITS at MIT-AI

Many and many a year ago, in a kingdom by the sea, I complained
of this, and it was said, "If you don't like it, you fix it."
So I fixed the archive device handler to return PNM if that was
the problem.  Unfortunately, the source to which I did this
was not in sync with the working binary, and my "fix" broke other
things.  The archive device has only recently recovered from this
long history of lossage.  This time, however, I am going to leave
it alone.
\1f
Date:  1 MAR 1981 2014-EST
From: PGS at MIT-AI (Patrick G. Sobalvarro)
To: (BUG ITS) at MIT-AI

When the pack that an archive resides on is not mounted, and one
attempts to list the archive, the losing error message,
"DSK:AR1;.FILE. (DIR) - NON-EXISTENT DIRECTORY" is printed, and one's
working directory is changed to AR1;. Something more reasonable, like
"PACK NOT MOUNTED" might be more of a win.
\1f
Date: 26 February 1981 03:36-EST
From: Charles Frankston <CBF at MIT-MC>
Subject: H19's on ITS
To: EBM at MIT-XX
cc: BUG-its at MIT-AI

    Date: 25 Feb 1981 2031-EST
    From: EBM at MIT-XX

    :TCTYP H19 would actually be useful if ITS would pad the ins/del line
    sequences.  Our experience indicates that 17ms. per line
    inserted/deleted is required at 9600 baud, and no padding is needed at
    1200 and lower.  We just pad proportionately in between.  (I.e., 4800
    baud => 8.5ms pad, etc.)  I don't think this will screw anybody very
    much, and would certainly please H19 users, though having ins/del char
    would be nice, too.  Getting that would require adding a terminal type,
    though (sigh).  Anyway, is anybody out there willing the hack TS3TTY to
    put in the padding?

You message makes no sense, but I implemented it anyway.  I don't think
the H19 is 17ms PER line inserted or deleted, and I don't see why it only
takes 8.5ms if the UART is running at 4800 baud.  I implemented a padding
of .625 ms per line moved at speeds higher than 1200 baud, and no padidng
at 1200 baud.  This is only in the source of course, some poor sucker
who brings up the next ITS will have to debug it.

\1f
Date: 25 Feb 1981 2031-EST
From: EBM at MIT-XX
Subject: H19's on ITS
To: bug-its at ai

:TCTYP H19 would actually be useful if ITS would pad the ins/del line
sequences.  Our experience indicates that 17ms. per line
inserted/deleted is required at 9600 baud, and no padding is needed at
1200 and lower.  We just pad proportionately in between.  (I.e., 4800
baud => 8.5ms pad, etc.)  I don't think this will screw anybody very
much, and would certainly please H19 users, though having ins/del char
would be nice, too.  Getting that would require adding a terminal type,
though (sigh).  Anyway, is anybody out there willing the hack TS3TTY to
put in the padding?

-------
\1f
JLK@MIT-MC 02/23/81 19:02:52 Re: MUX, ITS, and Tektronix wierdness
To: (BUG ITS) at MIT-MC
CC: RCE at MIT-MC
After painstaking investigations, I have determined that ITS does some very wierd
things on Chaos Supdup connections with a TCTYP of %TNTEK.  There seems to be a bug
where it ends up throwing away 2 packets completely.  The only thing I change in
my icp packet is the tctyp field (to say, teleray or somesuch) and it works fine.
This is repeatable.  Nothing in my software depends on the tctyp.  The observed
wedged state is that 2 packets are missing and ITS refuses to resend them,
even though ITS agrees that they have not been acknowledged.  Its hard for
me to see how this dependency could exist (output reset wierdness maybe?)

\1f
Date: 23 FEB 1981 1138-EST
From: SLH at MIT-AI (Stephen L. Hain)
To: (BUG ITS) at MIT-AI

Apparently a disk error has trashed my mail file, on ty's directory
Laurel
\1f
RWK@MIT-MC 02/19/81 13:11:04
To: CSTACY at MIT-MC
CC: (BUG ITS) at MIT-MC
The IMP seems to be having troubles.

\1f
Date: 19 FEB 1981 1259-EST
From: CSTACY at MIT-AI (Christopher C. Stacy)
To: (BUG ITS) at MIT-AI

This is really weird; I must be overlooking something simple.

When I connect to any ITS from DCECTIP or PENTIP (which are the
only ones I tried), funny things happen to my connection.
These funny things are consistant, and do not happen when I
use this same terminal/modem (300bd,btw) on non-net systems,
or on a Unix I tried which is on the net. These funny things
also do not happen on an AI Dialup.

The funny things:  the system pases in the middle of the SSTATUS
and hangs for a few secs, sometimes I have to control-G out to
pword toplevel.

Various characters are received and echoed wrong. When I first
saw this I thought that my terminal or modem was dropping bits,
but it is now clear that the problem only occurs connecting to
an ITS over a TIP.  To wit,
s := ^S
n := ^N  but N:=N
a := ^A
space := nothing? (sounds like its xmitting it, but no echo)
atsign := same as space


I cant imagine whats wrong.  Help?

Thanks,
Chris
\1f
Date: 16 FEB 1981 1924-EST
From: EB at MIT-AI (Edward Barton)
Subject: ai paper tape punch
To: (BUG ITS) at MIT-AI
CC: CENT at MIT-AI

    MSG: DEAD   PUNCH 
    the ai papertape punch, hasn't
    worked in years and has miniscule to disappearing chance of
    ever being repaired.
If the punch is really permanently losing, OPENs on PTP: should be made
to fail with some appropriate error code.
\1f
Date: 14 FEB 1981 2128-EST
From: RWK at MIT-AI (Robert W. Kerns)
Subject: File clobberage
To: (BUG MAIL) at MIT-AI
CC: (BUG ITS) at MIT-AI

Page 0 of AI:.MAIL.;^Q ^Q LIST ^Q QUEUE was bashed with random
mail (what looked like a random mail file).  I renamed the
file .MAIL.;  LIST CLOBRD, and copied the old set of (MSGS REMIND
MASTER) to .SAVE *, and did a MAKQFI.  It seems to be working
OK now.
\1f
ED@MIT-ML 02/12/81 04:09:36 Re: Index to History
To: (BUG ITS) at MIT-ML
Those of you who want to experience the old days might wish to run
ML:SYS;TS MONIT, which for some reason does not have symbols nor the
correct start address (1300).  It is pretty badly broken, but great fun
to play with nevertheless.  Too bad we don't have any working
microtapes to really hack it with.
\1f
Date: 12 FEB 1981 0235-EST
From: MOON5 at MIT-AI (David A. Moon)
To: (BUG ITS) at MIT-AI

I would kind of like to know why single pages of the inquir data base
have been clobbered to what looks like pages out of other files three times in
the last two days, on AI.  I don't think anyone maps it in read-write, so
it's hard to see how to blame it on Howard's memory.  Anyone have any ideas?
Anyone observe any other file clobbering problems?
\1f
Date:  8 FEB 1981 2226-EST
From: MOON at MIT-AI (David A. Moon)
To: (BUG ITS) at MIT-AI

I tried to take AI down using the DOWN/KILL command in LOCK so that I could
bring back a fixed disk.  The command fails to do anything, it just gives an _ prompt.
\1f
Date: 8 February 1981 09:26-EST
From: Robert W. Kerns <RWK at MIT-MC>
To: KMP at MIT-MC
cc: BUG-ITS at MIT-MC

    KMP@MIT-MC 02/07/81 05:20:27
    To: (BUG ITS) at MIT-MC
    MC has been randomly resetting its arpa connections this evening. I don't
    know why. I didn't notice anyone running LOCK. I guess it does it on its
    own sometimes. Usually the net goes off, on, off then there's a bit of a 
    gap (as much as a minute or two) and then back on again...


There was a system message a while back informing everyone that the TIP and
IMP were being moved.  Perhaps this is what was doing it?

\1f
Date:  8 FEB 1981 0352-EST
From: MP at MIT-AI (Mark A. Plotnick)
Subject: long leaders
To: (BUG ITS) at MIT-AI

I just tried to get onto ML from a TIP.  It wouldn't connect
me, saying that the Host didn't support extended leaders.
Is this something new?  I thought extended leaders were required
since Jan. 1.
\1f
Date:  7 FEB 1981 1227-EST
From: JONL at MIT-AI (Jon L White)
Subject: Crunch on AI:SYS;, part II
To: (BUG ITS) at MIT-AI

ITSDFS 4 ==> SYSENG;
SAIDFS 17 ==> SYSENG'
Both are "old" files.  current versions still on SYS;
\1f
Date:  7 FEB 1981 1224-EST
From: JONL at MIT-AI (Jon L White)
Subject: Directory space crunch on AI:SYS;
To: (BUG ITS) at MIT-AI, RWK at MIT-MC

I moved ATSIGN ODEVIC and ATSIGN OHACTR to SYSBIN;, since
one hadn't been referenced in over 2 years, and the other
in almost a year. 
\1f
KMP@MIT-MC 02/07/81 05:20:27
To: (BUG ITS) at MIT-MC
MC has been randomly resetting its arpa connections this evening. I don't
know why. I didn't notice anyone running LOCK. I guess it does it on its
own sometimes. Usually the net goes off, on, off then there's a bit of a 
gap (as much as a minute or two) and then back on again...

\1f
Date: 7 February 1981 05:05-EST
From: Charles Frankston <CBF at MIT-MC>
Subject: confused about char ins/del
To: BUG-ITS at MIT-MC
cc: HAL at MIT-MC, C100-FANS at MIT-MC, Craig Everhart at CMU-10A

    Date: 7 February 1981 00:52-EST
    From: Earl A. Killian <EAK at MIT-MC>

    The C100 would probably work fairly well on ITS without using
    CRTSTY, just as it does on XX.  This is to say that while it is
    completely trivial to construct legitimate sequences of requests
    to the virtual terminal support that will lose, those sequences
    don't tend to come up while editing in EMACS.  With CRTSTY,
    however, it is extremely common for CRTSTY to produce such
    sequences as the result of other unrelated optimizations that it
    is doing.  As a result CRTSTY definitely cannot use insert/delete
    character unless your terminal supports the set blank
    characteristics and set insert mode commands.  On ITS it's not so
    clear, but I think having the default be off is still the right
    thing; users with the proper microcode or bravery can always try
    :TCTYP +%TOCID (I hope this works).

:TCTYP +%TOCID does not work, in the sense that ITS has no entries for
char ins/del on a C100 whether on by default or not.  I was going to
put entries in, but unfortunately, the C100 uses Escape-Null to exit
insert mode.  I can't put the null in an ASCIZ string which is what
the table entries consist of, and I don't know TS3TTY well enough
to figure out a good kludge..

\1f
Date:  7 FEB 1981 0435-EST
From: CBF at MIT-MC (Charles Frankston)
Subject: TS3TTY terminal padding
To: (BUG ITS) at MIT-MC, (BUG TERMINALS) at MIT-MC

Remember the feature to vary a terminal's line insert/delete padding in
proportion to the number of lines left to be moved on the screen?  Anyway,
it was never exercised in any terminal defintions.  EAK and I tried
patching the entry for a C100 with PADCR=1 on ML and found it seems to
work fine.  However, when calculating the values for a 1200 baud C100 or
for a Teleray 1061, we find that they would really want to be 1.7 and 2.5
milliseconds respectively.  Rounding 2.5 ms up to 3 ms makes a difference
of 12 ms (* 10 lines moved can get annoying).  Therefore in the fine
tradition of TS3TTY kludges, if the table entry is negative (which used to
mean the value given is milliseconds per line to be moved), then it is the
number of 1/8 milliseconds per line to be moved.

This is MC:SYSTEM;TS3TTY 271, I have updated the terminal entries for the
C100 and Teleray.  Good luck to the next ITS debugger, why am I so
verbose?

\1f
HIC@MIT-MC 02/04/81 17:55:35
To: (BUG ITS) at MIT-MC
Oh well, I was confused...iot looks like some subtle off by a few error when the MMP
almost gets full.

\1f
HIC@MIT-MC 02/04/81 17:52:07
To: (BUG ITS) at MIT-MC
MC just tried to make an extra MMP page (one more than allowed).  MEMFR was 7.
Is someone forgetting to decrement this guy?

\1f
Date: 4 February 1981 05:01-EST
From: Robert W. Kerns <RWK at MIT-MC>
To: ED at MIT-AI
cc: GNU at MIT-AI, BUG-ITS at MIT-AI

    Date: 2 February 1981 21:59-EST
    From: Ed Schwalenberg <ED at MIT-AI>
    To: GNU at MIT-AI
    cc: BUG-ITS at MIT-AI
    
        What is the effect of linking to a free STY (i.e. Finger shows it as
        "STY not in use")?  I saw someone doing it earlier tonight and wondered.
    It depends on the state of the STY.  If you just link to an unused sty,
    you get a ?, since the tty you want to link to does not exist.  What
    must have happened is that the sty became unused after the link existed,
    as for instance if someone logs out from a sty and you link to him just
    before or after the logout (but before the net connection is closed.
    I believe that the system doesn't really do anything with stys whose
    only activity is a link, and they will vanish, breaking the link.
Actually, this isn't right at all.  You can link to a free sty, and
slave it, etc.  The fact that you have done so is recorded.  It doesn't
work very well, tho, since there isn't anybody on the other end of the
STY to gobble up it's output, so it quicly fills up it's output buffer
and can't print anything more.  FINGER's 'Sty not in use' merely means
that it is unowned.

\1f
Date:  3 FEB 1981 0302-EST
From: CENT at MIT-AI (Pandora B. Berman)
Subject: bitten again
To: (BUG MAIL) at MIT-AI, (BUG ITS) at MIT-AI

comsat decided to take another walk over my mail file. today i logged in
and typed :rmail, and found myself looking at a message sent to alan and
bee. neither of whom i am. this was somewhat disconcerting, so i quit out
of the rmail and poked around a bit. by now the rmail had obligingly 
copied the contents of my mail file into my rmail file and had deleted the
mail file, so there was no way of finding out information about it. i have
copied the entire bunch of new mail (everything before the first message
that i know i have seen in rmail before; i use r-option append and gmsgs
so the break was pretty clearly after the newest system msg) to the file 
ai:vsdb;foo2 mail. i also looked at this stuff: i am sure that the first 
seven msgs are not for me, and that the eighth (which starts with gubbish
and turns into a news digest) probably is. evidence of when i was last seen
by the system is a file i wrote the last time i was logged in (i know i 
read my mail that time); the file was written at 03:38 on 2/1, and i logged
out within a few hours of that. the time of the first msg that is probably
mine AND has a readable time is 13:35 on 2/1. this is the ninth msg in
foo2 mail; the eighth msg (the news digest with gubbish at the front) does
not have a readable time. the news digest canonically comes out at 10:00
PST which means 13:00 EST, but the ostats file has been written to disk 15
(third:) which is currently unaccesssible due to dead disk drive, so i 
can't tell exactly when it came out on sunday or what msgs i got earlier 
that morning. however, given the several hours between these times, i think 
that comsat (or something) walked over the first several msgs sent to me
sunday morning and replaced them with the random stuff that is now the 
first seven msgs in foo2 mail.
dave moon says that since i logged out sunday morning ai has had problems
(disk drive losing causing locked blocks all over, and hic's memory losing
in some way (he wasn't sure of the details when he mentioned this) causing
programs to act in very random ways) either of which could have caused
the lossage i experienced here.
i guess i will have to wait until the third: pack comes back online before
i can see what i missed; i may not be able to get the stuff i lost back
because of the time delay here.
\1f
Date: 2 February 1981 21:59-EST
From: Ed Schwalenberg <ED at MIT-AI>
To: GNU at MIT-AI
cc: BUG-ITS at MIT-AI

    What is the effect of linking to a free STY (i.e. Finger shows it as
    "STY not in use")?  I saw someone doing it earlier tonight and wondered.
It depends on the state of the STY.  If you just link to an unused sty,
you get a ?, since the tty you want to link to does not exist.  What
must have happened is that the sty became unused after the link existed,
as for instance if someone logs out from a sty and you link to him just
before or after the logout (but before the net connection is closed.
I believe that the system doesn't really do anything with stys whose
only activity is a link, and they will vanish, breaking the link.
\1f
Date:  2 FEB 1981 0401-EST
From: GNU at MIT-AI (John C. Gilmore)
To: (BUG ITS) at MIT-AI

What is the effect of linking to a free STY (i.e. Finger shows it as
"STY not in use")?  I saw someone doing it earlier tonight and wondered.
\1f
Date: 29 January 1981 18:44-EST
From: Earl A. Killian <EAK at MIT-MC>
Subject:  Page ahead
To: Guy.Steele at CMU-10A
cc: BUG-its at MIT-AI, klh at MIT-AI

Actually the documentation only existed on AI, not on the other
machines.  I've installed it elsewhere.

\1f
Date: 29 January 1981 1658-EST (Thursday)
From: Guy.Steele at CMU-10A
To: klh at MIT-AI
Subject:  Page ahead
CC: bug-its at MIT-AI
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
\1f
Date: 29 JAN 1981 1612-EST
From: KLH at MIT-AI (Ken Harrenstien)
Subject: page ahead
To: (BUG ITS) at MIT-AI

Did I miss something?  I have no idea what people are talking
about with respect to "page ahead".  Is that something like
disk file read-ahead in that if you reference a page, the next
sequential page is also swapped in?
\1f
Date: 29 January 1981 02:43-EST
From: Earl A. Killian <EAK at MIT-MC>
To: RMS at MIT-AI
cc: BUG-ITS at MIT-AI

When you first started hacking page ahead code in TECO/ITS I did
a quick calculation that showed that it would be a noticable
improvement on AI, but not so noticable on MC, because MC can
search a page faster.  I was moderately surprized at that result.
Anyway, glad to hear it really wins.  Of course, HIC's new memory
may help a lot too...

\1f
Date: 28 JAN 1981 2159-EST
From: RMS at MIT-AI (Richard M. Stallman)
To: (BUG ITS) at MIT-AI

Page ahead is a big improvement!
On a lightely loaded system, moving the gap in TECO
is about twice as fast.
When there gets to be more load, it slows down, but the
TECO, which was 165k with one 100k file, never even had
50 pages in at any time during moving the buffer from one
end to the other.
\1f
Date: 28 JAN 1981 0634-EST
From: RMS at MIT-AI (Richard M. Stallman)
To: SPC at MIT-AI, CENT at MIT-AI, RWK at MIT-MC
CC: (BUG ITS) at MIT-AI

When SPC told me he was working on a :S program,
I told him that there was already a :S.
But then I looked for it and didn't find any.
So I figured that the link had got lost somehow
and nobody had missed it, so I told SPC it was ok
to put in a new one.

I don't know when or how the old :S went away.
CENT, do you remember when you last used it?
I used to use it but got out of the habit a long time ago.
\1f
Date: 28 January 1981 05:49-EST
From: Robert W. Kerns <RWK at MIT-MC>
To: SPC at MIT-MC, CENT at MIT-AI
cc: RMS at MIT-AI, BUG-ITS at MIT-AI, BUG-DDT at MIT-AI

    Date: 27 January 1981 23:24-EST
    From: Pandora B. Berman <CENT at MIT-AI>
    To: RMS at MIT-AI
    cc: BUG-ITS at MIT-AI, BUG-DDT at MIT-AI
    
    what did you do to :s? when i tried to use it to send a msg to
    more than one person (using :s because :send only takes one
    recipient) it kept saying No message? :KILL

    This is most frustrating; a standard thing like this should not
    change so suddenly/incompatibly/without warning so that when a
    user expects it to act as it always has, it breaks incomprehensibly
    instead. please explain and fix.

This was not RMS, this was SPC.  I have deleted the offending program
and restored the link to QSEND.  *** SPC DO NOT DO THIS! ***.  Replacing
public programs with your own version is not at all polite.  If this
happened because you did not look before you put it on SYS3;, you should
be aware that you *MUST* check for the name being in use on any of
SYS, SYS1, SYS2, and SYS3.  Please excersize more restraint and caution
in the future.

\1f
Date: 27 JAN 1981 2324-EST
From: CENT at MIT-AI (Pandora B. Berman)
To: RMS at MIT-AI
CC: (BUG ITS) at MIT-AI, (BUG DDT) at MIT-AI

what did you do to :s? when i tried to use it to send a msg to more than one
person (using :s because :send only takes one recipient) it kept saying
No message? :KILL
this is most frustrating; a standard thing like this should not change so
suddenly/incompatibly/without warning so that when a user expects it to act
as it always has, it breaks incomprehensibly instead. please explain and fix.
\1f
Date: 27 JAN 1981 2020-EST
From: EB at MIT-AI (Edward Barton)
Subject: SAUTH bug
To: INFO-MLDEV at MIT-AI
CC: EB at MIT-AI

I have been playing around with MLDEV for a while, trying to figure
out why it so often hangs up while the DDT :COPY command is trying to
do a SAUTH call.  If anyone thinks the following fix is wrong, please
explain and delete it.  If anyone knowledgeable thinks it is right,
please assemble and install it.  It seems not to hang, and to
otherwise work, in my tests.

AI   SYSENG
FREE BLOCKS #1=91 #2=53 #14=116 #4=78 #5=101 #13=355 #15=298 #3=95 
  2   MLDEV  61       6 +919    6/09/80 03:28:23  (1/12/81) RMS   
  5   MLDEV  62       7  +86    1/12/81 19:41:51  (1/22/81) USERS1
  4   MLDEV  63       7 +139    1/22/81 00:51:45  (1/27/81) MOON  
  4   MLDEV  64       7 +143 !  1/27/81 20:08:40  (1/27/81) EB    

;COMPARISON OF DSK:SYSENG;MLDEV 63 AND DSK:SYSENG;MLDEV 64
;OPTIONS ARE    /3

**** FILE DSK:SYSENG;MLDEV 63, 17-39 (30351)
        SKIPE CALING    ;AND IF USER IS STILL WAITING FOR RETURN FROM SYSTEM CALL
         SOSLE CALACK   ;AND THIS REPLY IS TO HIS CURRENT ATTEMPT, NOT A PREVIOUS,
          JRST GOLOOP
**** FILE DSK:SYSENG;MLDEV 64, 17-39 (30351)
        SOSG CALACK     ; NOTE THE ACKNOWLEDGE AND SKIP IF NOT CURRENT YET
         SKIPN CALING    ; CURRENT; SKIP IF USER IS WAITING
          JRST GOLOOP   ; NOT CURRENT YET, KEEP WAITING; OR DON'T WANT IT
***************

\1f
GJC@MIT-MC 01/26/81 00:13:28
To: (BUG ITS) at MIT-MC
Does anybody know about this ARGUS frob, SYS2;TS ARGUS on MC?
Seems innocent enough, but it takes up incredible amounts
of resources for a trivial program, was getting like
33% to 44% of MC for quite some time before I killed it.
Sounds kind of buggy. I noticed it because it was being
run by a lot of turists, that kind of thing usually is.


\1f
Date: 24 JAN 1981 1507-EST
From: abrax at MIT-AI (Jeff Shrager)
Sent-by: ___035 at MIT-AI
Subject: Rubout to first char fails in DDT mode
To: (BUG ITS) at MIT-AI

If you forget the ":" to issue a real command and use rubout to get
back to the beginning of the line and insert it, ITS forgets that
there is a ":".  Looks like someone's crufty code looks for the ":"
ONLY on entry of the first character rather than at the beginning
of the line entered after all of it comes in.
\1f
KMP@MIT-MC 01/21/81 23:55:20
To: (BUG ITS) at MIT-MC
The system just hung for about a minute or so without accessing the disk.
Now I did a peek about 5 seconds after it started letting me get to disk
and there were only about 13 disk channels taken. Unless a lot were closed
in a very short time, I wonder if the problem is really disk channels all
used up or something else...

\1f
Date: 20 January 1981 16:31-EST
From: George J. Carrette <GJC at MIT-MC>
To: MOON at MIT-MC
cc: BUG-ITS at MIT-MC, JM at MIT-MC, JPG at MIT-MC

I know you need specific info about the state the running jobs where
in. What I'll do is set up some example runs, and make sure the 
behavior is repeatable, and catch you sometime system conditions
are right for a demo. 

-gjc

\1f
MOON@MIT-MC 01/20/81 15:48:24 Re: Terminal in 812
To: jerryb at MIT-AI
CC: (BUG ITS) at MIT-AI, beppe at MIT-AI
    Date: 19 JAN 1981 1514-EST
    From: jerryb at MIT-AI (Gerald R. Barber)
    Sent-by: BEPPE at MIT-AI
    To: (BUG ITS) at MIT-AI

    ITS doesn't seem to be listening to the terminal in 812.
    The AI ITS nnnn CONSOLE 36 ... message is coming through
    alright but the system doesn't respond to ^Z.
The system believes that Teleray has a meta key.  Evidently the parity
control switches in the back are not set correctly, such that
c-Z sends c-m-Z.  You want 8-bit characters, no parity, 1 stop bit.
\1f
MOON@MIT-MC 01/20/81 15:26:48
To: JPG at MIT-MC
CC: (BUG ITS) at MIT-MC, GJC at MIT-MC, JM at MIT-MC
    JPG@MIT-MC 01/20/81 07:36:49
    To: (BUG ITS) at MIT-MC
    CC: GJC at MIT-MC, JM at MIT-MC
    Forwarded for GJC:
       GJC@MIT-MC 01/19/81 20:09:53
       To: JPG at MIT-MC, JM at MIT-MC
       foo, its worse now than ever. BALCH's two dissowned macsyma
       jobs are still running hours later, its 8:00pm, and
       the fair-share is 3%. But, somehow his jobs get
       a total of 60% share, plus all the physical memory they
       need, almost a Moby unshared. How come these CPU-intensive
       memory-intensive dissowned jobs don't get swapped out?
       It should be something like active-for 1 minute, inactive for
       4 minutes.
Were these jobs running in a system call or in user mode?  Were they
taking page faults?  Were they getting some sort of interrupts such as
pdl overflow?  Were you able to reown them and stop them with the
DDT control-X command?  Without some specific information there is
nothing I can do.
\1f
JPG@MIT-MC 01/20/81 07:36:49
To: (BUG ITS) at MIT-MC
CC: GJC at MIT-MC, JM at MIT-MC
Forwarded for GJC:
   GJC@MIT-MC 01/19/81 20:09:53
   To: JPG at MIT-MC, JM at MIT-MC
   foo, its worse now than ever. BALCH's two dissowned macsyma
   jobs are still running hours later, its 8:00pm, and
   the fair-share is 3%. But, somehow his jobs get
   a total of 60% share, plus all the physical memory they
   need, almost a Moby unshared. How come these CPU-intensive
   memory-intensive dissowned jobs don't get swapped out?
   It should be something like active-for 1 minute, inactive for
   4 minutes.

\1f
Date: 19 JAN 1981 1514-EST
From: jerryb at MIT-AI (Gerald R. Barber)
Sent-by: BEPPE at MIT-AI
To: (BUG ITS) at MIT-AI

ITS doesn't seem to be listening to the terminal in 812.
The AI ITS nnnn CONSOLE 36 ... message is coming through
alright but the system doesn't respond to ^Z.
\1f
Date: 19 JAN 1981 0249-EST
From: MOON at MIT-AI (David A. Moon)
To: (BUG ITS) at MIT-AI

CHANNA;RAKASH DMNSTR does not work in the new ITS,
I think because it tries to slave from a not logged in sty
\1f
Date: 18 January 1981 2332-EST (Sunday)
From: Guy.Steele at CMU-10A
To: gnu at MIT-ML (Sent by ___022@MIT-ML)
Subject:  Transcribing COM links
CC: bug-its at MIT-ML
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

\1f
FREND@MIT-ML 01/18/81 17:39:53
To: (BUG ITS) at MIT-ML
I just logged in from the net, and before my login init was thru,
I got a message from system overseer saying I did not look like an
authorized user. there are about 8 people on now, half are tourists.
I think this is a bug because if PWORD let me in at this time, the
overseer program should not say he doesn't recognize me. Anyway, i
will leave as soon as I ^C this message
                                        michael bloom

\1f
Date: 18 JAN 1981 1530-EST
From: KLH at MIT-AI (Ken Harrenstien)
Subject: Spying on com-links
To: gnu at MIT-ML
CC: (BUG ITS) at MIT-AI

Tell your friend to ask the UC Berkeley Comp Sci dept.  Their UNIX
systems have a talk program which, while a feeble imitation of ITS com
links (eg no multiple party links), is much easier to modify for
scripting, because it is a user program rather than part of the
operating system.  I suspect the patterns will be different (more
sophomoric dialogue, owing to thousands of freshlings) but why not
take advantage of a home-grown resource...

\1f
gnu@MIT-ML (Sent by ___022@MIT-ML) 01/18/81 02:53:56
To: (BUG ITS) at MIT-ML
CC: GNU at MIT-ML
A friend of mine would like to do a study of language pattern in com-links
as a project for her class in Spoken/Written language differences.  (She
views com-links as a cross between the two.)  Is there any easy way to have
ITS record com-links somewhere for a week or two?  The person doing the study
is Nancy Levidow, a grad student in linguistics at UC Berkeley.  (I'm assuming
there are no privacy problems with this, as any comlink could be spied upon;
just technical problems.)  Easiest way to respond is via GNU@MC, since she's
not on the net.


\1f
Date: 15 January 1981 0110-EST (Thursday)
From: Guy.Steele at CMU-10A
To: moon at MIT-MC
Subject:  Re: system hanging on disk...
CC: eak at MIT-MC, bug-its at MIT-MC, ellen at MIT-MC, kmp at MIT-MC,
    rlb at MIT-MC
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

\1f
Date: 14 January 1981 21:09-EST
From: Earl A. Killian <EAK at MIT-MC>
Subject:  system hanging on disk...
To: MOON at MIT-MC
cc: BUG-ITS at MIT-MC, BIL at MIT-MC, ELLEN at MIT-MC, KMP at MIT-MC,
    RLB at MIT-MC

Gee, you could implement real resource management, and require
that any program that uses more than one disk channel, first say
"reserve me N channels", avoiding the deadlock.  Just kidding.

\1f
Moon@MIT-MC 01/14/81 02:24:39 Re: system hanging on disk...
To: ELLEN at MIT-MC
CC: KMP at MIT-MC, (BUG ITS) at MIT-MC, RLB at MIT-MC, BIL at MIT-MC
CC: JONL at MIT-MC
    ELLEN@MIT-MC 01/14/81 01:47:41 Re:  system hanging on disk...
    To: KMP at MIT-MC
    CC: (BUG ITS) at MIT-MC, RLB at MIT-MC, BIL at MIT-MC, JONL at MIT-MC
    CC: ELLEN at MIT-MC
    I just happened to have a peek today when one of those hangs happened...
    and by gosh and by golly, there were two full VT52 screens plus a few lines
    of disk channels in use from a C in peek.  I dunno... lots of TeX's and various
    INQUIRS (nasty Ellen here noting that some of the INQUIR channels were from
    unlogged lines doing WHOIS or NAME...).  Anyway, it probably was running out
    of disk channels.  How many are there?

Yes, exhausting the supply of disk channels is the usual cause of this.
There are a fairly humongous number I believe.  Maybe I should see if ITS
can be made to do something useful in this case.  (It used to return errors
instead of hanging, but someone decided it would be better to hang.)  Maybe
I can make it return an error after a while, which might encourage killing
of jobs.  TEX is a gross offender in this respect (so are PUB and COMPLR)
in that they open many channels, making a deadlock more likely.
\1f
ELLEN@MIT-MC 01/14/81 01:47:41 Re:  system hanging on disk...
To: KMP at MIT-MC
CC: (BUG ITS) at MIT-MC, RLB at MIT-MC, BIL at MIT-MC, JONL at MIT-MC
CC: ELLEN at MIT-MC
I just happened to have a peek today when one of those hangs happened...
and by gosh and by golly, there were two full VT52 screens plus a few lines
of disk channels in use from a C in peek.  I dunno... lots of TeX's and various
INQUIRS (nasty Ellen here noting that some of the INQUIR channels were from
unlogged lines doing WHOIS or NAME...).  Anyway, it probably was running out
of disk channels.  How many are there?

\1f
KMP@MIT-MC 01/13/81 00:17:15
To: (BUG ITS) at MIT-MC
CC: KMP at MIT-MC, RLB at MIT-MC, BIL at MIT-MC, JONL at MIT-MC
CC: ELLEN at MIT-MC
There has been a very high incidence rate of jobs hanging for a long time
(rlb: `several tens of seconds') waiting to do i/o to the disk. Is it possible
that this is due to an ITS bug or is it more likely to be people using up all
the disk channels/buffers/?? If it's possible that it's the former, could 
someone look into it? It's extremely irritating and has almost caused us to
reload the system unnecessarily a couple times because disk i/o was unavailable
for so long (one or two times ITS just started working again just as we were
about to reload it; these were several-minute pauses) ... 
-kmp

\1f
Date: 12 Jan 1981 2042-EST
From: EBM at MIT-XX
Subject: Slight protocol change, and new MLDEV/MLSLV installed
To: info-mldev at MIT-AI

The MLSLV protocol has been upgraded in response to some catastrophes
that occurred on DM about 6 weeks ago.  Specifically, a number of files
on SYS directories were deleted using MLSLV, and because of the way the
protocol is constructed, there was no way to track down the culprit,
even thought the usual console message were written.

MLSLV has been extended by the addition of a LOGIN command and reply
code.  Logging in is REQUIRED only for deletion of files, but for
simplicity and friendliness, MLDEV starts a login (but does not wait for
the response) almost immediately.  This should not particularly slow
down the protocol.

Instead of logging in as hhhJuu (host and user) MLSLV, it now logs in as
XUNAME (of the foreign user) MLSLV, with a "terminal name" of hhhJuu.
It should still be easy to match up jobs, connections, etc., via PEEK,
and much easier to identify who is doing what.

If it is deemed necessary to de-install the new MLSLV and MLDEV, it was
installed using links:
        On each site, SYS;ATSIGN MLDEV is a link to SYS;ATSIGN NMLDEV,
        and SYS;ATSIGN OMLDEV is the old MLDEV.

        MLSLV is organized the same way, but lives in DEVICE;
Bugs can be sent to me.

Although this change is slightly incompatible, it should not prove to be
a real problem for users, or for upgrading of other programs using the
protocol.

-------
\1f
Date: 12 January 1981 1412-EST (Monday)
From: Guy.Steele at CMU-10A
To: bug-its at MIT-MC
Subject:  File name > >
CC: kmp at MIT-MC
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 <.

\1f
KMP@MIT-MC 01/11/81 23:09:58
To: (BUG ITS) at MIT-MC, (BUG DDT) at MIT-MC
:COPY TTY:,DSK:KMP;> >
Hi.^M^J^C

created a file called _COPY_ OUTPUT on my dir with `hi' in it ... While this
*is* the greatest file of the last type in my dir, I should think there are
more aesthetic filenames it could have chosen.

\1f
BARRYG@MIT-MC 01/09/81 20:26:19 Re: strange interaction between RMAIL and TCTYP GLASS
To: (BUG RMAIL) at MIT-MC
CC: (BUG ITS) at MIT-MC
I normally run under TCTYP GLASS SCRL 22 (See MC: GUEST0; BARRYG LOGIN)
and most programs (INFO, PRINT, MSGS, MAIL) that I use get along well with
that.  When using RMAIL, however, when the screen  fills I get **MORE**
(instead of --MORE-- as with other programs).  No matter WHAT character is then
typed, RMAIL prints out the rest of the message (again printing out **MORE**
approximately every screenful but not pausing for input).

I haven't tested this in EMACS, so I can't tell if the problem is general with
EMACS or specific to ^R RMAIL.  If you need help with this, I'll try a few
things under EMACS to try isolating it.  

This is a minor bug (so far), but since we tourists are supposedly here
for the purpose of testing programs, I present this bug for your delectation.

        barry gold
\1f
Date: 8 Jan 1981 1305-EST
From: PDL at MIT-DMS (P. David Lebling)
To: BERN at MIT-ML
Cc: (BUG ITS) at MIT-ML
In-reply-to: Message of 08 Jan 81 at 1211 EST by BERN@MIT-ML
Message-id: <[MIT-DMS].178600>

The author is stored as the directory number, which is why you see
USERS1.  Unfortunately, there isn't room in the directory entry for
the full name.



\1f
BERN@MIT-ML 01/08/81 12:11:18
To: (BUG ITS) at MIT-ML
Now that passwords are implemented on most machines, it is more
appropriate when a file is created, written, or linked, that the
author be the uname rather than the sname (or whatever it currently
is).  It is hard to find out who wrote in a file when the author 
name is USERS1 for example.
\1f
BARRYG@MIT-MC 12/23/80 21:12:57
To: (BUG ITS) at MIT-MC
I would appreciate it if someone would, at your leisure, restore
MC:GUEST0;BARRYG XMAIL from whatever backups are maintained.
        /barry
\1f
Date: 22 December 1980 11:55-EST
From: Robert W. Kerns <RWK at MIT-MC>
To: KMP at MIT-MC
cc: BUG-ITS at MIT-MC, ELLEN at MIT-MC, MLK at MIT-MC,
    USER-ACCOUNTS at MIT-MC, USER-ACCOUNTS at MIT-AI

    Date: 22 December 1980 00:00-EST
    From: Kent M. Pitman <KMP at MIT-MC>
    To: RWK at MIT-MC, BUG-ITS at MIT-MC, USER-ACCOUNTS at MIT-MC
    cc: MLK at MIT-MC, ELLEN at MIT-MC

        Date: 21 December 1980 09:17-EST
        From: Michael L. Kazar <MLK>
        To:   USER-ACCOUNTS

        Some twerp just enslaved my terminal and $$U'ed me off. It was from
        a vadic dialup no less! May I suggest that maybe PWORD should
        not allow enslaves but only links. ??
    -----
    Would it be hard to set things up so that ^_E was disallowed from PWORD?
    Unlogged DDTs could also do it if it's easier to check uname than jname.
    Anyway, some unlogged random slaved a Macsyma user and lost him a lot of 
    work the other day and he was quite upset.

    If this can't be done, I recommend that for the safety of our paying users,
    initiating links from unlogged pwords should be made impossible. This is,
    however, a more extreme measure than I would like to take if we can help
    it, though.

    Thanks. -kmp

This has also happened several times recently on ML, and ML's PWORD is
currently patched to disallow initiating links.  But better than this would be
to have ^_E not work on a not-logged-in dialup or STY (leaving local TTY's
alone).  This is a simple change to ITS, and minimizes the restrictions imposed
to achieve the goal.  If there are no objections I'm willing to do the
(trivial) work.

\1f
Date: 22 December 1980 00:00-EST
From: Kent M. Pitman <KMP at MIT-MC>
To: RWK at MIT-MC, BUG-ITS at MIT-MC, USER-ACCOUNTS at MIT-MC
cc: MLK at MIT-MC, ELLEN at MIT-MC

    Date: 21 December 1980 09:17-EST
    From: Michael L. Kazar <MLK>
    To:   USER-ACCOUNTS

    Some twerp just enslaved my terminal and $$U'ed me off. It was from
    a vadic dialup no less! May I suggest that maybe PWORD should
    not allow enslaves but only links. ??
-----
Would it be hard to set things up so that ^_E was disallowed from PWORD?
Unlogged DDTs could also do it if it's easier to check uname than jname.
Anyway, some unlogged random slaved a Macsyma user and lost him a lot of 
work the other day and he was quite upset.

If this can't be done, I recommend that for the safety of our paying users,
initiating links from unlogged pwords should be made impossible. This is,
however, a more extreme measure than I would like to take if we can help
it, though.

Thanks. -kmp

\1f
GJC@MIT-MC 12/19/80 02:21:05
To: (BUG ITS) at MIT-MC
CC: ELLEN at MIT-MC
I'm not sure exactly who to complain to on this,
I've complained about the bugginess of H19WHO many times
before. Anyway, there is a DSN's tree with a running
H19WHO on it now on MC which has used up 2 hours of CPU time.
I've just :ujob jmsk hactro and :snarfed the job, and it
significantly improves the fair share.

This problem comes up very often when a user with an
h19who gets detached. As soon as I reowned the tree
the h19who typed out on my tty and stopped burning up cpu time.
When ^X'd it was doing a .HANG
...now, how is it that you save jobs for examination??

\1f
Date: 19 December 1980 01:06-EST
From: Frank J. Wancho <FJW at MIT-MC>
Subject:  Access to AI via DARCOM PTIP
To: BUG-ITS at MIT-AI
cc: FJW at MIT-MC, ELLEN at MIT-MC

Attempts to connect to AI from the DARCOM-PTIP are met with "ITS being
Debugged" when, in fact, it is not.  I understand that the same
message is sent when attempting to connect from other TIPs in the D.C.
area.  If you are trying to block randoms and are having trouble
specifically with DARCOM-PTIP users, I would like to have the details
so corrective action can be taken and the block can be removed.  If
not, then please remove the block.

Thanks,
Frank

\1f
Moon@MIT-MC (Sent by Moon at CADR16@MIT-MC) 12/16/80 22:35:23
To: CWH at MIT-MC
CC: (BUG ITS) at MIT-MC
    CWH@MIT-MC 12/16/80 19:57:53
    To: (BUG ITS) at MIT-MC
    If the userid contains a numeric digit as a character in the middle of the
    name, only the alphabetic characters preceding the digit are looked at when
    setting the file author.  For instance, if a file is created by uname
    K7X, the file author is shown to be K.
This sounds unlikely.  File authors are stored as the disk address of the
user's home directory.  No name parsing is involved.  (The reason they are stored
this peculiar way is because whoever put them in couldn't find enough bits to
store a sixbit name.)
\1f
CWH@MIT-MC 12/16/80 19:57:53
To: (BUG ITS) at MIT-MC
If the userid contains a numeric digit as a character in the middle of the
name, only the alphabetic characters preceding the digit are looked at when
setting the file author.  For instance, if a file is created by uname
K7X, the file author is shown to be K.

\1f
GJC@MIT-MC 12/12/80 19:53:21
To: (BUG ITS) at MIT-MC
MC appears to be crashing somewhat harder
than I've ever seen an ITS system do.
I have had files written out, e.g. GJC;FOO 1
a few minutes ago, and even compiled,
so I *know* is was there, and then
MC crashes, and when I get back 5 minutes
later the file is *gone*.

ouch.


\1f
Date: 11 DEC 1980 1935-EST
From: JLK at MIT-AI (John L. Kulp)
To: (BUG ITS) at MIT-AI

MLDEV SEEMS TO BE TRUNCATING FILES.  I JUST DID :COPY ON MC OF
MC:DATDRW;WL BIN TO AI:
AND THE FILE ON AI WAS NICELY ROUNDED OFF TO EXACTLY 72 BLOCKS
(THE ACTUAL FILE IS 72 AND 709 WORDS).
\1f
RWK@MIT-MC 12/08/80 19:44:05 Re: CORBLK: NO CORE AVAILABLE
To: RAM at MIT-MC
CC: (BUG ITS) at MIT-MC
That means there is no more virtual memory left in the system.  I.e. there
are too many people using the system to get anything done.  The best thing
to do is to go away for a while.  Baring that, you can always just $P it again.
When there is enough core, it will continue where it was.  It may take a while,
the easiest way to get some core freed up is to log out.  There's lots of other
people trying to get to any newly freed core before you.

\1f
RAM@MIT-MC 12/08/80 18:47:05
To: (BUG ITS) at MIT-MC
running nbabyl i got:

ERROR CORBLK: NO CORE AVAILABLE
15243>>.CALL 37607 (CORBLK)

\1f
Date: 6 December 1980 21:41-EST
From: Robert W. Kerns <RWK at MIT-MC>
Subject:  File Authors
To: JONL at MIT-MC
cc: BUG-DDT at MIT-MC, BUG-ITS at MIT-MC, BUG-EMACS at MIT-MC

    Date: 6 DEC 1980 0616-EST
    From: JONL at MIT-MC (Jon L White)
    To:   (BUG ITS) at MIT-MC
    cc:   RWK at MIT-MC, (BUG DDT) at MIT-MC
    Re:   File Authors

    :MOVE <foo>, <bar>
    fails to preserve the file's author field.
Not true!  You're being confused by EMACS's DIRED, which displays the bug.
\1f
JONL@MIT-MC 12/06/80 06:16:49 Re: File Authors
To: (BUG ITS) at MIT-MC
CC: RWK at MIT-MC, (BUG DDT) at MIT-MC
:MOVE <foo>, <bar>
fails to preserve the file's author field.

\1f
REM@MIT-AI (Sent by ___010@MIT-AI) 12/04/80 20:16:16
To: (BUG ITS) at MIT-MC
Gee, MC hasn't been very reliable lately, crashed again now...


\1f
Date: 26 NOV 1980 1255-EST
From: CL at MIT-MC (Charles C. Linton)
Sent-by: CL0 at MIT-MC
Subject: T36
To: (BUG ITS) at MIT-MC
CC: LPH at MIT-MC, (BUG R11) at MIT-MC

The default TCTYP for T36 appears to have changed to a software
imlac. (SIMLAC)  It should be set for a standard telaray (T1061)
at 9600 baud.  Also, when I attempted to set it back to teleray
from another console, the TCTYP program apparently wedged.  i.e.
it never returned.  After killing the TCTYP program and examining
the bits I found that %tpcbs was set.  I cleared it using
the :tctyp program.  Then I again tried :tctyp t1061 and everything
worked fine.  


\1f
Date: 17 NOV 1980 1331-EST
From: RICH at MIT-AI (Charles Rich)
To: (BUG ITS) at MIT-AI

How about allocating the CRASH; directory to SECOND: or THIRD:.
\1f
Date: 13 Nov 1980 1234-EST
From: PDL at MIT-DMS (P. David Lebling)
To: BUG-ITS at MIT-DMS
Subject: BUG => ITS
Message-id: <[MIT-DMS].168838>

Lately DM has been getting a lot of parity errors that do not cause
the system to stop even though parity stop is on.  It prints:

PARITY ERROR #N  PC=FOO,,BAR HH:MM:SS

DM ITS Revived!  hh:mm:ss

The parity stop switch is, of course, on.  These errors don't seem
to get stuffed in the PARADR buffer or get an IOR/AOR printed out,
or anything.  Is this supposed to be a feature?  Or is it a bug, or
is our parity stop switch not working?
        Dave


\1f
Date: 12 NOV 1980 0238-EST
From: ECC at MIT-AI (Eugene C. Ciccarelli)
Subject: T15 modem
To: (BUG ITS) at MIT-AI

For several days now, I have not been able to use the 258-6700
at all, but have been able to use 258-6701.  Though I can
connect to it ok, none of the characters seem to get through.
Are others able to use it?
\1f
Date: 5 November 1980 13:58-EST
From: Robert W. Kerns <RWK at MIT-MC>
To: BUG-ITS at MIT-MC
cc: ELLEN at MIT-MC

Kruczynski, Len of USAFA-GATEWAY called.  It seems that he can't connect to
MC.  He CAN connect to AI, XX, Multics, etc.  However, when trying to go from
MC to USAFA-GATEWAY via TELNET MC gets a RST TIMEOUT message printed on the
system console (host=31001 = USAFA-GATEWAY).  TELNET works fine from AI.  His
system maintainer may try to contact Moon.

\1f
GYRO@MIT-ML 11/04/80 23:08:52
To: (BUG its) at MIT-AI
An AI crash a few minutes ago was simultaneous with
a comm link that I opened (I mean a ^_c... in case "comm link" is
somehow ambiguous?) being closed (^_n) by the other person.
I don't know if it's really relevant but the coincidence was
remarkable.  Oh yes, I was in the middle of a :send when I started
the link.

-- Gyro
-------

\1f
Date: Monday, 3 November 1980  12:40-EST
From: Chris Ryland <CPR at MIT-EECS>
To: bug-r11 at mc, bug-its at mc
Subject: buffer hogging

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.

\1f
Date: 27 October 1980 19:14-EDT
From: Earl A. Killian <EAK at MIT-MC>
Subject:  Temporary files
To: MOON at MIT-MC
cc: BUG-ITS at MIT-MC, GJC at MIT-MC, RWK at MIT-MC

Couldn't you also open the file, and then delete it.  When you
close the file, or when it is closed for you by killing the job,
then it will be deleted by the system.

\1f
RWK@MIT-MC (Sent by ___011@MIT-MC) 10/26/80 06:09:56 Re: I replied to CSTACY
To: (BUG ITS) at MIT-MC
[Translating all devices to AI: including USR: and ERR:]

\1f
CSTACY@MIT-MC 10/26/80 00:19:09
To: (BUG ITS) at MIT-MC

On MC,  do:    $^T foo,ai:foo;
               foo^F FILE.DIR. etc -- CANT READ SYSTEM'S ERROR MESSAGE
               bar^K
               INFERIOR-CREATION FAILED

Chris
------

\1f
MOON@MIT-MC 10/24/80 20:35:22 Re: Temporary files
To: GJC at MIT-MC
CC: RWK at MIT-MC, (BUG ITS) at MIT-MC
If you read the file .INFO.; ITS LOCKS it will tell you about features
for creating unique IDs and having locks that get unlocked when a job
is killed.  Of course there is no way to run arbitrary code when a job
is killed; that could easily make it impossible to kill.

It's easy to tell whether a given job "points to" a file, if you include
that job's job-number in the name of the file.  You simply have
one file per job-number, recreated when a job starts up.  If you
want to delete "left over" files in some cleanup procedure, simply
check to see if the job has the name of that file in a fixed place
in its memory (or we could allocate a new .OPTION bit or use the
dragon's way of telling whether a job is a Macsyma).

\1f
Date: 24 October 1980 13:20-EDT
From: George J. Carrette <GJC at MIT-MC>
Subject:  new error message system
To: RWK at MIT-MC, BUG-ITS at MIT-MC


    Date: 24 October 1980 11:36-EDT
    From: Robert W. Kerns <RWK at MIT-MC>
    To:   GJC
    Re:   new error message system

    Files that want to be sure to go away when a process is killed can be written
    to .TEMP.;


I've seen files on the so-called .TEMP. directory end up on
back-up tape! Look, theres one now on MC:.TEMP.;LPH .PLOT.

Each and every macsyma which starts up will probably create
a new file on the .TEMP. directory, and these will have
to be garbage collected better than they are now.
The problem is, how can a clean-up program tell if any existing
macsyma jobs point to one of the files? Well, I guess AGE greater than
8 hours is a reasonable heuristic. Does ITS have any thing which could
give a UNIQUE process ID over the time between crashes?

Is there any provision in ITS for letting a process take an
interrupt when something tries to KILL it? It could then
delete the file(s) and kill itself.


\1f
Date: 22 OCT 1980 2331-EDT
From: EFH at MIT-AI (Edward F. Hardebeck)
To: (BUG ITS) at MIT-AI

the name dragon got a PURPG
(PURPG;) 1371>>MOVEM 2,(3)    2/   MOVEI 20100(4)   63336/   0
it is dumped on crash;namdrg >
\1f
Date: 20 October 1980 02:03-EDT
From: Robert W. Kerns <RWK at MIT-MC>
Subject:  FOOO$U doing a :MASSACRE
To: JNC at MIT-AI
cc: BUG-ITS at MIT-MC

    Date: 17 October 1980 02:20-EDT
    From: J. Noel Chiappa <JNC at MIT-AI>
    To:   RWK
    cc:   JNC at MIT-AI
    Re:   FOOO$U doing a :MASSACRE

        Barf! This has actively wedged me. What's the ratyionale, can it
    be changed, and if not, how do I avoid lossage (other than detaching
    all my jobs?)
                Noel
The reason is that logging in on ITS is not permitted (by ITS) if a job has
inferiors.  One way to avoid lossage is to log in before doing anything.
Of course, I think a better thing to do would be to allow logging in with
inferior jobs.  Since this is already done when a job is reowned, I wouldn't
think this would be very hard to do...
l
\1f
MOON@MIT-MC 10/19/80 04:18:06 Re: SPURIOUS CHARACTERS
To: CENT at MIT-AI
CC: TC at MIT-AI, RG at MIT-AI, (BUG ITS) at MIT-AI
    Date: 19 OCT 1980 0409-EDT
    From: CENT at MIT-AI (Pandora B. Berman)
    Subject: SPURIOUS CHARACTERS
    To: TC at MIT-AI, MOON at MIT-AI, RG at MIT-AI
    CC: (BUG ITS) at MIT-AI

    THE DATAPOINT IN LAUREL'S OFFICE (917) SEEMS TO OCCASIONALLY
    SEND SPURIOUS AND UNCALLED-FOR \b ^H'S. I HAVE SEEN THIS HAPPEN
    A FEW TIMES AFTER RUNNING :F; THE OUTPUT FROM :F WOULD PRINT
    OUT FOLLOWED BY A ^H AND GOING BACK INTO WHATEVER JOB IS
    CURRENT. I HAVE NOT SEEN THIS BEHAVIOR CONNECTED WITH ANYTHING
    ELSE. I DON'T KNOW WHETHER THIS IS A HARDWARE OR SOFTWARE BUG.
    CAN SOMEONE LOOK INTO IT?
It's a hardware bug, fixable by throwing the datapoint in the trash.
They have really crappy keyboards.
\1f
Date: 19 OCT 1980 0409-EDT
From: CENT at MIT-AI (Pandora B. Berman)
Subject: SPURIOUS CHARACTERS
To: TC at MIT-AI, MOON at MIT-AI, RG at MIT-AI
CC: (BUG ITS) at MIT-AI

THE DATAPOINT IN LAUREL'S OFFICE (917) SEEMS TO OCCASIONALLY
SEND SPURIOUS AND UNCALLED-FOR \b ^H'S. I HAVE SEEN THIS HAPPEN
A FEW TIMES AFTER RUNNING :F; THE OUTPUT FROM :F WOULD PRINT
OUT FOLLOWED BY A ^H AND GOING BACK INTO WHATEVER JOB IS
CURRENT. I HAVE NOT SEEN THIS BEHAVIOR CONNECTED WITH ANYTHING
ELSE. I DON'T KNOW WHETHER THIS IS A HARDWARE OR SOFTWARE BUG.
CAN SOMEONE LOOK INTO IT?
\1f
MOON@MIT-MC 10/17/80 21:30:20
To: DCP at MIT-MC
CC: (BUG ITS) at MIT-MC
    DCP@MIT-MC 10/17/80 16:54:08
    To: (BUG ITS) at MIT-MC
    Symbolic IOT is documented to XOR the control bits of the call with the
    appropriate channel variable in the system. I am trying to use this
    with the TTY to change from %TJDIS mode to %TJSIO mode, and I am losing.
    There is a short program in MC:DCP;TEST > which I think should work from 
    the specs in the documentation. Why am I losing??

It does XOR the control bits.  Where the documentation says the LH of the
first argument (the channel number) is also XOR'ed in it is lying.  Use
5000,,%tjdis+%tjsio and your program will work (this is an immediate control
bits arg.)
\1f
DCP@MIT-MC 10/17/80 16:54:08
To: (BUG ITS) at MIT-MC
Symbolic IOT is documented to XOR the control bits of the call with the
appropriate channel variable in the system. I am trying to use this
with the TTY to change from %TJDIS mode to %TJSIO mode, and I am losing.
There is a short program in MC:DCP;TEST > which I think should work from 
the specs in the documentation. Why am I losing??

\1f
GSB@MIT-ML 10/15/80 05:02:27
To: (BUG COMSAT) at MIT-ML
CC: (BUG ITS) at MIT-ML
The mailer lost again tonight because the system crashed renaming LISTS MSGS
to LISTS MSGT.  Either comsat should recognize this condition or ITS
shouldn't increment the name unless its necessary.

\1f
GJC@MIT-MC 10/04/80 01:19:40
To: (BUG ITS) at MIT-MC, ELLEN at MIT-MC
3-6985 rang but didn't answer, I'm on 3-6986 now
and am experiencing incredible line lossage and garbling,
(am on a VT52 with a 1200 baud vadic), when recieving at
high speed. Probably unrelated, but I thought you@might want
to know.

\1f
GSB@MIT-ML 09/23/80 07:23:37 Re: ML believes tty 0 to be a teletype
To: (BUG ITS) at MIT-ML
with -%TOLWR...

\1f
Date:  8 SEP 1980 0343-EDT
From: U at MIT-AI
To: (BUG ITS) at MIT-AI
CC: USER-A at MIT-AI, LEVITT at MIT-AI

Hello. I am Dave Levitt's music box line. I like to send characters
randomly to the AI machine over T33. Guess what I did today! I sent a
^Z and then after a while managed to send "U\eU" to log myself in.
Isn't that marvelous?  All I really did after that today was send a
lot of "?"  characters. I know ALL about DDT and ITS now. But just as
I was working on trying to send :LOCK CRASH, some luser took my tree
away from me. Now I have to start all over and try to get AI to
listen to me again.

You see, my buddy the PDP-6 (T06) and I have a little contest going
to see who can cause the first system crash by sending garbage down the
line. He's ahead of me: a few days ago he managed to get up a peek and
type ^B to it. 80 blocks of USERS5;.PEEK. 1. Ahhh, but now I've logged in...

Melodiously,
U@AI




U/klotz
\1f
Date:  7 SEP 1980 0217-EDT
From: HIC at MIT-AI (Howard I. Cannon)
To: (BUG ITS) at MIT-AI

I fixed the bug on DM, in both the running monitor and in the BIN file.
The bug was a PUSH P,TTEBAK which wanted to be a PUSHJ.
--Howard
\1f
Date: 7 September 1980 02:04-EDT
From: Howard I. Cannon <HIC at MIT-MC>
Subject:  BUG => its
To: PDL at MIT-DMS
cc: BUG-its at MIT-DMS

    Date: 6 Sep 1980 1318-EDT
    From: PDL at MIT-DMS (P. David Lebling)
    To:   BUG-its at MIT-DMS
    Re:   BUG => its

    In case anyone wants to look at it, a crash of ITS 1193 is on
    DM:.;CRASH 5535.  It crashed at UUOH0+2.
I looked at another crash at UUOH0+2.  It trapped from PI7 while
PUSHJ'ed to the echoin code.  It was hacking TTY 0 (I contained MOVE),
and 1(p) had IBP B (CRASH 5535 seems identical).  Unfortunatly,
it did a pretty good job of wiping out its tracks, so I couldn't
tell where it came from, but it is pretty clear that it POPJ'ed with
the IBP B on the stack (XUUOH contained C, of course).



\1f
Date: 6 Sep 1980 1318-EDT
From: PDL at MIT-DMS (P. David Lebling)
To: BUG-its at MIT-DMS
Subject: BUG => its
Message-id: <[MIT-DMS].160451>

In case anyone wants to look at it, a crash of ITS 1193 is on
DM:.;CRASH 5535.  It crashed at UUOH0+2.

\1f
Date: 5 Sep 1980 1047-EDT
From: PDL at MIT-DMS (P. David Lebling)
To: BUG-its at MIT-DMS
Subject: BUG => its
Message-id: <[MIT-DMS].160320>

The echoin bug is that at TTELP5+10/ TRNN A,xxx should be TRNE A,xxx.
I will patch the source accordingly.


\1f
Date: 5 Sep 1980 1040-EDT
From: PDL at MIT-DMS (P. David Lebling)
To: BUG-ITS at MIT-DMS
Subject: BUG => ITS
Message-id: <[MIT-DMS].160319>

We tried running ITS 1193.  It works okay except that ECHOIN seems
to echo in the command area after the first character typed.  Looking
at TS3TTY 258 vs. 255 indicates new code that fools around with that
sort of thing.  I suspect it's buggy...


\1f
Date: 1 September 1980 18:46-EDT
From: Robert W. Kerns <RWK at MIT-MC>
Subject:  The datacomputer is no more!
To: KEN at MIT-AI
cc: BUG-ITS at MIT-AI

The problem is really that the datacomputer was discontinued last March or so.
There were system messages about it long in advance.  You must have missed
seeing them or something.  I don't know if there is any way to recover your
files, although the fact that you were to connect at all would seem to indicate
they are providing some sort of limited service, perhaps to allow recovery in
cases such as yours.  Perhaps sending a note to someone at CCA will help?

\1f
Date: 29 AUG 1980 2336-EDT
From: KEN at MIT-AI (Kenneth Kahn)
Subject: really a dftp problem but bug-dftp is broken
To: (BUG ITS) at MIT-AI

I sent the following message and recieved this
    COMSAT@MIT-AI 08/29/80 22:50:12 Re: Msg of Friday, 29 August 1980 22:50-EDT
    A copy of your message is being returned, because:
    "DFTP-HACKERS" at MIT-AI is an unknown recipient.
        Message not sent.
     Failed message follows:
    -------
    KEN@MIT-AI 08/29/80 22:50:07
    It seems my directory on the data computer has disappeared.
    When I :dftp I get dftp.guest rather than dftp.its.ken ...
    Can it be restored or at least long enough for a tape dump of my files?

Could my question please be forwarded to whoever is hacking dftp these days?
\1f
MOON@MIT-MC 08/29/80 03:50:48 Re: Allocated devices
To: ED at MIT-AI
CC: RMS at MIT-AI, (BUG ITS) at MIT-AI
    Date: 28 AUG 1980 0013-EDT
    From: ED at MIT-AI (Ed Schwalenberg)
    Subject: Allocated devices
    To: RMS at MIT-AI, (BUG ITS) at MIT-AI

    Pnn: and Dnn: as devices work unless they have been "allocated" to
    the SECOND:, THIRD:, VISION: sort of pack.  I don't know whether this
    is alleged to be a feature or a bug; I can't see any good that derives
    from it.
It's because of the way the file system works on DM, which has actual
reserved packs.  Actually it could be fixed but it's random to use the
numbers rather than the names.
    Slightly more serious is that there is no way (as far as I know) of
    knowing what allocated devices there are (in particular .GETSYS knows
    nothing about them) or what the mapping between pack numbers and
    allocated devices is.  
The :DSKUSE # command should print this information, but doesn't currently.

                           There is also no way of telling what directories
    are allocated to what packs for the allocated directory scheme.
The :DSKUSE dirname command prints this information.
\1f
Date: 28 Aug 1980 1032-EDT
From: PDL at MIT-DMS (P. David Lebling)
To: ED at MIT-AI
Cc: RMS at MIT-AI, (BUG ITS) at MIT-AI
In-reply-to: Message of 28 Aug 80 at 0013 EDT by ED@MIT-AI
Subject: [Re: Allocated devices]
Message-id: <[MIT-DMS].159324>

In fact, DSKUSE does almost everything you are asking for; it
will tell what packs are allocated, pack each allocated directory
is on, and so on.  It doesn't know much about the named pack hack,
as this is fairly new, but maybe if I find some time...
        Dave


\1f
Date: 28 AUG 1980 0013-EDT
From: ED at MIT-AI (Ed Schwalenberg)
Subject: Allocated devices
To: RMS at MIT-AI, (BUG ITS) at MIT-AI

Pnn: and Dnn: as devices work unless they have been "allocated" to
the SECOND:, THIRD:, VISION: sort of pack.  I don't know whether this
is alleged to be a feature or a bug; I can't see any good that derives
from it.
Slightly more serious is that there is no way (as far as I know) of
knowing what allocated devices there are (in particular .GETSYS knows
nothing about them) or what the mapping between pack numbers and
allocated devices is.  There is also no way of telling what directories
are allocated to what packs for the allocated directory scheme.
I don't think that anybody is being actively screwed by this, but it
would be tasteful if a program could find out about such things without
experimenting or sending mail to Moon.
\1f
Date: 27 AUG 1980 0610-EDT
From: RMS at MIT-AI (Richard M. Stallman)
To: (BUG ITS) at MIT-AI

The device name P15: works for reading but gets
Device not Available for writing (from :COPY).
\1f
Date: 20 Aug 1980 1423-EDT
From: TAA at MIT-DMS (Timothy A. Anderson)
To: SWG at MIT-DMS
Cc: BUG-ITS at MIT-DMS, clr at MIT-DMS
In-reply-to: <[MIT-DMS].158301>
Subject: [Re: BUG => ITS]
Message-id: <[MIT-DMS].158305>

If the problem with .BATCH;NBATCH BAD was caused by a disk crash, which
seems likely, it (shiver) was never reported by the salvager.  Could
this happen if the file it's sharing with were deleted before the system
crashed?
        -taa

\1f
Date: 20 Aug 1980 1345-EDT
From: SWG at MIT-DMS (S. W. Galley)
To: BUG-ITS at MIT-DMS
Cc: taa at MIT-DMS, clr at MIT-DMS
Subject: BUG => ITS
Message-id: <[MIT-DMS].158301>

The file DM:.BATCH;NBATCH BAD is supposed to have the same contents as
DM:.BATCH;NBATCH SAVE, but words 166000-167777 have ASCII text from some
other file in them.  Could this be from some disk crash since February?

\1f
RWK@MIT-MC (Sent by RWK0@MIT-MC) 08/13/80 02:36:25 Re: CNSSET/TCMXV bug
To: (BUG ITS) at MIT-MC
CC: BDG at MIT-MC
When BDG sets his vertical screen size down to 1, ITS crashes at TYOAS7+3
because his cursor position is larger than his screen height.  It died when
DDT had the TTY, with his DDT at a .CALL CNSGET.  It had of course recently
done a ^PA.  Probably .CALL CNSSET (which he had been playing with in a program
of his) should not allow you to set the size below 2 in either dimension...

I did not dump this because I wanted to get my buffer back.  I hope I got
enough info for you to figure out what happened anyway.

\1f
RWK@MIT-MC 08/05/80 18:24:53
To: (BUG ITS) at MIT-MC
CC: TAFT at MIT-MC
Both FINGER and SUPDUP, when going via CHAOS, are saying:
? Internal error - ISE0

There is no problem, when via ARPA

\1f
MOON@MIT-MC 08/01/80 21:51:55 Re: rubout problem
To: EAK at MIT-MC
CC: (BUG DDT) at MIT-MC, (BUG ITS) at MIT-MC, (BUG MAIL) at MIT-MC
    Date: 1 August 1980 19:42-EDT
    From: Earl A. Killian <EAK at MIT-MC>
    Subject:  rubout problem
    To: BUG-DDT at MIT-MC, BUG-MAIL at MIT-MC
    cc: BUG-ITS at MIT-MC

    Perhaps DDT and other programs should be using ECHOIN to solve
    the rubout problem (where ABD<rubout>CD echoes as ABDC instead of
    ABCD).  If the rubout problem is the only reason why :MAIL
    doesn't use PI echoing, then maybe it should use it too.

Unfortunately ECHOIN is rather difficult to use.  I designed a scheme 
which would not require any changes to user programs but I don't have
nearly enough time to implement it.  The basic idea is that when a non-echoing
character is typed the system defers echoing, and re-enables it when
the next echoing character is read by the program (in the meantime the
program may have typed out, for instance to echo erasure for a rubout).
This wouldn't be too hard but the refinement to it is to go ahead and echo
additional characters so you can see what you're typing, but if the program
types anything out erase that echoage and do it again, which is too hard
to do right now.  I don't suppose there are any competent volunteers?
\1f
Date: 1 August 1980 19:42-EDT
From: Earl A. Killian <EAK at MIT-MC>
Subject:  rubout problem
To: BUG-DDT at MIT-MC, BUG-MAIL at MIT-MC
cc: BUG-ITS at MIT-MC

Perhaps DDT and other programs should be using ECHOIN to solve
the rubout problem (where ABD<rubout>CD echoes as ABDC instead of
ABCD).  If the rubout problem is the only reason why :MAIL
doesn't use PI echoing, then maybe it should use it too.

\1f
DLW@MIT-MC 07/29/80 03:52:20
To: (BUG ITS) at MIT-MC
In the version of ITS on MC, if you come in from SAIL on a TELNET
connection, set +%TPMTA, and send characters with the eighth bit
on, ITS does not see them at all.
\1f
REM@MIT-MC 07/20/80 00:17:16
To: (BUG ITS) at MIT-MC
Is there any really good reason for discarding a CLI file being passed from
one job to another just because that recipient job hasn't processed it
in a minute or two?  The recipient job was enabled for CLI interrup, but
had been ^Z'd, thus couldn't process it immediately.  The fact that it
was enabled for interrupt means it wasn't just a random message to
job that didn't want it.

\1f
MOON@MIT-MC 07/10/80 05:12:56 Re: FILLEN on non-disk devices
To: ED at MIT-AI, (BUG ITS) at MIT-AI
The bug is not in ITS, which does what it's documented to, but in
the special job device which is used if you read the directory of
a non-directory device.  Apparently after opening it simply SIOTs
to the BOJ: device, assuming that the first thing you will do after
opening is an IOT, but if you do something else novel effects occur.
\1f
Date: 10 JUL 1980 0401-EDT
From: ED at MIT-AI (Ed Schwalenberg)
Subject: FILLEN on non-disk devices
To: (BUG ITS) at MIT-AI, (BUG MLDEV) at MIT-AI

Doesn't fail, it just doesn't work.  This causes e.g. AIPTP\ 6 from
MC to cause MLSLV on AI to die horribly, believing that SIXBIT/.FILE./
is a byte size.  The code in MLSLV is reasonable given system calls
that work as they should.  The documentation DOES say that it doesn't
work on non-disk devices, but claims that it returns error 34 in that
case.
\1f
MOON@MIT-MC 07/06/80 04:34:02 Re: Fair Share and the GAME program
To: EJS at MIT-MC
CC: (BUG ITS) at MIT-MC, LPH at MIT-MC
The ITS bug that caused fair share to be very low on occasion when the system
was lightly loaded has been fixed. (In response to your message of 1 July 20:51)
\1f
Date: 1 July 1980 23:32-EDT
From: Earl A. Killian <EAK at MIT-MC>
Subject:  ITS H19 support
To: MRC at MIT-AI
cc: BUG-TCTYP at MIT-MC, BUG-ITS at MIT-AI

Try :TCTYP VT52 +%TOLID which at least gets you line
insert/delete.  There is no excuse for :TCTYP HEATH or :TCTYP H19
not existing to do at least this.

\1f
Date:  1 JUL 1980 2202-EDT
From: MRC at MIT-AI (Mark Crispin)
Subject: ITS H19 support
To: (BUG ITS) at MIT-AI

Is there any chance that H19's will be added to ITS soon?  I'll use
:TCTYP VT52 for now since CRTSTY is too expensive, but these things
do seem to be becoming more popular.
\1f
Date: 1 July 1980 20:51-EDT
From: Eric J. Swenson <EJS at MIT-MC>
Subject:  Fair Share and the GAME program
To: MOON at MIT-MC, BUG-ITS at MIT-MC
cc: LPH at MIT-MC


I'm getting tired of people telling me that the GAME program bites the
royal... because of the system load restrictions (determined from the
system Fair Share and the number of users).  Here is a message from Leo
Harten (LPH@MC).  Is it possible that ITS is not calculating the fair share
correctly or is it just not a reliable indication of system load even when
averaged over time?  
----- [Mail from LPH] ----:
    the fair share determiner is not useful to trek players. when no one
    is running a job, fair share is 5%. if i start a macsyma running for 
    i:1 thru 1.e6 do (j:i); and then get 60% fair share, then i can play 
    trek!!! to have to start a running job in order to play games at 3 am 
    is ludicrous! there are 11 lusers right now, and since no one is 
    actively running anything, the fair share is artificially low. 
    is this a feature of the new dragon? (as in star trek: the motion
    picture, that's not a bug, that's a vejur!)
----- [End of Mail from LPH] ----
So is there anything wrong with Fair Share?  Is it an accurate measure of
anything or can it be used in place of a one-hundred-sided die?  -- Eric

\1f
Date: 30 JUN 1980 1451-EDT
From: MOON at MIT-MC (David A. Moon)
Subject: \e\e\ 6 is S L O W
To: SJK at MIT-MC
CC: (BUG DDT) at MIT-MC, (BUG ITS) at MIT-MC

    SJK@MIT-MC 06/30/80 00:02:03 Re: \e\e\ 6 is S L O W
    To: (BUG DDT) at MIT-MC, (BUG ITS) at MIT-MC
    Is there any reason for this command to be slower?  I've noticed it sorta
    pauses after each line.  This is a fairly recent occurrance, maybe's been
    this way for two weeks.  Anyone else notice this?   -sjk
This is because the buffer for printing directories and files in DDT
is preposterously small (80 characters), and an interaction with the job
implementing the DIR: device is required for each buffer-load.  RWK
has promised to fix this but evidently hasn't had time.
\1f
SJK@MIT-MC 06/30/80 00:02:03 Re: \e\e\ 6 is S L O W
To: (BUG DDT) at MIT-MC, (BUG ITS) at MIT-MC
Is there any reason for this command to be slower?  I've noticed it sorta
pauses after each line.  This is a fairly recent occurrance, maybe's been
this way for two weeks.  Anyone else notice this?       -sjk
\1f
MOON@MIT-MC 06/28/80 00:01:09 Re: KMP's halt at TTYI15+15 from :REATTA
To: KMP at MIT-MC, (BUG ITS) at MIT-MC, (BUG REATTA) at MIT-MC
CC: RLB at MIT-MC, JIM at MIT-MC
I have fixed this in the source (TS3TTY).  RMS, could you check the
change and make sure I didn't break anything?
\1f
KMP@MIT-MC 06/27/80 14:09:45
To: (BUG ITS) at MIT-MC, (BUG REATTA) at MIT-MC, KMP at MIT-MC
CC: RLB at MIT-MC, JIM at MIT-MC
I did :REATTA JIM /K from a terminal near Jim's to demo how REATTA works
(the terminal I did it from was t22 on MC). I then typed \1a to see where
we were in the reatta'd process, but nothing happened. The system had
halted at TTYI15+15 (a JUMPL B,[JRST 4,.] which has a comment saying that
the interrupting character belongs to no user). I suspect that REATTA and/or
ITS needs to do something about this potential timing error. Control-Z is
always the first char I type after a REATTA to get myself back to DDT where
I can figure out what's going on ... Maybe it can just turn off interrupts
-- will that help? -- or maybe ITS needs to be more tolerant of this type
of error and just dismiss the interrupt and pretend it didn't see the 
character. In any case, the bug makes me nervous since I suggest REATTA to
many of our users who get themselves dropped by the network...  This was
the nature of the system crash today at 12:15pm
-kmp

\1f
Date: 25 Jun 1980 1749-EDT
From: CSTACY at MIT-DMS (Christopher C. Stacy)
To: BUG-its at MIT-DMS
Subject: BUG => its
Message-id: <[MIT-DMS].152408>

On DMS with three users (one of them my crtsty)
I got a FS from :sstatus of 102%.
Is this broken?
Chris
----


\1f
Date: 27 JUN 1980 1108-EDT
From: KMP at MIT-MC (Kent M. Pitman)
To: (BUG ITS) at MIT-MC
CC: RWK at MIT-MC, (BUG EMACS) at MIT-MC, (BUG BABYL) at MIT-MC

I was running Babyl a little while ago and managed to get it into a wierd
state where it started sending all sorts of garbage to the terminal that
I just couldn't stop. I did \1a to get out of it -- that worked. My terminal
went back to normal. When I \eP'd the job, the stream of garbage continued.
After that, it was hard to tell if things were listening to me. I tried \1a'ing
out of it again, but that didn't give me any re-assuring signs that my
console was listening to me -- just streams of random characters displaying
mostly. After a while, I noticed that the output I was seeing when I typed
something was mixed part of the stuff I should be seeing and part of the
stuff I'd seen a while back -- eg, "QUIQU^ IXX ?" or something when I typed
\a ... Presumably the XX? was from the \ 4's earlier. I had
JONL gun me and after \1a'ing the console again and typing some \a's
I finally saw my console free message and the wakeup message from the \1a.
RWK told me to do \e.\e\e0G and :PDUMP the Emacs job -- it's written to 
MC:KMP;TS SCREW if someone wants to look at if -- Since it's running Babyl
and I don't want my mail clobbered, be extremely careful not to "Q" out
of it if you do want to look at it ... If it's not worth looking at, that's
fine by me. Send me a message saying so, so that I can delete the dump file.
-kmp

\1f
Date: 27 JUN 1980 0352-EDT
From: RMS at MIT-AI (Richard M. Stallman)
To: (BUG DDT) at MIT-AI, (BUG ITS) at MIT-AI

I have :TCTYP QUERY in my init file,
but very often I find that the bit has been cleared.
Someone just linked to me and it didn't query.
The bit was off.  He said he didnt patch it off,
so it must be a bug.
\1f
Date: 26 JUN 1980 0116-EDT
From: DLW at MIT-AI (Daniel L. Weinreb)
To: (BUG ITS) at MIT-AI

I just got :LUISERed by someone who was trying to create
a file using :CREATE and getting confused.  I hadn't known
there even WAS a :CREATE, but there is such a program; it appears
to be a simple TECO frob or something.  Anyone know what this is??
\1f
ZRM@MIT-MC 06/25/80 17:59:25
To: (BUG ITS) at MIT-MC
Having just fingered mc it occurs to me that listing
ctrstys as users is redundant and leads to more confusion than
information.
\1f
Date: 24 June 1980 20:59-EDT
From: Earl A. Killian <EAK at MIT-MC>
To: BUG-ITS at MIT-MC

Date: 23 Jun 1980 2153-EDT
From: ZEMON at MIT-DMS (Landon M. Dyer)
To:   BUG-crtsty at MIT-DMS
Re:   BUG => crtsty

        I have a slight problem.  I own a microcomputer
system upon which I have simulated a superimage mode (SUPDUP?)
terminal, i.e. a terminal which would (in theory) take the 'raw'
output stream from ITS (escaped by 177s, as documented in INFO
somewhere) and do nice (and fast) things without the aid of a
front end preprocessor like CRTSTY.

        I have all of the escape sequences & so forth working (I have
tested them out in local mode....), but to date my efforts to get
ITS to beleive in my SUPDUP terminal have been fruitless, if not
unspectacular -- ITS will either ignore me completely and continue
to treat me as a printing terminal, or it will "blow up" and
start sending me wierd and wonderful, if useless, control characters.

        1) How do I get ITS to beleive in me?  What bits must I
twiddle in order to get the ITS buffer output codes to work for me?

        2) If I can't get ITS to send me the buffer codes, how can
I use CRTSTY's SOFT terminal emulator?  (Having looked
at the listing for the SOFT front end it seems that that is about
what I have written to emulate -- but I can't get SOFT to work either.)

        It would be preferable to just set bits in DDT and not have
to take up an extra job slot, of course.

        Please answer -- I am badly in need of some help here.
You can send mail to either  zemon@mit-ai  or  dyer@nbs-10.

                        Thank you very much...

\1f
Date: 24 June 1980 20:59-EDT
From: Earl A. Killian <EAK at MIT-MC>
Subject:  not getting software TTY codes
To: ZEMON at MIT-DMS
cc: BUG-ITS at MIT-MC

You were using :TCTYP SOFT, and you weren't getting what looked
like ITS internal codes?  Maybe they were coming in their 200+
form instead of the 177 escape form?  Could you tell us in octal
what is sent when you type CR to DDT?

\1f
Date: 24 JUN 1980 0300-EDT
From: EB at MIT-AI (Edward Barton)
Subject: CLI device
To: (BUG ITS) at MIT-AI
CC: EB at MIT-AI

The system job deletes core link files which have not been referenced
for two minutes.  I do not believe that files which were opened as CLI:
(perhaps as opposed to CLO:) should go away if the jobs to which interrupts
were given still have those interrupts pending.  The effect of the current
practice is that a job which is ^Z'ed at the time it receives its CLI
interrupt may later get that interrupt but not be able to open CLA:.

Also, it would be nice if a channel open to CLO: could interrupt when
input became available....

\1f
CPR@MIT-MC 06/23/80 08:23:32
To: (BUG ITS) at MIT-MC
I got a 'all network ports in use' message as the 10th net tty...seems small.
\1f
GNU@MIT-MC 06/19/80 03:34:46
To: (BUG ITS) at MIT-MC
ITS seems to be flakier these days about when it types a colon (when in
monitor mode).  Often after running a program it will type *, ^W,
or nothing, requiring you to hit CR to get your input interpreted as 
a command.  What has happened?  Can it be fixed to always provide a colon?
In particular, :TCTYP *never* provides any prompt except ^W, and as I recall,
never has.  This ought get fixed.  (Does anybody who works there use
:monmode?  I've heard it referred to as "crippled mode", but since I 
don't have an ITS manual handy ever, I can't remember the obscure
("incompatible") random control-strange-char-preceded-and-followed-by-other-
strange-parameters "commands".

\1f
JPG@MIT-MC 06/19/80 02:52:46
To: CMA at MIT-MC
CC: ELLEN at MIT-MC, (BUG ITS) at MIT-MC
CMA@MIT-MC 06/18/80 14:24:25
the command :tctyp padcr 0 padlf 0 padtab 1 width 228
seems to disconnect me from the system.It has happened twice.

I don't see any way there could be a connection between the two.
Getting disconnected unfortunately is also too easy to happen even 
without this scenario.  Anyway, I am forwarding your mail to people 
who know more about these things.

\1f
JLK@MIT-MC 06/16/80 15:37:00
To: FILE-RETRIEVE at MIT-MC
CC: (BUG ITS) at MIT-MC
Why are half of the login and emacs init files in the world on pack 13?
I think this is a total loss.  I imagine if someone is on a vacation
or something, their whole directory gets put on pack 13, and they never
notice it until pack 13 crashes.  Can't this brain damaged dumping process
be made more clever?  The backlash from this is likely to be people
writing programs for their logout file that sets the don't reap bit
for all their files and copies them all to primary packs.  I spent half
the moring handling complaints from dozens of users who didn't understand
why none of their normal activities worked (login, emacs, mail, etc.).
I consider this to be a very serious lossage and hope steps can be taken
to make sure this doesn't happen again.  I suppose I can write a trival
program that fixes all directories after every dump, but it is a loss that
this should be necessary.

\1f
Date: 11 Jun 1980 1216-EDT
From: PDL at MIT-DMS (P. David Lebling)
To: BUG-its at MIT-DMS
Cc: TAA at MIT-DMS, SWG at MIT-DMS, WJN at MIT-DMS
Subject: BUG => its
Message-id: <[MIT-DMS].150758>

Copying WJN;WJN READER to WJN;AR0:_WJNRE > causes a crash at USRUUO+5(?).
This also happens (as an innocent experiment showed) in the newer ITS
when you copy AI:COMMON;WJN READER to AI:COMMON;AR0:_WJNRE >.  We didn't
realize the bug was so virulent.
        Dave


\1f
FMRC@MIT-ML 06/09/80 02:44:30
To: (BUG ITS) at MIT-ML
It is currently about 0240 EST and there is only one other user on.
And it is sunday/mondaymorn at that.  I just recieved a message from
SYSTEM OVERSEER saying that I am not supposed to be on right now.  This
is I hope a bug?
\1f
Date:  6 JUN 1980 2327-EDT
From: ED at MIT-AI (Ed Schwalenberg)
Subject: Translations
To: CBF at MIT-MC, CSTACY at MIT-MC
CC: (BUG ITS) at MIT-AI

There are two seperate losses which are being confused here.
There are a finite number of entries in the system translation
table; if an attempt to create a translation (TRANAD) is done
a DIRECTORY FULL error message is generated.  This virtually
never happens, and clearly did not happen in this case.

If a translation gets chased more than 64 or so times, it is
deemed to be losing and the error TOO MANY TRANSLATIONS
is generated.  I think from CSTACY's message he did
\14 DSK:FOO;MUMBLE MUMBLE
To:
*
which resulted in a translation from MUMBLE MUMBLE to itself.
He then did :PRINT MUMBLE MUMBLE and got the correct error
message.
\1f
ECC@MIT-AI 06/06/80 17:37:29 Re:  tip port 5
To: (BUG its) at MIT-ML
Apparently, ML thinks that MIT-TIP port 5 is room 508, which is occupied
by Kent, Sollins, and Ciccarelli.  Offhand, I don't know about the 508 --
that is probably still correct, but I'm not in that office (or group, for
that matter) anymore.



\1f
CBF@MIT-MC 06/06/80 17:43:32 Re: Translations
To: CSTACY at MIT-MC
CC: (BUG ITS) at MIT-MC
    CSTACY@MIT-MC 06/05/80 07:04:03
    There are too many translations active on MC. Can this happen?
    (If I interpreted the error messg correctly...)
    I tried to do a $^T which failed,
    also a :link command failed with "TRANS: - TOO MANY TRANSLATIONS".
    How dynamic is this situation, or is this really a bug?

No bug, the total number of translations is a fixed constant on each ITS.
IN general you should not make a translation unless there is no other good
way to accomplish the objective and it is highly anti-social to have more
than a few at any given time.

\1f
Date:  6 JUN 1980 0126-EDT
From: RMS at MIT-AI (Richard M. Stallman)
To: (BUG ITS) at MIT-AI

Closing another job's disk channel inside IODCL,
with U and P set up for that other job, got to QDEL11
which went to UUOTRO.  UUOTRO assumes that U and P are
set up to the job which is running.  So it called
ALOGOUT again which decided, since U was a which
had an inferior and 40 had .LOGOUT 1, to act like
a .BREAK.  Giving the interrupt eventually crashed
because it checked for LSWPR being nonzero.
I think that UUOTRO assumes that LSWPR is zero.
Probably UUOTRO should be changed to make these
things true or bomb immediately if they are not.
I can't say anything about the code in QDEL11
because that code is not in the DISK listing at all,
but it is probably a loss for any close routine to
go to UUOTRO.
\1f
CSTACY@MIT-MC 06/05/80 07:04:03
To: (BUG ITS) at MIT-MC
There are too many translations active on MC. Can this happen?
(If I interpreted the error messg correctly...)
I tried to do a $^T which failed,
also a :link command failed with "TRANS: - TOO MANY TRANSLATIONS".
How dynamic is this situation, or is this really a bug?
Thanks,
Chris

\1f
GJC@MIT-MC 06/02/80 16:23:55
To: (BUG ITS) at MIT-MC
I saw two detached HACTRO's today on MC, and they took an awful
long time to die after being gunned with peek. The status stayed
at *MULTIX for a couple minutes (near as I could tell), and
then they went away...

-gjc


\1f
JONL@MIT-MC 06/02/80 07:58:58
To: (BUG ITS) at MIT-MC
CC: (BUG DDT) at MIT-MC
:MOVE  seems to lose the "don't-reap-me" bit, and also
resets the reference date to time of :MOVEing.  There
ought to be a way to shuffle stuff to secondary or tertiary
packs without destroying this valuable information.

\1f
Date: 30 May 1980 0512-PDT
From: Scott J. Kramer <Scott at SRI-KL>
Subject: Well...
To: bug-pword at MC, bug-its at MC

:DDTSYM BYERUN is set non-zero, don't know exactly what.
-------

\1f
Date: 30 May 1980 0501-PDT
From: Scott J. Kramer <Scott at SRI-KL>
Subject: PWORD weirdness
To: bug-pword at MC, bug-its at MC

Wonderful bugs:

MC ITS.1191. PWORD.1733.
TTY 42
8. Lusers, Fair Share = 64%

*$$u
MC ITS 1191  Console 42 Free. 07:57:57

MC ITS.1191. PWORD.1733.
TTY 42
8. Lusers, Fair Share = 74%

*sjk$^A
(This person's mail is forwarded to CHNL NOT OPEN
Bad file = ^Q : ^Q ; ^Q  ^Q 
*$^A
(This person's mail is forwarded to 
Top level interrupt, tree detached

MC ITS 1191  Console 42 Free. 07:58:07

MC ITS.1191. PWORD.1733.
TTY 42
8. Lusers, Fair Share = 72%

*sjk$^A
(This person's mail is forwarded to CHNL NOT OPEN
Bad file = ^Q : ^Q ; ^Q  ^Q 
*$$u
These are the topics for which HELP can give more info.
Type:
:HELP <topic>
for more info on a given topic.

        ACOUNT  LOGIN   TCTYP   LUSER   ITS     JCL
        PRINT   LOGOUT  SEND    NAME    SSTATU  WHOJ
        BUG     WHO     DATE    TIME    TIMES   TIMOON
        OCTPUS  WHOIS   HELP    MAIL    QSEND   PRMAIL
        PRSEND  LISTF   USERS
*
*:logout

See Ya Later ___035... 
The plural of spouse is spice.

...and it hangs here.  And somehow :DDTSYM BYERUN is set to -1.
Rather bizarre...       -sjk
-------

\1f
RWK@MIT-MC 05/29/80 13:16:43 Re: Scheduler observations
To: (BUG ITS) at MIT-MC
Response to --MORE-- in peek can still take 15 seconds or so (although
not usually).  It's a lot better, but not perfect.  Also, I just gunned
down a job with "1000000" interrupt according to PEEK.  What is that
interrupt?  It took about 2 minutes for it to finally go away.  In
the meantime, it could not be :UJOB'd, its FLSINS was zero, its
state in PEEK was *MULTICS, its inferior disappeared at about the 1
minute mark, etc.  Also, HIC and I saw a hung tree.  A WHOLIN job was
hung waiting for output room, which isn't suprising but the HACTRN
was hung in USRI.  It went away OK when gunned (we were going to lunch,
not investigating the system).

A lot better than before, but still some quirks.

\1f
Date: 29 MAY 1980 0720-EDT
From: RWK at MIT-MC (Robert W. Kerns)
To: (BUG ITS) at MIT-MC
CC: SJK at MIT-MC

I'm not certain SJK's suggestion should be done.  When I use DIR:, I often
use it in more than one mode.  However, I'm probably just abnormal.  Second
opinion?

\1f
RWK@MIT-MC 05/29/80 06:16:14
To: (BUG ITS) at MIT-MC
FIRST: should be a synonym for writing to a primary pack, for the benifit
of allocated directories.

\1f
GJC@MIT-MC 05/28/80 14:23:41
To: (BUG ITS) at MIT-MC
CC: CL at MIT-MC, JLK at MIT-MC
T36 seems to be wedged.

\1f
RWK@MIT-MC 05/27/80 15:57:22 Re: Schedualer lossage
To: (BUG ITS) at MIT-MC
CC: JM at MIT-MC, ELLEN at MIT-MC, JPG at MIT-MC
Fooi, I sent mail before but it log lost in the crash.  Anyway, there
definitely IS a problem, but it's not just that performance is bad.  There
is a screwy interaction at work here between interrupts and I/O and the
scheduler.

When a job has non-defered pending interrupts, SCHACK does not skip-return,
leading to doing a full schedual.  I think this relates to the problem, in
that only jobs with pending interrupts are scrod.  Because they only get run
when a full schedual is done, they can be heavily discriminated against under
some circumstances.  I'm not sure just what those circumstances are, but PEEK
is screwed in --MORE-- but not elsewhere.  This only happens during heavy load,
presumably because the full schedual then happens more often.

These observations are based on a lot of poking around, with H19WHO keeping me
informed of the state of my current job.

1)  EMACS does it's input in a single big SIOT, getting MPV's along the way,
which it handles and creates the core.  Unfortunately, these interrupts may
take a very long time to go off, and it won't be schedualed until they do.

2)  PEEK .SLEEP's except during the --MORE-- break, where it waits in an input
.IOT ... which never returns, since when you type a space, the %PITYI interrupt
is asserted in .PIRQC, but NEVER GOES OFF.  If you clear this interrupt,
disable %PITYI in .MASK, type the space, it reads the space.  Then of course
you have to restore the mask, since PEEK reads it's commands at interrupt
level.

3)  When COMSAT loses, getting schedualed but every minute or so, I've checked,
found the pages required in core, at an ordinary BLT or TLNN etc., and with
a %PIRLT interrupt that WAS NOT GOING OFF.  Eventually the load would drop and
it would run.

4)  DDT sometimes doesn't get its interrupt when the inferior is ^Z'd, while
it's sitting in it's .HANG  I also saw a .DTTY take 20 seconds, I don't have
any other clues on that.  Oddly enough, giving DDT a ^G seems to wake it up
when it's hung in that manner.  Perhaps the TTY driver manages to frob it in
just the right way to make it run again, I don't know.  Or maybe it just
happened to get schedualed when I typed &^G, but that seems unlikely; why
didn't it get schedualed for 15 seconds before that?

Anyway, I hope this is enough to track down the problem.  The threshold of
load before it shows up is fairly high, requiring many runnable jobs.  Probably
enough to fill SCHBTB or something and just sit there keeping it full.

\1f
RWK@MIT-MC 05/27/80 12:00:50 Re: Slowness
To: (BUG ITS) at MIT-MC
CC: JM at MIT-MC
I'm not so sure that the reported slowness of disk I/O is anything other
than very heavy disk loading.  Looking at the channels listing in peek, we're
often in the 20-25 channel range, and it's not uncommon for there to be 15
competitors for one disk drive.  Normal is more like 15-20 range, with maybe
8-10 competitors for a drive.  Today seems to be more disk intensive than usual
for some reason.  TY is doing a DUMP.  There are several compilers and TEX jobs
plus the dover spooler and PFTHMG and ...

I've seen the system grind to a halt when there were 25 channels in use before.
And indeed, when it drops back down to normal, it doesn't seem grossly slower
than usual, although I can't assert it's normal.  Under the 25-channel load,
I read SYSEN1;DDT > (98 blocks) into an EMACS in 110 seconds, watching with
H19WHO updatng every 5 seconds.  Only 4 samples out of that period of 22 were
in other than +DSKBI.  Under conditions of about 18 channels in use the time
was 65 seconds with only one sample not in +DSKBI.  65 seconds is not
inconsistant with times I've observed before under "similar" load.  It has also
been observed by many people that the system is much less responsive WRT disk
I/O when a dump is being taken.

Disclamer:  The above observations do not show that the system is performing as
well as before.  My only assertion is that the data doesn't show it when
balanced with the load observed. and the lack of a control case.  "Before" data
would be necessary to make any reasonable judgements.

Further Disclamer:  The above does not mean that I think the schedular is
working 100% right.  There are other clear problems with it.  Have yo utried
continuing a --MORE-- break in PEEK lately?

BTW, ITS doesn't use an elevator algorithm for its disk I/O does it?
110 seconds for 98 pages against say 12 competitors for one disk drive
looks to me about right for randomly contending competitors, no?  This works
out to about 10 seconds for the single user, with having it seek the block,
then wait until the next schedual to transfer the block to the user's address
space (perform the SIOT) and queue up the next transfer.  I.e. about 1/10
second for each pair of seek/xfer and schedual.

Maybe elevator algorithm might be worthwhile during the heavier load
situations?  Also, read-ahead when you encounter an extent of more than one
block might help.

Maybe we should run the old system sometime in the daytime and take some
performance measurements to compare with the current situation?

\1f
Date: 27 May 1980 10:32-EDT
From: Earl A. Killian <EAK at MIT-MC>
Subject:  ITS 1188 is slower.
To: BUG-ITS at MIT-MC
cc: CBF at MIT-MC

I agree; reading my large Babyl file into TECO took much much
longer just now than it ever has under similar load.

\1f
CBF@MIT-MC 05/27/80 09:01:58 Re: ITS 1188 is slower.
To: (BUG ITS) at MIT-MC
ITS 1186 is slower
It seems to take longer to do some things, ie. get into Rmail or Info.
Quit starting seems to help.  (ie. ^Z $P).
This claim is based on response time vs. my past experience at various
loads.  I havn't tried to do any quantitive measurement.

\1f
GLS@MIT-MC 05/26/80 17:35:09
To: (BUG ITS) at MIT-MC
See MC:CRASH;HALTPC 5550  for a crash at PC 5550 (see log).
\1f
Date: 12 MAY 1980 2214-EDT
From: KLH at MIT-AI (Ken Harrenstien)
Subject: Tabs
To: ED at MIT-MC
CC: (BUG ITS) at MIT-AI

    ED@MIT-MC 05/12/80 21:38:18 Re: Tabs
        This line begins with a tab.  However, it echoes and redisplays
    consistantly with only one blank space at the beginning.
                This line begins with two tabs.  It has 8 blank spaces.
    It appears to only happen at the beginning of the line.  This is
    on a C100, using :tctyp c100.

This appears to be an ITS problem; I cannot make it happen via
software-TTY, so it must be C100 specific.
\1f
KMP@MIT-MC (Sent by ___131@MIT-MC) 05/10/80 23:39:34
To: (BUG ITS) at MIT-MC
The system console stopped typing out at 20:02 tonight. The console 11's
lights are locked on ... it looks kinda out of it ... I asked RG who advised
not doing anything and just waiting until the system goes down voluntarily,
so I'm leaving it be. -kmp

\1f
CBF@MIT-MC 05/10/80 21:18:52 Re: strange occurances on T13 (the first Vadic 3467 line)
To: ASB at MIT-MC, (BUG ITS) at MIT-MC
CC: KMP at MIT-MC, ELLEN at MIT-MC, SK at MIT-MC
It is more than obvious that the T13 is not detecting hangup.  (Ie. either
the modem card, the wires from it to the DH-11, the DH-11, the tables in
the I/O-11, the I/O-11, the tables in ITS, ITS, the KL-10 or something in
the path is broken).  Someone might look into fixing it before half the
disk is taken up by bug reports.

\1f
ASB@MIT-MC 05/10/80 16:05:04 Re: ADDENDUM TO PREVIOUS NOTE
To: (BUG ITS) at MIT-MC
CC: KMP at MIT-MC, SK at MIT-MC, ELLEN at MIT-MC, ASB at MIT-MC
I now find that although <cr> wake-up still fails, CNTL-Z works fine.
The TCTYP was apparently irrelevant.

\1f
ASB@MIT-MC 05/10/80 14:47:44
To: (BUG ITS) at MIT-MC
CC: KMP at MIT-MC, ELLEN at MIT-MC, ASB at MIT-MC, SK at MIT-MC
I have repeatable problems characterized by the following:

[1] My equipment:
    ADM-3A thru VADIC 3434 over FTS 835-6985
[2] Procedure:
    Dial the phone no. get CXR light on VADIC indicating carrier locks.
    Type a <cr>, observe TXD light on vadic flash, indicating that <cr>
       was successfully transmitted.  No answering flash of RXD light on
       VADIC, indicating that the return copy of <cr> is not received.
    Repeat the <cr> transmission and return-receive failure as many times
       as desired.  I have done it 10 times with identical behavior.
    Type  :TCTYP FULL <cr> into MC.  After each character I notice the
       TXD flash, but no RXD flash.  No response yet.
    Type CNTL-Z .  Now the machine wakes up and transmits the banner:
       MC ITS.1168.PWORD bla bla
       TTY whatever
       ## LUSERS etc bla bla
    Now I find that I can log in.  
    After doing so, I do :P O and the line corresponding to me reads

13    137    ASB    P    T1061     24     80          X <- 


       which I interpret to mean that the systems thinks my terminal
       is T1061.

Perhaps I somehow told it this, though I am unaware of having done so.
I have repeated this process successfully 3 times in the last 1/2 hour.

\1f
ASB@MIT-MC (Sent by ASB0@MIT-MC) 05/09/80 18:46:32
To: (BUG ITS) at MIT-MC
CC: TYANG at MIT-MC, KMP at MIT-MC, CWH at MIT-MC
Logged in as ASB, I tried to log in again thru a printing terminal
to get a short listing.  I found that I was attached to a tree belonging
to TYANG, and could not log in on my own.  So I detached his tree,
logged in and all was well.

\1f
Date:  9 MAY 1980 1611-EDT
From: RICH at MIT-AI (Charles Rich)
To: (BUG ITS) at MIT-AI

It is very irritating that the DVR^F command leaves the default
device set to DVR: so that, for example, subsequence :PRINT
commands which do not explicitly specify AI: or DSK: in the
filename fail.  The XGP^F command, on which DVR^F is assumedly
modelled, does not have this problem.
\1f
Date: 9 May 1980 08:29-EDT
From: Kent M. Pitman <KMP at MIT-MC>
Subject: Here's another one...
To: BUG-ITS at MIT-MC

Date: 05/09/80 05:08:05
From: DLW at MIT-AI
To:   KMP
Re:   MC dialup failure on 5/8/80

Just for the record, I also have been unable to make 253-6985
respond to CR.

\1f
RWK@MIT-MC 05/09/80 02:12:41
To: KMP at MIT-MC, GZ at MIT-MC, DANIEL at MIT-MC
CC: (BUG ITS) at MIT-MC, (BUG PWORD) at MIT-MC
If someone would be so kind as to tell me which TTY line does not get PWORD,
I would be fix it.  Noone has cared to tell me yet.  It is hardly necessary
to send to note to all of BUG-ITS to get this fixed.  A single responsible
bug report would do it.  I am sure you are aware I do not have a modem in
my office, let alone a vadic triple-speed.

\1f
KMP@MIT-ML 05/09/80 02:06:32
To: (BUG PWORD) at MIT-ML
CC: GZ at MIT-ML, (BUG ITS) at MIT-ML, DANIEL at MIT-ML, KMP at MIT-ML
People have complained to me about dialing MC (GZ) and ML (DANIEL) and getting
DDT instead of PWORD on occasion in the last couple of days. Something might
be mixed up.

\1f
KMP@MIT-MC 05/09/80 02:04:03
To: (BUG ITS) at MIT-MC
CC: ASB at MIT-MC, SK at MIT-MC, ELLEN at MIT-MC, KMP at MIT-MC
I got multiple reports this evening of dialing 7985 and <Return> not waking
up MC ... Something may be messed up. ASB's line was also 1/2-dpx for unknown
reasons (said he did not :Tctyp Half) on it and doesn't know how it got into
that mode but he wasn't seeing anything he was typing for a while and
:Tctyp Full corrected the problem.
-kmp

\1f
RWK@MIT-MC 05/09/80 01:18:30
To: (BUG TECO) at MIT-MC, (BUG ITS) at MIT-MC
It seems that EMACS can't be ^P'd while running a keyboard macro, because
it keeps doing .CALL of TTYGET.  Now while I doubt that TECO needs to be
doing .CALL of TTYGET while doing a keyboard macro, on the other hand it
should not require the TTY to do such a call, but should get the information
out of .TTST1 and .TTST2 and TTSTS per-job variables.

\1f
KMP@MIT-MC 05/03/80 00:07:15
To: (BUG ITS) at MIT-MC, (BUG OS) at MIT-MC
CC: RWK at MIT-MC
There exists an AI:SYSENG;OS 93,95,and 96. 95 and 96 seemed to have been
victims of hacks, so I deleted them and re-installed 93 which seems to work
fine. -kmp

\1f
RWK@MIT-MC (Sent by ___106@MIT-MC) 05/03/80 00:04:13 Re: OS
To: RICH at MIT-MC
CC: (BUG ITS) at MIT-MC, (BUG OS) at MIT-MC, KMP at MIT-MC
KMP fixed OS; it had been vandalized.

\1f
Date:  2 MAY 1980 2342-EDT
From: RICH at MIT-AI (Charles Rich)
To: (BUG OS) at MIT-AI, (BUG ITS) at MIT-AI

The :OS program seems to be broken.  Regardless of whether it is
given a logged in user name or not, it just does a <cr> and
kills itself.
\1f
Date:  1 MAY 1980 1959-EDT
From: ED at MIT-AI (Ed Schwalenberg)
Subject: infinite translation
To: GLS at MIT-AI, (BUG ITS) at MIT-AI, (BUG EMACS) at MIT-AI
To: RWK at MIT-MC
CC: DUFTY at MIT-MC, ELLEN at MIT-MC, JPG at MIT-MC

    GLS@MIT-AI 05/01/80 17:11:40 Re: infinite translation
    Maybe making an infinite translation may be permitted, but ITS should
    certainly put an upper limit on the number of translation iterations
    (it does the same for links).  An obvious such limit is the size
    of its internal translation table (which is fixed)!
ITS already does this.  EMACS attempts to open the ERR: device, and if that
open fails, for ANY REASON including Too Many Translations, it simply tries
again.  The historical reason for this may lie in the fact that many programs
(including TECO itself) were exhibiting the malfeasance of failing to CLOSE
the ERR device when done, and the system would occasionally get wedged due
to this.  A suitable PEEK mode was invented, and TECO at least was fixed to
close ERR when done, but this business of reexecuting a failed OPEN was not.
\1f
GLS@MIT-AI 05/01/80 17:11:40 Re: infinite translation
To: (BUG ITS) at MIT-MC
CC: RWK at MIT-MC, DUFTY at MIT-MC, ELLEN at MIT-MC, JPG at MIT-MC
    RWK@MIT-MC (Sent by ___010@MIT-MC) 05/01/80 05:25:35 Re: infinite translation
    DUFTY had a translation of IO *:*;* * => *:*;* * in his EMACS.
    When it runs, it runs infinitely in OPEN.  ITS really should forbid such
    a translation, since it causes the system to lose totally, with the time
    hidden from view (it does not show up in PEEK).  Fair share dropped to
    2%, with about 10% going to users, and the rest just disappearing.  Anyway,
    probably the "right" thing to do is for ITS to detect attempts to define
    infinite translations, and return an error.  Of course, DDT could detect
    this obvious case.


Maybe making an infinite translation may be permitted, but ITS should
certainly put an upper limit on the number of translation iterations
(it does the same for links).  An obvious such limit is the size
of its internal translation table (which is fixed)!


\1f
Date:  1 MAY 1980 0943-EDT
From: ED at MIT-AI (Ed Schwalenberg)
Subject: infinite translation
To: (BUG ITS) at MIT-AI, (BUG EMACS) at MIT-AI, RWK at MIT-MC
CC: DUFTY at MIT-MC, ELLEN at MIT-MC, JPG at MIT-MC

The real bug here is in Emacs, which if the OPEN of the ERR: device
fails simply retries.  I complained about this some time ago.

The fact that DDT will create an infinite translation
entry of this sort by way of the user typing \14<return><return>, is
perhaps at fault.  Maybe there should be YET ANOTHER DDT flag, or an
improvement to one of the existing ones, which would turn off nearly
all short commands which naive users would never want (\ 2, \ f, \14 are
the "destructive" ones that come immediately to mind).
\1f
SJK@MIT-ML 05/01/80 07:10:54 Re: \12 DIR: ...
To: (BUG its) at MIT-MC
This isn't really a bug, just a suggestion.  When one is using the DIR:
"device" and does, for example, \12 DIR:LISP;CDATE DOWN and then does a
\12 .INFO.;  (ie no change to FN1 or FN2) the DIR: has been changed back
to DSK: and the command barfs.  But if one changes only FN1 and/or FN2
then a MODE NOT AVAILABLE error occurs.  This really seems to be the
opposite of what should happen, DIR: should be "sticky" if only the
directory names is changed, otherwise it can revert back to DSK: if
filenames are changed.  I'm open to arguments for its present method
of operation but vote that this be changed in the future if possible.
Thanks.         -sjk

\1f
RWK@MIT-MC (Sent by ___010@MIT-MC) 05/01/80 05:25:35 Re: infinite translation
To: (BUG ITS) at MIT-MC
CC: DUFTY at MIT-MC, ELLEN at MIT-MC, JPG at MIT-MC
DUFTY had a translation of IO *:*;* * => *:*;* * in his EMACS.
When it runs, it runs infinitely in OPEN.  ITS really should forbid such
a translation, since it causes the system to lose totally, with the time
hidden from view (it does not show up in PEEK).  Fair share dropped to
2%, with about 10% going to users, and the rest just disappearing.  Anyway,
probably the "right" thing to do is for ITS to detect attempts to define
infinite translations, and return an error.  Of course, DDT could detect
this obvious case.

\1f
Date: 28 APR 1980 0337-EDT
From: cstacy at MIT-AI (Christopher C. Stacy)
Sent-by: ___020 at MIT-AI
To: (BUG ITS) at MIT-AI

the same thing just happenned again!
Chris Stacy
\1f
Date: 28 APR 1980 0326-EDT
From: CSTACY at MIT-AI (Christopher C. Stacy)
Sent-by: CSTAC0 at MIT-AI
To: (BUG ITS) at MIT-AI

I was logged out with the normal console free message,
but I did not issue a logout command of any sort. I was
apparently not being gunned. When I Zd back up and logged
in, I was logged in as CSTAC0...ie, no detatched trees!?!
This occurred on AI. Whatsit mean???
Chris
\1f
CBF@MIT-MC 04/27/80 15:15:39 Re: Archive device
To: (BUG ITS) at MIT-MC
The file AR6:CBF;1980 MINS seems to be perpetually locked.  There is no
job which has it open.  Can this be repaired and is there a procedure
for repairing should this occur again?

\1f
Date: 25 April 1980 14:00-EST
From: Robert W. Kerns <RWK at MIT-MC>
Sender: ___126 at MIT-MC
To: BUG-ITS at MIT-MC

If the number that PEEK prints just after the foreign address is the
foreign connection number, then a second LSN by another job while waiting
for the other host to get the OPN can somehow get the same connection!
The number PEEK printed was identical for both jobs.

See HMR;.PEEK. >, the number 12541 is the one I'm talking about.

Am I misunderstanding what I'm seeing or is this an ITS bug?

(Note that while the state shown is INCXMT, there was a period while they
were both in OPEN)

\1f
Date: 20 APR 1980 1943-EST
From: EB at MIT-AI (Edward Barton)
To: (BUG ITS) at MIT-AI

Why is it that when logging in from a dialup or a STY (with :PTY)
that one gets the message "Tremont is Spooling and waiting"
before the AI ITS.1168 etc ??
\1f
Date: 14 Apr 1980 (Monday) 2358-EDT
From: WESTFW at WHARTON (William Westfield)
Subject: :F  SEEMS TO BE MESSED UP
To:   BUG-ITS at MIT-ML

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


\1f
SAM@MIT-AI 04/08/80 21:21:30
To: (BUG its) at MIT-ML
One of the ML dialups is very bad.  It starts out fine then worsens
to the point where you can't get any characters over the line.
Its one of the 300 baud ones.  I have no way of saying which
it is,
--Sam


\1f
Date:  4 APR 1980 2026-EST
From: JNC at MIT-AI (J. Noel Chiappa)
Sent-by: ___050 at MIT-AI
Subject: Logging in on AI...
To: (BUG ITS) at MIT-AI

        Gets you the message "84375 Memory errors in 23.4 Hours".
Is this machine serious, or do I detect little elves at work?
\1f
EAK@MIT-MC 04/01/80 17:34:17
To: (BUG ITS) at MIT-MC
"MC TOPS-20 V4.0 Console 60 Fried"?

\1f
Date: 29 MAR 1980 1249-EST
From: AGRE at MIT-AI (Philip E. Agre)
To: (BUG DDT) at MIT-AI, (BUG ITS) at MIT-AI
CC: AGRE at MIT-AI

I think that the "excessive tourist usage may lead to a restricted policy"
clause in the MIT-AI ITS login message sounds like a very unfriendly threat.
I don't think that we have made sufficient efforts yet to explain to 
tourists exactly what the state of the world is and what is the behavior
that is expected of members of the MIT-AI community.  Such explanations
should be made, and individuals who refuse to cooperate with us should
be singled out for threats rather than just threatening hundreds of our
guests for the misdeeds of a few.  (And there ought to be more to this than
an occasional flame by someone who has discovered a new form of tourist
ignorance or misbehavior.)    - Phil
\1f
Date: 28 MAR 1980 1707-EST
From: JERRYB at MIT-AI (Gerald R. Barber)
To: (BUG ITS) at MIT-AI

What happened to fido?  I hope he didn't die of old age.
\1f
Date: 26 MAR 1980 2207-EST
From: KLH at MIT-AI (Ken Harrenstien)
To: (BUG ITS) at MIT-AI

SYSMSG should show more stuff.  Nowadays things happen so
fast (logins/outs) that if, e.g. my net connection breaks,
by the time I get back 2 minutes later (yes two minutes)
any evidence as to the nature of the lossage has long vanished
from the minor fragments SYSMSG knows about.  Foo.
\1f
Date: 25 MAR 1980 1908-EST
From: MOON at MIT-MC (David A. Moon)
Subject: DIRHNG:
To: EBM at MIT-XX
CC: (BUG its) at MIT-AI

    Date: 25 Mar 1980 1118-EST
    From: EBM at MIT-XX
    Subject: DIRHNG:
    To: bug-its at MIT-AI

    I believe that creating new links in a directory should also result
    in an interrupt on the channel open to the DIRHNG: device.  
It does.
                                                                [Also,
    I have always believed that one should be able to read the device,
    which will result in hanging until a file is closed.  The data
    returned could be garbage, or 0 -- it does not matter.  The point
    is that one should not be REQUIRED to use interrupts for such
    things if they are unnecessary.]  
Maybe, but interrupts are trivial to use.
                                      Having a piece of documentation
    available on DIRHNG: would be nice, too.  E.g., :call open, or
    something.
Yes, it should be.

\1f
Date: 25 Mar 1980 1118-EST
From: EBM at MIT-XX
Subject: DIRHNG:
To: bug-its at MIT-AI

I believe that creating new links in a directory should also result
in an interrupt on the channel open to the DIRHNG: device.  [Also,
I have always believed that one should be able to read the device,
which will result in hanging until a file is closed.  The data
returned could be garbage, or 0 -- it does not matter.  The point
is that one should not be REQUIRED to use interrupts for such
things if they are unnecessary.]  Having a piece of documentation
available on DIRHNG: would be nice, too.  E.g., :call open, or
something.
-------
\1f
Date: 24 MAR 1980 2012-EST
From: agre at MIT-AI (Philip E. Agre)
Sent-by: GJS at MIT-AI
To: (BUG ITS) at MIT-AI

How about a program that asks all tourists to log out?
\1f
Date: 24 MAR 1980 1915-EST
From: AGRE at MIT-AI (Philip E. Agre)
To: (BUG ITS) at MIT-AI

Is there a program that says "change working directory to my home directory"?
\1f
Date: 24 March 1980 17:24-EST
From: "Guy L. Steele, Jr." <GLS at MIT-AI>
Subject: Comma in ^O filespec loses!!
To: KLH at MIT-AI, BUG-ITS at MIT-AI, BUG-DDT at MIT-AI

It is semi-well-known that a comma ends a filespec in DDT, as does
a CR; CR in addition ends the command.  Consider :RENAME, for example;
if you type :RENAME FOO GREPS\e,BARF GREPS\e the comma terminates
the first file name and the second altmode redisplays the second
file name.  This is actually useful.  However, had one used
\ f instead of :RENAME (\e\e\ f), then the comma terminates the
command, but the command doesn't "run" until the second altmode
is typed.  Moreover, any stuff after the comma is lost -- the second altmode
doesn't redisplay it or anything.  Maybe for safety's sake the number
of commas should be counted and a complaint registered if there are
too many.  Also, typing an altmode should NEVER cause the command to be run!
The whole point is to be able to see the name of the file you are
about to dastardly mung.
\1f
Date: 21 MAR 1980 2132-EST
From: KLH at MIT-AI (Ken Harrenstien)
Subject: Comma in ^O filespec loses!!
To: (BUG ITS) at MIT-AI, (BUG DDT) at MIT-AI

Goddamit, I did an ^O and it said that it was about to
delete ".FOO X".  I typed in ",FOO X" which was what
i really wanted to delete (the comma was mis-typed in an append
command), and the '"'$)#$)"#%#("$'$ went ahead and screwed me
by flushing the original ".FOO X" file!!!!   Snarrrl!!
Just what meaning is a comma supposed to have in a delete
command anyway???  The FN1 wasn't changed at all....
you'd at least have expected it to try deleting "FOO X".
\1f
Date: 20 MAR 1980 0913-EST
From: RICH at MIT-AI (Charles Rich)
Subject: Device Handling
To: ED at MIT-AI, MOON at MIT-AI
CC: (BUG ITS) at MIT-AI

Ok, with the help of your replies I think I understand the
problem:  the various machines do not recognize THEMSELVES
as a valid device combined with ARn in the same way as
other machines.  This makes it much less convenient to write
code which will run on any machine.

For example, on AI

        :LISTF AIAR3:RICH;

doesn't work, but on other machines it does.
Ed, you are right, the extra colon was never right;
the form

        :LISTF AI:AR3:RICH;

only worked on AI because the first AI: was thrown away.

        I now think we have now narrowed this down to an
honest-to-goodness bug.

        Thanks, Chuck.
\1f
Date: 20 March 1980 03:09-EST
From: Ed Schwalenberg <ED at MIT-AI>
Subject: Device Handling
To: RICH at MIT-AI, BUG-ITS at MIT-AI

    On AI you type
        :LISTF ML:ARn:UNAME;
I can' believe that this ever worked, or could work.  It certainly
does not work now.
        :LISTF MLARn:UNAME;
This has always been the form recognized by ITS.  The unknown device
handler checks to see if the first 2 chars are a machine name, and hands
the rest of the device name to that machine. Inserting an extra : will
cause most filename readers to ignore the ML: by clobbering the device
field with ARn:.  The exception is :FIND, which makes a LIST of all
devices (and directories) to be searched.  Is it possible you were led
down the garden path by having similar archives on 2 machines?  Experiment
with the MLTTY: device and you will see that MLTTY: gives you ML's, ML:TTY:
gives you AI's (TTY:) and TTYML: gives you NO SUCH DEVICE (the FIRST 2 chars
must be the machine name.
\1f
Date: 19 MAR 1980 1824-EST
From: RICH at MIT-AI (Charles Rich)
Subject:  Device Handling
To: (BUG ITS) at MIT-AI

On AI you type

        :LISTF ML:ARn:UNAME;

to refer to an archive on another machine, but
on DM you type it without the extra colon, i.e.

        :LISTF MLARn:UNAME;

to get the same effect.  The alternative form on
either machine loses.  Sigh... it would be nice
if it were compatible, no?
\1f
Date: 17 March 1980 21:12-EST
From: Ed Schwalenberg <ED at MIT-AI>
To: AGRE at MIT-AI, BUG-ITS at MIT-AI
cc: SHADOW at MIT-AI

    Date: 17 MAR 1980 1509-EST
    From: AGRE at MIT-AI (Philip E. Agre)
    Sent-by: SHADOW at MIT-AI

    I did agre<alt>ctl-s then :xfile agre;agre login on shadow's terminal,
    so I could read my mail without logging shadow out.  It did all the
    gmsgs's right, but when it finally called :rmail, it did it on shadow's
    mail file.  agre<alt>ctl-s :rmail works right, so I suspect that
    the agre<alt>ctl-s wasn't able to distribute over the whole :xfile
    execution.  This led to a rather embarrasing error.  Can it be fixed,
    or is it a feature?    - Phil
From DDT ORDER:
<user>$^S
        causes the next ^K, ^H or :-command, if it runs a program, to
        run it "as if <user> were running it".  Precisely, its .XUNAME
        variable will be <user> instead of you and its .HSNAME will be set to
        <user>'s HSNAME.  If the program follows the current convention, it
        will use <user>'s init file, etc.  $^S works by setting the ..TUNAME
        and ..THSNAME variables.
Since your XFILE runs 2 programs, you lose.
\1f
Date: 17 MAR 1980 1509-EST
From: AGRE at MIT-AI (Philip E. Agre)
Sent-by: SHADOW at MIT-AI
To: (BUG ITS) at MIT-AI
CC: SHADOW at MIT-AI

I did agre<alt>ctl-s then :xfile agre;agre login on shadow's terminal,
so I could read my mail without logging shadow out.  It did all the
gmsgs's right, but when it finally called :rmail, it did it on shadow's
mail file.  agre<alt>ctl-s :rmail works right, so I suspect that
the agre<alt>ctl-s wasn't able to distribute over the whole :xfile
execution.  This led to a rather embarrasing error.  Can it be fixed,
or is it a feature?    - Phil
\1f
Date: 15 MAR 1980 2140-EST
From: KLH at MIT-AI (Ken Harrenstien)
To: EAK at MIT-MC
CC: (BUG ITS) at MIT-AI

    Date: 9 February 1980 13:00-EST
    From: Earl A. Killian <EAK at MIT-MC>

    How about changing the definition of %TDICP n from being "insert
    n blanks in the current line" to being "insert next n characters
    in the current line"?  I suspect that no programs would have to
    change (i.e. TECO wouldn't).  The reason for the chnage would be
    to allow insertion to happen more reasonably on some terminals
    (in particular those with an insert character mode), without
    making it any less efficient for terminals like TVs or the
    Teleray.  CRTSTY would make use of the new constraint on what can
    follow a %TDICP, and maybe ITS could too.

I don't think it would be a good idea to change the %TDICP definition.
The idea is certainly clever, but I am paranoid about what could
happen if the output stream was interrupted or otherwise disrupted
while counting down these N characters, since this is also in effect
quoting the next N characters.  It seems much more robust to have a
way to enter insert-char mode and leave it; then a reset of this mode
would always be effective.  It would also be just as efficient, since
a %TDICP N is two characters plus the string, whereas a %TDSIC and
%TDEIC (Start & End insert-char mode) is also just two chars plus the
string.  I don't see anything wrong with having more %TD codes, except
that a TTYOPT bit might be needed to say whether the terminal could
handle it or not; if not, ITS would just simulate it with %TDICP's.
\1f
MOON@MIT-MC 03/14/80 10:50:49 Re: Your bug report about translations
To: KMP at MIT-MC
CC: (BUG ITS) at MIT-MC, ECC at MIT-AI
Presumably the underlying cause is that translations don't affect the
RENMWO system call.  It is not obvious that they should, or what would
be a consistent way of doing so.  Fortunately translations are mainly
useful for devices and directories rather than file names.
\1f
KLH@MIT-MC 03/14/80 04:59:05
To: (BUG ITS) at MIT-MC
I think someone has barfed about this before, but...
Is it really the right thing to turn foo < into foo >
when writing??

\1f
KMP@MIT-MC (Sent by TURNIP@MIT-MC) 03/14/80 04:46:16
To: (BUG ITS) at MIT-MC, KMP at MIT-MC, ECC at MIT-AI
CC: (BUG GMSGS) at MIT-MC
Sigh. This 'feature' of writing to a temp file turns out to affect GMSGS
for ECC ... We were just trying to isolate simpler cases, but the original
('real') attempt was to get GMSGS to output to a different file than
xuname MAIL ... Its writing to a temp file and then Rename-While-Opening
without checking translations is what prompted all this I guess.

\1f
ED@MIT-AI 03/14/80 02:56:10
To: ECC at MIT-AI, KMP at MIT-MC, (BUG ITS) at MIT-MC
Both TECO and DDT are too smart for their own good, sometimes.
The file OPENed in both cases (and thus subject to translations)
is KMP;_TECO_ OUTPUT (or _COPY_  for DDT.).  When the file is completely
written, it is RENMWOed to FOO BAR, which operation is NOT subject
to translation.
There is a teco command to write output directly without renaming,
search for "core link" in TECO ORDER for suggestions.

\1f
KMP@MIT-MC 03/14/80 01:07:49
To: (BUG ITS) at MIT-MC, ECC at MIT-AI
CC: KMP at MIT-MC
Doing \e\14 KMP;FOO BAR,KMP;BAR FOO on MC and then :CREATE'ing KMP;FOO BAR
still creates the file FOO BAR. :COPY TTY:, ... gives similar results
so I doubt this is a Teco problem. When I try to read the file, I get
a file not found error because an input translation has been created but
not an output translation... o\e\14 ... produces the same results. In the
former case, PEEK shows that there exists an IO translation. In the latter,
it says there is just an output translation -- but in neither does it
keep from writing to FOO BAR as a truename as it should. Can someone please
fix this or tell me why I am misunderstanding what output translations
are capable of? Thanks.
-kmp

\1f
Date: 13 MAR 1980 1857-EST
From: JERRYB at MIT-AI (Gerald R. Barber)
To: (BUG ITS) at MIT-AI


One outcome of the disk storage crunch getting worse and worse is that there
will be more randoms deleting random files.

It seem like a program that would combine the facilities of COMMON;FIND JUNK
and DIRED would be useful.  In addition, it would keep track of what files
were deleted and who deleted them.  In this way people would be less tempted
to do rash deletions.  It might do other things such as refusing
to delete files that have not been backed up, files that are > versions and
files where the file name is of a specific structure etc.
\1f
Date: 11 MAR 1980 1945-EST
From: EB at MIT-AI (Edward Barton)
To: (BUG ITS) at MIT-AI

Why does :COPYing to other machines so often hang up doing
an SAUTH ?  That has happened about five times today.
\1f
RWK@MIT-MC (Sent by ___036@MIT-MC) 03/06/80 04:07:41 Re: TTY hangage
To: (BUG ITS) at MIT-MC
I don't know if anybody cares, but it's possible to wedge a TTY completely
by doing :SPRT EJS;STYOUT DEBUG on MC.  This outputs a random asii file
as 8-bit codes.  I don't know if the TTY code claims not to wedge TTY's
in the case of garbage super-image output, but if it does, here's a
counter-example.

\1f
Date:  4 MAR 1980 1437-EST
From: gls at MIT-AI (Guy L. Steele, Jr.)
Sent-by: RICH at MIT-AI
To: MOON at MIT-AI
CC: GLS at MIT-AI, (BUG DDT) at MIT-AI, (BUG LISP) at MIT-AI
CC: (BUG ITS) at MIT-AI, (BUG TECO) at MIT-AI, (BUG EMACS) at MIT-AI
CC: (BUG LISPM) at MIT-AI, cpr at MIT-MC

Last note from RICH was really from GLS.
\1f
Date:  4 MAR 1980 1434-EST
From: RICH at MIT-AI (Charles Rich)
To: MOON at MIT-AI
CC: GLS at MIT-AI, (BUG DDT) at MIT-AI, (BUG LISP) at MIT-AI
CC: (BUG ITS) at MIT-AI, (BUG TECO) at MIT-AI, (BUG EMACS) at MIT-AI
CC: (BUG LISPM) at MIT-AI, CPR at MIT-MC

One obvious application of the Greek/Front key on the PDP-10
is that all such characters could be self-inserting in TEX format;
thus typing \ 2 would insert "\alpha", etc.  I don't know how much
more convenient this would make it to type weird formulas in TEX.
\1f
Date:  3 MAR 1980 2337-EST
From: MOON at MIT-MC (David A. Moon)
Subject: Use of New Keyboards with ITS.
To: JLK at MIT-MC
CC: CPR at MIT-MC, (BUG DDT) at MIT-MC, (BUG LISP) at MIT-MC
CC: (BUG ITS) at MIT-MC, (BUG TECO) at MIT-MC

I don't think ITS is going to be able to accomodate all of the new
modifier bits.  There are no free bits in the present internal
(18-bit) character code.  I don't think making Greek input work
is very important, since we certainly aren't going to go to the
very large amount of trouble required to make Greek output work
and have a more-than-7-bit printing-character set.

It would be nice to make Super and Hyper work to ITS, although there
are not enough bits available.  Note that shift-lock has already been
recycled.  Shift is sort of recycled and sort of vestigially still
there; it could be recycled for this.  It isn't necessary to be able to
represent all 16 combinations of the "bucky bits"; for instance there
are 8 combinations of 0, 1, or 2-adjacent buckies.

Since the function keys are there, you may as well make up top+>40
codes for them.  Some of the function keys map into keys on the old
keyboard; see the #\ table in LMIO;READ for something from which this
mapping can be derived, as we are doing it on the Lisp machine now.
From memory, it's clear-screen->form, delete->vt, clear-input->clear,
macro->back-next (but should be system->backnext in your case), terminal->esc.

It's not obvious that new keyboards will ever be attached to the AI TVs.
We might, and we might not.  It would involve slowing down the keyboard
scanner substantially, and we might have to put some buffering in the
keyboard microprocessor.
\1f
Date:  3 March 1980 21:41-EST
From: John L. Kulp <JLK at MIT-MC>
Subject:  Use of New Keyboards with ITS.
To: MOON at MIT-MC
cc: CPR at MIT-MC, BUG-DDT at MIT-MC, BUG-LISP at MIT-MC,
    BUG-ITS at MIT-MC, BUG-TECO at MIT-MC

We are going to hook up a new kbd to the PTV system in the next few
days, and the obvious question comes up about how to encode all
the function keys.  I suppose they could be handled the way
they are on the old keyboard, namely send chars with the TOP bit +
100 + <code>.  In order to distinguish them from the old kbd,
how about encoding them in 140-177?  Presumably the extra modifier
bits (SUPER, HYPER, and GREEK) need to be allowed (that uses up
all the bits available in the intelligent terminal protocol, unless
we want to flush SHIFT and SHIFT-LOCK).  It doesn't much matter
what the encoding is, as long as its documented.  I guess any
part of the system which masks off the high modifier bits or
otherwise depends on them being zero will have to get looked at.

ITS presumably wants to know about the SYSTEM key (treat like BACK/NEXT).

Its about time DDT knew about CLEAR (or CLEAR INPUT on the new kbds) which
should behave like ^D.  Also, HELP, STOP OUTPUT (^S, actually this should
probably be defined to do an output hold at the terminal, followed by an
output reset from the remote process (as is currently done)), ABORT (^G), END
(^C), RESUME ($P), etc.

TELNET and SUPDUP should be informed about the NETWORK key.

Various programs should know about END, ABORT, RESUME, BREAK, QUOTE, HELP,
STATUS (I'm not saying every program in the world should be retrofitted
to know about these, but the basic ones -- DDT, TECO, LISP -- probably
should).

I suspect that not much is going to happen on this until AI TV's start
getting new keyboards, but I would at least like to see the encoding
defined now, so that where only simple changes are required, they
can be done quickly when desired.


\1f
Date:  3 MAR 1980 1201-EST
From: AGRE at MIT-AI (Philip E. Agre)
To: (BUG ITS) at MIT-AI

The terminal controller still seems to think that CADR-2 is still in 907.
x6765 gets an occasional call looking for the person on CADR-2.  
\1f
CFFK@MIT-MC 03/01/80 19:04:16
To: (BUG PEEK) at MIT-MC, (BUG ITS) at MIT-MC
In PEEK M mode on a Macsyma I was running gave:
Mem=216, Top=254, Shared=158, Out=-1, Total=215
What does Out=-1 signify?
\1f
KLH@MIT-MC 03/01/80 18:40:23
To: MOON at MIT-MC
CC: (BUG ITS) at MIT-MC
I think FAST-APPEND can win using the following algorithm:
-------------------
If canonical file doesn't exist:
        Check for AOS'd version, and rename to canonical.
Find message-EOF of file:
        Re-open in read mode if not already in.
        Set .ACCESS ptr to file-EOF
        Read backwards until a msg-EOF mark is seen (ie ctl-_)
If canonical file already existed, msg-EOF is set to file-EOF.
Re-open file in write-over mode
Set .ACCESS ptr to msg-EOF
Write message.
        If IOC for some reason, just stop.
Close channel.
-------------------
        Note that there is no need to do anything about RENMWO'ing,
because following attempts will always start at the right place, and
it doesn't matter if the next attempt doesn't quite extend past the
true file EOF, because following appends will still back up to the
new msg-EOF mark.
        It would be a LOT more efficient if there
was some way to both read and write the file while it was open;
ironically enough the only way to do this now is to map into the
system buffer and see what's there!!  The data is there, but the
system won't let you get at it.  Foo.
        It would probably be easier to allow some way of doing
this dual I/O ("read-while-locked"?) mode than to hack APPEND mode,
since it doesn't depend on anything fundamental to the UFD.
        Another idea is for ITS to support this algorithm internally,
given the EOF delimiter(s) as argument.  Might be invoked by an OPEN
mode bit, or a new CALL.  This requires even less overhead and
makes the feature generally available.  This also
prevents race conditions since presumably one process would be
locked out while the other's APPEND effort progressed; this sort of
system-supported reliability could also make it reasonable to
use FAST-APPEND on normal MAIL files (since the FN2 is just 4 letters
and an AOS will stand out).

I'd claim this is a lot more useful than ECHOIN's hacking TECO buffers!
The amount of really gross disk I/O that the COMSAT does seems to far
exceed the amount of TTY-echo overhead being done, especially on AI.

Any comments on this scheme?  (No, I'm not likely to stop trying.)

\1f
BARRYG@MIT-MC 02/29/80 20:30:10 Re: filenames for automatic deletion
To: (BUG ITS) at MIT-MC
I use EMACS in autosave mode and I'm getting tired of cleaning up after
it.  I'm stuck with a filename1 of BARRYG (by convention), so is there
a filename2 that will cause the file to be automatically reaped?
If there is, it will simplify life as I want to keep the number of
files I leave around to a minimum.
        /barry gold
\1f
Date: 1 December 1979 12:10-EST
From: Robert W. Kerns <RWK at MIT-MC>
Subject: Directory block shuffle
To: GLS at MIT-AI
cc: BUG-ITS at MIT-AI, DLW at MIT-AI

It would be better to make it store the UNAME in the word with the reference
date, so you could find out who even if the person didn't have a directory
of his own....

\1f
Date: 11 December 1979 10:34-EST
From: Earl A. Killian <EAK at MIT-MC>
Subject:  sorting
To: BARRYG at MIT-MC
cc: BUG-DDT at MIT-MC, BUG-ITS at MIT-MC

    Date: 12/11/79 00:44:04
    From: BARRYG at MIT-MC
    To:   (BUG DDT)
    cc:   (BUG ITS)
    Re:   sorting

    Is there a way to sort a file on this system?  If it's easier to do than
    explain, the file I want to sort is MC:GUEST1;BARRYG YAMATO to be sorted
    in ascending order on the first 40 characters of each line.

Yes, try
\10 \e 40c \e l \e\e
in TECO.  \10 is the sort command - the first command string moves
from the beginning of the record to the beginning of the key, the
second command moves to the end of the key, and the third to the
end of the record.

\1f
MACRAK@MIT-MC 12/13/79 17:28:41
To: (BUG ITS) at MIT-MC, (BUG SYS) at MIT-MC
CC: RWK at MIT-MC
ARGGGGH!!

.open [1,,'nul]
.status  -> 2121

.open [1,,'dsk ? 'foobar ? 'quuzey]
.status  -> 43

What happened to the 100 bit?? (write)
Peek seems to know that the chnl is opened for writing.
Why doesn't .status?!
\1f
ED and ALAN and 42TLNT TELSER@MIT-MC (Sent by ALAN@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 ((??!!??!!??))
\1f
EJS@MIT-MC 02/26/80 20:24:16
To: (BUG ITS) at MIT-MC

:call echoin
and 
:call ttyesc

do not provide documentation on the respective system calls.  Could
somebody please update the doc file?  Thanks.
\1f
MOON@MIT-MC 02/24/80 21:37:03
To: ECC at MIT-MC
CC: (BUG ITS) at MIT-MC
    ECC@MIT-MC 02/24/80 21:31:43
    To: (BUG ITS) at MIT-AI
    The TV in 902 was garbling a lot of bits on the screen, in particular
    making the finger display shown when it is logged out almost totally
    unreadable.  I logged in to see if :FINGER would produce a more readable
    listing, which it sorta did.  However when I then logged out, it gave
    a little "bizzap!" sound (not very noisy) and the screen went blank,
    with nothing that I could type bringing it back.
The garbling of bits was a central problem which I believe I have just fixed.
If the screen is still blank, try turning the monitor off and back on (if you
can't find the plug, pull the fuse in the back out and put it back in.)
\1f
ECC@MIT-MC 02/24/80 21:31:43
To: (BUG ITS) at MIT-AI
The TV in 902 was garbling a lot of bits on the screen, in particular
making the finger display shown when it is logged out almost totally
unreadable.  I logged in to see if :FINGER would produce a more readable
listing, which it sorta did.  However when I then logged out, it gave
a little "bizzap!" sound (not very noisy) and the screen went blank,
with nothing that I could type bringing it back.
\1f
JLK@MIT-MC 02/11/80 09:05:07
To: (BUG @) at MIT-MC
CC: (BUG ITS) at MIT-MC
I think it is a rather major loss that :@ defaults to MIDAS or somesuch, given the
relatively few users of @ who make MIDAS listings.  If one were to base the defaults
on numbers, it should default to LISP code.  But I don't suggest that.
:@ <filename>
with no other JCL should obviously be the same as :@ <filename>/L[RANDOM]/D[DOVER]/#
these days.

\1f
Date: 10 FEB 1980 0203-EST
From: bak at MIT-AI (William A. Kornfeld)
Sent-by: ___101 at MIT-AI
To: (BUG ITS) at MIT-AI

This is a qubbling point, but if someone is REALLY bored he may
wish to fix it.

If an archive is on an unmounted disk (i.e. SECOND) and you do
an AR2^F, it gives an incorrect error message.  It thinks AR2
is a non-existent directory.  The correct error message should
be PACK NOT MOUNTED.
\1f
MOON@MIT-MC 02/09/80 16:25:23 Re: %TDICP suggestion (EAK)
To: (BUG ITS) at MIT-MC
CC: EAK at MIT-MC
Hmm, clever.  Sounds like it would work.
\1f
Date: 9 February 1980 13:00-EST
From: Earl A. Killian <EAK at MIT-MC>
Subject:  %TDICP suggestion
To: BUG-ITS at MIT-MC

How about changing the definition of %TDICP n from being "insert
n blanks in the current line" to being "insert next n characters
in the current line"?  I suspect that no programs would have to
change (i.e. TECO wouldn't).  The reason for the chnage would be
to allow insertion to happen more reasonably on some terminals
(in particular those with an insert character mode), without
making it any less efficient for terminals like TVs or the
Teleray.  CRTSTY would make use of the new constraint on what can
follow a %TDICP, and maybe ITS could too.

\1f
Date: 9 February 1980 13:00-EST
From: Earl A. Killian <EAK at MIT-MC>
To: BUG-ITS at MIT-MC
cc: %TDICP SUGGESTION at MIT-MC

How about changing the definition of %TDICP n from being "insert
n blanks in the current line" to being "insert next n characters
in the current line"?  I suspect that no programs would have to
change (i.e. TECO wouldn't).  The reason for the chnage would be
to allow insertion to happen more reasonably on some terminals
(in particular those with an insert character mode), without
making it any less efficient for terminals like TVs or the
Teleray.  CRTSTY would make use of the new constraint on what can
follow a %TDICP, and maybe ITS could too.

\1f
Date: 9 FEB 1980 0941-EST
From: GRAND at MIT-AI (Mark D. Grand)
To: (BUG ITS) at MIT-AI

        How does one go about recovering a file that (I presume)
was reaped?
\1f
CFFK@MIT-MC 02/07/80 10:21:33
To: (BUG ITS) at MIT-MC
I was logged into TTY 7, and all of a sudden nearly everything I typed
gave IBO.
\1f
Date: 27 JAN 1980 0457-EST
From: DLW at MIT-AI (Daniel L. Weinreb)
To: (BUG ITS) at MIT-AI

Someone should document the ECHOIN system call.
\1f
Date: 25 January 1980 01:40-EST
From: Robert W. Kerns <RWK at MIT-MC>
To: DLW at MIT-AI
cc: AGRE at MIT-AI, BUG-ITS at MIT-AI

    Date: 23 January 1980 01:17-EST
    From: Daniel L. Weinreb <DLW at MIT-AI>
    To:   AGRE at MIT-AI, BUG-ITS at MIT-AI

        Date: 22 JAN 1980 2028-EST
        From: AGRE at MIT-AI (Philip E. Agre)
        ...

    BUG-ITS: Does anyone think it might be more useful to display the
    MSNAME in the wholine, given that the SNAME is rather arbitrary?
    The main use I can see for the SNAME is that it seems to correlate with
    the *PRINT, :LISTF etc default directory in HACTRN, but I am not
    sure how good this correlation is.
The TV can't display the MSNAME.  The MSNAME lives only in DDT.  (It could
be added to ITS, but...) DDT's SNAME should correspond pretty well with
the :PRINT default, which is a more useful thing to display.  You don't change
your MSNAME very often.

\1f
BEN@MIT-ML 01/24/80 08:42:45
To: (BUG ITS) at MIT-ML
I use a Teleray 1061 with SIPB prom, and the display of overlong
lines seems to be incorrect.  I suspect that both the terminal and
ITS are providing an extra <CR>, because the continuation skips
a line before writing the remainder of the line.  If something was
previously on the skipped line, it remains (i.e. nobody does a
clear-to-end-of-line on <CR>).  This makes the text remarkably
difficult to read.  This happens most noticeably in RMAIL.

                                Ben Kuipers

\1f
GSB@MIT-ML 01/23/80 10:41:35 Re: ml lpt
To: (BUG ITS) at MIT-ML
CC: WAM at MIT-ML
There are two consecutive columns near the left margin that don't
print at all.

\1f
Date: 23 JAN 1980 0117-EST
From: DLW at MIT-AI (Daniel L. Weinreb)
To: AGRE at MIT-AI, (BUG ITS) at MIT-AI

    Date: 22 JAN 1980 2028-EST
    From: AGRE at MIT-AI (Philip E. Agre)

    When you do a :CWD on a TV, the current-directory entry on the bottom
    line of the screen doesn't change to the new value until you use the
    directory, say by ^F'ing it.
Philip: This is because the TV is showing you the "SNAME" of the
running job, rather than the "MSNAME"; the latter is what is
set by the :CWD command.
BUG-ITS: Does anyone think it might be more useful to display the
MSNAME in the wholine, given that the SNAME is rather arbitrary?
The main use I can see for the SNAME is that it seems to correlate with
the *PRINT, :LISTF etc default directory in HACTRN, but I am not
sure how good this correlation is.
\1f
Date: 22 JAN 1980 2028-EST
From: AGRE at MIT-AI (Philip E. Agre)
To: (BUG ITS) at MIT-AI

When you do a :CWD on a TV, the current-directory entry on the bottom
line of the screen doesn't change to the new value until you use the
directory, say by ^F'ing it.
\1f
MOON@MIT-MC 01/15/80 09:31:33
To: JONL at MIT-MC
CC: (BUG ITS) at MIT-MC
    JONL@MIT-MC 01/15/80 01:37:49
    To: (BUG ITS) at MIT-MC
    It would be nice to be able to display a directory with only
    the PRIMARY device shown - but FIND PK0:foo;* *  shows all
    the SECOND: and THIRD: files too.
The correct command is :FIND foo;* * &PACK 0.  I am surprised that
giving "PK0:" in a :FIND does not give you an error; I guess it
must be simply ignored.
\1f
JONL@MIT-MC 01/15/80 01:37:49
To: (BUG ITS) at MIT-MC
It would be nice to be able to display a directory with only
the PRIMARY device shown - but FIND PK0:foo;* *  shows all
the SECOND: and THIRD: files too.

\1f
JLK@MIT-MC 01/14/80 12:46:25
To: (BUG ITS) at MIT-MC
Well T37 is once again in the wedged state where ist output buffer pointer is 
garbaged.  Is there a way to patch this to make it functional again?
(I realize its probably impossible to track down this problem)

\1f
MOON@MIT-MC 12/27/79 08:04:42 Re: .STATUS and .CALL STATUS broken
To: MACRAK at MIT-MC
CC: (BUG ITS) at MIT-MC
I thought I answered it.  It's fixed in the source.  It had evidently
been broken for many years.
\1f
HAL@MIT-MC 12/26/79 22:24:08
To: (BUG ITS) at MIT-MC, (BUG CRTSTY) at MIT-MC

i just sent a bug message about not being able to run crtsty.  i now
realize that this occurred because, at the moment i tried to run it,
disc space went to zero.  so i guess you can ignore the previous bug
message.
\1f
HAL@MIT-MC 12/26/79 22:02:39
To: (BUG ITS) at MIT-MC, (BUG CRTSTY) at MIT-MC

Has there just been some change to MC ITS ?  Suddenly I can't seem to
run CRTSTY .
\1f
MACRAK@MIT-MC 12/26/79 21:18:38
To: (BUG ITS) at MIT-MC
I never received an answer about my complaint that .Status problem:
namely, .Status doesn't seem to correctly report whether a Dsk
or TTY channel is input or output!
Try:
100/ $$0'  !DSKfoo   >$
.open 100$x
.status$x
0/ 43  (not 143)
This does not seem to depend on the mode of output (image, block)
nor anything else I can find.

Can anyone tell me how to find out whether a channel is open for input
or output if this isn't considered a bug???
\1f
MOON@MIT-MC 12/20/79 00:07:07
To: MRC at MIT-AI
CC: (BUG ITS) at MIT-MC
    Date: 19 DEC 1979 2137-EST
    From: MRC at MIT-AI (Mark Crispin)
    To: (BUG ITS) at MIT-AI
    
    Why does .CALL USRVAR insist upon MOVEM for the return argument value?
    It should allow 2000,, like the rest of .CALL does.

It is not the same.  The arguments to USRVAR, TTYVAR are really
instructions.
\1f
Date: 19 DEC 1979 2137-EST
From: MRC at MIT-AI (Mark Crispin)
To: (BUG ITS) at MIT-AI

Why does .CALL USRVAR insist upon MOVEM for the return argument value?
It should allow 2000,, like the rest of .CALL does.
\1f
Date: 19 DEC 1979 2125-EST
From: MRC at MIT-AI (Mark Crispin)
To: (BUG ITS) at MIT-AI

TELNET failed to assemble because %TXSFL apparently is no longer
defined.  All TELNET used it for was to turn the bit off along
with %TXSFT.  I removed the reference; can TELNET trust that  that
bit will never be on?
\1f
DLW@MIT-MC (Sent by DLW0@MIT-MC) 12/14/79 08:39:37
To: (BUG ITS) at MIT-MC
It appears that ITS does not understand what %TOSAI on a DM2500 is
supposed to do.  On the SAIL-modified DMs, as well as our fake DMs,
you send escape (033) followed by the low-order code in order to make
it print an extended graphic.  Could ITS be changed to transmit this
sequencefor terminals with TCTYP of DM2500 with the %TOSAI bit
set?  This is not urgent...

\1f
BARRYG@MIT-MC 12/11/79 00:44:04 Re: sorting
To: (BUG DDT) at MIT-MC
CC: (BUG ITS) at MIT-MC
Is there a way to sort a file on this system?  If it's easier to do than
explain, the file I want to sort is MC:GUEST1;BARRYG YAMATO to be sorted
in ascending order on the first 40 characters of each line.
\1f
Date: 3 DEC 1979 0116-EST
From: jnc at MIT-AI (J. Noel Chiappa)
Sent-by: PK at MIT-AI
Subject: Shutting down an ITS
To: (BUG ITS) at MIT-AI

        It sort of unflavorful that  you have to wait at least 5 mins
to shut down the system (etc LOCK). In an emergency, you might want
a fast shutdown to repatriate disk bufs, etc.... preumably one could
patch, say, SHUTDN to the right thing, but it would be nice if there was
a good way to do this without such hacks...
\1f
Date: 30 NOV 1979 1458-EST
From: GLS at MIT-AI (Guy L. Steele, Jr.)
To: (BUG ITS) at MIT-AI
CC: GLS at MIT-AI, DLW at MIT-AI

    MSG: LOSER  1     
    DLW@MIT-AI 11/29/79 19:23:09 Re: Don't delete other people's files!
    Some very recently deleted a group of files on my directory.
    These were very important information, and some had been
    quite recently modified.  If you are trying to create disk
    space, ASK people to delete their own files--don't do it yourself!
    The ITS no-security system can only work in an environment of
    reasonable, responsible people; deleting other people's files
    like this is highly irresponsible.

I wonder how hard it would be to make the following modifications
to the disk routines:
[a] when a file is deleted, shuffle its five-word block to the
middle of the directory rather than just overwriting it.  Thus, a
rotation of a number of five-word blocks would occur, I think.
[b] install the uname of the deleting job as the file's "author".

This would tend (though not guarantee) to preserve information
as to who deleted a file.  It might make it easier to deal with this
problem, which has come up a lot recently.
\1f
RWK,RMS@MIT-MC (Sent by RWK@MIT-MC) 11/28/79 04:14:06
To: (BUG ITS) at MIT-MC
Translations should canonicallize DSK: to MC: etc, or the result is
unpredictible.  (Do YOU know if MM Load Library\eFOO\e uses MC: or DSK: ??)

\1f
Date: 28 NOV 1979 0250-EST
From: RMS at MIT-AI (Richard M. Stallman)
To: (BUG ITS) at MIT-AI

Control-CALL echoes as just a Z.  It should probably echo as ^Z.
\1f
CFFK@MIT-MC 11/20/79 08:32:07 Re: Continuation of previous message
To: (BUG ITS) at MIT-MC
Thus MC is receiving burst of ~ 70 characters at a time.
I realize that the real culprit is the TELNET program
that runs on the MFE-NET.  However is there any fix I
can make at MC to circumvent this problem?

\1f
CFFK@MIT-MC 11/20/79 08:28:12
To: (BUG ITS) at MIT-MC
If I log into MC from LLL-MFE, MC occasionally drops the last
few characters of the lines I type in (and the <cr>).  The problem
arises because I'm logged into LLL-MFE via the MFE-NET which works
a-line-at-time.  Thus MC is receiving 
\1f
Date: 15 NOV 1979 1046-EST
From: MAP at MIT-AI (Michael A. Patton)
To: (BUG ITS) at MIT-AI
CC: MAP at MIT-AI


The node A/1/a in ITSTTY cannot be reached by any normal means (that I
could find).  The only way I could get there was with G.
\1f
REM@MIT-MC 11/11/79 22:46:41 Re: Not a bug, rather a query/gripe/request
To: (BUG ITS) at MIT-MC
Given the SIXBIT name of a STY device, such as "S20", or just the number
such as 20, it should be easy to find out whether or not that STY is in use
by any job (your own job, or anybody else).  Anybody know how to do it?
Apparantly currently you can't do it unless you know the TTY that is
associated with it, thus making it impossible to write a subroutine that
gets you a new STY you don't already have unless you have  been keeping
a list of STYs-you-have all along since you started acquiring STYs.

\1f
Date: 7 November 1979 06:31-EST
From: Donald R. Woods <DWOODS at MIT-AI>
Subject: net ports
To: RWK at MIT-MC
cc: BUG-CRTSTY at MIT-AI, BUG-ITS at MIT-MC

Hmm, okay, I guess I hadn't been willing to believe that completely
unrestricted simulated ttys would number only 6, so I assumed that
only a subset of them were allowed as net ports.  Amazing that you
can survive with only 6!  Assuming most of them are normally in
use for net ports or lisp-machine users, I find it hard to believe
that you can get enough STYs for CRTSTY and other uses.  Maybe you
don't use them as much on ITS as we do at SAIL.

\1f
Date: 6 NOV 1979 2108-EST
From: CEH at MIT-MC (Charles E. Haynes)
To: C100-FANS at MIT-MC
Redistributed-To: bug-its at MC
Redistributed-By: GEOFF at SRI-KA
Redistributed-Date:  6 Nov 1979

Recently I have become involved in a discussion of the relative merits
of CRTSTY vs TCTYP support for C100's.  My personal feeling is that
the TCTYP support is inadequate in a number of areas, the largest being
its lack of support for the "Sail" character set.  Granted CRTSTY
takes an extra job slot, I feel that its support is enough better
that I prefer it (CRTSTY).

What do other people think?

-- Charles


\1f
Date: 7 November 1979 01:04-EST
From: Robert W. Kerns <RWK at MIT-MC>
Subject:  net ports
To: CSD.DON at SU-SCORE
cc: BUG-ITS at MIT-MC, BUG-crtsty at MIT-AI

    Date: 5 Nov 1979 2308-PST
    From: CSD.DON at SU-SCORE
    To:   bug-crtsty at MIT-AI
    Re:   net ports

    Incidentally, I consider it a crock of the finest shit that, for whatever
    reason(s), CRTSTY uses up an extra network port (of which I'm told there
    are only 6) instead of a system-internal simulated tty.  Do all STYs on
    ITS use net ports, or just CRTSTY STYs?  With net ports so rare, such an
    implementation seems rather silly.
It does use a system-internal simulated TTY.  That's what a STY is.  That is
also what a "net port" is.  It's not a limitation on how many network
connections there are, but on the number of system-internal simulated tty's.
While I would agree that 6 may be a little too few in the case of AI, it IS
a very heavily loaded machine, and there is justification for wanting to limit
the number of users coming in via the network.  This has nothing to do with
whether CRTSTY is implemented in the reasonable way; it is.

\1f
ED@MIT-MC 11/04/79 00:09:44 Re: I don't believe this
To: (BUG ITS) at MIT-MC, (BUG DDT) at MIT-MC
DDT version 1388 runs on AI and MC.  On MC, lower-case
characters typed as the first thing to DDT's command
loop (as in foo/ or foo\v, as opposed to :foo) generates
an OP? error.  On AI, this is not the case.  Further,
loading SYS;ATSIGN DDT into a job gets the same foul
behavior, but doing :copy sys;atsign ddt,common;random file
and then loading common;random file WINS!
It seems that the pure page that's always in core is broken.
Starting up several 256K jobs that referenced all their pages
managed to get the offending page swapped out which fixed things.
From this I gather that when a pure page is swapped, it is replaced
from the original, rather than put a dupe in the swap area.
Wierd.
\1f
Date: 26 OCT 1979 1212-EDT
From: EB at MIT-AI (Edward Barton)
To: (BUG ITS) at MIT-AI

:TIME, at least, claims that ITS has been up for 19 days
surpassing all previous records for uptime.  That seems doubtful
in view of the power situation earlier today.
\1f
Date: 26 Oct 1979 0113-EDT
From: HARV at MIT-DMS (Patrick L. Harvey)
To: (BUG its) at MIT-DMS
Subject: BUG its
Message-id: <[MIT-DMS].127634>

Continuation of previous message.  

After I finish with the new command, I get 
:KILL F$J
and a $P results in JOB?
...


\1f
Date: 26 Oct 1979 0111-EDT
From: HARV at MIT-DMS (Patrick L. Harvey)
To: (BUG its) at MIT-DMS
Subject: BUG its
Message-id: <[MIT-DMS].127633>

Sometimes when I do a :f then ^G it inthe middle, 
I start typing a new command line and I get <beep><beep> Job F finished.
Is this normal behavior?


\1f
Date: 26 October 1979 01:31-EDT
From: Robert W. Kerns <RWK at MIT-MC>
To: RMS at MIT-AI
cc: BUG-DDT at MIT-MC, BUG-ITS at MIT-MC

    Date: 26 October 1979 00:10-EDT
    From: Richard M. Stallman <RMS at MIT-AI>
    To:   BUG-DDT at MIT-AI

    If I type Control-Top-H at the DDT now on AI,
    it seems to be treatd just as an H;
    but rubbing it out just backspaces and doesn't erase it.

DDT doesn't quite expect to get numbers bigger than 177 in response to
it's IOT on a non %TIFUL channel.  Other than the [HELP] character, should
it?  (It already expects the [HELP] character.)

\1f
ED@MIT-MC 10/24/79 00:42:03
To: (BUG ITS) at MIT-MC, (FILE [UCODE;UCODE BUGS]) at MIT-MC
On MC, single-instruction proceed still loses if the
instruction page faults on fetch.  Doing 
100/ jrst 2000
2000/ jrst 4000
...
30000/ jrst 0
100\e0G
100>> JRST 2000  \ e     results in:
0>> 0                   note that 0, being swapped IN, doesn't execute.

\1f
Date: 23 OCT 1979 2254-EDT
From: MRC at MIT-AI (Mark Crispin)
To: (BUG ITS) at MIT-AI

Could AI have more STYs generated, or CRTSTY be less willing to have lots
of tourist STY users, or something?  Today, I was unable to get a net port
because there were three tourists on, one from a dialup and two from net
sites, taking up 5 out of the 6 available STYs because each was running a
CRTSTY.
\1f
pae@MIT-MC (Sent by ___043@MIT-MC) 10/21/79 15:02:33
To: (BUG ITS) at MIT-MC
mctty^f does not work when you are on mc.
\1f
Date: 17 October 1979 22:18-EDT
From: Howard I. Cannon <HIC at MIT-MC>
To: DHD at MIT-AI, BUG-ITS at MIT-AI

    Date: 17 OCT 1979 2112-EDT
    From: DHD at MIT-AI (David Hodgson Dennis)

    Is there any way the init files that use up almost all the file slots on
    users1/users2/users3 could be compacted (or the dir allocation changed)?
    That way, tourists who actually wanted to use storage for something other
    then init files (like documents or lisp programs) could do so more readily.
    I think this might make tourist's use of the system more productive.  Would
    this be too hard to do?
-----
Unfortunatly, the size of a directory is fixed by the system and cannot
be changed.  We realize that the USERSn directories get full, and there
is no easy fix.  Generally, it is possible to reap enough from the dirs
so that they are only about 75% full, but that takes time.  If the guests
were more responsible about cleaning up, the problem wouldn't be so bad.
Many people are on INFO-MICRO and don't read their 15 blocks of mail for
three months!  You should not be using the USERn dirs for anything but
very short term storage because you are lucky enough to have use of a
real dir on ML.  If a tourist wants to be productive, (s)he can always
find a way -- it's really that most of them don't particularly care.

\1f
Date: 17 OCT 1979 2112-EDT
From: DHD at MIT-AI (David Hodgson Dennis)
To: (BUG ITS) at MIT-AI

Is there any way the init files that use up almost all the file slots on
users1/users2/users3 could be compacted (or the dir allocation changed)?
That way, tourists who actually wanted to use storage for something other
then init files (like documents or lisp programs) could do so more readily.
I think this might make tourist's use of the system more productive.  Would
this be too hard to do?
\1f
Date: 16 Oct 1979 (Tuesday) 1457-EDT
From: OTTO at WHARTON (George Otto)
Subject: Solution to previously reported C100 problems.
To:   bug-its at MIT-AI, geoff at SRI-KA,
To:   eak at MIT-MC, OTTO (George Otto)

As RWK@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

\1f
Date: 16 OCT 1979 1223-EDT
From: RWK at MIT-MC (Robert W. Kerns)
Subject: OTTO's C100 complaints
To: (BUG ITS) at MIT-MC, (BUG EMACS) at MIT-MC, geoff at SRI-KL
CC: OTTO at WHARTON

(Sorry for not sending this note before, but I fell asleep).
I talked with OTTO last night, and he's going to talk to the TELNET
maintainer at his site.

\1f
Date: 16 October 1979 12:17-EDT
From: Earl A. Killian <EAK at MIT-MC>
Subject:  Possible solution to errors in C100 support.
To: OTTO at WHARTON
cc: BUG-ITS at MIT-AI, Geoff at SRI-KA

How are you getting to ITS?  If you're using a TELNET program I
suspect the problem is that it's doing some processing on the
output ITS sends.  Nothing in the path from ITS to your C100
should modify a single character output.

:TCTYP C100 works for other people, over the network.  That's why
I suspect it is a local problem.  Probably an over zealous
operating system turning form feeds into LFs.

P.S. don't include BUG-EMACS anymore, it's not relevant here.

\1f
Date: 16 Oct 1979 (Tuesday) 0446-EDT
From: OTTO at WHARTON (George Otto)
Subject: Possible solution to errors in C100 support.
To:   geoff at SRI-KA, OTTO (George Otto)
cc:   bug-emacs at MIT-AI, bug-its at MIT-AI

   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.

\1f
Date: 15 Oct 1979 (Monday) 2341-EDT
From: OTTO at WHARTON (George Otto)
Subject: Possible errors in C100 support/additional information
To:   bug-its at MIT-AI

   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


\1f
Date: 15 Oct 1979 (Monday) 2337-EDT
From: OTTO at WHARTON (George Otto)
Subject: Possible errors in C100 support/additional information.
To:   geoff at SRI-KA, OTTO (George Otto)
cc:   bug-its at MIT-AI, bug-emacs at MIT-AI

   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


\1f
Date: 15 Oct 1979 (Monday) 2256-EDT
From: OTTO at WHARTON (George Otto)
Subject: Possible errors in C100 support/padding solution
To:   geoff at SRI-KA, OTTO (George Otto)
cc:   bug-its at MIT-AI, bug-emacs at MIT-AI

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

\1f
Date: 15 Oct 1979 1943-PDT
Sender: GEOFF at SRI-KA
Subject: Re: Possible errors in C100 terminal support
From: the tty of Geoffrey S. Goodfellow
To: OTTO at WHARTON
Cc: bug-its at MIT-AI, bug-emacs at MIT-AI
Message-ID: <[SRI-KA]15-Oct-79 19:43:51.GEOFF>
In-Reply-To: Your message of 15 Oct 1979 (Monday) 2115-EDT
Reply-to: Geoff @ SRI-KA

Perhaps your terminal is not getting the right amount of
padding...  I suggest on the same TCTYP line along with C100 you
add SPEED #, i.e.  as in

:TCTYP C100 SPEED 9600

so the system will insert the right amount of padding (9600
baud's worth in this case).  I suspect this is your most likely
cause of lossage if operating over 300 baud.
\1f
Date: 15 Oct 1979 (Monday) 2115-EDT
From: OTTO at WHARTON (George Otto)
Subject: Possible errors in C100 terminal support
To:   bug-its at MIT-AI, bug-emacs at MIT-AI,
To:   OTTO (George Otto)

   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@WHARTON)


\1f
Date: 15 OCT 1979 1909-EDT
From: GVEO at MIT-AI (George V.E. Otto)
To: (BUG ITS) at MIT-AI

   I would like to report some trouble with either the screen control
for a C100 terminal, or the way INFO handles its display. I have the
full report of the problems in a file at Wharton, so I would like to
netmail the report from there. What userids should I use to mail the
error report?
\1f
Date: 15 OCT 1979 1607-EDT
From: OTTO@Wharton
Sent-by: ___021 at MIT-AI
To: (BUG ITS) at MIT-AI

I have a bug to report in either screen support of a CONCEPT 100 terminal
or in the way INFO handles screen control. To whom should I send a
description of the problems encountered? My addresses is OTTO@WHARTON.
I have an edited file containing the description of the situation which
I would liklike to send via netmail to the correcdt person
or persons.
                                                George Otto
\1f
BNLGHC@MIT-MC 10/15/79 15:37:22
To: (BUG ITS) at MIT-MC
My TEKtronix terminal (actually a 4051) is not being handled
correctly by TCTYP and/or MACSYMA.  The screen is not being
erased, --Continued-- overwrites --pause--, etc.

\1f
HIC@MIT-MC 10/13/79 07:57:31 Re: Chaosnet FORCE.
To: ED at MIT-MC, (BUG ITS) at MIT-MC

I explained the bug to ED.

\1f
ED@MIT-MC 10/13/79 05:13:00 Re: Chaosnet FORCE.
To: (BUG ITS) at MIT-MC
The sequence:
.iot chaoch,[go away]
.call [setz ? sixbit /force/ ? setzi chaoch]
.close chaoch,
causes the target lisp machine to go into the error handler
complaining that 3 is an illegal packet opcode.
Doing a .SLEEP 30. after the force and before the close wins.
\1f
EAK@MIT-MC 10/08/79 18:01:27
To: (BUG ITS) at MIT-MC
How about a ^_ command to do an input reset?  I.e. flush randomness
you accidentally typed.
\1f
Date: 6 OCT 1979 1740-EDT
From: DLW at MIT-AI (Daniel L. Weinreb)
To: (BUG ITS) at MIT-AI, KLH at MIT-MC

I must admit I've had the same problem.  It only takes two tourists
running CRTSTY to use up 2/3 of the AI STYs.
\1f
KLH@MIT-MC 10/05/79 18:37:23
To: (BUG ITS) at MIT-MC
I can hardly ever read my AI mail any more.  Recently
I had to let it pile up for a few days because I couldn't
seem to find any time when all STY's weren't being
hogged (either by LM's or T's or whatever).  Considering
the number of LM's, I would think the # of STY's should be
grossly increased, although the # of net logins could
be controlled as a separate limit.  True, this implies more
job slots, but I've always thought more were needed anyway.
I've nevver seriously considered departing AI altogether, but
the situation is getting grim.

\1f
Date: 3 OCT 1979 2049-EDT
From: JLK at MIT-AI (John L. Kulp)
To: (BUG ITS) at MIT-AI, ARC at MIT-AI

:LISTF ARC:CHAOS; ON AI GIVES ARC NO SUCH DEVICE
\1f
Date: 3 OCT 1979 0819-EDT
From: GRAND at MIT-AI (Mark D. Grand)
To: (BUG ITS) at MIT-AI

        I DON'T know if this is an oversite on sombody's part or
what, but when I try to :INFO MACLISP   
I get
\rOPN016  INFO \b;AI:LISP >   PACK NOT MOUNTED?\r\r\1f
Date:  2 Oct 1979 2341-PDT
From: Mark Crispin <Admin.MRC at SU-SCORE>
Subject: [PAE at MIT-MC (Philip A. Earnhardt): **more** state on the last line of the screen]
To: Bug-ITS at MIT-AI

Has anybody looked at this problem?  I've been told that it's a bug
in ITS.  Any comments?
                ---------------
Mail from MIT-AI rcvd at 2-Oct-79 2238-PDT
Date: 3 OCT 1979 0103-EDT
From: PAE at MIT-MC (Philip A. Earnhardt)
Subject: **more** state on the last line of the screen
To: (BUG TELNET) at MIT-MC, (BUG emacs) at MIT-MULTICS

two times tonight, I have gotten into a **more** state
in multics emacs, telnet thru mc. Once this was through
invoking emacs on the next-to-last line of my screen
(which I believe was a known bug) and once while doing
a multics command (using ^x-^m) in my minibuffer. Does
anyone know where the problem/responsibility lies with
this?

thanks,
philip

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

-------
\1f
MACRAK@MIT-MC 10/01/79 19:00:55
To: (BUG ITS) at MIT-MC
Two problems with carriage motion optimization on printing terminals:

1. Final spaces before cr aren't flushed.
2. Sometimes--especially when printing out Macsyma expressions using
backspaces and linefeeds substituting for cr's and spaces--its seems
to print out some backspaces, then some spaces, then more backspaces.

\1f
Sheldon Furst <FURST at BBN-TENEXB>@MIT-MC (Sent by ___065@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$\ 1" 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

\1f
KMP@MIT-MC 09/11/79 14:09:48 Re: KMP;.LOGIN 227
To: (BUG ITS) at MIT-MC
My login init gives an IRRECOVERABLE DATA ERROR when I try to read it.

\1f
KMP@MIT-MC 09/11/79 14:09:48 Re: KMP;.LOGIN 227
To: (BUG ITS) at MIT-MC
My login init gives an IRRECOVERABLE DATA ERROR when I try to read it.

\1f
Date: 10 SEP 1979 2324-EDT
From: MOON at MIT-MC (David A. Moon)
Subject: New ITS on MC has disk deadlocks
To: RWK at MIT-MC
CC: (BUG ITS) at MIT-MC, JPG at MIT-MC

This is fixed now.
\1f
Date: 10 SEP 1979 1839-EDT
From: MOON at MIT-MC (David A. Moon)
Subject: New ITS on MC has disk deadlocks
To: RWK at MIT-MC
CC: (BUG ITS) at MIT-MC, JPG at MIT-MC

I already know about this, I guess I should be more anxious about fixing it
if it is happening frequently.  I don't think it's a new bug, I don't
understand why it happens more now.  The reason you can't list the TTY
directory is probably that the DDT TTY^F command probably first checks for
a TTY; directory on the disk.
\1f
RWK@MIT-MC (Sent by ___042@MIT-MC) 09/10/79 07:25:59 Re: AddendumP
To: (BUG ITS) at MIT-MC
CC: JPG at MIT-MC
When it's hung as described, you can't list the TTY directory either.

\1f
Date: 10 SEP 1979 0723-EDT
From: RWK at MIT-MC (Robert W. Kerns)
Sent-by: ___041 at MIT-MC
Subject: New ITS on MC has disk deadlocks
To: (BUG ITS) at MIT-MC
CC: RWK at MIT-MC, JPG at MIT-MC

A phenomenon we've observed repeatedly on this new system is for it to go
into a mode where reading directories (for everyone trying to do so) for
up to several minutes.  It tends to hang repeatedly with short unhangings
for quite a while, and then suddenly clear up.  It tends to happen when DUMP
is running, grovelling over large numbers of directories.  I just saw such
a state, and managed to get a little info before it unhung.  The DUMP's
FLSINS was SKIPG QFUD (it was hung in this, QFUD being zero).  All the
directories were in use (QSNUD non-zero), aparently brought in by DUMP
(mostly in alphabetical order).  Other jobs trying to do things and getting
hung hung waiting on QSKOSW, which was locked by the DUMP frob.  That's about
all I could get before it spontaneously started working again.

\1f
KMP@MIT-MC 09/06/79 20:54:40
To: (BUG DDT) at MIT-MC, (BUG ITS) at MIT-MC
System keeps dying here on me at least. Echos all chars but doesn't do
anything. T^F doesn't even work ... wierd. Any guesses? It's like everything
ITS does in the way of interrupt handling works, but that's all. No jobs 
no ddt commands run. I detached myself from another tty and then tried to ^Z
the console. Took it fully a minute or more to get it to listen. another 
console next door had same problem. both freed at same time. system must
be hanging some obscure way.

\1f
BRIAN@MIT-ML 09/01/79 13:10:00 Re: Moving files to an archive
To: (BUG ITS) at MIT-ML
CC: BRIAN at MIT-ML
When I try to move the file ML:BRIAN;MAIL O-COMM onto ARC MAIL, I
get no error message, and the file name appears in the directory
as expected, but names a file of zero length.  I have had a similar
problem moving another fairly large file (14 blocks) on the
archive (which is about 160 blocks), but a small file got moved
OK.

\1f
Date: 28 AUG 1979 0101-EDT
From: ED at MIT-AI (Ed Schwalenberg)
To: (BUG ITS) at MIT-AI

Why is it that 
.CALL [SETZ ? '?_____ ? SETZM]
is an ILOPR, while
.CALL [SETZ ? 'FOOBAR ? SETZM]
fails to skip and returns an ILLEGAL SYSTEM CALL NAME error code?
I smell a crock.  Of course, I deserve no better, executing randomly
named system calls.  On the other hand, and related to this, the
.GETSYS uuo returns a list of NCALLS that includes ?_____ not once, but
200-<number of real system calls> times.  This should either be fixed or
documented.
\1f
Date: 26 August 1979 19:03-EDT
From: Earl A. Killian <EAK at MIT-MC>
To: BUG-ITS at MIT-MC, BUG-DDT at MIT-MC

When I exit my EMACS and type-ahead, most of the type-ahead isn't
echoed.  Perhaps DDT could check the %TXPIE bit and echo the character
itself if ITS didn't?  Or better, maybe ITS could do this?

Also, what about DDT option to use MP echoing instead of PI echoing?

\1f
Date: 26 Aug 1979 0600-EDT
From: RWK at MIT-MC
To: EBM at MIT-DMS, BUG-its at MIT-DMS
Subject: SYS directories full
Message-id: <[MIT-DMS].120744>

Date: 26 August 1979 06:51-EDT
From: Robert W. Kerns <RWK at MIT-MC>
Subject:  SYS directories full
To: EBM at MIT-DMS, BUG-its at MIT-DMS

    Date: 25 Aug 1979 1536-EDT
    From: EBM at MIT-DMS (J. Eliot B. Moss)
    To:   (BUG its) at MIT-DMS
    Re:   BUG its

    :linkn ml:sys2;ts nr,r;ts nr38
        fails when the link already exists, because the directory
    is full.  This is very annoying.  MC has the same problem.  I think
    that either the system call should be fixed, or some links in those
    two directoris should be gotten rid of so the directories are no longer
    full.
The real problem here is that the directory is full.  DDT has long supported,
and MC has long had a SYS3 directory.  I think that garbage links should be
GC'd, but that if a directory is available a SYS3 directory should be created
on the other machines.




\1f
Date: 25 Aug 1979 1536-EDT
From: EBM at MIT-DMS (J. Eliot B. Moss)
To: (BUG its) at MIT-DMS
Subject: BUG its
Message-id: <[MIT-DMS].120688>

:linkn ml:sys2;ts nr,r;ts nr38
        fails when the link already exists, because the directory
is full.  This is very annoying.  MC has the same problem.  I think
that either the system call should be fixed, or some links in those
two directoris should be gotten rid of so the directories are no longer
full.


\1f
Date: 24 AUG 1979 1343-EDT
From: CFFK at MIT-MC (Charles F. F. Karney)
Subject: Support of harware tabbing on printing terminal by Plot2
To: RJF at MIT-MC
CC: JPG at MIT-MC, (BUG PLOT2) at MIT-MC, (BUG ITS) at MIT-MC
CC: (BUG CRTSTY) at MIT-MC

Most of the shortcuts taken by PLOT2 when plotting on printing
terminals are in fact done by ITS.  (E.g. the suppression of
trailing spaces on a line, and the use of backspaces instead of
return+spaces.)  Support of hardware tabs by PLOT2 would similarly
be best done by ITS (e.g. via a new TCTYP).  If this is not done
then maybe CRTSTY could do the job.  (I believe CRTSTY may have
some minimum requirements which rules this out.)  Support of
tabs by PLOT2 itself would be the least desirable because (1)
nothing else (e.g. :print) would benefit, and (2) because Plot2
would have to implement ITS's other shortcuts at the same time.
(However, I don't rule out the support of tabbing by PLOT2.)
If ITS or CRTSTY also supported abs. curdsor positioning on daisy
wheel printers, you would be able to win using Plot2 by setting
PLOTMODE:DISPLAY$
An absolute requirement for the implementation of any of this
by any system is an EXACT specification of the  commands needed
to make the tabbing/cursor positioning work.

\1f
Date: 24 Aug 1979 0201-EDT
From: KDO at MIT-DMS (Ken D Olum)
To: (BUG its) at MIT-DMS
Subject: BUG its
Message-id: <[MIT-DMS].120603>

The tty input buffer is too small.  If you come from a site with a line
editor (SAIL) and type a full line and CR the whole line will get sent
at once and overfill your buffer.  I had a good time typing this message.


\1f
GJC@MIT-MC 08/21/79 21:13:08
To: (BUG ITS) at MIT-MC
I was running a peek, and the system fair-share was said to be
113% at one point. This is mighty fine if it is true!

\1f
EAK@MIT-MC 08/20/79 02:57:38
To: (BUG ITS) at MIT-MC
Using the .LOSE argument of .CALL DISMIS is really terribly inconvenient
when the interrupt stack pointer isn't in an AC.  You have you put it
in one to address the return PC etc., but then you've clobbered an AC
which is hard to restore...

\1f
SKH@MIT-MC 08/11/79 20:29:51
To: (BUG ITS) at MIT-MC
A suggestion:
Change the more handling in WHOJ, PEEK, FINGER etc. to (:PRINT)
to that of DDT'S implicit more (The one that vanishes if on
a display). Its annoying to see the --more-- thing stick
around. The vanishing more is 700% better.

\1f
RWK@MIT-MC (Sent by KMP@MIT-MC) 08/11/79 20:24:46
To: (BUG ITS) at MIT-MC
The system with the ARCHIV handler doing a .CALL FINISH for 13 hours
finally crashed, due to apparently related lossage.  It's dumped in
MC:CRASH;QFLDF1 H/50
The immediate cause of the crash was indexing the channel tables with
H being 1 larger than the largest channel table index!

\1f
Ed@MIT-MC (Sent by PAE@MIT-MC) 08/11/79 15:02:50
To: (BUG ITS) at MIT-MC
Look at MC:CHANNA;_DRGN_ TIMES
(and MC:CHANNA;_DRGN_ TIMES, and MC:CHANNA;_DRGN_ TIMES,
and MC:CHANNA;_DRGN_ TIMES, and MC:CHANNA;_DRGN_ TIMES, and...
\1f
RWK,KMP@MIT-MC (Sent by ___021@MIT-MC) 08/11/79 06:26:36 Re: .CALL FINISH won't
To: (BUG ITS) at MIT-MC
CC: (BUG ARCHIV) at MIT-MC, KMP at MIT-MC
There's an archive device handler here, hung in a .CALL FINISH on its disk
output channel.  The channel is in REAI mode according to PEEK's C mode.
It's definately an output channel, so I guess PEEK must display append-mode
channel's oddly.  Claims its 100% read.

The .CALL FINISH is at OPNOUT+16

The job's flush instruction is SKIPE QSBFS+5
The PUSHJ P,UFLS is at QOCL2+1/ SKIPE QSBFS(A)
A/ 1,,5
QSBFS+5/        1
QSCRW+5/        0       ;Read
QSRAC+5/        %QAEFR+%QAACC+%QALBK+%QAMWO,,0
QSMPRC+5/       0               ;No bytes left in buffer


I don't know what else might be relevant.  I leave the job KMP JOB.06
still hanging for your inspection.  KMP HACTRN is still hanging on the job
to finish.

\1f
KMP@MIT-MC 08/11/79 03:12:57
To: (BUG ITS) at MIT-MC
If I have a file name
FOO .EXP99
and write out a new file called
FOO > 
it seems to write to
FOO .EX100

This would be ok if it weren't for the fact that if I then
compile FOO >, I end up compiling FOO .EXP99 ... can this be
fixed? Like maybe to open the > file, you could find all contenders
(files with max number of digits, ending in a digit), strip all trailing
digits, readlist the digits and compare them?

-kmp

\1f
Date: 9 AUG 1979 1812-EDT
From: PAE at MIT-MC (Philip A. Earnhardt)
Subject: Getting thrown to DDT by :SEND
To: RWK at MIT-MC
CC: (BUG EMACS) at MIT-MC, (BUG ITS) at MIT-MC


    RWK@MIT-MC 08/09/79 05:41:16 Re: Getting thrown to DDT by :SEND
    If you type a ^G while a SEND is printing, DDT has control of the terminal
    and you'll end up in DDT.  Was this perhaps the problem?
no, I was just typing characters...no control chars.
\1f
RWK@MIT-MC 08/09/79 05:41:16 Re: Getting thrown to DDT by :SEND
To: PAE at MIT-MC
CC: (BUG EMACS) at MIT-MC, (BUG ITS) at MIT-MC
If you type a ^G while a SEND is printing, DDT has control of the terminal
and you'll end up in DDT.  Was this perhaps the problem?

\1f
Date: 8 AUG 1979 2050-EDT
From: RMS at MIT-AI (Richard M. Stallman)
To: (BUG ITS) at MIT-AI, ED at MIT-AI, RWK at MIT-MC


    RWK@MIT-MC (Sent by ___076@MIT-MC) 08/08/79 08:46:03
    It would seem that NO SUCH DEVICE is not really what's wanted.
    Note that if you are WRITING a file, that you want normally to
    go on the secondary pack, it also says "NO SUCH DEVICE".  In
    actual fact, there IS such a device, sitting broken and unavailable.

I agree.  "No such device" says "what you want makes no sense", which
is not true in this case.
\1f
PAE@MIT-MC 08/08/79 19:46:18
To: (BUG ITS) at MIT-MC
CC: (BUG EMACS) at MIT-MC
I received a message while replying to mail (using emacs rmail),
kept typing at the time, and somehow got kicked out of emacs back to
ddt.  I didn't think there was anything that would quit an emacs
like that.
\1f
RWK@MIT-MC (Sent by ___076@MIT-MC) 08/08/79 08:46:03
To: (BUG ITS) at MIT-MC
CC: ED at MIT-MC
It would seem that NO SUCH DEVICE is not really what's wanted.
Note that if you are WRITING a file, that you want normally to
go on the secondary pack, it also says "NO SUCH DEVICE".  In
actual fact, there IS such a device, sitting broken and unavailable.

\1f
MOON@MIT-MC 08/08/79 03:10:39 Re: SECOND:
To: ED at MIT-AI
CC: (BUG ITS) at MIT-MC
    Date: 8 AUG 1979 0201-EDT
    From: ED at MIT-AI (Ed Schwalenberg)
    Subject: SECOND:
    To: (BUG ITS) at MIT-AI
    
    Printing a file on SECOND: on AI these days results in NO SUCH DEVICE,
    when one would expect a PACK NOT MOUNTED.  Is this a bug or a feature?
It does give you pack not mounted.  You were probably typing SECOND:
and indeed there is no such device if the pack isn't mounted.  But you don't
need to, and usually don't, give the device name if you're just printing a file.
\1f
Date: 8 AUG 1979 0201-EDT
From: ED at MIT-AI (Ed Schwalenberg)
Subject: SECOND:
To: (BUG ITS) at MIT-AI

Printing a file on SECOND: on AI these days results in NO SUCH DEVICE,
when one would expect a PACK NOT MOUNTED.  Is this a bug or a feature?
\1f
Date: 5 AUG 1979 2158-EDT
From: BH at MIT-AI (Brian Harvey)
To: (BUG ITS) at MIT-AI

How come top-/ is infinity, but shift-/ is \vN ?  (Of course
I mean the blue slash key, not the grey one.)  I realize that
infinity is 016 octal and so is \vN, but the difference seems
weird to me, e.g. when typing in EMACS and getting to the next
line when one wanted an infinity.
\1f
Date: 3 AUG 1979 2030-EDT
From: MRC at MIT-AI (Mark Crispin)
To: (BUG ITS) at MIT-AI

Padding on Telerays seems to lose in EMACS with i/d mode.  Are you using
Pentti's algorithm yet?  Telerays require lots of padding!
\1f
Date: 29 JUL 1979 1748-EDT
From: KEN at MIT-AI (Kenneth Kahn)
Subject:  the dirar<n> devices.
To: (BUG ITS) at MIT-AI

I consistently get FILE LOCKED errors when printing
ken;dirar3:name1 up
dirar4:name1 up
dirar7:name1 up
dirarc:name1 up


All the other names (for example dirar5:)  seemed to work fine.
The archives themselves seemed fine, peek showed no one holding on to them,
and just creating a link from ar0 >, to ar7 > and then printing dirar0: avoided
the problem.
\1f
GSB@MIT-ML 07/27/79 17:23:55
To: (BUG ITS) at MIT-ML
why doesn't PK13:  work like PK3: etc.?

\1f
Date: 27 JUL 1979 1130-EDT
From: RICH at MIT-AI (Charles Rich)
Subject:  Job slots
To: (BUG ITS) at MIT-AI

I know we had this argument before, but I really think that 
we need more job slots.  With 7 Lisp machines logged
in (and soon to be more), the transient average of
CHAOSnet jobs had gone up noticeably, with the result
that people spend half the day doing :SHOUT FLUSH JOBS!
which is a nuisance.  As for example, right now, there
is noone logged in from the ARPA net -- just
local people, none of whom are running more than a
Lisp and an Emacs and maybe an occasional compiler,
and there are no free job slots to run even a :MAIL
(I am doing this inside EMACS, and it will probably
bomb the first time I try to send it!!!!!).

        Sincerely,  Chuck Rich.
\1f
HIC@MIT-MC 07/25/79 14:32:27
To: BYRON at MIT-ML, (BUG ITS) at MIT-ML


    BYRON@MIT-ML 07/25/79 09:23:54
    :tcytp c100 no no longer works, but gives back
    ERROR: CNSSET:  MEANINGLESS ARGS
    270>>.CALL 3330 (CNSSSET)

    Also, PWORD is no longer invoked on T04 (intentional?).


------
Some turkey loaded the wrong ITS (an old version) on ML.
I just reloaded the system, and all this
should be fixed now.


\1f
BYRON@MIT-ML 07/25/79 09:23:54
To: (BUG ITS) at MIT-ML
:tcytp c100 no no longer works, but gives back
ERROR: CNSSET:  MEANINGLESS ARGS
270>>.CALL 3330 (CNSSSET)

Also, PWORD is no longer invoked on T04 (intentional?).

\1f
BYRON@MIT-MC 07/25/79 10:55:25
To: (BUG ITS) at MIT-MC
I continually get "Host reset" messages while SUPDUPing from MC to ML.
They occur about once every 5 minutes or so, and detach me as well
of course.

\1f
Date: 23 JUL 1979 0251-EDT
From: RMS at MIT-AI (Richard M. Stallman)
To: (BUG ITS) at MIT-AI, AGRE at MIT-AI, KEN at MIT-AI

I just noticed that C-N on my TV was giving me only one
more line at the bottom of my screen.  The code was still
the old speed-dependent stuff, so I checked and found
that my TV was supposed to be running at 300 baud
(luckily my TV didn't know that!).
Probably it should be impossible to change the speed
of a TV, and :TCTYP should barf very loud at anyone who tries.

This is probably the result of an unconditional :TCTYP in an init file.
\1f
Date: 20 JUL 1979 1356-EDT
From: JERRYB at MIT-AI (Gerald R. Barber)
Subject: Dissappearance of init files
To: (BUG ITS) at MIT-AI

I keep losing some of my init files for no apparent reasons, usually either my
EMACS or LISP inits.  Is there a way to tell when a file was deleted and by
whom?  Failing this is there a way to set up some sort of mechanism so that in
the future I will be told who deleted one of these files.
\1f
Date: 18 JUL 1979 2044-EDT
From: RWK at MIT-AI (Robert W. Kerns)
To: (BUG ITS) at MIT-AI
CC: (BUG DDT) at MIT-AI

There seems to have been a time around 4:30 pm on the 25 of June, when
all the DDT's in the world (and a PWORD too) got scrod.  I'm not certain
right off exactly what happened to them, but many of them seem to have
gotten their PC's set to -1, probably by having the stack-pointers
changed out from under them.  (They seemed to be doing a TYI at the time).
The PWORD definately had a PDL underflow.  Something like 40 crash files
were dumped at the time.

There are a few saved crash files on CRASH;(first name BUGDDT)  The relavent
PWORD crash file is PWORD PDLHAK.
\1f
Date: 18 JUL 1979 0242-EDT
From: JNC at MIT-AI (J. Noel Chiappa)
To: DLW at MIT-AI
CC: (BUG ITS) at MIT-AI

        Well, IMPUP is definitely a symbol. Sounds like the system
was slowly dying away; did anybosy see any "memory changed between"
messages as it went? Sounds like the kind of cumulative bit rot whose
origin is almost impossible to track down....
                Noel
\1f
Date: 17 JUL 1979 1823-EDT
From: DLW at MIT-AI (Daniel L. Weinreb)
To: (BUG ITS) at MIT-AI

To add to the rash of strange reports: last night, RK tried to
use TELNET on MC and fond it halting with an "ERROR;" message
at a .EVAL.  I examined it; the symbol in question was "IMPUP",
and going into SYS$J showed that IMPUP was not a known symbol.
Maybe the exec symbol table was bashed?  Anyway, the system
crashed shortly after this (while I was examining the problem).
\1f
KMP@MIT-MC (Sent by ___031@MIT-MC) 07/17/79 07:53:33 Re: Unreproducible errors...
To: (BUG ITS) at MIT-MC
CC: (BUG COMPLR) at MIT-MC
I got an error from the lisp compiler just about 2 seconds before the 
last crash. I don't know if it is related ...

;(LOAD ((DSK LIBLSP) TTY FASL)) - NON-EXISTENT DIRECTORY

which is odd because that file and dir exist and as soon as system came
back up the complr did the compilation with no errors. 
-kmp

\1f
GSB@MIT-MC 07/11/79 00:34:43 Re: c100 padding for i&d line
To: (BUG ITS) at MIT-MC
CC: EAK at MIT-MC
!@#%^#&!@, ML is running an ITS 3 months older than MC, and the cruft
in the tty code for it doesn't look at all like the stuff in the current
source...  It appears to win on MC, EXCEPT THAT CLEOS DOESN'T WORK AT
ALL!!  (This is still at 9600 baud.)  (It doesn't on ML either.)

\1f
Date: 10 July 1979 18:41-EDT
From: Earl A. Killian <EAK at MIT-MC>
To: GSB at MIT-MC
cc: BUG-ITS at MIT-MC

    Date: 07/10/79 13:12:20
    From: GSB at MIT-ML
    To:   (BUG ITS) at MIT-ML

    Padding for the c100 is insufficient for i&d line at 9600 baud.
    Can anyone tell me a place i can patch to experiment?

You might experiment with CRTSTY's padding at 9600 and when you find
the appropriate value, try it in ITS.  Patch C1LIDP+7 to multiply by
different padding times (which are floating point no.s - it is
currently .75E-3).

\1f
GSB@MIT-ML 07/10/79 13:12:20
To: (BUG ITS) at MIT-ML
Padding for the c100 is insufficient for i&d line at 9600 baud.
Can anyone tell me a place i can patch to experiment?

\1f
Date: 2 JUL 1979 1046-EDT
From: APW at MIT-AI (Andrew P. Witkin)
To: (BUG ITS) at MIT-AI

(sorry about the incomplete msg) The bug reported by bkph -- random
garbling of type in-- has also struck the datamedia in E10 (T35).
\1f
Date: 2 JUL 1979 0954-EDT
From: APW at MIT-AI (Andrew P. Witkin)
To: (BUG ITS) at MIT-AI

T
\1f
Date: 2 JUL 1979 0845-EDT
From: BKPH at MIT-AI (Berthold K.P. Horn)
To: (BUG ITS) at MIT-AI

What's up with the Teletype lines? Both outside (telephone)
and inside (DATAPOINT & Mini-Robot) lines have very peculiar
random behaviour -- garbling characters, inserting characters,
dropping bits, copying several times every second letter of
what was typed recently and other such randomness...
\1f
JPG@MIT-MC 06/14/79 08:48:51
To: (BUG ITS) at MIT-MC
Say, this system is locking disk blocks!  
It just crashed, and I reloaded it from scratch.
Before the crash, the number of available blocks on #0,#1,#13 
respectively were 320,380,201 .  (I checked this just before the 
crash.)  After the crash, the number available was 547,552,257 
+ I dumped out a 171 block crash file on CRASH;.
I noticed this phenomenon about 2 weeks ago when the system crashed 
and RWK reloaded it, and mentioned it to him, but I wasn't as certain 
then, so didn't report it.
I wonder if this has something to do with swapping disk somehow using 
user blocks or whatever, and the system's marking them at high-use time 
getting screwed up.  Whatever, something is doing this!

\1f
Date: 11 JUN 1979 2014-EDT
From: RWK at MIT-MC (Robert W. Kerns)
Subject:  E? USR:$
To: EAK at MIT-MC, RWK at MIT-MC, (BUG ITS) at MIT-MC
CC: (BUG TECO) at MIT-MC

    Date: 10 JUN 1979 1242-EDT
    From: EAK at MIT-MC (Earl A. Killian)
    To:   RWK, (BUG ITS)
    cc:   (BUG TECO)
    Re:   E? USR:$

        Date: 06/09/79 03:47:19
        From: RWK at MIT-MC
        To:   (BUG TECO)
        Re:   E? USR:$

        creates an inferior.  It should set the bit saying to fail if the job
        doesn't exist.

    Even better would be to have the USR: device obey the same convention
    as the DSK: device, i.e. if you open for reading then it is an error
    if it doesn't exist.  RWK, you said once DDT could be fixed if ITS
    were so changed, is that still true?
Yes, it's still true.

\1f
Date: 10 JUN 1979 1242-EDT
From: EAK at MIT-MC (Earl A. Killian)
Subject:  E? USR:$
To: RWK at MIT-MC, (BUG ITS) at MIT-MC
CC: (BUG TECO) at MIT-MC

    Date: 06/09/79 03:47:19
    From: RWK at MIT-MC
    To:   (BUG TECO)
    Re:   E? USR:$

    creates an inferior.  It should set the bit saying to fail if the job
    doesn't exist.

Even better would be to have the USR: device obey the same convention
as the DSK: device, i.e. if you open for reading then it is an error
if it doesn't exist.  RWK, you said once DDT could be fixed if ITS
were so changed, is that still true?

\1f
JKESS@MIT-MC 06/01/79 03:02:59 Re: to whoever is maintaining the CROCKS again
To: (BUG ITS) at MIT-MC
and CROCK loses its center point, writing randomly.

Both of these are new bugs -- CROCK ran perfectly before today...
\1f
JKESS@MIT-MC 06/01/79 03:00:58 Re: to whoever maintains the CROCKs...
To: (BUG ITS) at MIT-MC
DCROCK fails totally to get its digit positioning right on VT100s.
\1f