From CSTACY at MIT-MC  Thu Mar 31 09:27:00 1983
From: CSTACY at MIT-MC (Christopher C. Stacy)
Date: March 31 1983 02:27 EST
Subject: No subject
Message-ID: <mailman.58.1479821104.4695.its@nocrew.org>

AI, MC, and DM are running the latest version of ITS 1332.
I reshuffled the version names and cards: NITS is what you
want, and ITS is older.  XITS is mostly GCd and not what you want.
I'll do this for ML tonite or tomorrow.  AI and DM have some more
STYs (number doubled on DM).  Also, latest COMSAT is installed
all around.

From CSTACY at MIT-MC  Thu Mar 31 07:01:00 1983
From: CSTACY at MIT-MC (Christopher C. Stacy)
Date: March 31 1983 00:01 EST
Subject: No subject
Message-ID: <mailman.59.1479821104.4695.its@nocrew.org>

Increased number of STYs on AI and DM.

From MOON at MIT-MC  Tue Mar 29 07:10:00 1983
From: MOON at MIT-MC (David A. Moon)
Date: March 29 1983 00:10 EST
Subject: MLSLV bug
Message-ID: <mailman.60.1479821104.4695.its@nocrew.org>

    Date: 28 March 1983 21:14 EST
    From: Robert W. Kerns <RWK @ MIT-MC>
    To: BUG-ITS @ MIT-MC

    There are some MLSLV's on MC which are spending much of their time in WHYINT,
    and eating lots of CPU.  Presumably they should be killing themselves, as
    part of network error handling or something.

I fixed this, killed the jobs, and installed the new version everywhere.
There were actually several bugs.

From MOON at MIT-MC  Tue Mar 29 07:09:00 1983
From: MOON at MIT-MC (David A. Moon)
Date: March 29 1983 00:09 EST
Subject: No subject
Message-ID: <mailman.61.1479821104.4695.its@nocrew.org>

I gunned down about 5 arc devices that were hung in BOJSO with
their creator (an FTP server) no longer in existence.

From RWK at MIT-MC  Tue Mar 29 04:14:00 1983
From: RWK at MIT-MC (Robert W. Kerns)
Date: March 28 1983 21:14 EST
Subject: No subject
Message-ID: <mailman.62.1479821104.4695.its@nocrew.org>

There are some MLSLV's on MC which are spending much of their time in WHYINT,
and eating lots of CPU.  Presumably they should be killing themselves, as
part of network error handling or something.

From RWK at MIT-MC  Tue Mar 29 04:05:00 1983
From: RWK at MIT-MC (Robert W. Kerns)
Date: March 28 1983 21:05 EST
Subject: No subject
Message-ID: <mailman.63.1479821104.4695.its@nocrew.org>

I just found a detached 340C23 CHAOS job which appears to have gotten
an ILOPR because it couldn't set its JNAME to MAIL, since
there already seemed to be a job with that name.  It doesn't
look like ot checks for this possibility at all, but given
that both the chaos address and job number parts of the UNAME
are truncated, it should certainly have some strategy for dealing
with this, like AOSing the UNAME or JNAME or something.

From RWKatSCRC-TENEX  Wed Mar 23 00:00:00 1983
From: RWKatSCRC-TENEX (Robert W. Kerns)
Date: Wednesday, 23 March 1983, 00:00
Subject: thought for the day
In-Reply-To: The message of 22 Mar 83 01:15-EST from George J. Carrette <GJC at MIT-MC>
Message-ID: <mailman.64.1479821104.4695.its@nocrew.org>

    Date: 22 March 1983 01:15 EST
    From: George J. Carrette <GJC @ MIT-MC>
    Taking a word frequency analysis of SYSENG;HOSTS >, we get the top ten
    "words" as:

    (522. HOST) (276. SERVER) (231. USER) (226. LISPM) (222. CHAOS) (205. PDP) 
    (171. MIT) (157. UNIX) (102. VAX) (100. TAC) 

Out of curiosity, I measured (88. SCRC^_SCH^_SPA).  I guess we won't make the
top ten until sometime this summer.

This argues for domains, of course.

From ZOMBIE at MIT-AI  Tue Mar 22 00:00:00 1983
From: ZOMBIE at MIT-AI (ZOMBIE at MIT-AI)
Date: 22 Mar 1983 00:00
Subject: No subject
Message-ID: <mailman.65.1479821104.4695.its@nocrew.org>

AI will not accept MC or ML as devices although it does make supdup
connections. Just thought someone might like to know...
Sean


From GJC at MIT-MC  Tue Mar 22 07:15:00 1983
From: GJC at MIT-MC (George J. Carrette)
Date: March 22 1983 01:15 EST
Subject: thought for the day
Message-ID: <mailman.66.1479821104.4695.its@nocrew.org>

Taking a word frequency analysis of SYSENG;HOSTS >, we get the top ten
"words" as:

(522. HOST) (276. SERVER) (231. USER) (226. LISPM) (222. CHAOS) (205. PDP) 
(171. MIT) (157. UNIX) (102. VAX) (100. TAC) 


From CSTACY at MIT-MC  Mon Mar 21 12:24:00 1983
From: CSTACY at MIT-MC (Christopher C. Stacy)
Date: March 21 1983 06:24 EST
Subject: No subject
Message-ID: <mailman.67.1479821104.4695.its@nocrew.org>

New PEEK and DDT installed on all four machines.

From CSTACY at MIT-AI  Mon Mar 21 00:00:00 1983
From: CSTACY at MIT-AI (CSTACY at MIT-AI)
Date: 21 Mar 1983 00:00
Subject: AI uptime
Message-ID: <mailman.68.1479821104.4695.its@nocrew.org>

I am gonna have to bring it down to install the latest ITS version,
so before I do...

Today is Monday, the 21st of March, 1983.
AI ITS 1325 has run for 16 days, 3 minutes, 11 seconds.
System last revivde 15 days, 20 hours, 54 minutes, 59 seconds ago.


From moon at MIT-MC  Sun Mar 20 04:56:00 1983
From: moon at MIT-MC (David A. Moon)
Date: March 19 1983 22:56 EST
Subject: job device wedged on MC
Message-ID: <mailman.69.1479821104.4695.its@nocrew.org>

The created job was in JOBREU, hung at NJBREU+4 waiting for JBCG
to clear.  Previously it had pclsred from NJBRU1+7.  The creator
was hung in OPEN, at JBFLS, presumably trying to reuse it.  Pclsring
the creator caused it to start a new device job and the old one
to go away.  Looks to me like just an inherent race in the code,
although there were multiple jobs trying to use the same AI: device.
Maybe I'll look at the code more some other time.

From CSTACY at MIT-MC  Sun Mar 20 04:45:00 1983
From: CSTACY at MIT-MC (Christopher C. Stacy)
Date: March 19 1983 22:45 EST
Subject: ARC device directories
Message-ID: <mailman.70.1479821104.4695.its@nocrew.org>

What programs (other than ARCDEV) depend on understanding
the binary representation of the internal directory?

From KLH at MIT-MC  Fri Mar 18 18:33:00 1983
From: KLH at MIT-MC (Ken Harrenstien)
Date: March 18 1983 12:33 EST
Subject: INQUIR vs DDT
Message-ID: <mailman.71.1479821104.4695.its@nocrew.org>

    Fixed in DDT.1430, installed on MC.

    I think what was going on was that it was failing to map in the
    database (probably out of file channels to open it with, since a
    broken TARAKA DVRSPL had them all).

No, actually it was failing because the LSR1 file was smashed for
real.  I don't know why, but it was definitely munged.  I fixed by
copying the old version back over.

    DDT's LSRMAP now has an error return.  All of it's callers seemed
    to be interested in finding out someone's HSNAME; I made them do
    something reasonable to fake it.

That's the right thing from user prog viewpoint, since LSRMAP could fail
no matter how cleverly it tries to find a good version.  It should try
harder, though.

From CSTACY at MIT-MC  Fri Mar 18 11:11:00 1983
From: CSTACY at MIT-MC (Christopher C. Stacy)
Date: March 18 1983 05:11 EST
Subject: MLDEV
Message-ID: <mailman.72.1479821104.4695.its@nocrew.org>

I reassembled the latest MLDEV on MC.
I think it wasnt using HOSTS3 or something, since it wasnt
doing anything useful.  I think it works now; so I installed it.

From CStacyatMIT-MC  Fri Mar 18 00:00:00 1983
From: CStacyatMIT-MC (Christopher C. Stacy)
Date: Friday, 18 March 1983, 00:00
Subject: INQUIR vs DDT
In-Reply-To: The message of 18 Mar 83 00:48-EST from Robert W. Kerns <RWK at SCRC-TENEX>
Message-ID: <mailman.73.1479821104.4695.its@nocrew.org>

    Date: Friday, 18 March 1983, 00:48-EST
    From: Robert W. Kerns <RWK at SCRC-TENEX>
	Date: 16 March 1983 18:36 EST
	From: Ken Harrenstien <KLH @ MIT-MC>
	I think it is really bad for DDT to refuse to work just because it can't
	look up a name in INQUIR.  This is just too much dependence; if we cant
	get a DDT to work then we are shafted, but good.
    DDT isn't supposed to not work in any serious way if the INQUIR
    database is trashed.  It shouldn't lose any more seriously than
    failing to find your home directory.  If it won't let you log in,
    that's a bug.  The only other probable loser I can think of is :PRMAIL.
    I don't think that not working is serious.

Fixed in DDT.1430, installed on MC.

I think what was going on was that it was failing to map in the
database (probably out of file channels to open it with, since a
broken TARAKA DVRSPL had them all).

DDT's LSRMAP now has an error return.  All of it's callers seemed
to be interested in finding out someone's HSNAME; I made them do
something reasonable to fake it.

From RWKatSCRC-TENEX  Fri Mar 18 00:00:00 1983
From: RWKatSCRC-TENEX (Robert W. Kerns)
Date: Friday, 18 March 1983, 00:00
Subject: INQUIR vs DDT
In-Reply-To: The message of 16 Mar 83 18:36-EST from Ken Harrenstien <KLH at MIT-MC>
Message-ID: <mailman.74.1479821104.4695.its@nocrew.org>

    Date: 16 March 1983 18:36 EST
    From: Ken Harrenstien <KLH @ MIT-MC>
    I think it is really bad for DDT to refuse to work just because it can't
    look up a name in INQUIR.  This is just too much dependence; if we cant
    get a DDT to work then we are shafted, but good.
DDT isn't supposed to not work in any serious way if the INQUIR
database is trashed.  It shouldn't lose any more seriously than
failing to find your home directory.  If it won't let you log in,
that's a bug.  The only other probable loser I can think of is :PRMAIL.
I don't think that not working is serious.

From KLH at MIT-MC  Thu Mar 17 00:36:00 1983
From: KLH at MIT-MC (Ken Harrenstien)
Date: March 16 1983 18:36 EST
Subject: No subject
Message-ID: <mailman.75.1479821104.4695.its@nocrew.org>

Considering how many things break totally when the INQUIR data base is
corrupted, I would suggest that LSRTNS try to map in LSR1 OLD (ie previous
version or versions) if it runs into problems with the standard file.
Furthermore, INQUPD should try to make sure the existing file is OK before
it renames it to LSR1 OLD.

I think it is really bad for DDT to refuse to work just because it can't
look up a name in INQUIR.  This is just too much dependence; if we cant
get a DDT to work then we are shafted, but good.

From CStacyatMIT-MC  Wed Mar 16 00:00:00 1983
From: CStacyatMIT-MC (Christopher C. Stacy)
Date: Wednesday, 16 March 1983, 00:00
Subject: DIR device
In-Reply-To: The message of 16 Mar 83 13:31-EST from John G. Aspinall <JGA at MIT-MC>
Message-ID: <mailman.76.1479821104.4695.its@nocrew.org>

    Date: 16 March 1983 13:31 EST
    From: John G. Aspinall <JGA @ MIT-MC>
    The DIR device seems to be permanently getting device-full errors.

    This happens from emacs dired and from various flavours of top level
    invocation - ie DIR:CDATE UP , DIR:RDATE DOWN, etc.

MC is probably permanently overloaded, and has no job slots for
the device handlers for DIR: ....it works fine for me when there
are available job slots.

From JGA at MIT-MC  Wed Mar 16 19:31:00 1983
From: JGA at MIT-MC (John G. Aspinall)
Date: March 16 1983 13:31 EST
Subject: DIR device
Message-ID: <mailman.77.1479821104.4695.its@nocrew.org>

The DIR device seems to be permanently getting device-full errors.

This happens from emacs dired and from various flavours of top level
invocation - ie DIR:CDATE UP , DIR:RDATE DOWN, etc.

From ALAN at MIT-MC  Sun Mar 13 12:43:00 1983
From: ALAN at MIT-MC (Alan Bawden)
Date: March 13 1983 06:43 EST
Subject: TTYFLS problem
Message-ID: <mailman.78.1479821104.4695.its@nocrew.org>

TTYFLS, with it's single control bit set to 0, simply sets %TXIGN in the
character in question.  Unfortunately this causes .LISTEN to lie about the
availability of input characters.  

Since EMACS won't redisplay if it thinks there are characters to be read,
this is one way to cause an EMACS to fail to redisplay when proceeded.  I
don't think this exact screw can explain the mysterious "CStacy's lossage".
Few programs probably use TTYFLS and even fewer with that control bit set
to 0.  But perhaps something else can cause .LISTEN to lie?  (Does the
MODLIN package do anything bizare?)

From KLH at MIT-MC  Sun Mar 13 12:36:00 1983
From: KLH at MIT-MC (Ken Harrenstien)
Date: March 13 1983 06:36 EST
Subject: New TELNET installed
Message-ID: <mailman.79.1479821104.4695.its@nocrew.org>

I installed a new TELNET which fixes some throughput problems.
In particular, one should not become hung waiting for typein to
reach the remote host, and thus output will continue to be
displayed and it should always be possible to break into command
mode.

From MOON at MIT-MC  Wed Mar  9 23:17:00 1983
From: MOON at MIT-MC (David A. Moon)
Date: March 9 1983 17:17 EST
Subject: .CALL 0, [ not SETZ ]
Message-ID: <mailman.80.1479821104.4695.its@nocrew.org>

    Date: 8 March 1983 15:39 EST
    From: Ken Harrenstien <KLH @ MIT-MC>

    Is it the right thing that .CALLs which point to a non-SETZ word
    get an ILOPR instead of failing to skip?

This is left over from about ten years ago, I believe, when that
was going to be used for some kind of dynamic linking of subroutines.
However, it is probably still right for it to ILOPR.

From KLH at MIT-MC  Wed Mar  9 09:54:00 1983
From: KLH at MIT-MC (Ken Harrenstien)
Date: March 9 1983 03:54 EST
Subject: New ITS
Message-ID: <mailman.81.1479821104.4695.its@nocrew.org>

New XITS (1329) installed on MC.  Old XITS renamed to ITS.  There is
no NITS.  This version has a subtle change in SALV; SALV now starts at
212000 instead of 200000, in order to make room for extra ITS code!
.;SALV 306BIN is the version that has this relocation hacked; SALV BIN
still points to the old version.  All future ITSes generated for MC must
use SALV 306 or higher.

This version of ITS tries to implement TCP URGENT handling for
direct-connected STYs.  I haven't tested it yet.  All the known
patches have also been incorporated; if I missed any we'll probably
know about it pretty soon.  The most important change is basically
the one to SALV, since the 200000 address has always been hard-wired
that way and there may conceivably be some ancient software that
is in for a rude shock.  There are no plans to change this for
the KA ITSes at the moment.

From ALAN at MIT-MC  Wed Mar  9 04:54:00 1983
From: ALAN at MIT-MC (Alan Bawden)
Date: March 8 1983 22:54 EST
Subject: ILOPR?
In-Reply-To: The message of 8 Mar 1983 20:44 EST from David C. Plummer <DCP>
Message-ID: <mailman.82.1479821104.4695.its@nocrew.org>

I was about to point out that there is already an error code for one
variety of malformed .CALL, %ENSCL (illegal system call name).  Except I
find that the following:

	.CALL [SETZ ? SIXBIT /FOOBAR/ ? %CLERR,,1 ? SETZ 2]

Fails to skip, yet also fails to load 1 with any error code (it does not
even clear it.)  The left half of .IOS 0 is loaded with %ENSCL however, so
is is possible to find out the error if you look hard enough.  I'll bet the
idea is that if the first two words in a call block don't clearly identify
it as such, then ITS has no business looking at the next word and using it
to trash some other random location in the user's address space.

Now that is all fine and good if the instruction following the .CALL is a
.LOSE, since DDT will be able to figure it all out, but if instead there
was a JRST to a error reporting routine, I'll bet total randomness would
result from using the garbage left in 1 as an error code.  I guess I have
never been so unlucky as to misspell the name of a system call in a .CALL
that I was planning on handling the errors from myself.  I would argue that
THIS case should be made an ILOPR as well!

Another kind of malformed call block, namely one that doesn't terminate
with a word with bit 4.9 on, generates %ETMRG (too many arguments).  Since
this error is NOT a function of which call was named in the call block, it
really can only be interpreted as meaning "malformed call block".  However
it seems that ITS thinks that such call blocks are well-formed enough to
actually risk storing the error code in any supplied error parameter.
Since convention is to write error parameters at the beginning of a call
block, I think this is reasonable.

Funny, when I started this message I was planning on agreeing with KLH, but
I seem to have convinced myself that DCP is right.

From DCP at MIT-MC  Wed Mar  9 02:44:00 1983
From: DCP at MIT-MC (David C. Plummer)
Date: March 8 1983 20:44 EST
Subject: No subject
Message-ID: <mailman.83.1479821104.4695.its@nocrew.org>

I think ILOPRing is the right thing.  One argument is to
enumerate the common system calls and observe the effect of
changing it.  My first impression is a change would cause subtle
bugs, especially during debugging (where I'd insist on ILOPR if I
programmed it incorrectly).  Another argument is philosophy:
non-SKIP means failure to perform the desired operation.  ILOPR
means failure to perform the desired instruction.  You can't have
an operation before you have an instruction.

From CSTACY at MIT-MC  Wed Mar  9 00:18:00 1983
From: CSTACY at MIT-MC (Christopher C. Stacy)
Date: March 8 1983 18:18 EST
Subject: for installation
Message-ID: <mailman.84.1479821104.4695.its@nocrew.org>

New PEEK on all machines in SYSBIN;PEEK 565BIN.

From KLH at MIT-MC  Tue Mar  8 21:39:00 1983
From: KLH at MIT-MC (Ken Harrenstien)
Date: March 8 1983 15:39 EST
Subject: No subject
Message-ID: <mailman.85.1479821104.4695.its@nocrew.org>

Is it the right thing that .CALLs which point to a non-SETZ word
get an ILOPR instead of failing to skip?  Currently the only
thing which uses .CALL 0, is the symbolic system call frob, and
presumably if any new secondary dispatch is invented for it (ie
something other than SETZ as 1st word pointed at) it could also
be made the sort of call that skipped on success.

(this came up because a botched net server had a bad .CALL arg and
was ILOPR'ing instead of getting a failure return which would have
cleaned up the resulting mess)

From MOON at MIT-MC  Mon Mar  7 10:18:00 1983
From: MOON at MIT-MC (David A. Moon)
Date: March 7 1983 04:18 EST
Subject: Autospeed dialups and system crashes
Message-ID: <mailman.86.1479821104.4695.its@nocrew.org>

    Date: 7 February 1983 00:37 EST
    From: Ed Schwalenberg <ED @ MIT-MC>
    Subject: Autospeed dialups and system crashes
    To: BUG-ITS @ MIT-MC

    If MC goes down and comes back up, and I've patiently remained dialled
    up while it was down, it typically types out 30 or so "x" characters and
    then just stays wedged, probably waiting for 300 baud input as opposed to
    1200 baud which is what I normally use.  I guess optimal behavior would be
    for the 11 to remember the baud rate and tell the 10 when it comes back up,
    while suboptimal behavior would be to flush the 11's input buffer and then
    retry autospeeding.  Lousy behavior would be to hang up on the user.  But
    the current behavior is just about pessimal.
I don't know why it does this, since autospeeding and baud rates and all
of that are entirely inside the 11; the 10 has nothing to do with it.
But maybe someone gratuitously reloaded the 11, or maybe KLDCP did a Unibus
reset or something??  Also I'm pretty sure the baud rate is set to 1200
when the program is first loaded, before autospeeding.  I remember that
a couple of years ago I tried to debug this and couldn't.

From MOON at MIT-MC  Mon Mar  7 08:59:00 1983
From: MOON at MIT-MC (David A. Moon)
Date: March 7 1983 02:59 EST
Subject: terminal question
Message-ID: <mailman.87.1479821104.4695.its@nocrew.org>

    Date: 5 March 1983 22:43 EST
    From: Gail Zacharias <GZ @ MIT-MC>

    Is there anyway I can tell ITS to send parity bit high always (on dialup line).
    I'm getting a lot of framing errors and I figure this might help.
On MC only, you can set all these parameters with :LSPEED.  You want
to turn on extra stop-bit, and then presumably set the character length
one bit shorter to compensate.

From GZ at MIT-MC  Sun Mar  6 04:43:00 1983
From: GZ at MIT-MC (Gail Zacharias)
Date: March 5 1983 22:43 EST
Subject: terminal question
Message-ID: <mailman.88.1479821104.4695.its@nocrew.org>

Is there anyway I can tell ITS to send parity bit high always (on dialup line).
I'm getting a lot of framing errors and I figure this might help.

From CSTACY at MIT-MC  Sat Mar  5 06:44:00 1983
From: CSTACY at MIT-MC (Christopher C. Stacy)
Date: March 5 1983 00:44 EST
Subject: AHA!
Message-ID: <mailman.89.1479821104.4695.its@nocrew.org>


When I use my Emacs init, Emacs does not redisplay after I type a
character after a %PIATY interrupt.  Things seem to work fine if I
remove MODLIN from my init.  Is it likely this will get fixed?  I
think MODLIN is spiffy, but I really hate having to refresh my own
screen under these circumstances.

From CSTACY at MIT-MC  Fri Mar  4 08:16:00 1983
From: CSTACY at MIT-MC (Christopher C. Stacy)
Date: March 4 1983 02:16 EST
Subject: No subject
Message-ID: <mailman.90.1479821104.4695.its@nocrew.org>


Hey, it looks to me like EMACS forgot to know to redisplay when I type
something after my screen has been bashed (got-back-the-tty interrupt).
Did someone break TECO, or ECHOIN, or am I hallucinating?