From SHAWN at MIT-ML  Wed Jun 29 00:00:00 1983
From: SHAWN at MIT-ML (SHAWN at MIT-ML)
Date: 29 Jun 1983 00:00
Subject: wish list
Message-ID: <mailman.1361.1479821134.4695.its@nocrew.org>

I *WISH* ITS had a UNIX(tm) type GREP command.

		-Shawn

From ALAN at MIT-MC  Wed Jun 29 23:19:00 1983
From: ALAN at MIT-MC (Alan Bawden)
Date: June 29 1983 17:19 EDT
Subject: CORBLK and .ACCESS interaction.
Message-ID: <mailman.1362.1479821134.4695.its@nocrew.org>

Here is a minimal case of some lossy interaction between CORBLKing and
.ACCESSing the same file:

	.call [setz ? sixbit /open/ ? [.uii,,dsk] ? [sixbit /dsk/]
		[sixbit /names/] ? [sixbit />/] ? setz [sixbit /.mail./]]
	 .lose %lsfil
	;;These next two are not necessary for the misbehavior, but help to
	;;make it more obvious later:
	.access dsk,[100]
	.iot dsk,a
	.access dsk,[2000]
	.iot dsk,b
	.access dsk,[0]
	.call [setz ? sixbit /corblk/ ? movei %cbndr ? movei %jself
		movei 7 ? setzi dsk]
	 .lose %lssys
	.access dsk,[100]
	.iot dsk,b

At the end of this sequence, A and B should obviously contain the same
thing, but they don't.  Typically B will get the contents of location 2100,
rather than 100.  It is not important what file you use, I just chose
.MAIL.;NAMES > out of randomness.

From DCP at MIT-MC  Tue Jun 21 15:01:00 1983
From: DCP at MIT-MC (David C. Plummer)
Date: June 21 1983 09:01 EDT
Subject: cli interrupts and emacs
Message-ID: <mailman.1363.1479821134.4695.its@nocrew.org>

    Date: Tuesday, 21 June 1983, 04:23-EDT
    From: Patrick Sobalvarro <PGS at MIT-OZ>

    I guess I'm a loser.  I do use MODLIN.
So am I, and so do I.  I'd like to be a winner who uses MODLIN, though.

From PGS at MIT-OZ  Tue Jun 21 00:00:00 1983
From: PGS at MIT-OZ (Patrick Sobalvarro)
Date: Tuesday, 21 June 1983, 00:00
Subject: No subject
In-Reply-To: The message of 2 Jun 83 21:27-EDT from Herschell A. Andrews <HAA>
Message-ID: <mailman.1364.1479821134.4695.its@nocrew.org>

    Date: 2 June 1983 21:27 EDT
    From: Herschell A. Andrews <HAA>
    To:   BUG-ITSTTY

    Does anyone know why my vt52 emuator suddenly started losing? It works
    fine on cmuc but loses bad on ITS. My software tty doesn't work either.
    Has something changed?

I tried running a vt52 connected directly to MC and had no trouble; I'd say the
trouble is probably in your emulator.  Or have you figured the problem out
already?

From PGS at MIT-OZ  Tue Jun 21 00:00:00 1983
From: PGS at MIT-OZ (Patrick Sobalvarro)
Date: Tuesday, 21 June 1983, 00:00
Subject: cli interrupts and emacs
In-Reply-To: The message of 21 Jun 83 04:05-EDT from Kent M. Pitman <KMP at MIT-MC>
Message-ID: <mailman.1365.1479821134.4695.its@nocrew.org>

    Date: 21 June 1983 04:05 EDT
    From: Kent M. Pitman <KMP @ MIT-MC>

    Do you use the MODLIN library? (For reasons I have never traced down, having
    this loaded seems to defeat Emacs' ability to recognize the tty having been
    potentially munged by superior typeout.) If you don't use the MODLIN library,
    perhaps you are a new data point.

I guess I'm a loser (not a new data point, ha ha).
I do use MODLIN.

From KMP at MIT-MC  Tue Jun 21 10:05:00 1983
From: KMP at MIT-MC (Kent M. Pitman)
Date: June 21 1983 04:05 EDT
Subject: cli interrupts and emacs
Message-ID: <mailman.1366.1479821134.4695.its@nocrew.org>

Do you use the MODLIN library? (For reasons I have never traced down, having
this loaded seems to defeat Emacs' ability to recognize the tty having been
potentially munged by superior typeout.) If you don't use the MODLIN library,
perhaps you are a new data point.

From ALAN at MIT-MC  Tue Jun 21 09:58:00 1983
From: ALAN at MIT-MC (Alan Bawden)
Date: June 21 1983 03:58 EDT
Subject: cli interrupts and emacs
In-Reply-To: Msg of 21 Jun 1983 01:27 EDT from Patrick G. Sobalvarro <PGS>
Message-ID: <mailman.1367.1479821134.4695.its@nocrew.org>

    Date: 21 June 1983 01:27 EDT
    From: Patrick G. Sobalvarro <PGS>
    Correct me if I'm wrong, but once upon a time I seem to remember having
    Emacs uderstand that I'd gotten my screen bashed and redisplay it after a
    CLI interrupt as soon as I typed a character.  This was a nice feature,
    something Twenex emacs couldn't do because of the way tty messages work
    there.  Well, it doesn't work anymore.  After a CLI interrupt, when I
    type characters, my Emacs doesn't redisplay at all.  It doesn't do anything
    until I type something like ^L, which is an ECHOIN break character.  Is
    ECHOIN broken?

CStacy has complained of something like this in the past.  DCP, I believe,
claimed to have seen this too.  I have never seen it.  Is it reproducable?

(I don't see how ECHOIN can itself be at fault, this works by having Emacs
enable %PIATY interrupts, but perhaps emacs does does something bogus when
it finds that this interrupt occured during an ECHOIN.  I am pretty sure I
have tested that case trying to reproduce this lossage, but I have never
seen it fail...  I just tried to find the source of TECO, but I couldn't, I
wonder where it is?)

From PGS at MIT-MC  Tue Jun 21 07:27:00 1983
From: PGS at MIT-MC (Patrick G. Sobalvarro)
Date: June 21 1983 01:27 EDT
Subject: cli interrupts and emacs
Message-ID: <mailman.1368.1479821134.4695.its@nocrew.org>

Correct me if I'm wrong, but once upon a time I seem to remember having
Emacs uderstand that I'd gotten my screen bashed and redisplay it after a
CLI interrupt as soon as I typed a character.  This was a nice feature,
something Twenex emacs couldn't do because of the way tty messages work
there.  Well, it doesn't work anymore.  After a CLI interrupt, when I
type characters, my Emacs doesn't redisplay at all.  It doesn't do anything
until I type something like ^L, which is an ECHOIN break character.  Is
ECHOIN broken?

From CENT at MIT-ML  Sat Jun 11 10:19:00 1983
From: CENT at MIT-ML (Pandora B. Berman)
Date: June 11 1983 04:19 EDT
Subject: DUMP
Message-ID: <mailman.1369.1479821134.4695.its@nocrew.org>

i have in hand the relevant tapes from ai's last full dump.  i expect to
load the .tape files onto ml one dir at a time and then move them to dm.
then i'll deal with the updates from the various incr.  dump tapes after
last august. chris, i will let you know when the dirs from the full
dump are in place; that should be good enough for testing..

From GSB at MIT-ML  Fri Jun 10 23:40:00 1983
From: GSB at MIT-ML (Glenn S. Burke)
Date: June 10 1983 17:40 EDT
Subject: DUMP
Message-ID: <mailman.1370.1479821134.4695.its@nocrew.org>

The issue was disk space.  I had been aware of the tape drive incompatibility
when i suggested DM.  People will just have to run the FIND and do the
loading on different machines.


From CSTACY at MIT-MC  Fri Jun 10 08:59:00 1983
From: CSTACY at MIT-MC (Christopher C. Stacy)
Date: June 10 1983 02:59 EDT
Subject: DUMP
In-Reply-To: Msg of 10 Jun 1983 02:26-EDT from David A. Moon <Moon at SCRC-TENEX>
Message-ID: <mailman.1371.1479821134.4695.its@nocrew.org>


    Date: Friday, 10 June 1983, 02:26-EDT
    From: David A. Moon <Moon at SCRC-TENEX>
    To:   Christopher C. Stacy <CSTACY>
    cc:   PGS, CENT, BUG-ITS
    Re:   DUMP

        Date: 7 June 1983 14:01 EDT
        From: Christopher C. Stacy <CSTACY @ MIT-MC>
        I have put a new command into DUMP.
        DFIND does a find for a deceased ITS.
        If someone reloads the .TAPEn; directories from AI
        onto DM, I will test it and you should be in business.
        The directories should be named %TAPEn; instead of .TAPEn;.

    But AI's tape drive was 7-track and DM's is 9-track.  So DM can't read AI's tapes.

Which machine they go on is just a variable in DUMP.
The people who wanted this had picked DM, probably due to the
number of free UFD slots...

From Moon at SCRC-TENEX  Fri Jun 10 00:00:00 1983
From: Moon at SCRC-TENEX (David A. Moon)
Date: Friday, 10 June 1983, 00:00
Subject: DUMP
In-Reply-To: The message of 7 Jun 83 14:01-EDT from Christopher C. Stacy <CSTACY at MIT-MC>
Message-ID: <mailman.1372.1479821134.4695.its@nocrew.org>

    Date: 7 June 1983 14:01 EDT
    From: Christopher C. Stacy <CSTACY @ MIT-MC>
    I have put a new command into DUMP.
    DFIND does a find for a deceased ITS.
    If someone reloads the .TAPEn; directories from AI
    onto DM, I will test it and you should be in business.
    The directories should be named %TAPEn; instead of .TAPEn;.

But AI's tape drive was 7-track and DM's is 9-track.  So DM can't read AI's tapes.

From KMP at MIT-MC  Thu Jun  9 21:57:00 1983
From: KMP at MIT-MC (Kent M. Pitman)
Date: June 9 1983 15:57 EDT
Subject: Bug in ">" handling by Archive Device
Message-ID: <mailman.1373.1479821134.4695.its@nocrew.org>

If two files exist on an archive, FOO A and FOO B, then if you open FOO >
for input, you'll get FOO A open, not FOO B.

On DSK, FOO B will be opened.
--kmp

From CSTACY at MIT-MC  Tue Jun  7 20:01:00 1983
From: CSTACY at MIT-MC (Christopher C. Stacy)
Date: June 7 1983 14:01 EDT
Subject: DUMP
Message-ID: <mailman.1374.1479821134.4695.its@nocrew.org>


I have put a new command into DUMP.
DFIND does a find for a deceased ITS.
If someone reloads the .TAPEn; directories from AI
onto DM, I will test it and you should be in business.
The directories should be named %TAPEn; instead of .TAPEn;.


From Ian at MIT-OZ  Tue Jun  7 00:32:00 1983
From: Ian at MIT-OZ (Ian Macky)
Date: Jun 6 1983  18:32 EDT (Mon)
Subject: No subject
In-Reply-To: Msg of 30 May 1983 16:30 EDT from David C. Plummer <DCP at MIT-MC>
Message-ID: <mailman.1375.1479821134.4695.its@nocrew.org>

    Date: 30 May 1983 16:30 EDT
    From: David C. Plummer <DCP at MIT-MC>
    To:   BUG-ITS at MIT-MC
    Received: from MIT-MC by MIT-OZ; Mon 30 May 83 16:33:25-EDT

    Anybody know where the source for UNTALK is hiding?  The creation
    date on SYS2;TS UNTALK is October 1977 (before the days when
    Midas insterted assembly information).  It isn't on MC:SYSEN*;

Ellen knew where it was, so I loaded a copy in my directory for the
time being - it's GREN;UNTALK 87 (and there's UNTALK MAIL, too).  It
calls for an .INSRT file of UNCOLA's doing (UNCOLA;.MIDAS >) which was
not on the same full-dump tape, so I dunno where it is.

From CSTACY at MIT-MC  Mon Jun  6 21:18:00 1983
From: CSTACY at MIT-MC (Christopher C. Stacy)
Date: June 6 1983 15:18 EDT
Subject: No subject
Message-ID: <mailman.1376.1479821134.4695.its@nocrew.org>

I'll hack up DUMP to look on DM, tonite when I come in.
I cant imagine it taking more than 20 minutes...

From PGS at MIT-MC  Mon Jun  6 21:13:00 1983
From: PGS at MIT-MC (Patrick G. Sobalvarro)
Date: June 6 1983 15:13 EDT
Subject: No subject
Message-ID: <mailman.1377.1479821134.4695.its@nocrew.org>

I suggest that we install the AI:.TAPEn; directories on some ITS machine as
AITAPn; and hack up a version of DUMP so that it'll be possible to find tapes
when we need them.  The problem is that there are no hardcopy dump logs
except for the ones Penny did of the last couple of dumps.  The hacking of
DUMP should be trivial if we want to use only the FIND command; it can
probably be done with translations.  Glenn says that we can probably squeeze
the directories on DM, and we might as well, because no one else is using the
machine these days.

I nominate Chris to do this.  All in favor say aye.

P.S.  Ty and I once did an incremental dump of AI to ML thru the MLDEV using
only translations.  It took a long time, but, hey, it worked.

From CSTACY at MIT-MC  Fri Jun  3 15:07:00 1983
From: CSTACY at MIT-MC (Christopher C. Stacy)
Date: June 3 1983 09:07 EDT
Subject: No subject
In-Reply-To: Msg of 06/02/83 23:17:22 from GSB at MIT-ML
Message-ID: <mailman.1378.1479821134.4695.its@nocrew.org>


    Date: 06/02/83 23:17:22
    From: GSB at MIT-ML

    Inqupd is writing out its new database to LSR1 >.  When it runs out of
    disk space, it closes the incompletely written file.

I think I have fixed my brain damage INQUPD.
Now it writes out the provisional version to NLSR1 >, and disk-full
interrupts prevent it from installing it (the interrupt handler had a
bogus instruction in it.) It will still leave the incomplete version
around as NLSR1. Later, I will put something in to get this deleted.

    In this case, DDT loses its ass when starting up when not-logged-in.
    It bugs out before it gets the system symbol table mapped in,
    making debugging incredibly difficult.

Maybe DDT should do all its initialization before logging the user in
(and needing to find his hsname.)  I thought it already did this,
but will look at.

    When CORBLK is doing block-mode map-from-disk, it apparently just
    tics the aobjn pointer away leaving MPV pages after end-of-file;
    no indication that you ran off the end.

Is this an ITS bug?

    I made two invalid assumptions when looking at this broken system
    this afternoon, which caused me to believe that it was horribly trashed.
    (Maybe it is.  It crashed randomly twice before, which lent great credence
    to its being trashed.)  One was that DDT would not fail so grossly with
    the inquir database smashed.  The other was that corblk would not 
    intentionally act the way it did.

ML *is* having some kind of trouble - COMSAT is repeat processing
messages from May somehow. I guess the QML is broken somehow?
Was it restored from tape, or is something even worse happenning?
See BUG-MAIL.

    I have renamed INQUPD BIN to INQUPD FUCKED.

I put the current database and program on ML.
Let me know if there are more bugs with it (it ran fine for three
weeks on MC, but of course some of the error code did not get
exxcercised there.)

From PGS at MIT-OZ  Thu Jun  2 00:00:00 1983
From: PGS at MIT-OZ (Patrick Sobalvarro)
Date: Thursday, 2 June 1983, 00:00
Subject: No subject
Message-ID: <mailman.1380.1479821134.4695.its@nocrew.org>

In MIT-Specific 19.3, System 94.23, ZMail 50.9, microcode 238, ZM GC at 0,
on Lisp Machine Thirty-one:

If I read the file MC: AR1: PGS; PKGDCL > into a Zwei buffer, I get 4 nulls at
the end.  I don't see these in Emacs.  If I delete the nulls and write the file
and read it again, they're back.  With nulls, the file has 115 characters in
it.

From DCP at MIT-MC  Thu Jun  2 01:53:00 1983
From: DCP at MIT-MC (David C. Plummer)
Date: June 1 1983 19:53 EDT
Subject: No subject
Message-ID: <mailman.1381.1479821134.4695.its@nocrew.org>

    Date: 1 June 1983 01:02 EDT
    From: Patrick G. Sobalvarro <PGS @ MIT-MC>
    In-reply-to: Msg of 1 Jun 1983 00:30-EDT from Christopher C. Stacy <CStacy>

    Wrongo, Roscoe.  First, since there are never bugs in my code, you should
    have known you were wrong.  Second, when you connect to MC via a terminal
    concentrator, I'll bet you use Supdup, not Telnet.  If you use Supdup, then
    MC doesn't know you're on an Ann Arbor.  In fact, when I use Telnet and do
    :tctyp aaa, I don't miss any characters in INQUIR.  I provided 5ms of padding
    for %tdeof in the AAA code in TS3TTY, and that turns out to be more than
    enough.

Your response was much better than mine could have been.  I was a
little mystified to learn that Stacy didn't know you WROTE the
ITS code for AAAs.

    If it works on the Lisp Machine, then MINITS is probably responsible, because
    it provides no padding at all.

That is true.  Perhaps if I find some time this summer and get
marginally bored I will correct this situation.

Anyway, the cause of the manifestation (call it a bug if you
wish) is CStacy's overeagerness to keep the screen as blank as
possible.  I think what is happening is that more than one %TDCLR
is being sent before the text (if entered with :INQUIR DCP).
This causes any AAA without padding to drop characters.

[Also, the following are defined
	.CS=.7TYP 4,[ASCIZ /C/]
	.CSL=.7TYPL 4,[ASCIZ /C/]
but are used in only 4 of the 10 places where they could be, the
other six are
	.7TYP 4,[ASCIZ /C/]
There are many other occurences of C scattered throughout.]

From CSTACY at MIT-MC  Wed Jun  1 08:04:00 1983
From: CSTACY at MIT-MC (Christopher C. Stacy)
Date: June 1 1983 02:04 EDT
Subject: No subject
In-Reply-To: Msg of 1 Jun 1983 01:02 EDT from Patrick G. Sobalvarro <PGS>
Message-ID: <mailman.1382.1479821134.4695.its@nocrew.org>


    Date: 1 June 1983 01:02 EDT
    From: Patrick G. Sobalvarro <PGS>
    To:   CSTACY
    cc:   BUG-INQUIR, BUG-ITS, BUG-MINITS

    It says "What next? ->", and then when I type a ^L, it
    says "Command-->"<cr>.

I just changed these to be a little better.

    Wrongo, Roscoe.  First, since there are never bugs in my 
    code, you should have known you were wrong.  Second, when you connect
    to MC via a terminal concentrator, I'll bet you use Supdup...
    If it works on the Lisp Machine, then MINITS is probably
    responsible, because it provides no padding at all.

Oh yeah.  I guess I forgot to turn my brain on tonite!

From PGS at MIT-MC  Wed Jun  1 07:02:00 1983
From: PGS at MIT-MC (Patrick G. Sobalvarro)
Date: June 1 1983 01:02 EDT
Subject: No subject
In-Reply-To: Msg of 1 Jun 1983 00:30-EDT from Christopher C. Stacy <CStacy>
Message-ID: <mailman.1383.1479821134.4695.its@nocrew.org>

    Date: Wednesday, 1 June 1983, 00:30-EDT
    From: Christopher C. Stacy <CStacy>
    To:   Patrick G. Sobalvarro <PGS>
    cc:   BUG-ITS, BUG-INQUIR

        Date: 31 May 1983 16:21 EDT
        From: Patrick G. Sobalvarro <PGS @ MIT-MC>
        I enter INQUIR via INQUIR PGS.  The automagic listme that happens is
        broken; half of the characters in it are dropped. There is also a
        CR at the end of the command line that says Command--> 

    I have had this sometimes happen to me on an AAA, buit it never ever
    happens on a Lisp Machine SUPDUP connection.  I tried it just now.
    Just to make sure we are talking about the same program, the prompt
    is actually "What next? ->", right?

It says "What next? ->", and then when I type a ^L, it says "Command-->"<cr>.


        (incidentally, a more informative prompt [like, say, INQUIR>] would be 
        better). This character dropping reminds me of Unix.  The random cursor 
        motion reminds me of another operating system for PDP-10s.  I had 
        entered INQUIR only to change my net address to MC.

    This looks to me like it must be an ITS problem, since it only happens
    on certain terminal types, and since that part of INQUIR hasn't been
    modified.  I suspect that there is not enough padding after a clear
    screen operation for Ann Arbor terminals.  If no TS3TTY/AAA wizard
    speaks up within a few days, I will start experimenting with the ITS tty
    code to see if that fixes the problem.

Wrongo, Roscoe.  First, since there are never bugs in my code, you should
have known you were wrong.  Second, when you connect to MC via a terminal
concentrator, I'll bet you use Supdup, not Telnet.  If you use Supdup, then
MC doesn't know you're on an Ann Arbor.  In fact, when I use Telnet and do
:tctyp aaa, I don't miss any characters in INQUIR.  I provided 5ms of padding
for %tdeof in the AAA code in TS3TTY, and that turns out to be more than
enough.

If it works on the Lisp Machine, then MINITS is probably responsible, because
it provides no padding at all.

From CStacyatMIT-MC  Wed Jun  1 00:00:00 1983
From: CStacyatMIT-MC (Christopher C. Stacy)
Date: Wednesday, 1 June 1983, 00:00
Subject: No subject
In-Reply-To: The message of 31 May 83 16:21-EDT from Patrick G. Sobalvarro <PGS at MIT-MC>
Message-ID: <mailman.1384.1479821135.4695.its@nocrew.org>

    Date: 31 May 1983 16:21 EDT
    From: Patrick G. Sobalvarro <PGS @ MIT-MC>
    I enter INQUIR via INQUIR PGS.  The automagic listme that happens is
    broken; half of the characters in it are dropped. There is also a
    CR at the end of the command line that says Command--> 

I have had this sometimes happen to me on an AAA, buit it never ever
happens on a Lisp Machine SUPDUP connection.  I tried it just now.
Just to make sure we are talking about the same program, the prompt
is actually "What next? ->", right?

    (incidentally, a more informative prompt [like, say, INQUIR>] would be 
    better). This character dropping reminds me of Unix.  The random cursor 
    motion reminds me of another operating system for PDP-10s.  I had 
    entered INQUIR only to change my net address to MC.

This looks to me like it must be an ITS problem, since it only happens
on certain terminal types, and since that part of INQUIR hasn't been
modified.  I suspect that there is not enough padding after a clear
screen operation for Ann Arbor terminals.  If no TS3TTY/AAA wizard
speaks up within a few days, I will start experimenting with the ITS tty
code to see if that fixes the problem.