From GSBatMIT-ML  Wed Mar 31 00:00:00 1982
From: GSBatMIT-ML (Glenn S. Burke)
Date: 31 March 1982, 00:00
Subject: fc lossage?
Message-ID: <mailman.391.1479821110.4695.its@nocrew.org>

    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.


From RWKatSCRC-TENEX  Tue Mar 30 00:00:00 1982
From: RWKatSCRC-TENEX (Robert W. Kerns)
Date: Tuesday, 30 March 1982, 00:00
Subject: OPEN
In-Reply-To: The message of 27 Mar 82 18:05-EST from Leigh L. Klotz <KLOTZ at MIT-AI>
Message-ID: <mailman.392.1479821110.4695.its@nocrew.org>


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

From KLOTZatMIT-AI  Sat Mar 27 00:00:00 1982
From: KLOTZatMIT-AI (Leigh L. Klotz)
Date: 27 March 1982, 00:00
Subject: OPEN
Message-ID: <mailman.393.1479821110.4695.its@nocrew.org>

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 P'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 P'd it, it printed
that out.  It hadn't asked for the tty.

Leigh.

From CSTACYatMIT-AI  Sat Mar 27 00:00:00 1982
From: CSTACYatMIT-AI (Christopher C. Stacy)
Date: 27 March 1982, 00:00
Subject: No subject
Message-ID: <mailman.394.1479821110.4695.its@nocrew.org>

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

From PGSatMIT-AI  Sat Mar 27 00:00:00 1982
From: PGSatMIT-AI (Patrick G. Sobalvarro)
Date: 27 March 1982, 00:00
Subject: No subject
Message-ID: <mailman.395.1479821110.4695.its@nocrew.org>

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.

From PGSatMIT-AI  Sat Mar 27 00:00:00 1982
From: PGSatMIT-AI (Patrick G. Sobalvarro)
Date: 27 March 1982, 00:00
Subject: No subject
Message-ID: <mailman.396.1479821110.4695.its@nocrew.org>

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?

From WJL at MIT-ML  Fri Mar 26 00:00:00 1982
From: WJL at MIT-ML (WJL at MIT-ML)
Date: 26 Mar 1982 00:00
Subject: ttyvar documentation out of date
Message-ID: <mailman.397.1479821110.4695.its@nocrew.org>

tctyp also has a number for Z19's thats not in the table -- are there others?

From DCPatMIT-MC  Mon Mar 22 00:00:00 1982
From: DCPatMIT-MC (David C. Plummer)
Date: 22 March 1982, 00:00
Subject: No subject
Message-ID: <mailman.398.1479821110.4695.its@nocrew.org>

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


From REM at MIT-MC  Fri Mar 19 00:00:00 1982
From: REM at MIT-MC (REM at MIT-MC)
Date: 19 Mar 1982 00:00
Subject: No subject
Message-ID: <mailman.400.1479821110.4695.its@nocrew.org>

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.


From DCPatMIT-MC  Thu Mar 18 00:00:00 1982
From: DCPatMIT-MC (David C. Plummer)
Date: 18 March 1982, 00:00
Subject: No subject
Message-ID: <mailman.401.1479821110.4695.its@nocrew.org>

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? 


From EBatMIT-AI  Thu Mar 18 00:00:00 1982
From: EBatMIT-AI (Edward Barton)
Date: 18 March 1982, 00:00
Subject: No subject
Message-ID: <mailman.402.1479821110.4695.its@nocrew.org>

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?

From CBF at MIT-MC  Thu Mar 11 00:00:00 1982
From: CBF at MIT-MC (CBF at MIT-MC)
Date: 11 Mar 1982 00:00
Subject: your crash dump
Message-ID: <mailman.403.1479821110.4695.its@nocrew.org>

The PC is on the system console somplace of course, I think I might even
have written it in the log.


From MOON at MIT-MC  Tue Mar  9 00:00:00 1982
From: MOON at MIT-MC (MOON at MIT-MC)
Date: 09 Mar 1982 00:00
Subject: your crash dump
Message-ID: <mailman.404.1479821110.4695.its@nocrew.org>

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?

From DCP at MIT-MC  Mon Mar  8 00:00:00 1982
From: DCP at MIT-MC (DCP at MIT-MC)
Date: 08 Mar 1982 00:00
Subject: No subject
Message-ID: <mailman.405.1479821110.4695.its@nocrew.org>

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. 


From DCP at MIT-MC  Mon Mar  8 00:00:00 1982
From: DCP at MIT-MC (DCP at MIT-MC)
Date: 08 Mar 1982 00:00
Subject: No subject
Message-ID: <mailman.406.1479821110.4695.its@nocrew.org>

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. 


From HIC0 at MIT-MC  Sun Mar  7 00:00:00 1982
From: HIC0 at MIT-MC (HIC0 at MIT-MC)
Date: 07 Mar 1982 00:00
Subject: No subject
Message-ID: <mailman.407.1479821111.4695.its@nocrew.org>

MC's IO-11 was wedged in some unknown fashion.  I reloaded it from home,
and it got fixed.


From HIC0 at MIT-MC  Sun Mar  7 00:00:00 1982
From: HIC0 at MIT-MC (HIC0 at MIT-MC)
Date: 07 Mar 1982 00:00
Subject: No subject
Message-ID: <mailman.408.1479821111.4695.its@nocrew.org>

Well, MC's IO-11 crashed again,and I reloaded it again.  Maybe it's a more
organic failure than I thought.


From HIC0 at MIT-MC  Sun Mar  7 00:00:00 1982
From: HIC0 at MIT-MC (HIC0 at MIT-MC)
Date: 07 Mar 1982 00:00
Subject: No subject
Message-ID: <mailman.409.1479821111.4695.its@nocrew.org>

MC's IO-11 was wedged in some unknown fashion.  I reloaded it from home,
and it got fixed.


From MOON at MIT-MC  Fri Mar  5 00:00:00 1982
From: MOON at MIT-MC (MOON at MIT-MC)
Date: 05 Mar 1982 00:00
Subject: No subject
Message-ID: <mailman.410.1479821111.4695.its@nocrew.org>

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.

From HGA at MIT-MC  Fri Mar  5 00:00:00 1982
From: HGA at MIT-MC (HGA at MIT-MC)
Date: 05 Mar 1982 00:00
Subject: No subject
Message-ID: <mailman.411.1479821111.4695.its@nocrew.org>

I took a quick look, and somebody changed the RFNAME code between ITS 
version 1261 and 1266.  Did this break things?


From HGA at MIT-MC  Fri Mar  5 00:00:00 1982
From: HGA at MIT-MC (HGA at MIT-MC)
Date: 05 Mar 1982 00:00
Subject: No subject
Message-ID: <mailman.412.1479821111.4695.its@nocrew.org>

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.


From EAKatMIT-MC  Thu Mar  4 00:00:00 1982
From: EAKatMIT-MC (Earl A. Killian)
Date: 4 March 1982, 00:00
Subject: hardware/microcode mod
Message-ID: <mailman.413.1479821111.4695.its@nocrew.org>

I thought the Jump in JFFL was what the programmer does if
there's a free Lispm.


From DCPatMIT-MC  Thu Mar  4 00:00:00 1982
From: DCPatMIT-MC (David C. Plummer)
Date: 4 March 1982, 00:00
Subject: hardware/microcode mod
Message-ID: <mailman.415.1479821111.4695.its@nocrew.org>

: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


From CSTACYatMIT-AI  Thu Mar  4 00:00:00 1982
From: CSTACYatMIT-AI (Christopher C. Stacy)
Date: 4 March 1982, 00:00
Subject: hardware/microcode mod
Message-ID: <mailman.416.1479821111.4695.its@nocrew.org>


  All ITS machines now have hardware for a new machine instruction:
                 JFFL - Jump if Find Free Lispmachine


From JMTURNatMIT-AI  Wed Mar  3 00:00:00 1982
From: JMTURNatMIT-AI (James M. Turner)
Date: 3 March 1982, 00:00
Subject: Disk Writes
Message-ID: <mailman.418.1479821111.4695.its@nocrew.org>

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

From MOON at MIT-MC  Wed Mar  3 00:00:00 1982
From: MOON at MIT-MC (MOON at MIT-MC)
Date: 03 Mar 1982 00:00
Subject: No subject
Message-ID: <mailman.419.1479821111.4695.its@nocrew.org>

    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.

From JMTURNatMIT-AI  Tue Mar  2 00:00:00 1982
From: JMTURNatMIT-AI (James M. Turner)
Date: 2 March 1982, 00:00
Subject: No subject
Message-ID: <mailman.420.1479821111.4695.its@nocrew.org>

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