From ALAN at MIT-MC  Fri Apr 30 00:00:00 1982
From: ALAN at MIT-MC (ALAN at MIT-MC)
Date: 30 Apr 1982 00:00
Subject: No subject
Message-ID: <mailman.360.1479821110.4695.its@nocrew.org>

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?

From ELLEN at MIT-MC  Tue Apr 27 00:00:00 1982
From: ELLEN at MIT-MC (ELLEN at MIT-MC)
Date: 27 Apr 1982 00:00
Subject: Changing the default for :find
Message-ID: <mailman.361.1479821110.4695.its@nocrew.org>

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.


From GJC at MIT-MC  Mon Apr 26 00:00:00 1982
From: GJC at MIT-MC (GJC at MIT-MC)
Date: 26 Apr 1982 00:00
Subject: No subject
Message-ID: <mailman.362.1479821110.4695.its@nocrew.org>

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.



From DEVON at MIT-MC  Sun Apr 25 00:00:00 1982
From: DEVON at MIT-MC (DEVON at MIT-MC)
Date: 25 Apr 1982 00:00
Subject: No subject
Message-ID: <mailman.363.1479821110.4695.its@nocrew.org>

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.

From GUMBYatMIT-AI  Sat Apr 24 00:00:00 1982
From: GUMBYatMIT-AI (David Vinayak Wallace)
Date: Saturday, 24 April 1982, 00:00
Subject: Access from DC area
Message-ID: <mailman.364.1479821110.4695.its@nocrew.org>

    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!

From PALLEN  Fri Apr 23 00:00:00 1982
From: PALLEN (Peter Allen)
Date: 23 Apr 1982, 00:00
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


From KLOTZatMIT-AI  Thu Apr 22 00:00:00 1982
From: KLOTZatMIT-AI (Leigh L. Klotz)
Date: 22 April 1982, 00:00
Subject: No subject
Message-ID: <mailman.365.1479821110.4695.its@nocrew.org>

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.

From RWKatSCRC-TENEX  Tue Apr 20 00:00:00 1982
From: RWKatSCRC-TENEX (Robert W. Kerns)
Date: 20 Apr 1982, 00:00
Subject: No subject
In-Reply-To: Your message of 20-Apr-82 0105-EST
Message-ID: <mailman.366.1479821110.4695.its@nocrew.org>

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

From MARTYatMIT-AI  Tue Apr 20 00:00:00 1982
From: MARTYatMIT-AI (Martin David Connor)
Date: 20 April 1982, 00:00
Subject: No subject
Message-ID: <mailman.367.1479821110.4695.its@nocrew.org>

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

Marty


From CSTACYatMIT-AI  Mon Apr 19 00:00:00 1982
From: CSTACYatMIT-AI (Christopher C. Stacy)
Date: 19 April 1982, 00:00
Subject: No subject
Message-ID: <mailman.368.1479821110.4695.its@nocrew.org>


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.

From EBatMIT-AI  Mon Apr 19 00:00:00 1982
From: EBatMIT-AI (Edward Barton)
Date: 19 April 1982, 00:00
Subject: No subject
Message-ID: <mailman.369.1479821110.4695.its@nocrew.org>

Is pack 15 ever going to have anything except zeros on it?

From MARTYatMIT-AI  Mon Apr 19 00:00:00 1982
From: MARTYatMIT-AI (Martin David Connor)
Date: 19 April 1982, 00:00
Subject: Anatomy of Lossage
Message-ID: <mailman.370.1479821110.4695.its@nocrew.org>


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


From MoonatSCRC-TENEX  Fri Apr 16 00:00:00 1982
From: MoonatSCRC-TENEX (David A. Moon)
Date: Friday, 16 April 1982, 00:00
Subject: No subject
In-Reply-To: The message of 15 Apr 82 12:49-EST from Patrick G. Sobalvarro <PGS at MIT-AI>
Message-ID: <mailman.371.1479821110.4695.its@nocrew.org>

    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.

From PGSatMIT-AI  Thu Apr 15 00:00:00 1982
From: PGSatMIT-AI (Patrick G. Sobalvarro)
Date: 15 April 1982, 00:00
Subject: No subject
Message-ID: <mailman.372.1479821110.4695.its@nocrew.org>

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.

From PGSatMIT-AI  Wed Apr 14 00:00:00 1982
From: PGSatMIT-AI (Patrick G. Sobalvarro)
Date: 14 April 1982, 00:00
Subject: No subject
Message-ID: <mailman.373.1479821110.4695.its@nocrew.org>

    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.

From ALANatMIT-MC  Wed Apr 14 00:00:00 1982
From: ALANatMIT-MC (Alan Bawden)
Date: 14 April 1982, 00:00
Subject: No subject
Message-ID: <mailman.374.1479821110.4695.its@nocrew.org>


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

From ALANatMIT-MC  Wed Apr 14 00:00:00 1982
From: ALANatMIT-MC (Alan Bawden)
Date: 14 April 1982, 00:00
Subject: No subject
Message-ID: <mailman.375.1479821110.4695.its@nocrew.org>


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

From ZvonaatMIT-AI  Wed Apr 14 00:00:00 1982
From: ZvonaatMIT-AI (David Chapman)
Date: Wednesday, 14 April 1982, 00:00
Subject: No subject
In-Reply-To: The message of 14 Apr 82 16:14-EST from Patrick G. Sobalvarro <PGS at MIT-AI>
Message-ID: <mailman.376.1479821110.4695.its@nocrew.org>

    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.

From PGSatMIT-AI  Wed Apr 14 00:00:00 1982
From: PGSatMIT-AI (Patrick G. Sobalvarro)
Date: 14 April 1982, 00:00
Subject: No subject
Message-ID: <mailman.377.1479821110.4695.its@nocrew.org>

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

    mc^K => ERROR: OPEN:  USR: DPH;  - DEVICE FULL
    levitt^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.

From zvonaatMIT-AI  Wed Apr 14 00:00:00 1982
From: zvonaatMIT-AI (David Chapman)
Date: 14 April 1982, 00:00
Subject: No subject
Message-ID: <mailman.378.1479821110.4695.its@nocrew.org>

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

Obviously there is some fundamental bogosity here.

From PGS at MIT-MC  Sun Apr 11 00:00:00 1982
From: PGS at MIT-MC (PGS at MIT-MC)
Date: 11 Apr 1982 00:00
Subject: No subject
Message-ID: <mailman.379.1479821110.4695.its@nocrew.org>

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.


From MARTYatMIT-AI  Sat Apr 10 00:00:00 1982
From: MARTYatMIT-AI (Martin David Connor)
Date: 10 April 1982, 00:00
Subject: OZ Shutdown
Message-ID: <mailman.380.1479821110.4695.its@nocrew.org>

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


From CSTACYatMIT-AI  Fri Apr  9 00:00:00 1982
From: CSTACYatMIT-AI (Christopher C. Stacy)
Date: 9 April 1982, 00:00
Subject: bogus ITS version number resolved
Message-ID: <mailman.381.1479821110.4695.its@nocrew.org>

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

From CStacyatMIT-AI  Thu Apr  8 00:00:00 1982
From: CStacyatMIT-AI (Christopher C. Stacy)
Date: 8 April 1982, 00:00
Subject: The :NAME program
Message-ID: <mailman.382.1479821110.4695.its@nocrew.org>

    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.

From MoonatSCRC-TENEX  Thu Apr  8 00:00:00 1982
From: MoonatSCRC-TENEX (David A. Moon)
Date: Thursday, 8 April 1982, 00:00
Subject: The :NAME program
Message-ID: <mailman.383.1479821110.4695.its@nocrew.org>

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.

From PGSatMIT-AI  Thu Apr  8 00:00:00 1982
From: PGSatMIT-AI (Patrick G. Sobalvarro)
Date: 8 April 1982, 00:00
Subject: name and finger losing in this morning's ITS
Message-ID: <mailman.384.1479821110.4695.its@nocrew.org>

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.

From AGREatMIT-AI  Thu Apr  8 00:00:00 1982
From: AGREatMIT-AI (Philip E. Agre)
Date: 8 April 1982, 00:00
Subject: No subject
Message-ID: <mailman.385.1479821110.4695.its@nocrew.org>

:NAME loses in the ITS that was brought up this morning.  You get
.VAL 0; 252>>.LOGOU   0/   10400,,500000
when it's done.

From KLOTZatMIT-AI  Tue Apr  6 00:00:00 1982
From: KLOTZatMIT-AI (Leigh L. Klotz)
Date: 6 April 1982, 00:00
Subject: No subject
Message-ID: <mailman.386.1479821110.4695.its@nocrew.org>

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.

From PDL  Tue Apr  6 00:00:00 1982
From: PDL (PDL)
Date: 6 Apr 1982, 00:00
Subject: No subject
In-Reply-To: Your message of 6-Apr-82 0107-EST
Message-ID: <mailman.387.1479821110.4695.its@nocrew.org>

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


From PGSatMIT-AI  Tue Apr  6 00:00:00 1982
From: PGSatMIT-AI (Patrick G. Sobalvarro)
Date: 6 April 1982, 00:00
Subject: No subject
Message-ID: <mailman.388.1479821110.4695.its@nocrew.org>

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

From GJS at MIT-MC  Tue Apr  6 00:00:00 1982
From: GJS at MIT-MC (GJS at MIT-MC)
Date: 06 Apr 1982 00:00
Subject: No subject
Message-ID: <mailman.389.1479821110.4695.its@nocrew.org>

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?


From GJS at MIT-MC  Tue Apr  6 00:00:00 1982
From: GJS at MIT-MC (GJS at MIT-MC)
Date: 06 Apr 1982 00:00
Subject: No subject
Message-ID: <mailman.390.1479821110.4695.its@nocrew.org>

I don't know where this bug should go, but 
:find mc:scheme;_sav4 *
goes into an infinite loop.