From SRA at XX.LCS.MIT.EDU  Thu Aug 21 08:05:00 1986
From: SRA at XX.LCS.MIT.EDU (Rob Austein)
Date: Aug 21 1986  02:05 EDT
Subject: .RYEAR and time zones again
In-Reply-To: Msg of 21 Aug 1986  00:12-EDT from Alan Bawden <ALAN@AI.AI.MIT.EDU>
Message-ID: <SRA.12232491989.BABYL@XX.LCS.MIT.EDU>

Making it a new system call is fine.  What I'm looking for is a single
UUO that will return the information currently returned by .RLPDTM
plus time zone information.  Doesn't have to be in .RLPDTM format, but
should be easy to calculate things like DATIME"TIMGTN from it.

For that matter it would be a win if there was a system call that did
the DATIME"TIMGTN calculation with maximum hair and all the leap year
corrections understood to the human race, once, at system boot time,
then just added system uptime to that to get current time.  This
business of having to recalculate the number of leap years since 1 Jan
1900 every time you want an absolute time value is for the birds.

From ALAN at AI.AI.MIT.EDU  Thu Aug 21 06:12:52 1986
From: ALAN at AI.AI.MIT.EDU (Alan Bawden)
Date: Aug 21 86 00:12:52 EDT
Subject: .RYEAR and time zones again
In-Reply-To: Msg of Wed 20 Aug 1986  16:04 EDT from Rob Austein <SRA at XX.LCS.MIT.EDU>
Message-ID: <[AI.AI.MIT.EDU].86070.860821.ALAN>

Why don't we just add another system call to return timezone related
information rather than trying to squeeze something into the last few bits
of .RYEAR?  First, I dislike recycling fields that are documented to be
zero (rather than being documented as reserved for future expansion.)
Second, given the existence of half-hour and even quarter-hour timezones in
parts of the world, five bits isn't really enough.  Third, while we are at
it, it might be a good idea to try and do something about generalizing the
daylight savings time stuff to cover whatever local laws there might be
geverning time.

From SRA at XX.LCS.MIT.EDU  Wed Aug 20 22:04:00 1986
From: SRA at XX.LCS.MIT.EDU (Rob Austein)
Date: Aug 20 1986  16:04 EDT
Subject: .RYEAR and time zones again
Message-ID: <SRA.12232382629.BABYL@XX.LCS.MIT.EDU>

Sorry, I should have made that a formal propoal, bits and all.

Time zones range from +1200 to -1200 (international date line, one day
apart from each other).

The two possible formats would be:

	the five low bits of an integer in the range -12. -> +12.

or
	one sign bit (3.5) and four bits of integer range 0 -> +12.

Only difference is in how you insert/extract it, of course.

From SRA at MC.LCS.MIT.EDU  Wed Aug 20 21:31:28 1986
From: SRA at MC.LCS.MIT.EDU (Rob Austein)
Date: Aug 20 86 15:31:28 EDT
Subject: .RYEAR and time zones
Message-ID: <[MC.LCS.MIT.EDU].73280.860820.SRA>

It would be nice if programs didn't have to have hardwired knowledge
of what time zone they are in (yes, I know, all ITS machines are at MIT
and thus in time zone -0500, but we're trying to be evangelical, here,
right?).

Bits 3.5 -> 3.1 of the result from .RYEAR are defined as zero.
24. (maxium time zone plus one) is 30 in octal.  Seems a timezone
would fit into those bits very nicely.

Anybody know of anything that would break if this were done?
About the only thing I can think of that this would mess up
would be grossitudes like MOVEI AC, at MEM (ignoring the fact that
HRRZ AC,MEM works just as well).  Does anybody really care
what's in those five zeroed bits?

(No, nothing of vital importance depends on this, it would just make
some code I was writing a little cleaner.)

From DEVON%MX.LCS.MIT.EDU at MC.LCS.MIT.EDU  Sun Aug 17 23:48:54 1986
From: DEVON%MX.LCS.MIT.EDU at MC.LCS.MIT.EDU (Devon S. McCullough)
Date: Aug 17 86 17:48:54 EDT
Subject: No subject
Message-ID: <[MX.LCS.MIT.EDU].941512.860817.DEVON>

Closer examination of my problem controlling my telnet connection to MX
reveals that my logout file on AI is sending telnet IAC DONT TRBIN even
though the MX->AI connection is supdup and not telnet.  The problem is
that the only way I can test for a telnet connection is to look at %TPMTA
because the IAC DO TRBIN in the login file turns off the %TPTEL bit!

I guess the way to tell if you are telnetting or supduping is to first
look at %TPCBS, if it's on you're supdup, if it's off look at %TPMTA
and if it's on you're telnet, otherwise it's unknown but for my purposes
this case doesn't matter.  Maybe the tctyp program should handle this?

From DEVON%MX.LCS.MIT.EDU at MC.LCS.MIT.EDU  Sun Aug 17 23:24:28 1986
From: DEVON%MX.LCS.MIT.EDU at MC.LCS.MIT.EDU (Devon S. McCullough)
Date: Aug 17 86 17:24:28 EDT
Subject: No subject
Message-ID: <[MX.LCS.MIT.EDU].941506.860817.DEVON>

note that BUG^K prompts "to:" but should prompt "to: bug-"

When I log in my init file checks for a telnet connection and
does :imgout 377 375 0 which sends a telnet IAC DO TRBIN so
that the TAC will pass @ characters instead of intercepting them,
and pass the 8th bit so the meta key works from my ann arbor.

it looks like nethopping bereaks this somehow, because after
nethopping to either AI or OZ the TAC stops passing meta bits
and starts to intercept @ characters.

	--Devon

From DEVON%MX.LCS.MIT.EDU at MC.LCS.MIT.EDU  Sun Aug 17 22:58:43 1986
From: DEVON%MX.LCS.MIT.EDU at MC.LCS.MIT.EDU (Devon S. McCullough)
Date: Aug 17 86 16:58:43 EDT
Subject: No subject
Message-ID: <[MX.LCS.MIT.EDU].941505.860817.DEVON>

I tried nethopping from

From CENT at AI.AI.MIT.EDU  Tue Aug  5 11:10:49 1986
From: CENT at AI.AI.MIT.EDU (Pandora B. Berman)
Date: Tue,  5 Aug 86 05:10:49 EDT
Subject: TU40 resurrection
Message-ID: <[AI.AI.MIT.EDU].79588.860805.CENT>

lester found another instance of the right drive belt somewhere, and even
installed it, so MX's tape drive works again. thanks, lester.

this means we can again read and write 800bpi 7track tapes. however, we
shouldn't WRITE any, because we can't read them anywhere else. i have run
an incremental dump of MX over the net, using Gut's drive (1600 bpi
9track). this causes a few non-fatal errors on the MX end but apparently
works (see system log). any future dumps of MX should be done this way;
i'll do them, or other interested parties (ty?) can ask how. it's only a
little more complicated than dumping to the local drive.

all old incremental tapes for MX are hereby retired and should only be used
to read off of. i have started a new set of incremental tapes at 375 (so
will not overwrite older tape data). all 1600bpi LCS ITS tapes are now on
the rack by the dover. i will try to run a full dump soon. we should get on
with the project of copying the GFR tapes, and then (if possible) proceed
forward into the past, copying full dumps as we go.