From MCB at MIT-MC  Sun Feb 27 02:29:00 1983
From: MCB at MIT-MC (Michael A. Bloom)
Date: February 26 1983 20:29 EST
Subject: No subject
Message-ID: <mailman.91.1479821104.4695.its@nocrew.org>

I just connected to DM through the arpanet, and got a DDT instead of a PWORD.

From DCPatSCRC-TENEX  Thu Feb 24 00:00:00 1983
From: DCPatSCRC-TENEX (David C. Plummer)
Date: Thursday, 24 February 1983, 00:00
Subject: Those mythical chaos BRD packets
Message-ID: <mailman.92.1479821104.4695.its@nocrew.org>

I implemented chaos BRD packets in MINITS today.  They seem to work.

I also hacked some code for the Lisp Machine to actually test it, but it's
just as gross and ugly as the rest of the current LispM chaos
implementation. 

From CSTACY at MIT-MC  Tue Feb 22 16:24:00 1983
From: CSTACY at MIT-MC (Christopher C. Stacy)
Date: February 22 1983 10:24 EST
Subject: No subject
Message-ID: <mailman.93.1479821104.4695.its@nocrew.org>

slightly less crockish WHOJ installed on MC, ML, and AI.
Bugs to me.

From MOON5 at MIT-MC  Tue Feb 22 02:49:00 1983
From: MOON5 at MIT-MC (David A. Moon)
Date: February 21 1983 20:49 EST
Subject: ML
Message-ID: <mailman.94.1479821105.4695.its@nocrew.org>

I made NSUBNT (number of Chaosnet subnets) be a more reasonable size.
ML (the only ITS machine that does its own Chaosnet routing) should
get a reassembled ITS when convenient.

From CSTACY at MIT-MC  Sun Feb 20 02:11:00 1983
From: CSTACY at MIT-MC (Christopher C. Stacy)
Date: February 19 1983 20:11 EST
Subject: [KLH: forwarded]
Message-ID: <mailman.95.1479821105.4695.its@nocrew.org>


I see KLH already fixed the safe site problem by reassembling
PWORD, so now it uses the same NETWRK goodies as TELSER.

From CSTACY at MIT-MC  Sun Feb 20 02:07:00 1983
From: CSTACY at MIT-MC (Christopher C. Stacy)
Date: February 19 1983 20:07 EST
Subject: No subject
In-Reply-To: The message of 18 Feb 1983 20:34 EST from J. Eliot B. Moss <EBM>
Message-ID: <mailman.96.1479821105.4695.its@nocrew.org>

    Date: 18 February 1983 20:34 EST
    From: J. Eliot B. Moss <EBM>
    To:   BUG-ITS

    I CHTN'ed from XX and had MC request my password ... has the interface
    changed or is something screwy going on?  I thought logins from other
    MIT machines did not require passwords ...

TELSER apparently has a bug putting the host address where PWORD can
see it, (or maybe PWORD needs to see a different format host address).
I will look at and fix this in a moment.

From KMP at MIT-MC  Sat Feb 19 21:47:00 1983
From: KMP at MIT-MC (Kent M. Pitman)
Date: February 19 1983 15:47 EST
Subject: MC crashing
Message-ID: <mailman.97.1479821105.4695.its@nocrew.org>

MC was down this morning when I came in. Someone cold booted it and it only
lasted a few minutes. He was in the midst of cold booting it when I came in
to look at it just now, so I finished the booting. Next time it crashes, I'll
try to poke a bit at the state and provide some debugging info. I posted
a system message (in SYS;SYSTEM MAIL) warning that the system was being 
unreliable. If it stays up for a while, someone might want to remove that 
message. --kmp

From TK at MIT-MC  Sat Feb 19 21:22:00 1983
From: TK at MIT-MC (Tom Knight)
Date: February 19 1983 15:22 EST
Subject: No subject
Message-ID: <mailman.98.1479821105.4695.its@nocrew.org>

MC would not boot from disk this afternoon, because it was hung, probably
at PI level 3, shlunking unit 1 back and forth.  Apparently booting
with the boot switch is incapable of stopping the processor???  Eventually,
by turning off unit 1, I got the machine to crash, and it then booted.  This
seems less than elegant as a way of solving the problem.

From EBM at MIT-MC  Sat Feb 19 02:34:00 1983
From: EBM at MIT-MC (J. Eliot B. Moss)
Date: February 18 1983 20:34 EST
Subject: No subject
Message-ID: <mailman.100.1479821105.4695.its@nocrew.org>

I CHTN'ed from XX and had MC request my password ... has the interface
changed or is something screwy going on?  I thought logins from other
MIT machines did not require passwords ...

From KLH at MIT-MC  Fri Feb 18 14:16:00 1983
From: KLH at MIT-MC (Ken Harrenstien)
Date: February 18 1983 08:16 EST
Subject: NETWRK and friends use HOSTS3 now
Message-ID: <mailman.101.1479821105.4695.its@nocrew.org>

I decided to do a little work on credit tonight.

SYSENG;HOSTS XFILE now generates SYSBIN;HOSTS3 BIN as well.  This is the
	new Internet host table and it is intended to become the standard.
	Both HOSTS1 and HOSTS2 will eventually go away.
SYSENG;NETWRK has a new switch, $$HSTS3, that tells the routines to use
	HOSTS3 instead of HOSTS2.  Also, the host number parser has
	been taught how to understand the new 4-octet syntax, as
	in "10.3.0.44" which is MC.
TELNET has been modified to use the NETWRK routines (HOSTNM and
	SYMGET and friends).  As a result, TELNET uses HOSTS3 and
	no longer needs HOSTS1.  Hurray!!!!!!!!!!!!!!!!
	This of course implies that TELNET parses anything NETWRK does.
	The big question: is there ANY other software that still depends
	on HOSTS1??  I am going to flush that table VERY soon.
HOST (alias HSTLOK) has likewise been modified for HOSTS3.
TELSER also uses HOSTS3.
PEEK now uses HOSTS3.
COMSAT now uses ...
QMAIL now ...
FTPS now ...
FTPU ...		(All on MC only for the moment)

Not a bad night's work.  Ka-ching!

There are still a number of programs that need to have $$HST3 turned
on.  The only thing you need to be careful of is references to NW$BYT
and NW%ARP or NW%CHS; it is better to use the GETNET macro than
NW$BYT.  The file format itself is almost the same; only the format
of host and net addresses is different.  Note that ITS will understand
either HOSTS2 or HOSTS3 format, using either NCP or TCP, so there is
no need to retain HOSTS2 even if you are keeping NCP code around for
posterity (which I recommend, by the way).
	As you upgrade, try to add a note to NETWRK pointing at your
software, (see the first page) so that eventually we will have a handy
list of things that use NETWRK and which will need to be reviewed in
the event of future changes.

--Ken

From CSTACY at MIT-MC  Thu Feb 17 03:04:00 1983
From: CSTACY at MIT-MC (Christopher C. Stacy)
Date: February 16 1983 21:04 EST
Subject: No subject
Message-ID: <mailman.102.1479821105.4695.its@nocrew.org>

Hack :WHOJ installed on all ITSs now.

From KLH at MIT-MC  Wed Feb 16 14:27:00 1983
From: KLH at MIT-MC (Ken Harrenstien)
Date: February 16 1983 08:27 EST
Subject: New PEEK on MC
Message-ID: <mailman.103.1479821105.4695.its@nocrew.org>

I have installed another new PEEK on MC for testing.
One feature of this version is that it does away with the stupid
internal table that gave certain people (who are CC'd above) J mode
by default.  Those people who cannot type :P J can just type :PJ
or PJ^K, if they establish the necessary link to SYS;TS PEEK.

A more interesting feature is the ability to PEEK at ITS crash dumps.
This must be invoked as JCL, to wit ":PEEK < filename".  For example,
	:P <CRASH;ITS BLOWN
This will grovel for a while and then put you into an "autopsy mode"
(command char is "<") which doesn't have much useful info at the
moment, but most of the other modes will then show you what ITS
was doing at the moment it crashed.  Rather entertaining...

A feature of interest only to PEEK hackers is that the code has
undergone a lot of facelifting.

From CSTACY at MIT-MC  Wed Feb 16 09:54:00 1983
From: CSTACY at MIT-MC (Christopher C. Stacy)
Date: February 16 1983 03:54 EST
Subject: I know this is a crock
Message-ID: <mailman.104.1479821105.4695.its@nocrew.org>


There is now a crock version of TALK  (WHOJ & friends)
installed on MC and AI.  If no one complains to much
I will install it on ML and DM later on.

This is not an RSEXEC frob at all, but a quick
dirty hack based on the MLSLV (it reads TTY:).

When I get a chance, I will convert TALK and IEC to
work with TCP, but this was driving me crazy so I
wrote this interim crock.

Chris

From KLH at MIT-MC  Tue Feb 15 13:18:00 1983
From: KLH at MIT-MC (Ken Harrenstien)
Date: February 15 1983 07:18 EST
Subject: No subject
Message-ID: <mailman.105.1479821105.4695.its@nocrew.org>

I just noticed that the :DOC for RFNAME doesn't mention that
it can take a 3rd argument which is a BP to place to deposit an
ASCIZ filename string.

From KMP at MIT-MC  Mon Feb 14 01:13:00 1983
From: KMP at MIT-MC (Kent M. Pitman)
Date: February 13 1983 19:13 EST
Subject: Can somebody answer this?
Message-ID: <mailman.106.1479821105.4695.its@nocrew.org>

Date: February 12 1983 15:02 mst
From: Schauble.HDSA at M.PCO.LISD.HIS
To:   KMP
Re:   ITS archive files
Received: from M.PCO.LISD.HIS by MIT-MULTICS.ARPA dial; 12-Feb-1983 17:03:33-est

I'm looking for a way to transfer ITS archive files to Multics and have
them arrive as Multics archives files. I recall that someone once wrote
a program to do this. Do you perchange know anything about it?

If not, do you have any documentation on the archive file format so that
I can write one? I have no problem transfering a binary image of the ITS
file, I just need to decode it.

          Thanks,
          Paul

From KLH at MIT-MC  Sun Feb 13 18:04:00 1983
From: KLH at MIT-MC (Ken Harrenstien)
Date: February 13 1983 12:04 EST
Subject: No subject
Message-ID: <mailman.107.1479821105.4695.its@nocrew.org>

New peek written to SYS;TS PEEK on MC only.
If no bugs surface after a few days, it can be copied to other systems.

From CSTACY at MIT-AI  Fri Feb 11 00:00:00 1983
From: CSTACY at MIT-AI (CSTACY at MIT-AI)
Date: 11 Feb 1983 00:00
Subject: No subject
Message-ID: <mailman.108.1479821105.4695.its@nocrew.org>

AI now has config options set for no 10-11 frobs such as the Chaosnet.
This seems to work, I am typing this from it.
I finished installing the MLDEV stuff here.


From DCP at MIT-MC  Thu Feb 10 12:54:00 1983
From: DCP at MIT-MC (David C. Plummer)
Date: February 10 1983 06:54 EST
Subject: TCP NAME user/server
Message-ID: <mailman.109.1479821105.4695.its@nocrew.org>

Let's see if I can remember everything I just did.

For MC:

I linked DEVICE;JOBDEV AI to the same thing DEVICE;JOBDEV DM
points to (SYSBIN;MLDEV BIN).  This caused AI to appear as a
device.  ML's and DM's DEVICE directories are consistent (and
hopefully have the correct programs).

For AI:

I installed the TCP NAME user/server program.  :F @AI from MC now
works.  :F @MC from AI does not because AI tries to use the
chaosnet!!??!!.  The host table on AI says it is arpanet only,
but apparently the system still has chaos code assembled in.  
:F @DM from AI does work.

I tried to make sure the user ITS JOBDEVs were correct.  MC:...
doesn't work, again because it tries to use the chaosnet.  DM:
does work though.

CSTACY, you should revise AI's greeting message (about MLSLV
services), clean up any mess I may have left around, and perhaps
assemble AI without chaosnet code (if that is the right thing).

From CSTACY at MIT-MC  Mon Feb  7 19:00:00 1983
From: CSTACY at MIT-MC (Christopher C. Stacy)
Date: February 7 1983 13:00 EST
Subject: No subject
Message-ID: <mailman.110.1479821105.4695.its@nocrew.org>

there is now a kludge in NETWRK for $$TCP inserters
who bomb into ANALYZ, cuz I was getting bored with ISE0.
I (or someone) should write a real TCP analyzer frob for it sometime.

From CENT at MIT-ML  Mon Feb  7 00:00:00 1983
From: CENT at MIT-ML (CENT at MIT-ML)
Date: 07 Feb 1983 00:00
Subject: TCP NAME user/server
Message-ID: <mailman.111.1479821105.4695.its@nocrew.org>

    I made the ITS name user and name server work under TCP.  I made some
    spazzes, and there was a NCP/TCP difference causing a little more
    lossage.
    ....
    I installed and pdumped this on MC, ML and DM (what's going on with
    AI?).  I tested it between MC and DM (both directions) and ML and DM
    (both directions).  Source is back in SYSEN2; (whence it came).

ai was down with minor disk lossage. please try installing now..

From ED at MIT-MC  Mon Feb  7 06:37:00 1983
From: ED at MIT-MC (Ed Schwalenberg)
Date: February 7 1983 00:37 EST
Subject: Autospeed dialups and system crashes
Message-ID: <mailman.112.1479821105.4695.its@nocrew.org>

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.
Obviously this is low-priority, though if somebody was to volunteer to fix
the symptom by simply having MC never go down I'm sure they'd get a penny
from JM.  I'd be willing to give them a quarter, myself!

From DCP at MIT-MC  Sun Feb  6 10:09:00 1983
From: DCP at MIT-MC (David C. Plummer)
Date: February 6 1983 04:09 EST
Subject: TCP NAME user/server
Message-ID: <mailman.113.1479821105.4695.its@nocrew.org>

I made the ITS name user and name server work under TCP.  I made
some spazzes, and there was a NCP/TCP difference causing a little
more lossage.

Spazz 1: I completely blew it when doing the NETBLK for the LSN.
  I gave it %NSRFS as the wait state.  A lot of good that does!!
Spazz 2: I didn't know that a NETBLK for the LSN would probably
  return the new state as %NSRFC.  There is another NETBLK
  waiting for it to go out of %NSRFC.
Spazz 3: The /i switch (use IP/TCP) simply could not work.  There
  is a comment to this effect in the code.  Basically, :f /i at dm
  passes the /i on to DM, and :f @dm/i throws the /i away (this
  is conjecture, but seems to fit the data).  Therefore, it
  always uses TCP over the arpanet.

Difference: NCP didn't need a FORCE done to send the JCL to the
  other host?  I know TCP does, but there was now such call in
  the program.  There is now!

I installed and pdumped this on MC, ML and DM (what's going on
with AI?).  I tested it between MC and DM (both directions) and
ML and DM (both directions).  Source is back in SYSEN2; (whence it
came).

Ken, I know several people complained that ITS thought it had a
TCP NAME server but it never worked.  Could you ask them to try
again?  Thanks.

From DCP at MIT-MC  Sun Feb  6 08:48:00 1983
From: DCP at MIT-MC (David C. Plummer)
Date: February 6 1983 02:48 EST
Subject: No subject
Message-ID: <mailman.114.1479821105.4695.its@nocrew.org>

The CHAOS ARPA server now behaves as follows:

Contact name TCP  tries to establish a  TCP connection
Contact name NCP  tries to establish an NCP connection, even
		  though it should never succeed.
Contact name ARPA tries to establish a  TCP connection.  If it
		  times out (15 seconds), then it tries an NCP
		  connection.

Auxiliary connections may work again, using the network protocol
that the primary connection is using.

From MOON at MIT-MC  Tue Feb  1 06:53:00 1983
From: MOON at MIT-MC (David A. Moon)
Date: February 1 1983 00:53 EST
Subject: No subject
Message-ID: <mailman.115.1479821105.4695.its@nocrew.org>

Noticing that there was no CHAOS-TCP gateway on ML, I put one there.
I didn't bother testing it.

From ASB at MIT-MC  Tue Feb  1 00:07:00 1983
From: ASB at MIT-MC (Richard Brenner)
Date: January 31 1983 18:07 EST
Subject: No subject
Message-ID: <mailman.116.1479821105.4695.its@nocrew.org>

  JPG at MIT-MC 01/31/83 17:56:21 Re: Job A wants the TTY
Subject: Job A wants the TTY
  To: ASB at MIT-MC
  CC: JPG at MIT-MC
     ASB at MIT-MC 01/31/83 17:23:03 Re: Job A wants the TTY
Subject: Job A wants the TTY
     Recently there has been a change in the way that the user is notified
     that a proceeded Macsyma needs the tty.
     Formerly, notification would be issued only once while in another Macsyma,
     but it now appears that this occurs whenever a file is loaded.  To see
     this new behavior, start up a Macsyma, then after you get a (C1)
     ^Z it and ^P it.
     Then start a second Macsyma, and try something like
     INTEGRATE(X,X,0,1);
     I have not tried OA^K.
     I prefer the old behavior.
  This printout is done by ITS, not by MACSYMA, so we have no control 
  over it.  It happens whenever the job needs to go up to top-level for 
  something which may very well happen while a file is being loaded. 
  I'm not convinced there's been any change here, but if there has, it's 
  an ITS issue, not a MACSYMA issue.