5-Jan-2002 01:23:12 -0800,1996;000000000020
Return-Path: <MRC@Panda.COM>
Received: via tmail-4.1(11) (invoked by user mrc) for t20arc; Sat, 5 Jan 2002 01:23:11 -0800 (PST)
Date: Sat, 5 Jan 2002 01:09:47 -0800 (PST)
From: Mark Crispin <MRC@Panda.COM>
Sender: Mark Crispin <mrc@Ikkoku-Kan.Panda.COM>
Subject: TOPS-20 release 7 bug in GTHST% definitions
To: TOPS-20 Hackers and Yackers <TOPS-20@Panda.COM>
Message-ID: <MailManager.1010221787.11959.mrc@Ikkoku-Kan.Panda.COM>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Edit 9155 to TOPS-20, part of the TSU tape, added some additional GTHST%
functions. Unfortunately, it also duplicated a symbol. .GTHLN is both the
GTHST% function to get the local number on a network and the offset for the
argument block length for the .GTHMX function.
The idea was to be compatible with the .GTDMX function of GTDOM%, which calls
that offset .GTDLN
This breaks Stanford FTP; routine TCDNSK in TCPDAT.MAC is unable to build a
correct port specification because it gets the wrong value for the local host
address.
Since the "get local number on a network" function used .GTHLN first, I
decided to rename the argument block length offet for .GTHMX to be .GTHML
instead. This necessitates changes both to MONSYM.MAC and to MNETDV.MAC.
In MONSYM.MAC:
IFE PANDASW,< ;[2]
.GTHLN==:0 ;[9155] Length of argument block in words
>;IFE PANDASW
IFN PANDASW,< ;[2]
.GTHML==:0 ;[9155] Length of argument block in words
>;IFN PANDASW
In MNETDV.MAC:
GTHRMX: UMOVE Q2,4 ;[9156] Load the user's AC4
IFE PANDASW,< ;[3]
UMOVE Q3,.GTHLN(Q2) ;[9156] Load the user's arg block length
>;IFE PANDASW
IFN PANDASW,< ;[3]
UMOVE Q3,.GTHML(Q2) ;[9156] Load the user's arg block length
>;IFN PANDASW
. . .
IFE PANDASW,< ;[3]
UMOVEM P3,.GTHLN(Q2) ;[9156] Store number of words used in block
>;IFE PANDASW
IFN PANDASW,< ;[3]
UMOVEM P3,.GTHML(Q2) ;[9156] Store number of words used in block
>;IFN PANDASW
RETSKP ;[9156] Skip return
5-Jan-2002 01:36:05 -0800,1992;000000000020
Return-Path: <MRC@Panda.COM>
Received: via tmail-4.1(11) (invoked by user mrc) for t20arc; Sat, 5 Jan 2002 01:36:05 -0800 (PST)
Date: Sat, 5 Jan 2002 01:23:08 -0800 (PST)
From: Mark Crispin <MRC@Panda.COM>
Sender: Mark Crispin <mrc@Ikkoku-Kan.Panda.COM>
Subject: DECnet Y2K and Y2001 bugs
To: TOPS-20 Hackers and Yackers <TOPS-20@Panda.COM>
Message-ID: <MailManager.1010222588.11959.mrc@Ikkoku-Kan.Panda.COM>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Most of TOPS-20 is fine with Y2K. However, DECnet breaks.
The first problem I discovered is that routine NMXTIM issues NMXTBG bugchks
after 2000, hence this is a Y2001 bug. The silly routine has a table of days
since January 1, 1977, indexed by <current year> - 1982. This table ran out
after 2000. What's worse, even though it recognizes that there is a problem
it just reads off the end of the table!
You can expand the YEARTB table, but the right thing to do is to get rid of it
entirely since TOPS-20 is perfectly capable of calculating Julian days without
it. Ralph Gorin at XKL wrote a fix that accomplishs this.
Another problem that I discovered is that NFT/FAL breaks. Some baby
programmer decided that dates should be an 18-byte fixed width field, which
just happens to be exactly "dd-mmm-yy hh:mm:ss" even though the comments claim
that it is "dd-mm-yyyy hh:mm". The lie is further exposed by the fact that
collects this string into a buffer and insists that seconds be specified.
I fought with the code at some length, but I don't know enough about DECnet
protocols to know if I could safely expand the date field. What I ended up
doing was recognize "dd-mm-yyyy hh:mm:" and if so erase the trailing colon and
don't insist upon seconds.
I don't think that anybody (except for VMS groupies) cares about DECnet these
days. I mostly did it as an exercise to see if it still worked (although
PHONE is a neat hack and it requires a monitor with DECnet support).
6-Jan-2002 02:31:03 -0800,2859;000000000020
Return-Path: <bqt@update.uu.se>
Received: via tmail-4.1(11) for t20arc; Sun, 6 Jan 2002 02:31:03 -0800 (PST)
Received: from Tempo.Update.UU.SE (root@Tempo.Update.UU.SE [130.238.19.17]) by Tomobiki-Cho.CAC.Washington.EDU; Sun, 06 Jan 2002 02:29:47 PST
Received: from Tempo.Update.UU.SE (bqt@localhost [127.0.0.1])
by Tempo.Update.UU.SE (8.12.1/8.12.1/Update-Iltempogigante) with ESMTP id g06AQjxe005501;
Sun, 6 Jan 2002 11:26:45 +0100
Received: from localhost (bqt@localhost)
by Tempo.Update.UU.SE (8.12.1/8.12.1/Update-Iltempogigante-submit) with ESMTP id g06AQjgh005497;
Sun, 6 Jan 2002 11:26:45 +0100
X-Authentication-Warning: Tempo.Update.UU.SE: bqt owned process doing -bs
Date: Sun, 6 Jan 2002 11:26:44 +0100 (CET)
From: Johnny Billquist <bqt@update.uu.se>
To: Mark Crispin <MRC@panda.com>
cc: TOPS-20 Hackers and Yackers <TOPS-20@panda.com>
Subject: Re: DECnet Y2K and Y2001 bugs
In-Reply-To: <MailManager.1010222588.11959.mrc@Ikkoku-Kan.Panda.COM>
Message-ID: <Pine.LNX.4.21.0201061107030.21663-100000@Tempo.Update.UU.SE>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
On Sat, 5 Jan 2002, Mark Crispin wrote:
> Most of TOPS-20 is fine with Y2K. However, DECnet breaks.
Yep. This was discovered in RSX a few years ago, and DECnet was made
Y2K-certified.
> Another problem that I discovered is that NFT/FAL breaks. Some baby
> programmer decided that dates should be an 18-byte fixed width field, which
> just happens to be exactly "dd-mmm-yy hh:mm:ss" even though the comments claim
> that it is "dd-mm-yyyy hh:mm". The lie is further exposed by the fact that
> collects this string into a buffer and insists that seconds be specified.
Here is what I read out of the release notes for DECnet-RSX.
The DAP specification says that years are in the range 1970-2069. So 00
means 2000, not 1900.
> I fought with the code at some length, but I don't know enough about DECnet
> protocols to know if I could safely expand the date field. What I ended up
> doing was recognize "dd-mm-yyyy hh:mm:" and if so erase the trailing colon and
> don't insist upon seconds.
Perhaps you should do it like RSX?
I would suspect VMS does it that way too, but I haven't really checked.
> I don't think that anybody (except for VMS groupies) cares about DECnet these
> days. I mostly did it as an exercise to see if it still worked (although
> PHONE is a neat hack and it requires a monitor with DECnet support).
PHONE is nice. Oh, have you seen about my HECnet
project? (http://www.update.uu.se/~bqt/hecnet.html)
Care to join? :-)
Johnny
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt@update.uu.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
6-Jan-2002 14:46:38 -0800,1241;000000000020
Return-Path: <mrc@Panda.COM>
Received: via tmail-4.1(11) (invoked by user mrc) for t20arc; Sun, 6 Jan 2002 14:46:38 -0800 (PST)
Date: Sun, 6 Jan 2002 14:46:16 -0800 (PST)
From: Mark Crispin <mrc@Panda.COM>
To: Johnny Billquist <bqt@update.uu.se>
cc: TOPS-20 Hackers and Yackers <TOPS-20@panda.com>
Subject: Re: DECnet Y2K and Y2001 bugs
In-Reply-To: <Pine.LNX.4.21.0201061107030.21663-100000@Tempo.Update.UU.SE>
Message-ID: <Pine.NXT.4.43.0201061440200.22750-100000@Ikkoku-Kan.Panda.COM>
Organization: Pandamonium Reigns
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
On Sun, 6 Jan 2002, Johnny Billquist wrote:
> Here is what I read out of the release notes for DECnet-RSX.
> The DAP specification says that years are in the range 1970-2069. So 00
> means 2000, not 1900.
Simply unbelievable. What were these baby programmers thinking?
> Perhaps you should do it like RSX?
I've just done so. If a TOPS-20 system ever has to talk DECnet to
something else it'll need to be compatible with it, and the last vestiges
of DECnet should be dead by 2070.
> Oh, have you seen about my HECnet
> project? (http://www.update.uu.se/~bqt/hecnet.html)
No I haven't, but I'll take a look
-- Mark --
7-Jan-2002 00:41:05 -0800,2319;000000000020
Return-Path: <bqt@update.uu.se>
Received: via tmail-4.1(11) for t20arc; Mon, 7 Jan 2002 00:41:05 -0800 (PST)
Received: from Tempo.Update.UU.SE (root@Tempo.Update.UU.SE [130.238.19.17]) by Tomobiki-Cho.CAC.Washington.EDU; Mon, 07 Jan 2002 00:40:03 PST
Received: from Tempo.Update.UU.SE (bqt@localhost [127.0.0.1])
by Tempo.Update.UU.SE (8.12.1/8.12.1/Update-Iltempogigante) with ESMTP id g078c0xe032668;
Mon, 7 Jan 2002 09:38:00 +0100
Received: from localhost (bqt@localhost)
by Tempo.Update.UU.SE (8.12.1/8.12.1/Update-Iltempogigante-submit) with ESMTP id g078c04N032664;
Mon, 7 Jan 2002 09:38:00 +0100
X-Authentication-Warning: Tempo.Update.UU.SE: bqt owned process doing -bs
Date: Mon, 7 Jan 2002 09:37:59 +0100 (CET)
From: Johnny Billquist <bqt@update.uu.se>
To: Mark Crispin <mrc@panda.com>
cc: TOPS-20 Hackers and Yackers <TOPS-20@panda.com>
Subject: Re: DECnet Y2K and Y2001 bugs
In-Reply-To: <Pine.NXT.4.43.0201061440200.22750-100000@Ikkoku-Kan.Panda.COM>
Message-ID: <Pine.LNX.4.21.0201070932390.21663-100000@Tempo.Update.UU.SE>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
On Sun, 6 Jan 2002, Mark Crispin wrote:
> On Sun, 6 Jan 2002, Johnny Billquist wrote:
> > Here is what I read out of the release notes for DECnet-RSX.
> > The DAP specification says that years are in the range 1970-2069. So 00
> > means 2000, not 1900.
>
> Simply unbelievable. What were these baby programmers thinking?
Beats me. Some of DECnet is pretty nice, and some stuff is just horrible.
> > Perhaps you should do it like RSX?
>
> I've just done so. If a TOPS-20 system ever has to talk DECnet to
> something else it'll need to be compatible with it, and the last vestiges
> of DECnet should be dead by 2070.
Probably.
I'll also be retired when Unix wraps the time...
Atleast the core parts of RSX won't break until a bit into the 35th
millenium.
> > Oh, have you seen about my HECnet
> > project? (http://www.update.uu.se/~bqt/hecnet.html)
>
> No I haven't, but I'll take a look
Do that. :-)
Johnny
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt@update.uu.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
7-Jan-2002 07:44:34 -0800,4170;000000000020
Return-Path: <jzj@ornl.gov>
Received: via tmail-4.1(11) for t20arc; Mon, 7 Jan 2002 07:44:33 -0800 (PST)
Received: from exchange4.y12.doe.gov (exchange4.y12.doe.gov [134.167.250.68]) by Tomobiki-Cho.CAC.Washington.EDU; Mon, 07 Jan 2002 07:43:15 PST
Received: from 127.0.0.1 by exchange4.y12.doe.gov (InterScan E-Mail VirusWall NT); Mon, 07 Jan 2002 10:21:16 -0500
Received: by exchange4.y12.doe.gov with Internet Mail Service (5.5.2653.19)
id <Y0H6533S>; Mon, 7 Jan 2002 10:21:15 -0500
Message-ID: <4E5056859D3FD4119CDD00508B6FE62B0D710882@exchange1.ctd.ornl.gov>
From: "Jones, Jeffrey A. (JZJ) " <jzj@ornl.gov>
To: "'Mark Crispin'" <MRC@panda.com>,
TOPS-20 Hackers and Yackers
<TOPS-20@panda.com>
Subject: RE: DECnet Y2K and Y2001 bugs
Date: Mon, 7 Jan 2002 10:21:14 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
charset="iso-8859-1"
For NFT/FAL, I hit this problem on 1/1/2000. The two TOPS-20 systems ran
normally but file transfers between themselves and some VMS systems were
failing.
I modified the DECnet code to hack around the problem (yes, I saw the bogus
comment too). Because of the transfers to the VMS systems, I didn't want to
mess with the date format passed so I kept the 2-digit year, but inserted
code in two different places in DAPLIB to say if the year was 00-49, assume
that the year is 2000-2049. If the year was 50-99, assume that the year is
1950-1999. The break at 1950 was arbitrarily chosen, but I wanted to use a
year I knew was before the start of development of any of the 36-bit OS so
as to not get into any date problems with old files from OS'es previous to
TOPS-20. Of course, this meant that the code would break again at 2049, but
(1) the systems would be shutdown by then (actually, they were shutdown
July, 2001), and (2) I would be retired.
This worked great for 2 months, but on 2/29/2000, the problem reoccurred.
One of the date/time monitor calls I used (sorry, I can't remember the exact
one) has a Y2K problem still present which flagged 2/29/2000 as an invalid
date. Once again the NFT/FAL transfers began to fail. The problem was not
reported until ~3pm on 2/29/2000 and after some evaluation, the decision was
made to live with the problem the rest of the day. The file transfers
completed successfully the next day and continued to complete successfully
until the systems were shutdown.
Jeff
-----Original Message-----
From: Mark Crispin [mailto:MRC@Panda.COM]
Sent: Saturday, January 05, 2002 4:23 AM
To: TOPS-20 Hackers and Yackers
Subject: DECnet Y2K and Y2001 bugs
Most of TOPS-20 is fine with Y2K. However, DECnet breaks.
The first problem I discovered is that routine NMXTIM issues NMXTBG bugchks
after 2000, hence this is a Y2001 bug. The silly routine has a table of
days
since January 1, 1977, indexed by <current year> - 1982. This table ran out
after 2000. What's worse, even though it recognizes that there is a problem
it just reads off the end of the table!
You can expand the YEARTB table, but the right thing to do is to get rid of
it
entirely since TOPS-20 is perfectly capable of calculating Julian days
without
it. Ralph Gorin at XKL wrote a fix that accomplishes this.
Another problem that I discovered is that NFT/FAL breaks. Some baby
programmer decided that dates should be an 18-byte fixed width field, which
just happens to be exactly "dd-mmm-yy hh:mm:ss" even though the comments
claim
that it is "dd-mm-yyyy hh:mm". The lie is further exposed by the fact that
collects this string into a buffer and insists that seconds be specified.
I fought with the code at some length, but I don't know enough about DECnet
protocols to know if I could safely expand the date field. What I ended up
doing was recognize "dd-mm-yyyy hh:mm:" and if so erase the trailing colon
and
don't insist upon seconds.
I don't think that anybody (except for VMS groupies) cares about DECnet
these
days. I mostly did it as an exercise to see if it still worked (although
PHONE is a neat hack and it requires a monitor with DECnet support).
7-Jan-2002 14:36:56 -0800,3172;000000000020
Return-Path: <MRC@Panda.COM>
Received: via tmail-4.1(11) (invoked by user mrc) for t20arc; Mon, 7 Jan 2002 14:36:56 -0800 (PST)
Date: Mon, 7 Jan 2002 13:58:10 -0800 (PST)
From: Mark Crispin <MRC@Panda.COM>
Sender: Mark Crispin <mrc@Ikkoku-Kan.Panda.COM>
Subject: RE: DECnet Y2K and Y2001 bugs
To: "Jones, Jeffrey A. (JZJ) " <jzj@ornl.gov>
cc: TOPS-20 Hackers and Yackers <TOPS-20@panda.com>
In-Reply-To: <4E5056859D3FD4119CDD00508B6FE62B0D710882@exchange1.ctd.ornl.gov>
Message-ID: <MailManager.1010440690.11959.mrc@Ikkoku-Kan.Panda.COM>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
On Mon, 7 Jan 2002 10:21:14 -0500 , Jones, Jeffrey A. (JZJ) wrote:
> Because of the transfers to the VMS systems, I didn't want to
> mess with the date format passed so I kept the 2-digit year, but inserted
> code in two different places in DAPLIB to say if the year was 00-49, assume
> that the year is 2000-2049.
Yup, that's what I ended up doing, only I used 2000-2069 and 1970-1999 since
allegedly that's what the NFT specification says.
> This worked great for 2 months, but on 2/29/2000, the problem reoccurred.
> One of the date/time monitor calls I used (sorry, I can't remember the exact
> one) has a Y2K problem still present which flagged 2/29/2000 as an invalid
> date.
If you can remember what call it was, I'd like to fix it.
I checked the various time calls, and as far as I could tell they all know
that February 29, 2000 is a real day. One possible source of confusion is
that the "separate numbers" used by IDCNV%, ODCNV%, IDTNC%, and ODTNC% are 0-
origin for the month and day; and the day of week is 0-origin starting at
Monday. Hence a correct call for ODTNC% of February 29, 2000 is:
MOVX 1,.PRIOU
DMOVE 2,[^D2000,,1 ; not ^D2000,,2
^D28,,1] ; not ^D29,,2
SETZB 4,5
ODTNC%
It's easy to think of the month as being 0-origin, but it's quite strange to
think of the day as also being 0 origin. However, if you had that kind of
bug, your code would probably crack on the last day of every month.
Also note that TOPS-20 considers the two-digit year 00 as 1900, so 29-FEB-00
*is* invalid. This means that you can't use the TOPS-20 time monitor calls to
parse that.
So, what I did in DAPLIB is as follows:
1) If the 18-character date/time string looks like "dd-mmm-yyyy hh:mm:", then
delete the final colon and allow time parse without seconds.
2) Otherwise (the string looks like "dd-mmm-yy hh:mm:ss"), look at the first
character of yy. If it is less than "7", convert the string into
"dd-mmm-20yy hh:mm:ss" before parsing.
3) Otherwise, parse as "dd-mm-yy hh:mm:ss".
For output, I had to fix DAPLIB not to write the bogus "dd-mmm-yyyy hh:mm:"
format. Since the truncation of the seconds was done by DAPLIB copying only
18 characters from what ODTIM% wrote, all I had to do was change the copy code
to check what format the year was in. If it is a "yyyy" format year, don't
copy the first two digits of yyyy.
This is, indeed, wrong, since it generates "29-FEB-00" which IDTIM% can not
parse, and it fails after 2069. But it's compatible with VMS.
7-Jan-2002 16:30:18 -0800,1571;000000000020
Return-Path: <dlm@lap.opost.com>
Received: via tmail-4.1(11) for t20arc; Mon, 7 Jan 2002 16:30:18 -0800 (PST)
Received: from ns.opost.com (root@ns.opost.com [207.22.41.1]) by mercury.mv.net (8.8.8/mem-971025) with ESMTP id LAA16077 for <TOPS-20@panda.com>; Mon, 7 Jan 2002 11:00:24 -0500 (EST)
Received: from lap.opost.com (HZw3toB8KqDplRnaTzNdsAcLy27wBB5G@lap.opost.com [207.22.41.4])
by ns.opost.com (8.8.7/8.8.7) with ESMTP id LAA19827
for <TOPS-20@panda.com>; Mon, 7 Jan 2002 11:00:20 -0500
Received: (from dlm@localhost)
by lap.opost.com (8.11.6/8.11.6) id g07G0KT07338
for TOPS-20@panda.com; Mon, 7 Jan 2002 11:00:20 -0500
Date: Mon, 7 Jan 2002 11:00:20 -0500
Message-Id: <200201071600.g07G0KT07338@lap.opost.com>
From: Dan Murphy <dlm@opost.com>
To: TOPS-20@panda.com
Subject: DECtapes anyone?
Reply-To: Dan Murphy <dlm@opost.com>
----- Original Message -----
From: "Peter Kaiser" <kaiser@acm.org>
To: <ninaeppes@mediaone.net>
Sent: Monday, January 07, 2002 3:44 AM
Subject: Urgent news!
Nina, please disseminate this as widely and quickly as possible to the
places you consider most relevant:
Pusterla Electronics, in Zurich just one short block
from Helvetiaplatz, is selling DECtapes for only
2 Swiss francs apiece.
Get 'em while they're hot! I'll take purchase commissions by arrangement,
no kidding.
___Pete
kaiser@acm.org
PS Perhaps the news became garbled on its way to Europe, but did I hear
correctly that the proposed software for America's planned missile defense
now contains a talking paper clip?
8-Jan-2002 17:07:59 -0800,2841;000000000020
Return-Path: <MRC@Panda.COM>
Received: via tmail-4.1(11) (invoked by user mrc) for t20arc; Tue, 8 Jan 2002 17:07:59 -0800 (PST)
Date: Tue, 8 Jan 2002 17:07:46 -0800 (PST)
From: Mark Crispin <MRC@Panda.COM>
Sender: mrc@Tomobiki-Cho.CAC.Washington.EDU
To: TOPS-20 Hackers and Yackers <TOPS-20@Panda.COM>
Subject: get your 9 track tapes now (fwd)
Message-ID: <Pine.NXT.4.50.0201081704280.29429-100000@Tomobiki-Cho.CAC.Washington.EDU>
Organization: Networks & Distributed Computing
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
[The end of an era...]
http://www.emaglink.com/Articles/17Dec01.htm
Atlanta (December 17, 2001) - eMag, the last manufacturer of open reel
(9-track) tape, is announcing its end of life program for users of
this product. eMag, which has produced open reel (9-track) tape in its
Graham, Texas facility for over 30 years, has determined that the
significantly decreased demand for this once dominant magnetic media
format mandates an organized end of life announcement and program. To
provide an orderly and seamless transition for users of open reel
(9-track) tape technology, we have spent over 3 years developing
alternative solutions that have proven to be both operationally
efficient and cost effective. For a more detailed description of
eMag's alternatives please visit 9-track Retirement.
Final Orders
In order to properly prepare for our final build of this product, eMag
will review and accept final orders for open reel (9-track) tape now,
and through January 14, 2002.
We will prioritize shipments for firm non-cancelable orders, on a
first come first served basis, consistent with our existing inventory
and final manufacturing run and plant capacity. eMag will not
manufacture new open reel (9-track) tape after these final orders are
completed. To assist you with your needs and answer any questions,
eMag has designated experienced program managers in the United States
and Europe to oversee this end of life program. Please direct all
orders, and other inquiries to them at:
USA
Scott Gaylord
Vice President
404-995-6022
sgaylord@emaglink.com
Europe, Middle East and Africa
Mark Stephens
Vice President
44-1495-311000
mstephens@emaglink.co.uk
About eMag Solutions
eMag Solutions is an international organization, headquartered in
Atlanta, Georgia. Our European operations are based in Brynmawr, UK,
and there are more the 200 employees worldwide. Thirty years of
success working in data center environments has created a team of
expert and experienced professionals, with unparalleled knowledge of
data media, its capability, application and potential which has
allowed us to develop additional strategic relationships to ensure
that our clients have access to the best data storage solutions
available.
30-Jan-2002 23:35:57 -0800,644;000000000020
Return-Path: <mrc@Panda.COM>
Received: via tmail-4.1(11) (invoked by user mrc) for t20arc; Wed, 30 Jan 2002 23:35:57 -0800 (PST)
Date: Wed, 30 Jan 2002 23:35:52 -0800 (PST)
From: Mark Crispin <mrc@Panda.COM>
To: TOPS-20 Hackers and Yackers <TOPS-20@Panda.COM>
Subject: web page for the TOPS-20 list
Message-ID: <Pine.NXT.4.43.0201302333470.2805-100000@Ikkoku-Kan.Panda.COM>
Organization: Pandamonium Reigns
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
I have created a web page for the TOPS-20 list:
http://www.panda.com/tops-20
There isn't much there yet, but there's a few amusing documents.
-- Mark --
4-Feb-2002 02:14:20 -0800,1450;000000000020
Return-Path: <MRC@lingling.panda.com>
Received: via tmail-4.1(11) for t20arc; Mon, 4 Feb 2002 02:14:19 -0800 (PST)
Date: Mon, 4 Feb 2002 02:14:13 -0800 (PST)
From: Mark Crispin <MRC@lingling.panda.com>
Subject: a big hello to the TOPS-20 list from a new TOPS-20 system!!
To: tops-20@panda.com
Message-ID: <13712602310.9.MRC@lingling.panda.com>
Yes, boys and girls, lingling.panda.com is up and running, and is sending you
all its first email message. Lingling benchmarks at 30,000 dhrystones/second,
which makes it 70 times faster than a 2020, about 30 times faster than a 2060,
and about 11 times faster than a Toad-1. Lingling currently has a single
RP07-equivalent PS, but more disk structures will be added (the underlying
hardware has 40GB).
Thanks to:
Ken Harrenstein for writing KLH10.
Tim Shoppa for preserving so many PDP-10 tapes and making their contents
available on CD-ROM and over the Internet.
Ralph Gorin and everybody else at XKL, who read in my last backup tapes after
my 2020's main PS head crashed, and allowed me to freeload disk space for so
long.
Frank Wancho, for helping to keep the dream alive.
Before everybody asks, I have *not* decided upon a guest account policy. The
Internet is a much more hostile place today than it was in the halcyon days
of SU-SCORE 20 years ago, as I learned to my dismay when I (briefly!) turned
on an anonymous FTP server on my UNIX workstation.
-------
4-Feb-2002 08:46:44 -0800,1454;000000000020
Return-Path: <clive.dawson@amd.com>
Received: via tmail-4.1(11) for t20arc; Mon, 4 Feb 2002 08:46:44 -0800 (PST)
Received: from amdext2.amd.com (amdext2.amd.com [163.181.251.1]) by Ikkoku-Kan.Panda.COM; Mon, 04 Feb 2002 08:46:13 PST
Received: from sausgs01.amd.com (sausgs01.amd.com [163.181.250.16])
by amdext2.amd.com (8.9.3/8.9.3/AMD) with SMTP id KAA28886;
Mon, 4 Feb 2002 10:44:56 -0600 (CST)
Received: from 163.181.250.1 by sausgs01.amd.com with ESMTP (Tumbleweed
MMS SMTP Relay (MMS v4.7)); Mon, 04 Feb 2002 10:44:55 -0600
X-Server-Uuid: 18a6aeba-11ae-11d5-983c-00508be33d6d
Received: from hendrix.amd.com (hendrix.amd.com [163.181.10.12]) by
amdint2.amd.com (8.9.3/8.9.3/AMD) with ESMTP id KAA27640; Mon, 4 Feb
2002 10:44:55 -0600 (CST)
Received: (from clive@localhost) by hendrix.amd.com (8.9.3/8.9.3) id
KAA22327; Mon, 4 Feb 2002 10:43:41 -0600 (CST)
Date: Mon, 4 Feb 2002 10:43:41 -0600 (CST)
Message-ID: <200202041643.KAA22327@hendrix.amd.com>
From: "Clive Dawson" <clive.dawson@amd.com>
To: MRC@lingling.panda.com
cc: tops-20@panda.com
In-Reply-To: <13712602310.9.MRC@lingling.panda.com>
Subject: Re: a big hello to the TOPS-20 list from a new TOPS-20 system!!
MIME-Version: 1.0
X-WSS-ID: 1040650D2294447-01-01
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
Congrats, Mark!
So please give us some more details on the underlying HW/SW platform, what
mail system you're running, etc.
Clive
4-Feb-2002 10:07:52 -0800,2565;000000000020
Return-Path: <MRC@lingling.panda.com>
Received: via tmail-4.1(11) for t20arc; Mon, 4 Feb 2002 10:07:51 -0800 (PST)
Date: Mon, 4 Feb 2002 10:07:43 -0800 (PST)
From: Mark Crispin <MRC@lingling.panda.com>
Subject: Re: a big hello to the TOPS-20 list from a new TOPS-20 system!!
To: clive.dawson@amd.com
cc: tops-20@panda.com
In-Reply-To: <200202041643.KAA22327@hendrix.amd.com>
Message-ID: <13712688509.8.MRC@lingling.panda.com>
So please give us some more details on the underlying HW/SW platform, what
mail system you're running, etc.
It's a military secret! :-)
Lingling's hardware is a 1700 MHz Athlon (this should please
Clive!), with 40GB hard drive 56x CD-ROM, Intel 10/100MHz
Ethernet card. The microcode/front-end operating system is
Gibraltar, a secure diskless Linux based upon Debian. Gibraltar
is being developed in Austria as part of a commercial firewall
product; however, the underlying Linux itself is free. Gibraltar
runs entirely from CD-ROM, storing only a small amount of
configuration on a floppy (which can be write locked since it's
only updated manually), and uses RAM disks created at boot time.
The microcode is the standard Linux version of KLH10, which runs
the dhrystone benchmark in PDP-10 instructions about 40 times
slower than micromachine Intel instructions (which is excellent
performance; 100 times slower is more typical). Separate
microcode engines provide TU45, RP07, and NI20 services.
I challenge purists, who claim that this is an "emulation on a
Linux system", to come up with a real difference with a KL10 or
KS10. Neither the KL10 nor the KS10 hardware were capable of
executing any PDP-10 instructions; it was all in microcode.
Lingling is undeniably running TOPS-20, the TCP is TOPS-20 TCP,
etc.
I'm surprised that Clive (or anyone else) has to ask what
mailsystem it's running. Of course, it is MMAILR! However,
MAISER (the SMTP server) has been updated so it is no longer an
open relay (thank you, spammers). I actually did that work some
time ago, to close the open relays at XKL and Peter Lothberg's
systems.
This message is being entered using good old MM, although I
should give some serious thought to a TOPS-20 port of Pine. The
c-client library already builds quite well on TOPS-20, but
getting Pine and Pico to build may be more of a problem.
Pine on UNIX is still capable of talking down to the TOPS-20 IMAP
server, but either the latter needs to be updated to IMAP4 or I
should just replace it with imapd.
-- Mark --
-------
4-Feb-2002 10:56:01 -0800,1365;000000000020
Return-Path: <billw@cisco.com>
Received: via tmail-4.1(11) for t20arc; Mon, 4 Feb 2002 10:56:01 -0800 (PST)
Received: from cisco.com (cypher.cisco.com [171.69.11.18]) by Ikkoku-Kan.Panda.COM; Mon, 04 Feb 2002 10:55:35 PST
Received: (from billw@localhost)
by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) id KAA22237;
Mon, 4 Feb 2002 10:54:08 -0800 (PST)
Sender: Bill Westfield <billw@cisco.com>
Date: Mon, 4 Feb 2002 10:54:08 PST
From: William "Chops" Westfield <billw@cisco.com>
Reply-To: Bill Westfield <billw@cisco.com>
To: Mark Crispin <MRC@lingling.panda.com>
Cc: clive.dawson@amd.com, tops-20@panda.com
Subject: Re: a big hello to the TOPS-20 list from a new TOPS-20 system!!
In-Reply-To: Your message of Mon, 4 Feb 2002 10:07:43 -0800 (PST)
Message-ID: <CMM.0.90.4.1012848848.billw@cypher>
The microcode is the standard Linux version of KLH10, which runs
the dhrystone benchmark in PDP-10 instructions about 40 times
slower than micromachine Intel instructions (which is excellent
performance; 100 times slower is more typical). Separate
microcode engines provide TU45, RP07, and NI20 services.
Hmm. So what benchmarks exist to compare overall system performance
between something like KLH10 and a "real" KL10? Set up those guest
accounts, Mark, and we'll see how well it handles 100 users :-)
BillW
4-Feb-2002 17:26:33 -0800,903;000000000020
Return-Path: <MRC@lingling.panda.com>
Received: via tmail-4.1(11) for t20arc; Mon, 4 Feb 2002 17:26:33 -0800 (PST)
Date: Mon, 4 Feb 2002 17:26:20 -0800 (PST)
From: Mark Crispin <MRC@lingling.panda.com>
Subject: Lingling performance
To: tops-20@panda.com
Message-ID: <13712768355.8.MRC@lingling.panda.com>
Lingling just built the entire TOPS-20 monitor from sources in 16 minutes,
33 seconds of CPU time (16 minutes, 50 seconds wall clock time). I think
that we can conclude that this is a fast PDP-10. :-)
One unpleasant thing that I discovered is that Linux doesn't always play
nice with bleeding edge hardware. The unfortunate consequences of an
IDE chipset that is too new for one's version of Linux is a corrupted
filesystem (and if the UNIX filesystem is corrupted you can just imagine
what it does to the PDP-10 filesystem). I think that I've tamed the beast
now.
-------
4-Feb-2002 18:06:34 -0800,1789;000000000020
Return-Path: <dempster@us.fornax.com>
Received: via tmail-4.1(11) for t20arc; Mon, 4 Feb 2002 18:06:33 -0800 (PST)
Received: from us.fornax.com (Joe-PC.US.Fornax.COM [206.67.177.139])
by US.Fornax.COM (8.11.1/8.11.1) with ESMTP id g151TcK18713;
Mon, 4 Feb 2002 20:29:38 -0500 (EST)
Message-ID: <3C5F3518.6773C90A@us.fornax.com>
Date: Mon, 04 Feb 2002 20:27:53 -0500
From: Joe Dempster <dempster@US.Fornax.COM>
X-Mailer: Mozilla 4.77 [en] (Win95; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Mark Crispin <MRC@lingling.panda.com>
CC: Bill Westfield <billw@cisco.com>, clive.dawson@amd.com, tops-20@panda.com,
beiben@bigfoot.com
Subject: Re: a big hello to the TOPS-20 list from a new TOPS-20 system!!
References: <CMM.0.90.4.1012848848.billw@cypher>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
William Chops Westfield wrote:
> The microcode is the standard Linux version of KLH10, which runs
> the dhrystone benchmark in PDP-10 instructions about 40 times
> slower than micromachine Intel instructions (which is excellent
> performance; 100 times slower is more typical). Separate
> microcode engines provide TU45, RP07, and NI20 services.
>
> Hmm. So what benchmarks exist to compare overall system performance
> between something like KLH10 and a "real" KL10? Set up those guest
> accounts, Mark, and we'll see how well it handles 100 users :-)
Mark...
This sounds like a job for a weekend afternoon. I vote for bringing
back the lcg.kermit account, open it up to the world, place some files
in the directory and see what this puppy can do. Even if your machine
is at the end of a cable modem link, it must be faster than the area 10
link into Marlboro at 56K.
/joe
4-Feb-2002 22:32:03 -0800,805;000000000020
Return-Path: <MRC@lingling.panda.com>
Received: via tmail-4.1(11) for t20arc; Mon, 4 Feb 2002 22:32:03 -0800 (PST)
Date: Mon, 4 Feb 2002 22:31:58 -0800 (PST)
From: Mark Crispin <MRC@lingling.panda.com>
Subject: it's even faster than I reported
To: tops-20@panda.com
Message-ID: <13712823996.8.MRC@lingling.panda.com>
I discovered that I had the CPU clock set wrong in the BIOS. After fixing
that, it builds the TOPS-20 monitor from scratch in a screaming 12 minutes
and 26 seconds. And mind you, this is TOPS-20 7.0, with all the CFS and
DECnet phase IV stuff in it.
Man! A fast PDP-10 is nice to have!
Only problem is, my fingers are unlearning all the Unix commands they've been
forced to recite in the past 13+ years, and going back to their old TOPS-20
habits... :-)
-------
5-Feb-2002 07:52:18 -0800,2456;000000000020
Return-Path: <ji@research.att.com>
Received: via tmail-4.1(11) for t20arc; Tue, 5 Feb 2002 07:52:18 -0800 (PST)
From: ji@research.att.com
Received: from mail-blue.research.att.com (mail-blue.research.att.com [135.207.30.102]) by Ikkoku-Kan.Panda.COM; Tue, 05 Feb 2002 07:51:18 PST
Received: from amontillado.research.att.com (amontillado.research.att.com [135.207.24.32])
by mail-blue.research.att.com (Postfix) with ESMTP id DF8184CE2F
for <tops-20@panda.com>; Tue, 5 Feb 2002 10:50:09 -0500 (EST)
Received: from bual.research.att.com (bual.research.att.com [135.207.24.19])
by amontillado.research.att.com (8.8.7/8.8.7) with ESMTP id KAA09650
for <tops-20@panda.com>; Tue, 5 Feb 2002 10:50:08 -0500 (EST)
Received: (from ji@localhost)
by bual.research.att.com (8.9.3+Sun/8.9.3) id KAA16060
for tops-20@panda.com; Tue, 5 Feb 2002 10:50:09 -0500 (EST)
Date: Tue, 5 Feb 2002 10:50:09 -0500 (EST)
Message-Id: <200202051550.KAA16060@bual.research.att.com>
To: tops-20@panda.com
Subject: installing TOPS20?
With the recent flurry of messages about TOPS20, I decided to finally
install my own. Small problem: I haven't used it in 13 years (we
decommissioned our '20 in 1988-89), and, while I loved the thing as a
user, I arrived on the scene too late (1985) to be accepted as one of
the local hackers (instead, I became one of the first unix kernel
hackers in the CS department at Columbia, which has served me well
career-wise, but does not get me any closer to installing TOPS20!).
I would just *love* to run a TOPS20 system on a 1GHz PC -- SCRIBE
should fly, and I can resurrect my SCRIBE macros for writing RFCs and
Internet Drafts!
I downloaded KLH10 from klh-10.trailing-edge.com, compiled under
FreeBSD, and brought it up with the twonky disk image, and that was
enough to whet my appetite for more.
So...
I'm in the process of downloading the TOPS20 7.0 files from
www.aracnet.com/~healyzh/pdp10emu.html (the site is slow... if its
owner is reading this: do you want me to mirror it?) but I'm not sure
what to do after that. Any help/handholding/documentation/etc. will
be welcome!
Cheers,
/ji - KC2IER
--
/\ ASCII ribbon | John "JI" Ioannidis * Secure Systems Research Department
\/ campaign | AT&T Labs - Research * Florham Park, NJ 07932 * USA
/\ against | "Intellectuals trying to out-intellectual
/ \ HTML email. | other intellectuals" (Fritz the Cat)
5-Feb-2002 08:14:48 -0800,2681;000000000020
Return-Path: <francini@zk3.dec.com>
Received: via tmail-4.1(11) for t20arc; Tue, 5 Feb 2002 08:14:48 -0800 (PST)
Received: from zmamail05.zma.compaq.com (zmamail05.zma.compaq.com [161.114.64.105]) by Ikkoku-Kan.Panda.COM; Tue, 05 Feb 2002 08:13:35 PST
Received: from mailrelay01.cac.cpqcorp.net (mailrelay01.cac.cpqcorp.net [16.47.132.152])
by zmamail05.zma.compaq.com (Postfix) with ESMTP id BAF7135A8
for <tops-20@panda.com>; Tue, 5 Feb 2002 11:12:28 -0500 (EST)
Received: from anw.zk3.dec.com (alpha.zk3.dec.com [16.140.128.4])
by mailrelay01.cac.cpqcorp.net (Postfix) with ESMTP id 1004DE1D
for <tops-20@panda.com>; Tue, 5 Feb 2002 08:12:28 -0800 (PST)
Received: from [16.140.96.116] by anw.zk3.dec.com (8.9.3/1.1.22.2/08Sep98-0251PM)
id LAA0001430839; Tue, 5 Feb 2002 11:12:23 -0500 (EST)
Mime-Version: 1.0
X-Sender: francini@mailhub.zk3.dec.com
Message-Id: <p0510120bb885b3d20847@[16.140.96.116]>
In-Reply-To: <200202051550.KAA16060@bual.research.att.com>
References: <200202051550.KAA16060@bual.research.att.com>
Date: Tue, 5 Feb 2002 11:12:21 -0500
To: tops-20@panda.com
From: John Francini <francini@zk3.dec.com>
Subject: Re: installing TOPS20?
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
>
>I'm in the process of downloading the TOPS20 7.0 files from
>www.aracnet.com/~healyzh/pdp10emu.html (the site is slow... if its
>owner is reading this: do you want me to mirror it?) but I'm not sure
>what to do after that. Any help/handholding/documentation/etc. will
>be welcome!
Why not pull them from Tim Shoppa's site <http:www.trailing-edge.com> instead?
He's got a faster link, and he's got sets of both TOPS-10 and TOPS-20
tapes, along with a smattering of docs...
SCRIBE, eh? I haven't used that since 1983 when I was working at
Brandeis University (TOPS-10 KL 1090 serial 1288)... Do you know if
there's still a distro existent for TOPS-10?
The speeds that people have been reporting here are _almost_ enough
to convince me to go out and actually (choke, cough, gag) _buy_ a PC
just to run Linux and KLH on. (I'm a Mac and Tru64 UNIX guy
otherwise...)
j
--
John Francini <mailto:francini@zk3.dec.com>
+---------------------------------------------------------------------------+
| "I have come to the conclusion that one useless man is called a disgrace; |
| that two or more are called a law firm; and that three or more become |
| a Congress. And by God I have had _this_ Congress!" |
| -- John Adams in "1776"|
+---------------------------------------------------------------------------+
5-Feb-2002 09:15:30 -0800,1067;000000000020
Return-Path: <billw@cisco.com>
Received: via tmail-4.1(11) for t20arc; Tue, 5 Feb 2002 09:15:30 -0800 (PST)
Received: from cisco.com (cypher.cisco.com [171.69.11.18]) by Ikkoku-Kan.Panda.COM; Tue, 05 Feb 2002 09:15:17 PST
Received: (from billw@localhost)
by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) id JAA25531
for tops-20@panda.com; Tue, 5 Feb 2002 09:14:10 -0800 (PST)
Sender: Bill Westfield <billw@cisco.com>
Date: Tue, 5 Feb 2002 9:14:10 PST
From: William "Chops" Westfield <billw@cisco.com>
Reply-To: Bill Westfield <billw@cisco.com>
Cc: tops-20@panda.com
Subject: Re: installing TOPS20?
In-Reply-To: Your message of Tue, 5 Feb 2002 10:50:09 -0500 (EST)
Message-ID: <CMM.0.90.4.1012929250.billw@cypher>
Hmm. Could someone summarize the state of emulators, source, and object
available for the assorted 36bit CPUs? I know most of the discussion has
been over on usenet's alt.sys.pdp10, but I haven't been keeping up well with
usenet these days. Surely ye old tops20 mailing list deserves periodic
status reports?
Thanks
Bill W
7-Feb-2002 03:20:55 -0800,1659;000000000020
Return-Path: <lars@junk.nocrew.org>
Received: via tmail-4.1(11) for t20arc; Thu, 7 Feb 2002 03:20:55 -0800 (PST)
Received: from junk.nocrew.org (mail@gem.atari.org [213.242.147.30]) by Ikkoku-Kan.Panda.COM; Thu, 07 Feb 2002 03:20:26 PST
Received: from lars by junk.nocrew.org with local (Exim 3.31 #1 (Debian))
id 16YmaD-0000au-00; Thu, 07 Feb 2002 12:19:17 +0100
To: tops-20@panda.com
Cc: Bill Westfield <billw@cisco.com>
Subject: GCC
References: <CMM.0.90.4.1012929250.billw@cypher>
From: Lars Brinkhoff <lars@nocrew.org>
Organization: nocrew
Date: 07 Feb 2002 12:19:17 +0100
In-Reply-To: <CMM.0.90.4.1012929250.billw@cypher>
Message-ID: <858za5mte2.fsf@junk.nocrew.org>
Lines: 24
User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: lars brinkhoff <lars@junk.nocrew.org>
William "Chops" Westfield <billw@cisco.com> writes:
> I know most of the discussion has been over on usenet's
> alt.sys.pdp10, but I haven't been keeping up well with usenet these
> days. Surely ye old tops20 mailing list deserves periodic status
> reports?
Ok, here's the current status of the GCC port targeting TOPS-20.
This is the result after running GCC's test suite for 15 hours:
=== gcc Summary ===
# of expected passes 15324
# of unexpected failures 1083
# of unexpected successes 1
# of expected failures 53
# of unresolved testcases 180
# of unsupported tests 470
More info at:
http://pdp10.nocrew.org/gcc/
--
Lars Brinkhoff http://lars.nocrew.org/ Linux, GCC, PDP-10,
Brinkhoff Consulting http://www.brinkhoff.se/ HTTP programming
7-Feb-2002 04:19:21 -0800,1602;000000000020
Return-Path: <lars@junk.nocrew.org>
Received: via tmail-4.1(11) for t20arc; Thu, 7 Feb 2002 04:19:21 -0800 (PST)
Received: from junk.nocrew.org (mail@gem.atari.org [213.242.147.30]) by Ikkoku-Kan.Panda.COM; Thu, 07 Feb 2002 04:18:52 PST
Received: from lars by junk.nocrew.org with local (Exim 3.31 #1 (Debian))
id 16YnUe-00055y-00; Thu, 07 Feb 2002 13:17:36 +0100
To: Mark Crispin <MRC@lingling.panda.com>
Cc: tops-20@panda.com
Subject: Re: Lingling performance
References: <13712768355.8.MRC@lingling.panda.com>
From: Lars Brinkhoff <lars@nocrew.org>
Organization: nocrew
Date: 07 Feb 2002 13:17:36 +0100
In-Reply-To: <13712768355.8.MRC@lingling.panda.com>
Message-ID: <85y9i5lc4f.fsf@junk.nocrew.org>
Lines: 14
User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: lars brinkhoff <lars@junk.nocrew.org>
Mark Crispin <MRC@lingling.panda.com> writes:
> One unpleasant thing that I discovered is that Linux doesn't always
> play nice with bleeding edge hardware. The unfortunate consequences
> of an IDE chipset that is too new for one's version of Linux is a
> corrupted filesystem (and if the UNIX filesystem is corrupted you
> can just imagine what it does to the PDP-10 filesystem).
Maybe you can put the PDP-10 filesystem on a dedicated partition, to
keep the PDP-10 filesystem off the UNIX filesystem, and perhaps get a
slight performance increase?
--
Lars Brinkhoff http://lars.nocrew.org/ Linux, GCC, PDP-10,
Brinkhoff Consulting http://www.brinkhoff.se/ HTTP programming
7-Feb-2002 06:33:38 -0800,1418;000000000020
Return-Path: <wilson@dbit.dbit.com>
Received: via tmail-4.1(11) for t20arc; Thu, 7 Feb 2002 06:33:38 -0800 (PST)
Received: from dbit.dbit.com (root@dbit.com [206.152.182.42]) by Ikkoku-Kan.Panda.COM; Thu, 07 Feb 2002 06:33:17 PST
Received: (from wilson@localhost)
by dbit.dbit.com (8.10.2/8.10.2) id g17EUBQ16096
for TOPS-20@PANDA.COM; Thu, 7 Feb 2002 09:30:11 -0500
Date: Thu, 7 Feb 2002 09:30:11 -0500
From: John Wilson <wilson@dbit.com>
Message-Id: <200202071430.g17EUBQ16096@dbit.dbit.com>
To: TOPS-20@PANDA.COM
Subject: Re: Lingling performance
>From: Lars Brinkhoff <lars@nocrew.org>
>Maybe you can put the PDP-10 filesystem on a dedicated partition, to
>keep the PDP-10 filesystem off the UNIX filesystem, and perhaps get a
>slight performance increase?
My biggest PDP-11 emulation customer does this for RSX disk images on their
Linux machines, and yes it is slightly faster than an image file on an ext2
partition (at least, in their application). We were afraid it would be a
big loss, having been burned by OS/2 where the caching is done individually
by the various FS drivers (talk about brain dead!), but, no problems at all.
And if you use a raw partition, then when someone writes a Linux FS driver
for TOPS-20 file systems, you won't have to go through the loopback driver
to mount them natively under Linux. Ya gotta plan ahead for this stuff!!!
John Wilson
D Bit
10-Feb-2002 12:19:05 -0800,1690;000000000020
Return-Path: <MRC@lingling.panda.com>
Received: via tmail-4.1(11) for t20arc; Sun, 10 Feb 2002 12:19:04 -0800 (PST)
Date: Sun, 10 Feb 2002 12:09:55 -0800 (PST)
From: Mark Crispin <MRC@lingling.panda.com>
Subject: test
To: "TOPS-20 distribution": ;
Message-ID: <13714283618.8.MRC@lingling.panda.com>
This is a test to see if the TOPS-20 mailing list can be hosted once again
on a TOPS-20 system. The last TOPS-20 mailing list message delivered by a
TOPS-20 system was on July 27, 1993 in advance of the shutdown of SIMTEL20
on September 30, 1993. In August 1993, the TOPS-20 list was moved to a
UNIX system here at Panda, where it has been ever since.
12 hours before SIMTEL20 was shut down, the last public message from a
Panda TOPS-20 system was send from one of my 2020s (Yuuyuu). Yuuyuu still
exists; although it spends most of its time in cold unpowered sleep to
conserve what's left of its disks. Yuuyuu's link to the outside world was
through a dial-mail protocol called Cafard which came into being in late
1985. Now that Lingling exists for Yuuyuu to talk Cafard too, I could
conceivably re-establish this link and have email to an actual DEC-manufactured
36-bit machine. However, I doubt that I'd want to run Yuuyuu much, at least
not until I have more reliable disks for it. Yuuyuu did, however, rouse from
sleep to see the calendar turn over from December 31, 1999 to January 1, 2000.
There's no need to reply to this message. I just want to see how well it
gets through MMailr's queues compared to sendmail. Even if the distribution
moves here to Lingling, the email address will continue to be
tops-20@panda.com.
-- Mark --
-------
19-Feb-2002 21:19:02 -0800,8971;000000000020
Return-Path: <MRC@lingling.panda.com>
Received: via tmail-4.1(11) for t20arc; Tue, 19 Feb 2002 21:19:02 -0800 (PST)
Return-Path: <MRC@lingling.panda.com>
Received: from lingling.panda.com (lingling.panda.c [206.124.149.115]) by Ikkoku-Kan.Panda.COM id VAA14517; Tue, 19 Feb 2002 21:18:58 -0800 (PST)
Date: Tue, 19 Feb 2002 21:18:56 -0800 (PST)
From: Mark Crispin <MRC@lingling.panda.com>
Subject: retro-chess
To: tops-20@panda.com
Message-ID: <13716742859.8.MRC@lingling.panda.com>
I just had Lingling spend 72 CPU hours running the 1970s TECH II chess
program in a "play self" at level 8. The results follow; white mated
black on its 51st move. I don't think that anyone has ever had TECH II
run that deeply.
If anyone is a chess expert, could he or she provide us with an analysis
of this game?
Type $? for help.
$d8
_ ps_ 1 W E2-E4 8 0 Time 133.9 in 132.0
1 B E7-E5 8 0 Time 227.8 in 224.4
2 W G1-F3 8 0 Time 680.3 in 671.8
2 B B8-C6 8 0 Time 693.5 in 686.7
3 W B1-C3 8 0 Time 655.2 in 648.5
3 B G8-F6 8 0 Time 831.6 in 823.9
4 W D2-D4 8 0 Time 1098.5 in 1087.9
4 B E5*D4 8 0 Time 719.8 in 711.4
5 W F3*D4 8 0 Time 1498.9 in 1479.3
5 B D7-D5 8 0 Time 558.6 in 550.2
6 W E4*D5 8 0 Time 1597.1 in 1579.0
6 B F6*D5 8 0 Time 2738.2 in 2711.3
7 W F1-C4 8 0 Time 1122.8 in 1110.8
7 B F8-B4 8 0 Time 1338.8 in 1325.5
8 W E1-G1 8 0 Time 1291.7 in 1278.6
8 B C6-E7 8 0 Time 1560.9 in 1545.4
9 W C3*D5 8 75 Time 3658.3 in 3619.4
9 B E7*D5 8 -75 Time 1342.2 in 1326.4
10 W D4-B5 8 75 Time 7908.1 in 7822.1
10 B C7-C6 8 -75 Time 1248.4 in 1234.4
11 W C4*D5 8 100 Time 3851.3 in 3810.6
11 B A7-A6 8 -100 Time 3512.3 in 3477.8
12 W C1-G5 8 125 Time 4106.7 in 4065.8
12 B D8*G5 8 -125 Time 1520.2 in 1506.5
13 W B5-C7 8 125 Time 3120.1 in 3088.1
13 B E8-F8 8 -125 Time 1966.7 in 1946.7
14 W D1-D4 8 125 Time 1524.2 in 1506.3
14 B B4-D6 8 -125 Time 960.1 in 948.6
15 W F1-E1 8 125 Time 2257.9 in 2230.7
15 B G5-D8 8 -125 Time 2998.8 in 2959.5
16 W E1-E8 8 225 Time 2211.3 in 2185.1
16 B D8*E8 8 -225 Time 734.0 in 726.4
17 W C7*E8 8 225 Time 733.9 in 727.1
17 B F8*E8 8 -325 Time 2263.1 in 2241.2
18 W A1-E1 8 325 Time 2891.0 in 2860.6
18 B E8-D8 8 -325 Time 2438.7 in 2413.4
19 W D5*C6 8 325 Time 1887.1 in 1868.8
19 B D8-C7 8 -325 Time 326.6 in 322.3
20 W D4*G7 8 325 Time 2002.5 in 1984.6
20 B C8-E6 8 -325 Time 556.0 in 550.2
21 W E1*E6 8 325 Time 1170.0 in 1157.8
21 B C7*C6 8 -325 Time 414.3 in 409.6
22 W G7*F7 8 425 Time 5168.4 in 5110.8
22 B A6-A5 8 -425 Time 4607.4 in 4562.5
23 W F7-F4 8 425 Time 5884.0 in 5827.2
23 B H8-D8 8 -425 Time 1190.3 in 1177.5
24 W G1-F1 8 425 Time 6383.2 in 6314.3
24 B A5-A4 8 -425 Time 2340.8 in 2317.2
25 W F1-E2 8 425 Time 8102.2 in 8014.8
25 B A8-A5 8 -425 Time 3960.4 in 3922.1
26 W F4-D4 8 425 Time 11168.5 in 11060.2
26 B A5-G5 8 -425 Time 3860.7 in 3824.2
27 W D4-H4 8 525 Time 11329.8 in 11220.7
27 B H7-H6 8 -525 Time -137568.-9 in 2218.9
28 W H4*A4 8 525 Time 6869.6 in 6796.9
28 B C6-B6 8 -525 Time 5627.7 in 5566.3
29 W E6*H6 8 525 Time 4037.5 in 3996.9
29 B G5-E5 8 -525 Time 2714.5 in 2687.1
30 W E2-D3 8 525 Time 3064.2 in 3029.0
30 B E5-D5 8 -525 Time 2969.4 in 2935.1
31 W D3-E4 8 525 Time 7532.5 in 7453.9
31 B D5-G5 8 -525 Time 1197.6 in 1186.9
32 W F2-F4 8 775 Time 6173.5 in 6101.1
32 B G5*G2 8 -775 Time 739.8 in 731.8
33 W A4-D4 8 775 Time 3876.3 in 3827.2
33 B B6-C7 8 -775 Time 7752.7 in 7676.8
34 W H6-H7 8 775 Time 2944.8 in 2915.9
34 B C7-C8 8 -825 Time 21304.8 in 21084.4
35 W D4-C4 8 825 Time 1953.3 in 1930.5
35 B C8-B8 8 -825 Time 2103.6 in 2076.4
36 W E4-F3 8 825 Time 2085.5 in 2060.1
36 B G2*C2 8 -825 Time 1085.1 in 1076.1
37 W C4*C2 8 825 Time 587.5 in 580.4
37 B D8-C8 8 -825 Time 481.0 in 476.2
38 W C2-F5 8 825 Time 1289.2 in 1275.0
38 B C8-C6 8 -825 Time 1105.3 in 1093.9
39 W F5-D5 8 1075 Time 7043.7 in 6972.3
39 B B8-A8 8 -1075 Time 1602.3 in 1588.9
40 W D5-B5 8 1175 Time 5854.9 in 5799.5
40 B D6-C7 8 -1175 Time 560.9 in 556.6
41 W B5-B4 8 1175 Time 4399.0 in 4354.6
41 B A8-A7 8 -1175 Time 918.2 in 906.6
42 W H2-H4 8 1175 Time 2314.6 in 2292.2
42 B A7-A8 8 -1175 Time 1071.1 in 1058.5
43 W F4-F5 8 1175 Time 3410.1 in 3374.8
43 B A8-A7 8 -1175 Time 740.0 in 731.4
44 W B4-A4 8 1175 Time 2381.4 in 2357.6
44 B C6-A6 8 -1675 Time 4253.0 in 4213.7
45 W A4-D4 8 1675 Time 561.2 in 554.8
45 B A7-A8 8 -1675 Time 2912.3 in 2880.8
46 W H7*C7 8 1675 Time 1867.1 in 1848.1
46 B A6-C6 8 -1950 Time 1349.1 in 1337.4
47 W C7*C6 8 32757 Time 145.7 in 144.4
47 B B7*C6 8 -32758 Time 107.5 in 106.4
48 W D4-D7 8 32759 Time 58.5 in 57.6
48 B C6-C5 8 -32760 Time 5.7 in 5.6
49 W F5-F6 8 32761 Time 0.0 in 0.4
49 B C5-C4 8 -32762 Time 0.0 in 0.0
50 W F6-F7 8 32763 Time 0.0 in 0.0
50 B C4-C3 8 -32764 Time 0.0 in 0.0
51 W F7-F8=Q 8 32765 Time 0.0 in 0.0
8 -32766 Time 0.0 in 0.0
^B
BK ** -- ** -- WQ -- **
** -- ** WQ ** -- ** --
-- ** -- ** -- ** -- **
** -- ** -- ** -- ** --
-- ** -- ** -- ** -- WP
** -- BP -- ** WK ** --
WP WP -- ** -- ** -- **
** -- ** -- ** -- ** --
$v
White Real CPU D Black Real CPU D
1 E2E4 137.5 133.9 8 E7E5 224.4 227.8 8
2 G1F3 671.8 680.3 8 B8C6 686.7 693.5 8
3 B1C3 648.5 655.2 8 G8F6 823.9 831.6 8
4 D2D4 1087.9 1098.5 8 E5D4 711.4 719.8 8
5 F3D4 1479.3 1498.9 8 D7D5 550.2 558.7 8
6 E4D5 1579.0 1597.1 8 F6D5 2711.3 2738.2 8
7 F1C4 1110.8 1122.8 8 F8B4 1325.5 1338.8 8
8 E1G1 1278.6 1291.7 8 C6E7 1545.4 1561.0 8
9 C3D5 3619.4 3658.3 8 E7D5 1326.4 1342.2 8
10 D4B5 7822.1 7908.1 8 C7C6 1234.4 1248.4 8
11 C4D5 3810.6 3851.4 8 A7A6 3477.8 3512.3 8
12 C1G5 4065.8 4106.7 8 D8G5 1506.5 1520.2 8
13 B5C7 3088.1 3120.1 8 E8F8 1946.7 1966.7 8
14 D1D4 1506.3 1524.2 8 B4D6 948.6 960.1 8
15 F1E1 2230.7 2257.9 8 G5D8 2959.9 2998.9 8
16 E1E8 2185.1 2211.4 8 D8E8 726.4 734.0 8
17 C7E8 727.1 733.9 8 F8E8 2241.2 2263.1 8
18 A1E1 2860.6 2891.0 8 E8D8 2413.4 2438.8 8
19 D5C6 1868.8 1887.1 8 D8C7 322.3 326.6 8
20 D4G7 1984.6 2002.5 8 C8E6 550.2 556.0 8
21 E1E6 1157.8 1170.0 8 C7C6 409.6 414.4 8
22 G7F7 5110.8 5168.4 8 A6A5 4562.5 4607.5 8
23 F7F4 5827.2 5884.0 8 H8D8 1177.5 1190.3 8
24 G1F1 6314.3 6383.2 8 A5A4 2317.2 2340.9 8
25 F1E2 8014.8 8102.2 8 A8A5 3922.1 3960.5 8
26 F4D4 11060.2 11168.6 8 A5G5 3824.2 3860.8 8
27 D4H4 11220.7 11329.8 8 H7H6 2218.9/-)+*(.-9 8
28 H4A4 6796.9 6869.7 8 C6B6 5566.3 5627.7 8
29 E6H6 3996.9 4037.5 8 G5E5 2687.1 2714.5 8
30 E2D3 3029.0 3064.3 8 E5D5 2935.1 2969.4 8
31 D3E4 7453.9 7532.5 8 D5G5 1186.9 1197.6 8
32 F2F4 6101.1 6173.5 8 G5G2 731.8 739.8 8
33 A4D4 3827.2 3876.3 8 B6C7 7676.8 7752.7 8
34 H6H7 2915.9 2944.9 8 C7C8 21084.4 21304.8 8
35 D4C4 1930.5 1953.4 8 C8B8 2076.4 2103.6 8
36 E4F3 2060.1 2085.5 8 G2C2 1076.1 1085.1 8
37 C4C2 580.4 587.5 8 D8C8 476.2 481.0 8
38 C2F5 1275.0 1289.3 8 C8C6 1093.9 1105.3 8
39 F5D5 6972.3 7043.7 8 B8A8 1588.9 1602.4 8
40 D5B5 5799.5 5854.9 8 D6C7 556.6 560.9 8
41 B5B4 4354.6 4399.0 8 A8A7 906.6 918.2 8
42 H2H4 2292.2 2314.6 8 A7A8 1058.5 1071.1 8
43 F4F5 3374.8 3410.1 8 A8A7 731.4 740.0 8
44 B4A4 2357.6 2381.4 8 C6A6 4213.7 4253.0 8
45 A4D4 554.8 561.2 8 A7A8 2880.8 2912.4 8
46 H7C7 1848.1 1867.1 8 A6C6 1337.4 1349.1 8
47 C7C6 144.4 145.7 8 B7C6 106.4 107.5 8
48 D4D7 57.6 58.5 8 C6C5 5.6 5.7 8
49 F5F6 0.4 0.1 8 C5C4 0.0 0.0 8
50 F6F7 0.0 0.0 8 C4C3 0.0 0.0 8
51 F7F8=Q 0.0 0.0 8
Total Min. 2669.8 2698.1 1777.3 +-,.-2
_
-------
11-Apr-2002 15:00:26 -0700,1955;000000000020
Return-Path: <MRC@Panda.COM>
Received: via tmail-4.1(11) (invoked by user mrc) for t20arc; Thu, 11 Apr 2002 15:00:25 -0700 (PDT)
Return-Path: <MRC@Panda.COM>
Received: from mxout3.cac.washington.edu (mxout3.cac.washington.ed [140.142.32.19]) by Ikkoku-Kan.Panda.COM id PAA25639; Thu, 11 Apr 2002 15:00:21 -0700 (PDT)
Received: from mailscan-out1.cac.washington.edu (mailscan-out1.cac.washington.edu [140.142.32.17])
by mxout3.cac.washington.edu (8.12.1+UW01.12/8.12.1+UW02.01) with SMTP id g3BM0I8J011385
for <TOPS-20@Panda.COM>; Thu, 11 Apr 2002 15:00:19 -0700
Received: FROM smtp.washington.edu BY mailscan-out1.cac.washington.edu ; Thu Apr 11 15:00:18 2002 -0700
Received: from Shimo-Tomobiki.Panda.COM (ikkoku-kan.panda.com [206.124.149.114])
(authenticated bits=0)
by smtp.washington.edu (8.12.1+UW01.12/8.12.1+UW02.01) with ESMTP id g3BM0Fjv003241
(version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO)
for <TOPS-20@Panda.COM>; Thu, 11 Apr 2002 15:00:17 -0700
Date: Thu, 11 Apr 2002 15:00:07 -0700 (Pacific Daylight Time)
From: Mark Crispin <MRC@Panda.COM>
To: TOPS-20 Hackers and Yackers <TOPS-20@Panda.COM>
Subject: Anyone preserved TOPS-20 CLISP?
Message-ID: <Pine.WNT.4.50.0204111450080.3060-100000@Shimo-Tomobiki.Panda.COM>
Organization: Networks & Distributed Computing
Sender: mrc@cac.washington.edu
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Did anyone preserve CLISP, Chuck Hedrick's implementation of Common Lisp
for TOPS-20? I just checked with Chuck, and learned that the Rutgers CS
department tossed out all their tapes from that era.
It appears that I don't have a copy either. It wasn't on my 2020
filesystem (probably because it couldn't run on a 2020). There's a small
chance that I might have it on a magtape, but I doubt it (not to mention
that my tapes are probably all unreadable).
-- Mark --
http://panda.com/mrc
Socialism: If you build it, they will leave
11-Apr-2002 15:13:15 -0700,1271;000000000020
Return-Path: <MRC@Panda.COM>
Received: via tmail-4.1(11) (invoked by user mrc) for t20arc; Thu, 11 Apr 2002 15:13:15 -0700 (PDT)
Return-Path: <MRC@Panda.COM>
Received: from Ikkoku-Kan.Panda.COM (Ikkoku-Kan.Panda.COM [192.107.14.50]) by Ikkoku-Kan.Panda.COM id PAA25693; Thu, 11 Apr 2002 15:13:11 -0700 (PDT)
Date: Thu, 11 Apr 2002 15:09:06 -0700 (PDT)
From: Mark Crispin <MRC@Panda.COM>
Sender: Mark Crispin <mrc@Ikkoku-Kan.Panda.COM>
Subject: re: Anyone preserved TOPS-20 CLISP?
To: TOPS-20 Hackers and Yackers <TOPS-20@Panda.COM>
In-Reply-To: <Pine.WNT.4.50.0204111450080.3060-100000@Shimo-Tomobiki.Panda.COM>
Message-ID: <MailManager.1018562946.237.mrc@Ikkoku-Kan.Panda.COM>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
> There's a small
> chance that I might have it on a magtape, but I doubt it (not to mention
> that my tapes are probably all unreadable).
I decided to check my magtapes. Most of what I have is either already on
trailing-edge.com (perhaps not some of the DECnet-20 stuff) or online on
Lingling. The notable exception is a tape labelled "Hoimes" which is almost
certainly Hermes (BBN's MUA circa late 1970s/early 1980s).
-- Mark --
http://panda.com/mrc
Socialism: If you build it, they will leave.
12-Apr-2002 02:05:40 -0700,1618;000000000020
Return-Path: <Bjorn.Victor@it.uu.se>
Received: via tmail-4.1(11) for t20arc; Fri, 12 Apr 2002 02:05:40 -0700 (PDT)
Return-Path: <Bjorn.Victor@it.uu.se>
Received: from meryl.it.uu.se (agent@localhost) by Ikkoku-Kan.Panda.COM id CAA26832; Fri, 12 Apr 2002 02:05:16 -0700 (PDT)
Received: from meryl.it.uu.se (root@meryl.it.uu.se [130.238.12.42]) by Ikkoku-Kan.Panda.COM; Fri, 12 Apr 2002 02:05:17 PDT
Received: from Nomine.it.uu.se (root@hamberg.it.uu.se [130.238.9.198])
by meryl.it.uu.se (8.8.5/8.8.5) with ESMTP id LAA05888;
Fri, 12 Apr 2002 11:05:05 +0200 (MET DST)
Received: by Nomine.it.uu.se (Postfix, from userid 501)
id 1872091F9E; Fri, 12 Apr 2002 11:05:04 +0200 (CEST)
Sender: victor@Nomen.it.uu.se
From: Bjorn Victor <Bjorn.Victor@it.uu.se>
To: Mark Crispin <MRC@Panda.COM>
Cc: TOPS-20 Hackers and Yackers <TOPS-20@Panda.COM>
Subject: Re: Anyone preserved TOPS-20 CLISP?
References: <Pine.WNT.4.50.0204111450080.3060-100000@Shimo-Tomobiki.Panda.COM>
Date: Fri, 12 Apr 2002 11:05:03 +0200
In-Reply-To: <Pine.WNT.4.50.0204111450080.3060-100000@Shimo-Tomobiki.Panda.COM>
(Mark Crispin's message of "Thu, 11 Apr 2002 15:00:07 -0700 (Pacific
Daylight Time)")
Message-ID: <m2bscpffsw.fsf@Nomen.it.uu.se>
Lines: 5
User-Agent: Gnus/5.090004 (Oort Gnus v0.04) XEmacs/21.4 (Common Lisp,
i686-pc-linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
I'm pretty sure I have it on my system, but parts of it may be
offline. I'll check - this may be a good incentive to restore the
migration tapes (which I have on a CD)...
-- Bjvrn
13-Apr-2002 05:27:57 -0700,1496;000000000020
Return-Path: <lars@junk.nocrew.org>
Received: via tmail-4.1(11) for t20arc; Sat, 13 Apr 2002 05:27:56 -0700 (PDT)
Return-Path: <lars@junk.nocrew.org>
Received: from junk.nocrew.org (agent@localhost) by Ikkoku-Kan.Panda.COM id FAA28519; Sat, 13 Apr 2002 05:27:31 -0700 (PDT)
Received: from junk.nocrew.org (mail@junk.nocrew.org [213.242.147.30]) by Ikkoku-Kan.Panda.COM; Sat, 13 Apr 2002 05:27:32 PDT
Received: from lars by junk.nocrew.org with local (Exim 3.31 #1 (Debian))
for tops-20@panda.com
id 16wMco-00028G-00; Sat, 13 Apr 2002 14:27:26 +0200
to: tops-20@panda.com
Subject: GCC status
From: Lars Brinkhoff <lars@nocrew.org>
Organization: nocrew
Date: 13 Apr 2002 14:27:26 +0200
Message-ID: <85d6x32381.fsf@junk.nocrew.org>
Lines: 18
User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: lars brinkhoff <lars@junk.nocrew.org>
The April 11th result of running the GCC test suite:
=== gcc Summary ===
# of expected passes 16510
# of unexpected failures 260
# of unexpected successes 1
# of expected failures 61
# of unresolved testcases 19
# of unsupported tests 1058
The upsupported tests use trampolines (for nested functions),
<varargs.h>, or any of the float, double, or long long types. (These
features may be supported later.)
--
Lars Brinkhoff http://lars.nocrew.org/ Linux, GCC, PDP-10,
Brinkhoff Consulting http://www.brinkhoff.se/ HTTP programming
8-May-2002 14:30:23 -0700,2680;000000000020
Return-Path: <dfb@watson.ibm.com>
Received: via tmail-4.1(11) for t20arc; Wed, 8 May 2002 14:30:23 -0700 (PDT)
Return-Path: <dfb@watson.ibm.com>
Received: from igw3.watson.ibm.com (igw3.watson.ibm. [198.81.209.18]) by Ikkoku-Kan.Panda.COM id OAA07420; Wed, 8 May 2002 14:30:16 -0700 (PDT)
Received: from sp1n293en1.watson.ibm.com (sp1n293en1.watson.ibm.com [9.2.112.57])
by igw3.watson.ibm.com (8.11.4/8.11.4) with ESMTP id g48DGlO15664
for <Tops-20@Panda.com>; Wed, 8 May 2002 09:16:47 -0400
Received: from flyingcloud.watson.ibm.com (flyingcloud.watson.ibm.com [9.2.32.200])
by sp1n293en1.watson.ibm.com (8.11.4/8.11.4) with ESMTP id g48DGmd24530
for <Tops-20@Panda.com>; Wed, 8 May 2002 09:16:48 -0400
Received: from HEDDA (HEDDA.watson.ibm.com [9.2.34.142])
by flyingcloud.watson.ibm.com (AIX4.3/8.9.3/8.9.3/01-10-2000) with SMTP id JAA27790
for <Tops-20@Panda.com>; Wed, 8 May 2002 09:16:46 -0400
Message-ID: <008701c1f692$9b99a380$8e220209@watson.ibm.com>
From: "David F. Bacon" <dfb@watson.ibm.com>
To: <Tops-20@Panda.com>
Subject: Swordfish
Date: Wed, 8 May 2002 09:16:44 -0400
MIME-Version: 1.0
Content-Type: multipart/alternative;
boundary="----=_NextPart_000_0084_01C1F671.12C82B10"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4807.1700
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700
This is a multi-part message in MIME format.
------=_NextPart_000_0084_01C1F671.12C82B10
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
I just caught "Swordfish" on cable -- a horrible movie filled with =
ridiculous techno-babble. But did anyone else catch the reference to an =
"old ITS machine in a basement at Caltech"? I nearly fell out of my =
chair!
david
------=_NextPart_000_0084_01C1F671.12C82B10
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 5.50.4807.2300" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>I just caught "Swordfish" on cable -- a =
horrible=20
movie filled with ridiculous techno-babble. But did anyone else =
catch the=20
reference to an "old ITS machine in a basement at Caltech"? I =
nearly fell=20
out of my chair!</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>david</FONT></DIV></BODY></HTML>
------=_NextPart_000_0084_01C1F671.12C82B10--
8-May-2002 15:03:34 -0700,1956;000000000020
Return-Path: <smj@sdf.lonestar.org>
Received: via tmail-4.1(11) for t20arc; Wed, 8 May 2002 15:03:33 -0700 (PDT)
Return-Path: <smj@sdf.lonestar.org>
Received: from sdf.lonestar.org (agent@localhost) by Ikkoku-Kan.Panda.COM id PAA07483; Wed, 8 May 2002 15:03:07 -0700 (PDT)
Received: from sdf.lonestar.org (root@sdf.lonestar.org [207.202.214.132]) by Ikkoku-Kan.Panda.COM; Wed, 08 May 2002 15:03:07 PDT
Received: (from smj@localhost)
by sdf.lonestar.org (8.11.6/8.11.6) id g48M2TT07851;
Wed, 8 May 2002 22:02:29 GMT
From: Stephen Jones <smj@sdf.lonestar.org>
Message-Id: <200205082202.g48M2TT07851@sdf.lonestar.org>
Subject: Re: Swordfish
To: dfb@watson.ibm.com (David F. Bacon)
Date: Wed, 8 May 2002 22:02:29 +0000 (UTC)
Cc: Tops-20@Panda.com
In-Reply-To: <no.id> from "David F. Bacon" at May 08, 2002 09:16:44 AM
X-Mailer: ELM [version 2.5 PL5]
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
David writes:
> I just caught "Swordfish" on cable -- a horrible movie filled with
> ridiculous techno-babble. But did anyone else catch the reference to an
> "old ITS machine in a basement at Caltech"? I nearly fell out of my
Neat .. did they really mean real ITS or the WAITS? and did they visit the
basement and save the KS10 from being scrapped?
When 'HACKERS' came out a few of us (Ted brought his wife) decided to go
see it. None of us had seen any previews and had already been boycotting
TV for years .. so it was a real treat for us. Of course, the movie poster
should have told us something, but needless to say we walked out and demanded
our money back. The manager said he had a few people complaining about it.
We were *REALLY* expecting to see a good documentary on Gosper, Moon, Steele,
Bobrow, Winereb, Knight, Greenberg and perhaps even MRC.
Naive? nah! we brainwashed ourselves into it. Still, maybe PBS will do a
real 'HACKERS' for us all.
8-May-2002 15:33:23 -0700,1326;000000000020
Return-Path: <MRC@Panda.COM>
Received: via tmail-4.1(11) (invoked by user mrc) for t20arc; Wed, 8 May 2002 15:33:23 -0700 (PDT)
Return-Path: <MRC@Panda.COM>
Received: from Ikkoku-Kan.Panda.COM (Ikkoku-Kan.Panda.COM [192.107.14.50]) by Ikkoku-Kan.Panda.COM id PAA07527; Wed, 8 May 2002 15:33:00 -0700 (PDT)
Date: Wed, 8 May 2002 15:21:27 -0700 (PDT)
From: Mark Crispin <MRC@Panda.COM>
Sender: Mark Crispin <mrc@Ikkoku-Kan.Panda.COM>
Subject: Re: Swordfish
To: Stephen Jones <smj@sdf.lonestar.org>
cc: "David F. Bacon" <dfb@watson.ibm.com>, Tops-20@Panda.com
In-Reply-To: <200205082202.g48M2TT07851@sdf.lonestar.org>
Message-ID: <MailManager.1020896487.3944.mrc@Ikkoku-Kan.Panda.COM>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
On Wed, 8 May 2002 22:02:29 +0000 (UTC), Stephen Jones wrote:
> Neat .. did they really mean real ITS or the WAITS?
To the best of my knowledge, WAITS only ever ran at Stanford (two sites) and
at Lawrence Livermore Labs (one site).
> We were *REALLY* expecting to see a good documentary on Gosper, Moon,
> Steele, Bobrow, Winereb, Knight, Greenberg and perhaps even MRC.
Hopefully *not* MRC!
With one exception (I was paid for it by a Japanese magazine) I have refused
interviews for 20 years. I do not desire media attention. My life is my own.
8-May-2002 16:16:02 -0700,1858;000000000020
Return-Path: <dempster@us.fornax.com>
Received: via tmail-4.1(11) for t20arc; Wed, 8 May 2002 16:16:02 -0700 (PDT)
Return-Path: <dempster@us.fornax.com>
Received: from US.Fornax.COM (Callisto.US.Fornax.c [199.171.27.110]) by Ikkoku-Kan.Panda.COM id QAA07584; Wed, 8 May 2002 16:15:58 -0700 (PDT)
Received: from us.fornax.com (Joe-PC.US.Fornax.COM [206.67.177.139])
by US.Fornax.COM (8.11.1/8.11.1) with ESMTP id g48NFW924640;
Wed, 8 May 2002 19:15:32 -0400 (EDT)
Message-ID: <3CD9B122.F7C88A15@us.fornax.com>
Date: Wed, 08 May 2002 19:13:38 -0400
From: Joe Dempster <dempster@US.Fornax.COM>
X-Mailer: Mozilla 4.77 [en] (Win95; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Stephen Jones <smj@sdf.lonestar.org>
CC: "David F. Bacon" <dfb@watson.ibm.com>, Tops-20@Panda.com
Subject: Re: Swordfish
References: <200205082202.g48M2TT07851@sdf.lonestar.org>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Stephen Jones wrote:
> David writes:
>
> > I just caught "Swordfish" on cable -- a horrible movie filled with
> > ridiculous techno-babble. But did anyone else catch the reference to an
> > "old ITS machine in a basement at Caltech"? I nearly fell out of my
I too caught the reference. I seem to remember watching this movie with my 17
year old son, in a very sparsely filled matinee show (I know these days are
numbered...), and giving him the elbow when the ITS reference appeared. I do
have an early picture of him with a wrench in his hand, leaning on a RM03 in
front of my KS10---but he was just annoyed with the elbow....
This movie has faded quickly into oblivion in my feeble mind. But I seem to
remember that a statement was made in the script to "hacking into the ITS machine
at CalTech" which anyone in the know knew only required a passing knowledge of
DDT.
/joe
8-May-2002 16:30:17 -0700,1092;000000000020
Return-Path: <billw@cisco.com>
Received: via tmail-4.1(11) for t20arc; Wed, 8 May 2002 16:30:17 -0700 (PDT)
Return-Path: <billw@cisco.com>
Received: from cisco.com (agent@localhost) by Ikkoku-Kan.Panda.COM id QAA07626; Wed, 8 May 2002 16:30:01 -0700 (PDT)
Received: from cisco.com (cypher.cisco.com [171.69.11.18]) by Ikkoku-Kan.Panda.COM; Wed, 08 May 2002 16:30:01 PDT
Received: (from billw@localhost)
by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) id QAA10498;
Wed, 8 May 2002 16:29:40 -0700 (PDT)
Sender: Bill Westfield <billw@cisco.com>
Date: Wed, 8 May 2002 16:29:40 PDT
From: William "Chops" Westfield <billw@cisco.com>
Reply-To: Bill Westfield <billw@cisco.com>
To: Joe Dempster <dempster@us.fornax.com>
Cc: Stephen Jones <smj@sdf.lonestar.org>,
"David F. Bacon" <dfb@watson.ibm.com>, Tops-20@Panda.com
Subject: Re: Swordfish
In-Reply-To: Your message of Wed, 08 May 2002 19:13:38 -0400
Message-ID: <CMM.0.90.4.1020900580.billw@cypher>
Ok. Did Caltech HAVE ITS systems? That sounds about as plausable as Harvard
running the Yale "exec"...
BillW
8-May-2002 19:54:36 -0700,2023;000000000020
Return-Path: <smj@sdf.lonestar.org>
Received: via tmail-4.1(11) for t20arc; Wed, 8 May 2002 19:54:36 -0700 (PDT)
Return-Path: <smj@sdf.lonestar.org>
Received: from sdf.lonestar.org (agent@localhost) by Ikkoku-Kan.Panda.COM id TAA07785; Wed, 8 May 2002 19:54:11 -0700 (PDT)
Received: from sdf.lonestar.org (root@sdf.lonestar.org [207.202.214.132]) by Ikkoku-Kan.Panda.COM; Wed, 08 May 2002 19:54:12 PDT
Received: (from smj@localhost)
by sdf.lonestar.org (8.11.6/8.11.6) id g492rK825373;
Thu, 9 May 2002 02:53:20 GMT
From: Stephen Jones <smj@sdf.lonestar.org>
Message-Id: <200205090253.g492rK825373@sdf.lonestar.org>
Subject: Re: Swordfish
To: dempster@us.fornax.com (Joe Dempster)
Date: Thu, 9 May 2002 02:53:20 +0000 (UTC)
Cc: smj@SDF.LONESTAR.ORG (Stephen Jones), dfb@watson.ibm.com (David F. Bacon),
Tops-20@Panda.com
In-Reply-To: <no.id> from "Joe Dempster" at May 08, 2002 07:13:38 PM
X-Mailer: ELM [version 2.5 PL5]
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
> This movie has faded quickly into oblivion in my feeble mind. But I seem to
> remember that a statement was made in the script to "hacking into the ITS machine
> at CalTech" which anyone in the know knew only required a passing knowledge of
> DDT.
Okay, well if they were using the term 'hacking' like we're assuming only
Hollywood would know how .. why the heck would they be concerned about breaking
into a system that doesn't have ACLs or even mandatory passwords?
And better yet, what sort of information that wasn't already public be worth
breaking the system over? why would you need to break the system? why would
need a script to do it? Was it the script that issued the ^Z to get the
system's attention? ;-)
If I saw it in the theatre I'd probably laugh out loud .. similar to the instance
in PI when the Go instructor was explaining to his student that a computer begins
to reason when its almost got PI calculated... remember that one?
8-May-2002 21:43:43 -0700,1655;000000000020
Return-Path: <MRC@lingling.panda.com>
Received: via tmail-4.1(11) for t20arc; Wed, 8 May 2002 21:43:43 -0700 (PDT)
Return-Path: <MRC@lingling.panda.com>
Received: from lingling.panda.com (Lingling.Panda.C [206.124.149.115]) by Ikkoku-Kan.Panda.COM id VAA07927; Wed, 8 May 2002 21:43:39 -0700 (PDT)
Received: from [10.0.0.12] (zed.nsw.garetech.com.au [10.0.0.12])
by bob.nsw.garetech.com.au (8.11.6/8.11.6) with ESMTP id g492Bo418307
for <Tops-20@panda.com>; Thu, 9 May 2002 12:11:50 +1000
User-Agent: Microsoft-Entourage/10.0.0.1331
Date: Thu, 09 May 2002 11:57:57 +1000
Subject: Re: Swordfish
From: Mark Garrett <markg@garetech.com.au>
To: totops20 <Tops-20@panda.com>
Message-ID: <B90014C5.4E37%markg@garetech.com.au>
In-Reply-To: <3CD9B122.F7C88A15@us.fornax.com>
Mime-version: 1.0
Content-type: text/plain; charset="US-ASCII"
Content-transfer-encoding: 7bit
ReSent-Date: Wed, 8 May 2002 20:43:37 -0800 (PDT)
ReSent-From: Mark Crispin <MRC@lingling.panda.com>
ReSent-To: tops-20@panda.com
ReSent-Message-ID: <13737172741.9.MRC@lingling.panda.com>
> Stephen Jones wrote:
>
> This movie has faded quickly into oblivion in my feeble mind. But I seem to
> remember that a statement was made in the script to "hacking into the ITS
> machine
> at CalTech" which anyone in the know knew only required a passing knowledge of
> DDT.
The reference to the ITS machine was that he had hidden his special hacking
tool(s) on the machine and need to get them, not that he needed to hack into
an ITS machine.
Unless I've forgotten some early reference to ITS and his younger hacking
exploits?
Cheers
Mark:)
8-May-2002 21:48:09 -0700,2763;000000000020
Return-Path: <carl@reststop.com>
Received: via tmail-4.1(11) for t20arc; Wed, 8 May 2002 21:48:09 -0700 (PDT)
Return-Path: <carl@reststop.com>
Received: from hustle-x.rahul.net (agent@localhost) by Ikkoku-Kan.Panda.COM id VAA07967; Wed, 8 May 2002 21:48:05 -0700 (PDT)
Received: from hustle-x.rahul.net (hustle.rahul.net [192.160.13.2]) by Ikkoku-Kan.Panda.COM; Wed, 08 May 2002 21:48:06 PDT
Received: by hustle.rahul.net id AA21015
(5.67b8/IDA-1.5 for Tops-20@Panda.com); Wed, 8 May 2002 21:06:52 -0700
X-Uucp-From: carl@reststop.com Wed, 15 Oct 97 21:54:44 PDT Wed, 8 May 02 20:09:35 PDT remote from udwarf
Received: by garage.1unique.com (uA-1.6v2); Wed, 8 May 02 19:32:12 PDT
Received: by udwarf.reststop.com (uA-1.6v2); Wed, 8 May 02 20:09:35 PDT
From: carl@reststop.com (Carl Baltrunas & Cherie Marinelli 1.6v2)
To: dfb@watson.ibm.com
Subject: Re: Swordfish
Date: Wed, 8 May 02 20:09:35 PDT
Cc: Tops-20@Panda.com
Organization: Catalyst Industries
Reply-To: carl@reststop.com
Message-Id: <D2150039.fudju7@udwarf.reststop.com>
X-Mailer: uAccess - Macintosh Release: 1.6v2
Funny... As I was reading your message David.. I had given up on finding
anything interesting on the satellite and left the channel on "Swordfish" ...
While doing something else, I overheard the characters talk about the last
PDP-10 left running in the world...
Did ITS ever run anywhere other than at MIT? ( not counting anything that
KLH may have tried running under his simulator )
Does anyone have a set of ITS sources? I fondly remember logging nto ITS
remotely from Maryland and California from 1973- until sometime in the 80's.
For those of you who won't bear watching the whole movie, (I haven't yet,
although Halle Berry is usually worth watching, I can't stand John Revolta)...
... the segment about the PDP-10 running ITS is right around
50-52 minutes into the film, which is just about 1/2. Movie said it
started at 7:00, clock said 7:52, info on screen said 53 minutes left.
I suggest you peek in a minute or two earlier just in case it's off by
a minute or two.
-Carl
> I just caught "Swordfish" on cable -- a horrible movie filled with
> ridiculous techno-babble. But did anyone else catch the reference to an
> "old ITS machine in a basement at Caltech"? I nearly fell out of my
> chair!
>
> david
Carl A Baltrunas <carl@reststop.com> and Cherie Marinelli <2bunnies@1unique.com>
Catalyst Industries: The One-Stop Internet registration and distribution service
URL: <http://www.reststop.com> INFO: info@reststop.com
-owned by EWBR, EWBR-ette & Paddy [our house bunnies] and Peri & Pixie the puppies.
Visit them at their hotel at http://www.reststop.com/info/bunny/bunnycam.html
8-May-2002 22:08:05 -0700,2216;000000000020
Return-Path: <gmarkham@futura.net>
Received: via tmail-4.1(11) for t20arc; Wed, 8 May 2002 22:08:05 -0700 (PDT)
Return-Path: <gmarkham@futura.net>
Received: from inside.centurytel.net (agent@localhost) by Ikkoku-Kan.Panda.COM id WAA08067; Wed, 8 May 2002 22:08:01 -0700 (PDT)
Received: from inside.centurytel.net (209.142.138.107) by Ikkoku-Kan.Panda.COM; Wed, 08 May 2002 22:08:02 PDT
Received: from futura.net (eight.centurytel.net [192.168.0.8])
by inside.centurytel.net (8.9.3/8.9.3) with ESMTP id WAA00947;
Sun, 6 May 2001 22:50:39 GMT
(envelope-from gmarkham@futura.net)
Message-ID: <3CD9F24B.AE795E71@futura.net>
Date: Wed, 08 May 2002 22:51:39 -0500
From: George Markham <gmarkham@futura.net>
Reply-To: gmarkham@futura.net
X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: "David F. Bacon" <dfb@watson.ibm.com>
CC: Tops-20@Panda.com
Subject: Re: Swordfish
References: <008701c1f692$9b99a380$8e220209@watson.ibm.com>
Content-Type: multipart/alternative;
boundary="------------3307B4C1FAD79D748ABFA827"
--------------3307B4C1FAD79D748ABFA827
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
I did.. was great!
"David F. Bacon" wrote:
> I just caught "Swordfish" on cable -- a horrible movie filled with
> ridiculous techno-babble. But did anyone else catch the reference to
> an "old ITS machine in a basement at Caltech"? I nearly fell out of
> my chair! david
--------------3307B4C1FAD79D748ABFA827
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit
<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
<body bgcolor="#FFFFFF">
I did.. was great!
<br>
<p>"David F. Bacon" wrote:
<blockquote TYPE=CITE><style></style>
<font face="Arial"><font size=-1>I
just caught "Swordfish" on cable -- a horrible movie filled with ridiculous
techno-babble. But did anyone else catch the reference to an "old
ITS machine in a basement at Caltech"? I nearly fell out of my chair!</font></font> <font face="Arial"><font size=-1>david</font></font></blockquote>
</body>
</html>
--------------3307B4C1FAD79D748ABFA827--
8-May-2002 22:22:06 -0700,1918;000000000020
Return-Path: <MRC@lingling.panda.com>
Received: via tmail-4.1(11) for t20arc; Wed, 8 May 2002 22:22:06 -0700 (PDT)
Return-Path: <MRC@lingling.panda.com>
Received: from lingling.panda.com (Lingling.Panda.C [206.124.149.115]) by Ikkoku-Kan.Panda.COM id WAA08111; Wed, 8 May 2002 22:22:04 -0700 (PDT)
Date: Wed, 8 May 2002 21:11:11 -0800 (PDT)
From: Mark Crispin <MRC@lingling.panda.com>
Subject: new, *SECRET* address for the TOPS-20 mailing list
To: TOPS-20@lingling.panda.com
Message-ID: <13737177758.9.MRC@lingling.panda.com>
Some of you have had trouble today in sending mail to the TOPS-20
mailing list, due to spam-blocking on panda.com. As a temporary
measure, I've turned off text-based spam blocking on
tops-20@panda.com so the messages will go through.
Unfortunately, this can't be permanent. Spams aimed at
tops-20@panda.com come through every few days, and only the
spam-blocking at panda.com stops them from sliming your mailbox.
As an experiment, I have enabled tops-20@lingling.panda.com.
That's right, the TOPS-20 list is once again hosted on a TOPS-20
system. Lingling does not have any spam blocking, so anyone can
send mail to this address.
The current tops-20@panda.com address will continue to go through
the UNIX host (and spam blocking).
I must emphasize, as strongly as possible, PLEASE keep this new
address secret!
1) do not tell any non-list member about it.
2) do not put it on web pages. The tops-20@panda.com address is
on some web pages (e.g. Joe Smith's page) and that's how
spammers got ahold of it.
3) do not put it in your email program's address book (otherwise
it may fall victim to KLEZ or some other virus/worm).
4) do not send any message to both tops-20@lingling.panda.com
and some other address.
I hope that this will be helpful to all of us, and hopefully we
can keep the secret.
-- Mark --
-------
15-May-2002 15:01:19 -0700,1777;000000000020
Return-Path: <MRC@lingling.panda.com>
Received: via tmail-4.1(11) for t20arc; Wed, 15 May 2002 15:01:19 -0700 (PDT)
Return-Path: <MRC@lingling.panda.com>
Received: from lingling.panda.com (Lingling.Panda.C [206.124.149.115]) by Ikkoku-Kan.Panda.COM id PAA17944; Wed, 15 May 2002 15:01:17 -0700 (PDT)
Date: Wed, 15 May 2002 13:41:42 -0800 (PDT)
From: Mark Crispin <MRC@lingling.panda.com>
Subject: anybody using DEC's resolver instead of Chives?
To: tops-20@lingling.panda.com
Message-ID: <13738930941.8.MRC@lingling.panda.com>
The final release of TOPS-20 from DEC included a DNS resolver in the monitor
as part of the TSU tape. Unfortunately, that resolver has bugs in it; they
reused the symbol name .GTHLN which broke the GTHST% function by that name,
and for .GTHMX they returned the MX table in the third (.GTHNM) word,
omitting the canonicalized name.
The second problem is an incompatibility with the GTDOM% JSYS, and breaks
MMAILR. I don't see how anyone could have successfully used DEC's resolver
on a system doing Internet mail with that bug.
Although I have moved the MX table to the fourth word, and added .GTHRD, I
am worried that I might be introducing an incompatibility with someone who
might be depending upon DEC's resolver.
I checked, and XKL systems do *NOT* have the DEC resolver, and therefore
there's no problem. But I don't know about SC systems, and more importantly
I don't know about any KLH10 based systems that are *not* using my Panda
distribution.
Hence this inquiry.
Can we have a show of hands of who is running TOPS-20 out there? I know about:
XKL: XKL, Paul Allen, Peter Lothberg
SC: Peter Lothberg (no longer running?)
plus 7 Panda systems (of which three seem to be running right now)
-------
15-May-2002 15:43:55 -0700,1438;000000000020
Return-Path: <lars@junk.nocrew.org>
Received: via tmail-4.1(11) for t20arc; Wed, 15 May 2002 15:43:55 -0700 (PDT)
Return-Path: <lars@junk.nocrew.org>
Received: from lingling.panda.com (Lingling.Panda.C [206.124.149.115]) by Ikkoku-Kan.Panda.COM id PAA17960; Wed, 15 May 2002 15:43:53 -0700 (PDT)
Received: from junk.nocrew.org ([213.242.147.30]) by lingling.panda.com with TCP/SMTP; Wed, 15 May 2002 14:32:04 -0800 (PDT)
Received: from lars by junk.nocrew.org with local (Exim 3.31 #1 (Debian))
id 1787JM-0003xl-00; Thu, 16 May 2002 00:31:56 +0200
To: Mark Crispin <MRC@lingling.panda.com>
Cc: tops-20@lingling.panda.com
Subject: Re: anybody using DEC's resolver instead of Chives?
References: <13738930941.8.MRC@lingling.panda.com>
From: Lars Brinkhoff <lars@nocrew.org>
Organization: nocrew
Date: 16 May 2002 00:31:56 +0200
In-Reply-To: <13738930941.8.MRC@lingling.panda.com>
Message-ID: <85g00t9h5v.fsf@junk.nocrew.org>
Lines: 8
User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: lars brinkhoff <lars@junk.nocrew.org>
Mark Crispin <MRC@lingling.panda.com> writes:
> Can we have a show of hands of who is running TOPS-20 out there? I
> know about:
> XKL: XKL, Paul Allen, Peter Lothberg
> SC: Peter Lothberg (no longer running?)
> plus 7 Panda systems (of which three seem to be running right now)
I run vanilla TOPS-20 V7.0 on KLH10.
15-May-2002 16:29:27 -0700,1298;000000000020
Return-Path: <MRC@lingling.panda.com>
Received: via tmail-4.1(11) for t20arc; Wed, 15 May 2002 16:29:27 -0700 (PDT)
Return-Path: <MRC@lingling.panda.com>
Received: from lingling.panda.com (Lingling.Panda.C [206.124.149.115]) by Ikkoku-Kan.Panda.COM id QAA18009; Wed, 15 May 2002 16:29:25 -0700 (PDT)
Date: Wed, 15 May 2002 15:17:30 -0800 (PDT)
From: Mark Crispin <MRC@lingling.panda.com>
Subject: Re: anybody using DEC's resolver instead of Chives?
To: lars@nocrew.org
cc: tops-20@lingling.panda.com
In-Reply-To: <85g00t9h5v.fsf@junk.nocrew.org>
Message-ID: <13738948379.9.MRC@lingling.panda.com>
Mark Crispin <MRC@lingling.panda.com> writes:
> Can we have a show of hands of who is running TOPS-20 out there? I
> know about:
> XKL: XKL, Paul Allen, Peter Lothberg
> SC: Peter Lothberg (no longer running?)
> plus 7 Panda systems (of which three seem to be running right now)
^ 8 (I forgot to count my development system)
I run vanilla TOPS-20 V7.0 on KLH10.
Is this an Internet system? If so, is it running TOPS-20 from
the monitor source tapes, or updated from the TSU tapes? DEC's
resolver is on the TSU tapes, and is only on Internet systems.
What I want to count are Internet TOPS-20 systems, not 2020 systems.
-------
16-May-2002 04:50:16 -0700,1673;000000000020
Return-Path: <Bjorn.Victor@it.uu.se>
Received: via tmail-4.1(11) for t20arc; Thu, 16 May 2002 04:50:15 -0700 (PDT)
Return-Path: <Bjorn.Victor@it.uu.se>
Received: from lingling.panda.com (Lingling.Panda.C [206.124.149.115]) by Ikkoku-Kan.Panda.COM id EAA18704; Thu, 16 May 2002 04:50:13 -0700 (PDT)
Received: from meryl.it.uu.se ([130.238.12.42]) by lingling.panda.com with TCP/SMTP; Thu, 16 May 2002 03:09:06 -0800 (PDT)
Received: from Nomine.it.uu.se (root@hamberg.it.uu.se [130.238.9.198])
by meryl.it.uu.se (8.8.5/8.8.5) with ESMTP id NAA12221;
Thu, 16 May 2002 13:09:00 +0200 (MET DST)
Received: by Nomine.it.uu.se (Postfix, from userid 1020)
id 3DEB091FCA; Thu, 16 May 2002 13:08:53 +0200 (CEST)
From: Bjorn Victor <Bjorn.Victor@it.uu.se>
To: Mark Crispin <MRC@lingling.panda.com>
Cc: tops-20@lingling.panda.com
Subject: Re: anybody using DEC's resolver instead of Chives?
References: <13738930941.8.MRC@lingling.panda.com>
Date: Thu, 16 May 2002 13:08:52 +0200
In-Reply-To: <13738930941.8.MRC@lingling.panda.com> (Mark Crispin's message
of "Wed, 15 May 2002 13:41:42 -0800 (PDT)")
Message-ID: <7nn0v0wdrv.fsf@Nomen.it.uu.se>
Lines: 5
User-Agent: Gnus/5.090007 (Oort Gnus v0.07) XEmacs/21.4 (Common Lisp,
i686-pc-linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable
X-MIME-Autoconverted: from 8bit to quoted-printable by meryl.it.uu.se id NAA12221
I'm running a clone of our original v7(21017) system on a kx10 - still
haven't had time to move the disks to klh10. We're not using any
resolver, believe it or not, but I'd be very happy to be able to do it.
-- Bj=F6rn
16-May-2002 11:25:56 -0700,681;000000000020
Return-Path: <MRC@lingling.panda.com>
Received: via tmail-4.1(11) for t20arc; Thu, 16 May 2002 11:25:56 -0700 (PDT)
Return-Path: <MRC@lingling.panda.com>
Received: from lingling.panda.com (Lingling.Panda.C [206.124.149.115]) by Ikkoku-Kan.Panda.COM id LAA19120; Thu, 16 May 2002 11:25:53 -0700 (PDT)
Date: Thu, 16 May 2002 10:09:45 -0800 (PDT)
From: Mark Crispin <MRC@lingling.panda.com>
Subject: TOPS-20, the faster growing OS on the Internet?
To: TOPS-20@lingling.panda.com
Message-ID: <13739154499.8.MRC@lingling.panda.com>
According to the data I've collected, it seems that the number of TOPS-20
systems on the Internet has tripled in the past 6 months.
-------
16-May-2002 23:24:38 -0700,794;000000000020
Return-Path: <MRC@Lingling.Panda.COM>
Received: via tmail-4.1(11) for t20arc; Thu, 16 May 2002 23:24:38 -0700 (PDT)
Return-Path: <MRC@Lingling.Panda.COM>
Received: from Lingling.Panda.COM (Lingling.Panda.C [206.124.149.115]) by Ikkoku-Kan.Panda.COM id XAA19917; Thu, 16 May 2002 23:24:36 -0700 (PDT)
Date: Thu, 16 May 2002 22:01:47 -0700 (PDT)
From: Mark Crispin <MRC@Lingling.Panda.COM>
Subject: bug in ODTIM% in Panda monitor
To: tops-20@Lingling.Panda.COM
Message-ID: <13739284121.9.MRC@Lingling.Panda.COM>
For those of using running the Panda monitor, there is a bug in timezone
output.
At OTT5+15, after:
MOVNS B ; RFC-822 timezones are east from GMT
insert:
TXNE AA,IC%ADS ; Daylight savings time applied?
ADDI T2,1 ; Yes, add an hour for summer time
-------
17-May-2002 10:27:53 -0700,967;000000000020
Return-Path: <MRC@Lingling.Panda.COM>
Received: via tmail-4.1(11) for t20arc; Fri, 17 May 2002 10:27:53 -0700 (PDT)
Return-Path: <MRC@Lingling.Panda.COM>
Received: from Lingling.Panda.COM (Lingling.Panda.C [206.124.149.115]) by Ikkoku-Kan.Panda.COM id KAA20929; Fri, 17 May 2002 10:27:50 -0700 (PDT)
Date: Fri, 17 May 2002 10:10:43 -0700 (PDT)
From: Mark Crispin <MRC@Lingling.Panda.COM>
Subject: 19 years ago today...
To: TOPS-20@Lingling.Panda.COM
Message-ID: <13739416820.8.MRC@Lingling.Panda.COM>
On May 17, 1983 DEC made the infamous decision to kill the PDP-10 product line
in favor of VAX/VMS. It is now 19 years later. VAX no longer exists. The
processor which replaced VAX is dying, as is VMS. The company which bought
DEC will soon cease to exist.
Yet we're still here, and new TOPS-20 systems are sprouting all over the place.
For at least a short while :-) TOPS-20 is the fastest growing operating system
on the Internet.
-------
17-May-2002 10:52:24 -0700,1678;000000000020
Return-Path: <smj@sdf.lonestar.org>
Received: via tmail-4.1(11) for t20arc; Fri, 17 May 2002 10:52:24 -0700 (PDT)
Return-Path: <smj@sdf.lonestar.org>
Received: from Lingling.Panda.COM (Lingling.Panda.C [206.124.149.115]) by Ikkoku-Kan.Panda.COM id KAA20973; Fri, 17 May 2002 10:52:22 -0700 (PDT)
Received: from sdf.lonestar.org ([207.202.214.132]) by Lingling.Panda.COM with TCP/SMTP; Fri, 17 May 2002 10:40:12 -0700 (PDT)
Received: (from smj@localhost)
by sdf.lonestar.org (8.11.6/8.11.6) id g4HHdPE11830;
Fri, 17 May 2002 17:39:25 GMT
From: Stephen Jones <smj@sdf.lonestar.org>
Message-Id: <200205171739.g4HHdPE11830@sdf.lonestar.org>
Subject: Re: 19 years ago today...
To: MRC@Lingling.Panda.COM (Mark Crispin)
Date: Fri, 17 May 2002 17:39:25 +0000 (UTC)
Cc: TOPS-20@Lingling.Panda.COM
In-Reply-To: <13739416820.8.MRC@Lingling.Panda.COM> from "Mark Crispin" at May 17, 2002 10:10:43 AM
X-Mailer: ELM [version 2.5 PL5]
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
> Yet we're still here, and new TOPS-20 systems are sprouting all over the place.
> For at least a short while :-) TOPS-20 is the fastest growing operating system
> on the Internet.
TOPS-20 certainly has alot of winning features. It sort of suffered the
same early hibernation that GENERA did. Maybe this really is the eve of
a renaissance? Micros have become fast enough that both the PDP-10 and
the Symbolics Ivory architectures can be successfully emulated without the
necessity for high power consumption and low capacity, slow and somewhat
unreliable mass storage.
And isn't it fitting for TOPS-20 to make a comeback?
17-May-2002 18:57:35 -0700,2010;000000000020
Return-Path: <jeff@blomberg.com>
Received: via tmail-4.1(11) for t20arc; Fri, 17 May 2002 18:57:35 -0700 (PDT)
Return-Path: <jeff@blomberg.com>
Received: from Lingling.Panda.COM (Lingling.Panda.C [206.124.149.115]) by Ikkoku-Kan.Panda.COM id SAA21547; Fri, 17 May 2002 18:57:33 -0700 (PDT)
Received: from blomberg.vwh.net ([128.121.227.216]) by Lingling.Panda.COM with TCP/SMTP; Fri, 17 May 2002 18:39:22 -0700 (PDT)
Received: from blomberg (12-235-23-9.client.attbi.com [12.235.23.9]) by blomberg.vwh.net (8.11.6) id g4I1dBq97170; Fri, 17 May 2002 19:39:11 -0600 (MDT)
From: "Jeffrey Blomberg" <jeff@blomberg.com>
To: "Mark Crispin" <MRC@Lingling.Panda.COM>, <TOPS-20@Lingling.Panda.COM>
Subject: RE: 19 years ago today...
Date: Fri, 17 May 2002 18:40:46 -0700
Message-ID: <NKEFILAMLNAALHPFPHCICEMGCGAA.jeff@blomberg.com>
MIME-Version: 1.0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
In-Reply-To: <13739416820.8.MRC@Lingling.Panda.COM>
Importance: Normal
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
19 years....scary - yes, I remember those dark days (especially when we just
bought one..... :-( )
Oh, the memories....
-Jeff Blomberg
U of Hawaii, back then (SN 2905)
-----Original Message-----
From: Mark Crispin [mailto:MRC@Lingling.Panda.COM]
Sent: Friday, May 17, 2002 10:11 AM
To: TOPS-20@Lingling.Panda.COM
Subject: 19 years ago today...
On May 17, 1983 DEC made the infamous decision to kill the PDP-10 product
line
in favor of VAX/VMS. It is now 19 years later. VAX no longer exists. The
processor which replaced VAX is dying, as is VMS. The company which bought
DEC will soon cease to exist.
Yet we're still here, and new TOPS-20 systems are sprouting all over the
place.
For at least a short while :-) TOPS-20 is the fastest growing operating
system
on the Internet.
-------
21-Jun-2002 11:41:57 -0700,1805;000000000020
Return-Path: <MRC@Panda.COM>
Received: via tmail-4.1(11) (invoked by user mrc) for t20arc; Fri, 21 Jun 2002 11:41:57 -0700 (PDT)
Return-Path: <MRC@Panda.COM>
Received: from lingling.panda.com (Lingling.Panda.C [206.124.149.115]) by Ikkoku-Kan.Panda.COM id LAA03489; Fri, 21 Jun 2002 11:41:55 -0700 (PDT)
Received: from Ikkoku-Kan.Panda.COM ([206.124.149.114] -- may be forged) by lingling.panda.com with TCP/SMTP; Fri, 21 Jun 2002 12:37:43 -0700 (PDT)
Received: from Ikkoku-Kan.Panda.COM (Ikkoku-Kan.Panda.COM [192.107.14.50]) by Ikkoku-Kan.Panda.COM id LAA03481; Fri, 21 Jun 2002 11:25:49 -0700 (PDT)
Date: Fri, 21 Jun 2002 11:23:55 -0700 (PDT)
From: Mark Crispin <MRC@Panda.COM>
Sender: Mark Crispin <mrc@Ikkoku-Kan.Panda.COM>
To: TOPS-20 Hackers and Yackers <TOPS-20@Lingling.Panda.COM>
Message-ID: <MailManager.1024683835.1541.mrc@Ikkoku-Kan.Panda.COM>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
** Begin Forwarded Message **
---------- Forwarded message ----------
Date: Fri, 21 Jun 2002 11:28:24 -0400
From: Jana Bergman <JBergman@comforce.com>
To: "'slime@atmos.washington.edu'" <slime@atmos.washington.edu>
Subject: The Slime: PDP-10
David Warren suggested I use this list-serv to see if anyone is interested!
I have a client (and well known local celebrity) who is creating a computing
museum in Seattle. They have several PDP-10s that will be in production,
and they are looking for a field engineer to maintain the systems. This
position would run approximately 20 hours a week. If you have interest,
please feel free to contact me.
Thank you for your time -
Jana Bergman
Director - Comforce
(425) 605-2334 (Redmond)
jbergman@comforce.com
The Slime (Newsletter and mailinglist of SeaLUG)
http://slime.atmos.washington.edu
30-Oct-2002 19:52:37 -0800,8072;000000000020
Return-Path: <MRC@Panda.COM>
Received: via tmail-4.1(11) (invoked by user mrc) for t20arc; Wed, 30 Oct 2002 19:52:37 -0800 (PST)
Return-Path: <MRC@Panda.COM>
Received: from Ikkoku-Kan.Panda.COM (Ikkoku-Kan.Panda.COM [192.107.14.50]) by Ikkoku-Kan.Panda.COM id TAA21668; Wed, 30 Oct 2002 19:52:33 -0800 (PST)
Received: via tmail-2000(13) (invoked by user mailnull) for mrc; Wed, 30 Oct 2002 05:21:38 -0800 (PST)
Received: from mailscan4.cac.washington.edu (mailscan4.cac.washington.edu [140.142.33.15])
by ndcms.cac.washington.edu (8.12.1+UW01.12/8.12.1+UW02.08) with SMTP id g9UDLcls025592
for <mrc@ndcms.cac.washington.edu>; Wed, 30 Oct 2002 05:21:38 -0800
Received: FROM mx2.cac.washington.edu BY mailscan4.cac.washington.edu ; Wed Oct 30 05:21:37 2002 -0800
Received: from mta6.srv.hcvlny.cv.net (mta6.srv.hcvlny.cv.net [167.206.5.17])
by mx2.cac.washington.edu (8.12.1+UW01.12/8.12.1+UW02.09) with ESMTP id g9UDLbvi026167
for <MRC@CAC.Washington.EDU>; Wed, 30 Oct 2002 05:21:37 -0800
Received: from optonline.net (ool-182f33c4.dyn.optonline.net [24.47.51.196])
by mta6.srv.hcvlny.cv.net
(iPlanet Messaging Server 5.2 HotFix 0.9 (built Jul 29 2002))
with ESMTP id <0H4S00DN9QASPB@mta6.srv.hcvlny.cv.net> for
MRC@CAC.Washington.EDU; Wed, 30 Oct 2002 08:18:30 -0500 (EST)
Date: Wed, 30 Oct 2002 08:17:48 -0500
From: Thomas DeBellis <slogin@optonline.net>
Subject: DECnet on Tops-20
To: Mark Crispin <MRC@CAC.Washington.EDU>
Message-id: <3DBFDBFC.9E22B091@optonline.net>
MIME-version: 1.0
X-Mailer: Mozilla 4.5 [en]C-CCK-MCD BA45DSL (WinNT; U)
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7BIT
X-Accept-Language: en
ReSent-Date: Wed, 30 Oct 2002 19:51:37 -0800 (PST)
ReSent-From: Mark Crispin <MRC@Panda.COM>
ReSent-Sender: Mark Crispin <mrc@Ikkoku-Kan.Panda.COM>
ReSent-Subject: this seemed to be of general interest
ReSent-To: TOPS-20 Hackers and Yackers <TOPS-20@Panda.COM>
ReSent-Message-ID: <MailManager.1036036297.7566.mrc@Ikkoku-Kan.Panda.COM>
Howdy the MRC,
Now that an increasing number of people are actually getting and
running Tops-20 again, I thought that it might be a nice friendly
gesture on my part to dust off a program that I wrote a long time ago
at Columbia and give it to the community as something that might be of
use between (hopefully) communicating Tops-20 systems.
Around 1984, not that long after DEC cancelled Jupiter, they were
still trying to keep us with the company and signed us up to test the
CI and NI, telling us how great it was going to be and how we wouldn't
need new processors. [What was that that Gorin said about jumping out
a window, again? :-) ]
Well, we planned on using the CI for libraries and shared directories
for students, to allow them to log on any machine in case one was down
(which happened a lot, sigh), but we couldn't do that for another
year. If you will remember, version six was quite late and REALLY
buggy. We had a CI, but no production ready software (or no software
at all, if memory serves me correctly).
So, we didn't dare risk using it for the academic year and we were
stuck with machines that were connected via KMC11's. Now the KMC was
a decent enough piece of hardware, but the associated DECnet software
was not up to the task. We had hoped to use NFT/FAL to transfer files
around, but this wouldn't work for a number of reasons.
NFT/FAL implemented the 'shared Digital' paradigm, which meant that
they followed the losing VMS standard, were buggy and didn't work
well. As I remember, one problem was that FAL wouldn't create
directories and there was no way to script this. I seem to remember
NFT not being able to handle a wildcarded directory, but I could be
wrong about that.
But, the real problem was that the late 5.1/early 6.0 DECnet transport
implementation was SERIOUSLY buggy. The DTE's (or was that DNC?)
would crash, the pipes would clog, the JFNs would disappear, but
worse, data would get corrupted on the famous error free network.
NFT/FAL wouldn't detect errors and used VMS standard recovery for
major error (viz: crash, hang the job or both). The shipped support
programs (such as NMLT20) were quite sensitive and crashed, hung or
went into wild CPU usage at the slightest provocation
So, I wrote my only DECnet application (and my last major program
under Tops-20). VIKING is something like RDIST under Unix. It takes
a set of directories and makes a small database file for each one. A
local client then talks to a remote server and decides which files and
directories need to be updated (or created/tossed) and goes about
transfering the data.
It is really, REALLY aggressive about checking for AND recovering from
network errors, so much so that you could turn off a DNC during the
middle of a transfer and leave it off for well over an hour (i.e., fix
it) and when it was turned back on, the transfer would recover and
continue (these were the early days of Kermit, so we all had error
free protocols on the brain).
The program is wonderful in some ways and had some absolutely winning
code in it (connection renegotiation, for example). As it was written
in emergency mode (i.e., we found out that the CI wasn't coming about
four weeks before classes started), it has some bletcherousness, sigh.
There is some truely profligate stack usage, a lot of wipe, yank and
yank someplace else, group management was completely differed to
another program (Gidget), a possibly inadequate remote file checking
mechanism, silly comments and only the barest minimum of security.
But it worked wonderfully for the year that we didn't have the CI,
keeping all of our directories in synch and allowing students to log
in anywhere in case of a system crash. In fact, we kept using it even
after we got working shared file software, to keep redundant copies of
key packages (i.e., EMACS) on seperate disks in case the CI broke. I
had always wanted to convert it to TCP/IP, but I never had time as I
then got stuck (er, assigned to) creating a real ID system for Ultrix
and well, you know how time passes.
Looking over all the people starting to play with Tops-20, I had been
thinking about dusting VIKING off for quite some time, but I didn't
have it on electronic media that I could read. I only had a Xerox
9700 listing. As the source code is nearly 84 (Tops-20) pages, I had
no real inclination to just type the whole thing in again. I mean, I
have *some* spare time, but nothing like that.
My wife (yup, I finally found somebody dumb enough, er...THE LOVE OF
MY LIFE!) recently got a small printer/scanner combo (a Lexmark X83).
The thing doesn't do a half bad job of OCR, either. So, I spent some
time this weekend feeding the Xerox 9700 sheets through the thing and
then touching up the OCR mistakes (about 5%).
I ftp'ed it over to the Toad and then assembled and linked it. But it
didn't run. Imagine my surprise when I found out that the XKL
version of Tops-20 didn't have DECnet loaded (i.e., no DCN or SRV
device). I seem to remember the reason for this being that there was
fear that the code wouldn't run in a non-zero section (but I always
thought that Tops-20 was better off without DECnet anyway if you could
get winning ARPAnet, as we eventually did).
Well, I could convert the program to use XKL pipes to check it out and
then do the (trivial for me) port to use TCP/IP, but I'd feel more
comfortable using a system with DECnet so that I could make sure that
none of the original code paths have been damaged during the scan. I
don't actually need DECnet to go anywhere, I could just connect to the
local system.
Do you know of any system that I might use for awhile to do a simple
DECnet checkout as listed above? Otherwise, I'll just give up and
fake it with pipes and then get the TCP/IP implementation knocked off.
Finally, did you know of a KLH10/Tops-20 distribution for Windows? My
Linux box is biting dust right now.
Thanks!!
--T
30-Oct-2002 20:24:28 -0800,1868;000000000020
Return-Path: <MRC@Panda.COM>
Received: via tmail-4.1(11) (invoked by user mrc) for t20arc; Wed, 30 Oct 2002 20:24:27 -0800 (PST)
Return-Path: <MRC@Panda.COM>
Received: from lingling.panda.com (Lingling.Panda.C [206.124.149.115]) by Ikkoku-Kan.Panda.COM id UAA21824; Wed, 30 Oct 2002 20:24:26 -0800 (PST)
Received: from Ikkoku-Kan.Panda.COM (panda.com [206.124.149.114]) by lingling.panda.com with TCP/SMTP; Wed, 30 Oct 2002 20:03:27 -0800 (PST)
Received: from Ikkoku-Kan.Panda.COM (Ikkoku-Kan.Panda.COM [192.107.14.50]) by Ikkoku-Kan.Panda.COM id UAA21729; Wed, 30 Oct 2002 20:03:19 -0800 (PST)
Date: Wed, 30 Oct 2002 19:52:47 -0800 (PST)
From: Mark Crispin <MRC@CAC.Washington.EDU>
Sender: Mark Crispin <mrc@Ikkoku-Kan.Panda.COM>
Subject: re: DECnet on Tops-20
To: Thomas DeBellis <slogin@optonline.net>
cc: tops-20@lingling.panda.com
In-Reply-To: <3DBFDBFC.9E22B091@optonline.net>
Message-ID: <MailManager.1036036367.7566.mrc@Ikkoku-Kan.Panda.COM>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Hi Tom -
It is nice to hear from you again. Your message seemed to be of general
interest, so I took the liberty of forwarding it to the TOPS-20 list.
The Panda monitor includes DECnet. DECnet definitely runs in a non-zero
section; in fact, it took a great deal of work for me in the mid-80s to make
it run in section 0 on a 2020.
I don't know of a Windows version of KLH10; I ported an ancient KS10-only
version a long time ago but that isn't useful for running anything after 4.1.
I do have a distribute which includes both KLH10 and a PS filesystem with the
Panda monitor and lots of other goodies. It's 142MB as a compressed gz file,
either of a CD-ROM image or a tarball. If you send me usable scp credentials
I can upload it to your machine, or I can look into getting a CD-ROM burned
for you.
-- Mark --
3-Nov-2002 18:24:44 -0800,2552;000000000020
Return-Path: <slogin@optonline.net>
Received: via tmail-4.1(11) for t20arc; Sun, 3 Nov 2002 18:24:44 -0800 (PST)
Return-Path: <slogin@optonline.net>
Received: from lingling.panda.com (Lingling.Panda.C [206.124.149.115]) by Ikkoku-Kan.Panda.COM id SAA28930; Sun, 3 Nov 2002 18:24:41 -0800 (PST)
Received: from mta10.srv.hcvlny.cv.net ([167.206.5.45]) by lingling.panda.com with TCP/SMTP; Sun, 3 Nov 2002 18:04:10 -0800 (PST)
Received: from optonline.net (ool-182f33c4.dyn.optonline.net [24.47.51.196])
by mta10.srv.hcvlny.cv.net
(iPlanet Messaging Server 5.2 HotFix 0.9 (built Jul 29 2002))
with ESMTP id <0H5100K5R497GQ@mta10.srv.hcvlny.cv.net> for
TOPS-20@Lingling.Panda.COM; Sun, 03 Nov 2002 21:00:44 -0500 (EST)
Date: Sun, 03 Nov 2002 20:59:46 -0500
From: Thomas DeBellis <slogin@optonline.net>
Subject: GnuEmacs ange-ftp.el for Tops-20
To: TOPS-20@Lingling.Panda.COM
Message-id: <3DC5D492.E33CF568@optonline.net>
MIME-version: 1.0
X-Mailer: Mozilla 4.5 [en]C-CCK-MCD BA45DSL (WinNT; U)
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7BIT
X-Accept-Language: en
Has anyone hacked up a copy of Ange-Ftp that will work to Tops-20?
Right now, the current version is broken in a number of ways.
While it will sign on to Tops-20, it tries to send a PWD to find
out where it is connected. Since the Tops-20 FTPSRT doesn't have
that command (and reports as such), ange-ftp gronks, leaving the
connection open.
A synonym for PWD is "QUOTE CWD .", which connects you to your
currently connected directory and then (more importantly), types
out where youi are connected, viz:
ftp> quote CWD .
250 Connected to TOAD:<SLOGIN>.
I spent some time hacking ange-ftp to send this, but I still can't
do a DIRED, write or read a file or do anything else useful. I'm
sure that there are other things to do, but before I make a project
out of this, I thought that I would ask to see if anyone else had
noticed and looked at it.
Ange-ftp actually looks like it has some thought put into it. There
is support for MTS (yeow!), losing operating systems such as VM/CMS,
and some crock named VMS. I have to believe that it would be possible,
somehow, to put support in for winning operating systems like Tops-20.
Finally, the obligatory flame bait: I noticed that gnuemacs is
running on the Toad and that other Gnu packages are being ported.
Does this mean that RMS will start trying to inspire us tall o call
it GNU/Tops-20? Or Gnu-20? Tops-Gnu? The mind boggles...
4-Nov-2002 18:48:44 -0800,1532;000000000020
Return-Path: <MRC@Panda.COM>
Received: via tmail-4.1(11) (invoked by user mrc) for t20arc; Mon, 4 Nov 2002 18:48:44 -0800 (PST)
Return-Path: <MRC@Panda.COM>
Received: from Lingling.Panda.COM (Lingling.Panda.C [206.124.149.115]) by Ikkoku-Kan.Panda.COM id SAA01303; Mon, 4 Nov 2002 18:48:41 -0800 (PST)
Received: from Ikkoku-Kan.Panda.COM (Panda.COM [206.124.149.114]) by Lingling.Panda.COM with TCP/SMTP; Mon, 4 Nov 2002 18:23:54 -0800 (PST)
Received: from Ikkoku-Kan.Panda.COM (Ikkoku-Kan.Panda.COM [192.107.14.50]) by Ikkoku-Kan.Panda.COM id SAA01272; Mon, 4 Nov 2002 18:23:44 -0800 (PST)
Date: Mon, 4 Nov 2002 18:15:45 -0800 (PST)
From: Mark Crispin <MRC@Panda.COM>
Sender: Mark Crispin <mrc@Ikkoku-Kan.Panda.COM>
Subject: re: GnuEmacs ange-ftp.el for Tops-20
To: Thomas DeBellis <slogin@optonline.net>
cc: TOPS-20@Lingling.Panda.COM
In-Reply-To: <3DC5D492.E33CF568@optonline.net>
Message-ID: <MailManager.1036462545.29255.mrc@Ikkoku-Kan.Panda.COM>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
"CWD ." may work on Toad TOPS-20 systems, but it doesn't work on Panda TOPS-20
systems (and probably also SC machines).
A sneaky way that works everywhere is to send a STAT<SP> (you need to have
that trailing space) and then look at the first 212- response line. However,
that will lose if the directory is empty.
What does it need the current working directory for? Of course, on TOPS-20,
you can assume that it is <loginusername> until such time as a CWD to
elsewhere has been done.
4-Nov-2002 20:09:57 -0800,3889;000000000020
Return-Path: <slogin@optonline.net>
Received: via tmail-4.1(11) for t20arc; Mon, 4 Nov 2002 20:09:57 -0800 (PST)
Return-Path: <slogin@optonline.net>
Received: from Lingling.Panda.COM (Lingling.Panda.C [206.124.149.115]) by Ikkoku-Kan.Panda.COM id UAA01390; Mon, 4 Nov 2002 20:09:54 -0800 (PST)
Received: from mta2.srv.hcvlny.cv.net ([167.206.5.5]) by Lingling.Panda.COM with TCP/SMTP; Mon, 4 Nov 2002 19:45:53 -0800 (PST)
Received: from optonline.net (ool-182f33c4.dyn.optonline.net [24.47.51.196])
by mta2.srv.hcvlny.cv.net
(iPlanet Messaging Server 5.2 HotFix 0.9 (built Jul 29 2002))
with ESMTP id <0H5300LF53921U@mta2.srv.hcvlny.cv.net> for
TOPS-20@Lingling.Panda.COM; Mon, 04 Nov 2002 22:34:15 -0500 (EST)
Date: Mon, 04 Nov 2002 22:33:06 -0500
From: Thomas DeBellis <slogin@optonline.net>
Subject: Re: GnuEmacs ange-ftp.el for Tops-20
To: Mark Crispin <MRC@Panda.COM>
Cc: TOPS-20@Lingling.Panda.COM
Message-id: <3DC73BF2.C4F7341F@optonline.net>
MIME-version: 1.0
X-Mailer: Mozilla 4.5 [en]C-CCK-MCD BA45DSL (WinNT; U)
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7BIT
X-Accept-Language: en
References: <MailManager.1036462545.29255.mrc@Ikkoku-Kan.Panda.COM>
As I said, I only glanced through the code, did some minor hacking and
tweaking and still couldn't get it to work. Once I satisfied myself
that it would probably require some real effort, I punted. However,
I'll most likely revisit the issue again, once I start getting really
annoyed. Here's what I remember from about an hour's work. It
appears that results of the PWD are used in two general ways.
The first is to guess the type of system by examining the returned
directory syntax (it also looks at the error message from the FTP
server). Here it seems that I could put in code to look for the
Tops-20 FTPSRT error response from a PWD and then flag a Tops-20 host.
I'd need a new system type and then put in code to respect that in a
number of places. Fairly straightforward but dreary hacking.
Second, the current directory looks like it is put into the exand-dir
hash table to enable the user to perform expansion on losing systems
that don't have built in file name and command completion.
The PWD results also appear to be used when building 'canonical'
(i.e., Unix) file specifications. This allows you to express things
like 'M-X cd<CR>./bar' which--assuming you were logged in as user foo
and were connected a login default directory of /usr/foo--would put
you into /usr/foo/bar.
That is more convienent then the default Tops-20 action of having you
have to type the entire directory specification (viz, Connect
PS:<FOO.BAR>) when changing directories. I seem to remember Columbia
having a small locally written utility that hacked strings to allow
you to not have to type the entire specification in RCDIR% and
friends, but I don't remember anything more about it.
It's a little harder to do, but I guess one way would be to assume
something like /PS/LOGINUSERNAME for the initial directory on login
and then record the results of subsequent CWD's to fake the output
of the PWD when required. I might need to hook CD to do that.
I can't remember exactly , but I think it also chokes on the results
of the NLIST when building a DIRED buffer for the remote system.
Mark Crispin wrote:
> CWD ." may work on Toad TOPS-20 systems, but it doesn't work on
> "Panda TOPS-20 systems (and probably also SC machines).
>
> A sneaky way that works everywhere is to send a STAT<SP> (you need
> to have that trailing space) and then look at the first 212-
> response line. However, that will lose if the directory is empty.
>
> What does it need the current working directory for? Of course, on
> TOPS-20, you can assume that it is <loginusername> until such time
> as a CWD to elsewhere has been done.
4-Dec-2002 11:41:31 -0800,2378;000000000020
Return-Path: <MRC@Shimo-Tomobiki.Panda.COM>
Received: via tmail-4.1(11) for t20arc; Wed, 4 Dec 2002 11:41:30 -0800 (PST)
Return-Path: <MRC@Shimo-Tomobiki.Panda.COM>
Received: from lingling.panda.com (Lingling.Panda.C [206.124.149.115]) by Ikkoku-Kan.Panda.COM id LAA05759; Wed, 4 Dec 2002 11:41:28 -0800 (PST)
Received: from Shimo-Tomobiki.Panda.COM ([206.124.149.114]) by lingling.panda.com with TCP/SMTP; Wed, 4 Dec 2002 11:14:27 -0800 (PST)
Date: Wed, 4 Dec 2002 11:11:19 -0800 (PST)
From: Mark Crispin <MRC@Shimo-Tomobiki.Panda.COM>
Subject: laptop wireless DCHP TOPS-20 now a reality
To: TOPS-20@Lingling.Panda.COM
Message-ID: <13792129720.8.MRC@Shimo-Tomobiki.Panda.COM>
This email was originated on a TOPS-20 system running on a laptop, and
transmitted via wireless to another TOPS-20 system for delivery.
Although it isn't news that TOPS-20 can be run on a laptop, what is new
is that it is using DHCP and that the laptop is Windows XP. On top of
Windows XP, I am running VMware, which in turn is hosting a Mandrake
Linux system, which in turn is running KLH10.
The laptop has a DHCP assigned address for the wireless card which the
WinXP system gets. VMware provides NAT service, with the wireless card
being the WAN and a 192.168.197.x network being the LAN. The Linux
system is assigned 192.168.197.128 via DHCP provided by VMware, and the
TOPS-20 system is arbitrarily assigned 192.168.197.20.
The wireless access point, in turn, is on a NATed LAN.
What is amazing is that this all works. What is even more amazing is
that this all works with an operating system that hasn't had much
development in 15 years. What is even more amazing is that it actually
all happens in a reasonable amount of time.
I had to make some changes in KLH10 in order to get it to run well on
a VMware-hosted Linux system. The time synchronization that VMware
does with Linux occasionally causes gettimeofday() to run backwards,
which caused horrible confusion to KLH10 (including timed out disk and
network I/O and resultant filesystem corruption...). Once TOPS-20 got
a hardware clock that didn't time-warp all was well.
I can not emphasize how incredibly cool this is all is. It actually
runs well enough to be used seriously. Now, if only we can find
someone crazy^H^H^H^H^Hdedicated enough to get Pine and SSH ported!
-------
5-Dec-2002 00:47:48 -0800,1544;000000000020
Return-Path: <lars@junk.nocrew.org>
Received: via tmail-4.1(11) for t20arc; Thu, 5 Dec 2002 00:47:48 -0800 (PST)
Return-Path: <lars@junk.nocrew.org>
Received: from lingling.panda.com (Lingling.Panda.C [206.124.149.115]) by Ikkoku-Kan.Panda.COM id AAA06613; Thu, 5 Dec 2002 00:47:45 -0800 (PST)
Received: from junk.nocrew.org ([213.242.147.30]) by lingling.panda.com with TCP/SMTP; Thu, 5 Dec 2002 00:21:34 -0800 (PST)
Received: from lars by junk.nocrew.org with local (Exim 3.35 #1 (Debian))
id 18JrG4-00058v-00; Thu, 05 Dec 2002 09:21:20 +0100
To: Mark Crispin <MRC@Shimo-Tomobiki.Panda.COM>
Cc: TOPS-20@Lingling.Panda.COM
Subject: Re: laptop wireless DCHP TOPS-20 now a reality
References: <13792129720.8.MRC@Shimo-Tomobiki.Panda.COM>
From: Lars Brinkhoff <lars@nocrew.org>
Organization: nocrew
Date: 05 Dec 2002 09:21:20 +0100
In-Reply-To: <13792129720.8.MRC@Shimo-Tomobiki.Panda.COM>
Message-ID: <857keolvun.fsf@junk.nocrew.org>
Lines: 10
User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: lars brinkhoff <lars@junk.nocrew.org>
Mark Crispin <MRC@Shimo-Tomobiki.Panda.COM> writes:
> Now, if only we can find someone crazy^H^H^H^H^Hdedicated enough to
> get Pine and SSH ported!
I'm working on a GNU C Library port, and an SSH port may be in the
pipeline when glibc is sufficiently functional.
--
Lars Brinkhoff http://lars.nocrew.org/ Linux, GCC, PDP-10,
Brinkhoff Consulting http://www.brinkhoff.se/ HTTP programming
5-Dec-2002 10:59:35 -0800,2056;000000000020
Return-Path: <MRC@Panda.COM>
Received: via tmail-4.1(11) (invoked by user mrc) for t20arc; Thu, 5 Dec 2002 10:59:34 -0800 (PST)
Return-Path: <MRC@Panda.COM>
Received: from lingling.panda.com (Lingling.Panda.C [206.124.149.115]) by Ikkoku-Kan.Panda.COM id KAA07282; Thu, 5 Dec 2002 10:59:32 -0800 (PST)
Received: from Ikkoku-Kan.Panda.COM (panda.com [206.124.149.114]) by lingling.panda.com with TCP/SMTP; Thu, 5 Dec 2002 10:35:04 -0800 (PST)
Received: from Ikkoku-Kan.Panda.COM (Ikkoku-Kan.Panda.COM [192.107.14.50]) by Ikkoku-Kan.Panda.COM id KAA07257; Thu, 5 Dec 2002 10:34:56 -0800 (PST)
Date: Thu, 5 Dec 2002 10:29:57 -0800 (PST)
From: Mark Crispin <MRC@Panda.COM>
Sender: Mark Crispin <mrc@Ikkoku-Kan.Panda.COM>
Subject: Re: laptop wireless DCHP TOPS-20 now a reality
To: Lars Brinkhoff <lars@nocrew.org>
cc: TOPS-20@Lingling.Panda.COM
In-Reply-To: <857keolvun.fsf@junk.nocrew.org>
Message-ID: <MailManager.1039112997.15587.mrc@Ikkoku-Kan.Panda.COM>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
On 05 Dec 2002 09:21:20 +0100, Lars Brinkhoff wrote:
> I'm working on a GNU C Library port, and an SSH port may be in the
> pipeline when glibc is sufficiently functional.
Yes, I know. I am very interested in the progress of your GNU C work. Please
keep the TOPS-20 list up to date.
The c-client library already builds under TOPS-20, as does the mtest and
mailutil programs. It would be a relatively simple matter to get imapd to
build under TOPS-20 as well, although it would be a bit sad for me to give up
on MAPSER. MAPSER is still RFC 1176, but it was the penultimate TOPS-20
assembly language program. I just need to write a TOPS-20 local mailbox
driver (native, rather than port the driver from UNIX).
For Pine, we need to get the Pico and Pine GUI code ported. That'll be a lot
more work due to all the terminal I/O hacking. I think that it'd be way cool
to have Pine on TOPS-20. Even more cool to have OpenSSL ported as well, so we
can have an SSL-capable Pine and imapd on TOPS-20!
9-Dec-2002 22:26:44 -0800,1302;000000000020
Return-Path: <MRC@lingling.panda.com>
Received: via tmail-4.1(11) for t20arc; Mon, 9 Dec 2002 22:26:44 -0800 (PST)
Return-Path: <MRC@lingling.panda.com>
Received: from lingling.panda.com (Lingling.Panda.C [206.124.149.115]) by Ikkoku-Kan.Panda.COM id WAA14490; Mon, 9 Dec 2002 22:26:42 -0800 (PST)
Date: Mon, 9 Dec 2002 22:08:06 -0800 (PST)
From: Mark Crispin <MRC@lingling.panda.com>
Subject: UTF-9, UTF-18, UTF-36
To: TOPS-20@lingling.panda.com
Message-ID: <13793560003.9.MRC@lingling.panda.com>
Lately, I've been thinking about PDP-10 formats for Unicode. We can use
UTF-7, but that format is incredibly clanky. Of course, if we go to 8-bits,
we then have the question about what to do with the other 4-bits.
Since we have an obviously far superior architecture to the 8-bit bytes that
the rest of the world is stuck with, we should develop formats based upon the
9-bit byte. Of course, we would also express this in octal the way god
intended.
I've been mulling over various ideas of what UTF-9, UTF-18, and UTF-36 would
look like. The requirements are that (1) it's way cool and (2) is
unimplementable in any reasonable fashion on machines based on 8-bit bytes.
I'd like to get an RFC written and published by April 1, 2003. Any comments
or suggestions?
-------
10-Dec-2002 06:55:08 -0800,2342;000000000020
Return-Path: <AMartin.MA.UltraNet@RCN.Com>
Received: via tmail-4.1(11) for t20arc; Tue, 10 Dec 2002 06:55:07 -0800 (PST)
Return-Path: <AMartin.MA.UltraNet@RCN.Com>
Received: from lingling.panda.com (Lingling.Panda.C [206.124.149.115]) by Ikkoku-Kan.Panda.COM id GAA15041; Tue, 10 Dec 2002 06:55:05 -0800 (PST)
Received: from service0.etnus.com ([204.164.68.91]) by lingling.panda.com with TCP/SMTP; Tue, 10 Dec 2002 06:38:44 -0800 (PST)
Received: from RCN.Com (ralfie.etnus.com [204.164.68.75])
by service0.etnus.com (8.11.1/8.11.0) with ESMTP id gBAEce810117;
Tue, 10 Dec 2002 09:38:41 -0500 (EST)
Sender: amartin@etnus.com
Message-ID: <3DF5FC70.E85D45C6@RCN.Com>
Date: Tue, 10 Dec 2002 09:38:40 -0500
From: "Alan H. Martin" <AMartin.MA.UltraNet@RCN.Com>
X-Mailer: Mozilla 4.78 [en] (X11; U; OSF1 V4.0 alpha)
X-Accept-Language: en, en-US, en-GB, es
MIME-Version: 1.0
To: Mark Crispin <MRC@lingling.panda.com>
CC: TOPS-20@lingling.panda.com
Subject: Re: UTF-9, UTF-18, UTF-36
References: <13793560003.9.MRC@lingling.panda.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Mark Crispin wrote:
>
> Lately, I've been thinking about PDP-10 formats for Unicode. We can use
> UTF-7, but that format is incredibly clanky. Of course, if we go to 8-bits,
> we then have the question about what to do with the other 4-bits.
>
> Since we have an obviously far superior architecture to the 8-bit bytes that
> the rest of the world is stuck with, we should develop formats based upon the
> 9-bit byte. Of course, we would also express this in octal the way god
> intended.
The intended (albeit never implemented) architecture for 8-bit ASCII
support in Cobol (and Fortran) was indeed to use 9-bit bytes as the
physical representation.
> I've been mulling over various ideas of what UTF-9, UTF-18, and UTF-36 would
> look like. The requirements are that (1) it's way cool and (2) is
> unimplementable in any reasonable fashion on machines based on 8-bit bytes.
I suspect the high-order bit was RTD/MBZ.
> I'd like to get an RFC written and published by April 1, 2003. Any comments
> or suggestions?
Notwithstanding that publication date, I've BCCed a few engineers who
might choose to comment.
/AHM
--
Alan Howard Martin AMartin.MA.UltraNet@RCN.Com
10-Dec-2002 08:25:32 -0800,1665;000000000020
Return-Path: <sra@hactrn.net>
Received: via tmail-4.1(11) for t20arc; Tue, 10 Dec 2002 08:25:32 -0800 (PST)
Return-Path: <sra@hactrn.net>
Received: from lingling.panda.com (Lingling.Panda.C [206.124.149.115]) by Ikkoku-Kan.Panda.COM id IAA15138; Tue, 10 Dec 2002 08:25:30 -0800 (PST)
Received: from thrintun.hactrn.net ([66.92.66.67]) by lingling.panda.com with TCP/SMTP; Tue, 10 Dec 2002 08:05:52 -0800 (PST)
Received: from thrintun.hactrn.net (localhost [::1])
by thrintun.hactrn.net (Postfix) with ESMTP
id 4C16D1957; Tue, 10 Dec 2002 11:05:50 -0500 (EST)
Date: Tue, 10 Dec 2002 11:05:50 -0500
From: Rob Austein <sra@hactrn.net>
To: Mark Crispin <MRC@lingling.panda.com>
Cc: TOPS-20@lingling.panda.com
Subject: Re: UTF-9, UTF-18, UTF-36
In-Reply-To: <13793560003.9.MRC@lingling.panda.com>
References: <13793560003.9.MRC@lingling.panda.com>
User-Agent: Wanderlust/2.8.1 (Something) Emacs/20.7 Mule/4.0 (HANANOEN)
MIME-Version: 1.0 (generated by SEMI 1.14.4 - "Hosorogi")
Content-Type: text/plain; charset=US-ASCII
Message-Id: <20021210160550.4C16D1957@thrintun.hactrn.net>
At Mon, 9 Dec 2002 22:08:06 -0800 (PST),Mark Crispin <MRC@lingling.panda.com> wrote:
>
> I've been mulling over various ideas of what UTF-9, UTF-18, and UTF-36 would
> look like. The requirements are that (1) it's way cool and (2) is
> unimplementable in any reasonable fashion on machines based on 8-bit bytes.
UTF-36 seems the obvious choice, since it allows you to add value on
top of UCS-4 without all the whacky "fairness" tradeoffs in the other
encodings of 10646. So what you need is an indispensable purpose to
be served by the extra four bits.
10-Dec-2002 09:16:46 -0800,2273;000000000020
Return-Path: <dboyes@sinenomine.net>
Received: via tmail-4.1(11) for t20arc; Tue, 10 Dec 2002 09:16:46 -0800 (PST)
Return-Path: <dboyes@sinenomine.net>
Received: from lingling.panda.com (Lingling.Panda.C [206.124.149.115]) by Ikkoku-Kan.Panda.COM id JAA15197; Tue, 10 Dec 2002 09:16:43 -0800 (PST)
Received: from mail.sinenomine.net ([192.204.203.218]) by lingling.panda.com with TCP/SMTP; Tue, 10 Dec 2002 08:58:52 -0800 (PST)
Received: from ebola.sinenomine.net (ebola.sinenomine.net [192.168.101.27])
by mail.sinenomine.net (8.11.2/8.11.2/SuSE Linux 8.11.1-0.5) with ESMTP id gBAHvau02873;
Tue, 10 Dec 2002 12:57:36 -0500
Received: by ebola.sinenomine.net with Internet Mail Service (5.5.1960.3)
id <VZP69A9A>; Tue, 10 Dec 2002 11:57:26 -0500
Message-ID: <F1F2B0484A1ED511904F08002BBDE5792182A2@ebola.sinenomine.net>
From: David Boyes <dboyes@sinenomine.net>
To: "'Rob Austein'" <sra@hactrn.net>,
"'Mark Crispin'"
<MRC@lingling.panda.com>
Cc: "'TOPS-20@lingling.panda.com'" <TOPS-20@lingling.panda.com>
Subject: RE: UTF-9, UTF-18, UTF-36
Date: Tue, 10 Dec 2002 11:57:26 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.1960.3)
Content-Type: text/plain
Reserve them for tonal indicators; or use a bit or two to indicate
vocalized/non-vocalized, aspirant/non-aspirant, and reserve two bits for
"Future Use". Must be forward thinking, after all.
-- db
David Boyes
Sine Nomine Associates
> -----Original Message-----
> From: Rob Austein [mailto:sra@hactrn.net]
> Sent: Tuesday, December 10, 2002 11:06 AM
> To: Mark Crispin
> Cc: TOPS-20@lingling.panda.com
> Subject: Re: UTF-9, UTF-18, UTF-36
>
>
> At Mon, 9 Dec 2002 22:08:06 -0800 (PST),Mark Crispin
> <MRC@lingling.panda.com> wrote:
> >
> > I've been mulling over various ideas of what UTF-9, UTF-18,
> and UTF-36 would
> > look like. The requirements are that (1) it's way cool and (2) is
> > unimplementable in any reasonable fashion on machines based
> on 8-bit bytes.
>
> UTF-36 seems the obvious choice, since it allows you to add value on
> top of UCS-4 without all the whacky "fairness" tradeoffs in the other
> encodings of 10646. So what you need is an indispensable purpose to
> be served by the extra four bits.
>
10-Dec-2002 09:30:17 -0800,1593;000000000020
Return-Path: <rossman@columbia.edu>
Received: via tmail-4.1(11) for t20arc; Tue, 10 Dec 2002 09:30:17 -0800 (PST)
Return-Path: <rossman@columbia.edu>
Received: from lingling.panda.com (Lingling.Panda.C [206.124.149.115]) by Ikkoku-Kan.Panda.COM id JAA15210; Tue, 10 Dec 2002 09:30:16 -0800 (PST)
Received: from marionberry.cc.columbia.edu ([128.59.59.100]) by lingling.panda.com with TCP/SMTP; Tue, 10 Dec 2002 09:11:14 -0800 (PST)
Received: from columbia.edu ([65.162.93.190])
(user=rossman mech=PLAIN bits=0)
by marionberry.cc.columbia.edu (8.12.3/8.12.3) with ESMTP id gBAHBAUV003384
(version=TLSv1/SSLv3 cipher=DES-CBC3-SHA bits=168 verify=NOT);
Tue, 10 Dec 2002 12:11:11 -0500 (EST)
Date: Tue, 10 Dec 2002 12:11:09 -0500
Subject: Re: UTF-9, UTF-18, UTF-36
Content-Type: text/plain; charset=US-ASCII; format=flowed
Mime-Version: 1.0 (Apple Message framework v548)
Cc: Ken Rossman <rossman@columbia.edu>, Mark Crispin <MRC@lingling.panda.com>,
TOPS-20@lingling.panda.com
To: "Alan H. Martin" <AMartin.MA.UltraNet@RCN.Com>
From: Ken Rossman <rossman@columbia.edu>
In-Reply-To: <3DF5FC70.E85D45C6@RCN.Com>
Message-Id: <604477A8-0C62-11D7-AA2D-00039384248C@columbia.edu>
Content-Transfer-Encoding: 7bit
X-Mailer: Apple Mail (2.548)
> Mark Crispin wrote:
>>
>> Lately, I've been thinking about PDP-10 formats for Unicode. We can
>> use
>> UTF-7, but that format is incredibly clanky. Of course, if we go to
>> 8-bits, we then have the question about what to do with the other
>> 4-bits.
DUMPER-style 9 byte doubleword???
:-) :-) :-)
/K
10-Dec-2002 18:09:43 -0800,7661;000000000020
Return-Path: <slogin@optonline.net>
Received: via tmail-4.1(11) for t20arc; Tue, 10 Dec 2002 18:09:43 -0800 (PST)
Return-Path: <slogin@optonline.net>
Received: from lingling.panda.com (Lingling.Panda.C [206.124.149.115]) by Ikkoku-Kan.Panda.COM id SAA15789; Tue, 10 Dec 2002 18:09:40 -0800 (PST)
Received: from sfhexch1.sfh-mhh.org ([64.72.65.148]) by lingling.panda.com with TCP/SMTP; Tue, 10 Dec 2002 17:51:54 -0800 (PST)
Received: from optonline.net (10.100.1.254 [10.100.1.254]) by sfhexch1.sfh-mhh.org with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55)
id WXDFTRQP; Tue, 10 Dec 2002 20:42:11 -0500
Message-ID: <3DF699DB.A3EE0477@optonline.net>
Date: Tue, 10 Dec 2002 20:50:19 -0500
From: Thomas DeBellis <slogin@optonline.net>
X-Mailer: Mozilla 4.5 [en]C-CCK-MCD BA45DSL (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: "'Mark Crispin'" <MRC@lingling.panda.com>
CC: David Boyes <dboyes@sinenomine.net>, "'Rob Austein'" <sra@hactrn.net>,
"'TOPS-20@lingling.panda.com'" <TOPS-20@lingling.panda.com>,
Frank da Cruz <fdc@watsun.cc.columbia.edu>
Subject: Re: UTF-9, UTF-18, UTF-36
References: <F1F2B0484A1ED511904F08002BBDE5792182A2@ebola.sinenomine.net>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Mark,
My initial snide comment is that I am sure that anything that worked
well would probably be just about unimplementable at this point on
standard desktop systems. So much for the peanut gallery...
It's been about fourteen years since I last studied linguistics, but I
think David's point about allocating space for pronounciation and
accents is quite interesting and I would like to elaborate on it. It
is important to note that UTF-8 and Unicode were designed to handle
printing the characters of a particular orthographic set and NOT how
to pronounce them. This has always been their major limitation, in my
opinion.
For example, there are some languages (I believe in Africa) that are
not really vocalized but rather are a series of what we might hear as
clicks and pops. I wasn't aware of any specific orthography for
these, however (meaning they have no alphabet). The explosives are
marked with grammatical symbols in English, not as seperate
characters. Thus, there is no way to cleanly represent the actual
characters in UTF-8 or Unicode.
In some languages (Italian, for example), stress that is out of the
typical pattern (penultimate, in this case) is presented by an accent
mark which flags the reader that a different phoneme is being used.
This can have actual semantic content in certain cases: "e" and "e'"
(imagine the apostrophe being over the e). The first "e" means "and"
while the second "e'" means "is". However, these two symbols actually
show up as two seperate letters in Unicode, but would be considered
the same letter with diacritical marks for the native speaker.
My own personal opinion has always been that, at least in the case of
written Italian, having "e" and "e'" be seperate characters is losing.
Italian speakers don't think of the phonemes that way, they think of
"is" as "and" with an accent. Unicode and (I'm pretty sure) UTF-8
represent "e" and "e'" as different character symbols, which is
bogus.
An electronic orthography that could represent diacritical marks
as modifications to base characters would be winning. This is
what we should shoot for because we could implement it in such a
way as to hopelessly confuse the 8 bit crowd (see below).
I believe David was refering to Asian languages? If so, it would
depend on how the tones (in Chinese) are written. Chinese characters
are symbolic semi-ideograms which are supposed represent the concept
being communicated and not necessarily how to pronounce it. However,
if there are diacritical modifiers on the ideograms that resulted in
seperate UTF-8 entries, then that might also be losing.
I believe I remember a particular Japanese orthography (there are more
than one), having diacritical marks to flag tonality. If this is the
case and these markers result in different entries, that that would be
losing.
What would be winning would be a system which would have a standard base
representation for the character or ideogram and then a seperate bit
stream to render the diacritical markers. This would allow you to do
character sorting based on base and not have to worry about where the
modified characters fell. You could then do sorting within a base
character by picking up the diacritical bits.
Perhaps what we might have would be an electronic orthographic system
which would be represented by variable length bit streams (which the
PDP-10 can handle with ease). The suffix portion of a particular
orthographic symbol would be its base representation (viz, "e"). The
prefix portion would then be a bit stream with the various diacritcal
marking to be written with the character (viz, "'").
Thus, for Italian, you might have a bit stream prefix of 4 to handle
the diacritical marks: accent, accent grave, dot and dierisis (sp?)
(there may be more, I forget) and a bit stream suffix of 7 to handle
the base Latin characters. This would give us a combined total 11
bits, which wouldn't fit into any eight bit machine and not be easily
decodeable (lots of shifts and masks).
On the other hand, you could use a byte pointer to pack three
characters per word on the 10. A graphical rendering engine for the
character set might legitimately use a JFFO to dispatch the strokes
written over the base characters. That would truely be winning.
Caveats would include noting that a single word global byte pointer
wouldn't be able to handle the character set; you'd need a double
word.
This might also handle script well. Current electronic orthographic
systems must be programmed to understand how to link scripted letters.
This can be a problem in script only systems such as Arabic where
adjacent characters will modify how a particular character is written.
A prefix bit stream could modify the suffix bit stream with a number
of standard "linkages" to describe to the rendering engine how to fit
the characters together. This might also be applicable to written
Hindi.
Finally, maybe I Frank might volunteer to put in his two cents as I
know that the Kermit project did a lot of work to port everything to
different languages.
--T
PS: Please feel free to jump down my throat: it's been a LONG time
since I thought about any of this stuff. I can't believe I
remember this much...
David Boyes wrote:
>
> Reserve them for tonal indicators; or use a bit or two to indicate
> vocalized/non-vocalized, aspirant/non-aspirant, and reserve two bits
> for "Future Use". Must be forward thinking, after all.
>
> -- db
>
> David Boyes
> Sine Nomine Associates
>
> > -----Original Message-----
> > From: Rob Austein [mailto:sra@hactrn.net]
> > Sent: Tuesday, December 10, 2002 11:06 AM
> > To: Mark Crispin
> > Cc: TOPS-20@lingling.panda.com
> > Subject: Re: UTF-9, UTF-18, UTF-36
> >
> > I've been mulling over various ideas of what UTF-9, UTF-18, and
> > UTF-36 would look like. The requirements are that (1) it's way
> > cool and (2) is unimplementable in any reasonable fashion on
> > machines based on 8-bit bytes.
> >
> > UTF-36 seems the obvious choice, since it allows you to add value
> > on top of UCS-4 without all the whacky "fairness" tradeoffs in
> > the other encodings of 10646. So what you need is an
> > indispensable purpose to be served by the extra four bits.
10-Dec-2002 19:56:17 -0800,6917;000000000020
Return-Path: <dboyes@sinenomine.net>
Received: via tmail-4.1(11) for t20arc; Tue, 10 Dec 2002 19:56:17 -0800 (PST)
Return-Path: <dboyes@sinenomine.net>
Received: from lingling.panda.com (Lingling.Panda.C [206.124.149.115]) by Ikkoku-Kan.Panda.COM id TAA15916; Tue, 10 Dec 2002 19:56:14 -0800 (PST)
Received: from va3.sinenomine.net ([32.100.27.13]) by lingling.panda.com with TCP/SMTP; Tue, 10 Dec 2002 19:38:33 -0800 (PST)
Received: from dboyes1 (dboyes1.sinenomine.net [192.168.0.2])
by va3.sinenomine.net (8.12.6/8.12.6/SuSE Linux 0.6) with ESMTP id gBB4bCGe023171;
Tue, 10 Dec 2002 23:37:13 -0500
Message-ID: <001e01c2a0c8$875cbb60$0200a8c0@dboyes1>
From: "David Boyes" <dboyes@sinenomine.net>
To: "Thomas DeBellis" <slogin@optonline.net>,
"'Mark Crispin'" <MRC@lingling.panda.com>
Cc: "'Rob Austein'" <sra@hactrn.net>, <TOPS-20@lingling.panda.com>,
"Frank da Cruz" <fdc@watsun.cc.columbia.edu>
References: <F1F2B0484A1ED511904F08002BBDE5792182A2@ebola.sinenomine.net> <3DF699DB.A3EE0477@optonline.net>
Subject: Re: UTF-9, UTF-18, UTF-36
Date: Tue, 10 Dec 2002 22:50:06 -0500
MIME-Version: 1.0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2720.3000
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
X-Virus-Scanned: by AMaViS - amavis-milter (http://www.amavis.org/)
> For example, there are some languages (I believe in Africa) that are
> not really vocalized but rather are a series of what we might hear as
> clicks and pops. I wasn't aware of any specific orthography for
> these, however (meaning they have no alphabet). The explosives are
> marked with grammatical symbols in English, not as seperate
> characters. Thus, there is no way to cleanly represent the actual
> characters in UTF-8 or Unicode.
Languages like Zulu (one of the "click" languages) are usually notated in
the International Phonetic Alphabet if there is no native orthography. All
the IPA characters are present (I think), in UTF-8, but I don't want to haul
out the books to check. We're probably covered there.
I was specifically thinking of the Asian languages, but I can see how the
idea could be expanded to other vocalizations. If we used the top 4 bits as
an index into a table of vocalization methods, that might be quite neat (and
contrary to the usual April 1 RFC, maybe really useful...8-)).
> In some languages (Italian, for example), stress that is out of the
> typical pattern (penultimate, in this case) is presented by an accent
> mark which flags the reader that a different phoneme is being used.
> This can have actual semantic content in certain cases: "e" and "e'"
> (imagine the apostrophe being over the e). The first "e" means "and"
> while the second "e'" means "is". However, these two symbols actually
> show up as two seperate letters in Unicode, but would be considered
> the same letter with diacritical marks for the native speaker.
Classical Greek has a similar problem (sigma at the end of a word is a
different sound, but can also be a different glyph).
> I believe David was refering to Asian languages? If so, it would
> depend on how the tones (in Chinese) are written. Chinese characters
> are symbolic semi-ideograms which are supposed represent the concept
> being communicated and not necessarily how to pronounce it. However,
> if there are diacritical modifiers on the ideograms that resulted in
> seperate UTF-8 entries, then that might also be losing.
In most of the ideoglyph languages I know, only the Romanizations have
diacritics. Use of the ideoglyphs carries implied pronunciation, although it
would be possible to indicate expression or a degree of emphasis with the
"emotive modifier" (to invent a term). For example in most Romanizations of
Mandarin, m\-a and m\'a would be a good example of a flat tone and a rising
tone.Mark can probably comment more on Japanese, and Thai has a *really*
complicated tonality structure, but could still be contained in a 16-element
structure. The human ear has trouble hearing more than a few distinctive
tones reliably.
> What would be winning would be a system which would have a standard base
> representation for the character or ideogram and then a seperate bit
> stream to render the diacritical markers. This would allow you to do
> character sorting based on base and not have to worry about where the
> modified characters fell. You could then do sorting within a base
> character by picking up the diacritical bits.
I think the PARC folks did something like this for internal representation
of Japanese kanji in their entry method widget. They used a scheme like this
to select between kanji glyphs based on syntax rules, but still allowing for
Romaji input.
> Perhaps what we might have would be an electronic orthographic system
> which would be represented by variable length bit streams (which the
> PDP-10 can handle with ease). The suffix portion of a particular
> orthographic symbol would be its base representation (viz, "e"). The
> prefix portion would then be a bit stream with the various diacritcal
> marking to be written with the character (viz, "'").
Ooh! we could do orthographic routing protocols -- with emphasis routing on
the prefix and vocalization in the suffix! This would be *really* elegant
for music notation...
> On the other hand, you could use a byte pointer to pack three
> characters per word on the 10. A graphical rendering engine for the
> character set might legitimately use a JFFO to dispatch the strokes
> written over the base characters. That would truely be winning.
> Caveats would include noting that a single word global byte pointer
> wouldn't be able to handle the character set; you'd need a double
> word.
Hmm...what if it were a pointer to tables of strokes? Would fit into your
next idea.
> This might also handle script well. Current electronic orthographic
> systems must be programmed to understand how to link scripted letters.
> This can be a problem in script only systems such as Arabic where
> adjacent characters will modify how a particular character is written.
> A prefix bit stream could modify the suffix bit stream with a number
> of standard "linkages" to describe to the rendering engine how to fit
> the characters together. This might also be applicable to written
> Hindi.
And the multicharacter cell glyphs used in Thai and Quecha/Maya. I'd even
think that this would allow some specification of relative location of
glyphemes (ie for Egyptian formal hieroglyphs, which sometimes change
meaning depending on proximity and direction of the surrounding glyphs).
Darn. Have we stumbled on Yet Another Useful TOPS-x0 Contribution to
Winnitude here? 8-)
--d b
11-Dec-2002 06:36:33 -0800,5048;000000000020
Return-Path: <fdc@columbia.edu>
Received: via tmail-4.1(11) for t20arc; Wed, 11 Dec 2002 06:36:33 -0800 (PST)
Return-Path: <fdc@columbia.edu>
Received: from lingling.panda.com (Lingling.Panda.C [206.124.149.115]) by Ikkoku-Kan.Panda.COM id GAA16536; Wed, 11 Dec 2002 06:36:30 -0800 (PST)
Received: from watsol.cc.columbia.edu ([128.59.39.139]) by lingling.panda.com with TCP/SMTP; Wed, 11 Dec 2002 06:19:56 -0800 (PST)
Received: from watsol.cc.columbia.edu (localhost [127.0.0.1])
by watsol.cc.columbia.edu (8.12.3/8.12.3) with ESMTP id gBBEJpmL005310;
Wed, 11 Dec 2002 09:19:51 -0500 (EST)
Received: (from fdc@localhost)
by watsol.cc.columbia.edu (8.12.3/8.12.3/Submit) id gBBEJp6g005309;
Wed, 11 Dec 2002 09:19:51 -0500 (EST)
Date: Wed, 11 Dec 2002 9:19:50 EST
From: Frank da Cruz <fdc@columbia.edu>
To: Thomas DeBellis <slogin@optonline.net>
Cc: "'Mark Crispin'" <MRC@lingling.panda.com>,
David Boyes <dboyes@sinenomine.net>, "'Rob Austein'" <sra@hactrn.net>,
"'TOPS-20@lingling.panda.com'" <TOPS-20@lingling.panda.com>
Subject: Re: UTF-9, UTF-18, UTF-36
In-Reply-To: Your message of Tue, 10 Dec 2002 20:50:19 -0500
Message-ID: <CMM.0.91.0.1039616390.fdc@watsol>
> It's been about fourteen years since I last studied linguistics, but I
> think David's point about allocating space for pronounciation and
> accents is quite interesting and I would like to elaborate on it. It
> is important to note that UTF-8 and Unicode were designed to handle
> printing the characters of a particular orthographic set and NOT how
> to pronounce them.
>
Right. Unicode is an attempt at (a) consolidating all of the world's
text character sets, and (b) encoding any scripts not already encoded.
It does not attempt to invent new writing systems, only to encode the
ones that exist in practice (in computers, books, chiseled into stone,
whatever).
> In some languages (Italian, for example), stress that is out of the
> typical pattern (penultimate, in this case) is presented by an accent
> mark which flags the reader that a different phoneme is being used.
> This can have actual semantic content in certain cases: "e" and "e'"
> (imagine the apostrophe being over the e). The first "e" means "and"
> while the second "e'" means "is". However, these two symbols actually
> show up as two seperate letters in Unicode, but would be considered
> the same letter with diacritical marks for the native speaker.
>
It's a bit more complicated. Unicode includes all characters that
were encoded in pre-existing character sets, such as ISO Latin-1.
Thus e and e-grave and e-acute (etc) each have their own code points.
It also allows e-grave (etc) to be formed from e plus combining grave.
Thus in some cases, the same character can be encoded two or more
ways. Vietnamese (in which the base letter can have up to four
diacritics) is an extreme case of this (think about it).
> An electronic orthography that could represent diacritical marks
> as modifications to base characters would be winning.
>
Unicode has a variety of "normalization forms" that say how text should
be encoded when there is more than one way to encode it. One of them
says: always use precomposed characters when available. Another one
says: always use combining sequences.
> Perhaps what we might have would be an electronic orthographic system
> which would be represented by variable length bit streams (which the
> PDP-10 can handle with ease). The suffix portion of a particular
> orthographic symbol would be its base representation (viz, "e"). The
> prefix portion would then be a bit stream with the various diacritcal
> marking to be written with the character (viz, "'").
>
Of course you can't assume a 36-bit word. Furthermore, if you are encoding
accents by setting bits, you'll need way more bits than that. Also there
are issues of stacking, precedence, etc. But finally, no encoding will
fly unless it's ASCII-compatible (as UTF-8 is), because no existing
software can cope with it.
> Finally, maybe I Frank might volunteer to put in his two cents as I
> know that the Kermit project did a lot of work to port everything to
> different languages.
>
Those of you who haven't seen this might enjoy it:
http://www.columbia.edu/kermit/utf8.html
I'm a Unicode Consortium member. All of these issues have been discussed
profusely for more than fifteen years, as you can see in the extensive
archives at the Unicode website, and most of them resolved years ago.
I missed the discussion that set this off, but evidently it's about
inventing even more UTFs? That's the last thing we need; there are way
too many of them already. If the idea was to use the extra 4 bits in
a 36-bit word for something, see the terabytes of discussions on the
topic of presentation forms versus encoding in the Unicode archive.
The consensus is that presentation and rendering are not concepts
for a character set; they belong at a higher (markup) level.
- Frank
11-Dec-2002 09:17:06 -0800,3638;000000000020
Return-Path: <MRC@Panda.COM>
Received: via tmail-4.1(11) (invoked by user mrc) for t20arc; Wed, 11 Dec 2002 09:17:06 -0800 (PST)
Return-Path: <MRC@Panda.COM>
Received: from lingling.panda.com (Lingling.Panda.C [206.124.149.115]) by Ikkoku-Kan.Panda.COM id JAA16755; Wed, 11 Dec 2002 09:17:04 -0800 (PST)
Received: from Ikkoku-Kan.Panda.COM (panda.com [206.124.149.114]) by lingling.panda.com with TCP/SMTP; Wed, 11 Dec 2002 09:00:36 -0800 (PST)
Received: from Ikkoku-Kan.Panda.COM (Ikkoku-Kan.Panda.COM [192.107.14.50]) by Ikkoku-Kan.Panda.COM id IAA16701; Wed, 11 Dec 2002 08:58:51 -0800 (PST)
Date: Wed, 11 Dec 2002 08:18:29 -0800 (PST)
From: Mark Crispin <MRC@CAC.Washington.EDU>
Sender: Mark Crispin <mrc@Ikkoku-Kan.Panda.COM>
Subject: Re: UTF-9, UTF-18, UTF-36
To: Frank da Cruz <fdc@columbia.edu>
cc: Thomas DeBellis <slogin@optonline.net>,
David Boyes <dboyes@sinenomine.net>, "'Rob Austein'" <sra@hactrn.net>,
TOPS-20 Mailing List <TOPS-20@lingling.panda.com>
In-Reply-To: <CMM.0.91.0.1039616390.fdc@watsol>
Message-ID: <MailManager.1039623509.15587.mrc@Ikkoku-Kan.Panda.COM>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
On Wed, 11 Dec 2002 9:19:50 EST, Frank da Cruz wrote:
> I missed the discussion that set this off, but evidently it's about
> inventing even more UTFs? That's the last thing we need; there are way
> too many of them already.
That indeed is what is being discussed.
However, to bring things back to reality; I was not talking about adding
presentation or rendering features to Unicode. Rather, I was talking about
what would be a good representation of Unicode on a 36-bit architecture,
particularly one in which 9, 18, and 36 bits are natural sizes.
> If the idea was to use the extra 4 bits in
> a 36-bit word for something,
It is.
> The consensus is that presentation and rendering are not concepts
> for a character set; they belong at a higher (markup) level.
I agree with this concensus.
The goals of this project are:
1) Have something done in time for an RFC on April 1, 2003.
2) Do no harm. The rest of the community should be amazed and amused, not
threatened.
3) Be arguably better for 36-bit machines.
4) Be reversibly transformable to the existing encodings, or document the
extra stuff as "local-use".
Here is something along the lines of what I've been thinking:
UCS-36 (not UTF-36). Would have 5 local-use tag bits in addition to the 31
(not 32) bits of UCS-32. Don't need to spend too much time on this, since
most people don't use UCS-32 either.
UTF-9. The 400 bit indicates "continuation"; that is, that there are more
bytes to come. It's MSB first; thus 777 000 results in U+ff00, 720 777 000
results in U+10ff00, etc. Surrogates would not be used. As in UTF-8, ASCII
fits in 1 byte, but so does ISO 8859-1. The entire BMP would fit in two bytes
(UTF-8 requires up to 3 bytes), all of Unicode would fit in three bytes (UTF-8
requires up to 4 bytes) with room to spare, and all of ISO 10646 would fit in
four bytes (UTF-8 requires up to 6 bytes).
What's difficult is going to be UTF-18. I have been wracking my brains trying
to figure out a way to get Unicode into an 18-bit encoding without needing
surrogates. The problem is that we need three more bits (really, two and a
half more bits...).
Of course, we could just have a UTF-18 encoding in which we provide for the
BMP and the first two extended plains in an 18-bit halfword, and then
continuation; that way UTF-18 would be able to represent all of ISO 10646
instead of being limited to Unicode.
11-Dec-2002 09:32:12 -0800,2598;000000000020
Return-Path: <fdc@columbia.edu>
Received: via tmail-4.1(11) for t20arc; Wed, 11 Dec 2002 09:32:12 -0800 (PST)
Return-Path: <fdc@columbia.edu>
Received: from lingling.panda.com (Lingling.Panda.C [206.124.149.115]) by Ikkoku-Kan.Panda.COM id JAA16771; Wed, 11 Dec 2002 09:32:10 -0800 (PST)
Received: from watsol.cc.columbia.edu ([128.59.39.139]) by lingling.panda.com with TCP/SMTP; Wed, 11 Dec 2002 09:15:50 -0800 (PST)
Received: from watsol.cc.columbia.edu (localhost [127.0.0.1])
by watsol.cc.columbia.edu (8.12.3/8.12.3) with ESMTP id gBBHFkmL018677;
Wed, 11 Dec 2002 12:15:46 -0500 (EST)
Received: (from fdc@localhost)
by watsol.cc.columbia.edu (8.12.3/8.12.3/Submit) id gBBHFj7o018676;
Wed, 11 Dec 2002 12:15:45 -0500 (EST)
Date: Wed, 11 Dec 2002 12:15:45 EST
From: Frank da Cruz <fdc@columbia.edu>
To: Mark Crispin <MRC@CAC.Washington.EDU>
cc: Thomas DeBellis <slogin@optonline.net>,
David Boyes <dboyes@sinenomine.net>, "'Rob Austein'" <sra@hactrn.net>,
TOPS-20 Mailing List <TOPS-20@lingling.panda.com>
Subject: Re: UTF-9, UTF-18, UTF-36
In-Reply-To: Your message of Wed, 11 Dec 2002 08:18:29 -0800 (PST)
Message-ID: <CMM.0.91.0.1039626945.fdc@watsol>
> UTF-9. The 400 bit indicates "continuation"; that is, that there are more
> bytes to come. It's MSB first; thus 777 000 results in U+ff00, 720 777 000
> results in U+10ff00, etc. Surrogates would not be used. As in UTF-8, ASCII
> fits in 1 byte, but so does ISO 8859-1. The entire BMP would fit in two
> bytes (UTF-8 requires up to 3 bytes), all of Unicode would fit in three
> bytes (UTF-8 requires up to 4 bytes) with room to spare, and all of ISO
> 10646 would fit in four bytes (UTF-8 requires up to 6 bytes).
>
It's a nice design -- gets around the need for surrogates, and could result
in some serious space savings over other forms.
There are other nice designs that will never see the light of day too,
for example "UTF-8.5" (or other whimsical name), which is a C1-safe form
of UTF-8 (i.e. one that does not use 0x80-0x9f bytes), to resolve the
conflict between UTF-8 and ISO 2022. (Everybody agreed this would have
been a better way to do UTF-8, but it was too late to change it.)
Anyway, since you care, it's probably worth writing up and submitting UTF-36,
if only half seriously, just to show that as the pendulum swings back and
forth between CISC and RISC, and now with Intel poised to shove the most
hideously complex architecture ever down everyone's throat and complexity is
back in style, variable-length bytes have their advantages!
- Frank
20-Dec-2002 03:46:55 -0800,2690;000000000020
Return-Path: <slogin@optonline.net>
Received: via tmail-4.1(11) for t20arc; Fri, 20 Dec 2002 03:46:55 -0800 (PST)
Return-Path: <slogin@optonline.net>
Received: from lingling.panda.com (Lingling.Panda.C [206.124.149.115]) by Ikkoku-Kan.Panda.COM id DAA03099; Fri, 20 Dec 2002 03:46:52 -0800 (PST)
Received: from mta3.srv.hcvlny.cv.net ([167.206.5.9]) by lingling.panda.com with TCP/SMTP; Fri, 20 Dec 2002 03:28:34 -0800 (PST)
Received: from asv14.srv.hcvlny.cv.net
(asv14.srv.hcvlny.cv.net [167.206.5.148]) by mta3.srv.hcvlny.cv.net
(iPlanet Messaging Server 5.2 HotFix 1.05 (built Nov 6 2002))
with ESMTP id <0H7F0075N17G1G@mta3.srv.hcvlny.cv.net> for
Tops-20@lingling.panda.com; Fri, 20 Dec 2002 06:28:28 -0500 (EST)
Received: from mta8.srv.hcvlny.cv.net (mta8.srv.hcvlny.cv.net [167.206.5.23])
by asv14.srv.hcvlny.cv.net (8.12.6/8.11.6) with ESMTP id gBKBSUtF016178 for
<Tops-20@lingling.panda.com>; Fri, 20 Dec 2002 06:28:31 -0500 (EST)
Received: from optonline.net (ool-182f33c4.dyn.optonline.net [24.47.51.196])
by mta8.srv.hcvlny.cv.net
(iPlanet Messaging Server 5.2 HotFix 1.05 (built Nov 6 2002))
with ESMTP id <0H7F003TW16JTW@mta8.srv.hcvlny.cv.net> for
Tops-20@lingling.panda.com; Fri, 20 Dec 2002 06:27:56 -0500 (EST)
Date: Fri, 20 Dec 2002 06:27:22 -0500
From: Thomas DeBellis <slogin@optonline.net>
Subject: The $200 DEC-20
To: Tops-20@lingling.panda.com
Message-id: <3E02FE9A.2A0C099@optonline.net>
MIME-version: 1.0
X-Mailer: Mozilla 4.5 [en]C-CCK-MCD BA45DSL (WinNT; U)
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7BIT
X-Accept-Language: en
References: <MailManager.1036036367.7566.mrc@Ikkoku-Kan.Panda.COM>
I thought that I would make a fun announcement. I recently
purchased a full blown DECSYSTEM-20 for $200. It is about
three times faster than a KL-10. The microengine is an 800mhz
VIA C3 processor with 128MB of memory and a 10GB hard drive.
It was manufactured by Microtel and sold by Walmart.
Setup time was approximately three hours. This included
cabling, downloading of ssh, downloading of Tops-20 and
associated fumbling. The version of Tops-20 is the Panda
distribution which is quite nice. If has just about everything
that you'd want: different flavors of Lisp (as opposed to
lisp flavors), Fortran, ALgol, Macro, Emacs, Cobol (!),
DECnet and TCP.
The only major thing that I didn't find was <INFO>, which
I got elsewhere. Stability is remarkable and I may have
already discovered a small bug that I tickled with a
programming error while (mis) naming a PID with .IPCII
(sent a pointer to a string instead of the string itself).
Happy DEC20 Day, Everyone!
20-Dec-2002 13:53:35 -0800,1373;000000000020
Return-Path: <MRC@lingling.panda.com>
Received: via tmail-4.1(11) for t20arc; Fri, 20 Dec 2002 13:53:35 -0800 (PST)
Return-Path: <MRC@lingling.panda.com>
Received: from lingling.panda.com (Lingling.Panda.C [206.124.149.115]) by Ikkoku-Kan.Panda.COM id NAA03741; Fri, 20 Dec 2002 13:53:32 -0800 (PST)
Date: Fri, 20 Dec 2002 13:30:12 -0800 (PST)
From: Mark Crispin <MRC@lingling.panda.com>
Subject: Happy DEC 20 day
To: TOPS-20@lingling.panda.com
Message-ID: <13796349307.9.MRC@lingling.panda.com>
This year has been eventful for the TOPS-20 community. With the release
of the klh10 microcode, the number of TOPS-20 systems on the Internet has
grown substantially. If you bring up one, be sure to let me know so that
it can be added to the host table.
This has also been an eventful year for the TOPS-20 mailing list. Traffic
has trebled over the previous year; in fact this is more traffic since
1993, when SIMTEL20 and most of the other straggling remnants of DEC 36-bit
hardware were shut down for the last time. 1993 was also when my 2020 sent
its last email message to the outside world. The nadir was in 1997, when
just two messages were sent to the list: a message from XKL offering a free
KL to a good home, and a message from Paul Allen announcing the XKLeTen
system.
Happy DEC-20 day, holidays, and New Year!
-- Mark --
-------
21-Dec-2002 11:36:42 -0800,6069;000000000020
Return-Path: <slogin@optonline.net>
Received: via tmail-4.1(11) for t20arc; Sat, 21 Dec 2002 11:36:42 -0800 (PST)
Return-Path: <slogin@optonline.net>
Received: from lingling.panda.com (Lingling.Panda.C [206.124.149.115]) by Ikkoku-Kan.Panda.COM id LAA06084; Sat, 21 Dec 2002 11:36:39 -0800 (PST)
Received: from mta6.srv.hcvlny.cv.net ([167.206.5.17]) by lingling.panda.com with TCP/SMTP; Sat, 21 Dec 2002 11:19:08 -0800 (PST)
Received: from asv15.srv.hcvlny.cv.net
(asv14.srv.hcvlny.cv.net [167.206.5.149]) by mta6.srv.hcvlny.cv.net
(iPlanet Messaging Server 5.2 HotFix 1.05 (built Nov 6 2002))
with ESMTP id <0H7H000D0HNW5X@mta6.srv.hcvlny.cv.net> for
Tops-20@lingling.panda.com; Sat, 21 Dec 2002 14:19:08 -0500 (EST)
Received: from mta8.srv.hcvlny.cv.net (mta8.srv.hcvlny.cv.net [167.206.5.23])
by asv15.srv.hcvlny.cv.net (8.12.6/8.11.6) with ESMTP id gBLJJ1XY025898 for
<Tops-20@lingling.panda.com>; Sat, 21 Dec 2002 14:19:02 -0500 (EST)
Received: from optonline.net (ool-182f33c4.dyn.optonline.net [24.47.51.196])
by mta8.srv.hcvlny.cv.net
(iPlanet Messaging Server 5.2 HotFix 1.05 (built Nov 6 2002))
with ESMTP id <0H7H00AZTHMQPC@mta8.srv.hcvlny.cv.net> for
Tops-20@lingling.panda.com; Sat, 21 Dec 2002 14:18:27 -0500 (EST)
Date: Sat, 21 Dec 2002 14:17:38 -0500
From: Thomas DeBellis <slogin@optonline.net>
Subject: QSRADM
To: Tops-20 Wizards <Tops-20@lingling.panda.com>
Message-id: <3E04BE52.8626E678@optonline.net>
MIME-version: 1.0
X-Mailer: Mozilla 4.5 [en]C-CCK-MCD BA45DSL (WinNT; U)
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7BIT
X-Accept-Language: en
I've been poking around my new DEC20, refamiliarizing myself with lots
of stuff. I started looking at the 7.0 Galaxy distribution to see
what had changed as I was interested in the new functionality that had
been added for the CI that we didn't have in 6.0 at Columbia (most
particularly, Nebula).
While I was at it, I checked to see if some of the (many, many) fixes
that I had so carefully SPR'ed (over eight years) had made it into the
distrubution. They didn't, grr. What particularly bugs me is a
rather major defect in the Quasar Administration (QSRADM) scheduler
aging code. I had SPR'ed this over 19 years ago on December 15th,
1983... You can still see the original message in the Tops-20
archives.
The bug is active ALL the time, but is particularly evident if you get
a large number of requests in a queue. This can happen if you have a
device down, some lengthy requests or network outages. To review, the
original code is this:
A$AGE:: $SAVE <T1> ;SAVE T1
CAMGE S1,S2 ;ORDERING CHECK
EXCH S1,S2 ;WANT THE LARGEST IN S1
SUB S1,S2 ;SUBTRACT THEM
HLRZ T1,S1 ; Get the days difference
HRRZS S1 ; Seperate the difference in fraction
IMULX S1,<^D1000.> ; Shift it over for greater accuracy
IDIVX S1,<^D3034.> ; Divide by the magic factor
IMULX T1,<^D<24*3600>> ; Calculate the seconds between the days
ADD S1,T1 ; Calculate the total number of seconds
$RET ; Return
The purpose of the code is to take two dates in (winning) universal
date/time (UDT) format and return the number of seconds that seperate
the two. UDT is winning as compared to the (losing) unix standard
because it has both higher resolution and higher magnitude.
Unix internal time is stored in the time_t type. The time() function
returns the value of time in seconds since the Epoch (00:00:00 UTC,
January 1, 1970). This will end in 2038, breaking much C code (is
everybody ready?). It is accurate to the nearest second.
As per the 5.0 Monitor Calls Reference manual page 2-79 (yes, I kept
it), UDT format is stored in a 36 bit word (what else?) as a fixed
point fraction. The left halfword stores the date as the elapsed days
since Nov 17, 1858. It will expire in 2576. The right halfword
contains the fraction of the current day.
As many DEC-20 programmers never had the opportunity to do anything
beyond integer arithmatic, I will elaborate a little further. The
time of day is a fraction of 24 hours divided by <1,,0>. In decimal,
this would be 1/262,144 or approximately 0.000003814697265625. The
quotient is thus: 0.32958984375, which is little less than a third of
a second. But! It isn't a third of a second...
To explain the code, it calculates the exact difference in days and
saves that in a temporary accumulator. It then handles the fractional
portion by shifting the binary point over to the right by three orders
of decimal magnitude. It then divides by a fixed representation of
of a shifted third of a second. The number of days is converted to
seconds and the totals are addeded. There are a number of problems:
1) The representations of the numbers used are incorrect. ^D is the
proper prefix to express a decimal number, but the period suffix
is used to flag the assembler that the number is to be converted
to floating point. This is wrong.
Instead of getting octal 1750 for decimal 1000, you get octal
<212764,,0> which is 18,653,118,464. This is the major source of
the 'interesting results'.
2) The algorythm is incorrect. The use of approximations will lead
to incorrect rounding or none at all.
3) The routine uses more instructions than necessary and an extra
register for temporary results. It is actually slower than the
code below.
A$AGE:: CAMGE S1,S2 ;ORDERING CHECK
EXCH S1,S2 ;WANT THE LARGEST IN S1
SUB S1,S2 ;SUBTRACT THEM
MULI S1,<^D60*^D60*^D24>;T1 Convert days to seconds
DIV S1,[1,,0] ;T1 Shift binary point
CAIL S2,400000 ;T1 Shall we round? (400000 = 1/2)
AOS S1 ;T1 Yes, give us another second
$RET ; Return
This is currently running on TommyT. I don't have any printers
defined nor run many batch streams, but nothing has broken, yet, nor
do I expect that it will. Doing all the compiles (at the same time)
actually got the load up past 8. Now that's the sound of old time
computing...