From ALAN at MIT-MC  Sun Jan 31 00:00:00 1982
From: ALAN at MIT-MC (ALAN at MIT-MC)
Date: 31 Jan 1982 00:00
Subject: No subject
Message-ID: <mailman.432.1479821111.4695.its@nocrew.org>

> doesn't work when opening any of the core-link devices.
(who cares!)

From KLOTZatMIT-AI  Thu Jan 28 00:00:00 1982
From: KLOTZatMIT-AI (Leigh L. Klotz)
Date: 28 January 1982, 00:00
Subject: No subject
Message-ID: <mailman.433.1479821111.4695.its@nocrew.org>

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.

From EDatMIT-AI  Thu Jan 28 00:00:00 1982
From: EDatMIT-AI (Ed Schwalenberg)
Date: 28 January 1982, 00:00
Subject: TTY:.FILE. (DIR)
Message-ID: <mailman.434.1479821111.4695.its@nocrew.org>

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.

From MACRAKatMIT-MC  Wed Jan 27 00:00:00 1982
From: MACRAKatMIT-MC (Stavros M. Macrakis)
Date: 27 January 1982, 00:00
Subject: ULSPBR
Message-ID: <mailman.435.1479821111.4695.its@nocrew.org>

Yes, I know it's unfinished; so presumably the variable can be flushed.


From MOON at MIT-MC  Wed Jan 27 00:00:00 1982
From: MOON at MIT-MC (MOON at MIT-MC)
Date: 27 Jan 1982 00:00
Subject: ULSPBR
Message-ID: <mailman.436.1479821111.4695.its@nocrew.org>

It's a feature that GLS never finished.

From MACRAK at MIT-MC  Tue Jan 26 00:00:00 1982
From: MACRAK at MIT-MC (MACRAK at MIT-MC)
Date: 26 Jan 1982 00:00
Subject: No subject
Message-ID: <mailman.437.1479821111.4695.its@nocrew.org>

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.

From MACRAKatMIT-MC  Tue Jan 26 00:00:00 1982
From: MACRAKatMIT-MC (Stavros M. Macrakis)
Date: 26 January 1982, 00:00
Subject: Disk delay
Message-ID: <mailman.438.1479821111.4695.its@nocrew.org>

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.


From GUMBYatMIT-AI  Sat Jan 23 00:00:00 1982
From: GUMBYatMIT-AI (David Vinayak Wallace)
Date: 23 January 1982, 00:00
Subject: No subject
Message-ID: <mailman.439.1479821111.4695.its@nocrew.org>

the file ai:.info.;its locks cantains nothing but nulls.
Perhaps other fies got destroyed in the crash?

From RMSatMIT-AI  Fri Jan 22 00:00:00 1982
From: RMSatMIT-AI (Richard M. Stallman)
Date: 22 January 1982, 00:00
Subject: No subject
Message-ID: <mailman.440.1479821111.4695.its@nocrew.org>

AI crashed with QFUD/1 but every QSNUD was nonzero.

From DCP at MIT-MC  Sat Jan 16 00:00:00 1982
From: DCP at MIT-MC (DCP at MIT-MC)
Date: 16 Jan 1982 00:00
Subject: No subject
Message-ID: <mailman.441.1479821111.4695.its@nocrew.org>

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


From GREN at MIT-MC  Sat Jan 16 00:00:00 1982
From: GREN at MIT-MC (GREN at MIT-MC)
Date: 16 Jan 1982 00:00
Subject: No subject
Message-ID: <mailman.442.1479821111.4695.its@nocrew.org>

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

From SWG  Wed Jan 13 00:00:00 1982
From: SWG (S. W. Galley)
Date: 13 Jan 1982, 00:00
Subject: [Re: :HISTORY Lossage on DMS]
In-Reply-To: Message of 18 Dec 81 at 0359 EST by mike@BRL
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!


From ED at MIT-AI  Wed Jan 13 00:00:00 1982
From: ED at MIT-AI (ED at MIT-AI)
Date: 13 Jan 1982 00:00
Subject: Is one-proceed broken on MC?
Message-ID: <mailman.444.1479821111.4695.its@nocrew.org>

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  and  are now abbreviations for P.
Emacs complains of PDL overflow when proceeded in this way, which explains
some bizarre behavior when I accidentally typed a  the other day.


From DCP at MIT-MC  Tue Jan 12 00:00:00 1982
From: DCP at MIT-MC (DCP at MIT-MC)
Date: 12 Jan 1982 00:00
Subject: Is one-proceed broken on MC?
Message-ID: <mailman.445.1479821111.4695.its@nocrew.org>

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? 


From GSB at MIT-ML  Mon Jan 11 00:00:00 1982
From: GSB at MIT-ML (GSB at MIT-ML)
Date: 11 Jan 1982 00:00
Subject: ml dialups
Message-ID: <mailman.446.1479821111.4695.its@nocrew.org>

    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.


From RSG at MIT-ML  Mon Jan 11 00:00:00 1982
From: RSG at MIT-ML (RSG at MIT-ML)
Date: 11 Jan 1982 00:00
Subject: No subject
Message-ID: <mailman.447.1479821111.4695.its@nocrew.org>

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


From RMS at MIT-AI  Mon Jan 11 00:00:00 1982
From: RMS at MIT-AI (RMS at MIT-AI)
Date: 11 Jan 1982 00:00
Subject: Purpg on CBLok Corblk
Message-ID: <mailman.448.1479821111.4695.its@nocrew.org>

I will do something reasonable about this situation.



From CSTACYatMIT-AI  Sun Jan 10 00:00:00 1982
From: CSTACYatMIT-AI (Christopher C. Stacy)
Date: 10 January 1982, 00:00
Subject: where is the DISK listing
Message-ID: <mailman.449.1479821111.4695.its@nocrew.org>


I frequently borrow the source listings, and if I have one it can
always be found in top of my desk in 926.

From MACRAK at MIT-MC  Sun Jan 10 00:00:00 1982
From: MACRAK at MIT-MC (MACRAK at MIT-MC)
Date: 10 Jan 1982 00:00
Subject: Purpg on CBLok Corblk
Message-ID: <mailman.450.1479821111.4695.its@nocrew.org>

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?


From RMS at MIT-MC  Sun Jan 10 00:00:00 1982
From: RMS at MIT-MC (RMS at MIT-MC)
Date: 10 Jan 1982 00:00
Subject: No subject
Message-ID: <mailman.451.1479821111.4695.its@nocrew.org>

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.


From RMSatMIT-AI  Sun Jan 10 00:00:00 1982
From: RMSatMIT-AI (Richard M. Stallman)
Date: 10 January 1982, 00:00
Subject: No subject
Message-ID: <mailman.452.1479821111.4695.its@nocrew.org>

Does anyone know where the listing of DISK is?

From RMSatMIT-AI  Sun Jan 10 00:00:00 1982
From: RMSatMIT-AI (Richard M. Stallman)
Date: 10 January 1982, 00:00
Subject: No subject
Message-ID: <mailman.453.1479821111.4695.its@nocrew.org>

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.

From MACRAKatMIT-MC  Sun Jan 10 00:00:00 1982
From: MACRAKatMIT-MC (Stavros M. Macrakis)
Date: 10 January 1982, 00:00
Subject: PURPG in CORBLK call (incorrect analysis)
Message-ID: <mailman.454.1479821111.4695.its@nocrew.org>

But none of my pages were pure.

From DCP at MIT-MC  Sun Jan 10 00:00:00 1982
From: DCP at MIT-MC (DCP at MIT-MC)
Date: 10 Jan 1982 00:00
Subject: CHAOS slots on MC
Message-ID: <mailman.455.1479821111.4695.its@nocrew.org>

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?

From RWK at MIT-MC  Fri Jan  8 00:00:00 1982
From: RWK at MIT-MC (RWK at MIT-MC)
Date: 08 Jan 1982 00:00
Subject: PURPG in CORBLK call
Message-ID: <mailman.456.1479821111.4695.its@nocrew.org>

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!


From MACRAK at MIT-MC  Thu Jan  7 00:00:00 1982
From: MACRAK at MIT-MC (MACRAK at MIT-MC)
Date: 07 Jan 1982 00:00
Subject: No subject
Message-ID: <mailman.457.1479821111.4695.its@nocrew.org>

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

From DLAatMIT-AI  Mon Jan  4 00:00:00 1982
From: DLAatMIT-AI (David L. Andre)
Date: 4 January 1982, 00:00
Subject: No subject
Message-ID: <mailman.458.1479821111.4695.its@nocrew.org>

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.

From MACRAK at MIT-MC  Mon Jan  4 00:00:00 1982
From: MACRAK at MIT-MC (MACRAK at MIT-MC)
Date: 04 Jan 1982 00:00
Subject: No subject
Message-ID: <mailman.459.1479821111.4695.its@nocrew.org>

Is .info.;its corblk needed given its .calls?

From MARTY at MIT-MC  Mon Jan  4 00:00:00 1982
From: MARTY at MIT-MC (MARTY at MIT-MC)
Date: 04 Jan 1982 00:00
Subject: No subject
Message-ID: <mailman.460.1479821111.4695.its@nocrew.org>

I was wondering if we get a DEC-20 and we use
ITS, if we could call it TWITS?



From MOON at MIT-MC  Mon Jan  4 00:00:00 1982
From: MOON at MIT-MC (MOON at MIT-MC)
Date: 04 Jan 1982 00:00
Subject: AOSG not working with .HANG
Message-ID: <mailman.461.1479821111.4695.its@nocrew.org>

This is fixed in the source; the sense of the skip condition
was backwards because the operands of the instruction were
interchanged.

From MACRAK at MIT-MC  Mon Jan  4 00:00:00 1982
From: MACRAK at MIT-MC (MACRAK at MIT-MC)
Date: 04 Jan 1982 00:00
Subject: No subject
Message-ID: <mailman.462.1479821111.4695.its@nocrew.org>

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.