From CStacyatMIT-MC  Fri Apr 29 00:00:00 1983
From: CStacyatMIT-MC (Christopher C. Stacy)
Date: Friday, 29 April 1983, 00:00
Subject: No subject
In-Reply-To: The message of 28 Apr 83 16:59-EDT from David C. Plummer <DCP at MIT-MC>
Message-ID: <mailman.0.1479821103.4695.its@nocrew.org>

    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.

From Ian at MIT-OZ  Thu Apr 28 23:43:00 1983
From: Ian at MIT-OZ (Ian Macky)
Date: Apr 28 1983  17:43 EDT (Thu)
Subject: ARPA server
In-Reply-To: Msg of 28 Apr 1983 17:13 EDT from David C. Plummer <DCP at MIT-MC>
Message-ID: <mailman.1.1479821103.4695.its@nocrew.org>

Ah, OK, thanks much -- All it needed was for me to send a NL after
the connection was established.

From DCP at MIT-MC  Thu Apr 28 23:13:00 1983
From: DCP at MIT-MC (David C. Plummer)
Date: April 28 1983 17:13 EDT
Subject: ARPA server
Message-ID: <mailman.2.1479821103.4695.its@nocrew.org>

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 mcTCP rutgers 117 (the caps
are important).  When it opens the connection, type return.

From DCP at MIT-MC  Thu Apr 28 22:59:00 1983
From: DCP at MIT-MC (David C. Plummer)
Date: April 28 1983 16:59 EDT
Subject: No subject
Message-ID: <mailman.3.1479821103.4695.its@nocrew.org>

    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.

From CSTACY at MIT-MC  Thu Apr 28 03:41:00 1983
From: CSTACY at MIT-MC (Christopher C. Stacy)
Date: April 27 1983 21:41 EDT
Subject: No subject
Message-ID: <mailman.4.1479821103.4695.its@nocrew.org>


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.


From Ian at MIT-OZ  Thu Apr 28 02:22:00 1983
From: Ian at MIT-OZ (Ian Macky)
Date: Apr 27 1983  20:22 EDT (Wed)
Subject: ARPA server
In-Reply-To: Msg of 11 Apr 1983 06:39 EST from David C. Plummer <DCP at MIT-MC>
Message-ID: <mailman.5.1479821103.4695.its@nocrew.org>

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.

From CStacy at MIT-OZ  Wed Apr 27 00:00:00 1983
From: CStacy at MIT-OZ (Christopher Stacy)
Date: Wednesday, 27 April 1983, 00:00
Subject: SYS:
In-Reply-To: The message of 27 Apr 83 05:24-EDT from Alan Bawden <ALAN at MIT-MC>
Message-ID: <mailman.6.1479821103.4695.its@nocrew.org>

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?


From DCP at MIT-MC  Wed Apr 27 17:04:00 1983
From: DCP at MIT-MC (David C. Plummer)
Date: April 27 1983 11:04 EDT
Subject: SYS:
Message-ID: <mailman.7.1479821103.4695.its@nocrew.org>


    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.

From CStacyatMIT-OZ  Wed Apr 27 00:00:00 1983
From: CStacyatMIT-OZ (Christopher Stacy)
Date: Wednesday, 27 April 1983, 00:00
Subject: SYS:
In-Reply-To: The message of 27 Apr 83 05:24-EDT from Alan Bawden <ALAN at MIT-MC>
Message-ID: <mailman.8.1479821103.4695.its@nocrew.org>

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?


From ALAN at MIT-MC  Wed Apr 27 11:24:00 1983
From: ALAN at MIT-MC (Alan Bawden)
Date: April 27 1983 05:24 EDT
Subject: SYS:
In-Reply-To: Msg of 27 Apr 1983 02:36 EDT from Devon S. McCullough <DEVON>
Message-ID: <mailman.9.1479821103.4695.its@nocrew.org>

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

From DEVON at MIT-MC  Wed Apr 27 08:36:00 1983
From: DEVON at MIT-MC (Devon S. McCullough)
Date: April 27 1983 02:36 EDT
Subject: No subject
Message-ID: <mailman.10.1479821103.4695.its@nocrew.org>

Why doesn't SYS: look in the overflow directories SYS1; SYS2; SYS3; prray tell?

From ALAN at MIT-MC  Wed Apr 27 07:20:00 1983
From: ALAN at MIT-MC (Alan Bawden)
Date: April 27 1983 01:20 EDT
Subject: CRASH;CRASH QSKCH
In-Reply-To: Msg of 26 Apr 1983 09:33 EDT from Ken Harrenstien <KLH>
Message-ID: <mailman.11.1479821103.4695.its@nocrew.org>

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

From SOLEY at MIT-MC  Tue Apr 26 19:05:00 1983
From: SOLEY at MIT-MC (Richard Mark Soley)
Date: April 26 1983 13:05 EDT
Subject: CRASH;QSKCH
In-Reply-To: Msg of 26 Apr 1983 05:56 EDT from Christopher C. Stacy <CSTACY>
Message-ID: <mailman.12.1479821103.4695.its@nocrew.org>

    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

From KLH at MIT-MC  Tue Apr 26 15:33:00 1983
From: KLH at MIT-MC (Ken Harrenstien)
Date: April 26 1983 09:33 EDT
Subject: CRASH;CRASH QSKCH
Message-ID: <mailman.13.1479821103.4695.its@nocrew.org>

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

From CSTACY at MIT-MC  Tue Apr 26 13:01:00 1983
From: CSTACY at MIT-MC (Christopher C. Stacy)
Date: April 26 1983 07:01 EDT
Subject: Translations
In-Reply-To: Msg of 23 Apr 1983 16:23 EST from Alan Bawden <ALAN>
Message-ID: <mailman.14.1479821103.4695.its@nocrew.org>


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



From CSTACY at MIT-MC  Tue Apr 26 11:56:00 1983
From: CSTACY at MIT-MC (Christopher C. Stacy)
Date: April 26 1983 05:56 EDT
Subject: CRASH;QSKCH
Message-ID: <mailman.15.1479821103.4695.its@nocrew.org>


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


From CSTACY at MIT-MC  Tue Apr 26 11:17:00 1983
From: CSTACY at MIT-MC (Christopher C. Stacy)
Date: April 26 1983 05:17 EDT
Subject: No subject
Message-ID: <mailman.16.1479821103.4695.its@nocrew.org>

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

From CStacyatMIT-MC  Tue Apr 26 00:00:00 1983
From: CStacyatMIT-MC (Christopher C. Stacy)
Date: Tuesday, 26 April 1983, 00:00
Subject: FileComputer
In-Reply-To: The message of 24 Apr 83 14:11-EDT from Peter Szolovits <PSZ at MIT-ML>
Message-ID: <mailman.17.1479821103.4695.its@nocrew.org>

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



From JPG at MIT-MC  Tue Apr 26 00:18:00 1983
From: JPG at MIT-MC (Jeffrey P. Golden)
Date: April 25 1983 18:18 EDT
Subject: No subject
Message-ID: <mailman.18.1479821103.4695.its@nocrew.org>

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

From DCP at MIT-MC  Mon Apr 25 10:13:00 1983
From: DCP at MIT-MC (David C. Plummer)
Date: April 25 1983 04:13 EDT
Subject: ASSLIS is such a kludge!
Message-ID: <mailman.19.1479821103.4695.its@nocrew.org>

    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.

From ALAN at MIT-MC  Mon Apr 25 01:31:00 1983
From: ALAN at MIT-MC (Alan Bawden)
Date: April 24 1983 18:31 EST
Subject: ASSLIS is such a kludge!
Message-ID: <mailman.20.1479821103.4695.its@nocrew.org>

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

From PSZ at MIT-ML  Sun Apr 24 20:11:00 1983
From: PSZ at MIT-ML (Peter Szolovits)
Date: April 24 1983 13:11 EST
Subject: FileComputer
In-Reply-To: Msg of 24 Apr 1983  01:49 EST (Sun) from Howard D. Trachtman <HDT at MIT-OZ>
Message-ID: <mailman.21.1479821103.4695.its@nocrew.org>

    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?


From MoonatMIT-MC  Sun Apr 24 00:00:00 1983
From: MoonatMIT-MC (David A. Moon)
Date: Sunday, 24 April 1983, 00:00
Subject: Running out of low core
In-Reply-To: The message of 19 Apr 83 21:17-EST from Christopher C. Stacy <CSTACY at MIT-MC>
Message-ID: <mailman.22.1479821103.4695.its@nocrew.org>

    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?

From ALAN at MIT-MC  Sat Apr 23 23:23:00 1983
From: ALAN at MIT-MC (Alan Bawden)
Date: April 23 1983 16:23 EST
Subject: Translations
In-Reply-To: Msg of 23 Apr 1983 1328-EST from Paul G. Weiss <PGW at MIT-XX>
Message-ID: <mailman.23.1479821103.4695.its@nocrew.org>

    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:

    ------------------------------------------------
    * arch;* *,ar1:inna;* *
      ...
    *:find arch;
     INFERIOR-CREATION FAILED? u:BYE
      INFERIOR-CREATION FAILED?:INPUSH  1u

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


From PGW at MIT-XX  Sat Apr 23 00:00:00 1983
From: PGW at MIT-XX (Paul G. Weiss)
Date: 23 Apr 1983, 00:00
Subject: Translations
Message-ID: <mailman.24.1479821103.4695.its@nocrew.org>

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

 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 u since it tries and fails to run
:BYE.  I must log out with 1u (or remove the translation).

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

------------------------------------------------
* arch;* *,ar1:inna;* *
*archML  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? u:BYE
  INFERIOR-CREATION FAILED?:INPUSH  1u
-----------------------------------------
-------


From RWK at SCRC-TENEX  Fri Apr 22 00:00:00 1983
From: RWK at SCRC-TENEX (Robert W. Kerns)
Date: Friday, 22 April 1983, 00:00
Subject: No subject
In-Reply-To: The message of 19 Apr 83 21:17-EST from Christopher C. Stacy <CSTACY at MIT-MC>
Message-ID: <mailman.25.1479821103.4695.its@nocrew.org>

    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.

From CSTACY at MIT-MC  Fri Apr 22 15:21:00 1983
From: CSTACY at MIT-MC (Christopher C. Stacy)
Date: April 22 1983 08:21 EST
Subject: No subject
Message-ID: <mailman.26.1479821103.4695.its@nocrew.org>


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.

From CStacyatMIT-OZ  Fri Apr 22 00:00:00 1983
From: CStacyatMIT-OZ (Christopher Stacy)
Date: Friday, 22 April 1983, 00:00
Subject: MC is now the bug host.
Message-ID: <mailman.27.1479821103.4695.its@nocrew.org>

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

From DCP at MIT-MC  Wed Apr 20 08:44:00 1983
From: DCP at MIT-MC (David C. Plummer)
Date: April 20 1983 01:44 EST
Subject: [Forwarded: COMSAT, Re: [Forwarded: Hank.Walker@CMU-CS-VLSI, Re: Mailer problems]]
Message-ID: <mailman.28.1479821103.4695.its@nocrew.org>

Date: April 15 1983 08:51 EST
From: David C. Plummer <DCP @ MIT-MC>
Subject: [Forwarded: Hank.Walker at 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: April 14 1983 21:15:03 EST
From: Hank.Walker at CMU-CS-VLSI
To: David C.Plummer <DCP at MIT-MC>
Subject: Mailer problems
Message-ID: <1983.4.15.2.10.27.Hank.Walker at 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.

From DCP at MIT-MC  Wed Apr 20 08:44:00 1983
From: DCP at MIT-MC (David C. Plummer)
Date: April 20 1983 01:44 EST
Subject: [Forwarded: COMSAT, Re: [Forwarded: Hank.Walker@CMU-CS-VLSI, Re: Infinite mail messages]]
Message-ID: <mailman.29.1479821103.4695.its@nocrew.org>

I originally sent this to BUG-MAIL at 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: April 14 1983 21:04 EST
From: David C. Plummer <DCP @ MIT-MC>
Subject: [Forwarded: Hank.Walker at 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 at CMU-CS-VLSI
    To: David C.Plummer <DCP at MIT-MC>
    Subject: Infinite mail messages
    Message-ID: <1983.4.15.1.49.7.Hank.Walker at 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 at 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 at 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

From DCP at MIT-ML  Tue Apr 19 00:00:00 1983
From: DCP at MIT-ML (DCP at MIT-ML)
Date: 19 Apr 1983 00:00
Subject: No subject
Message-ID: <mailman.30.1479821103.4695.its@nocrew.org>

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?


From CSTACY at MIT-MC  Wed Apr 20 04:18:00 1983
From: CSTACY at MIT-MC (Christopher C. Stacy)
Date: April 19 1983 21:18 EST
Subject: No subject
Message-ID: <mailman.31.1479821103.4695.its@nocrew.org>


In XITS on MC, I patched out the LMEMFR check bug message for the moment.

From CSTACY at MIT-MC  Wed Apr 20 04:17:00 1983
From: CSTACY at MIT-MC (Christopher C. Stacy)
Date: April 19 1983 21:17 EST
Subject: No subject
Message-ID: <mailman.32.1479821103.4695.its@nocrew.org>


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?


From CSTACY at MIT-MC  Sat Apr 16 11:36:00 1983
From: CSTACY at MIT-MC (Christopher C. Stacy)
Date: April 16 1983 04:36 EST
Subject: No subject
Message-ID: <mailman.33.1479821103.4695.its@nocrew.org>

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.

From CSTACY at MIT-MC  Sat Apr 16 09:52:00 1983
From: CSTACY at MIT-MC (Christopher C. Stacy)
Date: April 16 1983 02:52 EST
Subject: crash info
Message-ID: <mailman.34.1479821103.4695.its@nocrew.org>

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.

From CSTACY at MIT-MC  Sat Apr 16 08:17:00 1983
From: CSTACY at MIT-MC (Christopher C. Stacy)
Date: April 16 1983 01:17 EST
Subject: hardware trouble
Message-ID: <mailman.35.1479821103.4695.its@nocrew.org>


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.

From KLH at MIT-MC  Thu Apr 14 02:56:00 1983
From: KLH at MIT-MC (Ken Harrenstien)
Date: April 13 1983 19:56 EST
Subject: ML doesn't like to talk to the Symbolics ethernet (and any future new subnets)
Message-ID: <mailman.36.1479821104.4695.its@nocrew.org>

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.

From Moon at SCRC-TENEX  Wed Apr 13 00:00:00 1983
From: Moon at SCRC-TENEX (David A. Moon)
Date: Wednesday, 13 April 1983, 00:00
Subject: ML doesn't like to talk to the Symbolics ethernet (and any future new subnets)
Message-ID: <mailman.37.1479821104.4695.its@nocrew.org>

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.
    
    

From DCP at SCRC-TENEX  Wed Apr 13 00:00:00 1983
From: DCP at SCRC-TENEX (David C. Plummer)
Date: Wednesday, 13 April 1983, 00:00
Subject: (load "ml:router;pi >") never works from a 3600 at Symbolics
In-Reply-To: The message of 13 Apr 83 19:18-EST from Clark M. Baker <cmb at SCRC-VIXEN>
Message-ID: <mailman.38.1479821104.4695.its@nocrew.org>

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

From DCP at MIT-MC  Mon Apr 11 13:39:00 1983
From: DCP at MIT-MC (David C. Plummer)
Date: April 11 1983 06:39 EST
Subject: ARPA server
Message-ID: <mailman.39.1479821104.4695.its@nocrew.org>

    Date: 10 Apr 1983 1954-EST
    From: Ian Macky <Ian at 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).

From Ian at MIT-OZ  Sun Apr 10 00:00:00 1983
From: Ian at MIT-OZ (Ian Macky)
Date: 10 Apr 1983, 00:00
Subject: ARPA server
Message-ID: <mailman.40.1479821104.4695.its@nocrew.org>

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

From DCP at MIT-MC  Fri Apr  8 06:13:00 1983
From: DCP at MIT-MC (David C. Plummer)
Date: April 7 1983 23:13 EST
Subject: No subject
Message-ID: <mailman.41.1479821104.4695.its@nocrew.org>

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

From ALAN at MIT-MC  Fri Apr  8 00:26:00 1983
From: ALAN at MIT-MC (Alan Bawden)
Date: April 7 1983 17:26 EST
Subject: No subject
Message-ID: <mailman.42.1479821104.4695.its@nocrew.org>

DIRHNG^F acts pretty graceless.  Actually I can imagine that DIRHNG could
reasonably display an informative directory.

From CSTACY at MIT-AI  Tue Apr  5 00:00:00 1983
From: CSTACY at MIT-AI (CSTACY at MIT-AI)
Date: 05 Apr 1983 00:00
Subject: No subject
Message-ID: <mailman.43.1479821104.4695.its@nocrew.org>

In ITS 1332, on MIT-AI:

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


From KLOTZ at MIT-OZ  Tue Apr  5 11:45:00 1983
From: KLOTZ at MIT-OZ (Leigh L. Klotz)
Date: Apr 5 1983  04:45 EST
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>
Message-ID: <mailman.44.1479821104.4695.its@nocrew.org>

KLH knows more about midas than most people, including you.  Please keep
your nitbrained views to yourself.

From ALAN at MIT-MC  Tue Apr  5 08:43:00 1983
From: ALAN at MIT-MC (Alan Bawden)
Date: April 5 1983 01:43 EST
Subject: Gross OZ lossage
In-Reply-To: Msg of 4 Apr 1983  23:19 EST (Mon) from Martin David Connor <MARTY at MIT-OZ>
Message-ID: <mailman.45.1479821104.4695.its@nocrew.org>

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.

From DCP at MIT-MC  Tue Apr  5 07:57:00 1983
From: DCP at MIT-MC (David C. Plummer)
Date: April 5 1983 00:57 EST
Subject: Gross 8 inch spikes in various people's heads
Message-ID: <mailman.46.1479821104.4695.its@nocrew.org>

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.

From MARTY at MIT-OZ  Tue Apr  5 06:19:00 1983
From: MARTY at MIT-OZ (Martin David Connor)
Date: Apr 4 1983  23:19 EST (Mon)
Subject: Gross ITS lossage
In-Reply-To: Msg of 4 Apr 1983 21:40 EST from David C. Plummer <DCP at MIT-MC>
Message-ID: <mailman.47.1479821104.4695.its@nocrew.org>


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.


From DCP at MIT-MC  Tue Apr  5 04:40:00 1983
From: DCP at MIT-MC (David C. Plummer)
Date: April 4 1983 21:40 EST
Subject: Gross OZ lossage
Message-ID: <mailman.48.1479821104.4695.its@nocrew.org>

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

From NCP.EGK at SU-GSB-HOWatSU-SCORE  Mon Apr  4 00:00:00 1983
From: NCP.EGK at SU-GSB-HOWatSU-SCORE (Edjik)
Date: Mon 4 Apr 83, 00:00
Subject: Gross OZ lossage
In-Reply-To: Your message of Mon 4 Apr 83 13:53:00-PST
Message-ID: <mailman.49.1479821104.4695.its@nocrew.org>

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

From Ian at MIT-OZ  Mon Apr  4 22:31:00 1983
From: Ian at MIT-OZ (Ian Macky)
Date: Apr 4 1983  15:31 EST (Mon)
Subject: Gross OZ lossage
In-Reply-To: Msg of 4 Apr 1983 13:53 EST from Ken Harrenstien <KLH at MIT-MC>
Message-ID: <mailman.50.1479821104.4695.its@nocrew.org>

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.

From KLH at MIT-MC  Mon Apr  4 20:53:00 1983
From: KLH at MIT-MC (Ken Harrenstien)
Date: April 4 1983 13:53 EST
Subject: Gross OZ lossage
Message-ID: <mailman.51.1479821104.4695.its@nocrew.org>

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.

From GZ at MIT-MC  Mon Apr  4 17:26:00 1983
From: GZ at MIT-MC (Gail Zacharias)
Date: April 4 1983 10:26 EST
Subject: [JMSK: forwarded]
Message-ID: <mailman.52.1479821104.4695.its@nocrew.org>

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 ?

From PDL at MIT-XX  Sun Apr  3 00:00:00 1983
From: PDL at MIT-XX (P. David Lebling)
Date: 3 Apr 1983, 00:00
Subject: ARC device directories
In-Reply-To: Your message of 19-Mar-83 2245-EST
Message-ID: <mailman.53.1479821104.4695.its@nocrew.org>

DIRED (not EMACS DIRED) and FIND depend on it.
-------

From SASW at MIT-MC  Sun Apr  3 08:59:00 1983
From: SASW at MIT-MC (Steven A. Swernofsky)
Date: April 3 1983 01:59 EST
Subject: No subject
Message-ID: <mailman.54.1479821104.4695.its@nocrew.org>

The annoying 15-second (?) pause in output has returned!  -- Steve

From CSTACY at MIT-MC  Fri Apr  1 09:13:00 1983
From: CSTACY at MIT-MC (Christopher C. Stacy)
Date: April 1 1983 02:13 EST
Subject: take paws off keys and wait
Message-ID: <mailman.55.1479821104.4695.its@nocrew.org>

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

From ALAN at MIT-MC  Fri Apr  1 08:04:00 1983
From: ALAN at MIT-MC (Alan Bawden)
Date: April 1 1983 01:04 EST
Subject: take paws off keys and wait
In-Reply-To: Msg of 04/01/83 00:21:35 from JSPEAR@MIT-AI
Message-ID: <mailman.56.1479821104.4695.its@nocrew.org>

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


From JSPEAR at MIT-AI  Fri Apr  1 00:00:00 1983
From: JSPEAR at MIT-AI (JSPEAR at MIT-AI)
Date: 01 Apr 1983 00:00
Subject: No subject
Message-ID: <mailman.57.1479821104.4695.its@nocrew.org>

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