From DCP at MIT-MC  Mon May 30 22:30:00 1983
From: DCP at MIT-MC (David C. Plummer)
Date: May 30 1983 16:30 EDT
Subject: No subject
Message-ID: <mailman.1385.1479821135.4695.its@nocrew.org>

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

From CStacyatMIT-MC  Tue May 24 00:00:00 1983
From: CStacyatMIT-MC (Christopher C. Stacy)
Date: Tuesday, 24 May 1983, 00:00
Subject: date-print on system console
In-Reply-To: The message of 23 May 83 17:54-EDT from Jeffrey P. Golden <JPG at MIT-MC>
Message-ID: <mailman.1386.1479821135.4695.its@nocrew.org>

OK, the SYSJOB will additionally print the date on the console about every 50 lines.
This should get you at least one per page (why not?).
The feature is run when the two minute clock ticks.

From JPG at MIT-MC  Mon May 23 23:54:00 1983
From: JPG at MIT-MC (Jeffrey P. Golden)
Date: May 23 1983 17:54 EDT
Subject: date-print on system console
Message-ID: <mailman.1387.1479821135.4695.its@nocrew.org>

   KLH at MIT-MC 05/23/83 17:30:31
   To: JPG at MIT-MC
   CC: (BUG ITS) at MIT-MC
       JPG at MIT-MC 22 May 1983 13:22 EDT
       It would be nice if the system console had the date printed out more 
       frequently than once every several pages.
   The sysjob routines could count the number of LF's and trigger a new 
   date-print every so many lines (in addition to current time-based 
   interval).  This is what COMSAT does for its stats.  Probably once per 3 
   pages is enough?
If I could be assured that I could find the date somewhere in 3 consecutive 
pages if I only looked hard enough, that would be great!  So I like this.
 
   CSTACY at MIT-MC 05/23/83 01:38:43 Re:  IT IS NOW 1:39 ON MONDAY 23 MAY 1983
Subject:  IT IS NOW 1:39 ON MONDAY 23 MAY 1983
   To: JPG at MIT-MC
   CC: (BUG ITS) at MIT-MC
   I think it prints the date when the very slow clock ticks, about once
   every two hours; it also prints it when assorted random things happen.
   How often do you want to see it, and what console log events are you
   interested in having full timestamps for?
I like what KLH suggests better, but if I can't have that, I suppose 
once every half hour would be fine.  Since ITS does not have 
'auto-hangup' for its dialup lines, every now and then I have to find 
out who left a dialup line hung.  Then I can give the loser a stern 
warning.  By OS'ing the line I know the date and time the act was 
committed (and perhaps the loser's nickname!), but I need to look at 
the system console to get the login name.  

From KLH at MIT-MC  Mon May 23 23:30:00 1983
From: KLH at MIT-MC (Ken Harrenstien)
Date: May 23 1983 17:30 EDT
Subject: No subject
Message-ID: <mailman.1388.1479821135.4695.its@nocrew.org>

    Date: 22 May 1983 13:22 EDT
    From: Jeffrey P. Golden <JPG @ MIT-MC>

    It would be nice if the system console had the date printed out more 
    frequently then once every several pages.

The sysjob routines could count the number of LF's and trigger a new date-print
every so many lines (in addition to current time-based interval).  This
is what COMSAT does for its stats.  Probably once per 3 pages is enough?

From CSTACY at MIT-MC  Mon May 23 07:38:00 1983
From: CSTACY at MIT-MC (Christopher C. Stacy)
Date: May 23 1983 01:38 EDT
Subject: IT IS NOW 1:39 ON MONDAY 23 MAY 1983
In-Reply-To: Msg of 22 May 1983 13:22 EDT from Jeffrey P. Golden <JPG>
Message-ID: <mailman.1389.1479821135.4695.its@nocrew.org>

    Date: 22 May 1983 13:22 EDT
    From: Jeffrey P. Golden <JPG>
    To:   BUG-ITS

    It would be nice if the system console had the date printed out more 
    frequently then once every several pages.

I think it prints the date when the very slow clock ticks, about once
every two hour; it also prints it when assorted random things happen.
How often do you want to see it, and what console log events are you
interested in having full timestamps for?

From JPG at MIT-MC  Sun May 22 19:22:00 1983
From: JPG at MIT-MC (Jeffrey P. Golden)
Date: May 22 1983 13:22 EDT
Subject: No subject
Message-ID: <mailman.1390.1479821135.4695.its@nocrew.org>

It would be nice if the system console had the date printed out more 
frequently then once every several pages.

From CSTACY at MIT-MC  Sun May 22 12:27:00 1983
From: CSTACY at MIT-MC (Christopher C. Stacy)
Date: May 22 1983 06:27 EDT
Subject: No subject
Message-ID: <mailman.1391.1479821135.4695.its@nocrew.org>


When I come in over a TAC, I dont seem to be able to get meta bits
through.  Setting +%TPMTA doesn't work (it does on dialups though).
Am I forgetting to do something (like a TAC command) or was I dreaming
when I thought I had used meta keys over TIPs before?

From GSB at MIT-MC  Fri May 20 05:35:00 1983
From: GSB at MIT-MC (Glenn S. Burke)
Date: May 19 1983 23:35 EDT
Subject: dirsiz
Message-ID: <mailman.1392.1479821135.4695.its@nocrew.org>

:call dirsiz claims the second arg sets quota, the source says (and uses)
LH of second arg.

From CSTACY at MIT-MC  Fri May 13 22:08:00 1983
From: CSTACY at MIT-MC (Christopher C. Stacy)
Date: May 13 1983 16:08 EDT
Subject: one more time...
Message-ID: <mailman.1393.1479821135.4695.its@nocrew.org>


The new Inquire database is again experimentally installed
on MC only.  All bugs found last time appear to have been
fixed.  Send me mail if the old one needs to be re-installed
or anything.

Chris

From CSTACY at MIT-MC  Wed May 11 17:36:00 1983
From: CSTACY at MIT-MC (Christopher C. Stacy)
Date: May 11 1983 11:36 EDT
Subject: No subject
Message-ID: <mailman.1394.1479821135.4695.its@nocrew.org>


I de-installed the new INQUIRE  database and programs, because after
a few real users I found some bugs.  Will try again tomorrow.
l

From CSTACY at MIT-MC  Wed May 11 06:07:00 1983
From: CSTACY at MIT-MC (Christopher C. Stacy)
Date: May 11 1983 00:07 EDT
Subject: new Inquire database and stuff is being tested on MC
Message-ID: <mailman.1395.1479821135.4695.its@nocrew.org>


OK, the new LSR1 database is installed on MC only.
Experimental versions of INQUIR, LOOKUP, NAME, and INQUPD are running here.
I have tested each of these, and they seem to work.
If anyone notices anything very bad going on, send me mail.

Note that the user interface on ITS does not let you send entries
to Twenex, only the other way around.  This is because I could not
bring myself to deal with the INQUIR source code.  I will fix this
sometime by getting up more guts, or just rewriting it.  Inquires
on all the ITS will be the same.  This has the good side effect that
if I have badly blown it this evening, you can copy a database to MC
from one of the other machines and de-install the experimental programs.

Note that the databases are not in a completely compatible format.
LSRTNS has been updated to the new format.

From CSTACY at MIT-MC  Mon May  9 05:30:00 1983
From: CSTACY at MIT-MC (Christopher C. Stacy)
Date: May 8 1983 23:30 EDT
Subject: No subject
Message-ID: <mailman.1396.1479821135.4695.its@nocrew.org>

I replied to SJOBRG.

From SJOBRG at MIT-MC  Mon May  9 05:25:00 1983
From: SJOBRG at MIT-MC (Robert W. Sjoberg)
Date: May 8 1983 23:25 EDT
Subject: No subject
Message-ID: <mailman.1397.1479821135.4695.its@nocrew.org>

Can someone please point me to documentation (if any) on the format of the
ITS archive files?  I need enough information to be able to extract
directory information and file contents (I don't plan on adding anything
or deleting, just reading) from an archive file.  Thanks.
--Bob

From CStacyatMIT-MC  Sun May  8 00:00:00 1983
From: CStacyatMIT-MC (Christopher C. Stacy)
Date: Sunday, 8 May 1983, 00:00
Subject: [Re: Is I.T.S. mistaken as to today's date?]
In-Reply-To: The message of 8 May 83 04:56-EDT from Glenn S. Burke <GSB at MIT-ML>
Message-ID: <mailman.1398.1479821135.4695.its@nocrew.org>

Well, I just hacked GMSGS to do just expire hacking if it starts under
the job name EXPIRE, and I hacked TARAKA DEMSTR on DM to start it up.
So, now everday GMSGS will be run and the directory should stay
cleaned.  I have not tested this, so let me know if there are
problems, but it really should work.

From CSTACY at MIT-MC  Sat May  7 08:55:00 1983
From: CSTACY at MIT-MC (Christopher C. Stacy)
Date: May 7 1983 02:55 EDT
Subject: SYSHAK;
Message-ID: <mailman.1399.1479821135.4695.its@nocrew.org>


I merged SYSHAK back into SYSTEM;.

From Moon at SCRC-TENEX  Fri May  6 00:00:00 1983
From: Moon at SCRC-TENEX (David A. Moon)
Date: Friday, 6 May 1983, 00:00
Subject: No subject
In-Reply-To: The message of 6 May 83 11:28-EDT from Jeffrey J Tyrone Sealy <TY at MIT-MC>
Message-ID: <mailman.1400.1479821135.4695.its@nocrew.org>

    Date: 6 May 1983 11:28 EDT
    From: Jeffrey J Tyrone Sealy <TY @ MIT-MC>
    The console-11 died today, and so ITS was running along fine
    but the cty was not doing anything and the swr was not being
    read.  What is the optimum least obnoxious thing to do in
    this sort of event?
Reboot the 11.  Boot, RP0, P IOELEV, ITS ON.  If this makes ITS crash
as it sometimes does continue it.

From TY at MIT-MC  Fri May  6 17:28:00 1983
From: TY at MIT-MC (Jeffrey J Tyrone Sealy)
Date: May 6 1983 11:28 EDT
Subject: No subject
Message-ID: <mailman.1401.1479821135.4695.its@nocrew.org>

The console-11 died today, and so ITS was running along fine
but the cty was not doing anything and the swr was not being
read.  What is the optimum least obnoxious thing to do in
this sort of event?

From CSTACY at MIT-MC  Thu May  5 10:12:00 1983
From: CSTACY at MIT-MC (Christopher C. Stacy)
Date: May 5 1983 04:12 EDT
Subject: removing AI from stuff
Message-ID: <mailman.1403.1479821135.4695.its@nocrew.org>

TALK (WHOJ,U,WHOM,etc) fixed.

From CStacyatMIT-MC  Thu May  5 00:00:00 1983
From: CStacyatMIT-MC (Christopher C. Stacy)
Date: Thursday, 5 May 1983, 00:00
Subject: STLGET
In-Reply-To: The message of 5 May 83 02:56-EDT from David A. Moon <Moon at SCRC-TENEX>
Message-ID: <mailman.1404.1479821135.4695.its@nocrew.org>

    Date: Thursday, 5 May 1983, 02:56-EDT
    From: David A. Moon <Moon at SCRC-TENEX>
	Date: 2 May 1983 08:05 EDT
	From: Christopher C. Stacy <CSTACY @ MIT-MC>
	It would be nice if STLGET could actually return the HOSTS3 address
	of the host being served.  It's sort of a crock to parse the name
	of the host, which might not always fix in six characters anyway.
	I am not sure if it is reasonable to try to get this info, but if
	I get ambitious I'll find out.
    You can get it from some standard place in the memory of the server job,
    I think.

Right; it's documented in the TELSER source that a bunch of variables
should not move (ttyloc, binary-mode flag, host. etc.) but I didn't
think it was a good idea for the system to make even that assumption
about what the telnet server is like...

From Moon at SCRC-TENEX  Thu May  5 00:00:00 1983
From: Moon at SCRC-TENEX (David A. Moon)
Date: Thursday, 5 May 1983, 00:00
Subject: SYS:
In-Reply-To: The message of 27 Apr 83 08:41-EDT from Christopher Stacy <CStacy at MIT-OZ>
Message-ID: <mailman.1405.1479821135.4695.its@nocrew.org>

    Date: Wednesday, 27 April 1983, 08:41-EDT
    From: Christopher Stacy <CStacy at MIT-OZ>
    I have an idea for implementing Twenex-like logical names on ITS.
    My idea for getting around this is a to extend JOBRET so that there is
    a way for the BDH to tell the system: "I am going away now. Disconnect
    the user from me and retry the OPEN call using these args I am giving
    you."
This sounds like a good idea to me.

From Moon at SCRC-TENEX  Thu May  5 00:00:00 1983
From: Moon at SCRC-TENEX (David A. Moon)
Date: Thursday, 5 May 1983, 00:00
Subject: STLGET
In-Reply-To: The message of 2 May 83 08:05-EDT from Christopher C. Stacy <CSTACY at MIT-MC>
Message-ID: <mailman.1406.1479821135.4695.its@nocrew.org>

    Date: 2 May 1983 08:05 EDT
    From: Christopher C. Stacy <CSTACY @ MIT-MC>
    It would be nice if STLGET could actually return the HOSTS3 address
    of the host being served.  It's sort of a crock to parse the name
    of the host, which might not always fix in six characters anyway.
    I am not sure if it is reasonable to try to get this info, but if
    I get ambitious I'll find out.
You can get it from some standard place in the memory of the server job,
I think.

From CSTACY at MIT-MC  Thu May  5 05:36:00 1983
From: CSTACY at MIT-MC (Christopher C. Stacy)
Date: May 4 1983 23:36 EDT
Subject: No subject
Message-ID: <mailman.1407.1479821135.4695.its@nocrew.org>

I flushed AI from :INSTAL

From CENT at MIT-ML  Tue May  3 00:00:00 1983
From: CENT at MIT-ML (CENT at MIT-ML)
Date: 03 May 1983 00:00
Subject: *msg list info
Message-ID: <mailman.1408.1479821135.4695.its@nocrew.org>

no, there is already a meaning too close to *its for your suggestion to be
wise: :whois @ITS would do a :whois on everyone logged in on the ITSs (it
doesn't work quite right now because AI is gone; could someone dig into
:name or wherever this is hacked in and remove AI references?). this aside,
i don't know whether your idea could even be made to work (someone who
knows more about :whois and mailing lists might be able to tell you).

If you had looked in the menu for the MAIL subtree, you would have found
the node Announcements (also available from the top-level menu and through
a footnote from the new-user-info subtree), which gets you to this
information. for that matter, it's also mentioned in the mailing lists file
right where the sysmsg lists are defined..

From DEVON at MIT-MC  Tue May  3 07:04:00 1983
From: DEVON at MIT-MC (Devon S. McCullough)
Date: May 3 1983 01:04 EDT
Subject: No subject
Message-ID: <mailman.1409.1479821135.4695.its@nocrew.org>

Maybe it would be a good idea to be able to say :whois *ITS and get a description of what sort of messages should be addressed there, likewise for other magic mailing addressees.  I wasn't able to find the info from :info even thought I am fairly sure it's in there somewhere.

From CSTACY at MIT-MC  Mon May  2 20:04:00 1983
From: CSTACY at MIT-MC (Christopher C. Stacy)
Date: May 2 1983 14:04 EDT
Subject: AI
Message-ID: <mailman.1410.1479821135.4695.its@nocrew.org>


The AI KA10 has been flushed,
please update your programs.



    ...Each evening from December to December
    Before you drift asleep upon your cot
    Think back on all the tales that you remember
    Of Camelot

        Ask every person
        If he's heard the story
        And tell it loud and clear
        If he has not
        That once there was a fleeting wisp of glory
        Called Camelot

            Don't let it be forgot
            That once there was a spot
            For one brief shining moment
            That was known as Camelot....


[From the Lerner and Loewe musical "Camelot"]

From CSTACY at MIT-MC  Mon May  2 14:05:00 1983
From: CSTACY at MIT-MC (Christopher C. Stacy)
Date: May 2 1983 08:05 EDT
Subject: No subject
Message-ID: <mailman.1411.1479821135.4695.its@nocrew.org>


It would be nice if STLGET could actually return the HOSTS3 address
of the host being served.  It's sort of a crock to parse the name
of the host, which might not always fix in six characters anyway.
I am not sure if it is reasonable to try to get this info, but if
I get ambitious I'll find out.

From CSTACY at MIT-MC  Mon May  2 08:07:00 1983
From: CSTACY at MIT-MC (Christopher C. Stacy)
Date: May 2 1983 02:07 EDT
Subject: No subject
Message-ID: <mailman.1412.1479821135.4695.its@nocrew.org>


In ITS 1342, the STLGET call returns a fourth value, as documented
below.  (Note that in previous ITS versions, Val 4 was present but only
had the user index; this former behaviour was not documented.)

STLGET:	get information from Server Telnet

	arg 1	a <TTY>

	val 1	XJNAME of server telnet
	val 2	TRMNAM of server telnet
		This is the sixbit name of the host connected to.
	val 3	SNAME of server telnet
	val 4   In LH: STY status bits
		In RH: index of telnet server job which owns the STY.

	This call can be used to find out where in the network
	a TTY really is.

	The STY status bits are from the STYSTS table in ITS.
	Some of the more interesting ones include:
	%SSNET==4000	;4.3 = 1 => THIS STY CONNECTED TO SOME NET SOCKETS.
	%SSCHA==2000	;4.2 = 0 FOR ARPANET, 1 FOR CHAOS NET
	%SSTCP==1000	;4.1 = 1 for TCP internet (%SSCHA must be 0)


From ALAN at MIT-MC  Sun May  1 07:58:00 1983
From: ALAN at MIT-MC (Alan Bawden)
Date: May 1 1983 01:58 EDT
Subject: SYS:
In-Reply-To: Msg of 30 Apr 1983 21:25 EDT from Ed Schwalenberg <ED>
Message-ID: <mailman.1413.1479821135.4695.its@nocrew.org>

    Date: 30 April 1983 21:25 EDT
    From: Ed Schwalenberg <ED>

    Just for the sake of whatever ancient programs might depend on the
    behavior, I would strongly recommend that SYS: be equivalent to
    DSK:SYS; as the documentation states.

Yeah, I was gonna mention a couple of days ago that it would be best to
pick a new device name to have this behavior.  SYSTEM:?

CStacy's suggestion about giving JOBRET the ability to cause the OPEN to
retry with different arguments is a good one I think.  (I wonder if a
kludge is possible even currently by giving the loser a translation and
then causing him to get PCLSR'ed?  That would be a wierd hack!  The problem
would be cleaning up all of the translations that would accumulate...)  On
the other hand I would really hate to have SYSTEM: (or whatever) be a
jobdevice if it is going to be used all the time by DDT to find binarys.

From ED at MIT-MC  Sun May  1 03:25:00 1983
From: ED at MIT-MC (Ed Schwalenberg)
Date: April 30 1983 21:25 EDT
Subject: SYS:
Message-ID: <mailman.1414.1479821135.4695.its@nocrew.org>

Just for the sake of whatever ancient programs might depend on the behavior,
I would strongly recommend that SYS: be equivalent to DSK:SYS; as the
documentation states.

While on the subject of ITS devices, I'm spending idle moments compiling a
document on them- for each device, listing where it is implemented, what it
does, what machines have (or had) it, what option bits for it exist, etc.
Contributions are solicited, particularly by those of you who delight in
using obscure devices and have thus discovered unusual properties (like nil
documentation!).