2-Jan-2006 22:23:40-PST,1785;000000000000

2-Jan-2006 22:23:40-PST,1785;000000000000
Mail-From: MRC created at 2-Jan-2006 22:17:44
Date: Mon, 2 Jan 2006 22:17:44 -0800 (PST)
From: Mark Crispin <[email protected]>
Subject: 2005, yet another record year of TOPS-20 list traffic
To: [email protected]
Pithy-Thought: TOPS-20 was a great improvement over its successors
Message-ID: <[email protected]>

Happy New Year (agemashite omedetou gozaimasu)!

Traffic on the TOPS-20 list in 2005 increased by 50% over 2004, marking
the most list traffic in 20 years, and the 5th highest list traffic year
since the TOPS-20 list began. The record years were:

Top Traffic Least Traffic
Year Pages Year Pages
---- ----- ---- -----
1982 442 1997 3
1983 433 1979 9
1984 312 1996 19
1985 302 1998 22
2005 287 1999 23
1986 269 2001 24
1981 195 1994 26
2004 189 1995 29
1987 165 2000 36
1988 123 1991 42
2003 110 1980 53
1993 102 1990 57
1992 81 2002 66
1989 71

1979 and 1980 were the first years of the list. Prior to August 1981
the list was moderated (by me); messages were sent to me and I bouned them
to the list. In August 1981 the familiar TOPS-20@SU-SCORE address first
appeared.

2005 is also the year in which we can welcome real DEC 36-bit iron back
to the Internet. DEC-10.PDPPLANET.COM is a 2060 running TOPS-10, and is
part of Paul Allen's zoo. It doesn't do TCP/IP itself; instead it uses
terminal ports connected to a cisco terminal server. I don't know if it's
because they don't have the old TOPS-10 TCP/IP software, or because they
don't have suitable hardware. Nonetheless, it's great to see a real KL
on the network again, especially when trying to answer those nagging "what
does a real KL do with such-and-such" questions.

-- Mark --
-------
3-Jan-2006 08:31:40-PST,4972;000000000000
Return-Path: <[email protected]>
Received: from smtpout.mac.com ([17.250.248.88]) by lingling.panda.com with TCP/SMTP; Tue, 3 Jan 2006 08:25:13 -0800 (PST)
Received: from mac.com (smtpin02-en2 [10.13.10.147])
by smtpout.mac.com (Xserve/8.12.11/smtpout01/MantshX 4.0) with ESMTP id k03GOtus015083;
Tue, 3 Jan 2006 08:24:55 -0800 (PST)
Received: from [192.168.1.51] (c-24-128-160-88.hsd1.nh.comcast.net [24.128.160.88])
(authenticated bits=0)
by mac.com (Xserve/smtpin02/MantshX 4.0) with ESMTP id k03GOrkR013692;
Tue, 3 Jan 2006 08:24:54 -0800 (PST)
Mime-Version: 1.0
Message-Id: <p06230904bfe04b4795f3@[192.168.1.51]>
In-Reply-To: <[email protected]>
References: <[email protected]>
Date: Tue, 3 Jan 2006 11:25:17 -0500
To: Mark Crispin <[email protected]>, [email protected]
From: "John J. Francini" <[email protected]>
Subject: TCP/IP stacks for TOPS-10 [Was: Re: 2005, yet another record year
of TOPS-20 list traffic]
Content-Type: text/plain; charset="us-ascii" ; format="flowed"

Mark,

As someone who hung around DEC10 Development for awhile in the late
80s, I can say with reasonable confidence that there never _was_ a
DEC-issued and supported TCP/IP stack for TOPS-10. Several of our
customer sites implemented their own stacks, and the fine folks in
Sweden implemented one for 7.03 on a KI if memory serves.

TOPS-10's supported networking protocols were ANF-10, DECnet, and LAT.

It's a bit frustrating for TOPS-10 fans like me who want to install a
system on a Linux box using KLH, because the only way to talk to it
(at least with the stock KLH microengine) is through the console.
(If you run KLH on an Alpha running older versions of Digital UNIX,
you can use DECnet, but that's no bargain either.)

The SIMH emulator at least supports DZ-11 emulation through Telnet,
although it only emulates a KS-10 processor.

One other way to get around it, I'd suppose, would be to add "real"
DTE support to both KLH and SIMH. Then you could emulate a
full-blown DEC-10 environment, including the console DTE running
RSX20F -- supporting emulated DH11s, as well as additional copies of
SIMH running DN8x ANF-10 software.

One potential fly in this ointment is that I'm not sure that any of
the PDP-11 DN8x software has been released and/or put up on the
Internet. Last I knew, original tapes and disk packs are sitting
collecting dust in a storage room in the basement of MRO2 in
Marlboro. (I saw that storage room once back in 2003.)
Practically everything for 36-bit computing was in there: BLKx packs,
SNARK:, backup/dumper tapes of KL1026, KL2102, GIDNEY, CLOYD, spare
KL-10 boards, etc. Timothe Litt was their caretaker. (It's not
clear if TL is still at HP; if he isn't, then it's completely unclear
what has happened/will happen to all this material.

John Francini

At 22:17 -0800 1/2/06, Mark Crispin wrote:
>Happy New Year (agemashite omedetou gozaimasu)!
>
>Traffic on the TOPS-20 list in 2005 increased by 50% over 2004, marking
>the most list traffic in 20 years, and the 5th highest list traffic year
>since the TOPS-20 list began. The record years were:
>
> Top Traffic Least Traffic
> Year Pages Year Pages
> ---- ----- ---- -----
> 1982 442 1997 3
> 1983 433 1979 9
> 1984 312 1996 19
> 1985 302 1998 22
> 2005 287 1999 23
> 1986 269 2001 24
> 1981 195 1994 26
> 2004 189 1995 29
> 1987 165 2000 36
> 1988 123 1991 42
> 2003 110 1980 53
> 1993 102 1990 57
> 1992 81 2002 66
> 1989 71
>
>1979 and 1980 were the first years of the list. Prior to August 1981
>the list was moderated (by me); messages were sent to me and I bouned them
>to the list. In August 1981 the familiar TOPS-20@SU-SCORE address first
>appeared.
>
>2005 is also the year in which we can welcome real DEC 36-bit iron back
>to the Internet. DEC-10.PDPPLANET.COM is a 2060 running TOPS-10, and is
>part of Paul Allen's zoo. It doesn't do TCP/IP itself; instead it uses
>terminal ports connected to a cisco terminal server. I don't know if it's
>because they don't have the old TOPS-10 TCP/IP software, or because they
>don't have suitable hardware. Nonetheless, it's great to see a real KL
>on the network again, especially when trying to answer those nagging "what
>does a real KL do with such-and-such" questions.
>
>-- Mark --
>-------

--
----
John Francini <mailto:[email protected]>
+---------------------------------------------------------------------------+
| "I have come to the conclusion that one useless man is called a disgrace; |
| that two are called a law firm; and that three or more become a Congress.|
| And by God I have had _this_ Congress!" |
| -- John Adams |
+---------------------------------------------------------------------------+
3-Jan-2006 11:21:57-PST,3284;000000000000
Return-Path: <[email protected]>
Received: from mail2.panix.com ([166.84.1.73]) by lingling.panda.com with TCP/SMTP; Tue, 3 Jan 2006 11:16:03 -0800 (PST)
Received: from panix5.panix.com (panix5.panix.com [166.84.1.5])
by mail2.panix.com (Postfix) with ESMTP id 962BE9DC2D
for <[email protected]>; Tue, 3 Jan 2006 14:15:56 -0500 (EST)
Received: (from alderson@localhost)
by panix5.panix.com (8.11.6p3/8.8.8/PanixN1.1) id k03JFug15695;
Tue, 3 Jan 2006 14:15:56 -0500 (EST)
Date: Tue, 3 Jan 2006 14:15:56 -0500 (EST)
Message-Id: <[email protected]>
From: Rich Alderson <[email protected]>
To: [email protected]
In-reply-to: <p06230904bfe04b4795f3@[192.168.1.51]> ([email protected])
Subject: Re: TCP/IP stacks for TOPS-10 [Was: Re: 2005, yet another record year
of TOPS-20 list traffic]
References: <[email protected]> <p06230904bfe04b4795f3@[192.168.1.51]>

Piggy-backing off John Francini's subject line to respond to MRC's comments:

>> 2005 is also the year in which we can welcome real DEC 36-bit iron back
>> to the Internet. DEC-10.PDPPLANET.COM is a 2060 running TOPS-10, and is
>> part of Paul Allen's zoo. It doesn't do TCP/IP itself; instead it uses
>> terminal ports connected to a cisco terminal server. I don't know if it's
>> because they don't have the old TOPS-10 TCP/IP software, or because they
>> don't have suitable hardware. Nonetheless, it's great to see a real KL
>> on the network again, especially when trying to answer those nagging "what
>> does a real KL do with such-and-such" questions.

There are a couple of factors involved.

First, the monitor running on our 2065 (MG memory, MCA25 cache) is from the
KLAD installation tapes, FILDDTed to announce itself as PDPplanet, so it's
straight DEC. I've not been able to build a monitor that recognizes the DH-11
lines[1] when I boot it, and with the current shortage of disk space[2] I can't
install sources anyway so have to work with the emulators and transfer files
to the -10 by FTPing to the Toad-1 and writing a 9-track tape.[3]

Beyond that, I don't have the source to any TCP/IP implementation for Tops-10.
The only one we knew of at XKL was the CMU code which is lost in an uncataloged
warehouse of tapes; for other reasons we never completed our port of Tops-10 to
the Toad-1 anyway.

Finally, I doubt that any implementation for Tops-10 was done with the MEIS[4]
in mind, so we'd still have to add hardware to the system to make it work. By
connecting a terminal server in milking machine mode to the front end, we have
a system on the net.

Rich

[1] Actually an Able Computing DH/DM single-board work-alike.
[2] The system only has a single RP06 drive running at a time, so that we do
not get into the problems we had when we lost multiple drives at once. We
are far along on a replacement strategy.
[3] Kermit-10 is available from the 2065 out through the terminal server, but
is of course not really feasible for very large files at 9600bps.
[4] The Stanford-designed and built MASSBUS Ethernet Interface Subsystem which
was also a cisco Systems product at one time.
3-Jan-2006 12:34:33-PST,3033;000000000000
Return-Path: <[email protected]>
Received: from rwcrmhc12.comcast.net (rwcrmhc14.comcast.net [216.148.227.154]) by lingling.panda.com with TCP/SMTP; Tue, 3 Jan 2006 12:28:44 -0800 (PST)
Received: from c-66-30-204-193.hsd1.ma.comcast.net ([66.30.204.193])
by comcast.net (rwcrmhc14) with ESMTP
id <20060103202837014008ms64e>; Tue, 3 Jan 2006 20:28:37 +0000
Received: (from phil@localhost)
by ultimate.com (8.13.4/8.13.4) id k03KSZDb008839;
Tue, 3 Jan 2006 15:28:35 -0500 (EST)
Date: Tue, 3 Jan 2006 15:28:35 -0500 (EST)
From: Phil Budne <[email protected]>
Message-Id: <[email protected]>
To: [email protected], [email protected], [email protected]
Subject: Re: TCP/IP stacks for TOPS-10 [Was: Re: 2005, yet another record year of TOPS-20 list traffic]
Cc: [email protected]

> As someone who hung around DEC10 Development for awhile in the late

> 80s, I can say with reasonable confidence that there never _was_ a
> DEC-issued and supported TCP/IP stack for TOPS-10. Several of our
> customer sites implemented their own stacks, and the fine folks in
> Sweden implemented one for 7.03 on a KI if memory serves.

Their dual KI (KICKI) at some point ran one based (at least in part)
on the one done by Don Provan (contracted by the AF for the WPAFB dual
KI?) see:

ftp://ftp.stacken.kth.se/pub/pdp10/kicki/

Alas, all the user-mode parts are missing, including the hairy
(JACCTed?) program that established a connection and left an ASSIGNed
device for you to use.

Johnny Erickson also did a from-scratch implementation of UDP/IP w/
TFTP program for SIMH to talk to a DEUNA for 7.04. Files appear to be in:

ftp://ftp.stacken.kth.se/pub/pdp10/tops10/

He also did a KMC/DUP simulator that sends DDCMP frames encapsulated
in UDP packets:

ftp://ftp.stacken.kth.se/pub/pdp10/simh-kdp.tar

> One potential fly in this ointment is that I'm not sure that any of
> the PDP-11 DN8x software has been released and/or put up on the
> Internet.

How about these:

http://pdp-10.trailing-edge.com/tops10_704_monitoranf_bb-x140c-sb/index.html

http://pdp-10.trailing-edge.com/tops10_703_distr_bb-x140b-sb/index.html
(second save set)

> Last I knew, original tapes and disk packs are sitting
> collecting dust in a storage room in the basement of MRO2 in
> Marlboro. (I saw that storage room once back in 2003.)
> Practically everything for 36-bit computing was in there: BLKx packs,
> SNARK:, backup/dumper tapes of KL1026, KL2102, GIDNEY, CLOYD, spare
> KL-10 boards, etc. Timothe Litt was their caretaker. (It's not
> clear if TL is still at HP; if he isn't, then it's completely unclear
> what has happened/will happen to all this material.

Sounds like the archive that I head XKL got access to.

One tragedy Dan Murphy one related was that he had left a pack with
his archive of historical versions of TECO in Marlboro, and when he
called to have it mounted, found out it had been thrown out....
3-Jan-2006 12:39:26-PST,4369;000000000000
Return-Path: <[email protected]>
Received: from smtpout.mac.com ([17.250.248.87]) by lingling.panda.com with TCP/SMTP; Tue, 3 Jan 2006 12:29:49 -0800 (PST)
Received: from mac.com (smtpin03-en2 [10.13.10.148])
by smtpout.mac.com (Xserve/8.12.11/smtpout05/MantshX 4.0) with ESMTP id k03KTZIN014685;
Tue, 3 Jan 2006 12:29:35 -0800 (PST)
Received: from [192.168.1.51] (c-24-128-160-88.hsd1.nh.comcast.net [24.128.160.88])
(authenticated bits=0)
by mac.com (Xserve/smtpin03/MantshX 4.0) with ESMTP id k03KTTdG020651;
Tue, 3 Jan 2006 12:29:31 -0800 (PST)
Mime-Version: 1.0
Message-Id: <p06230901bfe08dbc2a29@[192.168.1.51]>
In-Reply-To: <[email protected]>
References: <[email protected]>
<p06230904bfe04b4795f3@[192.168.1.51]>
<[email protected]>
Date: Tue, 3 Jan 2006 15:29:50 -0500
To: Rich Alderson <[email protected]>,
[email protected]
From: "John J. Francini" <[email protected]>
Subject: Re: TCP/IP stacks for TOPS-10 [Was: Re: 2005, yet another record
year of TOPS-20 list traffic]
Content-Type: text/plain; charset="us-ascii" ; format="flowed"

Hmmm. Hadn't heard of an MEIS. Wonder how different that is from a
NIA-20 (which kills a Massbus slot)?

Too bad the TOPS-10 side of the house didn't embrace TCP/IP before
the development efforts ended.

john

At 14:15 -0500 1/3/06, Rich Alderson wrote:
>Piggy-backing off John Francini's subject line to respond to MRC's comments:
>
>>> 2005 is also the year in which we can welcome real DEC 36-bit iron back
>>> to the Internet. DEC-10.PDPPLANET.COM is a 2060 running TOPS-10, and is
>>> part of Paul Allen's zoo. It doesn't do TCP/IP itself; instead it uses
>>> terminal ports connected to a cisco terminal server. I don't know if it's
>>> because they don't have the old TOPS-10 TCP/IP software, or because they
>>> don't have suitable hardware. Nonetheless, it's great to see a real KL
>>> on the network again, especially when trying to answer those nagging "what
>>> does a real KL do with such-and-such" questions.
>
>There are a couple of factors involved.
>
>First, the monitor running on our 2065 (MG memory, MCA25 cache) is from the
>KLAD installation tapes, FILDDTed to announce itself as PDPplanet, so it's
>straight DEC. I've not been able to build a monitor that recognizes the DH-11
>lines[1] when I boot it, and with the current shortage of disk
>space[2] I can't
>install sources anyway so have to work with the emulators and transfer files
>to the -10 by FTPing to the Toad-1 and writing a 9-track tape.[3]
>
>Beyond that, I don't have the source to any TCP/IP implementation for Tops-10.
>The only one we knew of at XKL was the CMU code which is lost in an
>uncataloged
>warehouse of tapes; for other reasons we never completed our port of
>Tops-10 to
>the Toad-1 anyway.
>
>Finally, I doubt that any implementation for Tops-10 was done with the MEIS[4]
>in mind, so we'd still have to add hardware to the system to make it work. By
>connecting a terminal server in milking machine mode to the front end, we have
>a system on the net.
>
> Rich
>
>[1] Actually an Able Computing DH/DM single-board work-alike.
>[2] The system only has a single RP06 drive running at a time, so that we do
> not get into the problems we had when we lost multiple drives at once. We
> are far along on a replacement strategy.
>[3] Kermit-10 is available from the 2065 out through the terminal server, but
> is of course not really feasible for very large files at 9600bps.
>[4] The Stanford-designed and built MASSBUS Ethernet Interface Subsystem which
> was also a cisco Systems product at one time.

--
----
John Francini <mailto:[email protected]>
+---------------------------------------------------------------------------+
| "I have come to the conclusion that one useless man is called a disgrace; |
| that two are called a law firm; and that three or more become a Congress.|
| And by God I have had _this_ Congress!" |
| -- John Adams |
+---------------------------------------------------------------------------+
3-Jan-2006 13:09:08-PST,5220;000000000000
Return-Path: <[email protected]>
Received: from nic.cafax.se ([192.71.228.17]) by lingling.panda.com with TCP/SMTP; Tue, 3 Jan 2006 13:03:29 -0800 (PST)
Received: from nic.cafax.se (localhost [127.0.0.1])
by nic.cafax.se (8.12.11/8.12.11) with ESMTP id k03L3LLk012627
for <[email protected]>; Tue, 3 Jan 2006 22:03:21 +0100 (MET)
Received: (from bygg@localhost)
by nic.cafax.se (8.12.11/8.12.11/Submit) id k03L3Lek018352
for [email protected]; Tue, 3 Jan 2006 22:03:21 +0100 (MET)
Date: Tue, 3 Jan 2006 22:03:21 WET
From: Johnny Eriksson <[email protected]>
To: [email protected]
Subject: Re: TCP/IP stacks for TOPS-10 [Was: Re: 2005, yet another record
year of TOPS-20 list traffic]
In-Reply-To: Your message of Tue, 3 Jan 2006 11:25:17 -0500
Message-ID: <[email protected]>

"John J. Francini" <[email protected]> wrote:

> As someone who hung around DEC10 Development for awhile in the late
> 80s, I can say with reasonable confidence that there never _was_ a
> DEC-issued and supported TCP/IP stack for TOPS-10. Several of our
> customer sites implemented their own stacks, and the fine folks in
> Sweden implemented one for 7.03 on a KI if memory serves.

The system here was KICKI, a 3-cpu system running 7.02. The last
supported version of TOPS-10 for the KI was 7.01A, but the code to
handle KI cpus (and KI paging) was left in 7.02, and it still mostly
worked, even if some of the new code for 7.02 "assumed" a processor
that was either a KL or a KS. For instance, the latter cpus have a
defined final value in the AC after a BLT, while the KI does not...

For 7.03 the KI support was physically removed from the sources.

The KICKI system ran 7.02, with DECnet phase IV from 7.03 retro-
fitted, and the CMU TCP/IP merged in, with additions to do the IP
packets over a DDP link instead of via an IMP. Parts of getting
the DDP code running correctly was done by a visiting Robert D.
Houk, if the name rings a bell...

Anyhow, not all of the sources are lost, the monitor sources to the
last version of the KICKI monitor are available on-line at stacken,
check out ftp://ftp.stacken.kth.se/pub/pdp10/kicki/ for instance.

There has been a one-person effort going on very slowly for some
years now, to write a new TCP/IP stack for TOPS-10, in this case
for 7.04 running on a KS10 (or a SIMH). There are two systems
that I know of running this at the moment, one sits in my home
behind my firewall, the other is located at stacken. Both are
based on SIMH, with ethernet emulation (DEUNA/DELUA) added.

Ping works. UDP works. Outgoing TCP (like telnet) somewhat works.

> TOPS-10's supported networking protocols were ANF-10, DECnet, and LAT.
>
> It's a bit frustrating for TOPS-10 fans like me who want to install a
> system on a Linux box using KLH, because the only way to talk to it
> (at least with the stock KLH microengine) is through the console.
> (If you run KLH on an Alpha running older versions of Digital UNIX,
> you can use DECnet, but that's no bargain either.)

Another mention: I have added KDP/DUP emulation to my SIMH, and
the two systems mentioned above are actually connected to each
other that way:

.net/a
[ANF10 network: connected to TOPSY(1), located at TOPSY(1), 2 nodes]
Node TOPSY (1) topsy 04-Feb-04
Node NADJA (7) nadja 05-Feb-04

One side effect of this is that I can access the external emulator
via one of its TTY ports, .SET HOST home, and then access machines
behind my firewall... This is the *only* way to get through my fw,
and I believe it to be fairly script-kiddie-safe.

> The SIMH emulator at least supports DZ-11 emulation through Telnet,
> although it only emulates a KS-10 processor.
>
> One other way to get around it, I'd suppose, would be to add "real"
> DTE support to both KLH and SIMH. Then you could emulate a
> full-blown DEC-10 environment, including the console DTE running
> RSX20F -- supporting emulated DH11s, as well as additional copies of
> SIMH running DN8x ANF-10 software.

One way would be to find some software to do LAT as a client.

Another way could be to try to interface the ANF-over-ethernet code
(D8EINT) to the SIMH/DEUNA code, and use a SIMH system as a front
end to handle terminals.

> One potential fly in this ointment is that I'm not sure that any of
> the PDP-11 DN8x software has been released and/or put up on the
> Internet. Last I knew, original tapes and disk packs are sitting
> collecting dust in a storage room in the basement of MRO2 in
> Marlboro. (I saw that storage room once back in 2003.)
> Practically everything for 36-bit computing was in there: BLKx packs,
> SNARK:, backup/dumper tapes of KL1026, KL2102, GIDNEY, CLOYD, spare
> KL-10 boards, etc. Timothe Litt was their caretaker. (It's not
> clear if TL is still at HP; if he isn't, then it's completely unclear
> what has happened/will happen to all this material.

You do realise that this is a holy grail, do you?

Unless I am mistaken, the DN87 sources are on the tape images available
on trailing-edge.

> John Francini

--Johnny
3-Jan-2006 13:44:45-PST,1989;000000000000
Return-Path: <[email protected]>
Received: from sj-iport-1.cisco.com ([171.71.176.70]) by lingling.panda.com with TCP/SMTP; Tue, 3 Jan 2006 13:39:00 -0800 (PST)
Received: from sj-core-1.cisco.com ([171.71.177.237])
by sj-iport-1.cisco.com with ESMTP; 03 Jan 2006 13:38:52 -0800
Received: from cisco.com (cypher.cisco.com [171.69.11.142])
by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k03LcpZe010746;
Tue, 3 Jan 2006 13:38:51 -0800 (PST)
Received: (from billw@localhost)
by cisco.com (8.8.8-Cisco List Logging/8.8.8) id NAA15864;
Tue, 3 Jan 2006 13:38:51 -0800 (PST)
Sender: Bill Westfield <[email protected]>
Date: Tue, 3 Jan 2006 13:38:51 PST
From: William "Chops" Westfield <[email protected]>
To: "John J. Francini" <[email protected]>
Cc: Rich Alderson <[email protected]>,
[email protected]
Subject: Re: TCP/IP stacks for TOPS-10 [Was: Re: 2005, yet another record
year of TOPS-20 list traffic]
In-Reply-To: Your message of Tue, 3 Jan 2006 15:29:50 -0500 "Jagadeesh Maiya
(jmaiya)" <[email protected]>, "Bruce Babcock (bbabcock)"
<[email protected]>, "Don Schriner (dschrine)" <[email protected]>,
"Phillip Remaker (remaker)" <[email protected]>
Subject: Re: Terminal Services
In-Reply-To: Your message of Tue, 03 Jan 2006 11:15:13 -0700
Message-ID: <CMM.0.90.4.1136324331.billw@cypher>

Hmmm. Hadn't heard of an MEIS.
Wonder how different that is from a NIA-20 (which kills a Massbus slot)?

Very much different. Sat at the end of a massbus cable, didn't kill any
massbus slots (the NIA actually killed several, didn't it? Both due to
physical size and because DEC would insist on installing the CI support at
the same time. IIRC the combination took 4 of the 8 massbus slots, even if
all you wanted was a single ethernet connection.) The MEIS also handled
multiple ethernet interfaces in combinations of 10Mb and 3Mb (Xerox
experimental ethernet.)

BillW

3-Jan-2006 14:50:18-PST,7462;000000000000
Return-Path: <[email protected]>
Received: from smtpout.mac.com ([17.250.248.89]) by lingling.panda.com with TCP/SMTP; Tue, 3 Jan 2006 14:44:47 -0800 (PST)
Received: from mac.com (smtpin01-en2 [10.13.10.146])
by smtpout.mac.com (Xserve/8.12.11/smtpout02/MantshX 4.0) with ESMTP id k03MiMtx010539;
Tue, 3 Jan 2006 14:44:22 -0800 (PST)
Received: from [192.168.1.51] (c-24-128-160-88.hsd1.nh.comcast.net [24.128.160.88])
(authenticated bits=0)
by mac.com (Xserve/smtpin01/MantshX 4.0) with ESMTP id k03MiKL9010429;
Tue, 3 Jan 2006 14:44:21 -0800 (PST)
Mime-Version: 1.0
Message-Id: <p06230903bfe0ab1a0cae@[192.168.1.51]>
In-Reply-To: <[email protected]>
References: <[email protected]>
Date: Tue, 3 Jan 2006 17:44:38 -0500
To: Johnny Eriksson <[email protected]>, [email protected]
From: "John J. Francini" <[email protected]>
Subject: Re: TCP/IP stacks for TOPS-10
Content-Type: text/plain; charset="us-ascii" ; format="flowed"

At 22:03 +0000 1/3/06, Johnny Eriksson wrote:
>"John J. Francini" <[email protected]> wrote:
>
>> As someone who hung around DEC10 Development for awhile in the late
>> 80s, I can say with reasonable confidence that there never _was_ a
>> DEC-issued and supported TCP/IP stack for TOPS-10. Several of our
>> customer sites implemented their own stacks, and the fine folks in
>> Sweden implemented one for 7.03 on a KI if memory serves.
>
>The system here was KICKI, a 3-cpu system running 7.02. The last
>supported version of TOPS-10 for the KI was 7.01A, but the code to
>handle KI cpus (and KI paging) was left in 7.02, and it still mostly
>worked, even if some of the new code for 7.02 "assumed" a processor
>that was either a KL or a KS. For instance, the latter cpus have a
>defined final value in the AC after a BLT, while the KI does not...
>
>For 7.03 the KI support was physically removed from the sources.
>
>The KICKI system ran 7.02, with DECnet phase IV from 7.03 retro-
>fitted, and the CMU TCP/IP merged in, with additions to do the IP
>packets over a DDP link instead of via an IMP. Parts of getting
>the DDP code running correctly was done by a visiting Robert D.
>Houk, if the name rings a bell...

RDH -- definitely a 'blast from the past', as we'd say in the States.

>Anyhow, not all of the sources are lost, the monitor sources to the
>last version of the KICKI monitor are available on-line at stacken,
>check out ftp://ftp.stacken.kth.se/pub/pdp10/kicki/ for instance.

That's good!

>
>There has been a one-person effort going on very slowly for some
>years now, to write a new TCP/IP stack for TOPS-10, in this case
>for 7.04 running on a KS10 (or a SIMH). There are two systems
>that I know of running this at the moment, one sits in my home
>behind my firewall, the other is located at stacken. Both are
>based on SIMH, with ethernet emulation (DEUNA/DELUA) added.
>
>Ping works. UDP works. Outgoing TCP (like telnet) somewhat works.
>
>> TOPS-10's supported networking protocols were ANF-10, DECnet, and LAT.
>>
>> It's a bit frustrating for TOPS-10 fans like me who want to install a
>> system on a Linux box using KLH, because the only way to talk to it
>> (at least with the stock KLH microengine) is through the console.
>> (If you run KLH on an Alpha running older versions of Digital UNIX,
>> you can use DECnet, but that's no bargain either.)
>
>Another mention: I have added KDP/DUP emulation to my SIMH, and
>the two systems mentioned above are actually connected to each
>other that way:

Cool. The PDP-11 derived UNIBUS hardware I/O architecture of the KS
made it easy to do that sort of thing, as well as to add it to SIMH
..

> .net/a
> [ANF10 network: connected to TOPSY(1), located at TOPSY(1), 2 nodes]
> Node TOPSY (1) topsy 04-Feb-04
> Node NADJA (7) nadja 05-Feb-04
>
>One side effect of this is that I can access the external emulator
>via one of its TTY ports, .SET HOST home, and then access machines
>behind my firewall... This is the *only* way to get through my fw,
>and I believe it to be fairly script-kiddie-safe.

The only people likely to figure out a hack -- if possible -- would
be people like us on this list, and we've probably all got Better
Things To Do (tm) than that sort of thing...

>
>> The SIMH emulator at least supports DZ-11 emulation through Telnet,
>> although it only emulates a KS-10 processor.
>>
>> One other way to get around it, I'd suppose, would be to add "real"
>> DTE support to both KLH and SIMH. Then you could emulate a
>> full-blown DEC-10 environment, including the console DTE running
>> RSX20F -- supporting emulated DH11s, as well as additional copies of
>> SIMH running DN8x ANF-10 software.
>
>One way would be to find some software to do LAT as a client.

I'm not sure, that this _may_ work if you run KLH on a Digital UNIX
box, as it supported both DECnet and LAT. Unclear if you could do
'reverse LAT' that way; I'd have to play with it.

>Another way could be to try to interface the ANF-over-ethernet code
>(D8EINT) to the SIMH/DEUNA code, and use a SIMH system as a front
>end to handle terminals.
>
>> One potential fly in this ointment is that I'm not sure that any of
>> the PDP-11 DN8x software has been released and/or put up on the
>> Internet. Last I knew, original tapes and disk packs are sitting
>> collecting dust in a storage room in the basement of MRO2 in
>> Marlboro. (I saw that storage room once back in 2003.)
>> Practically everything for 36-bit computing was in there: BLKx packs,
>> SNARK:, backup/dumper tapes of KL1026, KL2102, GIDNEY, CLOYD, spare
>> KL-10 boards, etc. Timothe Litt was their caretaker. (It's not
>> clear if TL is still at HP; if he isn't, then it's completely unclear
>> what has happened/will happen to all this material.
>
>You do realise that this is a holy grail, do you?

Oh yes I do. When I worked there, Tim had asked me to keep it quiet
that this stuff still existed, until he could figure some way to
convince the powers at (then) Compaq to let it go. I left in 2003,
but as far as I know, the stuff's still there -- unless Phil Budne's
in-passing comment about XKL getting access to sources is in fact
true.

An effort would have to be mounted to copy/convert/sanitize the
files. (Some tapes contain personal information, and while most
everyone involved has moved on to other endeavors [or unfortunately
taken the final EXIT 1,], it's still best to keep this info private.)
Also, clearances would need to be obtained if anything that DEC built
and distributed with or for TOPS-10/20 came from a 3rd party.

>Unless I am mistaken, the DN87 sources are on the tape images available
>on trailing-edge.

You (and others) have corrected me. I sit corrected.

John
--
----
John Francini <mailto:[email protected]>
+---------------------------------------------------------------------------+
| "I have come to the conclusion that one useless man is called a disgrace; |
| that two are called a law firm; and that three or more become a Congress.|
| And by God I have had _this_ Congress!" |
| -- John Adams |
+---------------------------------------------------------------------------+
3-Jan-2006 15:14:29-PST,4286;000000000000
Return-Path: <[email protected]>
Received: from smtpout.mac.com ([17.250.248.86]) by lingling.panda.com with TCP/SMTP; Tue, 3 Jan 2006 15:08:47 -0800 (PST)
Received: from mac.com (smtpin03-en2 [10.13.10.148])
by smtpout.mac.com (Xserve/8.12.11/smtpout04/MantshX 4.0) with ESMTP id k03N8dsF006238;
Tue, 3 Jan 2006 15:08:39 -0800 (PST)
Received: from [192.168.1.51] (c-24-128-160-88.hsd1.nh.comcast.net [24.128.160.88])
(authenticated bits=0)
by mac.com (Xserve/smtpin03/MantshX 4.0) with ESMTP id k03N8bbR022996;
Tue, 3 Jan 2006 15:08:38 -0800 (PST)
Mime-Version: 1.0
Message-Id: <p06230904bfe0af04f784@[192.168.1.51]>
In-Reply-To: <CMM.0.90.4.1136324331.billw@cypher>
References: <CMM.0.90.4.1136324331.billw@cypher>
Date: Tue, 3 Jan 2006 18:08:55 -0500
To: William Chops Westfield <[email protected]>
From: "John J. Francini" <[email protected]>
Subject: Re: TCP/IP stacks for TOPS-10 [Was: Re: 2005, yet another record
year of TOPS-20 list traffic]
Cc: Rich Alderson <[email protected]>,
[email protected]
Content-Type: text/plain; charset="us-ascii" ; format="flowed"

Indeed. When DEC converted a system to use KLNIA and/or KLIPA
hardware, you lost the use of the top 4 MASSBUS slots.

If I recall correctly, this was because of cooling requirements,
along with the fact that converting a system to KLNIA/KLIPA required
backplane wiring changes. My understanding is that DEC's conversion
instructions were all-or-nothing: you couldn't convert only one pair
of MASSBUS channels for, say, NIA-20 operation, because the FS people
were not given instructions on how to do that alone.

OTOH, back then, the theoretical sheer amount of disk space you could
add through one or more HSC-50 controllers vastly outweighed the
capacity lost on the MASSBUS slots lost. Plus, the KLIPA made
TOPS-20 CFS clustering possible.

So it was seen (or at least sold) as a win for the customer. It
certainly was a win for us in DEC-10 Development. The primary TOPS-10
development system, KL1026, consisted of three CPUs, 1026, 1042, and
2476. 1026 and 1042 were 1090s, while 2476 was a 1091 (a blue-cabinet
2060). NIAs and IPAs were installed in all three CPUs, and all of
the BLKx packs were on RA81 and RA60 drives. Since the HSCs were
connected to all three CPUs, we could get at the BLK packs no matter
how many CPUs were running.

Before this, the BLKx packs used to be on RP07s dual-ported between
KL1026 and KL1042. There were occasional 'degenerate' situations when
both KL1026 and KL1042, the older two KLs, were down with hardware
problems, while KL2476 was running. And then we wouldn't see all the
RP07s.

KL2476 was a newer 1091 with external memory channels AND internal
memory. If the external memory was giving us problems, we could
switch KL2476 to use the internal memory and thus keep the
development system running. We couldn't do this without physically
re-cabling MASSBUS disks from system to system.

So the IPA was a win, at least for us.

John Francini

At 13:38 -0800 1/3/06, William Chops Westfield wrote:
> Hmmm. Hadn't heard of an MEIS.
> Wonder how different that is from a NIA-20 (which kills a Massbus slot)?
>
>Very much different. Sat at the end of a massbus cable, didn't kill any
>massbus slots (the NIA actually killed several, didn't it? Both due to
>physical size and because DEC would insist on installing the CI support at
>the same time. IIRC the combination took 4 of the 8 massbus slots, even if
>all you wanted was a single ethernet connection.) The MEIS also handled
>multiple ethernet interfaces in combinations of 10Mb and 3Mb (Xerox
>experimental ethernet.)
>
>BillW

--
----
John Francini <mailto:[email protected]>
+---------------------------------------------------------------------------+
| "I have come to the conclusion that one useless man is called a disgrace; |
| that two are called a law firm; and that three or more become a Congress.|
| And by God I have had _this_ Congress!" |
| -- John Adams |
+---------------------------------------------------------------------------+
3-Jan-2006 16:36:56-PST,2439;000000000000
Return-Path: <[email protected]>
Received: from mail1.panix.com ([166.84.1.72]) by lingling.panda.com with TCP/SMTP; Tue, 3 Jan 2006 16:31:24 -0800 (PST)
Received: from panix5.panix.com (panix5.panix.com [166.84.1.5])
by mail1.panix.com (Postfix) with ESMTP id 74B2858B18
for <[email protected]>; Tue, 3 Jan 2006 19:31:14 -0500 (EST)
Received: (from alderson@localhost)
by panix5.panix.com (8.11.6p3/8.8.8/PanixN1.1) id k040VE907089;
Tue, 3 Jan 2006 19:31:14 -0500 (EST)
Date: Tue, 3 Jan 2006 19:31:14 -0500 (EST)
Message-Id: <[email protected]>
From: Rich Alderson <[email protected]>
To: [email protected]
In-reply-to: <[email protected]> (message from Phil
Budne on Tue, 3 Jan 2006 15:28:35 -0500 (EST))
Subject: Re: TCP/IP stacks for TOPS-10 [Was: Re: 2005, yet another record year of TOPS-20 list traffic]
References: <[email protected]>

> Date: Tue, 3 Jan 2006 15:28:35 -0500 (EST)
> From: Phil Budne <[email protected]>

>> Last I knew, original tapes and disk packs are sitting collecting dust in a
>> storage room in the basement of MRO2 in Marlboro. (I saw that storage room
>> once back in 2003.) Practically everything for 36-bit computing was in
>> there: BLKx packs, SNARK:, backup/dumper tapes of KL1026, KL2102, GIDNEY,
>> CLOYD, spare KL-10 boards, etc. Timothe Litt was their caretaker. (It's
>> not clear if TL is still at HP; if he isn't, then it's completely unclear
>> what has happened/will happen to all this material.

> Sounds like the archive that I head XKL got access to.

Only more organized.

We were getting tapes from Dick G. from time to time, as time allowed. (We
didn't know Tim's name then, or his role in the effort.) The problem was that
these were BACKUP tapes made by reading DUMPER tapes in interchange mode and
then dumping the content back to tape, so a lot of information was getting
lost.

Eventually, I made a couple of trips to Massachusetts, and Dick, Tim and I went
through stacks of tapes. If we found duplicates, XKL got one, and there were
lots of duplicates. This also made it possible for us to start a Tops-10 port,
which a number of potentially large customers wanted.

But this was in 1995, long before John Francini's view of the storage room.

Rich
3-Jan-2006 16:43:21-PST,1384;000000000000
Mail-From: MRC created at 3-Jan-2006 16:38:55
Date: Tue, 3 Jan 2006 16:38:55 -0800 (PST)
From: Mark Crispin <[email protected]>
Subject: Re: TCP/IP stacks for TOPS-10 [Was: Re: 2005, yet another record
To: [email protected]
cc: [email protected]
In-Reply-To: <p06230904bfe0af04f784@[192.168.1.51]>
Pithy-Thought: TOPS-20 was a great improvement over its successors
Message-ID: <[email protected]>

> If I recall correctly, this was because of cooling requirements,
> along with the fact that converting a system to KLNIA/KLIPA required
> backplane wiring changes. My understanding is that DEC's conversion
> instructions were all-or-nothing: you couldn't convert only one pair
> of MASSBUS channels for, say, NIA-20 operation, because the FS people
> were not given instructions on how to do that alone.

Yet, somehow, the MEIS used a single channel *and* was available
before the NIA.

> OTOH, back then, the theoretical sheer amount of disk space you could
> add through one or more HSC-50 controllers vastly outweighed the
> capacity lost on the MASSBUS slots lost.

So the small matter that this additional disk space was forced
through fewer pipes never concerned Digital?

> Plus, the KLIPA made
> TOPS-20 CFS clustering possible.

I suspect that many more TOPS-20 sites used Ethernet than CFS.
-------
3-Jan-2006 18:35:56-PST,5057;000000000000
Return-Path: <[email protected]>
Received: from smtpout.mac.com ([17.250.248.88]) by lingling.panda.com with TCP/SMTP; Tue, 3 Jan 2006 18:30:28 -0800 (PST)
Received: from mac.com (smtpin02-en2 [10.13.10.147])
by smtpout.mac.com (Xserve/8.12.11/smtpout01/MantshX 4.0) with ESMTP id k042UMxR017004;
Tue, 3 Jan 2006 18:30:22 -0800 (PST)
Received: from [192.168.1.51] (c-24-128-160-88.hsd1.nh.comcast.net [24.128.160.88])
(authenticated bits=0)
by mac.com (Xserve/smtpin02/MantshX 4.0) with ESMTP id k042UIlW001186;
Tue, 3 Jan 2006 18:30:21 -0800 (PST)
Mime-Version: 1.0
Message-Id: <p06230907bfe0dbe87d99@[192.168.1.51]>
In-Reply-To: <[email protected]>
References: <[email protected]>
Date: Tue, 3 Jan 2006 21:30:34 -0500
To: Mark Crispin <[email protected]>
From: "John J. Francini" <[email protected]>
Subject: Re: TCP/IP stacks for TOPS-10 [Was: Re: 2005, yet another record
Cc: [email protected]
Content-Type: text/plain; charset="us-ascii" ; format="flowed"

> > If I recall correctly, this was because of cooling requirements,
>> along with the fact that converting a system to KLNIA/KLIPA required
>> backplane wiring changes. My understanding is that DEC's conversion
>> instructions were all-or-nothing: you couldn't convert only one pair
>> of MASSBUS channels for, say, NIA-20 operation, because the FS people
>> were not given instructions on how to do that alone.
>
>Yet, somehow, the MEIS used a single channel *and* was available
>before the NIA.

Not terribly surprising. This was back in the days when Digital was
seen as a behemoth with 3 heads (after a fairly famous Business Week
cover). It took a while to turn the ship. I don't know what the
technical/marketing/political reasons were that led to the
KLIPA/KLNIA design. I'm sure they could have done the same as the
MEIS, both for Ethernet and for disk.

> > OTOH, back then, the theoretical sheer amount of disk space you could
>> add through one or more HSC-50 controllers vastly outweighed the
>> capacity lost on the MASSBUS slots lost.
>
>So the small matter that this additional disk space was forced
>through fewer pipes never concerned Digital?

For the list's benefit, what you're alluding to, I believe, is the
fact that while there were two physical paths to each RAxx disk, and
two paths to each KLIPA, data actually only flowed through one path
from KL<->HSC50<->disk unit; the other path was effectively a hot
spare. This is in sharp contrast to dual-porting RP06/RP07/RP20
drives, where both ports were simultaneously active and available.

No, it unfortunately didn't concern the decision-makers. We engineers
knew darn well that the throughput wasn't anywhere near what a
dual-ported RP07 was capable of. We used a significant number of
them in DEC-10/DEC-20 development because we (a) had to support the
stuff, (b) believed in eating our own dogfood, (c) needed to keep
lots of stuff on-line at one time, and (d) were paying a lot (even in
internal-transfer funny money) for Field Service support of the aging
RP06/RP07/RP20 drives. Also, a row of RA60/RA81/HSC50/Star Coupler
gear gave a much higher storage-to-footprint ratio. (You could stack
RA81s 3 or 4 high in a single 19" rack, while a single RP06 was about
50% wider.)

Much of this was an attempt to offer the users increased storage
space through the use of designs already in-house. And of course,
the idea was that if a customer made the investment in a bunch of HSC
disks, they could later re-purpose all that gear to the VAXcluster
that would surely follow in the 10/20's place. (They'd probably even
eat the cost of replacing all the 18-bit HDAs in the RA8x drives if
it meant you went VAX and stayed with DEC.)

At the time, the RP07 (which was a buy-in from Sperry Univac if
memory serves) was DEC's fastest disk drive available. It was capable
of transferring 2.2 megabytes per second. Only KL-10 systems could
use the RP07 at full throughput; when an RP07 was connected to a VAX
Massbus, it had to be throttled down to 1.1 MB/sec. Compared to
today's interconnects, such as SCSI-320, SATA, FireWire, or even
USB2, these speeds seem rather quaintly slow. For the time, however,
they were blazing, especially for DEC gear.

John

>
>> Plus, the KLIPA made
>> TOPS-20 CFS clustering possible.
>
>I suspect that many more TOPS-20 sites used Ethernet than CFS.
>-------

--
----
John Francini <mailto:[email protected]>
+---------------------------------------------------------------------------+
| "I have come to the conclusion that one useless man is called a disgrace; |
| that two are called a law firm; and that three or more become a Congress.|
| And by God I have had _this_ Congress!" |
| -- John Adams |
+---------------------------------------------------------------------------+
3-Jan-2006 20:47:18-PST,1731;000000000000
Return-Path: <[email protected]>
Received: from sj-iport-2.cisco.com ([171.71.176.71]) by lingling.panda.com with TCP/SMTP; Tue, 3 Jan 2006 20:41:33 -0800 (PST)
Received: from sj-core-5.cisco.com ([171.71.177.238])
by sj-iport-2.cisco.com with ESMTP; 03 Jan 2006 20:41:27 -0800
Received: from cisco.com (cypher.cisco.com [171.69.11.142])
by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id k044fQYW020928;
Tue, 3 Jan 2006 20:41:26 -0800 (PST)
Received: (from billw@localhost)
by cisco.com (8.8.8-Cisco List Logging/8.8.8) id UAA03299;
Tue, 3 Jan 2006 20:41:25 -0800 (PST)
Sender: Bill Westfield <[email protected]>
Date: Tue, 3 Jan 2006 20:41:25 PST
From: William "Chops" Westfield <[email protected]>
To: Mark Crispin <[email protected]>
Cc: [email protected], [email protected]
Subject: Re: TCP/IP stacks for TOPS-10 [Was: Re: 2005, yet another record
In-Reply-To: Your message of Tue, 3 Jan 2006 16:38:55 -0800 (PST)
Message-ID: <CMM.0.90.4.1136349685.billw@cypher>

As for getting TCP connectivity to tops10... If the main interest is
telnet access for ttys, might it not be easier to write something on the
unix ("microcode") side that emulates whatever tops10 tty driver (on the
10 side) and talks to the unix tcp stack for actual connectivity? I'm
not at all familiar with tops tty hardware level drivers; all the systems
I ever used were based on network connectivity or "smart 8" front ends
that did the tty handling... We CAN do actual development for tops10/tops20,
right? We're not restricted to getting the stuff that used to exist working
in the emulated environment?

And, um, perhaps I shouldn't mention it, but how about the old tops10
NCP arpanet stack?

BillW
4-Jan-2006 09:14:57-PST,3980;000000000000
Return-Path: <[email protected]>
Received: from smtpout.mac.com ([17.250.248.71]) by lingling.panda.com with TCP/SMTP; Wed, 4 Jan 2006 09:08:40 -0800 (PST)
Received: from mac.com (smtpin01-en2 [10.13.10.146])
by smtpout.mac.com (Xserve/8.12.11/smtpout14/MantshX 4.0) with ESMTP id k04H8YQb007388;
Wed, 4 Jan 2006 09:08:34 -0800 (PST)
Received: from [10.68.5.13] ([12.45.253.10])
(authenticated bits=0)
by mac.com (Xserve/smtpin01/MantshX 4.0) with ESMTP id k04H8WFB015096;
Wed, 4 Jan 2006 09:08:33 -0800 (PST)
In-Reply-To: <CMM.0.90.4.1136349685.billw@cypher>
References: <CMM.0.90.4.1136349685.billw@cypher>
Mime-Version: 1.0 (Apple Message framework v746.2)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <[email protected]>
Cc: Mark Crispin <[email protected]>, [email protected]
Content-Transfer-Encoding: 7bit
From: John Francini <[email protected]>
Subject: Re: TCP/IP stacks for TOPS-10 [Was: Re: 2005, yet another record
Date: Wed, 4 Jan 2006 12:08:10 -0500
To: William Chops Westfield <[email protected]>
X-Mailer: Apple Mail (2.746.2)

Well, TOPS-10 (as shipped by DEC) talked to TTYs in these ways:

a) through DH-11s connected to the console FE

b) via ANF-10 networked front-ends (PDP-11s) connected to one of the
other three DTE interfaces, which means the connection could be
coming from either a remote terminal concentrator (another PDP-11 or
PDP-8), or another DEC-10 system via the SET HOSTESs command

c) through "hardwired" terminals connected to a DC-10 on the I/O bus
(KA-vintage hardware -- if that support hasn't been removed from
'recent' Monitor releases);

c.2) through 'intelligent' I/O bus terminal concentrators like the
PDP-8 based DC68 and clones

d) through DECnet CTerm protocol

e) through LAT

------------------------------------------------------------------

As far as the 'microcode' side: if you use SIMH, you get Telnet
DZ-11 support 'for free', but are restricted to running on an
emulated KS-10. If you use KLH, you get a full-blown KL-10B
emulation, but I believe the code only supports a single DTE, and not
completely, AFAIK. You'd have to add code to support DH-11 emulation.
So the alternatives are:

a) Flesh out the DTE support in KLH (and add DH11 support) --
possibly to the point where you could boot RSX20F under SIMH (which
would need DTE-11 support added as well) and DN87 code in another
SIMH image;

b) Add an emulated DC-10 or DC-68 via I/O bus simulation to KLH;
b.2) Add an emulated DL10 (I/O bus interface to PDP-11 comm gear, KI-
vintage) to KLH; perhaps easier to emulate than the under-documented
DTE20 interface;

c) Add TCP/IP support to TOPS-10, perhaps with one of the various
customer IP stacks out there

I guess it all depends on what people feel more comfortable hacking
on: emulated hardware in C, or TOPS-10 Monitor guts in Macro-10...

At least one of the long-time TOPS-10 Monitor developers reads this
list. Care to comment? (You know who you are...
:-))

John

On 3 Jan 2006, at 23:41, William Chops Westfield wrote:

> As for getting TCP connectivity to tops10... If the main interest is
> telnet access for ttys, might it not be easier to write something
> on the
> unix ("microcode") side that emulates whatever tops10 tty driver
> (on the
> 10 side) and talks to the unix tcp stack for actual connectivity? I'm
> not at all familiar with tops tty hardware level drivers; all the
> systems
> I ever used were based on network connectivity or "smart 8" front ends
> that did the tty handling... We CAN do actual development for
> tops10/tops20,
> right? We're not restricted to getting the stuff that used to
> exist working
> in the emulated environment?
>
> And, um, perhaps I shouldn't mention it, but how about the old tops10
> NCP arpanet stack?
>
> BillW

5-Jan-2006 10:21:26-PST,7560;000000000000
Return-Path: <[email protected]>
Received: from mta1.srv.hcvlny.cv.net ([167.206.4.196]) by lingling.panda.com with TCP/SMTP; Thu, 5 Jan 2006 10:15:14 -0800 (PST)
Received: from optonline.net (hamstr19.srv.hcvlny.cv.net [167.206.5.70])
by mta1.srv.hcvlny.cv.net
(Sun Java System Messaging Server 6.2-4.03 (built Sep 22 2005))
with ESMTP id <[email protected]> for
[email protected]; Thu, 05 Jan 2006 13:14:57 -0500 (EST)
Received: from [10.240.3.35] (Forwarded-For: [69.114.1.48])
by mstr13.srv.hcvlny.cv.net (mshttpd); Thu, 05 Jan 2006 13:14:56 -0500
Date: Thu, 05 Jan 2006 13:14:56 -0500
From: [email protected]
Subject: Kermit does not properly restore terminal width for a VT100 in 132
column mode
In-reply-to: <[email protected]>
To: [email protected]
Cc: [email protected]
Message-id: <[email protected]>
MIME-version: 1.0
X-Mailer: Sun Java(tm) System Messenger Express 6.2-4.03 (built Sep 22 2005)
Content-type: text/plain; charset=us-ascii
Content-language: en
Content-transfer-encoding: 7BIT
Content-disposition: inline
X-Accept-Language: en
Priority: normal
References: <[email protected]>

Symptom:
========

When running on a terminal in VT100 'wide' mode (I.E., 132 columns),
Kermit does not properly restore the terminal width. It is reset to
zero after a transfer. For other length and width linear dimensions
which exceed 127, Kermit does the wrong thing.

Analysis:
=========

Kermit is saving the terminal dimensions with RFMOD% and restoring
them with STPAR%. Since the terminal JFN mode word only provides for
a seperate seven bit field for each linear value, it can be overflowed
by terminals which exceed 127 columns or lengths.

Proposed Solution:
==================

Use MTOPR% to record and restore the linear dimensions. This is up as
version 5.1(185)-2 on Tommy Timesharing. Final approval of the source
code modification will, of course, be pending on Frank's review.

Code Modifications:
===================

File 1) DSK:K20MIT.MAC[4,36] created: 1159 05-Jan-06
File 2) DSK:K20MIT.BAK[4,36] created: 1405 17-Mar-05

1)1 $edno==^d185 ; [185] Edit number increases independent of version.
1) $who==^d2 ; [184] Who edited, 0=Columbia.
****
2)1 $edno==^d184 ; [184] Edit number increases independent of version.
2) $who==^d2 ; [184] Who edited, 0=Columbia.
**************
1)1 ;[TOMMYT]STAR:<KERMIT>K20MIT.MAC.366, 4-Jan-2006 17:27:09, Edit by SLOGIN
1) ;[185] Properly restore terminal length and width for large dimensions
1) ;[TOMMYT]STAR:<KERMIT>K20MIT.MAC.355, 16-Mar-2005 14:47:16, Edit by SLOGIN
****
2)1 ;[TOMMYT]STAR:<KERMIT>K20MIT.MAC.355, 16-Mar-2005 14:47:16, Edit by SLOGIN
**************
1)137 movei t2, ttydim ;[185] Point to controlling terminal block
1) call savlnw ;[185] Save the terminal length and width
1) RFMOD ; Get tty mode word.
****
2)137 RFMOD ; Get tty mode word.
**************
1)138 movei t2, ttydim ;[185] Point to controlling terminal dimensions
1) call rstlnw ;[185] Restore length and width
1) movx t1, .fhjob ; Put tty back the way it was.
****
2)138 movx t1, .fhjob ; Put tty back the way it was.
**************
1)139 ;[185] Save and restore terminal lengths (a.k.a., heights) and widths.
1) ;[185] This is necessary because linear dimensions in excess of seven
1) ;[185] bits (127) can not be stored in the JFN mode word as saved by
1) ;[185] SFMOD% and restored by STPAR%
1) ;[185]
1) ;[185] As these are stored in halfwords, this allows for a maximum of
1) ;[185] 262,143 for either a width or a length. As this is two decimal
1) ;[185] orders of magnitude larger than the highest resolution graphics
1) ;[185] cards (4096 in 2006), we probably don't have to worry about
1) ;[185] overflowing the field for the next decade or so. None the
1) ;[185] less, the MTOPR% does return a FULL 36 bit word; so if we ever
1) ;[185] overflow 18 bits, then we should change this code.
1) ;[185]
1) ;[185] Assumes:
1) ;[185]
1) ;[185] t1/ Valid terminal JFN (possibly .PRIOU)
1) ;[185] t2/ Pointer to block to save length and width
1) ;[185]
1) ;[185] Preserves the register file and is completely silent about errors.
1) savlnw: saveac <t1,t2,t3,t4,q1> ;[185] Do not side-effect the register file!
1) dmove t4, t1 ;[185] Preserve JFN, dimension block address
1) ;[185]
1) DVCHR% ;[185] What kind of device is this?
1) erjmpr r ;[185] it's a bogus device!
1) load t3, dv%typ, t2 ;[185] Get device type field
1) caie t3, .dvtty ;[185] Is this a terminal?
1) ret ;[185] No, better leave it alone
1) move t1, t4 ;[185] Restore the JFN
1) ;[185] Assume infinite (and therefore useless)
1) setzb t3, (q1) ;[185] defaults for width and length
1) movx t2, .morll ;[185] Return the terminal page length
1) MTOPR% ;[185] Which may be over 127 ...
1) erjmps .+2 ;[185] Must be a bogus JFN
1) hrlm t3, (q1) ;[185] Save length
1) dmove t2,[exp .morlw,0] ;[185] Return the terminal page width.
1) MTOPR% ;[185] Which may be over 127 ...
1) erjmps .+2 ;[185] Must be a bogus JFN
1) hrrm t3, (q1) ;[185] Save length
1) ret ;[185] Done, restore register file
1) rstlnw: saveac <t1,t2,t3,t4,q1> ;[185] Do not side-effect the register file!
1) dmove t4, t1 ;[185] Preserve JFN, dimension block address
1) ;[185]
1) DVCHR% ;[185] What kind of device is this?
1) erjmpr r ;[185] it's a bogus device!
1) load t3, dv%typ, t2 ;[185] Get device type field
1) caie t3, .dvtty ;[185] Is this a terminal?
1) ret ;[185] No, better leave it alone
1) move t1, t4 ;[185] Restore the JFN
1) ;[185]
1) movx t2, .mosll ;[185] Set the terminal page length.
1) hlrz t3, (q1) ;[185] Load old width
1) caie t3, 0 ;[185] Ever get anything? If not, leave
1) MTOPR% ;[185] it alone; otherwise restore it
1) erjmps .+1 ;[185] Ignore errors, preserve JFN
1) movx t2, .moslw ;[185] Set the terminal page width.
1) hrrz t3, (q1) ;[185] Load old width
1) caie t3, 0 ;[185] Ever get anything? If not, leave
1) MTOPR% ;[185] it alone; otherwise restore it
1) erjmps .+1 ;[185] Ignore errors, preserve JFN
1) ret ;[185] Done, restore register file
1) ;[185] End code insertion
1)140 ;[77] DEFINE command, added as edit 77.
****
2)139 ;[77] DEFINE command, added as edit 77.
**************
1)220 movei t2, olddim ;[185] Point to line block
1) call savlnw ;[185] Save this JFN's length and width
1) RFMOD% ; Get current mode for this line.
****
2)219 RFMOD% ; Get current mode for this line.
**************
1)223 movei t2, olddim ;[185] Point to this JFN's dimensions
1) call rstlnw ;[185] Restore length and width
1) movx t2, .mosnt ; Restore system msg refuse/accept.
****
2)222 movx t2, .mosnt ; Restore system msg refuse/accept.
**************
1)277 ttydim: 0 ;[185] Current controlling tty dimensions
1) oldjfn: 0 ; JFN on previous line.
1) oldmod: 0 ; Previous mode of the line.
1) olddim: 0 ;[185] Old line dimensions
1) oldpau: 0 ; Previous terminal pause on end mode.
****
2)276 oldjfn: 0 ; JFN on previous line.
2) oldmod: 0 ; Previous mode of the line.
2) oldpau: 0 ; Previous terminal pause on end mode.
**************
1)283 ; Comment Start:;[185]
1) ; Auto Fill Mode: 0
1) ; End:
****
2)282 ; Comment Start:;[184]
2) ; Auto Fill Mode: 1
2) ; End:
**************

5-Jan-2006 11:39:59-PST,2932;000000000000
Return-Path: <[email protected]>
Received: from mta6.srv.hcvlny.cv.net ([167.206.4.201]) by lingling.panda.com with TCP/SMTP; Thu, 5 Jan 2006 11:34:59 -0800 (PST)
Received: from optonline.net (hamstr19.srv.hcvlny.cv.net [167.206.5.70])
by mta6.srv.hcvlny.cv.net
(Sun Java System Messaging Server 6.2-4.03 (built Sep 22 2005))
with ESMTP id <[email protected]>; Thu,
05 Jan 2006 14:34:38 -0500 (EST)
Received: from [10.240.3.35] (Forwarded-For: [69.114.1.48])
by mstr13.srv.hcvlny.cv.net (mshttpd); Thu, 05 Jan 2006 14:34:37 -0500
Date: Thu, 05 Jan 2006 14:34:37 -0500
From: [email protected]
Subject: Re: TCP/IP stacks for TOPS-10
In-reply-to: <[email protected]>
To: John Francini <[email protected]>
Cc: William Chops Westfield <[email protected]>,
Mark Crispin <[email protected]>, [email protected]
Message-id: <[email protected]>
MIME-version: 1.0
X-Mailer: Sun Java(tm) System Messenger Express 6.2-4.03 (built Sep 22 2005)
Content-type: text/plain; charset=us-ascii
Content-language: en
Content-transfer-encoding: 7BIT
Content-disposition: inline
X-Accept-Language: en
Priority: normal
References: <CMM.0.90.4.1136349685.billw@cypher>
<[email protected]>

> From: John Francini <[email protected]
> Date: Wednesday, January 4, 2006 12:08 pm
> Subject: Re: TCP/IP stacks for TOPS-10
>
> Well, TOPS-10 (as shipped by DEC) talked to TTYs in these ways:
...

> d) through DECnet CTerm protocol
> e) through LAT
...

> c) Add TCP/IP support to TOPS-10, perhaps with one of the various
> customer IP stacks out there

For what it's worth, my vote would be for putting the TCP/IP support
(back) into Tops-10. It seems that if CTerm and LAT (and also NRT?)
can be made to work, then there are probably enough ways into Tops-10
for the moment. Naturally, I'm always in favor of hacking MACRO.
Also, who knows if there will be another incarnation of the PDP-10
instruction set? Were that to be the case, then the Tops-10 code
would have the most long term usefulness.

Of course, I have my own personal reasons for wanting this: there
would be yet another 36 bit platform for me to test my FTP server
against. However, it looks like a significant amount of systems
programs would need to be implemented if FTP server and client and
Telnet server and client can not be recovered.

Alternatively, with suitable brain surgery (via the use of GLXLIB
which I know how to utilize) and the lose of some functionality and
(probably) performance, some form of my FTP server could probably be
brought up.

One assumes that this would generate enough traffic that Mark (or
somebody else) would probably need to bring up a Tops-10 Wizards
mailing list. Wouldn't that be pleasant ?

6-Jan-2006 08:51:54-PST,3503;000000000000
Return-Path: <[email protected]>
Received: from mta9.srv.hcvlny.cv.net ([167.206.4.204]) by lingling.panda.com with TCP/SMTP; Fri, 6 Jan 2006 08:46:27 -0800 (PST)
Received: from optonline.net (hamstr19.srv.hcvlny.cv.net [167.206.5.70])
by mta9.srv.hcvlny.cv.net
(Sun Java System Messaging Server 6.2-4.03 (built Sep 22 2005))
with ESMTP id <[email protected]> for
[email protected]; Fri, 06 Jan 2006 11:46:17 -0500 (EST)
Received: from [10.240.3.32] (Forwarded-For: [69.114.1.48])
by mstr13.srv.hcvlny.cv.net (mshttpd); Fri, 06 Jan 2006 11:46:16 -0500
Date: Fri, 06 Jan 2006 11:46:16 -0500
From: [email protected]
Subject: FTPing to an ITS machine produces 425 errors for certain STAT commands
In-reply-to: <[email protected]>
To: [email protected]
Message-id: <[email protected]>
MIME-version: 1.0
X-Mailer: Sun Java(tm) System Messenger Express 6.2-4.03 (built Sep 22 2005)
Content-type: text/plain; charset=us-ascii
Content-language: en
Content-transfer-encoding: 7BIT
Content-disposition: inline
X-Accept-Language: en
Priority: normal
References: <[email protected]>
<[email protected]>

Symptom:
========

When FTPing into an ITS FTP server, some uses of the STAT command can
cause errors. A bare STAT command (which reports the server status
and current parameters) works. Doing a STAT of a file does not, the
user is presented with the following:

425 Can't connect to your port 2523 - FILE ALREADY EXISTS

Analysis:
=========

The ITS FTP server is attempting to create a data port back to the
remote client to give its response. Since the STAT command is
supposed to report its results on the control port (as per RFC959),
the client does not have a data port set up and hence, this approach
will always fail. Investigation of the FTPS.MID source code reveals
the following logic:

STAT1: POP P,A ;Yes - Recover string for reparsing,
PJRST NLST ; and proceed like NLST command.

Since NLST does not appear to have code to respond on the control
port, it would seem that the ITS FTP server was explicitly coded for
this behavior. A previous version of the FTP specification (RFC765)
also specifies the use of the control port, but perhaps this was done
differently for NCP. I'm not familiar enough with the source code to
predict why this was done the way it was at this point.

Remarks:
========

The fix here would be to (obviously) write the code to respond on the
control port. Maybe it's straightforward enough so that I could do
it. Maybe I'll try once I get my own FTP server on the air.

This is an obscure error and I expect that it was never bumped into
(at least I didn't notice any mention of it on the old ITS FTP server
bug list) because few FTP clients send STAT commands for files. I
don't remember whether ange-ftp or other clients use STAT.

The Tops-20 FTP client will issue a STAT, but only if it determines
that it is talking to another Tops-20 or Tenex machine. Otherwise,
the STAT must be issued directly with the QUOTE command, which was
what I was doing when I bumped into this.

I would cross post this to ITS-LOVERS, but I don't know where this is
hosted and I don't know if it is on restricted distribution (I don't
want the Tops-20 list nor my email address getting snarfed by
spammers). Can somebody respond to me off list about this?

6-Jan-2006 09:26:02-PST,2483;000000000000
Return-Path: <[email protected]>
Received: from mta8.srv.hcvlny.cv.net ([167.206.4.203]) by lingling.panda.com with TCP/SMTP; Fri, 6 Jan 2006 09:20:50 -0800 (PST)
Received: from optonline.net (hamstr19.srv.hcvlny.cv.net [167.206.5.70])
by mta8.srv.hcvlny.cv.net
(Sun Java System Messaging Server 6.2-4.03 (built Sep 22 2005))
with ESMTP id <[email protected]> for
[email protected]; Fri, 06 Jan 2006 12:20:02 -0500 (EST)
Received: from [10.240.3.32] (Forwarded-For: [69.114.1.48])
by mstr13.srv.hcvlny.cv.net (mshttpd); Fri, 06 Jan 2006 12:20:01 -0500
Date: Fri, 06 Jan 2006 12:20:01 -0500
From: [email protected]
Subject: NETBIOS over TCP/IP for Tops-20 programming
In-reply-to: <[email protected]>
To: [email protected]
Message-id: <[email protected]>
MIME-version: 1.0
X-Mailer: Sun Java(tm) System Messenger Express 6.2-4.03 (built Sep 22 2005)
Content-type: text/plain; charset=us-ascii
Content-language: en
Content-transfer-encoding: 7BIT
Content-disposition: inline
X-Accept-Language: en
Priority: normal
References: <[email protected]>
<[email protected]> <[email protected]>

I'm looking to do some automated regression testing in an overnight
batch job that I would run on my 20. I would like to issue commands
to a Windows workstation to cause it to execute various batch
scripts.

There are any number of ways to do this, but what I'd like would be an
RPC client that I could use to issue the commands from the Tops-20
batch job. I don't believe that such a thing exists, but I'm
perfectly willing to cobble some excessively minimal hack together to
suit my needs. After all, any MACRO coding is a GOOD thing.

At lot of what I see talks about SAMBA, but I'm not up to porting that
beast just right now. Besides, ange-ftp and the Windows Explorer do
everything I want for the moment.

If anybody has any pointers about how to do this or alternative
approaches, specifications, etc., I'd appreciate it. My only
requirement is that I want to do the bulk of the coding on the 20 and
not have to put something together under Windows as my current
development environment there is broken (I kind of stopped paying
attention to it once I got my 20 online :-)

Please e-mail me off list. If I get something together, I'll post an
announcement and put it up for ANONYMOUS FTP.

6-Jan-2006 11:54:01-PST,3140;000000000000
Return-Path: <[email protected]>
Received: from mxout7.cac.washington.edu ([140.142.32.178]) by lingling.panda.com with TCP/SMTP; Fri, 6 Jan 2006 11:47:24 -0800 (PST)
Received: from smtp.washington.edu (smtp.washington.edu [140.142.32.139])
by mxout7.cac.washington.edu (8.13.5+UW05.10/8.13.5+UW05.09) with ESMTP id k06JlAKZ020640
(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK)
for <[email protected]>; Fri, 6 Jan 2006 11:47:10 -0800
X-Auth-Received: from pangtzu.panda.com (pangtzu.panda.com [206.124.149.117])
(authenticated authid=mrc)
by smtp.washington.edu (8.13.5+UW05.10/8.13.5+UW05.09) with ESMTP id k06Jl9f2007707
(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT)
for <[email protected]>; Fri, 6 Jan 2006 11:47:10 -0800
Date: Fri, 6 Jan 2006 11:47:09 -0800 (PST)
From: Mark Crispin <[email protected]>
Sender: [email protected]
To: TOPS-20 Hackers and Yackers <[email protected]>
Subject: SSL and SSH support in TOPS-20
Message-ID: <[email protected]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
X-Uwash-Spam: Gauge=IIIIIII, Probability=7%, Report='__CT 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __KNOWN_SPAMMER_ADDRESS_2 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0'

I have been thinking about how to do SSL/TLS and SSH support in TOPS-20.

For SSL/TLS, I think that the easiest/best method would be to add KLH10
microcode support that links to OpenSSL, as if it were a hardware
implementation of SSL/TLS. Since this would consume resources in the
microcode, these would be privileged instructions which TOPS-20 would
export via an TLS: device. That way, when the user process terminates, we
can easily arrange to clean up the resources at the OpenSSL end.

So, I'm mulling over the design of an "essential TLS" interface with the
options which are absolutely required: selection of method (SSL vs. TLS,
client vs. server) and (in the case of servers) provision of the server
certificate and key. Everything else will be added later via MTOPR.

For SSH server, I think that the easiest/best method would be to negotiate
with the OpenSSH developers to see if we can split off OpenSSH server code
from UNIX virtual terminal handling; that is, have some sort of
abstraction layer. We would implement that abstraction layer as DH11
lines in the DTE. This requires itemizing what's in RSX-20F protocol and
cross-referencing that with UNIX pty operations to determine what would be
a good abstraction layer for both. The result is that SSH sessions would
look like dialups as if it were on a "milking machine", but in fact it
would be completely flow-controlled. I suspect that it'd actually be
quite a bit faster than TELNET.

I don't have a good idea for SSH client yet. Perhaps we can leverage on
the OpenSSL interface, but I don't think so.

-- Mark --

http://panda.com/mrc
Democracy is two wolves and a sheep deciding what to eat for lunch.
Liberty is a well-armed sheep contesting the vote.
6-Jan-2006 15:56:31-PST,1171;000000000000
Return-Path: <[email protected]>
Received: from sesame.cc.columbia.edu ([128.59.59.56]) by lingling.panda.com with TCP/SMTP; Fri, 6 Jan 2006 15:51:46 -0800 (PST)
Received: from sesame.cc.columbia.edu (localhost [127.0.0.1])
by sesame.cc.columbia.edu (8.13.0/8.13.0) with ESMTP id k06Npdv7024206
for <[email protected]>; Fri, 6 Jan 2006 18:51:39 -0500 (EST)
Received: (from fdc@localhost)
by sesame.cc.columbia.edu (8.13.0/8.12.8/Submit) id k06NpZZ2024203
for [email protected]; Fri, 6 Jan 2006 18:51:35 -0500 (EST)
Date: Fri, 6 Jan 2006 18:51:35 -0500 (EST)
From: Frank da Cruz <[email protected]>
To: [email protected]
Subject: New Kermit Release for TOPS-20
Message-ID: <[email protected]>

It's 5.1(186), with Tom De Bellis's updates since 2003, plus for Kermit-20's
25th anniversary, I added a version date (today's) to the program herald and
the SHOW VERSION display. Just two files:

ftp://kermit.columbia.edu/kermit/d/k20mit.mac (source)
ftp://kermit.columbia.edu/kermit/d/k20mit.txt (update notes)

The web page is:

http://www.columbia.edu/kermit/pdp10.html

- Frank
8-Jan-2006 14:03:47-PST,2082;000000000000
Return-Path: <[email protected]>
Received: from mta5.srv.hcvlny.cv.net ([167.206.4.200]) by lingling.panda.com with TCP/SMTP; Sun, 8 Jan 2006 13:58:10 -0800 (PST)
Received: from optonline.net (hamstr19.srv.hcvlny.cv.net [167.206.5.70])
by mta5.srv.hcvlny.cv.net
(Sun Java System Messaging Server 6.2-4.03 (built Sep 22 2005))
with ESMTP id <[email protected]> for
[email protected]; Sun, 08 Jan 2006 16:58:03 -0500 (EST)
Received: from [10.240.3.34] (Forwarded-For: [69.114.1.48])
by mstr13.srv.hcvlny.cv.net (mshttpd); Sun, 08 Jan 2006 16:58:03 -0500
Date: Sun, 08 Jan 2006 16:58:03 -0500
From: [email protected]
Subject: Parsing LINK switches with % does not work on a Toad EXEC
In-reply-to: <[email protected]>
To: [email protected]
Message-id: <[email protected]>
MIME-version: 1.0
X-Mailer: Sun Java(tm) System Messenger Express 6.2-4.03 (built Sep 22 2005)
Content-type: text/plain; charset=us-ascii
Content-language: en
Content-transfer-encoding: 7BIT
Content-disposition: inline
X-Accept-Language: en
Priority: normal
References: <[email protected]>
<[email protected]> <[email protected]>
<[email protected]>

I finally got an account on a Toad so I could start testing some
things with my FTP server. I also hope to do some Kermit regression
testing at some point.

Anyway, I seem to have developed a talent: I immediately bumped into a
problem. Consider the following when trying to generate a Kermit
executable:

@LOAD /COMPILE /MACRO %"/SAVE/GO" K20MIT.MAC

This breaks, you get:

?Not confirmed - ""/SAVE/GO" K20MIT.MAC"

There is some way that I used an escape to make this not happen work,
but I can't seem to get it to work right now. It always works on
PANDA. I don't know if I have access to the Toad Tops-20 EXEC
sources, so I can't fix this or speculate as to why this happens, but
I thought I'd report it.

Am I doing anything obviously wrong?
8-Jan-2006 15:24:19-PST,2263;000000000000
Return-Path: <[email protected]>
Received: from smtp02.mrf.mail.rcn.net ([207.172.4.62]) by lingling.panda.com with TCP/SMTP; Sun, 8 Jan 2006 15:18:42 -0800 (PST)
Received: from 208-59-182-51.s1321.apx1.sbo.ma.dialup.rcn.com (HELO RCN.Com) ([208.59.182.51])
by smtp02.mrf.mail.rcn.net with ESMTP; 08 Jan 2006 18:18:31 -0500
X-IronPort-AV: i="3.99,344,1131339600";
d="scan'208"; a="192656938:sNHT27476178"
Message-ID: <[email protected]>
Date: Sun, 08 Jan 2006 18:18:37 -0500
From: "Alan H. Martin" <[email protected]>
X-Mailer: Mozilla 4.77 [en] (Win95; U)
X-Accept-Language: en,en-US,en-GB,es
MIME-Version: 1.0
To: [email protected]
CC: [email protected]
Subject: Re: Parsing LINK switches with % does not work on a Toad EXEC
References: <[email protected]>
<[email protected]> <[email protected]>
<[email protected]> <[email protected]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

[email protected] wrote:

> Anyway, I seem to have developed a talent: I immediately bumped into a
> problem. Consider the following when trying to generate a Kermit
> executable:
>
> @LOAD /COMPILE /MACRO %"/SAVE/GO" K20MIT.MAC
>
> This breaks, you get:
>
> ?Not confirmed - ""/SAVE/GO" K20MIT.MAC"
>
> There is some way that I used an escape to make this not happen work,
> but I can't seem to get it to work right now. It always works on
> PANDA. I don't know if I have access to the Toad Tops-20 EXEC
> sources, so I can't fix this or speculate as to why this happens, but
> I thought I'd report it.
>
> Am I doing anything obviously wrong?

Uh, check out this line from a .CTL for the -10:

.DEBUG/DDT/COMPILE %"SEG:DEFAULT" T.FOR

And I did have the faint memory that the first slash is always omitted.

Maybe it's actually optional.
Maybe EXEC has a subtly different syntax.
(Maybe someone locallay hacked an EXEC to make the first slash
optional).

But try this:

@LOAD /COMPILE /MACRO %"SAVE/GO" K20MIT.MAC

and report back.
Hope this helps,
/AHM
--
Alan Howard Martin [email protected]
8-Jan-2006 16:47:20-PST,3031;000000000000
Return-Path: <[email protected]>
Received: from mta2.srv.hcvlny.cv.net ([167.206.4.197]) by lingling.panda.com with TCP/SMTP; Sun, 8 Jan 2006 16:42:06 -0800 (PST)
Received: from optonline.net (hamstr19.srv.hcvlny.cv.net [167.206.5.70])
by mta2.srv.hcvlny.cv.net
(Sun Java System Messaging Server 6.2-4.03 (built Sep 22 2005))
with ESMTP id <[email protected]> for
[email protected]; Sun, 08 Jan 2006 19:41:25 -0500 (EST)
Received: from [10.240.3.34] (Forwarded-For: [69.114.1.48])
by mstr13.srv.hcvlny.cv.net (mshttpd); Sun, 08 Jan 2006 19:41:24 -0500
Date: Sun, 08 Jan 2006 19:41:24 -0500
From: [email protected]
Subject: Re: Parsing LINK switches with % does not work on a Toad EXEC
In-reply-to: <[email protected]>
To: "Alan H. Martin" <[email protected]>
Cc: [email protected]
Message-id: <[email protected]>
MIME-version: 1.0
X-Mailer: Sun Java(tm) System Messenger Express 6.2-4.03 (built Sep 22 2005)
Content-type: text/plain; charset=us-ascii
Content-language: en
Content-transfer-encoding: 7BIT
Content-disposition: inline
X-Accept-Language: en
Priority: normal
References: <[email protected]>
<[email protected]> <[email protected]>
<[email protected]> <[email protected]>
<[email protected]>

Hello Alan,

Thanks for responding,

> .DEBUG/DDT/COMPILE %"SEG:DEFAULT" T.FOR
>
> And I did have the faint memory that the first slash is always
> omitted. Maybe it's actually optional. Maybe EXEC has a subtly
> different syntax. (Maybe someone locallay hacked an EXEC to make
> the first slash optional).

I don't remember how Tops-10 worked in that regard, although I spent
quite a few years in High School (LIRICS) and college (WPI) using it.
Currently, my Tops-10 access does not appear to be properly connecting
just right now (Rich?!). It types the system banner, but the monitor
(SCNSER?) processes no commands, so I can't check this.

In any event, you are pointing out the syntax of the LINK switches
inside of the quoted strings. I don't believe that the EXEC touches
these switches, it passes them 'directly' to LINK (via CCL? TMPCOR?
TMP file?)

The EXEC would need to have a TBLUK% table of all of the LINK switches
to do a .CMKEY on the quoted nested switches and I don't believe it
does, nor does it need to. I typed the first / in the quoted string
for many years at Columbia for lots of stuff, it's pure (20 year old)
habit.

> But try this:
>
> @LOAD /COMPILE /MACRO %"SAVE/GO" K20MIT.MAC
>
> and report back.

It worked on TOMMYT (PANDA), but not on the Toad. From what I can
tell, it does not appear to be processing the .CMQST properly after
the .CMTOK, but that is speculation, so don't, err, "quote" me on it.
JSol pointed me at the Toad EXEC sources, so maybe I'll have a look at
these.

--T
9-Jan-2006 08:29:27-PST,3689;000000000000
Return-Path: <[email protected]>
Received: from service0.etnus.com ([68.162.234.181]) by lingling.panda.com with TCP/SMTP; Mon, 9 Jan 2006 08:23:04 -0800 (PST)
Received: from RCN.Com (ralfie.etnus.com [192.168.68.75])
by service0.etnus.com (Postfix) with ESMTP id AB54F1F823B;
Mon, 9 Jan 2006 11:22:47 -0500 (EST)
Sender: [email protected]
Message-ID: <[email protected]>
Date: Mon, 09 Jan 2006 11:22:47 -0500
From: "Alan H. Martin" <[email protected]>
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: [email protected]
Cc: [email protected]
Subject: Re: Parsing LINK switches with % does not work on a Toad EXEC
References: <[email protected]>
<[email protected]> <[email protected]>
<[email protected]> <[email protected]>
<[email protected]> <[email protected]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

[email protected] wrote:
>
> Hello Alan,
>
> Thanks for responding,
>
> > .DEBUG/DDT/COMPILE %"SEG:DEFAULT" T.FOR
> >
> > And I did have the faint memory that the first slash is always
> > omitted. Maybe it's actually optional. Maybe EXEC has a subtly
> > different syntax. (Maybe someone locallay hacked an EXEC to make
> > the first slash optional).
..
> In any event, you are pointing out the syntax of the LINK switches
> inside of the quoted strings. I don't believe that the EXEC touches
> these switches, it passes them 'directly' to LINK ...

I see (as I speculated) it does indeed permit a leading slash, and
checks to see whether a leading slash exists before adding one:

http://pdp-10.trailing-edge.com/tops20_version7_0_exec_sources_clock/01/exec-sources/execcs.mac.html

;PASS2S CALLED TO DUMP LINK SWITCH

PASS2S: MOVEI B,"/" ;OUTPUT SLASH
MOVE Q1,NAM(P2) ;GET STRING POINTER
ILDB Q1,Q1 ;PEEK AT FIRST CHAR
CAIE Q1,"/" ;IS IT A SLASH?
CALL TBOUT ;NO - DUMP ONE
MOVE B,NAM(P2) ;GET STRING
CALL TSOUT0 ;DUMP IT

I'm in no position to see whether some systems have had a bug introduced
in surrounding EXECCS code.

> The EXEC would need to have a TBLUK% table of all of the LINK switches
> to do a .CMKEY on the quoted nested switches and I don't believe it
> does, nor does it need to. ...

No one has suggested it needed to.

>... I typed the first / in the quoted string
> for many years at Columbia for lots of stuff, it's pure (20 year old)
> habit.

I confess I'll be surprised if %"/SW1/SW2" is a documented syntax. I'm
not too surprised that permitting the first slash is an extension, but I
suspect it's undocumented.

> > But try this:
> >
> > @LOAD /COMPILE /MACRO %"SAVE/GO" K20MIT.MAC
> >
> > and report back.
>
> It worked on TOMMYT (PANDA), but not on the Toad. From what I can
> tell, it does not appear to be processing the .CMQST properly after
> the .CMTOK, but that is speculation, so don't, err, "quote" me on it.
> JSol pointed me at the Toad EXEC sources, so maybe I'll have a look at
> these.

Sounds like someone ``fixed'' something in EXECCS and broke something
else in the process.

You could move a copy of each EXEC to the other system, and see if the
bug moves with EXEC, or stays with the O/S. At least that would
exonerate (or implicate) COMND%, etc.
/AHM/THX
--
Alan Howard Martin [email protected]
9-Jan-2006 11:36:03-PST,2900;000000000000
Return-Path: <[email protected]>
Received: from mail1.panix.com ([166.84.1.72]) by lingling.panda.com with TCP/SMTP; Mon, 9 Jan 2006 11:30:25 -0800 (PST)
Received: from panix5.panix.com (panix5.panix.com [166.84.1.5])
by mail1.panix.com (Postfix) with ESMTP id 57EED59658
for <[email protected]>; Mon, 9 Jan 2006 14:30:16 -0500 (EST)
Received: (from alderson@localhost)
by panix5.panix.com (8.11.6p3/8.8.8/PanixN1.1) id k09JUG613976;
Mon, 9 Jan 2006 14:30:16 -0500 (EST)
Date: Mon, 9 Jan 2006 14:30:16 -0500 (EST)
Message-Id: <[email protected]>
From: Rich Alderson <[email protected]>
To: [email protected]
In-reply-to: <[email protected]> ([email protected])
Subject: PDPplanet 2065 [was Re: Parsing LINK switches with % does not work on a Toad EXEC]
References: <[email protected]>
<[email protected]> <[email protected]>
<[email protected]> <[email protected]>
<[email protected]> <[email protected]>

> Date: Sun, 08 Jan 2006 19:41:24 -0500
> From: [email protected]
>
> Hello Alan,
>
> Thanks for responding,
>
> > .DEBUG/DDT/COMPILE %"SEG:DEFAULT" T.FOR
> >
> > And I did have the faint memory that the first slash is always
> > omitted. Maybe it's actually optional. Maybe EXEC has a subtly
> > different syntax. (Maybe someone locallay hacked an EXEC to make
> > the first slash optional).
>
> I don't remember how Tops-10 worked in that regard, although I spent
> quite a few years in High School (LIRICS) and college (WPI) using it.
> Currently, my Tops-10 access does not appear to be properly connecting
> just right now (Rich?!). It types the system banner, but the monitor
> (SCNSER?) processes no commands, so I can't check this.
>
> In any event, you are pointing out the syntax of the LINK switches
> inside of the quoted strings. I don't believe that the EXEC touches
> these switches, it passes them 'directly' to LINK (via CCL? TMPCOR?
> .TMP file?)
>
> The EXEC would need to have a TBLUK% table of all of the LINK switches
> to do a .CMKEY on the quoted nested switches and I don't believe it
> does, nor does it need to. I typed the first / in the quoted string
> for many years at Columbia for lots of stuff, it's pure (20 year old)
> habit.
>
> > But try this:
> >
> > @LOAD /COMPILE /MACRO %"SAVE/GO" K20MIT.MAC
> >
> > and report back.
>
> It worked on TOMMYT (PANDA), but not on the Toad. From what I can
> tell, it does not appear to be processing the .CMQST properly after
> the .CMTOK, but that is speculation, so don't, err, "quote" me on it.
> JSol pointed me at the Toad EXEC sources, so maybe I'll have a look at
> these.
>
> --T
>
9-Jan-2006 11:41:29-PST,1664;000000000000
Return-Path: <[email protected]>
Received: from mail3.panix.com ([166.84.1.74]) by lingling.panda.com with TCP/SMTP; Mon, 9 Jan 2006 11:35:19 -0800 (PST)
Received: from panix5.panix.com (panix5.panix.com [166.84.1.5])
by mail3.panix.com (Postfix) with ESMTP id B3C5B13A871
for <[email protected]>; Mon, 9 Jan 2006 14:35:11 -0500 (EST)
Received: (from alderson@localhost)
by panix5.panix.com (8.11.6p3/8.8.8/PanixN1.1) id k09JZBU23197;
Mon, 9 Jan 2006 14:35:11 -0500 (EST)
Date: Mon, 9 Jan 2006 14:35:11 -0500 (EST)
Message-Id: <[email protected]>
From: Rich Alderson <[email protected]>
To: [email protected]
In-reply-to: <[email protected]> ([email protected])
Subject: oh, <mumble>: PDPplanet 2065 status
References: <[email protected]>
<[email protected]> <[email protected]>
<[email protected]> <[email protected]>
<[email protected]> <[email protected]>

> Currently, my Tops-10 access does not appear to be properly connecting
> just right now (Rich?!). It types the system banner, but the monitor
> (SCNSER?) processes no commands, so I can't check this.

I was sick over the weekend, and didn't take the time to look at the 2065's
status. When I saw Tom's note, I checked on it and found that it had gone
catatonic after midnight Friday/Saturday. We checked all the breakers, and
the voltages on the -11, and rebooted.

It's up and running now.

Rich
9-Jan-2006 15:39:26-PST,1229;000000000000
Return-Path: <[email protected]>
Received: from sesame.cc.columbia.edu ([128.59.59.56]) by lingling.panda.com with TCP/SMTP; Mon, 9 Jan 2006 15:33:48 -0800 (PST)
Received: from sesame.cc.columbia.edu (localhost [127.0.0.1])
by sesame.cc.columbia.edu (8.13.0/8.13.0) with ESMTP id k09NXX2V003890
for <[email protected]>; Mon, 9 Jan 2006 18:33:33 -0500 (EST)
Received: (from fdc@localhost)
by sesame.cc.columbia.edu (8.13.0/8.12.8/Submit) id k09NXWkh003889
for [email protected]; Mon, 9 Jan 2006 18:33:32 -0500 (EST)
Date: Mon, 9 Jan 2006 18:33:32 EST
From: Frank da Cruz <[email protected]>
To: [email protected]
Subject: Another C-MM beta
Message-ID: <[email protected]>

In the regular place:

http://www.columbia.edu/~fdc/mm/
ftp://kermit.columbia.edu/kermit/mm/test/mm-ccmd-0.95-20060109.tar.gz

Mail-file locking is back (at least for Columbia), and I fixed the REMAIL
command to work like it used to (and like it's supposed to), and I juggled
some filenames so it should be less tricky to build it on Mac OS X.

If anybody plans on doing anything to MM, please grab the latest sources
rather than using older ones. Thanks.

- Frank
9-Jan-2006 15:54:18-PST,2910;000000000000
Return-Path: <[email protected]>
Received: from smtpout.mac.com ([17.250.248.72]) by lingling.panda.com with TCP/SMTP; Mon, 9 Jan 2006 15:49:15 -0800 (PST)
Received: from mac.com (smtpin02-en2 [10.13.10.147])
by smtpout.mac.com (Xserve/8.12.11/smtpout15/MantshX 4.0) with ESMTP id k09Nn8wU001343;
Mon, 9 Jan 2006 15:49:08 -0800 (PST)
Received: from [192.168.1.50] (c-24-128-160-88.hsd1.nh.comcast.net [24.128.160.88])
(authenticated bits=0)
by mac.com (Xserve/smtpin02/MantshX 4.0) with ESMTP id k09Nn103022292;
Mon, 9 Jan 2006 15:49:03 -0800 (PST)
Mime-Version: 1.0
Message-Id: <p0623090bbfe8a3eb561d@[192.168.1.50]>
In-Reply-To: <[email protected]>
References: <[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
<[email protected]> <[email protected]>
<[email protected]>
<[email protected]>
Date: Mon, 9 Jan 2006 18:49:01 -0500
To: Rich Alderson <[email protected]>,
[email protected]
From: "John J. Francini" <[email protected]>
Subject: Re: oh, <mumble>: PDPplanet 2065 status
Content-Type: text/plain; charset="us-ascii" ; format="flowed"

At 14:35 -0500 1/9/06, Rich Alderson wrote:
> > Currently, my Tops-10 access does not appear to be properly connecting
>> just right now (Rich?!). It types the system banner, but the monitor
>> (SCNSER?) processes no commands, so I can't check this.
>
>I was sick over the weekend, and didn't take the time to look at the 2065's
>status. When I saw Tom's note, I checked on it and found that it had gone
>catatonic after midnight Friday/Saturday. We checked all the breakers, and
>the voltages on the -11, and rebooted.
>
>It's up and running now.
>
> Rich

What's with Galaxy on the pdpplanet system? QUASAR seems to be in
some sort of permanent funk, which means that any command that runs
QUEUE (including MOUNT) doesn't work; neither does OPR. (Yes, I know
I don't have privs, but OPR doesn't even get a chance to check that
out.) I had hoped that the reboot would fix that, but it seems not.

Also, how goes the battle to get more disk space running?

Thanks,

John
--
----
John Francini <mailto:[email protected]>
+---------------------------------------------------------------------------+
| "I have come to the conclusion that one useless man is called a disgrace; |
| that two are called a law firm; and that three or more become a Congress.|
| And by God I have had _this_ Congress!" |
| -- John Adams |
+---------------------------------------------------------------------------+
9-Jan-2006 16:56:06-PST,826;000000000000
Return-Path: <[email protected]>
Received: from tops.drkngs.com ([206.82.248.65]) by lingling.panda.com with TCP/SMTP; Mon, 9 Jan 2006 16:49:46 -0800 (PST)
Date: Mon, 9 Jan 2006 16:29:48 -0800 (PST)
From: Jon Solomon <[email protected]>
Subject: Re: oh, <mumble>: PDPplanet 2065 status
To: [email protected]
cc: [email protected], [email protected]
In-Reply-To: <p0623090bbfe8a3eb561d@[192.168.1.50]>
Message-ID: <[email protected]>

I believe the problem is that us "non privved" users don't have
an IPCF and ENQ/DEQ quota. I have enq-deq and ipcf priviledges but
that doesn't seem to fix it.

Rich's account has 511 as those quotas ( I spied on an
acct.lst in his directory)... I tthink he has to set the
quotas to something other than 0.

--jsol
-------
9-Jan-2006 17:24:02-PST,3204;000000000000
Return-Path: <[email protected]>
Received: from smtpout.mac.com ([17.250.248.45]) by lingling.panda.com with TCP/SMTP; Mon, 9 Jan 2006 17:18:47 -0800 (PST)
Received: from mac.com (smtpin07-en2 [10.13.10.152])
by smtpout.mac.com (Xserve/8.12.11/smtpout11/MantshX 4.0) with ESMTP id k0A1Id2U016110;
Mon, 9 Jan 2006 17:18:39 -0800 (PST)
Received: from [192.168.1.50] (c-24-128-160-88.hsd1.nh.comcast.net [24.128.160.88])
(authenticated bits=0)
by mac.com (Xserve/smtpin07/MantshX 4.0) with ESMTP id k0A1IVU5012650;
Mon, 9 Jan 2006 17:18:37 -0800 (PST)
Mime-Version: 1.0
Message-Id: <p0623090ebfe8b9d864c6@[192.168.1.50]>
In-Reply-To: <[email protected]>
References: <[email protected]>
Date: Mon, 9 Jan 2006 20:18:30 -0500
To: Jon Solomon <[email protected]>
From: "John J. Francini" <[email protected]>
Subject: Re: oh, <mumble>: PDPplanet 2065 status
Cc: [email protected], [email protected]
Content-Type: text/plain; charset="us-ascii" ; format="flowed"

Hmmm. Zero isn't exactly the number the typical non-developer user
got in the DEC days (when I cut my teeth supporting the panoply of
TOPS-10 systems that actually allowed DEC to do minor things like pay
bills, ship product, etc.)

[Pointless aside: The internal software support group's DEC-10 was
named TWINKY(77), and when I got there I changed the monitor name
from TWINKY to "Hostess Twinky", since, after all, to get there you
had to SET HOSTESS TWINKY. In fact, my montor name lives on in the
headers of the BACKUP tape images of the TOPS-10 DECUS library tapes
that are out on Tim Shoppa's archive. The DECUS people came to us one
day in the mid-1980s to cut a new set of master tapes from their
DCUS: pack. A typical header:

Start of Saveset on MTA771 LIB2
System Hostess Twinky KL703/70A TOPS-10 monitor 703(31042)-2 APR#1122
1600 BPI 9-track 26-Jun-86 14:07:15 BACKUP 5(614) tape format 1
Tape number 1

Ah, memories...]

I had wanted to play with QUEUE/MOUNT and OPR since I had worked on
merging them. Too bad we never added any code to handle the 'no
ENQ/DEQ or no IPCF quota' case. I guess we developers didn't ever
foresee a system where ordinary users would have no quota.

John

At 16:29 -0800 1/9/06, Jon Solomon wrote:
>I believe the problem is that us "non privved" users don't have
>an IPCF and ENQ/DEQ quota. I have enq-deq and ipcf priviledges but
>that doesn't seem to fix it.
>
>Rich's account has 511 as those quotas ( I spied on an
>acct.lst in his directory)... I tthink he has to set the
>quotas to something other than 0.
>
>--jsol
>-------

--
----
John Francini <mailto:[email protected]>
+---------------------------------------------------------------------------+
| "I have come to the conclusion that one useless man is called a disgrace; |
| that two are called a law firm; and that three or more become a Congress.|
| And by God I have had _this_ Congress!" |
| -- John Adams |
+---------------------------------------------------------------------------+
9-Jan-2006 17:42:48-PST,2537;000000000000
Return-Path: <[email protected]>
Received: from mail2.panix.com ([166.84.1.73]) by lingling.panda.com with TCP/SMTP; Mon, 9 Jan 2006 17:37:32 -0800 (PST)
Received: from panix5.panix.com (panix5.panix.com [166.84.1.5])
by mail2.panix.com (Postfix) with ESMTP id A92939DC1F
for <[email protected]>; Mon, 9 Jan 2006 20:37:24 -0500 (EST)
Received: (from alderson@localhost)
by panix5.panix.com (8.11.6p3/8.8.8/PanixN1.1) id k0A1bOA13332;
Mon, 9 Jan 2006 20:37:24 -0500 (EST)
Date: Mon, 9 Jan 2006 20:37:24 -0500 (EST)
Message-Id: <[email protected]>
From: Rich Alderson <[email protected]>
To: [email protected]
In-reply-to: <[email protected]> (message from Jon Solomon on
Mon, 9 Jan 2006 16:29:48 -0800 (PST))
Subject: Re: oh, <mumble>: PDPplanet 2065 status
References: <[email protected]>

> Date: Mon, 9 Jan 2006 16:29:48 -0800 (PST)
> From: Jon Solomon <[email protected]>

> I believe the problem is that us "non privved" users don't have an IPCF and
> ENQ/DEQ quota. I have enq-deq and ipcf priviledges but that doesn't seem to
> fix it.

> Rich's account has 511 as those quotas ( I spied on an acct.lst in his
> directory)... I tthink he has to set the quotas to something other than 0.

<ACK>

Read that however you like.

I've been deluded by my Tops-20 background (as I was when trying to single-
step an INCHWL in Tops-10 DDT). On Tops-20, of course, an ENQ/DEQ or IPCF
quota of 0 gets you the system default value, and I wrongly assumed (yeah...)
that Tops-10 worked the same way. I even thought I had seen that in the REACT
help info, but it's not there.

I just glanced at the Tops-10 Monitor Calls chapter on ENQ/DEQ, and read the
following:

9.1 ENQ. QUOTAS

Your job cannot use the ENQ. facility unless it has a nonzero ENQ. quota.
This quota is the total number of ENQ. requests plus ENQ. locks that the
job can have at any one time.

Yes, my account has 511. as the quota because that's the max, and I don't like
for quotas to get in the way when I'm trying to admin a system, just as I have
all the Tops-20 privileges set in my login directory on the Toad-1.

OK, what's a reasonable value, and does the user also need ENQ/DEQ and IPCF
privileges for the quotas to be meaningful? I'll fix everyone's accounts as
soon as I have the answer to those questions (or tomorrow).

Rich
9-Jan-2006 20:08:30-PST,4293;000000000000
Return-Path: <[email protected]>
Received: from smtpout.mac.com ([17.250.248.97]) by lingling.panda.com with TCP/SMTP; Mon, 9 Jan 2006 20:02:16 -0800 (PST)
Received: from mac.com (smtpin08-en2 [10.13.10.153])
by smtpout.mac.com (Xserve/8.12.11/smtpout06/MantshX 4.0) with ESMTP id k0A429vv013530;
Mon, 9 Jan 2006 20:02:09 -0800 (PST)
Received: from [192.168.1.50] (c-24-128-160-88.hsd1.nh.comcast.net [24.128.160.88])
(authenticated bits=0)
by mac.com (Xserve/smtpin08/MantshX 4.0) with ESMTP id k0A427RC002055;
Mon, 9 Jan 2006 20:02:08 -0800 (PST)
Mime-Version: 1.0
Message-Id: <p06230912bfe8cd3ff10b@[192.168.1.50]>
In-Reply-To: <[email protected]>
References: <[email protected]>
<[email protected]>
Date: Mon, 9 Jan 2006 23:02:07 -0500
To: Rich Alderson <[email protected]>, [email protected]
From: "John J. Francini" <[email protected]>
Subject: Re: oh, <mumble>: PDPplanet 2065 status
Content-Type: text/plain; charset="us-ascii" ; format="flowed"

I went looking for some REACT documentation; I found the whole of the
Software Notebooks on the bitsavers.org web site. First place I
looked was the TOPS-10 Operator's Guide. It doesn't have all that
much to say, referring interested parties to the TOPS-10 Software
Installation Guide. However, before leaving the subject of REACT, it
does offer this doozy of a CAUTION:

Do not attempt to update the accounting file unless you are completely
familiar with the REACT program. This program has no safeguards;
therefore, a mistake can have serious consequences.

Onward to the Software Installation guide. In Chapter 11,
"Maintaining the System Authorization File", an example account is
shown with default settings. The ones that matter here are:

* Context-quotas: Context 4, Total pages 512
* Core limits: Physical 512, Virtual 512
* ENQ/DEQ quota: 100
* IPCF quotas: Send 2, Receive 5, PIDs 2

Hope this helps!

John

At 20:37 -0500 1/9/06, Rich Alderson wrote:
> > Date: Mon, 9 Jan 2006 16:29:48 -0800 (PST)
>> From: Jon Solomon <[email protected]>
>
>> I believe the problem is that us "non privved" users don't have an IPCF and
>> ENQ/DEQ quota. I have enq-deq and ipcf priviledges but that doesn't seem to
>> fix it.
>
>> Rich's account has 511 as those quotas ( I spied on an acct.lst in his
>> directory)... I tthink he has to set the quotas to something other than 0.
>
><ACK>
>
>Read that however you like.
>
>I've been deluded by my Tops-20 background (as I was when trying to single-
>step an INCHWL in Tops-10 DDT). On Tops-20, of course, an ENQ/DEQ or IPCF
>quota of 0 gets you the system default value, and I wrongly assumed (yeah...)
>that Tops-10 worked the same way. I even thought I had seen that in the REACT
>help info, but it's not there.
>
>I just glanced at the Tops-10 Monitor Calls chapter on ENQ/DEQ, and read the
>following:
>
> 9.1 ENQ. QUOTAS
>
> Your job cannot use the ENQ. facility unless it has a nonzero ENQ. quota.
> This quota is the total number of ENQ. requests plus ENQ. locks that the
> job can have at any one time.
>
>Yes, my account has 511. as the quota because that's the max, and I don't like
>for quotas to get in the way when I'm trying to admin a system, just as I have
>all the Tops-20 privileges set in my login directory on the Toad-1.
>
>OK, what's a reasonable value, and does the user also need ENQ/DEQ and IPCF
>privileges for the quotas to be meaningful? I'll fix everyone's accounts as
>soon as I have the answer to those questions (or tomorrow).
>
> Rich

--
----
John Francini <mailto:[email protected]>
+---------------------------------------------------------------------------+
| "I have come to the conclusion that one useless man is called a disgrace; |
| that two are called a law firm; and that three or more become a Congress.|
| And by God I have had _this_ Congress!" |
| -- John Adams |
+---------------------------------------------------------------------------+
9-Jan-2006 22:59:09-PST,3676;000000000000
Return-Path: <[email protected]>
Received: from mta7.srv.hcvlny.cv.net ([167.206.4.202]) by lingling.panda.com with TCP/SMTP; Mon, 9 Jan 2006 22:53:52 -0800 (PST)
Received: from optonline.net (hamstr19.srv.hcvlny.cv.net [167.206.5.70])
by mta7.srv.hcvlny.cv.net
(Sun Java System Messaging Server 6.2-4.03 (built Sep 22 2005))
with ESMTP id <[email protected]> for
[email protected]; Tue, 10 Jan 2006 01:53:45 -0500 (EST)
Received: from [10.240.3.37] (Forwarded-For: [216.179.91.114])
by mstr13.srv.hcvlny.cv.net (mshttpd); Tue, 10 Jan 2006 01:53:45 -0500
Date: Tue, 10 Jan 2006 01:53:45 -0500
From: [email protected]
Subject: Re: Parsing LINK switches with % does not work on a Toad EXEC
In-reply-to: <[email protected]>
To: "Alan H. Martin" <[email protected]>
Cc: [email protected]
Message-id: <[email protected]>
MIME-version: 1.0
X-Mailer: Sun Java(tm) System Messenger Express 6.2-4.03 (built Sep 22 2005)
Content-type: text/plain; charset=us-ascii
Content-language: en
Content-transfer-encoding: 7BIT
Content-disposition: inline
X-Accept-Language: en
Priority: normal
References: <[email protected]>
<[email protected]> <[email protected]>
<[email protected]> <[email protected]>
<[email protected]> <[email protected]>
<[email protected]>

> Sounds like someone ``fixed'' something in EXECCS and broke
> something else in the process.
>
> You could move a copy of each EXEC to the other system, and see if
> the bug moves with EXEC, or stays with the O/S. At least that would
> exonerate (or implicate) COMND%, etc.

Yes, this was my suspicion, also. I tried compiling a PANDA EXEC with
an XKL EXECCS, but that actually worked. I was surprised by that
because there *is* a small change for the handling of % (to make
MM-BUILD work right), but I don't think this is in the code path that
is being executed.

I tried breakpointing the % .CMTOK handling code (at TPER:) but it is
so simple and straightforward that I don't see how it could possibly
be breaking. I did notice that as I did this, that if I hit an escape
in the right place that it actually worked. My results were
inconsistent, however. Anyway, here is the code snippet:

TPER: QUOTEX <LINK switch, in quotes>
CMERRX <Invalid LINK switch>
JRST TALL ;AFTER LINK SWITCH, ANYTHING MAY BE TYPED

It looks like it just wants to parse a quoted string and hand whatever
it gets to LINK. However, I'm really speculating at this point
because I haven't chased down what happens in QUOTEX nor seen what
happens when the parse is finally done. I'm trying to stay focused on
getting EFTPSR together. For now, it's easy enough to just change my
MIC files.

That's an interesting point about COMND% and I had thought about it
too. I don't have access to the XKL monitor sources either, but my
suspicion is that if the problem were with COMND% itself, then we
would be seeing a lot more stuff breaking. I don't have enough
experience using the XKL monitor/Exec to have any useful opinions
about them (I just started using them about a week ago).

I can say one thing, however: if there *is* a problem with COMND%,
then my Extended Mode FTP server will probably tickle it. I use
COMND% all over the place to parse commands. In some cases, I build
up parse lists and TBLUK% tables on the fly to properly handle the
stuff I get for the Unix simulator. Yech... But it works well enough.

9-Jan-2006 23:51:07-PST,2389;000000000000
Return-Path: <[email protected]>
Received: from mxout1.cac.washington.edu ([140.142.32.134]) by lingling.panda.com with TCP/SMTP; Mon, 9 Jan 2006 23:46:30 -0800 (PST)
Received: from smtp.washington.edu (smtp.washington.edu [140.142.33.9])
by mxout1.cac.washington.edu (8.13.5+UW05.10/8.13.5+UW05.09) with ESMTP id k0A7kNSx016722
(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
Mon, 9 Jan 2006 23:46:24 -0800
X-Auth-Received: from pangtzu.panda.com (pangtzu.panda.com [206.124.149.117])
(authenticated authid=mrc)
by smtp.washington.edu (8.13.5+UW05.10/8.13.5+UW05.09) with ESMTP id k0A7kMkT028925
(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT);
Mon, 9 Jan 2006 23:46:23 -0800
Date: Mon, 9 Jan 2006 23:46:22 -0800 (PST)
From: Mark Crispin <[email protected]>
Sender: [email protected]
To: [email protected]
cc: "Alan H. Martin" <[email protected]>, [email protected]
Subject: Re: Parsing LINK switches with % does not work on a Toad EXEC
In-Reply-To: <[email protected]>
Message-ID: <[email protected]>
References: <[email protected]> <[email protected]>
<[email protected]> <[email protected]>
<[email protected]> <[email protected]>
<[email protected]> <[email protected]>
<[email protected]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
X-Uwash-Spam: Gauge=IIIIIII, Probability=7%, Report='__CT 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0'

I confirmed that this is a bug in XKL's EXEC.

On an XKL system, the command:
@COMPILE %"foo/bar" FOO.MAC
gives an error in the XKL EXEC. If you do the same thing in the Panda
EXEC on the same XKL system, it compiles FOO.MAC (it doesn't matter that
the switches are bogus since no linking is done).

In fact, it looks to me like % in COMPILE/LOAD/EXECUTE commands is
completely broken in the XKL EXEC, at least on xkleten.paulallen.com which
is the only XKL that I have an account.

-- Mark --

http://panda.com/mrc
Democracy is two wolves and a sheep deciding what to eat for lunch.
Liberty is a well-armed sheep contesting the vote.
10-Jan-2006 14:18:46-PST,4258;000000000000
Return-Path: <[email protected]>
Received: from a.mail.sonic.net ([64.142.16.245]) by lingling.panda.com with TCP/SMTP; Tue, 10 Jan 2006 14:13:14 -0800 (PST)
Received: from Amiga.local (64-142-29-114.dsl.static.sonic.net [64.142.29.114])
by a.mail.sonic.net (8.13.3/8.13.3) with ESMTP id k0AMD7E9003406
for <[email protected]>; Tue, 10 Jan 2006 14:13:07 -0800
Date: Tue, 10 Jan 2006 14:13:07 -0800 (PST)
From: Fred Wright <[email protected]>
X-Sender: [email protected]
Reply-To: Fred Wright <[email protected]>
To: [email protected]
Subject: Re: Parsing LINK switches with % does not work on a Toad EXEC
In-Reply-To: <[email protected]>
Message-ID: <[email protected]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

On Sun, 8 Jan 2006, Alan H. Martin wrote:
> [email protected] wrote:
>
> > Anyway, I seem to have developed a talent: I immediately bumped into a
> > problem. Consider the following when trying to generate a Kermit
> > executable:
> >
> > @LOAD /COMPILE /MACRO %"/SAVE/GO" K20MIT.MAC
> >
> > This breaks, you get:
> >
> > ?Not confirmed - ""/SAVE/GO" K20MIT.MAC"
> >
> > There is some way that I used an escape to make this not happen work,
> > but I can't seem to get it to work right now. It always works on
> > PANDA. I don't know if I have access to the Toad Tops-20 EXEC
> > sources, so I can't fix this or speculate as to why this happens, but
> > I thought I'd report it.
> >
> > Am I doing anything obviously wrong?
>
> Uh, check out this line from a .CTL for the -10:
>
> .DEBUG/DDT/COMPILE %"SEG:DEFAULT" T.FOR
>
> And I did have the faint memory that the first slash is always omitted.

If you use it as intended, the first *and only* slash is always
omitted. The intent of % was never to pass arbitrary strings to LINK; the
intent was that you use % to pass *one* switch to LINK, with the /
implied. If you need to pass multiple switches, you use the % multiple
times.

It's supposed to keep track of which % switches are "global" and which go
with particular filespecs, and (at least in theory) puts the switches in
the right place in the LINK command. I know this works with COMPIL on
TOPS-10, but if you do it with %"SAVE" TOPS-20 it seems to write the EXE
over the associated *REL* file name. Not to mention failing to recognize
% as a filename delimiter.

> But try this:
>
> @LOAD /COMPILE /MACRO %"SAVE/GO" K20MIT.MAC

There are additional things wrong with that example:

1) /GO is always implied by any compile-class command that invokes LINK,
so using it explicitly is at best redundant.

2) There is no reason to use % for a /[S]SAVE switch, because that's
supported directly at the top level.

3) The /[S]SSAVE switch can be a bit tricky, because the only way to
specify the filename of the EXE file is by associating the switch with a
file term, but that doesn't override the "normal" meaning of that term.
IIRC, on TOPS-10 the switch is *only* accepted as a filespec switch, while
on TOPS-20 it's accepted either way, but always uses the *program name* of
the the last REL file as the EXE name (similar to what you'd get with a
separate [S]SAVE with no arguments. If you're trying to ovverride the
default name for the REL file, or concatenate multiple sources, things get
trickier. Sometimes I just give up on /[S]SAVE and do the [S]SAVE
manually.

In the above, replace the %"SAVE/GO" with /SAVE. And of course,
specifying *both* /MACRO *and* the explicit .MAC is at least redundant and
probably unnecessary altogether. Not to mention the /COMPILE unless
there's something funny going on with timestamps. So you could just
write:

@LOAD K20MIT/SAVE

On Mon, 9 Jan 2006, Mark Crispin wrote:

> I confirmed that this is a bug in XKL's EXEC.
>
> On an XKL system, the command:
> @COMPILE %"foo/bar" FOO.MAC
> gives an error in the XKL EXEC. If you do the same thing in the Panda
> EXEC on the same XKL system, it compiles FOO.MAC (it doesn't matter that
> the switches are bogus since no linking is done).

But does it work when you use it correctly? :-)

Fred Wright

10-Jan-2006 21:05:40-PST,1848;000000000000
Return-Path: <[email protected]>
Received: from mxout4.cac.washington.edu ([140.142.33.19]) by lingling.panda.com with TCP/SMTP; Tue, 10 Jan 2006 21:00:09 -0800 (PST)
Received: from smtp.washington.edu (smtp.washington.edu [140.142.32.139])
by mxout4.cac.washington.edu (8.13.5+UW05.10/8.13.5+UW05.09) with ESMTP id k0B5008c013330
(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
Tue, 10 Jan 2006 21:00:00 -0800
X-Auth-Received: from pangtzu.panda.com (pangtzu.panda.com [206.124.149.117])
(authenticated authid=mrc)
by smtp.washington.edu (8.13.5+UW05.10/8.13.5+UW05.09) with ESMTP id k0B4xjnq032314
(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT);
Tue, 10 Jan 2006 20:59:59 -0800
Date: Tue, 10 Jan 2006 20:59:43 -0800 (PST)
From: Mark Crispin <[email protected]>
Sender: [email protected]
To: Fred Wright <[email protected]>
cc: [email protected]
Subject: Re: Parsing LINK switches with % does not work on a Toad EXEC
In-Reply-To: <[email protected]>
Message-ID: <[email protected]>
References: <[email protected]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
X-Uwash-Spam: Gauge=IIIIIII, Probability=7%, Report='__CT 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0'

On Tue, 10 Jan 2006, Fred Wright wrote:
> But does it work when you use it correctly? :-)

No, it does not.
load %"noini" foo.mac
also gives the same error. It's definitely an XKL EXEC bug (at least on
the xkleten.paulallen.com system).

-- Mark --

http://panda.com/mrc
Democracy is two wolves and a sheep deciding what to eat for lunch.
Liberty is a well-armed sheep contesting the vote.
11-Jan-2006 07:26:33-PST,3351;000000000000
Return-Path: <[email protected]>
Received: from service0.etnus.com ([68.162.234.181]) by lingling.panda.com with TCP/SMTP; Wed, 11 Jan 2006 07:19:40 -0800 (PST)
Received: from RCN.Com (ralfie.etnus.com [192.168.68.75])
by service0.etnus.com (Postfix) with ESMTP id 08C421F812A;
Wed, 11 Jan 2006 10:19:05 -0500 (EST)
Sender: [email protected]
Message-ID: <[email protected]>
Date: Wed, 11 Jan 2006 10:19:04 -0500
From: "Alan H. Martin" <[email protected]>
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: [email protected]
Subject: Re: Parsing LINK switches with % does not work on a Toad EXEC
References: <[email protected]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Fred Wright wrote:
>
> On Sun, 8 Jan 2006, Alan H. Martin wrote:
..
> > Uh, check out this line from a .CTL for the -10:
> >
> > .DEBUG/DDT/COMPILE %"SEG:DEFAULT" T.FOR
> >
> > And I did have the faint memory that the first slash is always omitted.
..
> If you use it as intended, the first *and only* slash is always
> omitted. The intent of % was never to pass arbitrary strings to LINK; the
> intent was that you use % to pass *one* switch to LINK, with the /
> implied. If you need to pass multiple switches, you use the % multiple
> times.

http://bitsavers.trailing-edge.com/pdf/dec/pdp10/TOPS10_softwareNotebooks/vol13/AA-0988D-TB_link.pdf

"
TOPS-10
LINK Reference Manual

AA-0988D-TB, AD-0988D-T1, AD-0988D-T2

April 1986
..
OPERATING SYSTEM: TOPS-10 V7.03
SOFTWARE: LINK-10 V6.0

..
Updated, April 1986
..

CHAPTER 2
USING LINK AUTOMATICALLY

..

2.2 COMMAND SWITCHES

..

You can use any LINK program switches with the system commands LOAD,
EXECUTE, or DEBUG by using a special switch format. This format
requires that you use a percent sign (%) instead of the usual slash (/),
and that the entire switch specification be enclosed in double quotation
marks ("). ...

If you give more than one switch in this format, succeeding switches
within the quotation marks must have the usual slashes:

.EXECUTE MYPROG%"ERRORLEVEL:0/SEGMENT:LOW"

LINK program switches are described in Section 3.2.
"

As far as its applicability to the -20 goes:

http://pdp-10.trailing-edge.com/bb-lw55a-bm/01/7-documentation/link.doc.html

"
TOPS-20

LINK Reference Manual

AA-4183D-TM
..
OPERATING SYSTEM AND VERSION: TOPS-20, Version 4.1, 5.1

SOFTWARE VERSION: LINK-20, Version 6.0
..
Revised, May 1985
..
CHAPTER 2

USING LINK AUTOMATICALLY
..

2.2 COMMAND SWITCHES
..

You can use any LINK program switches with LOAD, EXECUTE, or DEBUG by
using a special switch format. This format requires that you use a
percent sign (%) instead of the usual slash (/), and that the entire
switch specification be enclosed in double quotation marks ("). ...

If you give more than one switch in this format, succeeding switches
within the quotation marks must have the usual slashes:

@EXECUTE MYPROG %"SYMSEG:HIGH/COUNTERS"<RET>

LINK program switches are described in Chapter 3.
"
/AHM
--
Alan Howard Martin [email protected]
11-Jan-2006 11:44:25-PST,1481;000000000000
Return-Path: <[email protected]>
Received: from b.mail.sonic.net ([64.142.19.5]) by lingling.panda.com with TCP/SMTP; Wed, 11 Jan 2006 11:38:52 -0800 (PST)
Received: from Amiga.local (64-142-29-114.dsl.static.sonic.net [64.142.29.114])
by b.mail.sonic.net (8.13.3/8.13.3) with ESMTP id k0BJcj6H027336
for <[email protected]>; Wed, 11 Jan 2006 11:38:45 -0800
Date: Wed, 11 Jan 2006 11:38:45 -0800 (PST)
From: Fred Wright <[email protected]>
X-Sender: [email protected]
Reply-To: Fred Wright <[email protected]>
To: [email protected]
Subject: Re: Parsing LINK switches with % does not work on a Toad EXEC
In-Reply-To: <[email protected]>
Message-ID: <[email protected]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

On Wed, 11 Jan 2006, Alan H. Martin wrote:

> 2.2 COMMAND SWITCHES
>
> ...
>
> You can use any LINK program switches with the system commands LOAD,
> EXECUTE, or DEBUG by using a special switch format. This format
> requires that you use a percent sign (%) instead of the usual slash (/),
> and that the entire switch specification be enclosed in double quotation
> marks ("). ...
>
> If you give more than one switch in this format, succeeding switches
> within the quotation marks must have the usual slashes:
>
> .EXECUTE MYPROG%"ERRORLEVEL:0/SEGMENT:LOW"

OK, I stand corrected. But I've always had better luck not trying to do
that.

Fred Wright

11-Jan-2006 14:04:30-PST,539;000000000000
Return-Path: <[email protected]>
Received: from tops.drkngs.com ([206.82.248.65]) by lingling.panda.com with TCP/SMTP; Wed, 11 Jan 2006 13:58:14 -0800 (PST)
Date: Wed, 11 Jan 2006 13:38:33 -0800 (PST)
From: Jon Solomon <[email protected]>
Subject: more LINK
To: [email protected]
Message-ID: <[email protected]>

I tried a simple load command on tops.drkngs.com, toad.xkl.com and
xkleten.paulallen.com. Both tops and toad work fine!!! (toad is an XKL system).
xkleten fails...

--jsol
-------
11-Jan-2006 14:10:14-PST,654;000000000000
Return-Path: <[email protected]>
Received: from tops.drkngs.com ([206.82.248.65]) by lingling.panda.com with TCP/SMTP; Wed, 11 Jan 2006 14:03:48 -0800 (PST)
Date: Wed, 11 Jan 2006 13:44:05 -0800 (PST)
From: Jon Solomon <[email protected]>
Subject: foo/save(was more LINK)
To: [email protected]
Message-ID: <[email protected]>

If you do

@load %"foo/save/go" foo.mac, it says "unknown switch FOO".

so you can't save it to another file....

I know, you can do @save another-file..

so it is not that much of a problem.

--jsol

p.s. this message comes from tops.drkngs.com, and toad.xkl.com

-------
12-Jan-2006 11:03:17-PST,4195;000000000000
Return-Path: <[email protected]>
Received: from mail.math.utah.edu ([155.101.98.135]) by lingling.panda.com with TCP/SMTP; Thu, 12 Jan 2006 10:56:51 -0800 (PST)
Received: from psi.math.utah.edu (psi.math.utah.edu [155.101.96.19])
by mail.math.utah.edu (8.13.4/8.13.4) with ESMTP id k0CIugFC026937;
Thu, 12 Jan 2006 11:56:43 -0700 (MST)
Received: from psi.math.utah.edu (localhost [127.0.0.1])
by psi.math.utah.edu (8.13.4/8.13.4) with ESMTP id k0CIug6R002161;
Thu, 12 Jan 2006 11:56:42 -0700 (MST)
Received: (from beebe@localhost)
by psi.math.utah.edu (8.13.4/8.13.4/Submit) id k0CIuggQ002159;
Thu, 12 Jan 2006 11:56:42 -0700 (MST)
Date: Thu, 12 Jan 2006 11:56:42 -0700 (MST)
From: "Nelson H. F. Beebe" <[email protected]>
To: [email protected]
Cc: [email protected]
X-US-Mail: "Department of Mathematics, 110 LCB, University of Utah, 155 S
1400 E RM 233, Salt Lake City, UT 84112-0090, USA"
X-Telephone: +1 801 581 5254
X-FAX: +1 801 585 1640, +1 801 581 4148
X-URL: http://www.math.utah.edu/~beebe
Subject: Brief comments on book ``Hacker's Delight''
Message-ID: <[email protected]>
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0 (mail.math.utah.edu [155.101.98.135]); Thu, 12 Jan 2006 11:56:43 -0700 (MST)

A list reader asked me to post comments on the book

Henry S. Warren
Hacker's delight
Addison-Wesley (2003)
ISBN 0-201-91465-4

for which I posted a longer announcement to this list on Sun, 18 Dec
2005 11:21:52 -0700 (MST).

I finished reading the book a few days ago, and substantially
augmented the BibTeX entry to include notes, keywords, remarks, and a
table of contents. You can find it at

http://www.math.utah.edu/pub/tex/bib/fparith.html#Warren:2003:HD

The book has a mind-boggling number of clever tricks to compute things
in a few loop-free and comparison-free instructions where a loop would
appear to be needed, such as for population counting (number of
one-bits in a register). Although the techniques were largely
discovered and developed on the PDP-10, and documented in various
HAKMEM reports from MIT, the author has adapted and revised them for
use on 32-bit two's complement machines, with some consideration of
64-bit ones as well.

There are important lessons here for machine designers, because some
task are made notably easier when the right set of instruction
primitives is available, and much harder when they are not. The
population count and number-of-leading-zeros operations that are
discussed early on in the book turn up many times later, and yet
relatively few instruction sets include them (e.g., IBM PowerPC has
two variants of CNTLZ (count leading zeros), and Sun SPARC has POPC
(population count)).

The book has important techniques for compiler optimization, such as
multiplication and division by small constants without using multiply
or divide instructions.

It also discusses the primitives needed to implement multiword integer
arithmetic efficiently. That in turn is an important component of
software implementations of multiple-precision floating-point
arithmetic. However, there is only one very short (six-page) chapter
devoted to floating-point arithmetic, mostly a description of the IEEE
754 formats, and a discussion of the distribution of leading digits.

If you enjoy reading about computer architecture, then you'll almost
certainly like this book.

The author did a superb job of typesetting; I recorded no
typographical errors at all (and I usually find and note many in books
that I read).

-------------------------------------------------------------------------------
- Nelson H. F. Beebe Tel: +1 801 581 5254 -
- University of Utah FAX: +1 801 581 4148 -
- Department of Mathematics, 110 LCB Internet e-mail: [email protected] -
- 155 S 1400 E RM 233 [email protected] [email protected] -
- Salt Lake City, UT 84112-0090, USA URL: http://www.math.utah.edu/~beebe/ -
-------------------------------------------------------------------------------
12-Jan-2006 17:05:30-PST,1495;000000000000
Return-Path: <[email protected]>
Received: from sj-iport-4.cisco.com ([171.68.10.86]) by lingling.panda.com with TCP/SMTP; Thu, 12 Jan 2006 16:59:39 -0800 (PST)
Received: from sj-core-4.cisco.com ([171.68.223.138])
by sj-iport-4.cisco.com with ESMTP; 12 Jan 2006 16:59:33 -0800
X-IronPort-AV: i="3.99,361,1131350400";
d="scan'208"; a="1766272205:sNHT30150300"
Received: from cisco.com (cypher.cisco.com [171.69.11.142])
by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id k0D0xWQJ024648
for <[email protected]>; Thu, 12 Jan 2006 16:59:33 -0800 (PST)
Received: (from billw@localhost)
by cisco.com (8.8.8-Cisco List Logging/8.8.8) id QAA26680
for [email protected]; Thu, 12 Jan 2006 16:59:32 -0800 (PST)
Sender: Bill Westfield <[email protected]>
Date: Thu, 12 Jan 2006 16:59:32 PST
From: William "Chops" Westfield <[email protected]>
To: [email protected]
Subject: unix-haters...
Message-ID: <CMM.0.90.4.1137113972.billw@cypher>

round about the time tops was dying, the "unix-haters" mailing list
was created for all the mainframe ex-patriots (and also lisp machine
afficianados) to whine about all the reasons that unix sucked...
Nowadays, of course, unix is the "good guy" (it's even used by the
microcode engines of todays tops systems :-), and I get questions like
"why did unix suck?" Does anyone happen to have pointers to or copies
of any historical documents that summarize the viewpoints of those
days (circa 1988?)

BillW
12-Jan-2006 17:58:04-PST,1467;000000000000
Return-Path: <[email protected]>
Received: from sj-iport-3.cisco.com ([171.71.176.72]) by lingling.panda.com with TCP/SMTP; Thu, 12 Jan 2006 17:52:27 -0800 (PST)
Received: from sj-core-5.cisco.com ([171.71.177.238])
by sj-iport-3.cisco.com with ESMTP; 12 Jan 2006 17:52:21 -0800
X-IronPort-AV: i="3.99,361,1131350400";
d="scan'208"; a="391220031:sNHT27085432"
Received: from cisco.com (cypher.cisco.com [171.69.11.142])
by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id k0D1qKjt028819
for <[email protected]>; Thu, 12 Jan 2006 17:52:20 -0800 (PST)
Received: (from billw@localhost)
by cisco.com (8.8.8-Cisco List Logging/8.8.8) id RAA12973
for [email protected]; Thu, 12 Jan 2006 17:52:20 -0800 (PST)
Sender: Bill Westfield <[email protected]>
Date: Thu, 12 Jan 2006 17:52:20 PST
From: William "Chops" Westfield <[email protected]>
Cc: [email protected]
Subject: Re: unix-haters...
In-Reply-To: Your message of Thu, 12 Jan 2006 16:59:32 PST Re: Comparing new
MacBook to Acer Laptop
In-Reply-To: Your message of Thu, 12 Jan 2006 12:59:29 -0500
Message-ID: <CMM.0.90.4.1137117140.billw@cypher>

Does anyone happen to have pointers to or copies of any historical
documents that summarize the viewpoints of those days (circa 1988?)

Never mind. Someone point out this, which looks about as good
as it's likely to get...

http://research.microsoft.com/~daniel/unix-haters.html

BillW
12-Jan-2006 18:35:35-PST,2520;000000000000
Return-Path: <[email protected]>
Received: from igw2.watson.ibm.com ([129.34.20.6]) by lingling.panda.com with TCP/SMTP; Thu, 12 Jan 2006 18:30:17 -0800 (PST)
Received: from sp1n294en1.watson.ibm.com (sp1n294en1.watson.ibm.com [129.34.20.40])
by igw2.watson.ibm.com (8.12.11/8.13.1/8.13.1-2005-04-25 igw) with ESMTP id k0D2WNZ4016123;
Thu, 12 Jan 2006 21:32:23 -0500
Received: from sp1n294en1.watson.ibm.com (localhost [127.0.0.1])
by sp1n294en1.watson.ibm.com (8.11.7-20030924/8.11.7/01-14-2004_2) with ESMTP id k0D2U9c284342;
Thu, 12 Jan 2006 21:30:09 -0500
Received: from OSTINATO (sig-9-65-107-218.mts.ibm.com [9.65.107.218])
by sp1n294en1.watson.ibm.com (8.11.7-20030924/8.11.7/01-14-2004_1) with SMTP id k0D2U7s323256;
Thu, 12 Jan 2006 21:30:07 -0500
Message-ID: <[email protected]>
From: "David F. Bacon" <[email protected]>
To: "William Chops Westfield" <[email protected]>, <[email protected]>
References: <CMM.0.90.4.1137113972.billw@cypher>
Subject: Re: unix-haters...
Date: Thu, 12 Jan 2006 21:29:59 -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.2800.1506
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506

well, no documents, but i can tell you why unix sucked when i switched from
tops. i remember it like it was yesterday:

- it didn't have command completion (a lame form was finally implemented ca.
1988)
- it didn't have shared libraries (which was finally fixed in the late 80's
as well i think)
- you couldn't detach and attach
- the help was a joke
- the only emacs was some half baked piece of shit written by some loser
named gosling

david
----- Original Message -----
From: "William Chops Westfield" <[email protected]>
To: <[email protected]>
Sent: Thursday, January 12, 2006 7:59 PM
Subject: unix-haters...

> round about the time tops was dying, the "unix-haters" mailing list
> was created for all the mainframe ex-patriots (and also lisp machine
> afficianados) to whine about all the reasons that unix sucked...
> Nowadays, of course, unix is the "good guy" (it's even used by the
> microcode engines of todays tops systems :-), and I get questions like
> "why did unix suck?" Does anyone happen to have pointers to or copies
> of any historical documents that summarize the viewpoints of those
> days (circa 1988?)
>
> BillW
>

12-Jan-2006 23:49:34-PST,1395;000000000000
Mail-From: MRC created at 12-Jan-2006 23:43:44
Date: Thu, 12 Jan 2006 23:43:44 -0800 (PST)
From: Mark Crispin <[email protected]>
Subject: Re: unix-haters...
To: [email protected]
cc: [email protected]
In-Reply-To: <CMM.0.90.4.1137113972.billw@cypher>
Pithy-Thought: TOPS-20 was a great improvement over its successors
Message-ID: <[email protected]>

> Nowadays, of course, unix is the "good guy" (it's even used by the
> microcode engines of todays tops systems :-), and I get questions like
> "why did unix suck?"

Of course, the correct question is "why *does* UNIX suck?"... :-)

It's been 18 years of daily use, and I still hate UNIX. I hate
UNIX worse than I hate Windows. The only good thing that I can
say about UNIX is that it is not VMS.

Some UNIX sucks less than others. BSD sucks less than Linux
which sucks less than SVR4 (Solaris/HP-UX/AIX/etc.). OSF/1
(a.k.a. Tru64) used to suck less than Linux, now it sucks worse
than SVR4. [Horror stories on request]

For what it's worth, my laptop and office desktop are Windows, my
home desktop is Mac OS X, and my servers are Linux (I'm gleefully
watching the extinction of our last few AIX servers).

By the way, Pine works quite well with the TOPS-20 IMAP server,
even though TOPS-20 never went beyond IMAP2. I'm thinking of
porting UW imapd to TOPS-20...
-------
13-Jan-2006 02:17:21-PST,817;000000000000
Return-Path: <[email protected]>
Received: from toad.xkl.com ([192.94.202.40]) by lingling.panda.com with TCP/SMTP; Fri, 13 Jan 2006 02:10:13 -0800 (PST)
Date: Thu, 12 Jan 2006 17:13:04 -0800 (PST)
From: Jon Solomon <[email protected]>
Subject: MM
To: [email protected]
Message-ID: <[email protected]>
ReSent-Date: Fri, 13 Jan 2006 01:58:24 -0800 (PST)
ReSent-From: Jon Solomon <[email protected]>
ReSent-To: [email protected]
ReSent-Message-ID: <[email protected]>

I noticed this while debugging a problem receiving mail here.
I have an MM.CMD which says "reply-to [email protected]". When I do
@mm send, it fails to check mm.cmd, so the reply-to address never
gets put in the mail. I can get around it by doing @mm<cr>send.

--jsol
-------

-------
13-Jan-2006 06:23:36-PST,2780;000000000000
Return-Path: <[email protected]>
Received: from mail.math.utah.edu ([155.101.98.135]) by lingling.panda.com with TCP/SMTP; Fri, 13 Jan 2006 06:18:02 -0800 (PST)
Received: from psi.math.utah.edu (psi.math.utah.edu [155.101.96.19])
by mail.math.utah.edu (8.13.4/8.13.4) with ESMTP id k0DEHtfa017936;
Fri, 13 Jan 2006 07:17:55 -0700 (MST)
Received: from psi.math.utah.edu (localhost [127.0.0.1])
by psi.math.utah.edu (8.13.4/8.13.4) with ESMTP id k0DEHsYb010620;
Fri, 13 Jan 2006 07:17:54 -0700 (MST)
Received: (from beebe@localhost)
by psi.math.utah.edu (8.13.4/8.13.4/Submit) id k0DEHsKZ010619;
Fri, 13 Jan 2006 07:17:54 -0700 (MST)
Date: Fri, 13 Jan 2006 07:17:54 -0700 (MST)
From: "Nelson H. F. Beebe" <[email protected]>
To: [email protected]
Cc: [email protected]
X-US-Mail: "Department of Mathematics, 110 LCB, University of Utah, 155 S
1400 E RM 233, Salt Lake City, UT 84112-0090, USA"
X-Telephone: +1 801 581 5254
X-FAX: +1 801 585 1640, +1 801 581 4148
X-URL: http://www.math.utah.edu/~beebe
Subject: Re: unix-haters...
Message-ID: <[email protected]>
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0 (mail.math.utah.edu [155.101.98.135]); Fri, 13 Jan 2006 07:17:55 -0700 (MST)

William "Chops" Westfield <[email protected]> asks on Thu, 12 Jan 2006
16:59:32 PST about reminiscences of Unix seen from the TOPS-20 point
of view.

Almost 19 years ago, I wrote a document to help our users transition
from TOPS-20 to Unix, and when I reread it a few months ago, I found
that it was balanced enough that it could serve for Unix to TOPS-20 as
well. I've just put it on the Web at

http://www.math.utah.edu/~beebe/publications/1987/t20unix.pdf

It wasn't written with a "unix sux" attitude, but rather, just to
show our users how to do the same task in both systems.

About the time our DEC-20/60 retired (31-Oct-1990), we (members of a
some mailing list) were discussing putting together a long document
about what TOPS-20 did right, with a view to some future design that
combined the best features of TOPS-20 and Unix. Unfortunately, I
don't believe that anything ever got published.

-------------------------------------------------------------------------------
- Nelson H. F. Beebe Tel: +1 801 581 5254 -
- University of Utah FAX: +1 801 581 4148 -
- Department of Mathematics, 110 LCB Internet e-mail: [email protected] -
- 155 S 1400 E RM 233 [email protected] [email protected] -
- Salt Lake City, UT 84112-0090, USA URL: http://www.math.utah.edu/~beebe/ -
-------------------------------------------------------------------------------
13-Jan-2006 06:43:51-PST,3736;000000000000
Return-Path: <[email protected]>
Received: from mail.math.utah.edu ([155.101.98.135]) by lingling.panda.com with TCP/SMTP; Fri, 13 Jan 2006 06:38:53 -0800 (PST)
Received: from psi.math.utah.edu (psi.math.utah.edu [155.101.96.19])
by mail.math.utah.edu (8.13.4/8.13.4) with ESMTP id k0DEckYl023299;
Fri, 13 Jan 2006 07:38:46 -0700 (MST)
Received: from psi.math.utah.edu (localhost [127.0.0.1])
by psi.math.utah.edu (8.13.4/8.13.4) with ESMTP id k0DEckAR010695;
Fri, 13 Jan 2006 07:38:46 -0700 (MST)
Received: (from beebe@localhost)
by psi.math.utah.edu (8.13.4/8.13.4/Submit) id k0DEck4d010694;
Fri, 13 Jan 2006 07:38:46 -0700 (MST)
Date: Fri, 13 Jan 2006 07:38:46 -0700 (MST)
From: "Nelson H. F. Beebe" <[email protected]>
To: [email protected]
Cc: [email protected]
X-US-Mail: "Department of Mathematics, 110 LCB, University of Utah, 155 S
1400 E RM 233, Salt Lake City, UT 84112-0090, USA"
X-Telephone: +1 801 581 5254
X-FAX: +1 801 585 1640, +1 801 581 4148
X-URL: http://www.math.utah.edu/~beebe
Subject: Niklaus Wirth looks back on lifetime of computing
Message-ID: <[email protected]>
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0 (mail.math.utah.edu [155.101.98.135]); Fri, 13 Jan 2006 07:38:47 -0700 (MST)

Vaguely related to the discussions about Unix vs TOPS-20 is a new
article by Niklaus Wirth that arrived in my mailbox yesterday.
He looks back on lifetime of computing, and discusses a collection of
once-good, but now seen to be bad, ideas in computing, both in
hardware and in software. One of his many deprecations is indirect
pointers, which the PDP-10 certainly made use of.

Here is a reference for the paper:

@String{j-COMPUTER = "Computer"}

@Article{Wirth:2006:GIT,
author = "Niklaus Wirth",
title = "Good Ideas, through the Looking Glass",
journal = j-COMPUTER,
volume = "39",
number = "1",
pages = "28--39",
month = jan,
year = "2006",
CODEN = "CPTRB4",
DOI = "http://dx.doi.org/10.1109/MC.2006.20",
ISSN = "0018-9162",
bibdate = "Fri Jan 13 07:25:30 2006",
URL = "http://csdl.computer.org/comp/mags/co/2006/01/r1toc.xml;
http://csdl2.computer.org/dl/mags/co/2006/01/r1028.pdf",
abstract = "Computing's history has been driven by many good and
original ideas, but a few turned out to be less
brilliant than they first appeared to be.",
acknowledgement = ack-nhfb,
keywords = "hardware technology; computer architectures;
programming languages; programming paradigms",
}

There is no link to the PDF file yet via links from the DOI (Digital
Object Identifier), but the link in the URL field will take you to it.
An IEEE member account is needed to retrieve it, and I have it up in a
browser right now. I think that most, if not all, IEEE members get
Computer, so if you aren't a member yourself, you probably have a
friend or colleague nearby who is, and has a copy of the new issue.

-------------------------------------------------------------------------------
- Nelson H. F. Beebe Tel: +1 801 581 5254 -
- University of Utah FAX: +1 801 581 4148 -
- Department of Mathematics, 110 LCB Internet e-mail: [email protected] -
- 155 S 1400 E RM 233 [email protected] [email protected] -
- Salt Lake City, UT 84112-0090, USA URL: http://www.math.utah.edu/~beebe/ -
-------------------------------------------------------------------------------
13-Jan-2006 07:21:39-PST,4924;000000000000
Return-Path: <[email protected]>
Received: from mail.math.utah.edu ([155.101.98.135]) by lingling.panda.com with TCP/SMTP; Fri, 13 Jan 2006 07:15:51 -0800 (PST)
Received: from psi.math.utah.edu (psi.math.utah.edu [155.101.96.19])
by mail.math.utah.edu (8.13.4/8.13.4) with ESMTP id k0DFFhfi026475;
Fri, 13 Jan 2006 08:15:43 -0700 (MST)
Received: from psi.math.utah.edu (localhost [127.0.0.1])
by psi.math.utah.edu (8.13.4/8.13.4) with ESMTP id k0DFFh7G010847;
Fri, 13 Jan 2006 08:15:43 -0700 (MST)
Received: (from beebe@localhost)
by psi.math.utah.edu (8.13.4/8.13.4/Submit) id k0DFFh1T010845;
Fri, 13 Jan 2006 08:15:43 -0700 (MST)
Date: Fri, 13 Jan 2006 08:15:43 -0700 (MST)
From: "Nelson H. F. Beebe" <[email protected]>
To: [email protected]
Cc: [email protected]
X-US-Mail: "Department of Mathematics, 110 LCB, University of Utah, 155 S
1400 E RM 233, Salt Lake City, UT 84112-0090, USA"
X-Telephone: +1 801 581 5254
X-FAX: +1 801 585 1640, +1 801 581 4148
X-URL: http://www.math.utah.edu/~beebe
Subject: Re: unix-haters... shared libraries, emacs, and NFS
Message-ID: <[email protected]>
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0 (mail.math.utah.edu [155.101.98.135]); Fri, 13 Jan 2006 08:15:43 -0700 (MST)

"David F. Bacon" <[email protected]> writes on Thu, 12 Jan 2006
21:29:59 -0500 about Unix deficiencies:

>> it didn't have shared libraries (which was finally fixed in the
>> late 80's as well i think)

GNU/Linux systems in particular continue to botch shared libraries:
each new release drops some from the distribution, completely
forgetting that they are an inviolable contract with millions of
executables in userland that are linked against them. We have been
bitten on almost every upgrade we have done.

This even happens between major O/S releases: a new package version
appears, and when installed, wipes out a shared library with a new one
of the same name, but different contents. There is no excuse for
this, because Unix shared libraries have version numbers [recall the
Microsoft Windows DLL hell, because dynamic link libraries lack
version numbers entirely].

On TOPS-20 today, I can still run executables linked with shared
libraries in the 1970s, because PDP-10 shared-library architects made
provisions in the design for backward-compatible additions to shared
libraries.

David goes on to note:

>> the only emacs was some half baked piece ...

While it is true that James Gosling (later known for the
PostScript-based Network extensible Window System (NeWS) on SunOS, and
then for Java) wrote the first Emacs-in-C, which I think eventually
became the commercial CCA Emacs, Richard Stallman was doing a similar
project about 1985--1986 as part of his early work on the GNU system.

I went through the change logs of my extensive Emacs Lisp code this
morning, and found this entry:

;; SYS$OPRROOT:[BEEBEN]DATE_EDIT.EL Tue Sep 2 12:42:38 1986
;; [1.00] Added date-edit, my very first Emacs-Lisp function!

date-edit is the function that makes change-log entry headers, like
that one.

Notice that this was actually created on VAX VMS. We ran CCA Emacs,
and later, GNU Emacs, on that system, and Wollongong BSD 3.x and 4.x
on a VAX 750, before getting a dozen Sun workstations in 1987.

I rewrote my TECO libraries for TOPS-20 Emacs in Emacs Lisp on VMS,
and the earliest change-log date on a Unix system that I could find
was Tue Feb 2 17:33:31 1988. Most of my work continued on TOPS-20
until its retirement on Halloween, 1990, when I switched from a
terminal to a Sun on my desktop.

What made our mixed TOPS-20 / VMS / Unix environment practical was
Mark Lottor's NFS-for-TOPS-20 implementation. I remember a visit to
SRI in the 1980s where Mark showed me a transparency with the entire
PDP-10 assembly-code listing for NFS-20: he used PostScript to reduce
about 20 or 30 pages of assembly code listing to a single sheet, and
displayed it in a talk at Sun Microsystems.

Lon Willett worked hard here on implementing NFS for VMS, code that we
hoped to distribute to others. However, we didn't have the resources
to push it to completion, and ultimately, abandoned the project and
bought the commercial TGV (Two Guys and a VAX) NFS for VMS.

-------------------------------------------------------------------------------
- Nelson H. F. Beebe Tel: +1 801 581 5254 -
- University of Utah FAX: +1 801 581 4148 -
- Department of Mathematics, 110 LCB Internet e-mail: [email protected] -
- 155 S 1400 E RM 233 [email protected] [email protected] -
- Salt Lake City, UT 84112-0090, USA URL: http://www.math.utah.edu/~beebe/ -
-------------------------------------------------------------------------------
13-Jan-2006 10:38:23-PST,2513;000000000000
Return-Path: <[email protected]>
Received: from mxout3.cac.washington.edu ([140.142.32.166]) by lingling.panda.com with TCP/SMTP; Fri, 13 Jan 2006 10:32:27 -0800 (PST)
Received: from smtp.washington.edu (smtp.washington.edu [140.142.33.9])
by mxout3.cac.washington.edu (8.13.5+UW05.10/8.13.5+UW05.09) with ESMTP id k0DIWG0O001178
(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
Fri, 13 Jan 2006 10:32:17 -0800
X-Auth-Received: from pangtzu.panda.com (pangtzu.panda.com [206.124.149.117])
(authenticated authid=mrc)
by smtp.washington.edu (8.13.5+UW05.10/8.13.5+UW05.09) with ESMTP id k0DIWBtC003605
(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT);
Fri, 13 Jan 2006 10:32:15 -0800
Date: Fri, 13 Jan 2006 10:32:10 -0800 (PST)
From: Mark Crispin <[email protected]>
Sender: [email protected]
To: Jon Solomon <[email protected]>
cc: [email protected]
Subject: Re: MM
In-Reply-To: <[email protected]>
Message-ID: <[email protected]>
References: <[email protected]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
X-Uwash-Spam: Gauge=IIIIIII, Probability=7%, Report='__CT 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0'

On Thu, 12 Jan 2006, Jon Solomon wrote:
> I noticed this while debugging a problem receiving mail here.
> I have an MM.CMD which says "reply-to [email protected]". When I do
> @mm send, it fails to check mm.cmd, so the reply-to address never
> gets put in the mail. I can get around it by doing @mm<cr>send.

This has always been the case. MM.CMD is a set of commands that are run
when you do a normal MM startup, not when you send mail from the command
line. You absolutely do not want mail file filter actions in a MM.CMD to
take place when you are sending from the command line!

The real problem in MM is that the FROM and REPLY-TO commands should never
have been commands; they should have been SET options and thus subject to
MM.INIT. The reason why they are commands is that they do various stuff
to their arguments instead of just setting a string.

Fortunately, there is a workaround. If you want a default Reply-To for
all cases, you can use HEADER-OPTIONS to accomplish that.

-- Mark --

http://panda.com/mrc
Democracy is two wolves and a sheep deciding what to eat for lunch.
Liberty is a well-armed sheep contesting the vote.
15-Jan-2006 18:57:41-PST,4059;000000000000
Return-Path: <[email protected]>
Received: from mta5.srv.hcvlny.cv.net ([167.206.4.200]) by lingling.panda.com with TCP/SMTP; Sun, 15 Jan 2006 18:52:11 -0800 (PST)
Received: from optonline.net (hamstr19.srv.hcvlny.cv.net [167.206.5.70])
by mta5.srv.hcvlny.cv.net
(Sun Java System Messaging Server 6.2-4.03 (built Sep 22 2005))
with ESMTP id <[email protected]> for
[email protected]; Sun, 15 Jan 2006 21:51:59 -0500 (EST)
Received: from [10.240.3.30] (Forwarded-For: [69.114.1.48])
by mstr13.srv.hcvlny.cv.net (mshttpd); Sun, 15 Jan 2006 21:51:59 -0500
Date: Sun, 15 Jan 2006 21:51:59 -0500
From: [email protected]
Subject: Re: Parsing LINK switches with % does not work on a Toad EXEC
In-reply-to: <[email protected]>
To: Fred Wright <[email protected]>
Cc: [email protected]
Message-id: <[email protected]>
MIME-version: 1.0
X-Mailer: Sun Java(tm) System Messenger Express 6.2-4.03 (built Sep 22 2005)
Content-type: text/plain; charset=us-ascii
Content-language: en
Content-transfer-encoding: 7BIT
Content-disposition: inline
X-Accept-Language: en
Priority: normal
References: <[email protected]>
<[email protected]>

> It's supposed to keep track of which % switches are "global" and
> which go with particular filespecs, and (at least in theory) puts
> the switches in the right place in the LINK command. I know this
> works with COMPIL on TOPS-10, but if you do it with %"SAVE" TOPS-20
> it seems to write the EXE over the associated *REL* file name. Not
> to mention failing to recognize % as a filename delimiter.

I don't see the .EXE file overwritting any .REL file; am I
misinterpreting what you meant? If this happened, then the compile
command would always assemble the macro file because there would be no
REL file instead of having me force it with /COMPILE.

> There are additional things wrong with that example:
>
> 1) /GO is always implied by any compile-class command that invokes
> LINK,so using it explicitly is at best redundant.
>
> 2) There is no reason to use % for a /[S]SAVE switch, because that's
> supported directly at the top level.
>
> 3) The /[S]SSAVE switch can be a bit tricky, because the only way to
> specify the filename of the EXE file is by associating the switch
> with a file term, but that doesn't override the "normal" meaning of
> that term. IIRC, on TOPS-10 the switch is *only* accepted as a
> filespec switch, while on TOPS-20 it's accepted either way, but
> always uses the *program name* of the the last REL file as the EXE
> name (similar to what you'd get with a separate [S]SAVE with no
> arguments. If you're trying to ovverride the default name for the
> REL file, or concatenate multiple sources, things get trickier.
> Sometimes I just give up on /[S]SAVE and do the [S]SAVE manually.
>
> In the above, replace the %"SAVE/GO" with /SAVE. And of course,
> specifying *both* /MACRO *and* the explicit .MAC is at least
> redundant and probably unnecessary altogether. Not to mention the
> /COMPILE unless there's something funny going on with timestamps.
> So you could just write:
>
> @LOAD K20MIT/SAVE

That example does not work under Tops-20 (see below). I used /COMPILE
because I wanted to force a compile after a FTP'ed an earlier copy of
KERMIT. /MACRO is old habit, dunno why.

I used %"/SAVE/GO" because neither /SAVE nor /SSAVE work on any
Tops-20 EXEC that I have. They do, however, work under Tops-10; I
just checked this on DEC-10.PDPplanet.com. I probably used /SAVE
/SSAVE when I was at WPI and LIRICS and then stopped when I was at
Marlboro. I think we may have implemented /SAVE at Columbia, but I
can't remember. By then, %"/SAVE/GO" was old habit. /GO is old
habit, dunno why.

For now, I just stuck a .TEXT "KERMIT/SAVE" directive in the source
MACRO file. Dunno why I didn't think of that before ...

16-Jan-2006 14:48:53-PST,2356;000000000000
Return-Path: <[email protected]>
Received: from b.mail.sonic.net ([64.142.19.5]) by lingling.panda.com with TCP/SMTP; Mon, 16 Jan 2006 14:43:34 -0800 (PST)
Received: from Amiga.local (64-142-29-114.dsl.static.sonic.net [64.142.29.114])
by b.mail.sonic.net (8.13.3/8.13.3) with ESMTP id k0GMhRgM008816
for <[email protected]>; Mon, 16 Jan 2006 14:43:27 -0800
Date: Mon, 16 Jan 2006 14:43:27 -0800 (PST)
From: Fred Wright <[email protected]>
X-Sender: [email protected]
Reply-To: Fred Wright <[email protected]>
To: [email protected]
Subject: Re: Parsing LINK switches with % does not work on a Toad EXEC
In-Reply-To: <[email protected]>
Message-ID: <[email protected]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

On Sun, 15 Jan 2006 [email protected] wrote:

> > It's supposed to keep track of which % switches are "global" and
> > which go with particular filespecs, and (at least in theory) puts
> > the switches in the right place in the LINK command. I know this
> > works with COMPIL on TOPS-10, but if you do it with %"SAVE" TOPS-20
> > it seems to write the EXE over the associated *REL* file name. Not
> > to mention failing to recognize % as a filename delimiter.
>
> I don't see the .EXE file overwritting any .REL file; am I
> misinterpreting what you meant? If this happened, then the compile
> command would always assemble the macro file because there would be no
> .REL file instead of having me force it with /COMPILE.

I was trying to test a case where I was linking two assemblies and trying
to force the SAVE file name to be the first one. I believe I did
something along the lines of:

@LOAD FOO %"SAVE",BAR

I then found a FOO.REL which was really a .EXE file.

> > @LOAD K20MIT/SAVE
>
> That example does not work under Tops-20 (see below). I used /COMPILE
> because I wanted to force a compile after a FTP'ed an earlier copy of
> KERMIT. /MACRO is old habit, dunno why.
>
> I used %"/SAVE/GO" because neither /SAVE nor /SSAVE work on any
> Tops-20 EXEC that I have. They do, however, work under Tops-10; I

Sorry - it looks like I put /SAVE and /SSAVE into the EXEC myself, but so
long ago I forgot they were my own doing. That was in the last millenium,
after all. :-)

Fred Wright

20-Jan-2006 15:46:22-PST,1062;000000000000
Return-Path: <[email protected]>
Received: from toad.xkl.com ([192.94.202.40]) by lingling.panda.com with TCP/SMTP; Fri, 20 Jan 2006 15:38:54 -0800 (PST)
Date: Fri, 20 Jan 2006 15:31:30 -0800 (PST)
From: Jon Solomon <[email protected]>
Subject: SSH/SSHD
To: [email protected]
Reply-to: [email protected]
Message-ID: <[email protected]>

I was thinking about this myself (although I don't know how to do the
coding ...) and I findthat under UNIX, SSHD uses two proceses,
one from root, one from the user process. I think the root part
can be put under SYSJOB, and you can probably get away with one
process for all users who need to access TELNET or FTP.
I would propose putting a process peered with the EXEC and FTPSRT
... You can then use the existing TELNET using port 22. Youwould
then have to modify FTP to do the SCP (or replace it with SCP).

You would then be asked if you want to save the codes which
are used to do SSH/SCP in a file (probably in your login directory).

I hope this helps.

--jsol
-------
21-Jan-2006 18:31:28-PST,9083;000000000000
Return-Path: <[email protected]>
Received: from mta6.srv.hcvlny.cv.net ([167.206.4.201]) by lingling.panda.com with TCP/SMTP; Sat, 21 Jan 2006 18:24:35 -0800 (PST)
Received: from optonline.net (hamstr19.srv.hcvlny.cv.net [167.206.5.70])
by mta6.srv.hcvlny.cv.net
(Sun Java System Messaging Server 6.2-4.03 (built Sep 22 2005))
with ESMTP id <[email protected]>; Sat,
21 Jan 2006 21:24:25 -0500 (EST)
Received: from [10.240.3.38] (Forwarded-For: [66.114.69.214])
by mstr13.srv.hcvlny.cv.net (mshttpd); Sat, 21 Jan 2006 21:24:24 -0500
Date: Sat, 21 Jan 2006 21:24:24 -0500
From: [email protected]
Subject: Re: SSL and SSH support in TOPS-20
In-reply-to: <[email protected]>
To: Mark Crispin <[email protected]>
Cc: TOPS-20 Hackers and Yackers <[email protected]>
Message-id: <[email protected]>
MIME-version: 1.0
X-Mailer: Sun Java(tm) System Messenger Express 6.2-4.03 (built Sep 22 2005)
Content-type: text/plain; charset=us-ascii
Content-language: en
Content-transfer-encoding: 7BIT
Content-disposition: inline
X-Accept-Language: en
Priority: normal
References: <[email protected]>

Mark,

Sorry for the long winded response: you've brought up some issues that
I happen to have been pondering on and off for about two years.

> I have been thinking about how to do SSL/TLS and SSH support in
> TOPS-20.
>
> For SSL/TLS, I think that the easiest/best method would be to add
> KLH10 microcode support that links to OpenSSL, as if it were a
> hardware implementation of SSL/TLS.

I had also been entertaining some ideas about extending the KLH10
microcode that are perhaps relevant to this approach. In particular,
I wanted to do two things. First, at one point, I was toying with the
idea of getting better (or perhaps different) floating point
performance, so I was considering having a mechanism to expose the
80x87 numerical co-processor interface.

Implementation could probably be fairly straightforward (or not). If
the waiting forms of the 80x87 instructions were forced, then Tops-20
could simply use the 80x87 as an atomic device and preserve the
co-processor state as necessary during normal timesharing. You could
DATAO the operands and then maybe somehow CONO the 80x87 opcode you
wanted. Non-waiting forms of the 80x87 would require Tops-20 to have
a little bit more knowledge about the device in order to know whether
a floating point instruction was in flight during a decision to switch
fork context.

One justification that I had for using such an approach was that, at
one point (maybe when I was still at Marlboro?), I believe I might
have heard of a PDP-10 with some sort of a mathematical (or other)
co-processor. Does anybody know anything more about this? I know
that ITS was able to use the PDP-6 as sort of slave processor and
maybe WAITS did something else, but that isn't what I'm asking about.

Anyway, I decided against doing this for a number of reasons. Among
these were that it wouldn't work for non-Intel platforms and thus the
code that I'd write wouldn't run anywhere else: KL, XKL, KS and other
microengines would be out of luck. If I had a massive amount
crunching to do, it probably would be just as cheap to ship the
numbers off to some random host using TCP and the code could then run
on any PDP10 with Internet.

Second, one major problem that I have had with doing the FTP server
was all the bit banging that I needed to do in order to get the
various subsets (proper and otherwise) of 36 bits over the Internet
wire. The string instructions ALMOST did what I wanted. Indeed,
converting from 7 bit ASCII to 8 bit ASCII was REAL easy: I just
loaded a 7 bit source (double) byte pointer and an 8-bit byte pointer
and did a MOVSLJ. Fast. Nice. Easy.

No such functionality exists for byte conversion and packing. What I
wanted was to load up an arbitrary source input byte pointer (like 36)
an arbitrary output byte pointer (like 8) and then do a new EXTEND
instruction like MOVSPB (MOVe String Packing Bits) and then the
microengine would do the shifting and or'ing.

It would be faster than doing it in MACRO and a whole lot simpler.
Indeed, I was somewhat surprised that DEC never implemented this; it
would have sped things up when talking to Vaxen over DECnet and might
have made talking to future devices (such as tape drives) require less
hardware in the bit fiddler. Maybe they were running out of space in
the KL microcode. It seems like an obvious thing now.

Anyway, I decided against doing a MOVSPB implementation for many of
the same reasons as above: I wanted the extended mode FTP server to
run on XKL and KL hardware and any other future hardware which
supported extended addressing. I would have had to write conditional
assembly (and/or execution) code and I'd still wind up sweating
through all the bit banging in MACRO. Besies, I also had no reason to
suspect that I'd be any better knocking out bits in C than in MACRO.
Come to think of it, I'd probably be worse ...

But it's something that I still wonder about. I think MOVSPB would be
general purpose enough to be quite useful, but I'd want to see about
having it be in the 'official' PDP-10 architecture. I don't know what
kind of mean such a phrase has anymore. That's one problem I see with
your approach: it's limited to the KLH10 microengine. I don't know if
this is a big deal or not. For myself, I find that I just like the
idea of having lots of PDP-10 code that will run everywhere. A port
of SSH/SSL would be usable by more microengines, so my inclination
would be to go that route.

> For SSH server, I think that the easiest/best method would be to
> negotiate with the OpenSSH developers to see if we can split off
> OpenSSH server code from UNIX virtual terminal handling; that is,
> have some sort of abstraction layer. We would implement that
> abstraction layer as DH11 lines in the DTE. This requires itemizing
> what's in RSX-20F protocol and cross-referencing that with UNIX pty
> operations to determine what would be a good abstraction layer for
> both. The result is that SSH sessions would look like dialups as if
> it were on a "milking machine", but in fact it would be completely
> flow-controlled. I suspect that it'd actually be quite a bit faster
> than TELNET.

Perhaps it might be faster. In terms of best performance for a user
on a KLH box, it is reasonable to assume that having the SSH code be
executed by the host engine would result less PDP-10 code being
executed in some cases. So, you'd clearly win there. However,
wouldn't you then be limited by the speed of the KLH10 DTE
implementation? Back in the day, KL-10 DTE's were only considered
fast enough for unit record equipment. I think I remember that the
upper speed of the DTE was something like 250KB/s. Was it in that
range? What are the constraints now?

Initially, you might be limited to KL DTE20 speed because of timing
issues in DTESRV. I'm not saying they're there are not, you just
might get stuck with them. Finally, I don't recall the DTE20 protocol
itself as being particularly efficient as compared to directly talking
to a channel device. Of course, all of this stuff is infinitely more
malleable now, but you still might wind up having to tinker with it.

For raw transfer speed, the NI should blow the DTE right out of the
water. Even the speeds that I'm getting right now in the extended
mode FTP server are faster than anything that a DTE could deliver.
Also, [SYSREF] states (on page 3-4) that the processor gives higher
priority to devices on channels (RH20s) than DTE, although I don't
know if this is relevant for the KLH10 microengine.

Given all this, it might actually be faster, in terms of measured end-
to-end performance, to port SSH. I did a port of an early version of
SSH v1 in the late 1990's while I was still at Citibank. The target
was a Unix platform that was pretty clunky. It wasn't compatible with
anything, so I had some work to do. There were modes in the SSH code
to not use PTYs, but use pipes instead. I don't know if that would be
useful now; maybe it would. But using the NI and doing the
calculations on the 10 might be faster then doing the calculations on
the host engine and then shoving things through the DTE.

Finally, with your approach, I believe that you would be talking about
hacking KLH10, grafting in SSH/SSL somehow and then defining and
debugging those hardware interfaces. Next you've got to write and
debug the Tops-20 operating system code and define and debug that
device interface. Then you've got to write the user mode software.
At least from the limited experience that I had with muscling ssh v1
around, I think a user mode port would be less effort, assuming that
KCC can get the job done and you don't have to start messing around
with that.

--T

21-Jan-2006 18:35:49-PST,4346;000000000000
Return-Path: <[email protected]>
Received: from mta3.srv.hcvlny.cv.net ([167.206.4.198]) by lingling.panda.com with TCP/SMTP; Sat, 21 Jan 2006 18:25:14 -0800 (PST)
Received: from optonline.net (hamstr19.srv.hcvlny.cv.net [167.206.5.70])
by mta3.srv.hcvlny.cv.net
(Sun Java System Messaging Server 6.2-4.03 (built Sep 22 2005))
with ESMTP id <[email protected]> for
[email protected]; Sat, 21 Jan 2006 21:25:07 -0500 (EST)
Received: from [10.240.3.38] (Forwarded-For: [66.114.69.214])
by mstr13.srv.hcvlny.cv.net (mshttpd); Sat, 21 Jan 2006 21:25:07 -0500
Date: Sat, 21 Jan 2006 21:25:07 -0500
From: [email protected]
Subject: Re: SSH/SSHD
In-reply-to: <[email protected]>
To: [email protected]
Cc: [email protected]
Message-id: <[email protected]>
MIME-version: 1.0
X-Mailer: Sun Java(tm) System Messenger Express 6.2-4.03 (built Sep 22 2005)
Content-type: text/plain; charset=us-ascii
Content-language: en
Content-transfer-encoding: 7BIT
Content-disposition: inline
X-Accept-Language: en
Priority: normal
References: <[email protected]>

JSol,

> I find that under UNIX, SSHD uses two proceses, one from root, one
> from the user process. I think the root part can be put under
> SYSJOB, and you can probably get away with one process for all users
> who need to access TELNET or FTP.

I'm not sure that I remember ssh being required to work this way. In
a short proof of concept port that I did for the Olivetti Unix
platform in 1998, I am fairly certain that I investigated and
demonstrated a mode where sshd was fired off by inetd. Each user sign
on via ssh or scp involved a seperate instance of sshd being ignited.

I do remember that startup performance was pretty terrible in this
mode and that you probably wanted to have sshd running around by
itself. However, there was no absolute necessity for a root instance
of sshd that I can recall (but this was nearly seven years ago).

What would the reason be for your strategy of putting sshd under job
0? Were you looking to have a monitor mode fork fire something up?
What? Why not SYSJB1 or a seperate subjob?

> I would propose putting a process peered with the EXEC and FTPSRT
> .... You can then use the existing TELNET using port 22. You .would
> then have to modify FTP to do the SCP (or replace it with SCP).

I'm not sure that I follow this architectural approach. What is it
that you are looking for the TELNET or FTP server to do for you? I
can't speak for TELNET, but at least for the (new) FTP server, I don't
immediately see what it would bring to the table. Its architecture is
quite different from ssh. Ssh/scp and friends encode all user data
and control information into a single data stream. Everything is (and
must be) packetized with packet headers describing data contents and
functions. This is quite similar in spirit to Kermit and, in some
respects, SMTP.

FTP, however, has a seperate control port used for negotiating data
flow on an entirely different IP port. Aside from packing bits for
image mode, formating paged files and some (trivial) ASCII
translation, the data fork doesn't do much else except PMAP% in/out
(big) files and then sit in a SOUT%/SIN% (R%, where necessary). None
of the (RFC959) control port parsing code, roughly a quarter of the
program, would be useful in any way that I can see. Also, something
like 20% of the code in the new server is just for the explicit
purpose of lying to graphical FTP clients to get them to believe that
they are talking to a plain old Unix system (as opposed to a winning
Tops-20 system). I don't know of what immediate use that would be for
sshd.

I think that, at best, you could fork up EFTPSR and have it grovel a
random file's contents into an 8 bit data stream which it could then
write to PIP: (it contains almost no code at all which does TCP:
checking). Some sort of an sshd thingie could then take this stream
and wrap it. I don't know how KCC would handle a sshd port, but I do
know that scp has file handling logic in it. It might be cheaper to
just make that work then trying to shoe horn EFTPSR in someplace.

Or not ... Am I missing something here? What capabilities were you
looking to leverage?
21-Jan-2006 20:27:12-PST,4415;000000000000
Return-Path: <[email protected]>
Received: from toad.xkl.com ([192.94.202.40]) by lingling.panda.com with TCP/SMTP; Sat, 21 Jan 2006 20:21:07 -0800 (PST)
Date: Sat, 21 Jan 2006 20:15:15 -0800 (PST)
From: Jon Solomon <[email protected]>
Subject: Re: SSH/SSHD
To: [email protected]
cc: [email protected]
In-Reply-To: <[email protected]>
Reply-to: [email protected]
Message-ID: <[email protected]>

JSol,

> I find that under UNIX, SSHD uses two proceses, one from root, one
> from the user process. I think the root part can be put under
> SYSJOB, and you can probably get away with one process for all users
> who need to access TELNET or FTP.

I'm not sure that I remember ssh being required to work this
way. In a short proof of concept port that I did for the
Olivetti Unix platform in 1998, I am fairly certain that I
investigated and wdemonstrated a mode where sshd was fired off
by inetd. Each user sign qon via ssh or scp involved a
seperate instance of sshd being ignited.

I don't disagree with this. I was just what I was reporting as the
unix boxes I use do. I am sure that you probably don't need separate
root sshd process.

What would the reason be for your strategy of putting sshd
under job 0? Were you looking to have a monitor mode fork
fire something up? What? Why not SYSJB1 or a seperate subjob?

No reason why not put it under SYSJB1 or another subjob. I was just
thinking about where to put the privved sshd. WIthout that all
you need to do is create a process under the job itself, perhaps
a process which can't be seen by the EXEC.

> I would propose putting a process peered with the EXEC and FTPSRT
> .... You can then use the existing TELNET using port 22. You .would
> then have to modify FTP to do the SCP (or replace it with SCP).

I'm not sure that I follow this architectural approach. What
is it that you are looking for the TELNET or FTP server to do
for you? I can't speak for TELNET, but at least for the (new)
FTP server, I don't immediately see what it would bring to the
table. Its architecture is quite different from ssh. Ssh/scp
and friends encode all user data and control information into
a single data stream. Everything is (and must be) packetized
with packet headers describing data contents and functions.
This is quite similar in spirit to Kermit and, in some
respects, SMTP.

Well, I don't it promise to know everything about the monitor...I do
the exec :)... Basically the encryption is something that the monitor
can call after unpacking the telnet packets and if the port is number
22, do a call to our encryption unpacking routine. Outgoing would
do the same if telnet uses port 22. As for FTP, as long as the
monitor encrypts the stuff being used by port 22 (the ssh/sshd port)

FTP, however, has a seperate control port used for negotiating
data flow on an entirely different IP port. Aside from
packing bits for image mode, formating paged files and some
(trivial) ASCII translation, the data fork doesn't do much
else except PMAP% in/out (big) files and then sit in a
SOUT%/SIN% (R%, where necessary). None of the (RFC959)
control port parsing code, roughly a quarter of the program,
would be useful in any way that I can see. Also, something
like 20% of the code in the new server is just for the explicit
purpose of lying to graphical FTP clients to get them to
believe that they are talking to a plain old Unix system (as
opposed to a winning Tops-20 system). I don't know of what
immediate use that would be for sshd.

I think that, at best, you could fork up EFTPSR and have it
grovel a random file's contents into an 8 bit data stream
which it could then write to PIP: (it contains almost no code
at all which does TCP: checking). Some sort of an sshd
know that scp has file handling logic in it. It might be
cheaper to thingie could then take this stream and wrap it. I
don't know how KCC would handle a sshd port, but I do
just make that work then trying to shoe horn EFTPSR in someplace.

Or not ... Am I missing something here? What capabilities
were you looking to leverage?

Yes. You want the user processes to have the forks for the outgoing
and incoming connections, and I want this to be in the monitor.

I feel this is possible.

-------
21-Jan-2006 21:22:38-PST,9328;000000000000
Return-Path: <[email protected]>
Received: from mxout5.cac.washington.edu ([140.142.32.135]) by lingling.panda.com with TCP/SMTP; Sat, 21 Jan 2006 21:17:59 -0800 (PST)
Received: from smtp.washington.edu (smtp.washington.edu [140.142.33.9])
by mxout5.cac.washington.edu (8.13.5+UW05.10/8.13.5+UW05.09) with ESMTP id k0M5Hq4R014379
(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
Sat, 21 Jan 2006 21:17:52 -0800
X-Auth-Received: from pangtzu.panda.com (pangtzu.panda.com [206.124.149.117])
(authenticated authid=mrc)
by smtp.washington.edu (8.13.5+UW05.10/8.13.5+UW05.09) with ESMTP id k0M5HoBC011196
(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT);
Sat, 21 Jan 2006 21:17:51 -0800
Date: Sat, 21 Jan 2006 21:17:50 -0800 (PST)
From: Mark Crispin <[email protected]>
Sender: [email protected]
To: [email protected]
cc: TOPS-20 Hackers and Yackers <[email protected]>
Subject: Re: SSL and SSH support in TOPS-20
In-Reply-To: <[email protected]>
Message-ID: <[email protected]>
References: <[email protected]>
<[email protected]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
X-Uwash-Spam: Gauge=IIIIIII, Probability=7%, Report='__CT 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0'

Tom -

Although your idea of access to the 80x87 co-processor is interesting, I
agree with your decision to punt. We really don't want to make KLH10
dependent upon a particular hardware platform.

> I know
> that ITS was able to use the PDP-6 as sort of slave processor and
> maybe WAITS did something else, but that isn't what I'm asking about.

Nothing as fancy as you imagine.

This was just your typical slave processor setup where you could load the
slave processor with something to run and it would do it. The PDP-6 at
MIT-AI ran whatever someone loaded into it. At SAIL, the PDP-6 ran the
computer music group's operating system (MULE) which drove various
synthesizers. The KA10 ran the XGP font compiler and sometimes spacewar.

TOPS-10 later had SMP, but that was different than a co-processor as well.

> No such functionality exists for byte conversion and packing. What I
> wanted was to load up an arbitrary source input byte pointer (like 36)
> an arbitrary output byte pointer (like 8) and then do a new EXTEND
> instruction like MOVSPB (MOVe String Packing Bits) and then the
> microengine would do the shifting and or'ing.

For what it was worth, the old IMP interfaces had a 36-bit mode and a CONO
to switch it between 32-bit and 36-bit modes. With "old" 8-bit NCP, the
1822 leader was 32 bits and the NCP leader was 40 bits, so you simply read
two words in 36-bit mode. If the socket indicated that it was a 32-bit
session, you then switched to 32-bit mode for the rest of the packet.

I realized that you could do the same thing with "new" 32-bit NCP. The
1822 leader was now 96 bits, so you would read two words in 32-bit mode,
two words in 36-bit mode, and then do the optional switch to 32-bit mode
as needed.

I forget if TOPS-20 used this technique or not; but WAITS definitely did
(I wrote it) and ITS probably also did. TOPS-20 probably did, since the
AN20 supported it. However, the last TOPS-20 version that had NETWRK.MAC
was 4.0, and my oldest TOPS-20 sources are 4.1. IIRC, TOPS-20 3A was
8-bit addresses, so TOPS-20 4.0 was the only version that had a 32-bit
address NCP.

TCP made it a lot harder. Instead of looking up a 32-bit socket number,
you now needed to look up a 32-bit source host + 16-bit source port +
32-bit destination host + 16-bit destination port = 96 bit session
identifier.

As a consequence, TOPS-20 didn't offer 36-bit mode for TCP:. That's why
FTP has to do the bit banging. I really wish that TOPS-20 had a 36-bit
mode for TCP:, even if it had to do the bit banging in the monitor, since
that would have put pressure on the Ethernet interface guys to support
36-bit data mode the way the IMP interfaces did.

It would also make our task now easier. Certainly, bit banging in the
KLH10 C code is faster than in PDP-10 code; and if there was a standard
interface we could have supported it.

> Indeed, I was somewhat surprised that DEC never implemented this; it
> would have sped things up when talking to Vaxen over DECnet

I assume that you're talking about 7-bit files here?

> and might
> have made talking to future devices (such as tape drives) require less
> hardware in the bit fiddler.

At the time, hardware bit fiddlers were the way to go. I still think that
it's the best way to do it.

> But it's something that I still wonder about. I think MOVSPB would be
> general purpose enough to be quite useful, but I'd want to see about
> having it be in the 'official' PDP-10 architecture.

As far as I'm concerned, XKL is the Official Keeper Of The PDP-10
Architecture. I have registered the new Panda IOTs (which extend the
idle device support of KLH10 to also support switches and lights) with
XKL. That isn't to say that XKL is adopting these; but rather that they
know about them and ideally if they do something essentially similar
they'll use my IOTs.

XKL does have their own directions, which are very different from us in
the hobbyist community. Nevertheless, I feel that it's important to work
with them as much as possible; and if we can agree upon any joint
extensions so much the better.

I have not yet done so, but I do plan on adding the KS10 BLTUB and BLTBU
instructions to the Panda IOT set. There are a few issues; KLH10 code
assumes that these are KS-only, and I think that they conflict with XKL
assigned IOTs.

A better argument may be made for getting everybody to agree to assign 247
to CIRC. It's that way in all ITS systems and in Panda. CIRC has proven
itself to be useful, most notably "CIRC ac,^D36" which bit-reverses a
doubleword.

I haven't wanted to push any of this. I think that we're building up
enough critical mass to be a credible community, but we really need to
tread lightly.

> However,
> wouldn't you then be limited by the speed of the KLH10 DTE
> implementation?

Currently, there is none. The DTE is implemented enough to drive the CTY
and get the time. That's it. So, this would be entirely new code.

In the old KS-only version of KLH10, I actually implemented support for
the KLINIK, but I haven't done anything yet in the modern system. It
probably would be interesting to offer KLINIK on a COM port. It would
make remote rebooting of KLH10 systems much easier.

> Initially, you might be limited to KL DTE20 speed because of timing
> issues in DTESRV.

That is a concern. DTESRV definitely has timing issues with the CTY.

> I'm not saying they're there are not, you just
> might get stuck with them. Finally, I don't recall the DTE20 protocol
> itself as being particularly efficient as compared to directly talking
> to a channel device. Of course, all of this stuff is infinitely more
> malleable now, but you still might wind up having to tinker with it.

Yup. The thing is that the prospect of dealing with software TTYs (TVTs
are even worse than PTYs) scares me. The DTE20 hardware line protocol
actually isn't all that bad, and as long as timing issues in DTESRV don't
bite us it should be a lot easier than dealing with DTEs.

> For raw transfer speed, the NI should blow the DTE right out of the
> water.

For hardware, yet; but we're not dealing with that hardware. It's all a
matter of how the software implements the DTE protocol.

> Given all this, it might actually be faster, in terms of measured end-
> to-end performance, to port SSH.

I find that difficult to believe. The PDP-10 is at least 30 times slower
than its host processor (which, by the way, is *excellent* for any sort of
emulator; 100x is much more typical). That's quite a lot to overcome.

> Finally, with your approach, I believe that you would be talking about
> hacking KLH10, grafting in SSH/SSL somehow and then defining and
> debugging those hardware interfaces.

Correct.

> Next you've got to write and
> debug the Tops-20 operating system code and define and debug that
> device interface.

No. As far as TOPS-20 is concerned, it's talking to a modem. A damn fast
one.

> Then you've got to write the user mode software.

No, again.

> At least from the limited experience that I had with muscling ssh v1
> around, I think a user mode port would be less effort, assuming that
> KCC can get the job done and you don't have to start messing around
> with that.

KCC is definitely not up to the task. Porting stuff to use it is even
worse than porting stuff to use VAX C. Sadly, there's a "C" programming
language, and there's GCC; and most stuff today is written for the latter.

I got a copy of PDP-10 GCC but haven't even started looking at it.

-- Mark --

http://panda.com/mrc
Democracy is two wolves and a sheep deciding what to eat for lunch.
Liberty is a well-armed sheep contesting the vote.
21-Jan-2006 21:33:52-PST,2391;000000000000
Return-Path: <[email protected]>
Received: from mxout3.cac.washington.edu ([140.142.32.166]) by lingling.panda.com with TCP/SMTP; Sat, 21 Jan 2006 21:28:22 -0800 (PST)
Received: from smtp.washington.edu (smtp.washington.edu [140.142.33.9])
by mxout3.cac.washington.edu (8.13.5+UW05.10/8.13.5+UW05.09) with ESMTP id k0M5SFo2000447
(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
Sat, 21 Jan 2006 21:28:15 -0800
X-Auth-Received: from pangtzu.panda.com (pangtzu.panda.com [206.124.149.117])
(authenticated authid=mrc)
by smtp.washington.edu (8.13.5+UW05.10/8.13.5+UW05.09) with ESMTP id k0M5SDPx011531
(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT);
Sat, 21 Jan 2006 21:28:14 -0800
Date: Sat, 21 Jan 2006 21:28:13 -0800 (PST)
From: Mark Crispin <[email protected]>
Sender: [email protected]
To: [email protected]
cc: TOPS-20 Hackers and Yackers <[email protected]>
Subject: Re: SSH/SSHD
In-Reply-To: <[email protected]>
Message-ID: <[email protected]>
References: <[email protected]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
X-Uwash-Spam: Gauge=IIIIIII, Probability=7%, Report='__CT 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0'

On Sat, 21 Jan 2006, Jon Solomon wrote:
> Yes. You want the user processes to have the forks for the outgoing
> and incoming connections, and I want this to be in the monitor.

I think that this would be much too slow.

A PDP-10 on today's CPUs only gets about the equivalent of 40 to 100 MHz,
depending upon the underlying CPU (an XKL-1 is only about 4-5 MHz). On
top of this, you have to consider that Tenex/TOPS-20 has *never* driven
PTYs of any kind very well, and that it was necessary to move TELNET
protocol into the monitor to get even the mediocre performance that it has
now. On top of this, you'd be adding all the crypto stuff.

Implementing SSH protocol in the monitor is a non-starter because you're
not likely to find anyone who would do it. Running C compiler generated
binaries as part of the monitor is even more of a non-starter.

-- Mark --

http://panda.com/mrc
Democracy is two wolves and a sheep deciding what to eat for lunch.
Liberty is a well-armed sheep contesting the vote.
22-Jan-2006 10:22:56-PST,1302;000000000000
Return-Path: <[email protected]>
Received: from nic.cafax.se ([192.71.228.17]) by lingling.panda.com with TCP/SMTP; Sun, 22 Jan 2006 10:16:44 -0800 (PST)
Received: from nic.cafax.se (localhost [127.0.0.1])
by nic.cafax.se (8.12.11/8.12.11) with ESMTP id k0MIGaQg015594
for <[email protected]>; Sun, 22 Jan 2006 19:16:36 +0100 (MET)
Received: (from bygg@localhost)
by nic.cafax.se (8.12.11/8.12.11/Submit) id k0MIGZF2010150
for TOPS-20 Hackers and Yackers <[email protected]>; Sun, 22 Jan 2006 19:16:35 +0100 (MET)
Date: Sun, 22 Jan 2006 19:16:35 WET
From: Johnny Eriksson <[email protected]>
To: TOPS-20 Hackers and Yackers <[email protected]>
Subject: Re: SSL and SSH support in TOPS-20
In-Reply-To: Your message of Sat, 21 Jan 2006 21:17:50 -0800 (PST)
Message-ID: <[email protected]>

> I have not yet done so, but I do plan on adding the KS10 BLTUB and BLTBU
> instructions to the Panda IOT set. There are a few issues; KLH10 code
> assumes that these are KS-only, and I think that they conflict with XKL
> assigned IOTs.

Opcodes 716 and 717:

KS10: BLTBU BLTUB
KC10: LDPAC STPAC
XKL-1: UMOVE UMOVEM

fwiw: 704 and 705:

KS10: UMOVE UMOVEM
KC10: UMOVE UMOVEM
XKL-1: AMOVE AMOVEM

--Johnny
22-Jan-2006 12:30:23-PST,2140;000000000000
Return-Path: <[email protected]>
Received: from mxout7.cac.washington.edu ([140.142.32.178]) by lingling.panda.com with TCP/SMTP; Sun, 22 Jan 2006 12:24:47 -0800 (PST)
Received: from smtp.washington.edu (smtp.washington.edu [140.142.33.9])
by mxout7.cac.washington.edu (8.13.5+UW05.10/8.13.5+UW05.09) with ESMTP id k0MKOYl4019096
(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
Sun, 22 Jan 2006 12:24:34 -0800
X-Auth-Received: from pangtzu.panda.com (pangtzu.panda.com [206.124.149.117])
(authenticated authid=mrc)
by smtp.washington.edu (8.13.5+UW05.10/8.13.5+UW05.09) with ESMTP id k0MKOToo013926
(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT);
Sun, 22 Jan 2006 12:24:33 -0800
Date: Sun, 22 Jan 2006 12:24:27 -0800 (PST)
From: Mark Crispin <[email protected]>
Sender: [email protected]
To: Johnny Eriksson <[email protected]>
cc: TOPS-20 Hackers and Yackers <[email protected]>
Subject: Re: SSL and SSH support in TOPS-20
In-Reply-To: <[email protected]>
Message-ID: <[email protected]>
References: <[email protected]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
X-Uwash-Spam: Gauge=IIIIIII, Probability=7%, Report='__CT 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0'

Do you have a copy of the KC10 architecture specification? I saw it once,
but I've been unable to find a copy since. Or are you just looking at
PROLOG?

UMOVE/UMOVEM were also on my list to deal with, and I remember now that
the XKL-1 uses a different definition than the KS. Which is why it's "on
the list" and not "done".

Amazingly, TOPS-20 on the KS did not use UMOVE/UMOVEM; it uses the macros
that generate PXCT. I made it use UMOVE/UMOVEM in my system, and actually
reduced the monitor by a couple of pages (which in a KS really count!!).

-- Mark --

http://panda.com/mrc
Democracy is two wolves and a sheep deciding what to eat for lunch.
Liberty is a well-armed sheep contesting the vote.
22-Jan-2006 13:36:11-PST,1233;000000000000
Return-Path: <[email protected]>
Received: from nic.cafax.se ([192.71.228.17]) by lingling.panda.com with TCP/SMTP; Sun, 22 Jan 2006 13:30:44 -0800 (PST)
Received: from nic.cafax.se (localhost [127.0.0.1])
by nic.cafax.se (8.12.11/8.12.11) with ESMTP id k0MLURwH019901
for <[email protected]>; Sun, 22 Jan 2006 22:30:27 +0100 (MET)
Received: (from bygg@localhost)
by nic.cafax.se (8.12.11/8.12.11/Submit) id k0MLUR50005851
for TOPS-20 Hackers and Yackers <[email protected]>; Sun, 22 Jan 2006 22:30:27 +0100 (MET)
Date: Sun, 22 Jan 2006 22:30:27 WET
From: Johnny Eriksson <[email protected]>
To: TOPS-20 Hackers and Yackers <[email protected]>
Subject: Re: SSL and SSH support in TOPS-20
In-Reply-To: Your message of Sun, 22 Jan 2006 12:24:27 -0800 (PST)
Message-ID: <[email protected]>

> Do you have a copy of the KC10 architecture specification? I saw it once,
> but I've been unable to find a copy since. Or are you just looking at
> PROLOG?

ftp://ftp.stacken.kth.se/pub/pdp10/KC10.pdf

I have a paper copy, and I recently found out that the new copier at
work can be fed a stack of papers, resulting in a .pdf mailed to you...

> -- Mark --

--Johnny
22-Jan-2006 14:12:25-PST,2414;000000000000
Return-Path: <[email protected]>
Received: from mxout2.cac.washington.edu ([140.142.33.4]) by lingling.panda.com with TCP/SMTP; Sun, 22 Jan 2006 14:07:50 -0800 (PST)
Received: from smtp.washington.edu (smtp.washington.edu [140.142.32.139])
by mxout2.cac.washington.edu (8.13.5+UW05.10/8.13.5+UW05.09) with ESMTP id k0MM7e7Y000660
(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
Sun, 22 Jan 2006 14:07:41 -0800
X-Auth-Received: from pangtzu.panda.com (pangtzu.panda.com [206.124.149.117])
(authenticated authid=mrc)
by smtp.washington.edu (8.13.5+UW05.10/8.13.5+UW05.09) with ESMTP id k0MM7d2N024124
(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT);
Sun, 22 Jan 2006 14:07:40 -0800
Date: Sun, 22 Jan 2006 14:07:38 -0800 (PST)
From: Mark Crispin <[email protected]>
Sender: [email protected]
To: Johnny Eriksson <[email protected]>
cc: TOPS-20 Hackers and Yackers <[email protected]>
Subject: Re: SSL and SSH support in TOPS-20
In-Reply-To: <[email protected]>
Message-ID: <[email protected]>
References: <[email protected]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
X-Uwash-Spam: Gauge=IIIIIII, Probability=7%, Report='__CT 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __LINES_OF_YELLING 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0'

On Sun, 22 Jan 2006, Johnny Eriksson wrote:
>> Do you have a copy of the KC10 architecture specification?
> ftp://ftp.stacken.kth.se/pub/pdp10/KC10.pdf

THANK YOU!! THANK YOU!! THANK YOU!!

This is the document that I saw once in late 1982 or early 1983. I very
definitely remember reading about PUSHI and PUSHM/POPM.

Now we need to see how far TOPS-20 got in supporting the KC, and whether
it makes sense in trying to make klh10 implement a KC. A quick glance at
TOPS-20 7.0 monitor sources indicates that it definitely wasn't finished,
but possibly it ran. It isn't clear how much of the KC code was broken in
the 7 year period between the cancellation of the KC and the end of DEC
edits to TOPS-20.

It *would* be damn funny if, after all these years, we finally got
Jupiter.... :-)

-- Mark --

http://panda.com/mrc
Democracy is two wolves and a sheep deciding what to eat for lunch.
Liberty is a well-armed sheep contesting the vote.
23-Jan-2006 09:07:13-PST,1685;000000000000
Return-Path: <[email protected]>
Received: from sj-iport-4.cisco.com ([171.68.10.86]) by lingling.panda.com with TCP/SMTP; Mon, 23 Jan 2006 09:00:28 -0800 (PST)
Received: from sj-core-5.cisco.com ([171.71.177.238])
by sj-iport-4.cisco.com with ESMTP; 23 Jan 2006 09:00:13 -0800
X-IronPort-AV: i="4.01,212,1136188800";
d="scan'208"; a="1769191749:sNHT28663400"
Received: from cisco.com (cypher.cisco.com [171.69.11.142])
by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id k0NH0Cjt004691;
Mon, 23 Jan 2006 09:00:12 -0800 (PST)
Received: (from billw@localhost)
by cisco.com (8.8.8-Cisco List Logging/8.8.8) id JAA17691;
Mon, 23 Jan 2006 09:00:12 -0800 (PST)
Sender: Bill Westfield <[email protected]>
Date: Mon, 23 Jan 2006 9:00:12 PST
From: William "Chops" Westfield <[email protected]>
To: Mark Crispin <[email protected]>
Cc: [email protected], TOPS-20 Hackers and Yackers <[email protected]>
Subject: Re: SSH/SSHD
In-Reply-To: Your message of Sat, 21 Jan 2006 21:28:13 -0800 (PST)
ply-To: Your message of Mon, 23 Jan 2006 09:20:57 +0100
Message-ID: <CMM.0.90.4.1138035612.billw@cypher>

> Yes. You want the user processes to have the forks for the
> outgoing and incoming connections...

I think that this would be much too slow.

On top of this, you have to consider that Tenex/TOPS-20 has
*never* driven PTYs of any kind very well, and that it was
necessary to move TELNET protocol into the monitor to get even
the mediocre performance that it has now.

How about a user process acting as a sort of ssh -> telnet converter,
leveraging the works that's already been done to improve TCP TTYs?

BillW

23-Jan-2006 20:31:13-PST,6106;000000000000
Return-Path: <[email protected]>
Received: from mta7.srv.hcvlny.cv.net ([167.206.4.202]) by lingling.panda.com with TCP/SMTP; Mon, 23 Jan 2006 20:26:14 -0800 (PST)
Received: from optonline.net (hamstr19.srv.hcvlny.cv.net [167.206.5.70])
by mta7.srv.hcvlny.cv.net
(Sun Java System Messaging Server 6.2-4.03 (built Sep 22 2005))
with ESMTP id <[email protected]>; Mon,
23 Jan 2006 23:25:02 -0500 (EST)
Received: from [10.240.3.40] (Forwarded-For: [69.114.1.48])
by mstr13.srv.hcvlny.cv.net (mshttpd); Mon, 23 Jan 2006 23:25:01 -0500
Date: Mon, 23 Jan 2006 23:25:01 -0500
From: [email protected]
Subject: Re: SSL and SSH support in TOPS-20
In-reply-to: <[email protected]>
To: Mark Crispin <[email protected]>
Cc: TOPS-20 Hackers and Yackers <[email protected]>
Message-id: <[email protected]>
MIME-version: 1.0
X-Mailer: Sun Java(tm) System Messenger Express 6.2-4.03 (built Sep 22 2005)
Content-type: text/plain; charset=us-ascii
Content-language: en
Content-transfer-encoding: 7BIT
Content-disposition: inline
X-Accept-Language: en
Priority: normal
References: <[email protected]>
<[email protected]>
<[email protected]>

> > Indeed, I was somewhat surprised that DEC never implemented this;
> > it would have sped things up when talking to Vaxen over DECnet

> I assume that you're talking about 7-bit files here?

No, I have mistaken myself. I meant that it would have made sending
36 bit files to a VAX take less load on the PDP-10 CPU. But, you'd
never want to send 36 bits to the VAX (would you?)

MOVSLJ works fine to send 7 bit ASCII to a VAX. You set a 7 bit
source pointer and an 8 bit destination pointer, issue the EXTEND and
you're done. Nice. I use this in ASCII mode on the extended FTP
server.

Of course, somebody still has to swap the bytes (see BLTBU, below)

> > and might have made talking to future devices (such as tape
> > drives) require less hardware in the bit fiddler.

> At the time, hardware bit fiddlers were the way to go. I still
> think that it's the best way to do it.

I agree that a hardware bit fiddler would certainly take more load off
the host PDP-10 CPU. That was an important thing in the days of
Largely Overloaded Timesharing Systems. That's not the case now.
But, having a bit banging instruction might largely eliminate the need
for a fiddler which (at the time) might have meant a cheaper tape
controller.

The I/O world was increasingly moving towards 8 bit bytes in the
1980's and now has nearly completely done so (modulo some devices
transfering multiples of eight bits). Having a bit banging
instruction might make interfacing to these devices cheaper and
(hence) easier because you wouldn't have to run as many data lines or
do fiddlish things.

I was thrilled to finally see PUSHI, PUSHM and POPM! I'm surpised
that nobody ever seems to have considered 'MOVSPB'. It's an obvious
win: a completely generalize bit packing instruction. It might also
win with converting RADIX50 (with a MOVSPB offset), also, but I
haven't really thought about that.

> I have not yet done so, but I do plan on adding the KS10 BLTUB and
> BLTBU instructions to the Panda IOT set. There are a few issues;
> KLH10 code assumes that these are KS-only, and I think that they
> conflict with XKL assigned IOTs.

Yes, it would be an obvious win to have byte swapping instructions.
Reviewing the write up in the KS Microcode Version 124 is particularly
instructive: [a MACRO implementation makes]

" 19 memory references per word in the LOOP. (3 refs/DPB x 4 bytes +
4 LSH + 2 MOVE + AOBJN ) BLTBU would make 2. Further, DPB does
shifting and masking that BLTBU does not. BLTBU shifts 2 bytes at
a time, for a total of 19 shifts (1 bit each) for the entire word.
BLTBU makes 2"

> > Given all this, it might actually be faster, in terms of measured
> > end- to-end performance, to port SSH.

> I find that difficult to believe. The PDP-10 is at least 30 times
> slower than its host processor (which, by the way, is *excellent*
> for any sort of emulator; 100x is much more typical). That's quite
> a lot to overcome.

Yes, it is difficult to believe, that's why I (think I) went to such
lengths to qualify what I was saying. If you run into problems with
the DTE speeds (because of timing issues and whatnot) and find
yourself limited to whatever the DTE actually ran at, then it might be
that doing the calculation on the 10 itself and using the NI to ship
the data will get you faster end-to-end throughput, as measured by the
remote client ssh. That's all I was saying--an extremely limited
case.

When I did my proof-of-concept port of ssh v1 in 1999, my host machine
was a 60 Mhz Pentium with 128 MB of memory and a 4 Mbps token ring
interface. That is roughly the same order of magnitude machine that I
have today on my KLH10 box. Running ssh on the Pentium did not
present significant computational load. This being the case, I'd like
to think that running that code on 10 wouldn't be a big dog, either.

However, I couldn't say how well this would scale for lots of users.
That (currently) isn't the case for hobbiest machines.

> > Next you've got to write and debug the Tops-20 operating system
> > code and define and debug that device interface.
>
> No. As far as TOPS-20 is concerned, it's talking to a modem. A
> damn fast one.

> > Then you've got to write the user mode software.
>
> No, again.

I've mistated, again. I switched the topic to your exposing an
SSL/TLS device on Tops-20 but never said this. Opps! What I meant
was that if you do want to bring SSL/TLS out to the user, then you've
got to do the above to use it.

> I got a copy of PDP-10 GCC but haven't even started looking at it.

Is/will this available to the general hobbiest community? I have a
number of things I'd like to port!

23-Jan-2006 20:40:28-PST,2171;000000000000
Return-Path: <[email protected]>
Received: from mta5.srv.hcvlny.cv.net ([167.206.4.200]) by lingling.panda.com with TCP/SMTP; Mon, 23 Jan 2006 20:36:06 -0800 (PST)
Received: from optonline.net (hamstr19.srv.hcvlny.cv.net [167.206.5.70])
by mta5.srv.hcvlny.cv.net
(Sun Java System Messaging Server 6.2-4.03 (built Sep 22 2005))
with ESMTP id <[email protected]>; Mon,
23 Jan 2006 23:35:51 -0500 (EST)
Received: from [10.240.3.40] (Forwarded-For: [69.114.1.48])
by mstr13.srv.hcvlny.cv.net (mshttpd); Mon, 23 Jan 2006 23:35:50 -0500
Date: Mon, 23 Jan 2006 23:35:50 -0500
From: [email protected]
Subject: Re: SSH/SSHD
In-reply-to: <[email protected]>
To: Mark Crispin <[email protected]>
Cc: TOPS-20 Hackers and Yackers <[email protected]>
Message-id: <[email protected]>
MIME-version: 1.0
X-Mailer: Sun Java(tm) System Messenger Express 6.2-4.03 (built Sep 22 2005)
Content-type: text/plain; charset=us-ascii
Content-language: en
Content-transfer-encoding: 7BIT
Content-disposition: inline
X-Accept-Language: en
Priority: normal
References: <[email protected]>
<[email protected]>

> A PDP-10 on today's CPUs only gets about the equivalent of 40 to 100
> MHz, depending upon the underlying CPU (an XKL-1 is only about 4-5
> MHz).

A 60 Mhz Pentium had plenty of juice to run two or three ssh/scp v1
sessions in 1999. I don't know if ssh itself actually relies on 8 (or
32) bit arithmatic; if that is the case, then a PDP-10 port would be
slower, but perhaps not abysmally so.

Given my experience, I don't feel comfortable with immediately ruling
out this approach. Also, with a gcc-10 compiler, it might be easier
to port to the 10.

So an XKL-1 is about the speed of an IBM PC-AT? Ouch ... I wouldn't
want to assume that it would have enough gas to run ssh.

> On top of this, you have to consider that Tenex/TOPS-20 has *never*
> driven PTYs of any kind very well,

Are Tops-20 PTY's beyond fixing? Maybe it's something that we should
put on the list of 'things to do'.

23-Jan-2006 21:00:56-PST,3108;000000000000
Return-Path: <[email protected]>
Received: from mta7.srv.hcvlny.cv.net ([167.206.4.202]) by lingling.panda.com with TCP/SMTP; Mon, 23 Jan 2006 20:55:59 -0800 (PST)
Received: from optonline.net (hamstr19.srv.hcvlny.cv.net [167.206.5.70])
by mta7.srv.hcvlny.cv.net
(Sun Java System Messaging Server 6.2-4.03 (built Sep 22 2005))
with ESMTP id <[email protected]> for
[email protected]; Mon, 23 Jan 2006 23:54:43 -0500 (EST)
Received: from [10.240.3.40] (Forwarded-For: [69.114.1.48])
by mstr13.srv.hcvlny.cv.net (mshttpd); Mon, 23 Jan 2006 23:54:43 -0500
Date: Mon, 23 Jan 2006 23:54:43 -0500
From: [email protected]
Subject: Re: SSH/SSHD
In-reply-to: <CMM.0.90.4.1138035612.billw@cypher>
To: William Chops Westfield <[email protected]>
Cc: TOPS-20 Hackers and Yackers <[email protected]>
Message-id: <[email protected]>
MIME-version: 1.0
X-Mailer: Sun Java(tm) System Messenger Express 6.2-4.03 (built Sep 22 2005)
Content-type: text/plain; charset=us-ascii
Content-language: en
Content-transfer-encoding: 7BIT
Content-disposition: inline
X-Accept-Language: en
Priority: normal
References: "21 Jan 2006 21:28:13 -0800" <CMM.0.90.4.1138035612.billw@cypher>

> How about a user process acting as a sort of ssh -> telnet
> converter, leveraging the works that's already been done to improve
> TCP TTYs?

It's interesting that you should say this. I was toying with what I
think might be similar approach.

In approximately the 1986 timeframe, Columbia got its first Microvax
in Watson Labs. As this was down the hall from where I worked, my my
brother (I think) ran a line to the machine for me and hooked it into
a serial port switch on my Ann Arbor Ambassdor (AAA) terminal (he
would still do SA stuff, then). This line ran at the maximum speed of
the AAA, which was 19.2 Kbs.

The Microvax was also connected into the (early) campus Ethernet
backbone, so I then used the Microvax to LAT into the 20--a splendid
use of a VAX, I think. Terminal performance was incredible. Things
seemed to literally blink onto the screen and I was the ONLY person at
Columbia with non-machine room 9600 baud service (again, something
that my brother set up for me).

Other than using an Imlac, this was the fastest terminal I ever used
on a PDP-10. However, I don't know if the internal implementation was
via PTY. It sure was plenty adequate for hacking EMACS on a 60 line
screen.

Is routing fixed for KLH10? If so, then I know that free DECnet/LAT
packages exist for Linux. I have downloaded and installed them for
Debian. Unfortunately, I can't LAT into my 20 from its host and I
don't have another Linux box to try this on.

Assuming we could get that to work, I think that it would probably be
pretty trivial to cons up some sort of a 'T' to have a host ssh
implementation fork up a LAT to get into the 20.

It might elminate a lot of mucking around with KLH10, DTESRV and the
like. We could then concentrate on some *REAL* KLH10 hacking like
getting a KC10 or a CI implemented!
28-Jan-2006 10:57:20-PST,880;000000000000
Mail-From: MRC created at 28-Jan-2006 10:52:08
Date: Sat, 28 Jan 2006 10:52:08 -0800 (PST)
From: Mark Crispin <[email protected]>
Subject: it appears that spammers have discovered the TOPS-20 list
To: [email protected]
Pithy-Thought: TOPS-20 was a great improvement over its successors
Message-ID: <[email protected]>

Many of you received spam today that was sent to the TOPS-20 list. I
apologize. As I mentioned last June, someone in Norway unilaterally
decided that it was alright to forward TOPS-20 list messages to a
USENET newsgroup. I deleted the offending address, but the list address
is still harvestable in Google Groups.

I haven't taken any action yet; but if there's another spam incident in
the near future I will switch the list to moderated.

Once again, my apologies for the clutter in your inbox.
-------
30-Jan-2006 15:06:56-PST,1881;000000000000
Return-Path: <[email protected]>
Received: from biscayne-one-station.mit.edu ([18.7.7.80]) by lingling.panda.com with TCP/SMTP; Mon, 30 Jan 2006 15:00:23 -0800 (PST)
Received: from outgoing.mit.edu (OUTGOING-AUTH.MIT.EDU [18.7.22.103])
by biscayne-one-station.mit.edu (8.12.4/8.9.2) with ESMTP id k0UMnRip023205
for <[email protected]>; Mon, 30 Jan 2006 17:49:28 -0500 (EST)
Received: from home-on-the-dome.mit.edu (HOME-ON-THE-DOME.MIT.EDU [18.7.16.76])
(authenticated bits=56)
(User authenticated as [email protected])
by outgoing.mit.edu (8.13.1/8.12.4) with ESMTP id k0UMnOkM027298
(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT)
for <[email protected]>; Mon, 30 Jan 2006 17:49:25 -0500 (EST)
Received: (from jsol@localhost) by home-on-the-dome.mit.edu (8.12.9)
id k0UMnOS6004745; Mon, 30 Jan 2006 17:49:24 -0500 (EST)
Date: Mon, 30 Jan 2006 17:49:24 -0500 (EST)
Message-Id: <[email protected]>
From: "Jonathan A. Solomon" <[email protected]>
To: [email protected]
Subject: tops-20 under KLH-10...
X-Spam-Score: -2.599
X-Spam-Flag: NO
X-Scanned-By: MIMEDefang 2.42

I have been experiencing a small problem with the TOPS-20's that
are run through KLH-10 under UNIX (linux)....

It also affects ITS from sv.svensson.org.

What happens is outgoing and incoming TCP/IP connections hang
and cannot be reinstated without booting the unix system and
then boot TOPS-20 and ITS.

When you run KLH-10 under Microsoft, the problem doesn't
exist. Dave Kompel's machine was run under Microsoft,
before his house was burnt to the ground, killing off
the hosts.

TWENEX.ORG and SV.SVENSSON.ORG are run under unix.
Both of these systems demonstrate some problems with
TCP/IP connections hang, and you have to reboot.

just thought you'd like to know.

--jsol
30-Jan-2006 17:06:30-PST,1484;000000000000
Return-Path: <[email protected]>
Received: from sdf.lonestar.org (mx.freeshell.ORG [192.94.73.21]) by lingling.panda.com with TCP/SMTP; Mon, 30 Jan 2006 17:00:27 -0800 (PST)
Received: from [10.0.0.3] (dsl254-015-081.sea1.dsl.speakeasy.net [216.254.15.81])
(authenticated (0 bits))
by sdf.lonestar.org (8.13.1/8.12.10) with ESMTP id k0V108M2012125
for <[email protected]>; Tue, 31 Jan 2006 01:00:09 GMT
Mime-Version: 1.0 (Apple Message framework v746.2)
In-Reply-To: <[email protected]>
References: <[email protected]>
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <[email protected]>
Content-Transfer-Encoding: 7bit
From: Stephen Jones <[email protected]>
Subject: Re: tops-20 under KLH-10...
Date: Mon, 30 Jan 2006 17:00:17 -0800
To: [email protected]
X-Mailer: Apple Mail (2.746.2)

On Jan 30, 2006, at 2:49 PM, Jonathan A. Solomon wrote:

> TWENEX.ORG and SV.SVENSSON.ORG are run under unix.
> Both of these systems demonstrate some problems with
> TCP/IP connections hang, and you have to reboot.

I've never experienced it like you have described. There was a
problem in
the dpni20 which Ken cited has a NetBSD shortcoming. He wrote a work
around (grep for "NetBSD still sucks") which works fine for me.

Just for the record:
12:58AM up 70 days, 5:09, 24 users, load averages: 1.91, 1.78, 1.85

30-Jan-2006 17:11:33-PST,1805;000000000000
Return-Path: <[email protected]>
Received: from sdf.lonestar.org (mx.freeshell.ORG [192.94.73.21]) by lingling.panda.com with TCP/SMTP; Mon, 30 Jan 2006 17:02:29 -0800 (PST)
Received: from [10.0.0.3] (dsl254-015-081.sea1.dsl.speakeasy.net [216.254.15.81])
(authenticated (0 bits))
by sdf.lonestar.org (8.13.1/8.12.10) with ESMTP id k0V12FgK027999
for <[email protected]>; Tue, 31 Jan 2006 01:02:16 GMT
Mime-Version: 1.0 (Apple Message framework v746.2)
Content-Transfer-Encoding: 7bit
Message-Id: <[email protected]>
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
To: [email protected]
From: Stephen Jones <[email protected]>
Subject: twenex.org new account stats
Date: Mon, 30 Jan 2006 17:02:21 -0800
X-Mailer: Apple Mail (2.746.2)

-------------------------
New LOGINs for TWENEX.ORG
-------------------------

MON 2003 2004 2005 TOTAL
------------------------- -----
Jan: 226 355 154 735
Feb: 91 225 141 457
Mar: 418 267 55 740
Apr: 617 197 90 904
May: 553 228 94 875
Jun: 788 52 114 954
Jul: 939 129 412 1480
Aug: 840 23 150 1013
Sep: 708 45 68 821
Oct: 624 162 112 898
Nov: 553 122 53 728
Dec: 486 159 67 712
------------------------- -----
TOTAL: 6843 1964 1510 10317

I'm sorry I don't have stats for prior to 2003.

People create logins for different reasons and I would gather that
TOPS-20 access is probably not high on that list of reasons, which
is sad. However, there is an interest in the system from both the
new and old. And some of those newbies just stumble upon it and like
it.
30-Jan-2006 19:13:59-PST,2155;000000000000
Return-Path: <[email protected]>
Received: from biscayne-one-station.mit.edu ([18.7.7.80]) by lingling.panda.com with TCP/SMTP; Mon, 30 Jan 2006 19:05:51 -0800 (PST)
Received: from outgoing.mit.edu (OUTGOING-AUTH.MIT.EDU [18.7.22.103])
by biscayne-one-station.mit.edu (8.12.4/8.9.2) with ESMTP id k0V32ggB019985;
Mon, 30 Jan 2006 22:02:42 -0500 (EST)
Received: from mint-square.mit.edu (MINT-SQUARE.MIT.EDU [18.7.16.77])
(authenticated bits=56)
(User authenticated as [email protected])
by outgoing.mit.edu (8.13.1/8.12.4) with ESMTP id k0V32dPr014172
(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT);
Mon, 30 Jan 2006 22:02:39 -0500 (EST)
Received: (from jsol@localhost) by mint-square.mit.edu (8.12.9)
id k0V32doL012811; Mon, 30 Jan 2006 22:02:39 -0500 (EST)
Date: Mon, 30 Jan 2006 22:02:39 -0500 (EST)
Message-Id: <[email protected]>
From: "Jonathan A. Solomon" <[email protected]>
To: [email protected]
CC: [email protected]
In-reply-to: <[email protected]> (message from
Stephen Jones on Mon, 30 Jan 2006 17:00:17 -0800)
Subject: Re: tops-20 under KLH-10...
References: <[email protected]> <[email protected]>
X-Spam-Score: -2.599
X-Spam-Flag: NO
X-Scanned-By: MIMEDefang 2.42

well, i used a batch job running on twenex.org, to notify me by
e-mail whenever mail exists for me to read. At some point, the
mailer refused to send out mail. I tested and at that time no
mail was going out at all.

ALso there are times when "FTPSRV" is hung on an internet NVT
(which you can see from finger), and of course "twenex.org" when
you systat it.

I also know that Rutgers had a unix system which was broken as
well. Apparently users who logged out never got logged out,
leaving their ttys disowned and not-responsive. This is clearly
a bug in the unix system.

So I got mail from mailer saying it couldn't deliver the mail
to "[email protected]" (which is the address of my cellphone.
because "connection timed out".

Just thought you'd like to know.

30-Jan-2006 20:52:44-PST,2732;000000000000
Return-Path: <[email protected]>
Received: from mxout1.cac.washington.edu ([140.142.32.134]) by lingling.panda.com with TCP/SMTP; Mon, 30 Jan 2006 20:47:52 -0800 (PST)
Received: from smtp.washington.edu (smtp.washington.edu [140.142.33.9])
by mxout1.cac.washington.edu (8.13.5+UW05.10/8.13.5+UW05.09) with ESMTP id k0V4ljkR028771
(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
Mon, 30 Jan 2006 20:47:46 -0800
X-Auth-Received: from pangtzu.panda.com (pangtzu.panda.com [206.124.149.117])
(authenticated authid=mrc)
by smtp.washington.edu (8.13.5+UW05.10/8.13.5+UW05.09) with ESMTP id k0V4lMbH002063
(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT);
Mon, 30 Jan 2006 20:47:45 -0800
Date: Mon, 30 Jan 2006 20:47:22 -0800 (PST)
From: Mark Crispin <[email protected]>
Sender: [email protected]
To: "Jonathan A. Solomon" <[email protected]>
cc: TOPS-20 Hackers and Yackers <[email protected]>
Subject: Re: tops-20 under KLH-10...
In-Reply-To: <[email protected]>
Message-ID: <[email protected]>
References: <[email protected]>
<[email protected]> <[email protected]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
X-Uwash-Spam: Gauge=IIIIIII, Probability=7%, Report='__C230066_P5 0, __CT 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0'

On Mon, 30 Jan 2006, Jonathan A. Solomon wrote:
> ALso there are times when "FTPSRV" is hung on an internet NVT
> (which you can see from finger), and of course "twenex.org" when
> you systat it.

These are ancient, known issues in TOPS-20. Unlike UNIX, TOPS-20 does not
have aggressive "kill TCP session" features that activate when there is
some disturbance. Also, TOPS-20 FTP servers run on virtual terminals
which tend to get stuck in TTY output buffer waits.

I see no reason to blame klh10 for any of this.

Personally, I prefer the TOPS-20 behavior of not aggressively killing TCP
sessions. I have had TCP sessions survive on TOPS-20 over network outages
(and subsequently get recovered) while simultaneous UNIX sessions were
lost.

> So I got mail from mailer saying it couldn't deliver the mail
> to "[email protected]" (which is the address of my cellphone.
> because "connection timed out".

That doesn't necessarily indicate anything other than a temporary network
outage.

-- Mark --

http://panda.com/mrc
Democracy is two wolves and a sheep deciding what to eat for lunch.
Liberty is a well-armed sheep contesting the vote.
31-Jan-2006 02:17:29-PST,2033;000000000000
Return-Path: <[email protected]>
Received: from aun.it.uu.se ([130.238.12.36]) by lingling.panda.com with TCP/SMTP; Tue, 31 Jan 2006 02:11:31 -0800 (PST)
Received: from Nomen.it.uu.se (h150n2c1o851.bredband.skanova.com [81.225.33.150])
(authenticated bits=0)
by aun.it.uu.se (8.13.3/8.13.3) with ESMTP id k0V9xMXG007119
(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
Tue, 31 Jan 2006 10:59:22 +0100 (MET)
Received: by Nomen.it.uu.se (Postfix, from userid 1020)
id E3113119296; Tue, 31 Jan 2006 10:59:16 +0100 (CET)
From: Bjorn Victor <[email protected]>
To: "Jonathan A. Solomon" <[email protected]>
Cc: [email protected]
Subject: Re: tops-20 under KLH-10...
References: <[email protected]>
Date: Tue, 31 Jan 2006 10:59:15 +0100
In-Reply-To: <[email protected]> (Jonathan
A. Solomon's message of "Mon, 30 Jan 2006 17:49:24 -0500 (EST)")
Message-ID: <[email protected]>
User-Agent: Gnus/5.110004 (No Gnus v0.4) XEmacs/21.4.18 (linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii

On Mon, 30 Jan 2006 17:49:24 -0500 (EST) "Jonathan A. Solomon" <[email protected]> wrote:

> I have been experiencing a small problem with the TOPS-20's that
> are run through KLH-10 under UNIX (linux)....
>
> It also affects ITS from sv.svensson.org.
>
> What happens is outgoing and incoming TCP/IP connections hang
> and cannot be reinstated without booting the unix system and
> then boot TOPS-20 and ITS.

I don't understand precisely what you mean by this description; I've
never seen anything like this on my TOPS-20 or ITS systems. What I
have seen is TOPS-20 running out of NVTs, and ITS running out of
network connections, because of FTP/Telnet script kiddie attacks. I
had to block Telnet to my ITS system because of this, and close down
the FTP server on my TOPS-20 system.

But I've never had to reboot the host (Linux/Solaris) systems because
of this.

-- Bjorn
31-Jan-2006 05:30:28-PST,3151;000000000000
Return-Path: <[email protected]>
Received: from ddexch.y12.doe.gov ([134.167.192.29]) by lingling.panda.com with TCP/SMTP; Tue, 31 Jan 2006 05:24:09 -0800 (PST)
Received: from TW-Y12 ([134.167.192.28]) by ddexch.y12.doe.gov with InterScan Messaging Security Suite; Tue, 31 Jan 2006 08:23:53 -0500
Received: from 134.167.192.28 by TW-Y12 with ESMTP (Tumbleweed Email
Firewall SMTP Relay); Tue, 31 Jan 2006 08:23:51 -0500
X-Server-Uuid: 06FD5F43-8D61-49E7-83C9-1CAA26F771B9
Received: from twy12.y12.doe.gov ([134.167.192.28]) by twy12.y12.doe.gov
with Microsoft SMTPSVC(6.0.3790.1830); Tue, 31 Jan 2006 08:23:50 -0500
Received: from exchange4.y12.doe.gov ([134.167.250.68]) by
twy12.y12.doe.gov with InterScan Messaging Security Suite; Tue, 31 Jan
2006 08:23:49 -0500
Received: from Y12MAIL01.y12.doe.gov ([134.167.250.22]) by
exchange4.y12.doe.gov with Microsoft SMTPSVC(6.0.3790.1830); Tue, 31
Jan 2006 08:23:37 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Subject: KLH10 on Windows
Date: Tue, 31 Jan 2006 08:23:36 -0500
Message-ID: <[email protected]>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: KLH10 on Windows
Thread-Index: AcYl82vh1s+f9JUpTdyh4gJheMOrsAAdDAAQ
From: "Jones, Jeffrey A (JAJ)" <[email protected]>
To: [email protected]
Return-path: [email protected]
X-OriginalArrivalTime: 31 Jan 2006 13:23:37.0370 (UTC)
FILETIME=[8B1887A0:01C62669]
X-WSS-ID: 6FC1BB6D2WO1821797-01-01
Content-Type: text/plain;
charset=us-ascii
Content-Transfer-Encoding: quoted-printable

Everyone,

Does Jsol's comment "When you run KLH-10 under Microsoft" mean that =
KLH10 can
run directly under a Windows OS (namely Windows XP)? By the word =
'directly',
I mean running KLH10 as a Windows application. I was always under the
impression that a Windows system would need to run virtual machine =
software
(i.e. vmware) with a Unix virtual machine that runs KLH10 running =
TOPS-20.
From a monetary and performance perspective, this would be a win for me =
since
I only run Windows at home.

My apologies if this is common knowledge.

Thank you,
Jeff

-----Original Message-----
From: Jonathan A. Solomon [mailto:[email protected]]=20
Sent: Monday, January 30, 2006 5:49 PM
To: [email protected]
Subject: tops-20 under KLH-10...

I have been experiencing a small problem with the TOPS-20's that
are run through KLH-10 under UNIX (linux)....

It also affects ITS from sv.svensson.org.

What happens is outgoing and incoming TCP/IP connections hang
and cannot be reinstated without booting the unix system and
then boot TOPS-20 and ITS.

When you run KLH-10 under Microsoft, the problem doesn't
exist. Dave Kompel's machine was run under Microsoft,
before his house was burnt to the ground, killing off
the hosts.

TWENEX.ORG and SV.SVENSSON.ORG are run under unix.=20
Both of these systems demonstrate some problems with
TCP/IP connections hang, and you have to reboot.

just thought you'd like to know.

--jsol

31-Jan-2006 06:31:28-PST,2496;000000000000
Return-Path: <[email protected]>
Received: from mail.math.utah.edu ([155.101.98.135]) by lingling.panda.com with TCP/SMTP; Tue, 31 Jan 2006 06:24:57 -0800 (PST)
Received: from psi.math.utah.edu (psi.math.utah.edu [155.101.96.19])
by mail.math.utah.edu (8.13.4/8.13.4) with ESMTP id k0VEHKHO029433;
Tue, 31 Jan 2006 07:17:20 -0700 (MST)
Received: from psi.math.utah.edu (localhost [127.0.0.1])
by psi.math.utah.edu (8.13.4/8.13.4) with ESMTP id k0VEHK0B022025;
Tue, 31 Jan 2006 07:17:20 -0700 (MST)
Received: (from beebe@localhost)
by psi.math.utah.edu (8.13.4/8.13.4/Submit) id k0VEHKIa022024;
Tue, 31 Jan 2006 07:17:20 -0700 (MST)
Date: Tue, 31 Jan 2006 07:17:20 -0700 (MST)
From: "Nelson H. F. Beebe" <[email protected]>
To: Stephen Jones <[email protected]>, [email protected]
Cc: [email protected]
X-US-Mail: "Department of Mathematics, 110 LCB, University of Utah, 155 S
1400 E RM 233, Salt Lake City, UT 84112-0090, USA"
X-Telephone: +1 801 581 5254
X-FAX: +1 801 585 1640, +1 801 581 4148
X-URL: http://www.math.utah.edu/~beebe
Subject: Re: twenex.org new account stats
In-Reply-To: Your message of Mon, 30 Jan 2006 17:02:21 -0800
Message-ID: <[email protected]>
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0 (mail.math.utah.edu [155.101.98.135]); Tue, 31 Jan 2006 07:17:20 -0700 (MST)

Stephen Jones <[email protected]> notes the drop in logins on twenex.org
from 2003 to 2005, and comments

>> People create logins for different reasons and I would gather that
>> TOPS-20 access is probably not high on that list of reasons, which
>> is sad.

Another strong reason, I think, is that more of us are running KLH10
on our local hardware, with a PDP-10 O/S on top. I have a window open
on a TOPS-20 system at all times, and carried a (virtual) PDP-10 and
RP07 in my pocket to a conference in China last August.

-------------------------------------------------------------------------------
- Nelson H. F. Beebe Tel: +1 801 581 5254 -
- University of Utah FAX: +1 801 581 4148 -
- Department of Mathematics, 110 LCB Internet e-mail: [email protected] -
- 155 S 1400 E RM 233 [email protected] [email protected] -
- Salt Lake City, UT 84112-0090, USA URL: http://www.math.utah.edu/~beebe/ -
-------------------------------------------------------------------------------
31-Jan-2006 08:32:50-PST,2541;000000000000
Return-Path: <[email protected]>
Received: from mxout4.cac.washington.edu ([140.142.33.19]) by lingling.panda.com with TCP/SMTP; Tue, 31 Jan 2006 08:27:25 -0800 (PST)
Received: from smtp.washington.edu (smtp.washington.edu [140.142.32.139])
by mxout4.cac.washington.edu (8.13.5+UW05.10/8.13.5+UW05.09) with ESMTP id k0VGRIUD023885
(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
Tue, 31 Jan 2006 08:27:18 -0800
X-Auth-Received: from pangtzu.panda.com (pangtzu.panda.com [206.124.149.117])
(authenticated authid=mrc)
by smtp.washington.edu (8.13.5+UW05.10/8.13.5+UW05.09) with ESMTP id k0VGRHvK021661
(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT);
Tue, 31 Jan 2006 08:27:18 -0800
Date: Tue, 31 Jan 2006 08:27:17 -0800 (PST)
From: Mark Crispin <[email protected]>
Sender: [email protected]
To: "Jones, Jeffrey A (JAJ)" <[email protected]>
cc: [email protected]
Subject: Re: KLH10 on Windows
In-Reply-To: <[email protected]>
Message-ID: <[email protected]>
References: <[email protected]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
X-Uwash-Spam: Gauge=IIIIIII, Probability=7%, Report='__CT 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0'

On Tue, 31 Jan 2006, Jones, Jeffrey A (JAJ) wrote:
> Does Jsol's comment "When you run KLH-10 under Microsoft" mean that KLH10 can
> run directly under a Windows OS (namely Windows XP)? By the word 'directly',
> I mean running KLH10 as a Windows application.

Not that I know. I ported a very old version of KS10-only klh10 to
Windows and Mac OS 7.5 years ago, but that port was an ugly kludge and
nothing in there is usable for modern klh10.

If someone has ported modern klh10 to Windows XP, they ought to share it
with the rest of the community.

> I was always under the
> impression that a Windows system would need to run virtual machine software
> (i.e. vmware) with a Unix virtual machine that runs KLH10 running TOPS-20.

That's how I run TOPS-20 on my laptop: TOPS-20 over klh10 over Linux over
vmware over Windows XP. It's still quite a bit faster than a KL10 (you
get about 1 KL equivalent for each 100 MHz).

-- Mark --

http://panda.com/mrc
Democracy is two wolves and a sheep deciding what to eat for lunch.
Liberty is a well-armed sheep contesting the vote.
31-Jan-2006 08:44:58-PST,2382;000000000000
Return-Path: <[email protected]>
Received: from mxout3.cac.washington.edu ([140.142.32.166]) by lingling.panda.com with TCP/SMTP; Tue, 31 Jan 2006 08:39:54 -0800 (PST)
Received: from smtp.washington.edu (smtp.washington.edu [140.142.33.9])
by mxout3.cac.washington.edu (8.13.5+UW05.10/8.13.5+UW05.09) with ESMTP id k0VGda38005207
(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
Tue, 31 Jan 2006 08:39:37 -0800
X-Auth-Received: from pangtzu.panda.com (pangtzu.panda.com [206.124.149.117])
(authenticated authid=mrc)
by smtp.washington.edu (8.13.5+UW05.10/8.13.5+UW05.09) with ESMTP id k0VGdZ2a008081
(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT);
Tue, 31 Jan 2006 08:39:36 -0800
Date: Tue, 31 Jan 2006 08:39:35 -0800 (PST)
From: Mark Crispin <[email protected]>
Sender: [email protected]
To: Bjorn Victor <[email protected]>
cc: "Jonathan A. Solomon" <[email protected]>, [email protected]
Subject: Re: tops-20 under KLH-10...
In-Reply-To: <[email protected]>
Message-ID: <[email protected]>
References: <[email protected]>
<[email protected]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
X-Uwash-Spam: Gauge=IIIIIII, Probability=7%, Report='__CT 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0'

On Tue, 31 Jan 2006, Bjorn Victor wrote:
> I don't understand precisely what you mean by this description; I've
> never seen anything like this on my TOPS-20 or ITS systems.

I agree.

> What I
> have seen is TOPS-20 running out of NVTs, and ITS running out of
> network connections, because of FTP/Telnet script kiddie attacks.

Panda monitors boost the number of TVTs and TCBs. The default from DEC is
much too small.

Most of my network traffic is incoming script kiddie attacks these days.
Much of it goes into a black hole on my router. The logs of what does get
through are amusing.

> But I've never had to reboot the host (Linux/Solaris) systems because
> of this.

I agree, and the claim that such is needed makes no sense to me.

-- Mark --

http://panda.com/mrc
Democracy is two wolves and a sheep deciding what to eat for lunch.
Liberty is a well-armed sheep contesting the vote.
31-Jan-2006 12:38:07-PST,2092;000000000000
Return-Path: <[email protected]>
Received: from mail1.panix.com ([166.84.1.72]) by lingling.panda.com with TCP/SMTP; Tue, 31 Jan 2006 12:31:55 -0800 (PST)
Received: from panix5.panix.com (panix5.panix.com [166.84.1.5])
by mail1.panix.com (Postfix) with ESMTP id 44C275888F;
Tue, 31 Jan 2006 15:31:37 -0500 (EST)
Received: (from alderson@localhost)
by panix5.panix.com (8.11.6p3/8.8.8/PanixN1.1) id k0VKVak24292;
Tue, 31 Jan 2006 15:31:36 -0500 (EST)
Date: Tue, 31 Jan 2006 15:31:36 -0500 (EST)
Message-Id: <[email protected]>
From: Rich Alderson <[email protected]>
To: [email protected]
CC: [email protected], [email protected]
In-reply-to: <[email protected]> (message
from Mark Crispin on Tue, 31 Jan 2006 08:27:17 -0800 (PST))
Subject: Re: KLH10 on Windows
References: <[email protected]>
<[email protected]>

> Date: Tue, 31 Jan 2006 08:27:17 -0800 (PST)
> From: Mark Crispin <[email protected]>

> On Tue, 31 Jan 2006, Jones, Jeffrey A (JAJ) wrote:

>> Does Jsol's comment "When you run KLH-10 under Microsoft" mean that KLH10
>> can run directly under a Windows OS (namely Windows XP)? By the word
>> 'directly', I mean running KLH10 as a Windows application.

> Not that I know. I ported a very old version of KS10-only klh10 to Windows
> and Mac OS 7.5 years ago, but that port was an ugly kludge and nothing in
> there is usable for modern klh10.

> If someone has ported modern klh10 to Windows XP, they ought to share it with
> the rest of the community.

I talked to Ken about what would be needed for a Windows XP port in the last
couple of years, when I was looking for KL-specific tools to help in the
restoration of the PDPplanet 2065 and 1090. To the best of his knowledge, no
one had done it yet at the time; it doesn't sound as though anyone has taken
it on since then.

Rich
31-Jan-2006 13:15:37-PST,2051;000000000000
Return-Path: <[email protected]>
Received: from sdf.lonestar.org (mx.freeshell.ORG [192.94.73.21]) by lingling.panda.com with TCP/SMTP; Tue, 31 Jan 2006 13:10:02 -0800 (PST)
Received: from [10.0.0.3] (dsl254-015-081.sea1.dsl.speakeasy.net [216.254.15.81])
(authenticated (0 bits))
by sdf.lonestar.org (8.13.1/8.12.10) with ESMTP id k0VL9jh0007341;
Tue, 31 Jan 2006 21:09:46 GMT
In-Reply-To: <[email protected]>
References: <[email protected]>
Mime-Version: 1.0 (Apple Message framework v746.2)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <[email protected]>
Cc: [email protected]
Content-Transfer-Encoding: 7bit
From: Stephen Jones <[email protected]>
Subject: Re: twenex.org new account stats
Date: Tue, 31 Jan 2006 13:09:52 -0800
To: "Nelson H. F. Beebe" <[email protected]>
X-Mailer: Apple Mail (2.746.2)

On Jan 31, 2006, at 6:17 AM, Nelson H. F. Beebe wrote:

> Stephen Jones <[email protected]> notes the drop in logins on twenex.org
> from 2003 to 2005, and comments
>
>>> People create logins for different reasons and I would gather that
>>> TOPS-20 access is probably not high on that list of reasons, which
>>> is sad.
>
> Another strong reason, I think, is that more of us are running KLH10
> on our local hardware, with a PDP-10 O/S on top. I have a window open
> on a TOPS-20 system at all times, and carried a (virtual) PDP-10 and
> RP07 in my pocket to a conference in China last August.

No, that is the weak reason. I was referring to a very different
reason. So, the reason why people create accounts on twenex.org is
that they believe that they can run a 'free IRC bot'. When I first
discovered this a few years ago I went along with it saying that
anyone who could write their own bot could run it. So far there have
been two people who wrote IRC clients that ran, but didn't do
anything. Its been far less entertaining than I hoped for. Thank god.
1-Feb-2006 10:08:56-PST,806;000000000000
Mail-From: MRC created at 1-Feb-2006 10:08:35
Date: Wed, 1 Feb 2006 10:08:35 -0800 (PST)
From: Mark Crispin <[email protected]>
Subject: TOPS-20 list temporarily moderated
To: [email protected]
Pithy-Thought: TOPS-20 was a great improvement over its successors
Message-ID: <[email protected]>
ReSent-Date: Wed, 1 Feb 2006 10:08:56 -0800 (PST)
ReSent-From: Mark Crispin <[email protected]>
ReSent-To: "TOPS-20 distribution": ;
ReSent-Message-ID: <[email protected]>

Another spam happened today, so I have temporarily put the TOPS-20 list
under moderation. I apologize again for the pollution in your mailbox.

Lingling's SMTP server now does HELO validation. If that proves to be
effective, I'll relax the moderation.
-------
1-Feb-2006 23:57:15-PST,3109;000000000000
Return-Path: <[email protected]>
Received: from pangtzu.panda.com ([206.124.149.117]) by lingling.panda.com with TCP/SMTP; Wed, 1 Feb 2006 23:51:26 -0800 (PST)
X-Return-Path: <[email protected]>
X-Received: from pangtzu.panda.com ([206.124.149.117]) by lingling.panda.com with TCP/SMTP; Wed, 1 Feb 2006 23:50:51 -0800 (PST)
Date: Wed, 1 Feb 2006 23:50:44 -0800 (PST)
From: Mark Crispin <[email protected]>
Sender: [email protected]
To: [email protected]
cc: TOPS-20 Hackers and Yackers <[email protected]>
Subject: Re: SSL and SSH support in TOPS-20
In-Reply-To: <[email protected]>
Message-ID: <[email protected]>
References: <[email protected]>
<[email protected]> <[email protected]>
<[email protected]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
ReSent-Date: Wed, 1 Feb 2006 23:51:13 -0800 (PST)
ReSent-From: TOPS-20 List Moderator <[email protected]>
ReSent-To: TOPS-20 Distribution: ;
ReSent-Subject: Re: SSL and SSH support in TOPS-20
ReSent-Message-ID: <[email protected]>

On Mon, 23 Jan 2006, [email protected] wrote:
> No, I have mistaken myself. I meant that it would have made sending
> 36 bit files to a VAX take less load on the PDP-10 CPU. But, you'd
> never want to send 36 bits to the VAX (would you?)

Wouldn't it be useful to have a BLT that converts from 8 36-bit words to 9
32-bit words and vice-versa? I can't help but thinking that TCP FTP
probably spends a lot of time doing that on a PDP-10 -> PDP-10 file
transfer.

Back in NCP days, we used the 36-bit mode of the IMP interface, but that
all seems to have gone out the windows with TCP.

> MOVSLJ works fine to send 7 bit ASCII to a VAX. You set a 7 bit
> source pointer and an 8 bit destination pointer, issue the EXTEND and
> you're done. Nice. I use this in ASCII mode on the extended FTP
> server.
> Of course, somebody still has to swap the bytes (see BLTBU, below)

I don't understand. Since this is ASCII text, the bytes should be in a
stream. If the target was a 32-bit file I would see the need to
byte-swap, but isn't the target 8-bit in this case (and thus the VAX does
the byte swapping)?

> I was thrilled to finally see PUSHI, PUSHM and POPM!

Yeah, but as has been pointed out to me the real value for these is
questionable.

> I'm surpised
> that nobody ever seems to have considered 'MOVSPB'. It's an obvious
> win: a completely generalize bit packing instruction.

How would you envision this working?

>> I got a copy of PDP-10 GCC but haven't even started looking at it.
> Is/will this available to the general hobbiest community? I have a
> number of things I'd like to port!

http://pdp-10.nocrew.org/gcc/

Let me know if you figure out how to do something useful with it.

-- Mark --

http://panda.com/tops-20
TOPS-20: a great improvement over its successors
2-Feb-2006 00:01:42-PST,1800;000000000000
Return-Path: <[email protected]>
Received: from pangtzu.panda.com ([206.124.149.117]) by lingling.panda.com with TCP/SMTP; Wed, 1 Feb 2006 23:52:46 -0800 (PST)
X-Return-Path: <[email protected]>
X-Received: from pangtzu.panda.com ([206.124.149.117]) by lingling.panda.com with TCP/SMTP; Wed, 1 Feb 2006 23:34:24 -0800 (PST)
Date: Wed, 1 Feb 2006 23:34:16 -0800 (PST)
From: Mark Crispin <[email protected]>
Sender: [email protected]
To: [email protected]
cc: TOPS-20 Hackers and Yackers <[email protected]>
Subject: Re: SSH/SSHD
In-Reply-To: <[email protected]>
Message-ID: <[email protected]>
References: "21 Jan 2006 21:28:13 -0800" <CMM.0.90.4.1138035612.billw@cypher>
<[email protected]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
ReSent-Date: Wed, 1 Feb 2006 23:52:36 -0800 (PST)
ReSent-From: TOPS-20 List Moderator <[email protected]>
ReSent-To: TOPS-20 Distribution: ;
ReSent-Subject: Re: SSH/SSHD
ReSent-Message-ID: <[email protected]>

On Mon, 23 Jan 2006, [email protected] wrote:
> Is routing fixed for KLH10?

This requires changing the MAC address. This may be feasible if klh10 has
a dedicated Ethernet interface, but I don't think that it would be if you
share the interface with the host system since the host system would have
to know about the new MAC address.

Once I realized this, I put the question aside. Although it would be easy
enough to add a second Ethernet interface for Lingling, the machine that
I'd want it to talk DECnet with only has one interface possible.

-- Mark --

http://panda.com/tops-20
TOPS-20: a great improvement over its successors
12-Feb-2006 21:35:55-PST,3260;000000000000
Return-Path: <[email protected]>
Received: from pangtzu.panda.com ([206.124.149.117]) by Lingling.Panda.COM with TCP/SMTP; Sun, 12 Feb 2006 21:31:19 -0800 (PST)
X-Return-Path: <[email protected]>
X-Received: from pangtzu.panda.com ([206.124.149.117]) by Lingling.Panda.COM with TCP/SMTP; Sun, 12 Feb 2006 21:30:54 -0800 (PST)
Date: Sun, 12 Feb 2006 22:30:42 -0800 (PST)
From: Mark Crispin <[email protected]>
Sender: [email protected]
To: TOPS-20 Hackers and Yackers <[email protected]>
Subject: Mark vs. DECnet
Message-ID: <[email protected]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
ReSent-Date: Sun, 12 Feb 2006 22:30:57 -0800 (PST)
ReSent-From: TOPS-20 List Moderator <[email protected]>
ReSent-To: TOPS-20 Distribution: ;
ReSent-Subject: Mark vs. DECnet
ReSent-Message-ID: <[email protected]>

Well, I got a second Ethernet interface for Meimei (the host processor for
Lingling) and tried to make it play the DECnet game. I got as far as
doing the following:

1) Changed the ni0 definition in my KLH10 configuration file (klt20.ini)
to:
devdef ni0 564 ni20 dedic=true ifc=eth1

2) Added the following to 7-1-CONFIG.CMD:
NODE PANDA 1.1
DECNET ROUTER-ENDNODE
ETHERNET 0 DECNET

3) Added the following to my OPR config file (SYSTEM.CMD):
WAIT 5
NCP SET CIRCUIT NI-0-0 SERVICE ENABLED
NCP SET CIRCUIT NI-0-0 STATE ON

4) Did battle with Linux to convince it to allow the change in MAC
address. It turns out that dpni20 won't work unless the interface is up,
but that by default Linux won't let you set the MAC address unless the
interface is down. After some colorful cursing, I made the startup file
set the MAC address to what DECnet was going to want prior to bringing
eth1 up.

That made dpni20 happy, and sure enough everybody agrees that Lingling's
MAC address is aa:00:04:00:01:04 which corresponds to a DECnet node number
of 1.1.

5) Wow, it seems that the circuit now comes up. Even better, Meimei can
now talk to Lingling, which it couldn't do when they were sharing an
interface.

Well, supposedly all I need to do is add "decnet=true" to the ni0
definition for the TOPS-20 machine running on my Mac, and do changes (2)
and (3). So I do that, only with a node number of 1.2 and a different
node name. Unlike Linux, Mac OS lets me change the MAC address with
little complaint.

So, now TOPS-20 is running on two systems, both with appropriate DECnet
MAC addresses, and the circuits are both up. Do they talk to each other?

Of course not!

Looking at the counters of the two circuits, I see that both systems show
that they are sending DECnet to the world, but are receiving nothing. I
suspect that the virtual machine running under MacOS isn't really
communicating DECnet. It may be the MacOS firewall.

I also am stunned by how truly horrible the NCP command interface in OPR
is. It looks like something that was ported from VMS.

Anyway, DECnet seems to have won this round, although I got a lot closer.

-- Mark --

http://panda.com/tops-20
TOPS-20: a great improvement over its successors
13-Feb-2006 09:53:04-PST,4844;000000000000
Return-Path: <[email protected]>
Received: from pangtzu.panda.com ([206.124.149.117]) by Lingling.Panda.COM with TCP/SMTP; Mon, 13 Feb 2006 09:48:32 -0800 (PST)
X-Return-Path: <[email protected]>
X-Received: from smtpout.mac.com ([17.250.248.87]) by Lingling.Panda.COM with TCP/SMTP; Mon, 13 Feb 2006 05:07:10 -0800 (PST)
X-Received: from mac.com (smtpin04-en2 [10.13.10.149])
by smtpout.mac.com (Xserve/8.12.11/smtpout05/MantshX 4.0) with ESMTP id k1DE6w8G013284;
Mon, 13 Feb 2006 06:06:58 -0800 (PST)
X-Received: from [192.168.1.51] (c-24-128-160-88.hsd1.nh.comcast.net [24.128.160.88])
(authenticated bits=0)
by mac.com (Xserve/smtpin04/MantshX 4.0) with ESMTP id k1DE6gaV024186;
Mon, 13 Feb 2006 06:06:52 -0800 (PST)
Mime-Version: 1.0
Message-Id: <p06230900c0164204c3ee@[192.168.1.51]>
In-Reply-To: <[email protected]>
References: <[email protected]>
Date: Mon, 13 Feb 2006 09:06:33 -0500
To: Mark Crispin <[email protected]>,
TOPS-20 Hackers and Yackers <[email protected]>
From: "John J. Francini" <[email protected]>
Subject: Re: Mark vs. DECnet
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
ReSent-Date: Mon, 13 Feb 2006 10:47:06 -0800 (PST)
ReSent-From: TOPS-20 List Moderator <[email protected]>
ReSent-To: TOPS-20 Distribution: ;
ReSent-Subject: Re: Mark vs. DECnet
ReSent-Message-ID: <[email protected]>

Congratulations on getting as far as you have. I'm hoping to do the
same thing soon, on the TOPS-10 side.

As to your comment on OPR's NCP command syntax, you're exactly right.
The VMS command syntax for NCP was indeed the model. After all, back
in those days, VMS was taking over the world, and we pretty much had
our hands tied as to how to do the syntax.

How little we knew...

John Francini

At 22:30 -0800 2/12/06, Mark Crispin wrote:
>Well, I got a second Ethernet interface for Meimei (the host
>processor for Lingling) and tried to make it play the DECnet game.
>I got as far as doing the following:
>
>1) Changed the ni0 definition in my KLH10 configuration file (klt20.ini) to:
> devdef ni0 564 ni20 dedic=true ifc=eth1
>
>2) Added the following to 7-1-CONFIG.CMD:
> NODE PANDA 1.1
> DECNET ROUTER-ENDNODE
> ETHERNET 0 DECNET
>
>3) Added the following to my OPR config file (SYSTEM.CMD):
> WAIT 5
> NCP SET CIRCUIT NI-0-0 SERVICE ENABLED
> NCP SET CIRCUIT NI-0-0 STATE ON
>
>4) Did battle with Linux to convince it to allow the change in MAC
>address. It turns out that dpni20 won't work unless the interface
>is up, but that by default Linux won't let you set the MAC address
>unless the interface is down. After some colorful cursing, I made
>the startup file set the MAC address to what DECnet was going to
>want prior to bringing eth1 up.
>
>That made dpni20 happy, and sure enough everybody agrees that
>Lingling's MAC address is aa:00:04:00:01:04 which corresponds to a
>DECnet node number of 1.1.
>
>5) Wow, it seems that the circuit now comes up. Even better, Meimei
>can now talk to Lingling, which it couldn't do when they were
>sharing an interface.
>
>
>Well, supposedly all I need to do is add "decnet=true" to the ni0
>definition for the TOPS-20 machine running on my Mac, and do changes
>(2) and (3). So I do that, only with a node number of 1.2 and a
>different node name. Unlike Linux, Mac OS lets me change the MAC
>address with little complaint.
>
>So, now TOPS-20 is running on two systems, both with appropriate
>DECnet MAC addresses, and the circuits are both up. Do they talk to
>each other?
>
>Of course not!
>
>Looking at the counters of the two circuits, I see that both systems
>show that they are sending DECnet to the world, but are receiving
>nothing. I suspect that the virtual machine running under MacOS
>isn't really communicating DECnet. It may be the MacOS firewall.
>
>I also am stunned by how truly horrible the NCP command interface in
>OPR is. It looks like something that was ported from VMS.
>
>Anyway, DECnet seems to have won this round, although I got a lot closer.
>
>-- Mark --
>
>http://panda.com/tops-20
>TOPS-20: a great improvement over its successors

--
----
John Francini <mailto:[email protected]>
+---------------------------------------------------------------------------+
| "I have come to the conclusion that one useless man is called a disgrace; |
| that two are called a law firm; and that three or more become a Congress.|
| And by God I have had _this_ Congress!" |
| -- John Adams |
+---------------------------------------------------------------------------+
13-Feb-2006 10:21:03-PST,2513;000000000000
Return-Path: <[email protected]>
Received: from pangtzu.panda.com ([206.124.149.117]) by Lingling.Panda.COM with TCP/SMTP; Mon, 13 Feb 2006 10:16:49 -0800 (PST)
X-Return-Path: <[email protected]>
X-Received: from pangtzu.panda.com ([206.124.149.117]) by Lingling.Panda.COM with TCP/SMTP; Mon, 13 Feb 2006 10:12:11 -0800 (PST)
Date: Mon, 13 Feb 2006 11:11:59 -0800 (PST)
From: Mark Crispin <[email protected]>
Sender: [email protected]
To: "John J. Francini" <[email protected]>
cc: TOPS-20 Hackers and Yackers <[email protected]>
Subject: Re: Mark vs. DECnet
In-Reply-To: <p06230900c0164204c3ee@[192.168.1.51]>
Message-ID: <[email protected]>
References: <[email protected]>
<p06230900c0164204c3ee@[192.168.1.51]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
ReSent-Date: Mon, 13 Feb 2006 11:16:34 -0800 (PST)
ReSent-From: TOPS-20 List Moderator <[email protected]>
ReSent-To: TOPS-20 Distribution: ;
ReSent-Subject: Re: Mark vs. DECnet
ReSent-Message-ID: <[email protected]>

On Mon, 13 Feb 2006, John J. Francini wrote:
> Congratulations on getting as far as you have. I'm hoping to do the
> same thing soon, on the TOPS-10 side.

Yeah, well, at least now I understand what needs to be done to get the NI
configured. Finding that "ETHERNET 0 DECNET" incantation in SETSPD was a
major breakthrough.

> As to your comment on OPR's NCP command syntax, you're exactly right.
> The VMS command syntax for NCP was indeed the model. After all, back
> in those days, VMS was taking over the world, and we pretty much had
> our hands tied as to how to do the syntax.
> How little we knew...

Indeed. Two things are objectionable about NCP's command syntax.

The first are the incredible number of silly state commands (that is,
commands which are syntactically valid but meaningless). This makes it
impossible to figure one's way around by use of "?" to go through all the
menus; half of what menu exploration leads you is to a silly state.

The second are utterly worthless error messages such as "Set Circuit
Failed, Operation failure". I'm not asking for touchy-feely novice
messages, but at least something that says what went wrong ("Circuit
NI-0-0 not initialized for DECnet" would have been better).

-- Mark --

http://panda.com/tops-20
TOPS-20: a great improvement over its successors
13-Feb-2006 11:07:49-PST,3572;000000000000
Return-Path: <[email protected]>
Received: from pangtzu.panda.com ([206.124.149.117]) by Lingling.Panda.COM with TCP/SMTP; Mon, 13 Feb 2006 11:03:25 -0800 (PST)
X-Return-Path: <[email protected]>
X-Received: from smtpout.mac.com ([17.250.248.71]) by Lingling.Panda.COM with TCP/SMTP; Mon, 13 Feb 2006 10:49:41 -0800 (PST)
X-Received: from mac.com (smtpin03-en2 [10.13.10.148])
by smtpout.mac.com (Xserve/8.12.11/smtpout14/MantshX 4.0) with ESMTP id k1DJnS0I020865;
Mon, 13 Feb 2006 11:49:28 -0800 (PST)
X-Received: from [10.68.5.13] ([12.45.253.10])
(authenticated bits=0)
by mac.com (Xserve/smtpin03/MantshX 4.0) with ESMTP id k1DJnMdE012267;
Mon, 13 Feb 2006 11:49:28 -0800 (PST)
In-Reply-To: <[email protected]>
References: <[email protected]> <p06230900c0164204c3ee@[192.168.1.51]> <[email protected]>
Mime-Version: 1.0 (Apple Message framework v746.2)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <[email protected]>
Cc: TOPS-20 Hackers and Yackers <[email protected]>
Content-Transfer-Encoding: 7bit
From: John Francini <[email protected]>
Subject: Re: Mark vs. DECnet
Date: Mon, 13 Feb 2006 14:50:59 -0500
To: Mark Crispin <[email protected]>
X-Mailer: Apple Mail (2.746.2)
ReSent-Date: Mon, 13 Feb 2006 12:03:11 -0800 (PST)
ReSent-From: TOPS-20 List Moderator <[email protected]>
ReSent-To: TOPS-20 Distribution: ;
ReSent-Subject: Re: Mark vs. DECnet
ReSent-Message-ID: <[email protected]>

Well, not only was the command syntax defined by the standard, but
the error messages were as well. NCP commands on VMS, Digital UNIX,
and TOPS (and probably on RSX-11M+ and RSTS/E as well) used the same
syntax and generated the same kinds of error messages.

Hence the all the state commands. And also the difference between
SET and DEFINE. (On VMS, SET changed the running DECnet incarnation;
DEFINE changed the on-disk database.)

On 13 Feb 2006, at 14:11, Mark Crispin wrote:

> On Mon, 13 Feb 2006, John J. Francini wrote:
>> Congratulations on getting as far as you have. I'm hoping to do the
>> same thing soon, on the TOPS-10 side.
>
> Yeah, well, at least now I understand what needs to be done to get
> the NI configured. Finding that "ETHERNET 0 DECNET" incantation in
> SETSPD was a major breakthrough.
>
>> As to your comment on OPR's NCP command syntax, you're exactly right.
>> The VMS command syntax for NCP was indeed the model. After all, back
>> in those days, VMS was taking over the world, and we pretty much had
>> our hands tied as to how to do the syntax.
>> How little we knew...
>
> Indeed. Two things are objectionable about NCP's command syntax.
>
> The first are the incredible number of silly state commands (that
> is, commands which are syntactically valid but meaningless). This
> makes it impossible to figure one's way around by use of "?" to go
> through all the menus; half of what menu exploration leads you is
> to a silly state.
>
> The second are utterly worthless error messages such as "Set
> Circuit Failed, Operation failure". I'm not asking for touchy-
> feely novice messages, but at least something that says what went
> wrong ("Circuit NI-0-0 not initialized for DECnet" would have been
> better).
>
> -- Mark --
>
> http://panda.com/tops-20
> TOPS-20: a great improvement over its successors

20-Feb-2006 19:42:35-PST,3011;000000000000
Return-Path: <[email protected]>
Received: from pangtzu.panda.com ([206.124.149.117]) by lingling.panda.com with TCP/SMTP; Mon, 20 Feb 2006 19:40:49 -0800 (PST)
X-Return-Path: <[email protected]>
X-Received: from aun.it.uu.se ([130.238.12.36]) by lingling.panda.com with TCP/SMTP; Mon, 20 Feb 2006 02:08:15 -0800 (PST)
X-Received: from Nomen.it.uu.se (h211n5c1o851.bredband.skanova.com [81.225.36.211])
(authenticated bits=0)
by aun.it.uu.se (8.13.3/8.13.3) with ESMTP id k1KA7xgp015903
(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
Mon, 20 Feb 2006 11:08:00 +0100 (MET)
X-Received: by Nomen.it.uu.se (Postfix, from userid 1020)
id 6A72318770; Mon, 20 Feb 2006 11:07:55 +0100 (CET)
From: Bjorn Victor <[email protected]>
To: Mark Crispin <[email protected]>
Cc: TOPS-20 Hackers and Yackers <[email protected]>
Subject: Re: Mark vs. DECnet
References: <[email protected]>
Date: Mon, 20 Feb 2006 11:07:54 +0100
In-Reply-To: <[email protected]> (Mark
Crispin's message of "Sun, 12 Feb 2006 22:30:42 -0800 (PST)")
Message-ID: <[email protected]>
User-Agent: Gnus/5.110004 (No Gnus v0.4) XEmacs/21.4.18 (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 aun.it.uu.se id k1KA7xgp015903
ReSent-Date: Mon, 20 Feb 2006 18:58:09 -0800 (PST)
ReSent-From: TOPS-20 List Moderator <[email protected]>
ReSent-To: TOPS-20 Distribution: ;
ReSent-Subject: Re: Mark vs. DECnet
ReSent-Message-ID: <[email protected]>

On Sun, 12 Feb 2006 22:30:42 -0800 (PST) MRC wrote:

> 4) Did battle with Linux to convince it to allow the change in MAC=20
> address. It turns out that dpni20 won't work unless the interface is u=
p,=20
> but that by default Linux won't let you set the MAC address unless the=20
> interface is down. After some colorful cursing, I made the startup fil=
e=20
> set the MAC address to what DECnet was going to want prior to bringing=20
> eth1 up.

Hmm, you don't know if it's possible to do something with this effect
(sending/receiving at a DECnet MAC address) without a dedicated
interface, do you? I'd imagine promiscuous mode and "manual"
filtering would work, but that's a lot of overhead...

We have some other DECnet machines (VAX, PDP-11, whatnot) running
which would like to talk to TINA. Since most of them are emulated
these days (no money for electricity and cooling of the real iron -
soon no ROOM for the real iron), I guess one option would be the UDP
tunneling trick (which I used for Chaosnet), letting the emulator
pack/unpack DECnet packets separately from ARP/IP. Uh, but probably
all packets would have to have their Ethernet addresses changed
anyway, since TOPS-20 uses the same DECnet MAC for all packets, right?
Urk.

Ideas?

-- Bj=F6rn
20-Feb-2006 20:22:48-PST,1718;000000000000
Return-Path: <[email protected]>
Received: from pangtzu.panda.com ([206.124.149.117]) by lingling.panda.com with TCP/SMTP; Mon, 20 Feb 2006 20:21:23 -0800 (PST)
X-Return-Path: <[email protected]>
X-Received: from pangtzu.panda.com ([206.124.149.117]) by lingling.panda.com with TCP/SMTP; Mon, 20 Feb 2006 19:56:01 -0800 (PST)
Date: Mon, 20 Feb 2006 19:55:55 -0800 (PST)
From: Mark Crispin <[email protected]>
Sender: [email protected]
To: Bjorn Victor <[email protected]>
cc: TOPS-20 Hackers and Yackers <[email protected]>
Subject: Re: Mark vs. DECnet
In-Reply-To: <[email protected]>
Message-ID: <[email protected]>
References: <[email protected]>
<[email protected]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
ReSent-Date: Mon, 20 Feb 2006 20:21:13 -0800 (PST)
ReSent-From: TOPS-20 List Moderator <[email protected]>
ReSent-To: TOPS-20 Distribution: ;
ReSent-Subject: Re: Mark vs. DECnet
ReSent-Message-ID: <[email protected]>

On Mon, 20 Feb 2006, Bjorn Victor wrote:
> Hmm, you don't know if it's possible to do something with this effect
> (sending/receiving at a DECnet MAC address) without a dedicated
> interface, do you?

Yes, read klh10[*]/docs/install.txt. The option is decnet=true.

I tried it on my Mac, and while it did change the MAC address (and
confused the hell out of the Mac OS X end!) I still couldn't get DECnet to
flow between it and my machine with the dedicated interface.

-- Mark --

http://panda.com/tops-20
TOPS-20: a great improvement over its successors
5-Mar-2006 18:30:47-PST,2112;000000000000
Return-Path: <[email protected]>
Received: from pangtzu.panda.com ([206.124.149.117]) by lingling.panda.com with TCP/SMTP; Sun, 5 Mar 2006 18:28:11 -0800 (PST)
X-Return-Path: <[email protected]>
X-Received: from pangtzu.panda.com ([206.124.149.117]) by lingling.panda.com with TCP/SMTP; Sun, 5 Mar 2006 18:26:26 -0800 (PST)
Date: Sun, 5 Mar 2006 18:26:21 -0800 (PST)
From: Mark Crispin <[email protected]>
Sender: [email protected]
To: TOPS-20 Hackers and Yackers <[email protected]>
Subject: CRITICAL bugfix/patch to Panda monitor
Message-ID: <[email protected]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
ReSent-Date: Sun, 5 Mar 2006 18:28:00 -0800 (PST)
ReSent-From: TOPS-20 List Moderator <[email protected]>
ReSent-To: TOPS-20 Distribution: ;
ReSent-Subject: CRITICAL bugfix/patch to Panda monitor
ReSent-Message-ID: <[email protected]>

A bug has been discovered in the Panda monitor that allows a malicious
user to crash the system (typically an ILMNRF bughlt). This bug also
causes crashes with routine operation on systems with timezones other than
those in North America or GMT.

This is a Panda-only problem; it does not apply to unmodified DEC
monitors, nor (AFAIK) to XKL monitors.

Patch instructions:
!get system:monitr.EXE.1
!stART (PROGRAM) 140
DDT
$w (NOTE: this is ESC w, not dollar W)
6,,ott5+42/ CALL LJNTMA#+60 call @fff
fff/ 0 1,,bouta
FFF+1/ 0 fff:
^Z
!saVE (on file) system:monitr.EXE.2 !New generation! (PAGES FROM)
<SYSTEM>MONITR.EXE.2 Saved
!

If you want to patch a live monitor:
!mddt
MDDT

fff/ 0 1,,bouta
$w 6,,ott5+42/ CALL LJNTMA#+60 call @fff
fff/ T1,,BOUTA
6,,FFF+1/ 0 fff:
^Z
!

Source code patch:

In <MONITOR-SOURCES>DATIME.MAC, in routine OTT5 plus 45 lines, there is a
CALL BOUTA
that should be
CALLX (MSEC1,BOUTA)

-- Mark --

http://panda.com/tops-20
TOPS-20: a great improvement over its successors
5-Mar-2006 19:06:31-PST,1019;000000000000
Return-Path: <[email protected]>
Received: from pangtzu.panda.com ([206.124.149.117]) by lingling.panda.com with TCP/SMTP; Sun, 5 Mar 2006 19:05:05 -0800 (PST)
Mail-From: MRC created at 5-Mar-2006 19:00:42
Date: Sun, 5 Mar 2006 19:00:42 -0800 (PST)
From: Mark Crispin <[email protected]>
Subject: passive mode in TOPS-20 FTP client
To: [email protected]
Pithy-Thought: TOPS-20 was a great improvement over its successors
Message-ID: <[email protected]>
ReSent-Date: Sun, 5 Mar 2006 19:04:55 -0800 (PST)
ReSent-From: TOPS-20 List Moderator <[email protected]>
ReSent-To: TOPS-20 Distribution: ;
ReSent-Subject: passive mode in TOPS-20 FTP client
ReSent-Message-ID: <[email protected]>

I know that we all have copious amounts of free time (ha!), but a worthwhile
project for someone to undertake would be to implement passive mode in the
TOPS-20 FTP client. It would make FTP work much better when NAT is involved!
-------
16-Mar-2006 12:36:39-PST,584;000000000000
Mail-From: MRC created at 16-Mar-2006 12:35:11
Date: Thu, 16 Mar 2006 12:35:11 -0800 (PST)
From: Mark Crispin <[email protected]>
Subject: TOPS-20 mailing list is direct-delivery again
To: [email protected]
Pithy-Thought: TOPS-20 was a great improvement over its successors
Message-ID: <[email protected]>

Since it appears that the latest set of anti-spam measures has been effective
against the spammers that hit the list in January, I have switched off list
moderation. Mail to the TOPS-20 list is once again direct-delivery.
-------
8-Apr-2006 13:44:02-PDT,2012;000000000000
Return-Path: <[email protected]>
Received: from mta2.srv.hcvlny.cv.net ([167.206.4.197]) by lingling.panda.com with TCP/SMTP; Sat, 8 Apr 2006 13:42:07 -0700 (PDT)
Received: from optonline.net (hamstr3.srv.hcvlny.cv.net [167.206.5.10])
by mta2.srv.hcvlny.cv.net
(Sun Java System Messaging Server 6.2-4.03 (built Sep 22 2005))
with ESMTP id <[email protected]> for
[email protected]; Sat, 08 Apr 2006 16:42:01 -0400 (EDT)
Received: from [10.240.3.198] (Forwarded-For: [10.240.3.198])
by mstr3.srv.hcvlny.cv.net (mshttpd); Sat, 08 Apr 2006 20:42:00 +0000 (GMT)
Date: Sat, 08 Apr 2006 20:42:00 +0000 (GMT)
From: [email protected]
Subject: Control-T breaks when using DEBUG on XKL system
In-reply-to: <[email protected]>
To: [email protected]
Message-id: <[email protected]>
MIME-version: 1.0
X-Mailer: Sun Java(tm) System Messenger Express 6.2-4.03 (built Sep 22 2005)
Content-type: text/plain; charset=us-ascii
Content-language: en
Content-transfer-encoding: 7BIT
Content-disposition: inline
X-Accept-Language: en
Priority: normal
References: <[email protected]>

I don't have a lot of information about this, but I just bumped into it
and thought I'd write it up before I forgot about it. Has anybody else
noticed the problem?

Symptom:

When using the DEBUG command under XKL TOPS-20 Monitor 7(102400)-1
with EXEC 7(4168)-1, a program in section 0 will generate an EXEC
error for a Control-T.

Sample Program:

TITLE TBUG - Control-T Debug Bug
Subttl Thomas DeBellis, 1:30pm Saturday, 8 April 2006

SEARCH MONSYM

TBUG: RESET%
HALTF%
JRST TBUG

END 1,,TBUG

Example:

@debug tbug
MACRO: TBUG
LINK: Loading
[LNKDEB DDT execution]
DDT
13:31:42 TBUG IO wait at 37,,
?Internal illegal instruction at 72164 - Invalid section number
@

Work Around:

Use LOAD instead and then do a DDT. The problem does not occur on a
(my) PANDA system.

8-Apr-2006 15:23:26-PDT,3930;000000000000
Return-Path: <[email protected]>
Received: from mta9.srv.hcvlny.cv.net ([167.206.4.204]) by lingling.panda.com with TCP/SMTP; Sat, 8 Apr 2006 15:21:32 -0700 (PDT)
Received: from optonline.net (hamstr3.srv.hcvlny.cv.net [167.206.5.10])
by mta9.srv.hcvlny.cv.net
(Sun Java System Messaging Server 6.2-4.03 (built Sep 22 2005))
with ESMTP id <[email protected]> for
[email protected]; Sat, 08 Apr 2006 18:21:24 -0400 (EDT)
Received: from [10.240.3.198] (Forwarded-For: [10.240.3.198])
by mstr3.srv.hcvlny.cv.net (mshttpd); Sat, 08 Apr 2006 22:21:24 +0000 (GMT)
Date: Sat, 08 Apr 2006 22:21:24 +0000 (GMT)
From: [email protected]
Subject: Section space discovery
In-reply-to: <[email protected]>
To: [email protected]
Message-id: <[email protected]>
MIME-version: 1.0
X-Mailer: Sun Java(tm) System Messenger Express 6.2-4.03 (built Sep 22 2005)
Content-type: text/plain; charset=us-ascii
Content-language: en
Content-transfer-encoding: 7BIT
Content-disposition: inline
X-Accept-Language: en
Priority: normal
References: <[email protected]>
<[email protected]>

I've finished writing the FTP server STOR code for TYPE I transfers
and am in the process of debugging it. Once this is done, all I have
to do is finish paged file structures (STRU P) and I should have a
release candidate.

I ran across a problem in one of my page management routines and in
the process of correcting it, I came up with a number of questions
about address space usage. The memory management code is architected
to handle buffers that span multiple sections. However as currently
implemented, a buffer is limited to a maximum of 512 pages. At some
point after I have a stable release in the field, I will probably want
to revisit the code to rework some of the grosser hacks.

My intention is to spend some time finishing the multiple section
buffer code for two reasons: first, just to do it and second to see at
what point throwing memory at the FTP server slows down transfer
speeds or otherwise adversely effects the system. Thus far, my
results have been that increasing the buffer size on a lightly loaded
system consistently yields faster transfers. Since I am using
gnuEmacs' ange-ftp mode to review huge CREF listings, I obviously want
as fast transfers as I can get.

How do I efficiently find out how many sections I can get? I'd rather
not do anything iterative with SMAP% (like a binary section create
search) to discover this. One approach might be to have a subroutine
that discovers the processor type and then look up the implemented
sections for that processor. This should work with KL and KLH
hardware. Does anybody have code that does this?

I'm not sure I understand what the limits on the XKL Toad are. My
understanding is that it implements the entire 30 bit address space,
so I should be able to to get something like 4095 sections (SYSREF
says that section 7777 is reserved to trap to the monitor). But,
doing a @DDT /O /U 1000 on a Toad got me an "?Invalid Section Number".
What is the story, here?

Also, Mark has talked about doing a 27 bit (XKLH? XKLM? :-) processor
implementation. I'd love to see this happen. That's a 128 Megaword
machine or roughly half an Internet gigabyte--a completely reasonable
Tops-20 environment. However... How would I find out the address
space there?

Also, some questions arise about file mapping. What is the most
efficient way to get a file into a section based buffer? I currently
create a private section and then use PMAP% with FH%EPN and PM%CNT to
map the file. I forgot to create the section one day and found out
that PMAP% will create this on the fly for you. A brief look in JSYSA
at FRKMP2 appears to validate this. Or should I use SMAP%? Or does
it even matter?
8-Apr-2006 20:10:59-PDT,1230;000000000000
Return-Path: <[email protected]>
Received: from pangtzu.panda.com ([206.124.149.117]) by lingling.panda.com with TCP/SMTP; Sat, 8 Apr 2006 20:09:08 -0700 (PDT)
Date: Sat, 8 Apr 2006 20:09:02 -0700 (PDT)
From: Mark Crispin <[email protected]>
Sender: [email protected]
To: [email protected]
cc: [email protected]
Subject: Re: Control-T breaks when using DEBUG on XKL system
In-Reply-To: <[email protected]>
Message-ID: <[email protected]>
References: <[email protected]> <[email protected]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed

On Sat, 8 Apr 2006, [email protected] wrote:
> When using the DEBUG command under XKL TOPS-20 Monitor 7(102400)-1
> with EXEC 7(4168)-1, a program in section 0 will generate an EXEC
> error for a Control-T.

It happens on Panda systems too.

It seems to happen when using XKL's LINK, which uses SYS:DDT.REL (which
should be just UDDT.REL). It doesn't happen if you use the DEC LINK.

It's not just CTRL/T. I MEM is also broken.

-- Mark --

http://panda.com/tops-20
TOPS-20: a great improvement over its successors
8-Apr-2006 21:10:56-PDT,1821;000000000000
Return-Path: <[email protected]>
Received: from pangtzu.panda.com ([206.124.149.117]) by lingling.panda.com with TCP/SMTP; Sat, 8 Apr 2006 21:09:24 -0700 (PDT)
Date: Sat, 8 Apr 2006 21:09:16 -0700 (PDT)
From: Mark Crispin <[email protected]>
Sender: [email protected]
To: [email protected]
cc: [email protected]
Subject: Re: Section space discovery
In-Reply-To: <[email protected]>
Message-ID: <[email protected]>
References: <[email protected]> <[email protected]>
<[email protected]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed

My GETCPU.MAC subroutine will tell you what type of processor you are on
(well, not an SC, but that's only because I don't have access to an SC to
make the test).

I really do not think that a multi-section buffer is a good idea.
Certainly, you need a large enough buffer so that the transfer flows more
or less continuously. But...

A section is 1.25 megabytes. It takes about 10 seconds to transfer that
much on my 1.5M/896K DSL line. Most people have slower DSL (256K or
640K/256K) that would take closer to 40 seconds.

Transfers within a 100MB Ethernet will be faster, but I doubt very much
that TOPS-20/klh10 can drive the network that fast.

What I'm getting at is that a ring-buffer type setup would probably work
better. While I/O is happening on one buffer, change the map on the next.
Some empirical testing should come up with an ideal buffer size and number
of buffers.

Also, I don't think that the virtual memory space is as interesting as the
physical memory space.

-- Mark --

http://panda.com/tops-20
TOPS-20: a great improvement over its successors
10-Apr-2006 10:05:59-PDT,7080;000000000000
Return-Path: <[email protected]>
Received: from mta9.srv.hcvlny.cv.net ([167.206.4.204]) by lingling.panda.com with TCP/SMTP; Mon, 10 Apr 2006 10:04:02 -0700 (PDT)
Received: from optonline.net (hamstr3.srv.hcvlny.cv.net [167.206.5.10])
by mta9.srv.hcvlny.cv.net
(Sun Java System Messaging Server 6.2-4.03 (built Sep 22 2005))
with ESMTP id <[email protected]> for
[email protected]; Mon, 10 Apr 2006 13:03:56 -0400 (EDT)
Received: from [10.240.3.196] (Forwarded-For: [10.240.3.196])
by mstr3.srv.hcvlny.cv.net (mshttpd); Mon, 10 Apr 2006 17:03:56 +0000 (GMT)
Date: Mon, 10 Apr 2006 17:03:56 +0000 (GMT)
From: [email protected]
Subject: Re: Section space discovery
In-reply-to: <[email protected]>
To: [email protected]
Message-id: <[email protected]>
MIME-version: 1.0
X-Mailer: Sun Java(tm) System Messenger Express 6.2-4.03 (built Sep 22 2005)
Content-type: text/plain; charset=us-ascii
Content-language: en
Content-transfer-encoding: 7BIT
Content-disposition: inline
X-Accept-Language: en
Priority: normal
References: <[email protected]>
<[email protected]> <[email protected]>

> My GETCPU.MAC subroutine will tell you what type of processor you
> are on (well, not an SC, but that's only because I don't have access
> to an SC to make the test).

I downloaded a version that you posted on Usenet and modified it for
my use. For PDP-6, KA, KI and KS processors, I report an error. For
KL and KLH processors, I assume 32 sections. For a Toad, I assume 512
sections, the highest value I can SMAP% on the Toad that I have access
to (but isn't it supposed to be able to do 4095?). Do I need to care
about an SC? Does this do extended addressing? If you have an
updated version of GETCPU.MAC, could you please email that to me
offline?

> I really do not think that a multi-section buffer is a good idea.
> Certainly, you need a large enough buffer so that the transfer flows
> more or less continuously. But...

If multi-moby buffers adversely effect system performance for any
reason, then of course I shouldn't use them. On the other hand, for
an eight bit RETR transfer, I usually do one PMAP% and one SOUT%. I
don't take up paging space because the pages never get dirty. The
working set is linked to the speed of the transfer. It's hard to see
how I'm going to get more efficient than this or have lower Jsys
overhead.

As I increase the buffer size, I get better performance. The effect
thus far has been linear. I'm very interested in knowing what the
break even point is.

> A section is 1.25 megabytes. It takes about 10 seconds to transfer
> that much on my 1.5M/896K DSL line. Most people have slower DSL
> (256K or 640K/256K) that would take closer to 40 seconds.

Yes, that's you, today. If you are doing a moby every 10 seconds,
then your transfer speed is approximately 128 KB/s. Most DSL around
my neck of the woods is 1.6M /768K while most cable is 2M/1M. My
cable and DSL providers are having a speed war and I am now getting
sustained 30M/2M on cable (Optonline Boost). I expect the FIOS roll
out will provide similar speed on my phone line. I think it's
reasonable to assume an increase of media speed for the next few years
(but see below).

> Transfers within a 100MB Ethernet will be faster, but I doubt very
> much that TOPS-20/klh10 can drive the network that fast.

My primary (cable) backbone is gigabit and the secondary is 100 Mbps.
The current FTP server regularly transfers at 220 KB/s and I have
spiked 300 KB/s. If we assume that the maximum throughput for 100
Mbps media is 12,800 KB/s, then I am using a little over 2% of the
total possible bandwidth. I have other machines that will saturate
the 100 Mbps backbone, nothing that will saturate the gigabit
backbone.

> What I'm getting at is that a ring-buffer type setup would probably
> work better. While I/O is happening on one buffer, change the map on
> the next. Some empirical testing should come up with an ideal
> buffer size and number of buffers.

The moby buffer approach was my first cut at this. I went this way
for no other reason than it was easy (two Jsyi). The multi-moby
buffer approach may or may not be the second, depending on what I
discover in the field. If the speed of the host machine is limiting
things, then faster KLH engines should have higher transfer speeds. I
am also sharing a NIC with the host machine and perhaps this may
adversely effect transport.

I am, of course, considering some alternatives to the current design.
One such approach is to have a secondary 'scavenger' fork that
asynchronous unmaps pages as the primary data fork goes through them.
For example, when reading from the network (I.E., a STOR) for eight
bit files, the data fork PMAP%'s the output buffer directly to disk
and fills it, depending on DDMP to asynchronously begin flushing
things. The scavanger fork would determine which pages had been
filled and punt them to reduce data transfer fork working set size on
the fly.

Other alternatives, such as a multi-fork ring buffer system also
suggest themselves, but I'll want performance data to see where the
bottle necks are before I decide what to do. Everything is just too
speculative at this point. Another possibility is that 2.4 Mbps is
the maximum that a KLH-NI can do. If I am bumping into that limit,
then a lot of this may be moot, modulo system impact.

However, another thing I'm going to be looking to see will be how fast
I can drive a Toad interface. It may also be possible for me to test
on KL hardware at some point. My long term goal is to have the data
fork essentially be a seperate program that can be invoked by either
an EFTPSR command processor or a re-written Tops-20 FTP client. There
are two reasons for this.

First, if the Tops-20 FTP client can't drive the extended mode FTP
server at full speed, then I don't want to waste time figuring out how
to fix it. I'll just flush all of the data transfer stuff and hook
the stubs into the extended mode transfer fork. Second, a future
design goal may be to allow multiple simulaneous data transfers in
flight from the same control connections.

> Also, I don't think that the virtual memory space is as interesting
> as the physical memory space.

I'm not sure that I agree with what I think you're saying. I've found
a larger virtual memory space to be quite interesting. Even if you're
not going to use the physical memory, having a bigger option of where
to put stuff can make your life a lot easier.

Once you get enough bits, you can treat large swaths of memory as if
they were variable length segments. This can be quite flexible.
Having a lot of address space has made certain low level data base
applications that I wrote be much easier to code. On KLH, it has made
certain garbage collection routines simplier and easier to code.

10-Apr-2006 10:07:53-PDT,4288;000000000000
Return-Path: <[email protected]>
Received: from mta5.srv.hcvlny.cv.net ([167.206.4.200]) by lingling.panda.com with TCP/SMTP; Mon, 10 Apr 2006 10:06:26 -0700 (PDT)
Received: from optonline.net (hamstr3.srv.hcvlny.cv.net [167.206.5.10])
by mta5.srv.hcvlny.cv.net
(Sun Java System Messaging Server 6.2-4.03 (built Sep 22 2005))
with ESMTP id <[email protected]> for
[email protected]; Mon, 10 Apr 2006 13:06:20 -0400 (EDT)
Received: from [10.240.3.196] (Forwarded-For: [10.240.3.196])
by mstr3.srv.hcvlny.cv.net (mshttpd); Mon, 10 Apr 2006 17:06:20 +0000 (GMT)
Date: Mon, 10 Apr 2006 17:06:20 +0000 (GMT)
From: [email protected]
Subject: Toad JOV
In-reply-to: <[email protected]>
To: [email protected]
Message-id: <[email protected]>
MIME-version: 1.0
X-Mailer: Sun Java(tm) System Messenger Express 6.2-4.03 (built Sep 22 2005)
Content-type: text/plain; charset=us-ascii
Content-language: en
Content-transfer-encoding: 7BIT
Content-disposition: inline
X-Accept-Language: en
Priority: normal
References: <[email protected]>
<[email protected]> <[email protected]>

Consider the following code segment, below. I had a long list of
negative numbers and wanted to keep a running tally of the magnitude,
taking care to handle large numbers. My first code was to simply
negate and DADD. I noticed that most of the numbers weren't large
enough to cause a carry into the high order and wrote some code to do
it faster.

I supposed that a JFCL, SUBM, JFCL would be faster, on average than a
MOVN, SETZ, DADD, DMOVEM. Where I carried into the high order, it
would be slower, but this didn't happen often.

On a KL (Tops-10) and KLH (PANDA Tops-20), JOVST and DADDT are the
same: 0,,2 high order and 377777,,777776 low order. On a Toad, I get
a completely different result: 0,,1 high order and 0,,2 low order.
The difference is that the Toad is not taking the JOV. Ignoring for
the moment whether the approach is bogus, isn't the Toad supposed to
take the JOV because of overflow?

Can anybody check this out on other machines? KS? SIMH? I was just
wondering. For now, I'll just stick with the DADD ...

TITLE JOVT

SEARCH MONSYM,MACSYM ; The usual suspects
STDAC. ; The usual names

JOVT: RESET% ; Reset the world
JFCL 17,.+1 ; Clear all the flags

DMOVE T1,[EXP 1, .INFIN] ;Load 68,719,476,735
DMOVEM T1,DADDT ; Set Current total
DMOVEM T1,JOVST ; Ditto
MOVN P3,[.INFIN] ; Negative 34,359,738,367
; Normal positive running tally
MOVN T2,P3 ; Convert negative count to positive
SETZ T1, ; Cast character count to long
DADD T1,DADDT ; Tally total bytes done
DMOVEM T1,DADDT ; Update total
; Attempt to bum some code
JFCL 17,.+1 ; Clear all the flags
SUBM P3,JOVST+1 ; Accumulate total, checking wrap
JOV [ MOVN T1,JOVST+1 ; Re-sign the low order
TXZE T1,1B0 ; Test for carry into bit 0
AOS JOVST ; Propagate a carry into the high order
MOVEM T1,JOVST+1 ;Update total
JRST .+1 ] ; Rejoin

DMOVE T3,DADDT ; Load DADD tally
CAME T3,JOVST ; High order the same?
JRST NOSAME ; No!
CAME T4,JOVST+1 ; What about the low order?
JRST NOSAME ; No!

MOVE T1,[POINT 7,[ASCIZ /Tallys are the same/]]
PSOUT% ; Type it
HALTF% ; Exit to superior
JRST JOVT ; Do it again

NOSAME: MOVE T1,[POINT 7,[ASCIZ /Tallys are NOT the same/]]
PSOUT% ; Type it
HALTF% ; Exit to superior
JRST JOVST ; Do it again

DADDT: BLOCK 2 ; Dadd test
JOVST: BLOCK 2 ; JOV subtract test

END 1,,JOVT

10-Apr-2006 11:59:15-PDT,1338;000000000000
Return-Path: <[email protected]>
Received: from newcheshire.xkl.com (clare.xkl.com [192.94.202.41]) by lingling.panda.com with TCP/SMTP; Mon, 10 Apr 2006 11:56:55 -0700 (PDT)
Received: from tardis.xkl.com (tardis.xkl.com [10.1.0.29])
by newcheshire.xkl.com (8.13.3/8.13.3/SuSE Linux 0.7) with ESMTP id k3AIsBD2022829
for <[email protected]>; Mon, 10 Apr 2006 11:54:13 -0700
Received: from tardis.xkl.com (tardis.xkl.com [10.1.0.29])
by tardis.xkl.com (8.13.3/8.13.3/SuSE Linux 0.7) with ESMTP id k3AIt8g6019015;
Mon, 10 Apr 2006 11:55:11 -0700
Subject: Re: Toad JOV
From: Ralph Gorin <[email protected]>
Reply-To: [email protected]
To: [email protected]
Cc: [email protected]
In-Reply-To: <[email protected]>
References: <[email protected]>
<[email protected]> <[email protected]>
<[email protected]>
Content-Type: text/plain
Organization: XKL, LLC; Redmond, WA
Date: Mon, 10 Apr 2006 11:55:08 -0700
Message-Id: <[email protected]>
Mime-Version: 1.0
X-Mailer: Evolution 2.2.1
Content-Transfer-Encoding: 7bit

It's not JOV,

On the toad-1, SUBM fails to set AROV.
(Also, it doesn't set Carry 0.)
SUB sets the flags properly.

There will be further investigation.

Ralph

10-Apr-2006 12:05:14-PDT,1227;000000000000
Return-Path: <[email protected]>
Received: from pangtzu.panda.com ([206.124.149.117]) by lingling.panda.com with TCP/SMTP; Mon, 10 Apr 2006 12:03:49 -0700 (PDT)
Date: Mon, 10 Apr 2006 12:03:44 -0700 (PDT)
From: Mark Crispin <[email protected]>
Sender: [email protected]
To: [email protected]
cc: [email protected]
Subject: Re: Section space discovery
In-Reply-To: <[email protected]>
Message-ID: <[email protected]>
References: <[email protected]> <[email protected]>
<[email protected]> <[email protected]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed

On Mon, 10 Apr 2006, [email protected] wrote:
> Yes, that's you, today. If you are doing a moby every 10 seconds,
> then your transfer speed is approximately 128 KB/s. Most DSL around
> my neck of the woods is 1.6M /768K while most cable is 2M/1M.

You're confusing kilobits and kilobytes. The numbers reported by the DSL
and cable providers are kilobits, not kilobytes.

-- Mark --

http://panda.com/tops-20
TOPS-20: a great improvement over its successors
10-Apr-2006 12:49:09-PDT,6110;000000000000
Return-Path: <[email protected]>
Received: from mxout5.cac.washington.edu ([140.142.32.135]) by lingling.panda.com with TCP/SMTP; Mon, 10 Apr 2006 12:48:02 -0700 (PDT)
Received: from smtp.washington.edu (smtp.washington.edu [140.142.33.9])
by mxout5.cac.washington.edu (8.13.6+UW06.03/8.13.5+UW06.03) with ESMTP id k3AJltU0030866
(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
Mon, 10 Apr 2006 12:47:56 -0700
X-Auth-Received: from Shimo-Tomobiki.panda.com ([65.122.177.186])
(authenticated authid=mrc)
by smtp.washington.edu (8.13.6+UW06.03/8.13.5+UW06.03) with ESMTP id k3AJlsvr001174
(version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT);
Mon, 10 Apr 2006 12:47:55 -0700
Date: Mon, 10 Apr 2006 12:47:50 -0700
From: Mark Crispin <[email protected]>
To: [email protected]
cc: [email protected]
Subject: Re: Section space discovery
In-Reply-To: <[email protected]>
Message-ID: <[email protected]>
References: <[email protected]> <[email protected]>
<[email protected]> <[email protected]>
Organization: Networks & Distributed Computing
Sender: [email protected]
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
X-Uwash-Spam: Gauge=IIIIIII, Probability=7%, Report='__CP_URI_IN_BODY 0, __CT 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0'

On Mon, 10 Apr 2006, [email protected] wrote:
> I downloaded a version that you posted on Usenet and modified it for
> my use. For PDP-6, KA, KI and KS processors, I report an error. For
> KL and KLH processors, I assume 32 sections. For a Toad, I assume 512
> sections, the highest value I can SMAP% on the Toad that I have access
> to (but isn't it supposed to be able to do 4095?).

You'll have to ask Ralph. However, I think that the interesting value is
the amount of physical memory, not the processor's virtual memory. Even
if it can, a program should try to avoid seizing an excessive amount of
physical memory. TOPS-20 is quite vengeful in punishing such programs
once swapping starts.

> Do I need to care
> about an SC? Does this do extended addressing?

Yes.

> If multi-moby buffers adversely effect system performance for any
> reason, then of course I shouldn't use them. On the other hand, for
> an eight bit RETR transfer, I usually do one PMAP% and one SOUT%. I
> don't take up paging space because the pages never get dirty.

That's not the issue. Of course mapped pages won't become dirty. On the
other hand, they may cause other processes' pages to be swapped out.

I think that you need to do some timing tests, perhaps with the same page
mapped repeatedly to other pages, to see how fast TOPS-20 can reasonably
blast data. The idea here is to remove disk transfer and swap from the
equation.

If you're not doing PM%PLD, then TOPS-20 is probably faulting one page at
a time as it works through the SOUT. So you're getting disk I/O wait
blocks during your transfer.

Next, you need to measure blast speed vs. disk read/write speed.

I really think that what you need is a buffer ring, in which you fill one
buffer (doing PM%PLD) while other buffers are being output. You may need
to do this in multiple forks.

> As I increase the buffer size, I get better performance. The effect
> thus far has been linear. I'm very interested in knowing what the
> break even point is.

The problem is, since you haven't controlled for disk I/O speed (and, I
suspect, page faults), the data isn't meaningful unless all you ever
intend to do is a synchronous PMAP/SOUT loop for a bigbuf. I think that
you can do better than that, using less memory and be faster.

>> A section is 1.25 megabytes. It takes about 10 seconds to transfer
>> that much on my 1.5M/896K DSL line. Most people have slower DSL
>> (256K or 640K/256K) that would take closer to 40 seconds.
> Yes, that's you, today. If you are doing a moby every 10 seconds,
> then your transfer speed is approximately 128 KB/s. Most DSL around
> my neck of the woods is 1.6M /768K while most cable is 2M/1M. My

As I said, you're confusing kilobits and kilobytes. My DSL is 1.5M/896K,
which is equivalent to the 1.6M/768K that you report in your area (are you
sure about the 1.6M part?)...actually, a little bit faster.

> My
> cable and DSL providers are having a speed war and I am now getting
> sustained 30M/2M on cable (Optonline Boost).

Of course, there's the small matter of having to share bandwidth on
cable...

> I think it's
> reasonable to assume an increase of media speed for the next few years
> (but see below).

I don't disagree; that's why I'm telling you that a simple PMAP/SOUT loop
isn't good enough. You have to think about streaming, and have the disk
I/O waits happen while the network is also doing I/O instead of blocking
the network. That suggests a buffer ring rather than throwing memory at
it.

> My primary (cable) backbone is gigabit and the secondary is 100 Mbps.
> The current FTP server regularly transfers at 220 KB/s and I have
> spiked 300 KB/s.

That's my point; TOPS-20 itself is limited as to how fast it can drive the
network. The limit is not the pipe.

> Another possibility is that 2.4 Mbps is the maximum that a
> KLH-NI can do. If I am bumping into that limit, then a lot of this may
> be moot, modulo system impact.

Yup...

> I'm not sure that I agree with what I think you're saying. I've found
> a larger virtual memory space to be quite interesting.

In terms of how big you can make a multi-section buffer, the physical
memory is the limiting factor since if you exceed that you fight against
yourself.

By the way, you have looked into PM%PLD, haven't you?

-- Mark --

http://staff.washington.edu/mrc
Science does not emerge from voting, party politics, or public debate.
Si vis pacem, para bellum.
10-Apr-2006 12:50:31-PDT,1864;000000000000
Return-Path: <[email protected]>
Received: from mxout1.cac.washington.edu ([140.142.32.134]) by lingling.panda.com with TCP/SMTP; Mon, 10 Apr 2006 12:49:08 -0700 (PDT)
Received: from smtp.washington.edu (smtp.washington.edu [140.142.32.139])
by mxout1.cac.washington.edu (8.13.6+UW06.03/8.13.5+UW06.03) with ESMTP id k3AJn2Kb022163
(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
Mon, 10 Apr 2006 12:49:03 -0700
X-Auth-Received: from Shimo-Tomobiki.panda.com ([65.122.177.186])
(authenticated authid=mrc)
by smtp.washington.edu (8.13.6+UW06.03/8.13.5+UW06.03) with ESMTP id k3AJn1Cw021230
(version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT);
Mon, 10 Apr 2006 12:49:02 -0700
Date: Mon, 10 Apr 2006 12:48:57 -0700
From: Mark Crispin <[email protected]>
To: [email protected]
cc: [email protected]
Subject: TOPS-20 FTP client
In-Reply-To: <[email protected]>
Message-ID: <[email protected]>
References: <[email protected]> <[email protected]>
<[email protected]> <[email protected]>
Organization: Networks & Distributed Computing
Sender: [email protected]
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
X-Uwash-Spam: Gauge=IIIIIII, Probability=7%, Report='__CP_URI_IN_BODY 0, __CT 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0'

Speaking of the FTP client, it would be invaluable if you could figure out
a patch to add passive mode. Currently, it doesn't work in some
configurations due to NAT and active-mode only.

-- Mark --

http://staff.washington.edu/mrc
Science does not emerge from voting, party politics, or public debate.
Si vis pacem, para bellum.
11-Apr-2006 00:23:01-PDT,2247;000000000000
Return-Path: <[email protected]>
Received: from mta7.srv.hcvlny.cv.net ([167.206.4.202]) by lingling.panda.com with TCP/SMTP; Tue, 11 Apr 2006 00:21:16 -0700 (PDT)
Received: from optonline.net (hamstr3.srv.hcvlny.cv.net [167.206.5.10])
by mta7.srv.hcvlny.cv.net
(Sun Java System Messaging Server 6.2-4.03 (built Sep 22 2005))
with ESMTP id <[email protected]> for
[email protected]; Tue, 11 Apr 2006 03:21:10 -0400 (EDT)
Received: from [10.240.3.199] (Forwarded-For: [10.240.3.199])
by mstr3.srv.hcvlny.cv.net (mshttpd); Tue, 11 Apr 2006 07:21:09 +0000 (GMT)
Date: Tue, 11 Apr 2006 07:21:09 +0000 (GMT)
From: [email protected]
Subject: Re: TOPS-20 FTP client
In-reply-to: <[email protected]>
To: Mark Crispin <[email protected]>
Cc: [email protected]
Message-id: <[email protected]>
MIME-version: 1.0
X-Mailer: Sun Java(tm) System Messenger Express 6.2-4.03 (built Sep 22 2005)
Content-type: text/plain; charset=us-ascii
Content-language: en
Content-transfer-encoding: 7BIT
Content-disposition: inline
X-Accept-Language: en
Priority: normal
References: <[email protected]>
<[email protected]> <[email protected]>
<[email protected]>
<[email protected]>

> Speaking of the FTP client, it would be invaluable if you could
> figure out a patch to add passive mode.

Whoops! I saw your previous note and forgot to reply to it. I must
have been servicing a maternity interrupt ...

The code to do this is finished and has been tested against the BBN
Tops-20 FTP server on a PANDA system (Twenex.ORG) and whatever a Toad
runs (I don't actually know). I have also verified it against SCO
UNIX and Windows 2000 FTP servers.

I have yet to verify the modified FTP client against my own extended
mode Tops-20 FTP server, but I doubt that there will be any trouble
there. In addition, there are a number of other servers that I want
to test against.

Once I am done buffing and polishing, I'll post the changes to the
Tops-20 FTP client; probably before the end of the week.

13-Apr-2006 10:46:39-PDT,1981;000000000000
Return-Path: <[email protected]>
Received: from newcheshire.xkl.com (clare.xkl.com [192.94.202.41]) by lingling.panda.com with TCP/SMTP; Thu, 13 Apr 2006 10:43:50 -0700 (PDT)
Received: from tardis.xkl.com (tardis.xkl.com [10.1.0.29])
by newcheshire.xkl.com (8.13.3/8.13.3/SuSE Linux 0.7) with ESMTP id k3DHfHbY010955
for <[email protected]>; Thu, 13 Apr 2006 10:41:19 -0700
Received: from tardis.xkl.com (tardis.xkl.com [10.1.0.29])
by tardis.xkl.com (8.13.3/8.13.3/SuSE Linux 0.7) with ESMTP id k3DHgERU026245;
Thu, 13 Apr 2006 10:42:16 -0700
Subject: Re: Section space discovery
From: Ralph Gorin <[email protected]>
Reply-To: [email protected]
To: [email protected]
Cc: [email protected]
In-Reply-To: <[email protected]>
References: <[email protected]>
<[email protected]> <[email protected]>
<[email protected]>
Content-Type: text/plain
Organization: XKL, LLC; Redmond, WA
Date: Thu, 13 Apr 2006 10:42:14 -0700
Message-Id: <[email protected]>
Mime-Version: 1.0
X-Mailer: Evolution 2.2.1
Content-Transfer-Encoding: 7bit

Re: number of sections supported on Toads.

The machine you're using has an older operating
system that limits user space to 512 sections,
i.e., supersection 0 only.

A later version of TOPS-20 for the Toad allows
access to the other seven supersections.
Various JSYS argument formats were unfriendly
to process page numbers greater than 18 bits,
e.g., fork handle,,page number.
Either new JSYSes have been provided or new
argument formats have been introduced. Although
we use this in house, it hasn't been released,
in part due to lack of thorough testing and
lack of adequate user documentation.

The largest Toads in use have 64 Mw = 2^26
physical memory; most are half that size.
As Mark says, if you force the system to swap,
you won't like the results.

Ralph

13-Apr-2006 11:05:08-PDT,1922;000000000000
Return-Path: <[email protected]>
Received: from pangtzu.panda.com ([206.124.149.117]) by lingling.panda.com with TCP/SMTP; Thu, 13 Apr 2006 11:03:43 -0700 (PDT)
Date: Thu, 13 Apr 2006 11:03:38 -0700 (PDT)
From: Mark Crispin <[email protected]>
Sender: [email protected]
To: Ralph Gorin <[email protected]>
cc: [email protected], [email protected]
Subject: Re: Section space discovery
In-Reply-To: <[email protected]>
Message-ID: <[email protected]>
References: <[email protected]> <[email protected]>
<[email protected]> <[email protected]>
<[email protected]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed

On Thu, 13 Apr 2006, Ralph Gorin wrote:
> The largest Toads in use have 64 Mw = 2^26
> physical memory; most are half that size.
> As Mark says, if you force the system to swap,
> you won't like the results.

Hi Ralph. Do you have any insights on good buffer strategies for
high-performance TCP data transfers on TOPS-20?

It seems to me that as long as a buffer is large enough to require some
real time for the TCP side, the disk side should be able to fill an
advance buffer fast enough so that the TCP side never blocks.

If Tom's program is not doing preloading, it should be faulting page at a
time as the SOUT progresses, shouldn't it? The fact that he says that
larger buffers improve the performance linearly suggest that there must be
something very costly when he refills the buffers (presumably a new PMAP
and then a SOUT).

My UNIX-based programs don't use buffers anywhere near a megabyte in size.
I'm certainly not timid on using memory when I need it.

-- Mark --

http://panda.com/tops-20
TOPS-20: a great improvement over its successors
13-Apr-2006 12:47:02-PDT,2247;000000000000
Return-Path: <[email protected]>
Received: from newcheshire.xkl.com (clare.xkl.com [192.94.202.41]) by lingling.panda.com with TCP/SMTP; Thu, 13 Apr 2006 12:44:44 -0700 (PDT)
Received: from tardis.xkl.com (tardis.xkl.com [10.1.0.29])
by newcheshire.xkl.com (8.13.3/8.13.3/SuSE Linux 0.7) with ESMTP id k3DJg9fW012665;
Thu, 13 Apr 2006 12:42:11 -0700
Received: from tardis.xkl.com (tardis.xkl.com [10.1.0.29])
by tardis.xkl.com (8.13.3/8.13.3/SuSE Linux 0.7) with ESMTP id k3DJh8SO024555;
Thu, 13 Apr 2006 12:43:10 -0700
Subject: Re: Section space discovery
From: Ralph Gorin <[email protected]>
Reply-To: [email protected]
To: Mark Crispin <[email protected]>
Cc: [email protected], [email protected]
In-Reply-To: <[email protected]>
References: <[email protected]>
<[email protected]> <[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
Content-Type: text/plain
Organization: XKL, LLC; Redmond, WA
Date: Thu, 13 Apr 2006 12:43:07 -0700
Message-Id: <[email protected]>
Mime-Version: 1.0
X-Mailer: Evolution 2.2.1
Content-Transfer-Encoding: 7bit

Mark and all,

I don't have any insights as to a good
buffer strategy, except to doubt that a
good strategy would provide a great improvement.

The notion of high-performance network traffic
seems ludicrous in TOPS-20. Sorry, but it's so.
TCP is not efficiently implemented in TOPS-20.

File IO isn't efficiently implemented in TOPS-20.
For example, TDBOOT dumps a 32 Mw memory image
in about 1 minute. Using TOPS-20, SETSPD
copies the resulting DUMP.EXE in about 10 minutes.
Admittedly, SETSPD has to read the data and write
it, where TDBOOT only wrote it. So that explains
2 minutes. I don't have a good explanation as to
the other 8 minutes; some of it would be allocating
disk space, maintaining the file system, and doing
the BLT to copy the data when the program
dirties the page to snap the mapping of
input file page to memory page. We've grown a fine
crop of barnacles over the years.

Ralph

18-Apr-2006 21:00:50-PDT,1979;000000000000
Return-Path: <[email protected]>
Received: from newcheshire.xkl.com (clare.xkl.com [192.94.202.41]) by lingling.panda.com with TCP/SMTP; Tue, 18 Apr 2006 20:58:03 -0700 (PDT)
Received: from tardis.xkl.com (tardis.xkl.com [10.1.0.29])
by newcheshire.xkl.com (8.13.3/8.13.3/SuSE Linux 0.7) with ESMTP id k3J3tSis011140
for <[email protected]>; Tue, 18 Apr 2006 20:55:30 -0700
Received: from tardis.xkl.com (tardis.xkl.com [10.1.0.29])
by tardis.xkl.com (8.13.3/8.13.3/SuSE Linux 0.7) with ESMTP id k3J3uThW006800;
Tue, 18 Apr 2006 20:56:31 -0700
Subject: Re: Control-T breaks when using DEBUG on XKL system
From: Ralph Gorin <[email protected]>
Reply-To: [email protected]
To: [email protected]
Cc: [email protected]
In-Reply-To: <[email protected]>
References: <[email protected]>
<[email protected]>
Content-Type: text/plain
Organization: XKL, LLC; Redmond, WA
Date: Tue, 18 Apr 2006 20:56:29 -0700
Message-Id: <[email protected]>
Mime-Version: 1.0
X-Mailer: Evolution 2.2.1
Content-Transfer-Encoding: 7bit

The Exec that breaks is fairly a fairly old one.

The debug command contrives to put the symbol
table in high memory (page 771). Load or
Execute would put the symbols 100 locations
after the end of the code. (In page 0 of
your tiny program.)

The part of the Exec that tries to do
symbolic output of locations (in this
case, the PC location)
maps a window of the process' symbol
table into a portion of itself. It
allocates 10 pages to do so and
tries to PMAP inferior page 771
into Exec page 541 and repeat until
10 pages have been mapped.
After it maps page 777,
PMAP fails with no such section.

I don't have the old code so
I can't debug it further. The
current exec code doesn't break this way.
(But I don't know why it doesn't.)

It would be fixed in the next release
if there were ever a next release.

Ralph

18-Apr-2006 22:21:14-PDT,1648;000000000000
Return-Path: <[email protected]>
Received: from pangtzu.panda.com ([206.124.149.117]) by lingling.panda.com with TCP/SMTP; Tue, 18 Apr 2006 22:19:23 -0700 (PDT)
Date: Tue, 18 Apr 2006 22:19:14 -0700 (PDT)
From: Mark Crispin <[email protected]>
Sender: [email protected]
To: Ralph Gorin <[email protected]>
cc: [email protected], [email protected]
Subject: Re: Control-T breaks when using DEBUG on XKL system
In-Reply-To: <[email protected]>
Message-ID: <[email protected]>
References: <[email protected]> <[email protected]>
<[email protected]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed

Thank you Ralph for your analysis.

I took a look at it, and it looks like all that is needed is to add an
ERJMP .+1 after the PMAP at GETS1+17 in EXECP.MAC. The PMAP will do a
partial map up to the section boundary, so all we have to do is disregard
the failure.

A more comprehensive fix is to change the instructions from the PMAP to
the MOVEM A,SYMEA as follows:

PMAP ;ESTABLISH NEW WINDOW INTO SYMBOL TABLE
ERJMP .+1 ;IGNORE ERROR
HRRZ A,SYMBA ;GET SMALLEST ADDRESS THAT IS MAPPED
ADDI A,-1+NSMPGS*1000 ;CALCULATE LARGEST ADDRESS MAPPED
TLNE A,-1 ;DID IT OVERFLOW INTO NEXT SECTION?
MOVEI A,-1 ;YES, STOP AT END OF SECTION
HRRM A,SYMEA ;REMEMBER IT

This ensures that the value stored in SYMEA does not cross a section
boundary.

-- Mark --

http://panda.com/tops-20
TOPS-20: a great improvement over its successors
20-Apr-2006 18:42:38-PDT,16165;000000000000
Return-Path: <[email protected]>
Received: from mta5.srv.hcvlny.cv.net ([167.206.4.200]) by lingling.panda.com with TCP/SMTP; Thu, 20 Apr 2006 18:40:21 -0700 (PDT)
Received: from optonline.net (hamstr3.srv.hcvlny.cv.net [167.206.5.10])
by mta5.srv.hcvlny.cv.net
(Sun Java System Messaging Server 6.2-4.03 (built Sep 22 2005))
with ESMTP id <[email protected]> for
[email protected]; Thu, 20 Apr 2006 21:40:08 -0400 (EDT)
Received: from [10.240.3.197] (Forwarded-For: [10.240.3.197])
by mstr3.srv.hcvlny.cv.net (mshttpd); Fri, 21 Apr 2006 01:40:08 +0000 (GMT)
Date: Fri, 21 Apr 2006 01:40:08 +0000 (GMT)
From: [email protected]
Subject: Tops-20 FTP client Passive Mode
In-reply-to: <[email protected]>
To: [email protected]
Message-id: <[email protected]>
MIME-version: 1.0
X-Mailer: Sun Java(tm) System Messenger Express 6.2-4.03 (built Sep 22 2005)
Content-type: text/plain; charset=us-ascii
Content-language: en
Content-transfer-encoding: 7BIT
Content-disposition: inline
X-Accept-Language: en
Priority: normal
References: <[email protected]>
<[email protected]> <[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>

The following changes allow the Tops-20 FTP client to communicate with
a remote host using passive mode (PASV) data connections. The command
for passive mode is "SET DATA-CONNECTION (port negotiation mode to)
PASSIVE". These cause the remote server to wait for a data connection
rather than actively attempting to make a connection back to the local
client. This is useful when trying to transfer files while behind a
non-stateful firewall.

In the active case, the server attempts to make a connection back to
the client on the client requested data port, but this will not work
because the firewall, being stateless and/or not inspecting packets on
the FTP control port, will either not open the requested port in the
firewall and/or not route data packets to the appropriate host.
Passive mode allows the client to continue to make outgoing
connections which, assuming the firewall is not blocking outgoing
ports, are more likely to succeed.

The problem with implementing passive mode under Tops-20 is twofold.
First, while RFC959 gives an example of a response to the PASV
command, it does not explicitly REQUIRE that an FTP server MUST adhere
to this format. A brief survey of five servers show that NONE do:

RFC959: 227 Entering Passive Mode. A1,A2,A3,A4,a1,a2
Tops-20 (BBN): 227 Entering Passive mode, use PORT 192,168,1,20,12,20
Windows 2000: 227 Entering Passive Mode (10,100,1,251,15,9).
SCO UNIX: 227 Entering Passive Mode (10,100,1,1,6,166)
MAC OSX (Darwin): 227 Entering Passive Mode (192,168,1,80,192,178)
Lindows (OpenBSD): 227 Entering Passive Mode (192,168,2,9,128,106)

This is not a problem for a human interpreting the output of the
command. However, for programmed clients which DO interprete the
output, the question arises of recognizing the appropriate fields.
The Tops-20 FTP client attempts to do the right thing by parsing the
PASV response (227) and combining the numbers after the last two
commas as the port.

The new extended mode Tops-20 FTP server attempts to ease the parsing
problem in the following way:

1) When operating in 'native' or Tops-20 mode, the format of
the response exactly matches that of the previous BBN server.
This is done to ensure backward compatibility with those
clients that are coded to recognize Tops-20 systems.

2) When operating in TVFS mode, the format matches that of Unix
(see Mac OSX, Lindows and SCO UNIX).

This is necessary for the Windows Explorer and other graphical clients
which only handle something that is very close to the Unix format.
The Tops-20 FTP client will handle all of the examples and has been
tested against all of the above systems. However, I obviously can't
guarantee that it will work with everything.

Second, RFC959 does not specify when the locally selected port should
actually become active. In particular, an older version of the
extended mode server did not allocate and open the port until the
actual data transfer (RETR,STOR,STOU) was issued by the remote FTP
client. This worked for the EFTP3 graphical client and a number of
character mode clients. It broke on the Windows Explorer.

The extended mode server was changed to have the port open and ready
for a connect BEFORE responding to the PASV (or EPSV) command. The
Tops-20 FTP assumes this paradigm: that the port will be open at the
response to the PASV (or EPSV). The reason for this was not dogmatic
so much as the code was more straightforward to write. It may also be
more secure.

File 1) DSK:FTPDEF.MAC[4,24] created: 2254 10-Apr-06
File 2) DSK:FTPDEF.BAK[4,24] created: 0320 20-Sep-05

1)1 ;[T37] [TOMMYT]STAR:<FTP>FTPDEF.MAC.120, 10-Apr-2006 22:40:40, Edit by SLOGIN
1) ;[T37] Implement passive mode for FTP client
1) ;[T29] [TOMMYT]STAR:<FTP>FTPDEF.MAC.115, 20-Sep-2005 02:19:02, Edit by SLOGIN
****
2)1 ;[T29] [TOMMYT]STAR:<FTP>FTPDEF.MAC.115, 20-Sep-2005 02:19:02, Edit by SLOGIN
**************
1)6 F%PASV==1B4 ;[T37] Data connections are passive
1) ; FTP only permanent flags
****
2)6 ; FTP only permanent flags
**************

File 1) DSK:FTP.MAC[4,24] created: 1105 11-Apr-06
File 2) DSK:FTP.BAK[4,24] created: 2305 21-Sep-05

1)1 ;[T37] [TOMMYT] STAR:<FTP>FTP.MAC.354, 10-Apr-2006 22:41:29, Edit by SLOGIN
1) ;[T37] Implement passive mode for FTP client
1) ;[T30] [TOMMYT]STAR:<FTP>FTP.MAC.346, 21-Sep-2005 17:44:12, Edit by SLOGIN
****
2)1 ;[T30] [TOMMYT]STAR:<FTP>FTP.MAC.346, 21-Sep-2005 17:44:12, Edit by SLOGIN
**************
1)2 VEDIT==313 ;[T37] ; Edit version
1) VWHO==6 ;[T16] ; Who last edited (4 = Stanford)
****
2)2 VEDIT==312 ;[T30] ; Edit version
2) VWHO==6 ;[T16] ; Who last edited (4 = Stanford)
**************
1)16 DSPCON: IFXE. F,F%PASV ;[T37]
1) TYPE <Data connection negotiation mode is server ACTIVE%/> ;[T37]
1) ELSE. ;[T37]
1) TYPE <Data connection negotiation mode is server PASSIVE%/> ;[T37]
1) ENDIF. ;[T37]
1)
1) IFXE. F,F%COPN
1) TYPE <No connection is open%/>
****
2)16 DSPCON: IFXE. F,F%COPN
2) TYPE <No connection is open%/>
**************
1)24 T DATA-CONNECTION,DATA ;;[T37] Data port negotiation mode
1) TI DEBUG
****
2)24 TI DEBUG
**************
1)40 ;[T37] Parsing for active/passive data connections
1)
1) H.DATA: ASCIZ/Sets the data port negotiation mode. Normally, the FTP client assumes
1) that the FTP server will make the data connection to the client. It
1) does this via the use of the PORT command which tells the server which
1) port to connect to on the client machine. This is known as "ACTIVE"
1) mode because the server is making the connection.
1)
1) For FTP clients which operate behind firewalls that do not do stateful
1) packet inspection to open and forward negotiated ports, this approach
1) will fail. The alternative is to use "PASSIVE" mode. In this case,
1) the FTP client issues a PASV command. The FTP server choses a free
1) local port and reserves it. It reports this in the response. The FTP
1) client then connects to the server on the specified port.
1)
1) N.B., Because a host may be behind a firewall using address
1) translation, there is a chance that it will report a target address
1) which is not routable. FTP handles this by always ignoring the
1) reported host address and using the foreign address of the control
1) connection. This is not appropriate for third party transfers.
1)
1) There are certain cases where neither ACTIVE or PASSIVE mode will
1) work. For example, if both FTP client and server are behind firewalls
1) which do not do stateful packet inspection or otherwise will not open
1) and or forward the requested data ports, then no data FTP transfers
1) will EVER be possible.
1)
1) In these cases, another protocol which does not negotiate TCP ports
1) (such as KERMIT) must be used.
1) / ;[T37]
1)
1) S.DATA: NOISE <port negotiation mode to> ;[T37]
1) MOVEI B,[FLDDB. .CMKEY,,DATAMT,,<ACTIVE>] ;[T37]
1) CALL .COMND ;[T37]
1) ERMSG <Invalid data port connection mode> ;[T37]
1) CALL CONFRM ;[T37] Tie off the line
1) HRLZ B,(B) ;[T37] Get the keyword value
1) TXZ F,F%PASV ;[T37] Assume active mode (default)
1) IOR F,B ;[T37] Set data connection mode
1) RET ;[T37] Done
1)
1) DATAMT: TABLE ;[T37] Data connection mode table
1) T ACTIVE,0 ;[T37] Will use PORT command
1) T PASSIVE,(F%PASV) ;[T37] Will use PASV command
1) TEND ;[T37] End of table
1)
1)41 ; SET NO -- Prefix set option with NO.
****
2)40 ; SET NO -- Prefix set option with NO.
**************

File 1) DSK:TCPDAT.MAC[4,24] created: 1109 15-Apr-06
File 2) DSK:TCPDAT.BAK[4,24] created: 2248 21-Sep-05

1)1 ;[T37[ [TOMMYT]STAR:<FTP>TCPDAT.MAC.35, 10-Apr-2006 22:51:36, Edit by SLOGIN
1) ;[T37] Implement passive mode for FTP client
1) ;[T29] [TOMMYT]STAR:<FTP>TCPDAT.MAC.14, 20-Sep-2005 02:27:10, Edit by SLOGIN
****
2)1 ;[T29] [TOMMYT]STAR:<FTP>TCPDAT.MAC.14, 20-Sep-2005 02:27:10, Edit by SLOGIN
**************
1)7 TCDOP1: IFXE. F,F%PASV ;[T37] Active?
1) TXNE F,F%ALTS ;[T37] Want alternate sockets?
1) CALL TCDNSK ;[T37] Yes, get new socket
1) HRROI A,NETBUF ;[T37] Into this buffer space
1) MOVE B,LCLPRT ;[T37] Get the new local port number
1) MOVE C,HSTNUM ;[T37] With foreign host number
1) WRITE <TCP:%2D.%3O-20;CONNECTION:PASSIVE;TIMEOUT:60> ;[T37] Make JFN string
1) ELSE. ;[T37] Otherwise passive
1) CALL TCDPAS ;[T37] Find out the port from the host
1) HRROI A,NETBUF ;[T37] Into this buffer space
1) MOVE C,HSTNUM ;[T37] Control connection remote host address
1) WRITE <TCP:20.%3O-%4D;CONNECTION:ACTIVE;TIMEOUT:60> ;[T37] C,D
1) ENDIF. ;[T37]
1) MOVX A,GJ%SHT ; Short form of GTJFN%
****
2)7 TCDOP1: TXNE F,F%ALTS ; Want alternate sockets?
2) CALL TCDNSK ; Yes, get new socket
2) HRROI A,NETBUF ; Into this buffer space
2) MOVE B,LCLPRT ; Get the new local port number
2) MOVE C,HSTNUM ; With foreign host number
2) MOVEI D,^D20 ; And default data port (no need for variable)
2) WRITE <TCP:%2D.%3O-%4D;CONNECTION:PASSIVE;TIMEOUT:60> ; Make JFN string
2) MOVX A,GJ%SHT ; Short form of GTJFN%
**************
1)7 ;[T37] Base network bits: 8 bit bytes, read/write
1) MOVX B,<<FLD ^D8,OF%BSZ>!OF%WR!OF%RD>
1) ;[T37] When active, don't wait, high throughput
1) MOVX C,<FLD .TCMIH,OF%MOD>
1) TXNE F,F%PASV ;[T37] Passive mode?
1) MOVX C,<FLD .TCMWH,OF%MOD>
1) ;[T37] Assume wait before return, high throughput
1) IOR B,C ;[T37] Construct complete open bits
1) OPENF% ; Open the connection, but return immediately
****
2)7 MOVE B,[FLD(8,OF%BSZ)!FLD(.TCMIH,OF%MOD)!OF%RD!OF%WR]
2) OPENF% ; Open the connection, but return immediately
**************
1)8 ; Here to get a new socket number for the data connection
1) TCDNSK: MOVX A,.GTHLN ; Getting host number on network
****
2)8 ; Here to get a new socket number for the dadta connection
2) TCDNSK: MOVX A,.GTHLN ; Getting host number on network
**************
1)8 ;[T37] Here to get a port from the remote host when in passive mode
1)
1) TCDPAS: FTPM <PASV> ;[T37] Ask server for a port
1) TCDPA1: CALL TCPRSQ ;[T37] Get response
1) JRST TCDPA2 ;[T37] Lost; maybe the server doesn't have PASV?
1) JRST TCDPAS ;[T37] Retry, we weren't logged in
1) CAIN B,"-" ;[T37] Continued????
1) JRST TCDPA1 ;[T37] Yes, only want one line
1) CAIE A,^D227 ;[T37] Did it give us a port?
1) JRST TCDPA3 ;[T37] No, bad response
1) ;[T37] So far, so good: parse the response
1) SETZB A,B ;[T37] Penultimate and ultimate commas
1) DO. ;[T37] Parse for the port
1) ILDB D,C ;[T37] Pick up a character
1) CAIE D,"," ;[T37] A comma?
1) IFSKP. ;[T37] Yes, this delimits host and port octets
1) MOVE A,B ;[T37] Remember last comma
1) MOVE B,C ;[T37] This one, two, too
1) ENDIF. ;[T37] End case of octet delimiter
1) JUMPN D,TOP. ;[T37] Not at end? Get more characters
1) ENDDO. ;[T37] Now should have high and low port
1) ;[T37] Do a little bogo-checking
1) JUMPE A,TCDPA4 ;[T37] No high port octet?
1) JUMPE B,TCDPA4 ;[T37] No low port octet?
1) ;[T37] Good, now form the internal 16 bit port
1) MOVE D,B ;[T37] Save low order
1) MOVX C,^D10 ;[T37] Port octet is reported in decimal
1) NIN% ;[T37] Convert to internal
1) ERJMPS TCDPA4 ;[T37] Mal-formed server response
1) MOVE A,D ;[T37] Load low order position
1) MOVE D,B ;[T37] Save high order byte
1) NIN% ;[T37] Convert low port octet to internal
1) ERJMPS TCDPA4 ;[T37] Mal-formed server response
1) LSH D,^D8 ;[T37] Position high order byte
1) IORB B,D ;[T37] Complete the waiting data port number
1) RET ;[T37] Return a twin, just in case
1)
1) TCDPA2: ETYPE <Couldn't negotiate a passive data connection - %J%/> ;[T37] Complain
1) RET ;[T37]
1)
1) TCDPA3: ETYPE <Server didn't report a passive data connection port - %J%/> ;[T37]
1) RET ;[T37]
1)
1) TCDPA4: ETYPE <Server didn't specify a passive data connection port number - %J%/> ;[T37]
1) RET ;[T37]
1)
1)9 ; TCXCLS - Release the data port
****
2)9 ; TCXCLS - Release the data port
**************

20-Apr-2006 21:50:22-PDT,2283;000000000000
Return-Path: <[email protected]>
Received: from mxout3.cac.washington.edu ([140.142.32.166]) by lingling.panda.com with TCP/SMTP; Thu, 20 Apr 2006 21:47:45 -0700 (PDT)
Received: from smtp.washington.edu (smtp.washington.edu [140.142.32.139])
by mxout3.cac.washington.edu (8.13.6+UW06.03/8.13.5+UW06.03) with ESMTP id k3L4ldea025070
(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
Thu, 20 Apr 2006 21:47:39 -0700
X-Auth-Received: from Shimo-Tomobiki.panda.com (panda.com [206.124.149.114])
(authenticated authid=mrc)
by smtp.washington.edu (8.13.6+UW06.03/8.13.6+UW06.03) with ESMTP id k3L4lap4030034
(version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT);
Thu, 20 Apr 2006 21:47:38 -0700
Date: Thu, 20 Apr 2006 21:47:30 -0700
From: Mark Crispin <[email protected]>
To: [email protected]
cc: [email protected]
Subject: Re: Tops-20 FTP client Passive Mode
In-Reply-To: <[email protected]>
Message-ID: <[email protected]>
References: <[email protected]> <[email protected]>
<[email protected]> <[email protected]>
<[email protected]>
<[email protected]> <[email protected]>
Organization: Networks & Distributed Computing
Sender: [email protected]
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
X-Uwash-Spam: Gauge=IIIIIII, Probability=7%, Report='__CP_URI_IN_BODY 0, __CT 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __LINES_OF_YELLING 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0'

On Fri, 21 Apr 2006, [email protected] wrote:
> 1) WRITE <TCP:20.%3O-%4D;CONNECTION:ACTIVE;TIMEOUT:60> ;[T37] C,D

I disagree with this line. It should be

WRITE <TCP:.%3O-%4D;CONNECTION:ACTIVE;TIMEOUT:60> ;[T37] C,D

In other words, the local port should not be specified. You can't specify
local low ports (such as port 20) without the #, and unprivileged users
can't do it at all.

-- Mark --

http://staff.washington.edu/mrc
Science does not emerge from voting, party politics, or public debate.
Si vis pacem, para bellum.
21-Apr-2006 11:57:33-PDT,2563;000000000000
Return-Path: <[email protected]>
Received: from mta3.srv.hcvlny.cv.net ([167.206.4.198]) by lingling.panda.com with TCP/SMTP; Fri, 21 Apr 2006 11:55:36 -0700 (PDT)
Received: from optonline.net (hamstr3.srv.hcvlny.cv.net [167.206.5.10])
by mta3.srv.hcvlny.cv.net
(Sun Java System Messaging Server 6.2-4.03 (built Sep 22 2005))
with ESMTP id <[email protected]> for
[email protected]; Fri, 21 Apr 2006 14:55:12 -0400 (EDT)
Received: from [10.240.3.200] (Forwarded-For: [10.240.3.200])
by mstr3.srv.hcvlny.cv.net (mshttpd); Fri, 21 Apr 2006 18:55:11 +0000 (GMT)
Date: Fri, 21 Apr 2006 18:55:11 +0000 (GMT)
From: [email protected]
Subject: Re: Tops-20 FTP client Passive Mode
In-reply-to: <[email protected]>
To: Mark Crispin <[email protected]>
Cc: [email protected]
Message-id: <[email protected]>
MIME-version: 1.0
X-Mailer: Sun Java(tm) System Messenger Express 6.2-4.03 (built Sep 22 2005)
Content-type: text/plain; charset=us-ascii
Content-language: en
Content-transfer-encoding: 7BIT
Content-disposition: inline
X-Accept-Language: en
Priority: normal
References: <[email protected]>
<[email protected]> <[email protected]>
<[email protected]>
<[email protected]>
<[email protected]> <[email protected]>
<[email protected]>

> I disagree with this line. It should be
>
> WRITE <TCP:.%3O-%4D;CONNECTION:ACTIVE;TIMEOUT:60> ;[T37] C,D

Yes, you're correct and that is, in fact, what I have in my sources.
Somehow, I managed to FILCOM TCPDAT with an intermediate version.
Dunno how I did that, since this wouldn't have worked on the Toad or
the other Panda system where I tested (and don't have Wheel), but
there it is. I double checked the other FILCOMs and these are
correct--thanks for backstopping me.

I should also mention that passive mode will not work with ITS as its
FTP server does not implement PASV. I had a brief look at ftps.mid
and it didn't look like it would be that hard to add this. The ITS
FTP client does not support passive mode, either. I am less familar
with ftpu.mid and do not have an informed opinion as to the difficulty
of adding passive support.

I have no information on anything to do with WAITS, the Tenex FTP
client nor anything to do with Tops-10 (*** SIGH ***)

21-Apr-2006 12:24:35-PDT,3455;000000000000
Return-Path: <[email protected]>
Received: from pangtzu.panda.com ([206.124.149.117]) by lingling.panda.com with TCP/SMTP; Fri, 21 Apr 2006 12:22:55 -0700 (PDT)
Date: Fri, 21 Apr 2006 12:22:49 -0700 (PDT)
From: Mark Crispin <[email protected]>
Sender: [email protected]
To: [email protected]
cc: TOPS-20 Hackers and Yackers <[email protected]>
Subject: Re: Tops-20 FTP client Passive Mode
In-Reply-To: <[email protected]>
Message-ID: <[email protected]>
References: <[email protected]> <[email protected]>
<[email protected]> <[email protected]>
<[email protected]>
<[email protected]> <[email protected]>
<[email protected]>
<[email protected]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed

On Fri, 21 Apr 2006, [email protected] wrote:
> I should also mention that passive mode will not work with ITS as its
> FTP server does not implement PASV. I had a brief look at ftps.mid
> and it didn't look like it would be that hard to add this.

Hmm. I thought that passive mode was mandatory-to-implement in the FTP
server. If so, that sounds like a bug.

I only know of two ITS systems in serious use; and only one of which is
actually up on the Internet with any regularity. Sadly, (IMHO) ITS
succumbed to software rot due in part to aggressive file reaping. A lot
of valuable historical stuff was lost forever on GFR tapes.

Chris Stacy would probably be the person to contact about getting FTP
passive mode implemented in ITS.

> I have no information on anything to do with WAITS, the Tenex FTP
> client nor anything to do with Tops-10 (*** SIGH ***)

WAITS is extinct, although Martin Frost and Les Earnest have talked about
an effort to revive it. They certainly have an impressive archive of
WAITS software (and personal data of hundreds of individuals...).

AFAIK, Tenex is extinct with no effort underway to revive it. I know that
Foonly had TCP in their "Foonex" variant of Tenex, and initial TCP
development was in Tenex.

But the last BBN Tenex release did not have TCP. Anyway the only way to
access TCP on Tenex (and probably Foonex as well) was through those
cretinous BBN TCP jsi (OPEN, CLOSE, SEND, RECV, SCSLV, STAT, CHANL, ABORT)
that would make any sane programmer retch. I actually mastered those jsi,
and when the TCP: device was debugged I made a careful effort to forget
everything I learned. Executive summary: if you liked everything that was
wrong with TOPS-10 buffered I/O and UNIX sockets, and desire to avoid any
of the benefits of either, then you'll love the BBN TCP jsi.

With the possible exception of some machines at Systems Concepts, TOPS-10
is also extinct as an Internet operating system. The only accessible
TOPS-10 machine on the Internet that I know of is Paul Allen's KL10, but
that supports Internet through a cisco "milking machine" through the
serial ports. It does not have the TOPS-10 TCP code, which was never a
DEC product anyway. Don Provan was the last person I know to hack on it
regularly.

-- Mark --

http://panda.com/tops-20
TOPS-20: a great improvement over its successors
22-Apr-2006 16:05:32-PDT,3230;000000000000
Return-Path: <[email protected]>
Received: from pop-cowbird.atl.sa.earthlink.net ([207.69.195.68]) by lingling.panda.com with TCP/SMTP; Sat, 22 Apr 2006 16:02:56 -0700 (PDT)
Received: from cpe-24-221-177-162.ca.sprintbbd.net ([24.221.177.162] helo=[204.238.239.104])
by pop-cowbird.atl.sa.earthlink.net with esmtp (Exim 3.36 #10)
id 1FXR7o-00048V-00
for [email protected]; Sat, 22 Apr 2006 19:02:49 -0400
Mime-Version: 1.0 (Apple Message framework v623)
In-Reply-To: <[email protected]>
References: <[email protected]> <[email protected]> <[email protected]> <[email protected]> <[email protected]> <[email protected]> <[email protected]> <[email protected]> <[email protected]> <[email protected]>
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <[email protected]>
Content-Transfer-Encoding: 7bit
From: Carl Baltrunas <[email protected]>
Subject: Re: Tops-20 FTP client Passive Mode
Date: Sat, 22 Apr 2006 16:02:47 -0700
To: TOPS-20 Hackers and Yackers <[email protected]>
X-Mailer: Apple Mail (2.623)

On Apr 21, 2006, at 12:22 PM, Mark Crispin wrote:
> On Fri, 21 Apr 2006, [email protected] wrote:
>> I have no information on anything to do with WAITS, the Tenex FTP
>> client nor anything to do with Tops-10 (*** SIGH ***)

As of TOPS-10 7.03 [circa 1985] (the last brush I had with a running
TOPS-10) the only networking support was for ANF-10, DECnet or LAT and
there was no FTP server or client since neither NCP nor TCP had been
injected. I don't remember anything in RSX-11M at that time either, so
definitely nothing in RSX-20F.

Vance Socci or Ralph Gorin may have tinkered with TCP for the XKL
modifications to TOPS-10, but I don't recall hearing of a working
implementation.

Tymshare ran a hybrid or modified TENEX on the Foonly F3 and F4, which
were up on the ARPAnet as OFFICE-1 thru at least OFFICE-11. Phil
French or Vance Socci would be the last people who worked on the
microcode (not counting Dave Poole) and would know what was going on
there. After McDonnell Douglas (MDC) bought Tymshare, the only machines
still on the net were then running TOPS-20 on the F4 which was renamed
the 26KL by McDonnell Douglas Field Service Company. Doug Englebart,
Raylene Pak and Linda Parkhurst kept those machines running until they
parted ways with MDC and for some time after.

The other systems run at Tymshare, TYMCOM-X only had a Tymnet DMA ring
buffer interface (and later a 68k DMA interface) to the SA-10 and we
used a program called Telecopy for file transfers over Tymnet. On the
DEC-2020 the interface was an -11 board (whose name escapes me, I want
to say a DMC-11) and it connected to an LSI-11 directly that interfaced
to Tymnet. So, no FTP program there. We also ran TYMCOM-X on the
Foonly F3, but again, we were connected to an LSI-11 as our network
interface.

-Carl

22-Apr-2006 18:08:03-PDT,3395;000000000000
Return-Path: <[email protected]>
Received: from mta5.srv.hcvlny.cv.net ([167.206.4.200]) by lingling.panda.com with TCP/SMTP; Sat, 22 Apr 2006 18:06:07 -0700 (PDT)
Received: from optonline.net (hamstr3.srv.hcvlny.cv.net [167.206.5.10])
by mta5.srv.hcvlny.cv.net
(Sun Java System Messaging Server 6.2-4.03 (built Sep 22 2005))
with ESMTP id <[email protected]> for
[email protected]; Sat, 22 Apr 2006 21:05:47 -0400 (EDT)
Received: from [10.240.3.200] (Forwarded-For: [10.240.3.200])
by mstr3.srv.hcvlny.cv.net (mshttpd); Sun, 23 Apr 2006 01:05:47 +0000 (GMT)
Date: Sun, 23 Apr 2006 01:05:47 +0000 (GMT)
From: [email protected]
Subject: CVTBDO everywhere
In-reply-to: <[email protected]>
To: [email protected]
Message-id: <[email protected]>
MIME-version: 1.0
X-Mailer: Sun Java(tm) System Messenger Express 6.2-4.03 (built Sep 22 2005)
Content-type: text/plain; charset=us-ascii
Content-language: en
Content-transfer-encoding: 7BIT
Content-disposition: inline
X-Accept-Language: en
Priority: normal
References: <[email protected]>
<[email protected]> <[email protected]>
<[email protected]>
<[email protected]>
<[email protected]> <[email protected]>
<[email protected]>
<[email protected]>

The following program, when run in section 0 on a Toad and KLH10
machine, produces the expected output: "49598". Under Tops-10 on a KL
(see below), the output is the same. When run in any non-zero section
on KLH10, the output remains the same.

When run in a non-zero section on a Toad, no output is produced and
nothing is deposited into STRING, although the pointer in 5,6 is
updated to STRING+1. Register zero gets a "150" which is the first
character of 49598. Page 0 in section 0 is created and this contains
344000,,0 at location 0,,36; 7,,100000 at location 65 and 1520,,34000
at location 71.

This broke some stuff on my FTP server, but I can program around it by
checking for a Toad, doing some math and using some NOUT%s, instead.
However, these are good pointers, right?

TITLE DNOUT
SEARCH MONSYM

STRING: REPEAT ^D10,<Z> ; Space for string

DNOUT: RESET% ; Reset the world
DMOVE 1,[EXP 0,140676] ; Decimal 49,598
DMOVE 3,[EXP 0,^D23] ; Output string maximum length
DMOVE 5,[ 100740,,0 ; Global byte pointer
0,,STRING ] ; Where to put this
XHLLI 6,. ; Load the section
TLNE 6,-1 ; In an extended section?
JRST DOIT ; Yes, just issue the instruction
HRR 5,6 ; Load the offset
TLZ 5,(1B12) ; Shut off the global pointer bit
SETZ 6, ; Bonk the address

DOIT: DMOVE 7,5 ; Store the pointer
EXTEND 1,[EXP <CVTBDO 0,"0">,040] ; Convert to decimal
JFCL
JFCL

LOOP: ILDB 1,7 ; Pick up a byte
JUMPE 1,DONE ; End of string?
PBOUT% ; Type it
JRST LOOP ; Do more

DONE: HALTF% ; Exit to superior
JRST DNOUT ; Do it all over again

END 1,,DNOUT ; Nothing to do for reenter

PS: To run under Tops-10,
a) Remove the "SEARCH MONSYM"
b) Change the "RESET%" to "RESET"
c) Change the "PBOUT%" to "OUTCHR 1"
d) Change the "HALTF%" to "EXIT 1,"

22-Apr-2006 20:10:59-PDT,2511;000000000000
Return-Path: <[email protected]>
Received: from mail3.panix.com ([166.84.1.74]) by lingling.panda.com with TCP/SMTP; Sat, 22 Apr 2006 20:08:28 -0700 (PDT)
Received: from panix5.panix.com (panix5.panix.com [166.84.1.5])
by mail3.panix.com (Postfix) with ESMTP id 8859413AD15
for <[email protected]>; Sat, 22 Apr 2006 23:08:21 -0400 (EDT)
Received: (from alderson@localhost)
by panix5.panix.com (8.11.6p3/8.8.8/PanixN1.1) id k3N38LU14673;
Sat, 22 Apr 2006 23:08:21 -0400 (EDT)
Date: Sat, 22 Apr 2006 23:08:21 -0400 (EDT)
Message-Id: <[email protected]>
From: Rich Alderson <[email protected]>
To: [email protected]
In-reply-to: <[email protected]> (message from
Carl Baltrunas on Sat, 22 Apr 2006 16:02:47 -0700)
Subject: Re: Tops-20 FTP client Passive Mode
References: <[email protected]> <[email protected]> <[email protected]> <[email protected]> <[email protected]> <[email protected]> <[email protected]> <[email protected]> <[email protected]> <[email protected]> <[email protected]>

> From: Carl Baltrunas <[email protected]>
> Date: Sat, 22 Apr 2006 16:02:47 -0700

> As of TOPS-10 7.03 [circa 1985] (the last brush I had with a running
> TOPS-10) the only networking support was for ANF-10, DECnet or LAT and
> there was no FTP server or client since neither NCP nor TCP had been
> injected. I don't remember anything in RSX-11M at that time either, so
> definitely nothing in RSX-20F.

Peter Lothberg has told me that there was a TCP/IP implementation done for
7.02 using the front-end, and that he has the tapes somewhere. If anyone
is interested in resurrecting this and bringing it forward to 7.04, he'd be
willing to dig these out.

> Vance Socci or Ralph Gorin may have tinkered with TCP for the XKL
> modifications to TOPS-10, but I don't recall hearing of a working
> implementation.

We never proposed to do TCP/IP for Tops-10 on the Toad-1. We tried to obtain
the CMU implementation, which is how we learned of their tape catalog problem
and decided just to do DECNET. Then we cancelled it for lack of interest.

Rich
22-Apr-2006 22:03:11-PDT,1708;000000000000
Return-Path: <[email protected]>
Received: from pangtzu.panda.com ([206.124.149.117]) by lingling.panda.com with TCP/SMTP; Sat, 22 Apr 2006 22:01:27 -0700 (PDT)
Date: Sat, 22 Apr 2006 22:01:22 -0700 (PDT)
From: Mark Crispin <[email protected]>
Sender: [email protected]
To: Carl Baltrunas <[email protected]>
cc: TOPS-20 Hackers and Yackers <[email protected]>
Subject: Re: Tops-20 FTP client Passive Mode
In-Reply-To: <[email protected]>
Message-ID: <[email protected]>
References: <[email protected]> <[email protected]>
<[email protected]> <[email protected]>
<[email protected]>
<[email protected]> <[email protected]>
<[email protected]>
<[email protected]> <[email protected]>
<[email protected]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed

On Sat, 22 Apr 2006, Carl Baltrunas wrote:
> As of TOPS-10 7.03 [circa 1985] (the last brush I had with a running
> TOPS-10) the only networking support was for ANF-10, DECnet or LAT and
> there was no FTP server or client since neither NCP nor TCP had been
> injected.

DEC never did ARPAnet (NCP) or Internet (TCP) for TOPS-10. However, there
was a non-DEC NCP, and later a TCP, for TOPS-10. Don Provan at LLL was
associated with TOPS-10 TCP.

-- Mark --

http://panda.com/tops-20
TOPS-20: a great improvement over its successors
23-Apr-2006 01:14:49-PDT,2711;000000000000
Return-Path: <[email protected]>
Received: from elasmtp-banded.atl.sa.earthlink.net ([209.86.89.70]) by lingling.panda.com with TCP/SMTP; Sun, 23 Apr 2006 01:12:27 -0700 (PDT)
Received: from [24.221.177.162] (helo=[204.238.239.105])
by elasmtp-banded.atl.sa.earthlink.net with asmtp (Exim 4.34)
id 1FXZhd-0006Mz-BW; Sun, 23 Apr 2006 04:12:21 -0400
In-Reply-To: <[email protected]>
References: <[email protected]> <[email protected]> <[email protected]> <[email protected]> <[email protected]> <[email protected]> <[email protected]> <[email protected]> <[email protected]> <[email protected]> <[email protected]> <[email protected]>
Mime-Version: 1.0 (Apple Message framework v749.3)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <[email protected]>
Cc: [email protected]
Content-Transfer-Encoding: 7bit
From: Carl Baltrunas <[email protected]>
Subject: Re: Tops-20 FTP client Passive Mode
Date: Sun, 23 Apr 2006 01:12:38 -0700
To: Rich Alderson <[email protected]>
X-Mailer: Apple Mail (2.749.3)
X-ELNK-Trace: 657dc9a5ceb70f7f3e74c9a82e36a01394f5150ab1c16ac04be4f309a0cc41dd4d6161396695064d5dda444e9f5ef89d350badd9bab72f9c350badd9bab72f9c
X-Originating-IP: 24.221.177.162

On Apr 22, 2006, at 8:08 PM, Rich Alderson wrote:
>> From: Carl Baltrunas <[email protected]>
>> Date: Sat, 22 Apr 2006 16:02:47 -0700
>
>> As of TOPS-10 7.03 [circa 1985] (the last brush I had with a running
>> TOPS-10) the only networking support was for ANF-10, DECnet or LAT
>> and
>> there was no FTP server or client since neither NCP nor TCP had been
>> injected. I don't remember anything in RSX-11M at that time
>> either, so
>> definitely nothing in RSX-20F.
>
> Peter Lothberg has told me that there was a TCP/IP implementation
> done for
> 7.02 using the front-end, and that he has the tapes somewhere. If
> anyone
> is interested in resurrecting this and bringing it forward to 7.04,
> he'd be
> willing to dig these out.
>
Hmmm. Now you've piqued my interest Rich. At a 7.03 internals class at
the DEC DDC in Colorado, I don't recall much in the way of networking.

Did Peter say who did the TCP for 7.02, since we all know that it was
never
a DEC product. Anyone know if DEC tried a TCP implementation in-house
but never let it out?

-Carl

23-Apr-2006 09:29:40-PDT,2355;000000000000
Return-Path: <[email protected]>
Received: from ics.com (mx.ics.com [209.59.5.4]) by lingling.panda.com with TCP/SMTP; Sun, 23 Apr 2006 09:27:11 -0700 (PDT)
Received: from c-66-30-204-193.hsd1.ma.comcast.net (c-66-30-204-193.hsd1.ma.comcast.net [66.30.204.193])
by ics.com (8.12.9p1/8.12.9) with SMTP id k3NGQsp6079079;
Sun, 23 Apr 2006 12:26:54 -0400 (EDT)
(envelope-from [email protected])
Received: (from phil@localhost)
by ultimate.com (8.13.6/8.13.6) id k3NGQOmY003716;
Sun, 23 Apr 2006 12:26:24 -0400 (EDT)
Date: Sun, 23 Apr 2006 12:26:24 -0400 (EDT)
From: Phil Budne <[email protected]>
Message-Id: <[email protected]>
To: [email protected], [email protected]
Subject: Re: Tops-20 FTP client Passive Mode
Cc: [email protected]

> Date: Sat, 22 Apr 2006 23:08:21 -0400 (EDT)
> From: Rich Alderson <[email protected]>
>
> Peter Lothberg has told me that there was a TCP/IP implementation done for
> 7.02 using the front-end, and that he has the tapes somewhere. If anyone
> is interested in resurrecting this and bringing it forward to 7.04, he'd be
> willing to dig these out.

You can find the sources for the monitor run on KICKI (Dual KI10) at:

ftp://ftp.stacken.kth.se/pub/pdp10/kicki/

This however, includes none of the user-mode programs
(including the one used to establish new TCP connections).

I believe there are also sources for a from-scratch UDP implementation
(using simulated DEUNA under SIMH?) for 7.04 along with a TFTP implementation.

> From: Carl Baltrunas <[email protected]>
> Date: Sun, 23 Apr 2006 01:12:38 -0700
> > Peter Lothberg has told me that there was a TCP/IP implementation
> > done for
> > 7.02 using the front-end, and that he has the tapes somewhere. If
> > anyone
> > is interested in resurrecting this and bringing it forward to 7.04,
> > he'd be
> > willing to dig these out.
> >
> Hmmm. Now you've piqued my interest Rich. At a 7.03 internals class at
> the DEC DDC in Colorado, I don't recall much in the way of networking.
>
> Did Peter say who did the TCP for 7.02, since we all know that it was
> never a DEC product.

Don Provan's name appears in the sources.

> Anyone know if DEC tried a TCP implementation in-house but never let it out?

No, not to my knowledge.
27-Apr-2006 09:19:06-PDT,2227;000000000000
Return-Path: <[email protected]>
Received: from sesame.cc.columbia.edu ([128.59.59.56]) by lingling.panda.com with TCP/SMTP; Thu, 27 Apr 2006 09:17:14 -0700 (PDT)
Received: from sesame.cc.columbia.edu (localhost [127.0.0.1])
by sesame.cc.columbia.edu (8.13.6/8.13.0) with ESMTP id k3RGH9rK008661
for <[email protected]>; Thu, 27 Apr 2006 12:17:09 -0400 (EDT)
Received: (from fdc@localhost)
by sesame.cc.columbia.edu (8.13.6/8.12.8/Submit) id k3RGH5dS008660
for [email protected]; Thu, 27 Apr 2006 12:17:05 -0400 (EDT)
Date: Thu, 27 Apr 2006 12:17:05 EDT
From: Frank da Cruz <[email protected]>
To: [email protected]
Subject: Announcing Kermit-10 3.136
Message-ID: <[email protected]>

An update to PDP-10 DECsystem-10 Kermit from Nick Bush, one of the original
authors. This was one of the first Kermit programs written outside of
Columbia University, and it was written to be portable to three different
Digital Equipment Corporation platforms: the PDP-10 with TOPS-10, the VAX
with VMS, and the Professional 350 and 380 PDP-11 based workstations with
P/OS, the main three platforms in use at Stevens Institute of Technology in
1983, where Nick worked at the time.

While P/OS is long forgotten, VMS is still surprisingly strong after nearly
30 years (but nowadays we use C-Kermit there rather than Stevens'
Kermit-32). The 36-bit PDP-10, like its sibling the DECSYSTEM-20, were
highly influential machines of the 1970s and 80s. Although a few are still
operational, the resurgence of interest in them comes from the recent
availability of hardware emulators for these machines that can be run on
today's desktop architectures.

The new release of PDP-10 Kermit, Kermit-10 3.136, unifies the various
patches that have come in since Stevens halted development 20 years ago,
and also fixes a few bugs, notably incorrect terminal modes upon return from
CONNECT mode (e.g. ESC would echo as $).

Thanks to Nick for remembering how to do this!

The new version is accessible from the PDP-10 Kermit page:

http://www.columbia.edu/kermit/pdp10.html

as is information about the PDP-10 emulators and related topics.

- Frank
17-May-2006 08:07:56-PDT,430;000000000000
Mail-From: MRC created at 17-May-2006 08:06:05
Date: Wed, 17 May 2006 08:06:05 -0700 (PDT)
From: Mark Crispin <[email protected]>
Subject: 23 years ago today...
To: [email protected]
Pithy-Thought: TOPS-20 was a great improvement over its successors
Message-ID: <[email protected]>

23 years ago today at 2PM Eastern time, Ken Olsen and Bill Johnson cancelled
Project Jupiter.
-------
17-May-2006 16:10:31-PDT,1850;000000000000
Return-Path: <[email protected]>
Received: from smtpout.mac.com ([17.250.248.177]) by lingling.panda.com with TCP/SMTP; Wed, 17 May 2006 16:08:10 -0700 (PDT)
Received: from mac.com (smtpin01-en2 [10.13.10.146])
by smtpout.mac.com (Xserve/8.12.11/smtpout07/MantshX 4.0) with ESMTP id k4HN857M000639
for <[email protected]>; Wed, 17 May 2006 16:08:05 -0700 (PDT)
Received: from [192.168.1.52] (c-24-147-40-233.hsd1.nh.comcast.net [24.147.40.233])
(authenticated bits=0)
by mac.com (Xserve/smtpin01/MantshX 4.0) with ESMTP id k4HN7w78006534
for <[email protected]>; Wed, 17 May 2006 16:08:04 -0700 (PDT)
Mime-Version: 1.0
Message-Id: <p06230912c0915cfb0351@[192.168.1.52]>
In-Reply-To: <[email protected]>
References: <[email protected]>
Date: Wed, 17 May 2006 19:08:08 -0400
To: [email protected]
From: John Francini <[email protected]>
Subject: Re: 23 years ago today...
Content-Type: text/plain; charset="us-ascii" ; format="flowed"

In 23-year hindsight, it was quite definitely a "Day the (computing)
Universe Changed".

And the repercussions are still being felt.

j

At 8:06 -0700 5/17/06, Mark Crispin wrote:
>23 years ago today at 2PM Eastern time, Ken Olsen and Bill Johnson cancelled
>Project Jupiter.
>-------

--
----
John Francini <mailto:[email protected]>
+---------------------------------------------------------------------------+
| "I have come to the conclusion that one useless man is called a disgrace; |
| that two are called a law firm; and that three or more become a Congress.|
| And by God I have had _this_ Congress!" |
| -- John Adams |
+---------------------------------------------------------------------------+
1-Jun-2006 15:46:58-PDT,3425;000000000000
Return-Path: <[email protected]>
Received: from mxout7.cac.washington.edu ([140.142.32.178]) by lingling.panda.com with TCP/SMTP; Thu, 1 Jun 2006 15:44:32 -0700 (PDT)
Received: from smtp.washington.edu (smtp.washington.edu [140.142.33.9])
by mxout7.cac.washington.edu (8.13.6+UW06.03/8.13.6+UW06.03) with ESMTP id k51MiQcS015552
for <[email protected]>; Thu, 1 Jun 2006 15:44:26 -0700
X-Auth-Received: from Tomobiki-Cho.CAC.Washington.EDU (tomobiki-cho.cac.washington.edu [128.95.135.58])
(authenticated authid=mrc)
by smtp.washington.edu (8.13.6+UW06.03/8.13.6+UW06.03) with ESMTP id k51MiPxF016198
(version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT)
for <[email protected]>; Thu, 1 Jun 2006 15:44:26 -0700
Date: Thu, 1 Jun 2006 15:44:26 -0700 (Pacific Daylight Time)
From: Mark Crispin <[email protected]>
To: TOPS-20 Hackers and Yackers <[email protected]>
Subject: sad news: Alan Kotok
Message-ID: <[email protected]>
Organization: Networks & Distributed Computing
Sender: [email protected]
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
X-Uwash-Spam: Gauge=IIIIIII, Probability=7%, Report='__CP_URI_IN_BODY 0, __CT 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0'

Another giant passes... :-(

-- Mark --

http://staff.washington.edu/mrc
Science does not emerge from voting, party politics, or public debate.
Si vis pacem, para bellum.

---------- Forwarded message ----------
Date: Wed, 31 May 2006 14:15:33 -0400
From: Tim Berners-Lee <[email protected]>
To: W3T Team <[email protected]>
Subject: Very sad news
Resent-Date: Wed, 31 May 2006 18:15:58 +0000
Resent-From: [email protected]

Dear W3C team-mates,

With the greatest of sorrow we share the news that our great
friend, colleague, and mentor Alan Kotok has passed away.

Alan's daughter Leah had come to visit him on a whim Thursday
evening and had dinner with him. She said he was fine when
she left. Alan apparently died peacefully sleeping in his
lounge chair Thursday night. He had told Leah that he was
intending to go to his Cape May home for the weekend and
not take his laptop with him. Ralph, Susan and Amy discovered that
he had passed away when went to his home.

The world has lost a beautiful, sweet, kind person. He's been
with W3C since before it was conceived ... in fact he largely
conceived it.

He's an incredibly integral part of the team -- his spirit
is so much the spirit of positively working together and having
fun. He is so benevolent. He's just kind -- sometimes in a
friendly way and sometimes in a quite paternal way. He's done
all kinds of work, and he's expressed his opinions on all kinds
of things, and he's taken on things difficult, exciting or boring.
I'm not going to make a list of all he has done, as it would make
a very long message.

A group of people like W3T goes through many ups and downs together,
and we know that we have been through a lot of crises and celebrations.
This is a blow of the sort we have not had to face before.

We have had the benefit of knowing a wonderful and extraordinary
person.
We will celebrate him in many ways in days to come.

Now, though, we just sit stunned by our loss, contemplating the void
suddenly left within us.

Tim and Ralph

1-Jun-2006 23:11:50-PDT,1052;000000000000
Return-Path: <[email protected]>
Received: from a.mail.sonic.net ([64.142.16.245]) by Lingling.Panda.COM with TCP/SMTP; Thu, 1 Jun 2006 23:10:17 -0700 (PDT)
Received: from Amiga.local (64-142-29-114.dsl.static.sonic.net [64.142.29.114])
by a.mail.sonic.net (8.13.6/8.13.3) with ESMTP id k526ADql014284
for <[email protected]>; Thu, 1 Jun 2006 23:10:13 -0700
Date: Thu, 1 Jun 2006 23:10:12 -0700 (PDT)
From: Fred Wright <[email protected]>
X-Sender: [email protected]
Reply-To: Fred Wright <[email protected]>
To: TOPS-20 Hackers and Yackers <[email protected]>
Subject: Re: sad news: Alan Kotok
In-Reply-To: <[email protected]>
Message-ID: <[email protected]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

On Thu, 1 Jun 2006, Mark Crispin wrote:

> Another giant passes... :-(

That's a shame. I actually just saw him a couple of weeks ago at CHM's
PDP-1 event. Looked fine except for having less hair.

Fred Wright

2-Jun-2006 07:32:44-PDT,1026;000000000000
Return-Path: <[email protected]>
Received: from pangtzu.panda.com ([206.124.149.117]) by Lingling.Panda.COM with TCP/SMTP; Fri, 2 Jun 2006 07:31:09 -0700 (PDT)
Date: Fri, 2 Jun 2006 07:31:06 -0700 (PDT)
From: Mark Crispin <[email protected]>
Sender: [email protected]
To: Fred Wright <[email protected]>
cc: TOPS-20 Hackers and Yackers <[email protected]>
Subject: Re: sad news: Alan Kotok
In-Reply-To: <[email protected]>
Message-ID: <[email protected]>
References: <[email protected]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed

On Thu, 1 Jun 2006, Fred Wright wrote:
> That's a shame. I actually just saw him a couple of weeks ago at CHM's
> PDP-1 event. Looked fine except for having less hair.

According to the orbituary he was just 64 years old.

-- Mark --

http://panda.com/tops-20
TOPS-20: a great improvement over its successors
5-Jun-2006 09:01:43-PDT,3891;000000000000
Return-Path: <[email protected]>
Received: from ccerelbas01.cce.hp.com ([161.114.21.104]) by lingling.panda.com with TCP/SMTP; Mon, 5 Jun 2006 08:59:18 -0700 (PDT)
Received: from cceexg13.americas.cpqcorp.net (cceexg13.americas.cpqcorp.net [16.81.1.58])
by ccerelbas01.cce.hp.com (Postfix) with ESMTP id 9CDF834360;
Mon, 5 Jun 2006 10:59:09 -0500 (CDT)
Received: from cxoexc11.americas.cpqcorp.net ([16.112.229.1]) by cceexg13.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.1830);
Mon, 5 Jun 2006 10:59:09 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: sad news: Alan Kotok
Date: Mon, 5 Jun 2006 09:59:07 -0600
Message-ID: <9B832BEB407A774AA0520CCFC23221970A09E9B5@CXOEXC11.AMERICAS.CPQCORP.NET>
In-Reply-To: <[email protected]>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: sad news: Alan Kotok
Thread-Index: AcaIuPogHB3yHXl6Q9a35LIHasppsw==
From: "Marzulla, Lorrie" <[email protected]>
To: "Mark Crispin" <[email protected]>,
"TOPS-20 Hackers and Yackers" <[email protected]>
X-OriginalArrivalTime: 05 Jun 2006 15:59:09.0390 (UTC) FILETIME=[FB0C86E0:01C688B8]

Thanks for sending this information out to us Mark as it as this very
sad news and has made its way to the Digital Alumni dist. list - we all
remember and revere Alan Kotok and I believe he was badge #9 for our
beloved company.

Lorrie Marzulla

-----Original Message-----
From: [email protected] [mailto:[email protected]]
On Behalf Of Mark Crispin
Sent: Thursday, June 01, 2006 4:44 PM
To: TOPS-20 Hackers and Yackers
Subject: sad news: Alan Kotok

Another giant passes... :-(

-- Mark --

http://staff.washington.edu/mrc
Science does not emerge from voting, party politics, or public debate.
Si vis pacem, para bellum.

---------- Forwarded message ----------
Date: Wed, 31 May 2006 14:15:33 -0400
From: Tim Berners-Lee <[email protected]>
To: W3T Team <[email protected]>
Subject: Very sad news
Resent-Date: Wed, 31 May 2006 18:15:58 +0000
Resent-From: [email protected]

Dear W3C team-mates,

With the greatest of sorrow we share the news that our great friend,
colleague, and mentor Alan Kotok has passed away.

Alan's daughter Leah had come to visit him on a whim Thursday evening
and had dinner with him. She said he was fine when she left. Alan
apparently died peacefully sleeping in his lounge chair Thursday night.
He had told Leah that he was intending to go to his Cape May home for
the weekend and not take his laptop with him. Ralph, Susan and Amy
discovered that he had passed away when went to his home.

The world has lost a beautiful, sweet, kind person. He's been with W3C
since before it was conceived ... in fact he largely conceived it.

He's an incredibly integral part of the team -- his spirit is so much
the spirit of positively working together and having
fun. He is so benevolent. He's just kind -- sometimes in a
friendly way and sometimes in a quite paternal way. He's done all kinds
of work, and he's expressed his opinions on all kinds of things, and
he's taken on things difficult, exciting or boring.
I'm not going to make a list of all he has done, as it would make a very
long message.

A group of people like W3T goes through many ups and downs together, and
we know that we have been through a lot of crises and celebrations.
This is a blow of the sort we have not had to face before.

We have had the benefit of knowing a wonderful and extraordinary person.
We will celebrate him in many ways in days to come.

Now, though, we just sit stunned by our loss, contemplating the void
suddenly left within us.

Tim and Ralph

12-Jun-2006 17:38:53-PDT,662;000000000000
Return-Path: <[email protected]>
Received: from xkleten.paulallen.com ([216.220.195.4]) by lingling.panda.com with TCP/SMTP; Mon, 12 Jun 2006 17:35:37 -0700 (PDT)
Date: Mon, 12 Jun 2006 17:35:06 -0700
From: Jon Solomon <[email protected]>
Subject: exec
To: [email protected]
Reply-to: [email protected]
Message-ID: <[email protected]>

I was thinking of creating an EXEC which will run on both XKL and
Panda. I would be interested in doing it for any other TOPS-20
system available....

What I need now is a copy of the PANDA exec sources... I Don't
currently have a machine which has them.

-------
15-Jun-2006 13:32:20-PDT,1092;000000000000
Return-Path: <[email protected]>
Received: from TheWorld.com (pcls2.std.com [192.74.137.142]) by Lingling.Panda.COM with TCP/SMTP; Thu, 15 Jun 2006 13:30:37 -0700 (PDT)
Received: from shell.TheWorld.com ([email protected] [192.74.137.71])
by TheWorld.com (8.12.8p1/8.12.8) with ESMTP id k5FKK4Is019420
for <[email protected]>; Thu, 15 Jun 2006 16:22:12 -0400
Received: (from jsol@localhost)
by shell.TheWorld.com (8.9.3/8.9.3) id PAA961209;
Thu, 15 Jun 2006 15:56:42 -0400 (EDT)
Date: Thu, 15 Jun 2006 15:56:42 -0400 (EDT)
Message-Id: <[email protected]>
From: "Jonathan A. Solomon" <[email protected]>
To: [email protected]
Subject: panda exec sources
X-Spam-Status: No, score=-4.3 required=10.0 tests=ALL_TRUSTED,AWL,BAYES_00
autolearn=ham version=3.1.0
X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on pcls2.std.com
X-Virus-Scanned: ClamAV 0.88/1539/Wed Jun 14 10:21:49 2006 on pcls2.std.com
X-Virus-Status: Clean

Does anyone here have access to the panda exec sources?

thanx in advance.

15-Jun-2006 16:43:13-PDT,1183;000000000000
Return-Path: <[email protected]>
Received: from TheWorld.com (pcls2.std.com [192.74.137.142]) by Lingling.Panda.COM with TCP/SMTP; Thu, 15 Jun 2006 16:39:31 -0700 (PDT)
Received: from shell.TheWorld.com ([email protected] [192.74.137.71])
by TheWorld.com (8.12.8p1/8.12.8) with ESMTP id k5FNdQIi011513
for <[email protected]>; Thu, 15 Jun 2006 19:39:26 -0400
Received: (from jsol@localhost)
by shell.TheWorld.com (8.9.3/8.9.3) id TAA968409;
Thu, 15 Jun 2006 19:39:25 -0400 (EDT)
Date: Thu, 15 Jun 2006 19:39:25 -0400 (EDT)
Message-Id: <[email protected]>
From: "Jonathan A. Solomon" <[email protected]>
To: [email protected]
Subject: panda exec sources
X-Spam-Status: No, score=-4.3 required=10.0 tests=ALL_TRUSTED,AWL,BAYES_00
autolearn=ham version=3.1.0
X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on pcls2.std.com
X-Virus-Scanned: ClamAV 0.88/1542/Thu Jun 15 17:32:01 2006 on pcls2.std.com
X-Virus-Status: Clean

I can set up a directory which you can log in through anonymous FTP.
You don't have to set up anything...

I really appreciate the panda EXEC-SOURCES files.

--jsol

16-Jun-2006 07:13:19-PDT,7461;000000000000
Return-Path: <[email protected]>
Received: from wr-out-0506.google.com ([64.233.184.232]) by Lingling.Panda.COM with TCP/SMTP; Fri, 16 Jun 2006 07:11:02 -0700 (PDT)
Received: by wr-out-0506.google.com with SMTP id i11so555884wra
for <[email protected]>; Fri, 16 Jun 2006 07:10:57 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
s=beta; d=gmail.com;
h=received:message-id:date:from:to:subject:mime-version:content-type;
b=bD7lczvkp8OiF9qgvMnpcCf5Bzt72AgCRuw8TtDClwZliPp+JWFhgF2WlOx7sBzwACz4Gqtvfnyzgmf4DA2Bw1IqI6lISY+4jrtxgHMwWu3L+UgdyMpJib3FvHWQ9atajiy3JVyL1lfIgFKnneFqQ2EvqwB7HwwQ8e0MUs2msn0=
Received: by 10.65.93.20 with SMTP id v20mr1654234qbl;
Fri, 16 Jun 2006 07:10:57 -0700 (PDT)
Received: by 10.64.49.16 with HTTP; Fri, 16 Jun 2006 07:10:57 -0700 (PDT)
Message-ID: <[email protected]>
Date: Fri, 16 Jun 2006 08:10:57 -0600
From: "Chris Smith" <[email protected]>
To: [email protected]
Subject: lcc progress report, also lack of progress
MIME-Version: 1.0
Content-Type: multipart/alternative;
boundary="----=_Part_4236_15604828.1150467057200"

------=_Part_4236_15604828.1150467057200
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

Hi there --

I thought I'd describe some work I did on lcc, Hanson and Fraser's
lightweight cc, for pdp10's, just tops-20 so far.

It's c89, meaning it has prototypes, meaning it's much nicer to use
than K&R C as in kcc. Also void* and such amenities.

I have it passing its self tests and some c89 validation suites, using
kcc's libc and therefore kcc's calling conventions and crt0 and so on.

The compiler proper, RCC.EXE -- equivalent of cc1 -- fits in half a
section, barely -- pages 1400-1713 plus whatever kcc's runtime is
using sections 2 and 3 for, I forget, plus some other grot in section 1,
which I also forget.

As a proof of concept, it will do, but as a compiler, not soup yet.
In particular:

- lcc handles two-address machines by basically pretending they are
three address machines then at the last minute doing

MOVE dest,op1
OP dest,op2

if necessary. (Boy is the pdp10 arg order backwards, but I digress.)
This does not totally work -- dest and op2 must not be the same.

I handled this in a very gcclike way, by describing a mythical
three-address pdp10

ADD AC3,AC7,MEM

and expanding these pseudoinstructions at assembly time into e.g.
MOVE/ADD/MOVEM. Something like 2x or 3x code bloat and performance
penalty, but correct.

The intent is to eventually generate a simple 10ish IR that can
easily be compiled to macro/fail/midas by a simple postpass that
could optionally be less simple -- hairier register allocation, etc.
kcc does a large number of cool peephole optimizations.

- MACRO and LINK do not understand long symbols. This is needed
in practice.

- c89 uses L"string" for 16-bit chars, suggesting the obvious
6"string" 7"string" 8"string" 9"string" 18"string" for kcc
strings currently denoted by the kludgy ((char7 *) "string")
notation. lcc could support the kludge, but why? At present
it does not support any extensions, including most especially
#asm, needed to compile libc.

- kcc calling conventions empty the registers at all calls.
lcc can, and wants to, do better than this. Putting everything
in memory generates crummy code even by lcc standards. Porting
kcc's libc would allow this to be changed easily.

There's more, but nothing that comes to mind at the moment, this is
all from sometime back in 2004. I know there's a gcc port, or at
least part of one. Is there any hope of that running on a 10? gcc's
code is not going to fit in a section. Has the gcc work solved any of
the above?

-- Chris Smith

------=_Part_4236_15604828.1150467057200
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

Hi there --<br>
<br>
I thought I'd describe some work I did on lcc, Hanson and Fraser's<br>
lightweight cc, for pdp10's, just tops-20 so far.<br>
<br>
It's c89, meaning it has prototypes, meaning it's much nicer to use<br>
than K&R C as in kcc.  Also void* and such amenities.<br>
<br>
I have it passing its self tests and some c89 validation suites, using<br>
kcc's libc and therefore kcc's calling conventions and crt0 and so on.<br>
<br>
The compiler proper, RCC.EXE -- equivalent of cc1 -- fits in half a<br>
section, barely -- pages 1400-1713 plus whatever kcc's runtime is<br>
using sections 2 and 3 for, I forget, plus some other grot in section 1, <br>
which I also forget.<br>
<br>
As a proof of concept, it will do, but as a compiler, not soup yet.<br>
In particular:<br>
<br>
 - lcc handles two-address machines by basically pretending they are<br>
   three address machines then at the last minute doing<br>
<br>
     MOVE dest,op1<br>
     OP dest,op2<br>
<br>
   if necessary.  (Boy is the pdp10 arg order backwards, but I digress.)<br>
   This does not totally work -- dest and op2 must not be the same.<br>
<br>
   I handled this in a very gcclike way, by describing a mythical<br>
   three-address pdp10<br>
<br>
     ADD AC3,AC7,MEM<br>
<br>
   and expanding these pseudoinstructions at assembly time into e.g.<br>
   MOVE/ADD/MOVEM.  Something like 2x or 3x code bloat and performance<br>
   penalty, but correct.<br>
<br>
   The intent is to eventually generate a simple 10ish IR that can<br>
   easily be compiled to macro/fail/midas by a simple postpass that<br>
   could optionally be less simple -- hairier register allocation, etc.<br>
   kcc does a large number of cool peephole optimizations.<br>
<br>
 - MACRO and LINK do not understand long symbols.  This is needed<br>
   in practice.<br>
<br>
 - c89 uses L"string" for 16-bit chars, suggesting the obvious<br>
   6"string" 7"string" 8"string" 9"string" 18"string" for kcc<br>
   strings currently denoted by the kludgy ((char7 *) "string")<br>
   notation.  lcc could support the kludge, but why?  At present<br>
   it does not support any extensions, including most especially<br>
   #asm, needed to compile libc.<br>
<br>
 - kcc calling conventions empty the registers at all calls.<br>
   lcc can, and wants to, do better than this.  Putting everything<br>
   in memory generates crummy code even by lcc standards.  Porting<br>
   kcc's libc would allow this to be changed easily.<br>
<br>
There's more, but nothing that comes to mind at the moment, this is<br>
all from sometime back in 2004.  I know there's a gcc port, or at<br>
least part of one.  Is there any hope of that running on a 10?  gcc's<br>
code is not going to fit in a section.  Has the gcc work solved any of<br>
the above?<br>
<br>
-- Chris Smith<br>
<br>

------=_Part_4236_15604828.1150467057200--
16-Jun-2006 11:49:40-PDT,878;000000000000
Mail-From: MRC created at 16-Jun-2006 11:48:01
Date: Fri, 16 Jun 2006 11:48:01 -0700 (PDT)
From: Mark Crispin <[email protected]>
Subject: Re: lcc progress report, also lack of progress
To: [email protected]
cc: [email protected]
In-Reply-To: <[email protected]>
Pithy-Thought: TOPS-20 was a great improvement over its successors
Message-ID: <[email protected]>

I don't understand your comment about prototypes. KCC most certainly
has prototypes. The UW IMAP toolkit uses prototypes; and the c-client
library and the mtest and mailutil applications both build with KCC on
TOPS-20. KCC also has void*.

I believe that XKL made LINK do long symbols, but I just have a system
of #define definitions that I have in a TOPS-20 only file to shorten all
the long global symbols.
-------
16-Jun-2006 13:13:42-PDT,1546;000000000000
Return-Path: <[email protected]>
Received: from TheWorld.com (pcls2.std.com [192.74.137.142]) by lingling.panda.com with TCP/SMTP; Fri, 16 Jun 2006 13:12:12 -0700 (PDT)
Received: from shell.TheWorld.com ([email protected] [192.74.137.71])
by TheWorld.com (8.12.8p1/8.12.8) with ESMTP id k5GKA75c027319
for <[email protected]>; Fri, 16 Jun 2006 16:11:24 -0400
Received: (from jsol@localhost)
by shell.TheWorld.com (8.9.3/8.9.3) id PAA1048204;
Fri, 16 Jun 2006 15:59:06 -0400 (EDT)
Date: Fri, 16 Jun 2006 15:59:06 -0400 (EDT)
Message-Id: <[email protected]>
From: "Jonathan A. Solomon" <[email protected]>
to: [email protected]
Subject: exec sources
X-Spam-Status: No, score=-4.3 required=10.0 tests=ALL_TRUSTED,AWL,BAYES_00
autolearn=ham version=3.1.0
X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on pcls2.std.com
X-Virus-Scanned: ClamAV 0.88/1546/Fri Jun 16 09:41:54 2006 on pcls2.std.com
X-Virus-Status: Clean

Looks like the exec changes I needed to make were able to be done
without your panda exec sources. I still want a copy for my
own hacking.

It also looks like I was the one who broke the exec sources for
XKL.

What happened is in execca.mac, the command
T SUBSYSTEM-STATISTICS,NOLG+ONEWRD,SUBSTA ;[jsol]

to

T SUBSYSTEM-STATISTICS,ONEWRD,SUBSTA ;[new jsol]

Just wanted you to share my embarrassment.

I noticed it when not-logged in execs worked with
@info subsystem-status but logged in execs don't.

--jsol
16-Jun-2006 22:27:07-PDT,15626;000000000000
Return-Path: <[email protected]>
Received: from pangtzu.panda.com ([206.124.149.117]) by lingling.panda.com with TCP/SMTP; Fri, 16 Jun 2006 22:25:21 -0700 (PDT)
Date: Fri, 16 Jun 2006 22:25:17 -0700 (PDT)
From: Mark Crispin <[email protected]>
Sender: [email protected]
To: TOPS-20 Hackers and Yackers <[email protected]>
Subject: address break patch for klh10
Message-ID: <[email protected]>
MIME-Version: 1.0
Content-Type: MULTIPART/MIXED; BOUNDARY="0-1145418779-1150521917=:5764"

This message is in MIME format. The first part should be readable text,
while the remaining parts are likely unreadable without MIME-aware tools.

--0-1145418779-1150521917=:5764
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed

The attached patch, courtesy of Chris Smith, implements address break in
klh10. As of June 15, 2006, this is now part of the standard Panda
distribution.

I did some performance testing, and it appears that address break support
in the microcode causes only a modest performance hit, about 2.4-3.5%.
It's easy enough to get much more than that back simply by upgrading the
motherboard and processor to something faster. So I consider it to be
well worth the cost.

Of course, XKL has had address break on their processors all along. But
for the Panda world, it's been a hiatus of nearly 13 years (since
September 30, 1993 when SIMTEL20 shut down). KS10s don't have address
break, so I didn't have it on my 2020s.

SET ADDRESS-BREAK now works again! Yippee!

-- Mark --

http://panda.com/tops-20
TOPS-20: a great improvement over its successors
--0-1145418779-1150521917=:5764
Content-Type: TEXT/PLAIN; charset=US-ASCII; name=klh10-addrbreak-patch
Content-Transfer-Encoding: BASE64
Content-ID: <[email protected]>
Content-Description: address book patch
Content-Disposition: attachment; filename=klh10-addrbreak-patch

LS0tIGtuMTBkZWYuaC5+MX4JMjAwMS0xMS0xMCAxNToyOTowOC4wMDAwMDAw
MDAgLTA2MDANCisrKyBrbjEwZGVmLmgJMjAwNC0wNC0wMyAxOToxNTozMi4w
MDAwMDAwMDAgLTA2MDANCkBAIC04NTgsOCArODU4LDE3IEBADQogI2VuZGlm
DQogI2lmIEtMSDEwX0NQVV9LUw0KIAl3MTBfdCBtcl9oc2I7CQkvKiBIYWx0
IFN0YXR1cyBCbG9jayBiYXNlIGFkZHJlc3MgKi8NCi0jZWxpZiBLTEgxMF9D
UFVfS0kgfHwgS0xIMTBfQ1BVX0tMDQotCXcxMF90IG1yX2FkcmJyazsJLyog
QWRkcmVzcyBCcmVhayByZWdpc3RlciAqLw0KKyNlbGlmIEtMSDEwX0NQVV9L
TA0KKwl2YWRkcl90IG1yX2Fia19hZGRyOwkvKiBBZGRyZXNzIEJyZWFrIHZp
cnR1YWwgYWRkcmVzcyAqLw0KKwlwYWdub190IG1yX2Fia19wYWdubzsJLyog
UGFnZSBjb250YWluaW5nIGJyZWFrIGFkZHJlc3MsIC0xIGlmIG5vbmUgKi8N
CisJcG1lbnRfdCAqbXJfYWJrX3BtYXA7CS8qIFBhZ2UgbWFwIGNvbnRhaW5p
bmcgYnJlYWsgYWRkcmVzcyBwYWdlICovDQorCXBtZW50X3QgbXJfYWJrX3Bt
ZmxhZ3M7CS8qIFNhdmVkIHBhZ2UgYWNjZXNzIGZsYWdzICYgVk1GX0FDQyAq
Lw0KKwlwbWVudF90IG1yX2Fia19wbW1hc2s7CS8qIE1hc2sgdG8gY2xlYXIg
Vk1GX1JFQUQgYW5kL29yIFZNRl9XUklURSAqLw0KKwlpbnQgbXJfYWJrX2Nv
bmQ7CS8qIEJyZWFrIGNvbmRpdGlvbiBmbGFncywgYXMgZm9sbG93czogKi8N
CisjIGRlZmluZSBBQktfSUZFVENIIDgJCS8qICAgQnJlYWsgb24gaW5zdHJ1
Y3Rpb24gZmV0Y2ggKi8NCisjIGRlZmluZSBBQktfUkVBRCAgIDQJCS8qICAg
QnJlYWsgb24gcmVhZCAqLw0KKyMgZGVmaW5lIEFCS19XUklURSAgMgkJLyog
ICBCcmVhayBvbiB3cml0ZSAqLw0KKyMgZGVmaW5lIEFCS19VU0VSICAgMQkJ
LyogICBCcmVhayBhZGRyZXNzIGlzIHVzZXIgKGVsc2UgZXhlYykgKi8NCiAj
ZW5kaWYNCiAJdzEwX3QgbXJfYXByaWQ7CQkvKiBQcm9jZXNzb3IgSUQgKi8N
CiAJdzEwX3QgbXJfZWJyOwkJLyogRXhlY3V0aXZlIEJhc2UgUmVnaXN0ZXIg
Ki8NCi0tLSBrbjEwcGFnLmgufjF+CTIwMDEtMTEtMTAgMTU6Mjk6MDkuMDAw
MDAwMDAwIC0wNjAwDQorKysga24xMHBhZy5oCTIwMDQtMDQtMDMgMTk6MjY6
NTEuMDAwMDAwMDAwIC0wNjAwDQpAQCAtNDYwLDEzICs0NjAsMjAgQEANCiAj
ZGVmaW5lIFZNRl9OT1RSQVAgKChwbWVudF90KTE8PChQQUdfUE1FQklUUy0z
KSkgLyogRmxhZyBmb3IgcGFnX3JlZmlsbCgpICovDQogCQkJCQkvKiBOT1Qg
dXNlZCBpbiBtYXAgZW50cnkhICovDQogDQotLyogU3lub255bSBmb3IgVk1G
X1JFQUQgdG8gZGlzdGluZ3Vpc2ggaW5zdHJ1Y3Rpb24gZmV0Y2ggcmVmZXJl
bmNlcyBpbiBjYXNlDQotKiogdGhhdCBldmVyIGJlY29tZXMgaW1wb3J0YW50
LiAgRm9yIGV4YW1wbGUsIGl0IG1pZ2h0IHByb3ZpZGUgYSB3YXkNCi0qKiBv
ZiBpbmRpY2F0aW5nIHRoYXQgdGhlIGFkZHJlc3MgKGllIFBDKSBpcyBmb3Jj
aWJseSBpbnRlcnByZXRlZCBhcw0KLSoqIGxvY2FsLg0KLSovDQotI2RlZmlu
ZSBWTUZfRkVUQ0ggKFZNRl9SRUFEKQ0KKy8qIEV4dHJhIGZsYWcgdXNlZCB3
aXRoIFZNRl9SRUFEIHRvIGRpc3Rpbmd1aXNoIGluc3RydWN0aW9uIGZldGNo
DQorKiogcmVmZXJlbmNlcyBmb3IgYWRkcmVzcyBicmVhayBhbmQgd2hhdGV2
ZXIgZWxzZSBiZWNvbWVzIGltcG9ydGFudC4NCisqKiBGb3IgZXhhbXBsZSwg
aXQgbWlnaHQgcHJvdmlkZSBhIHdheSBvZiBpbmRpY2F0aW5nIHRoYXQgdGhl
IGFkZHJlc3MNCisqKiAoaWUgUEMpIGlzIGZvcmNpYmx5IGludGVycHJldGVk
IGFzIGxvY2FsLg0KKyovDQorI2RlZmluZSBWTUZfSUZFVENIICgocG1lbnRf
dCkxPDwoUEFHX1BNRUJJVFMtNCkpIC8qIEZsYWcgZm9yIHBhZ19yZWZpbGwo
KSAqLw0KKyAJCQkJCS8qIE5PVCB1c2VkIGluIG1hcCBlbnRyeSEgKi8NCisj
ZGVmaW5lIFZNRl9GRVRDSCAoVk1GX1JFQUQgfCBWTUZfSUZFVENIKQ0KIA0K
Ky8qIEZsYWcgdXNlZCB3aXRoIFZNRl9SRUFEIG9yIFZNRl9XUklURSB0byBm
bGFnIGRvdWJsZXdvcmQgcmVmcywgc28NCisqKiBhZGRyZXNzIGJyZWFrIGNh
biB0cmFwIGlmIHRoZSBsb3cgd29yZCBoaXRzLg0KKyovDQorI2RlZmluZSBW
TUZfRFdPUkQgKChwbWVudF90KTE8PChQQUdfUE1FQklUUy01KSkgLyogRmxh
ZyBmb3IgcGFnX3JlZmlsbCgpICovDQorIAkJCQkJLyogTk9UIHVzZWQgaW4g
bWFwIGVudHJ5ISAqLw0KIA0KIC8qIFZNX1hNQVAgLSBNYXAgdmlydHVhbCBh
ZGRyZXNzIGluIGdpdmVuIGNvbnRleHQgdG8gcGh5c2ljYWwgYWRkcmVzcy4N
CiAqKglQYWdlIGZhdWx0cyBpZiByZXF1ZXN0ZWQgYWNjZXNzIGNhbm5vdCBi
ZSBncmFudGVkLCB1bmxlc3MNCkBAIC01OTksNyArNjA2LDggQEANCiAqLw0K
ICNkZWZpbmUgdm1fZHJlYWQoYSxkKSBcDQogICAgICh2bV9pc3NhZmVkb3Vi
bGUoYSkJCQkJCS8qIElmIHNhZmUgZG91YmxlLCAqL1wNCi0JPyAoKGQpID0g
dm1fcGdldGQodm1feHJ3bWFwKGEsVk1GX1JFQUQpKSwgMCkJLyogdXNlIGZh
c3Qgd2F5ICovXA0KKwk/ICgoZCkgPSB2bV9wZ2V0ZCh2bV94cndtYXAoYSxW
TUZfUkVBRHxWTUZfRFdPUkQpKSwgMCkgIFwNCisJCQkJCQkJLyogdXNlIGZh
c3Qgd2F5ICovXA0KIAk6ICgoZCkud1swXSA9IHZtX3JlYWQoYSksIAkJCS8q
IFVnaCwgc2xvdyB3YXkgKi9cDQogCQl2YV9pbmMoYSksIChkKS53WzFdID0g
dm1fcmVhZChhKSwgMCkpDQogDQpAQCAtNjE2LDcgKzYyNCw3IEBADQogKi8N
CiAjZGVmaW5lIHZtX2R3cml0ZShhLGQpIFwNCiAJaWYgKHZtX2lzc2FmZWRv
dWJsZShhKSkgewkJLyogSWYgc2FmZSBkb3VibGUsICovXA0KLQkgICB2bV9w
c2V0ZCh2bV94cndtYXAoYSxWTUZfV1JJVEUpLCAoZCkpOyAvKiB1c2UgZmFz
dCB3YXkgKi9cDQorCSAgIHZtX3BzZXRkKHZtX3hyd21hcChhLFZNRl9XUklU
RXxWTUZfRFdPUkQpLCAoZCkpOyAvKiB1c2UgZmFzdCB3YXkgKi9cDQogCX0g
ZWxzZSBpZiAoMSkgewkJCQlcDQogCSAgICByZWdpc3RlciB2bXB0cl90IHAw
X18sIHAxX187CS8qIFVnaCwgc2xvdyB3YXkgKi9cDQogCSAgICBwMF9fID0g
dm1feHJ3bWFwKGEsIFZNRl9XUklURSk7CVwNCi0tLSBrbjEwcGFnLmMufjF+
CTIwMDEtMTEtMTAgMTU6Mjk6MDkuMDAwMDAwMDAwIC0wNjAwDQorKysga24x
MHBhZy5jCTIwMDQtMDQtMDMgMTk6Mjk6NTUuMDAwMDAwMDAwIC0wNjAwDQpA
QCAtMTM2LDYgKzEzNiwxMCBAQA0KICAgICBjcHUucGFnLnByX2VyYSA9IDA7
DQogI2VuZGlmDQogDQorI2lmIEtMSDEwX0NQVV9LTA0KKyAgICBjcHUubXJf
YWJrX3BhZ25vID0gLTE7CS8qIEluaXQgYWRkcmVzcyBicmVhayBwYWdlIHRv
IG5ldmVyIG1hdGNoICovDQorI2VuZGlmDQorDQogICAgIC8qIERvIEFDIGJs
b2NrIGluaXRpYWxpemF0aW9uLiAqLw0KICAgICBjcHUubXJfYWNiY3VyID0g
MDsJCS8qIFNwZWNpZnkgY3VycmVudCBBQyBibG9jayAqLw0KICAgICBhY2Js
a19zZXQoMCwgMCk7CQkvKiBTZXQgdXAgY3VyICYgcHJldiBibG9ja3MgKi8N
CkBAIC0yNTUsNiArMjU5LDkgQEANCiBwYWdfbWFwY2xyKHJlZ2lzdGVyIHBt
ZW50X3QgKnApDQogew0KICAgICBtZW1zZXQoKGNoYXIgKilwLCAwLCBQQUdf
TUFYVklSVFBHUypzaXplb2YoKnApKTsNCisjaWYgS0xIMTBfQ1BVX0tMDQor
ICAgIGNwdS5tcl9hYmtfcG1mbGFncyA9IDA7DQorI2VuZGlmDQogfQ0KIA0K
IC8qIE5vdCBhY3R1YWxseSB1c2VkIGZvciBhbnl0aGluZyAqLw0KQEAgLTI2
Miw2ICsyNjksOSBAQA0KIHBhZ19zZWdjbHIocmVnaXN0ZXIgcG1lbnRfdCAq
cCkNCiB7DQogICAgIG1lbXNldCgoY2hhciAqKXAsIDAsIChQQUdfTUFYVklS
VFBHUy8yKSpzaXplb2YoKnApKTsNCisjaWYgS0xIMTBfQ1BVX0tMDQorICAg
IGNwdS5tcl9hYmtfcG1mbGFncyA9IDA7DQorI2VuZGlmDQogfQ0KIAwNCiAv
KiBDb21tb24gSU8gaW5zdHJ1Y3Rpb25zIHRoYXQgbWFuaXB1bGF0ZSB0aGUg
cGFnaW5nIHN5c3RlbSAqLw0KQEAgLTQ2NCw2ICs0NzQsMTAgQEANCiAgICAg
UENDQUNIRV9SRVNFVCgpOwkJCS8qIEludmFsaWRhdGUgY2FjaGVkIFBDIGlu
Zm8gKi8NCiAgICAgY3B1LnByX3VtYXBbdmFfcGFnZShlKV0gPSAwOwkvKiBa
YXBvISAqLw0KICAgICBjcHUucHJfZW1hcFt2YV9wYWdlKGUpXSA9IDA7DQor
I2lmIEtMSDEwX0NQVV9LTA0KKyAgICBpZiAodmFfcGFnZShlKSA9PSBjcHUu
bXJfYWJrX3BhZ25vKQ0KKwljcHUubXJfYWJrX3BtZmxhZ3MgPSAwOw0KKyNl
bmRpZg0KICAgICByZXR1cm4gUENJTkNfMTsNCiB9DQogDQpAQCAtMTMwNCwy
MSArMTMxOCw1NyBAQA0KIA0KIC8qICg3MDAxNCA9IERBVEFPIEFQUiwpIC0g
S0w6IFNldCBBZGRyZXNzIEJyZWFrIHJlZ2lzdGVyDQogKioJU2V0cyBhZGRy
ZXNzIGJyZWFrIGZyb20gYyhFKS4NCi0qKiBOb3RlOiBUaGlzIGlzIG5vdCBh
Y3R1YWxseSBpbXBsZW1lbnRlZCwgZm9yIG9idmlvdXMgZWZmaWNpZW5jeQ0K
LSoqCXJlYXNvbnMuICBJdCBjZXJ0YWlubHkgKmNvdWxkKiBiZSBpZiB0aGF0
IHByb3ZlZCBkZXNpcmFibGUuDQogKi8NCiBpb2luc2RlZihpb19kb19hcHIp
DQogew0KLSAgICBjcHUubXJfYWRyYnJrID0gdm1fcmVhZChlKTsNCisgICAg
dWludDMyIHc7DQorDQorICAgIC8qIFJlbW92ZSBhbnkgcHJpb3IgYWRkcmVz
cyBicmVhayAqLwkNCisNCisgICAgaWYgKGNwdS5tcl9hYmtfcGFnbm8gIT0g
LTEpIHsNCisNCisJLyogU2V0IHBhZ2VyIGFjY2VzcyBmbGFncyBiYWNrIHRv
IHRoZWlyIHRydWUgdmFsdWUgKi8NCisJY3B1Lm1yX2Fia19wbWFwW2NwdS5t
cl9hYmtfcGFnbm9dIHw9IGNwdS5tcl9hYmtfcG1mbGFnczsNCisNCisJLyog
U2V0IGJyZWFrIHBhZ2UgdG8gdmFsdWUgdGhhdCBuZXZlciBtYXRjaGVzICov
DQorCWNwdS5tcl9hYmtfcGFnbm8gPSAtMTsNCisgICAgfQ0KKw0KKyAgICAv
KiBSZWNvcmQgaW5mbyBmb3IgbmV3IGFkZHJlc3MgYnJlYWssIHNwbGl0IG91
dCBmb3IgZmFzdCBhY2Nlc3MgKi8NCisNCisgICAgdyA9IGZldGNoMzIoZSk7
DQorICAgIGlmICh3ICYgKChBQktfSUZFVENIIHwgQUJLX1JFQUQgfCBBQktf
V1JJVEUpIDw8IFBBR19WQUJJVFMpKSB7DQorDQorCS8qIEJyZWFrIGFkZHJl
c3MsIHBhZ2UgY29udGFpbmluZyBpdCwgYnJlYWsgY29uZGl0aW9ucyAqLw0K
KwljcHUubXJfYWJrX2FkZHIgPSB3ICYgTUFTSzIzOw0KKwljcHUubXJfYWJr
X3BhZ25vID0gdmFfcGFnZShjcHUubXJfYWJrX2FkZHIpOw0KKwljcHUubXJf
YWJrX2NvbmQgPSB3ID4+IFBBR19WQUJJVFM7DQorCQ0KKwkvKiBNYWtlIG1h
c2sgdG8gY2xlYXIgcGFnZSBhY2Nlc3MgZmxhZ3MgdGhhdCBzYXRpc2Z5IGJy
ZWFrIGNvbmRpdGlvbiAqLw0KKwljcHUubXJfYWJrX3BtbWFzayA9IC0xOw0K
KwlpZiAoY3B1Lm1yX2Fia19jb25kICYgKEFCS19JRkVUQ0ggfCBBQktfUkVB
RCkpDQorCSAgICBjcHUubXJfYWJrX3BtbWFzayAmPSB+Vk1GX1JFQUQ7DQor
CWlmIChjcHUubXJfYWJrX2NvbmQgJiBBQktfV1JJVEUpDQorCSAgICBjcHUu
bXJfYWJrX3BtbWFzayAmPSB+Vk1GX1dSSVRFOwkgICAgDQorDQorCS8qIFNh
dmUgcGFnZSBhY2Nlc3MgZmxhZ3MgYW5kIGNsZWFyIHRoZW0gc28gYWxsIHJl
ZnMgY2F1c2UgYSByZWZpbGwgKi8NCisJY3B1Lm1yX2Fia19wbWFwID0NCisJ
ICAgIChjcHUubXJfYWJrX2NvbmQgJiBBQktfVVNFUikgPyBjcHUucHJfdW1h
cCA6IGNwdS5wcl9lbWFwOw0KKwljcHUubXJfYWJrX3BtZmxhZ3MgPSBjcHUu
bXJfYWJrX3BtYXBbY3B1Lm1yX2Fia19wYWdub10gJiBWTUZfQUNDOw0KKwlj
cHUubXJfYWJrX3BtYXBbY3B1Lm1yX2Fia19wYWdub10gJj0gY3B1Lm1yX2Fi
a19wbW1hc2s7DQorICAgIH0NCisNCiAgICAgcmV0dXJuIFBDSU5DXzE7DQog
fQ0KIA0KIC8qICg3MDAwNCA9IERBVEFJIEFQUiwpIC0gS0w6IFJlYWQgQWRk
cmVzcyBCcmVhayByZWdpc3Rlcg0KLSoqCVJlYWRzIGFkZHJlc3MgYnJlYWsg
aW50byBjKEUpLg0KKyoqCVJlYWRzIGFkZHJlc3MgYnJlYWsgY29uZGl0aW9u
cyBpbnRvIGMoRSkuDQogKi8NCiBpb2luc2RlZihpb19kaV9hcHIpDQogew0K
LSAgICB2bV93cml0ZShlLCBjcHUubXJfYWRyYnJrKTsNCisgICAgdzEwX3Qg
dzsNCisgICAgVzEwX1hTRVQgKHcsIGNwdS5tcl9hYmtfY29uZCA8PCAoUEFH
X1ZBQklUUyAtIEgxMEJJVFMpLCAwKTsNCisgICAgdm1fd3JpdGUoZSwgdyk7
DQogICAgIHJldHVybiBQQ0lOQ18xOw0KIH0NCiANCkBAIC0xNDY0LDExICsx
NTE0LDM5IEBADQogew0KICAgICByZWdpc3RlciB2bXB0cl90IHZtcDsNCiAg
ICAgcmVnaXN0ZXIgaDEwX3QgcGZsaDsNCisgICAgcmVnaXN0ZXIgcGFnbm9f
dCB2cGFnOw0KKw0KKyAgICB2cGFnID0gdmFfeGFwYWdlKGUpOw0KKw0KKyNp
ZiBLTEgxMF9DUFVfS0wNCisgICAgLyogSWYgYW4gYWRkcmVzcyBicmVhayBp
cyBzZXQsIHNlZSBpZiB0aGlzIHZhZGRyIGlzIGluIHRoYXQgcGFnZSAqLw0K
KyAgICBpZiAodnBhZyA9PSBjcHUubXJfYWJrX3BhZ25vICYmIHAgPT0gY3B1
Lm1yX2Fia19wbWFwKSB7DQorCS8qIFBhZ2UgZmF1bHQgaWYgd2UgaGl0IHRo
ZSBhZGRyZXNzIGFuZCBzYXRpc2Z5IHRoZSBjb25kaXRpb25zICovDQorCWlm
ICgoZSA9PSBjcHUubXJfYWJrX2FkZHINCisJICAgICB8fCAoKGYgJiBWTUZf
RFdPUkQpICYmIGUgKyAxID09IGNwdS5tcl9hYmtfYWRkcikpDQorCSAgICAm
JiAhIGNwdS5tcl9pbmFmaQ0KKwkgICAgLyogUmVhZC1tb2RpZnktd3JpdGUg
Y3ljbGVzIHJlcXVlc3QgVk1GX1dSSVRFIG9ubHksIHNvDQorCSAgICAqKiBh
c3N1bWUgQUJLX1JFQUQgaGl0cyB3aGV0aGVyIG9yIG5vdCBWTUZfUkVBRCBp
cyBvbg0KKwkgICAgKi8NCisJICAgICYmICgoZiAmIFZNRl9XUklURSkgJiYg
KGNwdS5tcl9hYmtfY29uZCAmIEFCS19XUklURSkNCisJCXx8ICgoZiAmIFZN
Rl9JRkVUQ0gpID8gKGNwdS5tcl9hYmtfY29uZCAmIEFCS19JRkVUQ0gpDQor
CQkJCSAgICAgOiAoY3B1Lm1yX2Fia19jb25kICYgQUJLX1JFQUQpKSkpIHsN
CisJICAgIGNwdS5wYWcucHJfZmxoID0gUE1GX0FEUkVSUjsJLyogcmVwb3J0
IGFkZHJlc3MgYnJlYWsgKi8NCisJICAgIGdvdG8gcGZhdWx0OwkJCS8qIGdv
IHNldCBWSVJUIGV0YyAqLw0KKwl9DQorDQorCS8qIE5vIGJyZWFrLCByZWNh
bGN1bGF0ZSBhY2Nlc3MgdXNpbmcgdHJ1ZSBwYWdlciBmbGFncyAqLw0KKwlp
ZiAoZiAmIGNwdS5tcl9hYmtfcG1mbGFncykgew0KKwkgICAgLyogYWJrX3Bh
Z25vIGlzIGluIHNlY3Rpb24gMC0zNywgbm8gbmVlZCB0byByYW5nZSBjaGVj
ayB2cGFnICovDQorCSAgICByZXR1cm4gdm1fcGh5c21hcChwYWdfcGd0b3Bh
KHBbdnBhZ10mUEFHX1BBTVNLKSB8IHZhX3BhZ29mZihlKSk7DQorCX0NCisg
ICAgfQ0KKyNlbmRpZg0KIA0KICAgICAvKiBOb3RlIHBhZ2UgbnVtYmVyIHBh
c3NlZCB0byBwYWdfdDIwbWFwIGlzIHRoZSBGVUxMIFhBIHBhZ2UsIHdoaWNo
IG9uDQogICAgICoqIGEgS0wgaXMgMTIrOT0yMSBiaXRzLCBub3QgdGhlIHN1
cHBvcnRlZCA1Kzk9MTQgdmlydHVhbC4NCiAgICAgKi8NCi0gICAgaWYgKHZt
cCA9IHBhZ190MjBtYXAocCwgdmFfeGFwYWdlKGUpLCAoZiAmIFZNRl9BQ0Mp
KSkgLyogVHJ5IG1hcHBpbmcgKi8NCisgICAgaWYgKHZtcCA9IHBhZ190MjBt
YXAocCwgdnBhZywgKGYgJiBWTUZfQUNDKSkpIC8qIFRyeSBtYXBwaW5nICov
DQogCXJldHVybiB2bXAgKyB2YV9wYWdvZmYoZSk7CQkvKiBXb24sIHJldHVy
biBtYXBwZWQgcHRyISAqLw0KIA0KICAgICAvKiBVZ2gsIGFuYWx5emUgZXJy
b3IgZmFyIGVub3VnaCB0byBidWlsZCBwYWdlIGZhaWwgd29yZCBMSCBiaXRz
LA0KQEAgLTE0ODAsNiArMTU1OCw3IEBADQogICAgICoqIGFmdGVyIHRoZSBw
YWdlIGZhaWwgdHJhcCBoYXMgaGFwcGVuZWQgYW5kIGNvbnRyb2wgcmV0dXJu
cyB0byB0aGUNCiAgICAgKiogbWFpbiBpbnN0cnVjdGlvbiBsb29wLiAgDQog
ICAgICovDQorIHBmYXVsdDoNCiAgICAgY3B1LnBhZy5wcl9mbWFwID0gcDsN
CiAgICAgY3B1LnBhZy5wcl9mYWNmID0gZjsNCiAgICAgc3dpdGNoIChwZmxo
ID0gY3B1LnBhZy5wcl9mbGgpIHsNCkBAIC0xODE2LDYgKzE4OTUsMTYgQEAN
CiAgICAgcFt2cGFnXSA9IHBhZyB8IFZNRl9SRUFEDQogCQkgfCAoKGFjY2Jp
dHMgJiBDU1RfTUJJVCkgPyBWTUZfV1JJVEUgOiAwKTsNCiANCisjaWYgS0xI
MTBfQ1BVX0tMDQorICAgIC8qIElmIHBhZ2UgdnBhZyBjb250YWlucyB0aGUg
YWRkcmVzcyBicmVhayBhZGRyZXNzLCBjbGVhciBpdHMNCisgICAgKiogYWNj
ZXNzIGZsYWdzIHNvIHRoYXQgcmVmcyB3aWxsIGNhdXNlIGEgcmVmaWxsLg0K
KyAgICAqLw0KKyAgICBpZiAodnBhZyA9PSBjcHUubXJfYWJrX3BhZ25vICYm
IHAgPT0gY3B1Lm1yX2Fia19wbWFwKSB7DQorCWNwdS5tcl9hYmtfcG1mbGFn
cyA9IHBbdnBhZ10gJiBWTUZfQUNDOw0KKwlwW3ZwYWddICY9IGNwdS5tcl9h
YmtfcG1tYXNrOw0KKyAgICB9DQorI2VuZGlmDQorDQogICAgIHJldHVybiB2
bV9waHlzbWFwKHBhZ19wZ3RvcGEocGFnKSk7DQogfQ0KIA0KLS0tIGlubW92
ZS5jLn4xfgkyMDAxLTExLTEwIDE1OjI5OjA3LjAwMDAwMDAwMCAtMDYwMA0K
KysrIGlubW92ZS5jCTIwMDQtMDQtMDMgMTc6MjU6NDMuMDAwMDAwMDAwIC0w
NjAwDQpAQCAtMjI5LDcgKzIyOSw3IEBADQogICAgIGlmIChhY19pc3NhZmVk
b3VibGUoYWMpCQkvKiBBQ3MgY29udGlndW91cz8gKi8NCiAgICAgICAmJiB2
bV9pc3NhZmVkb3VibGUoZSkJCS8qIE1lbSBsb2NzIHNhZmUgdG9vPyAqLw0K
ICAgICAgICYmICh2YV9pbnNlY3QoZSkgIT0gYWNfb2ZmKGFjLC0xKSkpCS8q
IG5vIEFDIG92ZXJsYXAgd2l0aCBNZW0/ICovDQotCSphY19tYXBkKGFjKSA9
IHZtX3BnZXRkKHZtX3hyd21hcChlLFZNRl9SRUFEKSk7CS8qIFllcCEgKi8N
CisJKmFjX21hcGQoYWMpID0gdm1fcGdldGQodm1feHJ3bWFwKGUsVk1GX1JF
QUR8Vk1GX0RXT1JEKSk7IC8qIFllcCEgKi8NCiAgICAgZWxzZSB7DQogCXJl
Z2lzdGVyIGR3MTBfdCBkOwkvKiBDb25zZXJ2YXRpdmUgY2FzZSwgdXNlIGlu
dGVybWVkIHN0ZyAqLw0KIAl2bV9kcmVhZChlLCBkKTsJCS8qIEZldGNoIHRo
ZSBkb3VibGUgKi8NCkBAIC0yNDgsNyArMjQ4LDcgQEANCiAgICAgaWYgKGFj
X2lzc2FmZWRvdWJsZShhYykJCS8qIEFDcyBjb250aWd1b3VzPyAqLw0KICAg
ICAgICYmIHZtX2lzc2FmZWRvdWJsZShlKQkJLyogTWVtIGxvY3Mgc2FmZSB0
b28/ICovDQogICAgICAgJiYgKHZhX2luc2VjdChlKSAhPSBhY19vZmYoYWMs
MSkpKQkvKiBubyBBQyBvdmVybGFwIHdpdGggTWVtPyAqLw0KLQl2bV9wc2V0
ZCh2bV94cndtYXAoZSxWTUZfV1JJVEUpLCAqYWNfbWFwZChhYykpOwkvKiBZ
ZXAhICovDQorCXZtX3BzZXRkKHZtX3hyd21hcChlLFZNRl9XUklURXxWTUZf
RFdPUkQpLCAqYWNfbWFwZChhYykpOyAvKiBZZXAhICovDQogICAgIGVsc2Ug
ew0KIAlyZWdpc3RlciBkdzEwX3QgZDsJLyogQ29uc2VydmF0aXZlIGNhc2Us
IHVzZSBpbnRlcm1lZCBzdGcgKi8NCiAjaWYgS0xIMTBfQ1BVX0tMDQpAQCAt
MzAyLDcgKzMwMiw3IEBADQogICAgIGFjX2RnZXQoYWMsIGQpOwkJCS8qIEZl
dGNoIEFDLCBBQysxIGludG8gRCAqLw0KICAgICBvcDEwbWZfZG1vdm4oZCk7
CQkJLyogTmVnYXRlIGluIHBsYWNlLCB3aXRoIGZsYWdzISAqLw0KICAgICBp
ZiAodm1faXNzYWZlZG91YmxlKGUpKQkJLyogRmFzdCBtb3ZlIE9LPyAqLw0K
LQl2bV9wc2V0ZCh2bV94cndtYXAoZSxWTUZfV1JJVEUpLCBkKTsJLyogWWVw
ISAqLw0KKwl2bV9wc2V0ZCh2bV94cndtYXAoZSxWTUZfV1JJVEV8Vk1GX0RX
T1JEKSwgZCk7CS8qIFllcCEgKi8NCiAgICAgZWxzZSB7DQogI2lmIEtMSDEw
X0NQVV9LTA0KIAl2bV93cml0ZShlLCBISUdFVChkKSk7CQkvKiBEbyBmaXJz
dCB3b3JkICovDQo=

--0-1145418779-1150521917=:5764--
17-Jun-2006 06:01:33-PDT,3570;000000000000
Return-Path: <[email protected]>
Received: from mail.math.utah.edu ([155.101.98.135]) by lingling.panda.com with TCP/SMTP; Sat, 17 Jun 2006 05:59:18 -0700 (PDT)
Received: from psi.math.utah.edu (psi.math.utah.edu [155.101.96.19])
by mail.math.utah.edu (8.13.6/8.13.6) with ESMTP id k5HCxCwl029558;
Sat, 17 Jun 2006 06:59:12 -0600 (MDT)
Received: from psi.math.utah.edu (localhost [127.0.0.1])
by psi.math.utah.edu (8.13.6/8.13.6) with ESMTP id k5HCxBu4024561;
Sat, 17 Jun 2006 06:59:11 -0600 (MDT)
Received: (from beebe@localhost)
by psi.math.utah.edu (8.13.6/8.13.6/Submit) id k5HCxBI3024560;
Sat, 17 Jun 2006 06:59:11 -0600 (MDT)
Date: Sat, 17 Jun 2006 06:59:11 -0600 (MDT)
From: "Nelson H. F. Beebe" <[email protected]>
To: "Chris Smith" <[email protected]>, [email protected]
Cc: [email protected]
X-US-Mail: "Department of Mathematics, 110 LCB, University of Utah, 155 S
1400 E RM 233, Salt Lake City, UT 84112-0090, USA"
X-Telephone: +1 801 581 5254
X-FAX: +1 801 585 1640, +1 801 581 4148
X-URL: http://www.math.utah.edu/~beebe
Subject: Re: lcc progress report, also lack of progress
Message-ID: <[email protected]>
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0 (mail.math.utah.edu [155.101.98.135]); Sat, 17 Jun 2006 06:59:12 -0600 (MDT)

I was delighted to read Chris Smith's report of work porting lcc to
TOPS-20. I have worked on the compiler myself for several systems:
the current state for the 4.1 series is at

http://www.math.utah.edu/pub/lcc
ftp://ftp.math.utah.edu/pub/lcc

I have as-yet-unreleased additions for the 4.2 series, available on
request.

One project that I have planned for it is implementation of support
for long long int, and another is support for decimal floating-point
arithmetic, a feature for which proposals have been placed before both
the ISO C and C++ committees.

There has already been work on the long long problem for one platform
(SGI MIPS).

My current project is a large elementary function library, and
accompanying book, that covers all of C99, and more. It is designed
to support the arithmetic of historical systems, future decimal
systems, and future octuple precision (ca. 256-bit long long double),
as well as IEEE 754. The missing run-time library support is a major
impediment to adding decimal support, but since I have working code
now, the job is essentially done, but needs testing in a decimal
environment that no one yet has in C.

lcc seems to be the best candidate compiler for the initial
implementation of decimal arithmetic, and supports multiple platforms.
tcc works for only a single architecture. gcc's huge size is well
beyond what I have time for as a single person. The code generator
backends for lcc are typically 600 to 1000 lines of code (Chris, how
big is the PDP-10 backend for lcc?), and the total compiler at version
4.2.1 is 80,500 lines of C, including the back ends.

-------------------------------------------------------------------------------
- Nelson H. F. Beebe Tel: +1 801 581 5254 -
- University of Utah FAX: +1 801 581 4148 -
- Department of Mathematics, 110 LCB Internet e-mail: [email protected] -
- 155 S 1400 E RM 233 [email protected] [email protected] -
- Salt Lake City, UT 84112-0090, USA URL: http://www.math.utah.edu/~beebe/ -
-------------------------------------------------------------------------------
17-Jun-2006 14:19:56-PDT,3135;000000000000
Return-Path: <[email protected]>
Received: from mxfep01.bredband.com ([195.54.107.70]) by lingling.panda.com with TCP/SMTP; Sat, 17 Jun 2006 14:17:39 -0700 (PDT)
Received: from junk.nocrew.org ([85.226.171.82] [85.226.171.82])
by mxfep01.bredband.com with ESMTP
id <[email protected]>;
Sat, 17 Jun 2006 23:17:33 +0200
Received: from lars by junk.nocrew.org with local (Exim 4.50)
id 1FriAe-0005y7-Jk; Sat, 17 Jun 2006 23:17:32 +0200
To: "Chris Smith" <[email protected]>
Cc: [email protected]
Subject: Re: lcc progress report, also lack of progress
References: <[email protected]>
From: Lars Brinkhoff <[email protected]>
Organization: nocrew
Date: Sat, 17 Jun 2006 23:17:32 +0200
In-Reply-To: <[email protected]> (Chris
Smith's message of "Fri, 16 Jun 2006 08:10:57 -0600")
Message-ID: <[email protected]>
User-Agent: Gnus/5.1007 (Gnus v5.10.7) Emacs/21.4 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii

"Chris Smith" <[email protected]> writes:
> I know there's a gcc port, or at least part of one. Is there any
> hope of that running on a 10? gcc's code is not going to fit in a
> section.

I was contrated to work on the GCC port until June 2003. After that,
the company moved development in-house. There may well have been
significant improvements since then.

It should be entirely possible to run GCC on a PDP-10, albeit slowly.
The primary obstacle would be a libc port. For that, MACRO and LINK
support for long symbols would be helpful.

I started a port of the GNU libc, but hadn't gotten very far at the
time my contract was discontinued.

> Has the gcc work solved any of the above?

See below.

> - lcc handles two-address machines by basically pretending they are
> three address machines

At the lower-level machine code generating phase, GCC uses a
representation assuming three-address instructions. It's up to the
register allocator to minimize unnecessary moves, and this is usually
done quite well, but not always.

> - MACRO and LINK do not understand long symbols. This is needed
> in practice.

This was not solved by the time I stopped working on the port.

> - c89 uses L"string" for 16-bit chars, suggesting the obvious
> 6"string" 7"string" 8"string" 9"string" 18"string" for kcc
> strings currently denoted by the kludgy ((char7 *) "string")
> notation.

GCC has support for various char sizes. There may have been weak
support for string literals of various char sizes.

> - kcc calling conventions empty the registers at all calls.
> lcc can, and wants to, do better than this. Putting everything
> in memory generates crummy code even by lcc standards. Porting
> kcc's libc would allow this to be changed easily.

By default, GCC will use seven registers for argument passing, and put
the rest on the stack. This is adjustable. The number of call-
clobbered registers is also adjustable.
18-Jun-2006 02:41:04-PDT,13789;000000000000
Return-Path: <[email protected]>
Received: from mail.frii.com (phobos01.frii.net [216.17.128.161]) by lingling.panda.com with TCP/SMTP; Sun, 18 Jun 2006 02:38:39 -0700 (PDT)
Received: from foxboro.stoneboro.net (host206-209.lpbroadband.net [66.54.206.209])
by mail.frii.com (FRII) with ESMTP id E254CAEB1F
for <[email protected]>; Sun, 18 Jun 2006 03:38:33 -0600 (MDT)
Received: by foxboro.stoneboro.net (Postfix, from userid 525)
id 6A5828093EB2; Sun, 18 Jun 2006 03:38:33 -0600 (MDT)
From: Chris Smith <[email protected]>
To: [email protected]
In-reply-to: <[email protected]> (message from Mark
Crispin on Fri, 16 Jun 2006 11:48:01 -0700 (PDT))
Subject: Re: lcc progress report, also lack of progress
References: <[email protected]>
Message-Id: <[email protected]>
Date: Sun, 18 Jun 2006 03:38:33 -0600 (MDT)

>I don't understand your comment about prototypes. KCC most certainly
>has prototypes. The UW IMAP toolkit uses prototypes; and the c-client
>library and the mtest and mailutil applications both build with KCC on
>TOPS-20.

Oh great, so it does. <KCC.INCLUDE> does not use them, however.
This was my reason for working on lcc. Oh well, call it a learning
experience.

This might be interesting, here's a change log for lcc-10, I tried to
post it here before but panda rejected it, probably too many "binary"
"attachments".

----------
2004-05-02 <csmith@foxboro>

======================= FQ+3D.20H.57M.35S. TAG: BL1 =======================

* tst/switch.c: Pass. 36-bit <limits.h> and native rcc.

* simp.c (simplify): Resurrect MIPS address range hack [repair
65536 that should be 65535] and convert from 16 to 18 bits,
producing PDP-10 address range hack. PDP-10 has two problems:
doesn't use EFIW, and huge word offsets converted to bits don't
fit into an int. L.nnn+400000000005 is fine until converted from
words to bits and back. EFIW and internal use of long long will
fix. Later.

* tst/limits.c: Pass. Compiler ok, libc can't print MININT.

2004-05-01 <csmith@foxboro>

* triple test: Pass. stage1 : stage2 minor diffs due to 32 vs 36
bit host, constant folding of boundary cases and float lsb's.
stage2 : stage3 identical.

* types.c (type_init): pointer max is (void *) ones(36), which
should be excellent. However, it is in section 7777, and reveals
that the code for byte pointer < uses a signed compare that should
be unsigned. Fixing the code template would cost instructions to
handle a case that doesn't otherwise occur. Except on XKL's. Hm.
For now, just hack up the def of pointersym->u.limits.max.p. Later.

* list.c (ltov): The list of void *'s is converted properly to a
vector of void *'s, but this results in a bunch of byte pointers
where the caller wants struct foo pointers (word addresses).
Could write elegant macro to cast a vector of void *'s to a
designated pointer type; instead, cheap out and make array[]
a vector of int *'s not void *'s.

2004-04-25 <csmith@foxboro>

* hello.c (main): Hello from native RCC.EXE.

* gen.c (rtarget): TWOADDRESS problem with (VREG lhs) hidden
deeper inside RHS:
tail = &(*tail)->link;
(ADDP36 (CNSTI36 7) (INDIRP36 (INDIRP36 (VREGP tail))))
Add routine tree_reads_vreg to examine whole tree for (VREG lhs).

* simp.c (simplify): Comment out zerofield() calls, their mask
arithmetic doesn't work in 32-bit cross compiler.

* config.h (emitbin): Comment out unused extern declaration.
rcc externs it, MACRO externs it, LINK raises ?LNKUGS.
(widens): Ditto.

* simp.c (simplify): Repair idempotent(BCOM+U) in BCOM+I case.

* expr.c (unary): Remove preimplementation of NEG+U.
Retain warning under Aflag.
* ops.h (NEG): Add U+ilh.
* simp.c (simplify): Add NEG+U.
* pdp10.md : Add NEGU36, NEGU72.
* dagcheck.md: Add NEGU.

* expr.c (cast): Remove preimplementation of CVF+U.
* ops.h (CVF): Add U+ilh.
* simp.c (simplify): Add CVF+U.
* pdp10.md: Add CVFU36, CVFU72.
* dagcheck.md: Add CVFU.

* expr.c (cast): Remove preimplementation of CVU+F.
* ops.h (CVU): Add F+fdx.
* pdp10.md: Add CVUF36, CVUF72.
* dagcheck.md: Add CVUF.

* tst/fields.c: Pass.

* c.h: Remove FIELD (op 43). FIELD is now a dag operator.
* ops.h: Add FIELD (op 5), FIELD+I+i, and FIELD+U+i.
* bytecode.c (dumptree): Add FIELD.
* gen.c (dumptree): Add FIELD.
* tree.c (opname): Add FIELD.
Top extra tree operator is now RIGHT (op 42).
* gen.c (NeedsReg[]): Add FIELD (yes needs reg).
* dag.c (listnodes, FIELD): Generate (INDIR (FIELD addr)), with
kids[0] the field address, syms[0] an intconst giving fieldsize,
syms[1] an intconst giving fieldright.
(listnodes, ASGN, FIELD): Generate (ASGN (FIELD addr) val) as above.
(listnodes, RIGHT, e++ case): Handle FIELD same as INDIR.
(undag): Handle FIELD same as INDIR.
* dagcheck.md: Add FIELD.
* pdp10.md: Add FIELD.

* alloc.c: Add rcsid[].

2004-04-24 <csmith@foxboro>

* tst/yacc.c: Pass.

* tst/wf1.c: Pass.

* tst/switch.c: Pass. Not fully tested, 32-bit limits.h.

* tst/struct.c: Pass.

* tst/stdarg.c: Pass.

* include/pdp10/tops20/stdarg.h: New. Arg list is inverted, grows
toward low addresses. Char, short point to the low bits of the
arg word. Struct/union get extra dereference. (Why doesn't sparc
need this?)

* tst/spill.c: Pass. Spilling doesn't entirely work with reg
pairs -- spillee() only picks one reg to spill, if getreg() wants
a D and the regs are full of R's, it won't find a D. This doesn't
happen here but seems like it could.

* tst/sort.c: Pass.

* tst/paranoia.c: Pass. Needs #defines to distinguish Random1,
Random2, Random9. Needs -DNOSIGNAL to avoid premature death by
floating underflow raising SIGFPE which it does not expect or handle.
Rough results, runtime issue, needs TRAPS and better libm.

* kcc/lib/math/modf.c: SETZB @-3(17) does not store a double 0.0 as
the comment says. It stores zero in the high word and leaves junk
in the low word. Use SETZB/DMOVEM.

* tst/limits.c: 32-bit <limits.h> not interesting. Later.

* tst/init.c: Pass.

* tst/incr.c: Pass.

* tst/front.c: Pass.

* tst/fields.c: A mess. 32-bit arithmetic does not make for
accurate 36-bit masks. Basically works. Eventually want FIELD in
dag nodes anyway, for ldb/dpb. Later.

* tst/cvt.c: Pass. Needs #defines to work around case significant
names.

* tst/cq.c: Pass. Output diffs: type bitsizeofs, unsigned
bit fields. 'No errors detected'.

* gen.c (rtarget): Insert LOAD when targeting q to r if q's
right kid is (INDIR (VREG r)). We will evaluate q by ?moving
its left kid to r, smashing the right kid. Not a problem for
three-address code, so put under #if TWOADDRESS.

* simp.c (muli): Min and max args are int36 not long.
* (addi): Ditto.

* enode.c (subtree): Pointer diff SUB+P is a signed int; generate
(CVI+I (SUB+P ptr1 ptr2)) so code that examines optype gets I not P.

* etc/parith.c: New. Compute ptrdiff constants, a la kcc utiltity
of the same name (not included in distribution, unfortunately).

* dagcheck.md: Add EQP, GEP, GTP, LEP, LTP, NEP.
Change SUBP from P: P,I to I: P,P.
Remove ADDP(P,I), leave ADDP(I,P).
Similarly for U.
symbolic.c (defstring): len is in bits, convert for emitString.

* tst/cf.c: Pass.

* tst/array.c: Pass.

* tst/8q.c: Pass.

* pdp10.md, lccsym.mac: Continual changes, ongoing, not logged.

* etc/tops20.c: New. Define __STDC__, __CHAR_UNSIGNED__,
__pdp10__, __tops20__, __kl10__, and __dfloat__, reflecting some
options that do not exist. Search only LCCDIR/include, not host
/usr/include.
* lcc: Build cross compiler, good up to -S and no farther.
* cpp: Build.

2004-04-18 <csmith@foxboro>

* gen.c (range): Handle CNST+P range test like CNST+U.

* simp.c (foldaddp): Don't do target pointer arithmetic in host
type char *. Use long int. (Target pointer values are in units
of this->type->scale, not char.)
(simplify CVP+P): Ditto. Also (CVP+P ADDR+P) is just retype.
(simplify SUB+P): Ditto.

* enode.c (shtree): LSH and RSH both shift left. Right shifts
use (RSH val -n) to shift right n. RSH is retained for the
dubious LSH-left-ASH-right semantics of signed int shifts.
* expr.c (cast): Use (RSH val -1) for right shift 1.
* simp.c (simplify DIV+U): Use (RSH val -n) for right shift n.
(simplify RSH): Fix constant folding, fix range checks.

* stmt.c (swcode): Dispatch table pointers are funcptype not
voidptype. -- i.e. word addresses not byte pointers.
(jump): Ditto ordinary code labels.

* dag.c (visit): Call temporary() with correct type, not btot().
* types.c (btot): Exterminate. Dag nodes need true type.
* c.h (btot): Ditto.

* sym.c (newtemp): Replace optype and opsize args with Type ty.
* c.h (newtemp): Corresponding declaration.
* gen.c (spillr): Pass type instead of optype/opsize to newtemp.

* c.h (struct node): Add type to dag nodes.
(newnode): Add type arg to constructor.
* dag.c (node, newnode, dagnode): Ditto.
* dag.c (*): Supply type to node & newnode.
gen.c (*): Ditto.
stmt.c (*): Ditto.

* expr.c (cast): Generate CVP+P if pointer cast changes scale.
(retype): Retyping (CVP+P op1) is op1 if op1 has the desired type.
* gen.c (prelabel): Don't convert CVP to LOAD, it's not a nop.
* dag.c (listnodes): Don't assert, it's not a nop.

* expr.c (field): Generate int+ptr (the correct order) for field
accesses. Divide the int by scale of element type. Cast ptr
to that type.

* enode.c (addtree): ADD+P is not commutative, it's always int+ptr.
(subtree): Generate (ADD+P (NEG int) ptr) for ptr-int.
Generate (SUB+P ptr ptr) for ptr-ptr only.
* simp.c (simplify): Fix simplifications of ADD+P to preserve
operand order. Flush MIPS address range hack.
Fix SUB+P, always ptr diff never ptr-int.

* enode.c (cmptree): Generate LT+P etc for pointer compares.
(eqtree): Ditto EQ+P and NE+P.
* simp.c (simplify): Handle LT+P etc.

2004-04-17 <csmith@foxboro>

* hello.s (main): Hello, world!

* enode.c (addtree): ptr+int multiplies by size/scale.
(subtree): ptr-int ditto. ptr-ptr divides by ditto.

* c.h (struct type): Add scale to Type.
* types.c (type): Add scale arg to Type constructor.
(xxinit): Initialize scale from Metrics.scale.
(type_init): Scale of voidtype from chartype->scale.
Scale of unsignedptr and signedptr from voidptype->scale.
(ptr): Scale of POINTER types from IR->ptrmetric.
(array): Scale of ARRAY types from element type.
(qual): Scale of qualified type from type being qualified.
(newstruct): Scale of struct types from IR->structmetric.
(func): Scale of FUNCTION types from IR->structmetric.

* c.h (struct metrics): New field Metrics.scale, gives unit
of addressing for type.
* pdp10.md (pdp10IR): Define: 9 for char, 18 for short, 36
for word-addressed types.
* symbolic.c (symbolic36IR): Ditto.
* null.c (nullIR): Define: 1 byte for all types.
* bytecode.c (bytecodeIR): Ditto.

* main.c (main): Default -target is pdp10. Save typing. Temp.

* pdp10.md: Args on stack, like KCC. Return reg 1.
Regs 1-6 temp, 7-16 preserved.
KCC trashes all ACs, use shim to push/pop 7-16 on aux stack.
* lccsym.mac: New, register defs & macros & such.

* init.c (initchar): Do accounting in bits not bytes.
(initfields): Use int36 variables to accumulate fields into an int.
Repair 8-bit-byte assumptions and use of host char casts.

* c.h (roundup): Fix to work for non power of 2.

* decl.c (bits2bytes): Now a nop, size is already in bits.

* expr.c (unary): SIZEOF unit is chartype->size.

* c.h (ones): repair 8 * sizeof(unsigned long).
(ischar): Char is int of size chartype->size, not size 1.

* c.h (extend): 8 * ty->size => ty->size -- size is already in bits.
(fieldleft): Ditto.
(fieldmask): Ditto.
* dag.c (listnodes, field ASGN): Ditto.
(listnodes, FIELD): Ditto.
* decl.c (fields): Ditto.
* enode.c (cnsttree): Ditto.
(asgntree): Ditto.
* init.c (initfields): Ditto.
* lex.c (backslash): Ditto.
* simp.c (sfoldcnst): Ditto.
(simplify): Ditto.
* types.c (xxinit): Ditto.

* c.h (int36, uint36): New types for 36-bit quantities.
(INT36(k), UINT36(k)): New, for constants of above types.

* decl.c (specifier): Add argument *signd that returns SIGNED
or UNSIGNED if seen, else 0.
(fields): Bit fields default to unsigned if char does.

* ../makefile: Remove alpha, mips, sparc, x86, add pdp10.

* c.h (struct node): op no longer fits in a short, make it int.
#define CROSS for stuff like this that can change back.

* pdp10.md: Start with the 202 operators from
etc/ops c=9 s=18 i=36 l=36 h=72 f=36 d=72 x=72 p=36
Crib boilerplate.

* ops.h: Add CVP+P for pointer->pointer conversions.
Add EQ+P NE+P GE+P GT+P LE+P LT+P for pointer compares.

* etc/ops.c: Include LOADxx.

* symbolic.c (symbolic36IR): Give sizes in bits, as if using 1-bit
bytes. long = int, long double = double, struct align = 36.
Big endian. Evaluate args left to right. Unsigned char.

* bind.c (yy): Remove all bindings except symbolic; change that
to use symbolic36IR. Add binding pdp10, using pdp10IR.

============================== TAG: INDENTED ==============================

2004-04-18 <csmith@foxboro>

* *.[ch]: Run through 'indent -gnu' to get left brace in col 1
where emacs requires it.

=============== INITIAL LCC 4.2 DISTRIBUTION. TAG: LCC_4_2 ===================
6-Jul-2006 19:05:47-PDT,786;000000000000
Mail-From: MRC created at 6-Jul-2006 19:03:30
Mail-From: MRC created at 6-Jul-2006 19:02:50
Date: Thu, 6 Jul 2006 19:02:50 -0700 (PDT)
From: Mark Crispin <[email protected]>
Subject: TOPS-20 list moderated again
To: [email protected]
Pithy-Thought: TOPS-20 was a great improvement over its successors
Message-ID: <[email protected]>
ReSent-Date: Thu, 6 Jul 2006 19:03:30 -0700 (PDT)
ReSent-From: Mark Crispin <[email protected]>
ReSent-To: TOPS-20: ;
ReSent-Message-ID: <[email protected]>

Sadly, two phish messages made it to the TOPS-20 list. I've converted
the list back to being moderated to spare your mailboxes any more spam.

I will probably move the TOPS-20 list to a new address shortly.
-------
5-Aug-2006 13:49:55-PDT,4452;000000000000
Return-Path: <[email protected]>
Received: from pangtzu.panda.com ([206.124.149.117]) by lingling.panda.com with TCP/SMTP; Sat, 5 Aug 2006 13:48:10 -0700 (PDT)
X-Return-Path: <[email protected]>
X-Received: from mta2.srv.hcvlny.cv.net ([167.206.4.197]) by lingling.panda.com with TCP/SMTP; Sat, 5 Aug 2006 12:27:56 -0700 (PDT)
X-Received: from optonline.net (hamstr3.srv.hcvlny.cv.net [167.206.5.10])
by mta2.srv.hcvlny.cv.net
(Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006))
with ESMTP id <[email protected]> for
[email protected]; Sat, 05 Aug 2006 15:27:50 -0400 (EDT)
X-Received: from [10.240.3.210] (Forwarded-For: [10.240.3.210])
by mstr3.srv.hcvlny.cv.net (mshttpd); Sat, 05 Aug 2006 19:27:50 +0000 (GMT)
Date: Sat, 05 Aug 2006 19:27:50 +0000 (GMT)
From: [email protected]
Subject: MOVSLJ behavior in non-zero sections on a Toad
To: [email protected]
Message-id: <[email protected]>
MIME-version: 1.0
X-Mailer: Sun Java(tm) System Messenger Express 6.2-6.01 (built Apr 3 2006)
Content-type: text/plain; charset=us-ascii
Content-language: en
Content-transfer-encoding: 7BIT
Content-disposition: inline
X-Accept-Language: en
Priority: normal
ReSent-Date: Sat, 5 Aug 2006 13:47:59 -0700 (PDT)
ReSent-From: TOPS-20 List Moderator <[email protected]>
ReSent-To: TOPS-20 Distribution: ;
ReSent-Subject: MOVSLJ behavior in non-zero sections on a Toad
ReSent-Message-ID: <[email protected]>

Symptom:

The following program, when run in section zero and a non-zero section
on a KLH10 machine correctly displays the source string twice on the
terminal. When modified to use UUO's, it correctly executes under
Tops-10 on KL-10B hardware. It also functions properly in section
zero on a Toad.

When run in a NON-zero section on a Toad, illegal memory read errors
are produced.

Conjecture:

One suspects that the problem that causes this may also be causing the
similar behavior on CVTDBO that I reported a few months ago.

Work-around:

Use a ILDB/IDPB loop on a Toad. I've also worked around the CVTDBO
issue by using a recursive DDIV routine to handle double integers
(that NOUT% won't handle) and NOUT% for everything else. This is
conditioned at run-time by MRC's GETCPU routine. The MOVSLJ actually
is faster.

This has finally enabled me to get the latest version of my extended
mode FTP server running on a Toad. I've done ASCII and TYPE L 8
transfers. I'll need to simulate a MOVST at some point to handle the
Unix Linefeed to Carriage Return Linefeed auto-frobinication.

For the Alpha Release:

1) Fix 36 bit small buffer retrieve bug
2) Integrate 36 bit unpacking routine to buffering system for store
3) Do page file structures

TITLE MOVLJ
SEARCH MONSYM

SOURCE: ASCIZ /"Gort! Klaatu barada nikto!"
/
0 ; Make SURE we have a NUL
SRCLEN==^D28+^D2+^D1 ; Length of string + NUL
DSTLEN==SRCLEN ; Strings are of equal length

STRING: REPEAT ^D20,<Z> ; Space for destination

MOVLJ: RESET% ; Reset the world
MOVEI 1,SRCLEN ; Source length
DMOVE 2,[ <POINT 7,,0>!1B12 ; Global byte pointer
0,,SOURCE ] ; Source string
MOVEI 4,DSTLEN ; Destination length
DMOVE 5,[ <POINT 7,,0>!1B12 ; Global byte pointer
0,,STRING ] ; Where to put this
XHLLI 6,. ; Load the section
HLL 3,6 ; Put whatever we got in source, also
TLNE 6,-1 ; In an extended section?
JRST DOIT ; Yes, just issue the instruction
; Else convert to section 0 pointers
HRR 2,3 ; Load source offset
TLZ 2,(1B12) ; Shut off the global pointer bit
HRR 5,6 ; Load destination offset
TLZ 5,(1B12) ; Shut off the global pointer bit
SETZB 3,6 ; Bonk 30 bit addresses

; Transfer the string
DOIT: EXTEND 1,[EXP <MOVSLJ 0,0>,0]
JFCL
JFCL

MOVE 1,[POINT 7,SOURCE] ; Load local pointer to source
PSOUT% ; Type it
MOVE 1,[POINT 7,STRING] ; Load local pointer destination
PSOUT% ; Type it

HALTF% ; Exit to superior
JRST MOVLJ ; Do it all over again

END MOVLJ ; Nothing to do for reenter

5-Aug-2006 13:51:34-PDT,4602;000000000000
Return-Path: <[email protected]>
Received: from pangtzu.panda.com ([206.124.149.117]) by lingling.panda.com with TCP/SMTP; Sat, 5 Aug 2006 13:50:12 -0700 (PDT)
X-Return-Path: <[email protected]>
X-Received: from mta3.srv.hcvlny.cv.net ([167.206.4.198]) by lingling.panda.com with TCP/SMTP; Sat, 5 Aug 2006 12:32:57 -0700 (PDT)
X-Received: from optonline.net (hamstr3.srv.hcvlny.cv.net [167.206.5.10])
by mta3.srv.hcvlny.cv.net
(Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006))
with ESMTP id <[email protected]> for
[email protected]; Sat, 05 Aug 2006 15:32:51 -0400 (EDT)
X-Received: from [10.240.3.210] (Forwarded-For: [10.240.3.210])
by mstr3.srv.hcvlny.cv.net (mshttpd); Sat, 05 Aug 2006 19:32:50 +0000 (GMT)
Date: Sat, 05 Aug 2006 19:32:50 +0000 (GMT)
From: [email protected]
Subject: Multi-forking program causes Tops-20 job to run out of fork handles
To: [email protected]
Message-id: <[email protected]>
MIME-version: 1.0
X-Mailer: Sun Java(tm) System Messenger Express 6.2-6.01 (built Apr 3 2006)
Content-type: text/plain; charset=us-ascii
Content-language: en
Content-transfer-encoding: 7BIT
Content-disposition: inline
X-Accept-Language: en
Priority: normal
ReSent-Date: Sat, 5 Aug 2006 13:49:59 -0700 (PDT)
ReSent-From: TOPS-20 List Moderator <[email protected]>
ReSent-To: TOPS-20 Distribution: ;
ReSent-Subject: Multi-forking program causes Tops-20 job to run out of fork
handles
ReSent-Message-ID: <[email protected]>

Symptom:
========

Job runs out of fork handles. Neither RESETing all forks nor ^E
QUITing the Exec to the mini-exec, doing a RESET followed by an
EXEC will cure the problem. The job must be logged out. Exec
complains about disappeared forks and sometimes gets an error on
exit of multi-forking program. This happens on the PANDA
monitor. The fork disappeared problem also happens on a Toad, but
I haven't done enough debugging there to exhaust all the forks,
yet.

Example, EFTPSR start up when trying to CFORK% the data fork:
-------------------------------------------------------------

421 Service full, please try later. Goodbye., Insufficient system resources at PC: FINIT+11

Example, Exec:
--------------

!g sys:filcom
?Internal EXEC JRST GET2B error at $GET2+6
?Insufficient system resources
!

Example, disappeared fork:
--------------------------

!GET EFTPSR
%Process disappeared
!

Analysis:
=========

The inferior data fork self-initialization code ensures that the
data fork has the ability to interrupt the superior control fork
by explicitly getting a handle on the superior and using the
result of that GFRKH% as the confirmation that it could properly
IIC% to commmunicate operation completion. Viz:

DMOVE T1,[EXP .FHSUP,.FHSLF]
GFRKH% ; Get an actual handle to our superior
ERCALR WAA ; Assume not allowed to IIC%
MOVEM T1,CFRKH ; Store control fork handle

This fork handle is never explicitly released. Either the data
fork is KFORK%ed by the control fork or (almost never) restarted.
When the data fork does restart, it explicitly issues a RESET%
before going the GFRKH%

Workaround:
===========

Don't use GFRKH% to get a handle on the superior. Use the general
fork handle .FHSUP to IIC% the superior. Check capability vector
for SC%SUP, instead:

MOVX T1,.FHSLF ; Looking at ourself
RPCAP% ; Get our capability vector
ERCALR WAA ; What?? How could this fail?
TXNN T2,SC%SUP ; Could we interrupt our superior?
CALL WAA ; Gronk, we'll never work
TXOE T3,SC%SUP ; Could we interrupt our superior?
IFSKP. ; That's odd, FINIT should have done this
RPCAP% ; But gracefully handle this by enabling it
CALL WAA ; Not too graceful, I'd have to say!
ENDIF. ; End case of enabled capability double check
MOVX T1,.FHSUP ; The data fork will use the general handle
MOVEM T1,CFRKH ; Store control fork handle

Anybody have any obvious ideas? I thought KFORK% or at least RESET%
would release handles and was fairly certain that bonking the
top-level Exec would get rid of the orphan handles.

5-Aug-2006 13:56:00-PDT,9601;000000000000
Return-Path: <[email protected]>
Received: from pangtzu.panda.com ([206.124.149.117]) by lingling.panda.com with TCP/SMTP; Sat, 5 Aug 2006 13:54:36 -0700 (PDT)
X-Return-Path: <[email protected]>
X-Received: from mta9.srv.hcvlny.cv.net ([167.206.4.204]) by lingling.panda.com with TCP/SMTP; Sat, 5 Aug 2006 13:25:03 -0700 (PDT)
X-Received: from optonline.net (hamstr3.srv.hcvlny.cv.net [167.206.5.10])
by mta9.srv.hcvlny.cv.net
(Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006))
with ESMTP id <[email protected]> for
[email protected]; Sat, 05 Aug 2006 16:24:31 -0400 (EDT)
X-Received: from [10.240.3.210] (Forwarded-For: [10.240.3.210])
by mstr3.srv.hcvlny.cv.net (mshttpd); Sat, 05 Aug 2006 20:24:56 +0000 (GMT)
Date: Sat, 05 Aug 2006 20:24:56 +0000 (GMT)
From: [email protected]
Subject: Tops-20 Extended mode FTP Server Update
To: [email protected]
Message-id: <[email protected]>
MIME-version: 1.0
X-Mailer: Sun Java(tm) System Messenger Express 6.2-6.01 (built Apr 3 2006)
Content-type: text/plain; charset=us-ascii
Content-language: en
Content-transfer-encoding: 7BIT
Content-disposition: inline
X-Accept-Language: en
Priority: normal
ReSent-Date: Sat, 5 Aug 2006 13:54:25 -0700 (PDT)
ReSent-From: TOPS-20 List Moderator <[email protected]>
ReSent-To: TOPS-20 Distribution: ;
ReSent-Subject: Tops-20 Extended mode FTP Server Update
ReSent-Message-ID: <[email protected]>

Since it's been a while, I thought that I would give an update on the
extended mode FTP server that I have been working on. Here is what
has been done:

1) (Even more) Extensive code to handle certain kinds of attacks.
The logging function that I had previously implemented showed that
I was getting attacked 7 to 8 times every day. The new code, when
it detects an attack, blats a scary (configurable) message and
then hangs up.

It would be nice to then deny future connects from that IP address
for some period of time, but the current architectural design of
the FTP server invocation does not make this a straightforward
task.

2) The buffer code has been changed to use SMAP% to and from files
for section sized buffers. D. Murphy's "EXTENDED ADDRESSING ON
THE DECSYSTEM-20" memo (in the SWSKIT) suggested that this might
be a win, so I wrote about 30 lines of code to do it. However, I
have no timing results on this on the actual network, yet, and
suspect that it might not help, but see below.

3) The STOR code for ASCII (TYPE A) is completely implemented and
debugged. Initial timing and operating system impact results are
below.

4) The STOR code for L 8 (UNIX IMAGE) is finished. Along with L 8
(Unix IMAGE) retrievals, this produces the fastest transfers in
the server, regularly topping 250 MBps

5) I have decided to take MRC's suggestion and only implement TYPE L
36 and TYPE L 8 IMAGE transfers. I have ripped out the retrieval
code that handled the other byte sizes.

6) 36 bit bit-banging/unpacking code finished for image (TYPE I)
STOR.

7) Unix text carriage return strip code has been finished and
debugged. In addition, it has been (somewhat) optimised. For
retrieval, the server can be configured to understand that it is
transfering text to Unix system and strip carriage returns to get
bare line feeds like Unix loves.

This is necessary because some FTP clients will not handle
anything but (8 bit) IMAGE transfers. This behavior can be forced
via a (non-standard) parameter to the server "TYPE U".

8) Unix text carriage return insertion code has been finished and
debugged. When doing a STOR while in TVFS mode and IMAGE TYPE,
the server checks to see if it is either creating a new version of
or overwriting a 7 bit (ASCII) or 36 bit (PA1050 output) existing
file.

If this is the case, then the server assumes it is doing a text
transfer and uses a translate table to insert carriage returns in
front of bare linefeeds and attempts to convert certain accented
characters into their 7 bit ASCII equivalents.

If the file being transferred is a completely new file, then the
server looks up the file type (extension) in a TBLUK% table to
guess an appropriate file byte size. This behavior can be forced
via a (non-standard) parameter to the server "TYPE U".

9) The buffering system has been slightly redesigned to handle a
subtle off by one error that TYPE U STORs exposed. The minimum
buffer size is now 2 pages (up from a single page) to allow
certain buffer wrapping operations to take place.

10) Because of the difficulties I encountered using the EXTENDed
string instructions on Toads, I have taken MRC's suggestion and
detect (via the use of the winning GETCPU routine) whether I'm
running on a Toad. If this is the case, then I simulate the
instructions with the so called 'classic' instructions.

The instructions that are simulated are CVTBDO, MOVSO, MOVSLJ and
MOVST (partial). No, I didn't do EDIT (horrors!), but I almost
did use it. Fortunately, I was able to get by with a MOVST.
XBLT works.

Note that, although these instructions are more complicated to
program, I have measured actual CPU time reductions when using
them under KLH10. The improvement, however, is not substantial.
It would be interesting to try them on KL-10B hardware and on a
Toad, if I can use one where they work in non-zero sections.

11) The extended mode FTP server has been 'fixed' (via the automatic
use of the 'classic' instruction set described above) to run on a
Toad. I have run a number of regression tests between operation
on Toad and KLH10 processors and have encountered no differences
in data transfer.

The things that remain to be done before an Alpha candidate are:

1) Fix a problem for 36 bit retrievals when using very small buffers.
2) Finish buffering interface for 36 bit store.
3) Implement Paged file structures

36 bit retrieval remarks:

Efficiently implementing all of the bit banging code for 36 bits has
been a moby chore. I really wish that there was an EXTENDed string
instruction (BBANG?) to do this for me. It would have saved a lot of
time. I mean, if they implemented the much hairy EDIT instruction, I
don't see why they couldn't have done a BBANG. Especially in the
DECnet code (but also possibly the Internet code), it might have
substancially reduced the processing time used for conversion and
would certainly have reduced routine hair.

It's hard for me to believe that this never occurred to anyone, but I
suppose KL microcode space limitations would been the obvious reason
for not doing it. However, I remember that around the 1982 timeframe,
DEC asked Columbia what kind of new instructions might be useful for
the new (KC10) processor and I remember suggesting BBANG. Looking at
the KC10 instruction set, I see that it never made it in. Neither did
hardware SOUT% (four registers, no counts, stop on a byte). Just like
a couple of my SPR's, Grr...

I've had to spend a lot of time doing some heavy tweaking to get the
bit banging code to be correct and fast. For packing 36 bits into an
8 byte data stream (retrieve), I use 32 instructions per 288 bit loop
or an average of 9 bits per instruction. For unpacking the 8 bit
network data into 36 bits (store), I use 40 instructions per 288 bit
loop or an average of 7.2 bits per instruction.

One assumes that these loops would still use more CPU time than a
single BBANG string instruction.

7 bit ASCII (TYPE A) store remarks:

Initial tests of the ASCII (TYPE A) STOR code with SMAP% have been
interesting, to say the least. I have set up some special debugging
code to NOT use the network to determine what the maximum program
throughput might be. When running with section buffers, I can convert
a 2,437,130 eight bit byte file (1,191 pages) to a 2,437,130 seven bit
byte file (953 pages) in six seconds of wall time on an essentially
empty machine.

That is an end to end throughput of a little more than 396 KB/s. The
measured wire read speed was 1.04 MB/s. I used a total of 5.8 seconds
of CPU time for this transfer. The system load rose from 0.28 to 0.37
(0.09 points) and the response time was not noticable degraded. At
this point, I'm inclined to say that I'm probably driving the actual
Tops-20 Internet code (or NI) as fast as it can go.

I also did some buffer checking and reduced the buffer size from a
section to a page. This produced some unexpected results. For the
same transfer, the wall time went increased to 4 minutes and 22
seconds. That is an end to end throughput of a little more than 9
KB/s, or a reduction to 2% of the previous wall speed. I used a total
of 4 minutes and and 22 seconds of CPU time for this transfer. The
measured wire read speed dropped to 796 KB/s.

The system load rose from 0.23 to 3.02 (2.79 points). The system
response was quite noticably effected with ^T responses being very
delayed. The server job itself wouldn't respond to a ^T nor a ^Y
internal probe. Of course, there is very likely some happy medium
between a page and a section buffer and I'd like to look at this after
I get the alpha release out and get feedback from others

5-Aug-2006 14:45:23-PDT,2064;000000000000
Return-Path: <[email protected]>
Received: from pangtzu.panda.com ([206.124.149.117]) by lingling.panda.com with TCP/SMTP; Sat, 5 Aug 2006 14:43:56 -0700 (PDT)
X-Return-Path: <[email protected]>
X-Received: from pangtzu.panda.com ([206.124.149.117]) by lingling.panda.com with TCP/SMTP; Sat, 5 Aug 2006 14:43:33 -0700 (PDT)
Date: Sat, 5 Aug 2006 14:43:28 -0700 (PDT)
From: Mark Crispin <[email protected]>
Sender: [email protected]
To: [email protected]
cc: [email protected]
Subject: Re: Tops-20 Extended mode FTP Server Update
In-Reply-To: <[email protected]>
Message-ID: <[email protected]>
References: <[email protected]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
ReSent-Date: Sat, 5 Aug 2006 14:43:47 -0700 (PDT)
ReSent-From: TOPS-20 List Moderator <[email protected]>
ReSent-To: TOPS-20 Distribution: ;
ReSent-Subject: Re: Tops-20 Extended mode FTP Server Update
ReSent-Message-ID: <[email protected]>

On Sat, 5 Aug 2006, [email protected] wrote:
> I've had to spend a lot of time doing some heavy tweaking to get the
> bit banging code to be correct and fast. For packing 36 bits into an
> 8 byte data stream (retrieve), I use 32 instructions per 288 bit loop
> or an average of 9 bits per instruction. For unpacking the 8 bit
> network data into 36 bits (store), I use 40 instructions per 288 bit
> loop or an average of 7.2 bits per instruction.

Hmm, I just tried hand-coding a 36->32 bit-banger (using DMOVE/M, MOVE/M,
and LSH/C) and came up with 30 instructions. With the test and loop,
that's 32. So that sounds right.

I'm definitely agreeable to adding a bit-banger to the klh10 microcode;
perhaps something like the KS10 BLTBU/BLTUB instructions. Ideally, we
would get XKL and perhaps SC on board with its definition.

Ralph? Fred?

-- Mark --

http://panda.com/tops-20
TOPS-20: a great improvement over its successors
5-Aug-2006 19:14:00-PDT,1975;000000000000
Return-Path: <[email protected]>
Received: from pangtzu.panda.com ([206.124.149.117]) by lingling.panda.com with TCP/SMTP; Sat, 5 Aug 2006 19:12:24 -0700 (PDT)
X-Return-Path: <[email protected]>
X-Received: from newcheshire.xkl.com (clare.xkl.com [192.94.202.41]) by lingling.panda.com with TCP/SMTP; Sat, 5 Aug 2006 17:18:03 -0700 (PDT)
X-Received: from tardis.xkl.com (tardis.xkl.com [10.1.0.29])
by newcheshire.xkl.com (8.13.3/8.13.3/SuSE Linux 0.7) with ESMTP id k760EheL023071;
Sat, 5 Aug 2006 17:14:45 -0700
X-Received: from tardis.xkl.com (localhost [127.0.0.1])
by tardis.xkl.com (8.13.3/8.13.3/SuSE Linux 0.7) with ESMTP id k760GT7T011645;
Sat, 5 Aug 2006 17:16:31 -0700
X-Received: from localhost (gorin@localhost)
by tardis.xkl.com (8.13.3/8.13.3/Submit) with ESMTP id k760GSFd011642;
Sat, 5 Aug 2006 17:16:28 -0700
Date: Sat, 5 Aug 2006 17:16:28 -0700 (PDT)
From: Ralph Gorin <[email protected]>
To: [email protected]
cc: [email protected],
TOPS-20 List Moderator <[email protected]>,
TOPS-20 Distribution: ;
Subject: Re: MOVSLJ behavior in non-zero sections on a Toad
In-Reply-To: <[email protected]>
Message-ID: <[email protected]>
References: <[email protected]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
ReSent-Date: Sat, 5 Aug 2006 19:12:16 -0700 (PDT)
ReSent-From: TOPS-20 List Moderator <[email protected]>
ReSent-To: TOPS-20 Distribution: ;
ReSent-Subject: Re: MOVSLJ behavior in non-zero sections on a Toad
ReSent-Message-ID: <[email protected]>

Yes,

I'm aware of problems in Toad string insructions
with two-word byte pointers.

I can't predict if we'll make new firmware for the
machine.

I am accumulating the failures so that we have diagnostics
to display these problems if we ever have the opportunity
to revisit the firmare.

Ralph

7-Aug-2006 19:40:46-PDT,2325;000000000000
Return-Path: <[email protected]>
Received: from pangtzu.panda.com ([206.124.149.117]) by lingling.panda.com with TCP/SMTP; Mon, 7 Aug 2006 19:38:43 -0700 (PDT)
X-Return-Path: <[email protected]>
X-Received: from mta10.srv.hcvlny.cv.net ([167.206.4.205]) by lingling.panda.com with TCP/SMTP; Mon, 7 Aug 2006 13:46:22 -0700 (PDT)
X-Received: from optonline.net (hamstr3.srv.hcvlny.cv.net [167.206.5.10])
by mta10.srv.hcvlny.cv.net
(Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006))
with ESMTP id <[email protected]> for
[email protected]; Mon, 07 Aug 2006 16:44:39 -0400 (EDT)
X-Received: from [10.240.3.205] (Forwarded-For: [10.240.3.205])
by mstr3.srv.hcvlny.cv.net (mshttpd); Mon, 07 Aug 2006 20:45:25 +0000 (GMT)
Date: Mon, 07 Aug 2006 20:45:25 +0000 (GMT)
From: [email protected]
Subject: Re: MOVSLJ behavior in non-zero sections on a Toad
In-reply-to: <[email protected]>
To: Ralph Gorin <[email protected]>
Cc: [email protected]
Message-id: <[email protected]>
MIME-version: 1.0
X-Mailer: Sun Java(tm) System Messenger Express 6.2-6.01 (built Apr 3 2006)
Content-type: text/plain; charset=us-ascii
Content-language: en
Content-transfer-encoding: 7BIT
Content-disposition: inline
X-Accept-Language: en
Priority: normal
References: <[email protected]>
<[email protected]>
ReSent-Date: Mon, 7 Aug 2006 19:38:34 -0700 (PDT)
ReSent-From: TOPS-20 List Moderator <[email protected]>
ReSent-To: TOPS-20 Distribution: ;
ReSent-Subject: Re: MOVSLJ behavior in non-zero sections on a Toad
ReSent-Message-ID: <[email protected]>

Actually, may I ask you to clarify this a bit?

ILDB/IPDB/ADJSP and the like work fine in a non-zero section with two word pointers. One word global byte pointers also work. One word global byte pointers stay one word when used with the above and two word global pointers stay two words.

Are you saying that I could use the string instructions if I used single word global byte pointers? I thought that they always converted one word pointers to two word pointers.

> I'm aware of problems in Toad string insructions
> with two-word byte pointers.

7-Aug-2006 19:42:15-PDT,4818;000000000000
Return-Path: <[email protected]>
Received: from pangtzu.panda.com ([206.124.149.117]) by lingling.panda.com with TCP/SMTP; Mon, 7 Aug 2006 19:39:32 -0700 (PDT)
X-Return-Path: <[email protected]>
X-Received: from mta10.srv.hcvlny.cv.net ([167.206.4.205]) by lingling.panda.com with TCP/SMTP; Mon, 7 Aug 2006 14:58:02 -0700 (PDT)
X-Received: from optonline.net (hamstr3.srv.hcvlny.cv.net [167.206.5.10])
by mta10.srv.hcvlny.cv.net
(Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006))
with ESMTP id <[email protected]>; Mon,
07 Aug 2006 17:56:38 -0400 (EDT)
X-Received: from [10.240.3.205] (Forwarded-For: [10.240.3.205])
by mstr3.srv.hcvlny.cv.net (mshttpd); Mon, 07 Aug 2006 21:57:24 +0000 (GMT)
Date: Mon, 07 Aug 2006 21:57:24 +0000 (GMT)
From: [email protected]
Subject: Re: Tops-20 Extended mode FTP Server Update
In-reply-to: <[email protected]>
To: Mark Crispin <[email protected]>
Cc: [email protected]
Message-id: <[email protected]>
MIME-version: 1.0
X-Mailer: Sun Java(tm) System Messenger Express 6.2-6.01 (built Apr 3 2006)
Content-type: text/plain; charset=us-ascii
Content-language: en
Content-transfer-encoding: 7BIT
Content-disposition: inline
X-Accept-Language: en
Priority: normal
References: <[email protected]>
<[email protected]>
ReSent-Date: Mon, 7 Aug 2006 19:39:06 -0700 (PDT)
ReSent-From: TOPS-20 List Moderator <[email protected]>
ReSent-To: TOPS-20 Distribution: ;
ReSent-Subject: Re: Tops-20 Extended mode FTP Server Update
ReSent-Message-ID: <[email protected]>

> Hmm, I just tried hand-coding a 36->32 bit-banger (using DMOVE/M,
> MOVE/M, and LSH/C) and came up with 30 instructions. With the test
> and loop, that's 32. So that sounds right.

So, you just did in a day what it took me more than "a while" to get
right? .... Sigh .... What a lousy bit banging I am (but see below).

> I'm definitely agreeable to adding a bit-banger to the klh10
> microcode; perhaps something like the KS10 BLTBU/BLTUB instructions.
> Ideally, we would get XKL and perhaps SC on board with its
> definition.

At the risk of having the discussion degenerate into everybody's
favorite JFFO variant, I could say, judging from my instruction mix,
the following:

1) I compare a lot.
2) I JRST a lot.
3) I shuttle a LOT of characters for messages and the like
4) For 36 <-> 8, I bit bang A LOT
5) I call and return a lot.
6) I save registers a lot
7) I do almost no math.

I think cases 1), 2) and 5) are handled fairly well by the current
instruction set architecture (ISA).

The code that MACSYM generates for register saving sometimes speeds
things up over a bunch of PUSHs. One assumes that the additional KC
stack instructions would yield better performance due to the
instruction decodes that would be saved. We probably should consider
implementing them.

However, a great deal of big banging must be taking place behind the
scenes for the DECnet code and it is forced into the programmer's
responsibility for the TCP/IP network due to the lack of a 36 bit
interface.

Also, the performance of the classic instruction set is even poorer
for doing the inverse operation (8 -> 36). Per 288 bit round, I use
40 instructions per loop or abot 7.2 bits per instruction. For large
files, this can burn up a lot of CPU time with all the shifting,
or'ing and instruction decode times. I think that having an
instruction to do this would be a real win.

But the thing that really bugs me is the simple case of just shuttling
characters around! MOVSLJ is difficult to use both because of having
to schedule six registers and because it requires known string
lengths. I could use MOVST to stop on a NUL, but that's slower than
the MOVSLJ (due in part to the table references), still has the
register scheduling problems and uses extra memory for the translate
table.

I spent a great deal of time talking with the friendly DEC hardware
repsentative about an HSOUT instruction. Four registers: two one word
global pointers, a positive count, or, or a negative count and a stop
byte. Actually, now that I think about it, we could get that down to
three registers: a count in the left half word and a stop in the right
half word.

This would save me a LOT of aggravation and probably a ton of CPU time
when compared to an ILDB/IPDB loop. As it stands now, a number of
programs use SOUT% to copy characters around and I can't help but
imagine that the JSYS overhead is larger than an ILDB/IDBP loop most
of the time for relatively small strings (BYTBLT nonwithstanding).

7-Aug-2006 20:20:01-PDT,4575;000000000000
Return-Path: <[email protected]>
Received: from pangtzu.panda.com ([206.124.149.117]) by lingling.panda.com with TCP/SMTP; Mon, 7 Aug 2006 20:18:34 -0700 (PDT)
X-Return-Path: <[email protected]>
X-Received: from pangtzu.panda.com ([206.124.149.117]) by lingling.panda.com with TCP/SMTP; Mon, 7 Aug 2006 20:17:57 -0700 (PDT)
Date: Mon, 7 Aug 2006 20:17:53 -0700 (PDT)
From: Mark Crispin <[email protected]>
Sender: [email protected]
To: [email protected]
cc: [email protected]
Subject: Re: Tops-20 Extended mode FTP Server Update
In-Reply-To: <[email protected]>
Message-ID: <[email protected]>
References: <[email protected]>
<[email protected]> <[email protected]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
ReSent-Date: Mon, 7 Aug 2006 20:18:25 -0700 (PDT)
ReSent-From: TOPS-20 List Moderator <[email protected]>
ReSent-To: TOPS-20 Distribution: ;
ReSent-Subject: Re: Tops-20 Extended mode FTP Server Update
ReSent-Message-ID: <[email protected]>

On Mon, 7 Aug 2006, [email protected] wrote:
>> Hmm, I just tried hand-coding a 36->32 bit-banger (using DMOVE/M,
>> MOVE/M, and LSH/C) and came up with 30 instructions. With the test
>> and loop, that's 32. So that sounds right.
> So, you just did in a day what it took me more than "a while" to get
> right? .... Sigh .... What a lousy bit banging I am (but see below).

Well, I don't claim that I came up with the best method (you'd need Stew
Nelson for that!) but it seemed pretty straightforward to me.

Actually, upon subsequent reflection, it can be 28 instructions, plus 2
instructions for the loop test, since you don't need to fuss over any junk
in the low order 4 bits for 32-bit data. So, for each 8-word source
block:

DMOVE T1,6(SRC) ; T1,T2/ bytes 28-36
MOVE T3,T1 ; T3/ byte 28 in high order byte
LSHC T1,^D4 ; T2/ bytes 33-36
LSH T1,^D4 ; T1/ bytes 29-32
DMOVEM T1,7(DST) ; save bytes 29-36
DMOVE T1,4(SRC) ; T1,T2/ bytes 19-27
MOVE T4,T1 ; T4/ bytes 19-20 in high order 2 bytes
LSHC T1,^D12 ; T1/ bytes 21-24 right-adjusted
LSH T1,^D4 ; T1/ bytes 21-24
LSH T2,-^D12 ; T2/ bytes 25-27 right adjusted
LSHC T2,^D12 ; T2/ bytes 25-28
DMOVEM T1,5(DST) ; save bytes 21-28
MOVE T3,T4 ; T3/ bytes 19-20 in high order 2 bytes
DMOVE T1,2(SRC) ; T1,T2/ bytes 10-18
MOVE T4,T1 ; T4/ bytes 10-12 in high order 3 bytes
LSHC T1,^D20 ; T1/ bytes 13-16 right-adjusted
LSH T1,^D4 ; T1/ bytes 13-16
LSH T2,-^D20 ; T2/ bytes 17-18 right-adjusted
LSHC T2,^D20 ; T2/ bytes 17-20
DMOVEM T1,5(DST) ; save bytes 13-20
MOVE T3,T4 ; T3/ bytes 10-12 in high order 3 bytes
DMOVE T1,0(SRC) ; T1,T2/ bytes 1-9
MOVEM T4,(DST) ; save bytes 1-4
LSHC T1,^D28 ; T1/ bytes 5-8 right-adjusted
LSH T1,^D4 ; T1/ bytes 5-8
LSH T2,-^D28 ; T2/ byte 9 right adjusted
LSHC T2,^D28 ; T2/ bytes 9-12
DMOVEM T1,1(DST) ; save bytes 5-12

I haven't actually tested this; it's strictly gedanken and I may have
goofed somewhere. Life would be easier if we had a three-word shift, oh
well.

> The code that MACSYM generates for register saving sometimes speeds
> things up over a bunch of PUSHs. One assumes that the additional KC
> stack instructions would yield better performance due to the
> instruction decodes that would be saved. We probably should consider
> implementing them.

There's been some debate about that, and in particular if those
instructions actually are a savings.

> Also, the performance of the classic instruction set is even poorer
> for doing the inverse operation (8 -> 36). Per 288 bit round, I use
> 40 instructions per loop or abot 7.2 bits per instruction. For large
> files, this can burn up a lot of CPU time with all the shifting,
> or'ing and instruction decode times. I think that having an
> instruction to do this would be a real win.

You shouldn't need to OR. I suspect, but don't know for a fact, that
shifting is faster.

> But the thing that really bugs me is the simple case of just shuttling
> characters around!

Agreed. Most people who use SOUT% to copy strings do so for code
cleanliness, not for performance. The ILDP/IDPB loop is always better
except in those cases where MOVSLJ is suitable.

-- Mark --

http://panda.com/tops-20
TOPS-20: a great improvement over its successors
7-Aug-2006 20:44:42-PDT,2595;000000000000
Return-Path: <[email protected]>
Received: from pangtzu.panda.com ([206.124.149.117]) by lingling.panda.com with TCP/SMTP; Mon, 7 Aug 2006 20:43:11 -0700 (PDT)
X-Return-Path: <[email protected]>
X-Received: from pangtzu.panda.com ([206.124.149.117]) by lingling.panda.com with TCP/SMTP; Mon, 7 Aug 2006 20:42:34 -0700 (PDT)
Date: Mon, 7 Aug 2006 20:42:28 -0700 (PDT)
From: Mark Crispin <[email protected]>
Sender: [email protected]
To: [email protected]
cc: [email protected]
Subject: Re: Tops-20 Extended mode FTP Server Update
In-Reply-To: <[email protected]>
Message-ID: <[email protected]>
References: <[email protected]>
<[email protected]> <[email protected]>
<[email protected]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
ReSent-Date: Mon, 7 Aug 2006 20:43:04 -0700 (PDT)
ReSent-From: TOPS-20 List Moderator <[email protected]>
ReSent-To: TOPS-20 Distribution: ;
ReSent-Subject: Re: Tops-20 Extended mode FTP Server Update
ReSent-Message-ID: <[email protected]>

Hmm, for 32->36, I also get 28 instructions. Again, this is gedanken, I
haven't tried this code, but it looks right.

DMOVE T1,(SRC) ; T1,T2/ bytes 1-8
MOVE T3,2(SRC) ; T3/ bytes 9-12
LSH T1,-4 ; right justify
LSHC T1,^D8 ; T1/ word 1
LSH T2,-^D8 ; right justify
LSHC T2,^D8 ; T2/ word 2
DMOVEM T1,(DST) ; save words 1-2
MOVE T1,T3 ; T1, bytes 10-12
LSH T1,-^D12 ; right-justify
DMOVE T2,4(SRC) ; T2,T3/ bytes 13-20
LSHC T1,^D12 ; T1/ word 3
LSH T2,-^D12 ; right justify
LSHC T2,^D12 ; T2/ word 4
DMOVEM T1,2(DST) ; save words 3-4
MOVE T1,T3 ; T1/ bytes 19-20
LSH T1,-^D20 ; right justify
DMOVE T2,6(SRC) ; T2,T3/ bytes 21-28
LSHC T1,^D20 ; T1/ word 5
LSH T2,-^D20 ; right justify
LSHC T2,^D20 ; T2/ word 6
DMOVEM T1,4(DST) ; save words 5-6
MOVE T1,T3 ; T1/ byte 28
LSH T1,-^D28 ; right justify
DMOVE T2,7(SRC) ; T2,T3/ bytes 29-36
LSHC T1,^D28 ; T1/ word 7
LSH T2,-^D28 ; right justify
LSHC T2,^D28 ; T2/ word 8
DMOVEM T2,6(DST) ; save words 7-8

Yeah, I know, it's actually 3 instructions for test/loop; an ADDI for one
pointer, an ADJSP for another, and a JUMPL to test the ADJSP pointer. So
31 instructions, not 30.

-- Mark --

http://panda.com/tops-20
TOPS-20: a great improvement over its successors
8-Aug-2006 13:11:29-PDT,2344;000000000000
Return-Path: <[email protected]>
Received: from pangtzu.panda.com ([206.124.149.117]) by lingling.panda.com with TCP/SMTP; Tue, 8 Aug 2006 13:09:55 -0700 (PDT)
X-Return-Path: <[email protected]>
X-Received: from newcheshire.xkl.com (clare.xkl.com [192.94.202.41]) by lingling.panda.com with TCP/SMTP; Tue, 8 Aug 2006 12:13:53 -0700 (PDT)
X-Received: from tardis.xkl.com (tardis.xkl.com [10.1.0.29])
by newcheshire.xkl.com (8.13.3/8.13.3/SuSE Linux 0.7) with ESMTP id k78JASuZ011390
for <[email protected]>; Tue, 8 Aug 2006 12:10:30 -0700
X-Received: from tardis.xkl.com (tardis.xkl.com [10.1.0.29])
by tardis.xkl.com (8.13.3/8.13.3/SuSE Linux 0.7) with ESMTP id k78JCGLv001153;
Tue, 8 Aug 2006 12:12:18 -0700
Subject: Re: Multi-forking program causes Tops-20 job to run out of fork
handles
From: Ralph Gorin <[email protected]>
Reply-To: [email protected]
To: [email protected]
Cc: [email protected]
In-Reply-To: <[email protected]>
References: <[email protected]>
Content-Type: text/plain
Organization: XKL, LLC; Redmond, WA
Date: Tue, 08 Aug 2006 12:12:15 -0700
Message-Id: <[email protected]>
Mime-Version: 1.0
X-Mailer: Evolution 2.2.1
Content-Transfer-Encoding: 7bit
ReSent-Date: Tue, 8 Aug 2006 13:09:46 -0700 (PDT)
ReSent-From: TOPS-20 List Moderator <[email protected]>
ReSent-To: TOPS-20 Distribution: ;
ReSent-Subject: Re: Multi-forking program causes Tops-20 job to run out of
fork handles
ReSent-Message-ID: <[email protected]>

1/ ,FHSUP
2/ ,FHSLF
GTFRK

creates a new relative fork handle, in effect, an alias
of .FHSUP. The new handle can't be released by RFRKH.
(RESET uses RFRKH to clean up a process's relative
fork handles.)

GFRKH increments the share count (FKHCNT field in
SYSFK) of the underlying (i.e., job-wide) fork handle
from 0 to 1. (Well, this is what happened in the test
I ran.) However, in RFRKH, there is test for a share
count that is greater than 1. Short of that value,
RFRKH returns the FRKHX1 error.

At first glance, it appears the test for greater than
one should be a test for greater than zero. But,
I'm not sure that I understand the semantics of
FKHCNT, so I'm not ready to recommend that as the fix.

Ralph

8-Aug-2006 16:57:34-PDT,5068;000000000000
Return-Path: <[email protected]>
Received: from pangtzu.panda.com ([206.124.149.117]) by lingling.panda.com with TCP/SMTP; Tue, 8 Aug 2006 16:55:58 -0700 (PDT)
X-Return-Path: <[email protected]>
X-Received: from a.mail.sonic.net ([64.142.16.245]) by lingling.panda.com with TCP/SMTP; Tue, 8 Aug 2006 16:48:07 -0700 (PDT)
X-Received: from Amiga.local (64-142-29-114.dsl.static.sonic.net [64.142.29.114])
by a.mail.sonic.net (8.13.8.Beta0-Sonic/8.13.7) with ESMTP id k78Nm2sv031053
for <[email protected]>; Tue, 8 Aug 2006 16:48:02 -0700
Date: Tue, 8 Aug 2006 16:48:02 -0700 (PDT)
From: Fred Wright <[email protected]>
X-Sender: [email protected]
Reply-To: Fred Wright <[email protected]>
To: [email protected]
Subject: Re: Tops-20 Extended mode FTP Server Update
In-Reply-To: <[email protected]>
Message-ID: <[email protected]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
ReSent-Date: Tue, 8 Aug 2006 16:55:50 -0700 (PDT)
ReSent-From: TOPS-20 List Moderator <[email protected]>
ReSent-To: TOPS-20 Distribution: ;
ReSent-Subject: Re: Tops-20 Extended mode FTP Server Update
ReSent-Message-ID: <[email protected]>

On Sat, 5 Aug 2006, Mark Crispin wrote:

> On Sat, 5 Aug 2006, [email protected] wrote:
> > I've had to spend a lot of time doing some heavy tweaking to get the
> > bit banging code to be correct and fast. For packing 36 bits into an
> > 8 byte data stream (retrieve), I use 32 instructions per 288 bit loop
> > or an average of 9 bits per instruction. For unpacking the 8 bit
> > network data into 36 bits (store), I use 40 instructions per 288 bit
> > loop or an average of 7.2 bits per instruction.
>
> Hmm, I just tried hand-coding a 36->32 bit-banger (using DMOVE/M, MOVE/M,
> and LSH/C) and came up with 30 instructions. With the test and loop,
> that's 32. So that sounds right.
>
> I'm definitely agreeable to adding a bit-banger to the klh10 microcode;
> perhaps something like the KS10 BLTBU/BLTUB instructions. Ideally, we
> would get XKL and perhaps SC on board with its definition.
>
> Ralph? Fred?

At this point in time I wouldn't count on making any significant additions
to the SC-x0 microcode. It wouldn't help anywhere near as much on the SC
machines, anyway, since many simple operations approach the hardware's
fundamental speed limits.

On Mon, 7 Aug 2006, Mark Crispin wrote:
> On Mon, 7 Aug 2006, [email protected] wrote:
>
> > The code that MACSYM generates for register saving sometimes speeds
> > things up over a bunch of PUSHs. One assumes that the additional KC
> > stack instructions would yield better performance due to the
> > instruction decodes that would be saved. We probably should consider
> > implementing them.
>
> There's been some debate about that, and in particular if those
> instructions actually are a savings.

And given the hassles of providing code alternatives for different
processor models, you need a pretty significant savings for it to be
justifiable. In the particular case of register save/restore, if you're
calling a function that's doing that in a tight loop, then your code is
badly designed to begin with. :-)

> > Also, the performance of the classic instruction set is even poorer
> > for doing the inverse operation (8 -> 36). Per 288 bit round, I use
> > 40 instructions per loop or abot 7.2 bits per instruction. For large
> > files, this can burn up a lot of CPU time with all the shifting,
> > or'ing and instruction decode times. I think that having an
> > instruction to do this would be a real win.
>
> You shouldn't need to OR. I suspect, but don't know for a fact, that
> shifting is faster.

On the SC-x0, not necessarily. The fundamental shift operation is ROT,
and turning it into LSH requires an additional masking step. In fact, on
the SC-30, ROT/TRZ is actually faster than LSH, but on the SC-40 it's a
breakeven.

Double-precision shifts are especially expensive, since the hardware
shifter is only sigle-precision. The worst case is ROTC, which has to
make a double-precision shift out of a single-precision shifter while
preserving all the bits, but LSHC and ASHC are no prize, either.

> > But the thing that really bugs me is the simple case of just shuttling
> > characters around!
>
> Agreed. Most people who use SOUT% to copy strings do so for code
> cleanliness, not for performance. The ILDP/IDPB loop is always better
> except in those cases where MOVSLJ is suitable.

And even then on the SC-x0, where the hardware is optimized for the simple
instructions. It looks like MOVSLJ is about 50% slower than
ILDB/IDPB/SOJG.

It's very different in an interpretive emulator, where a lot of the time
is spent decoding instructions. There, the more you can do in one
instruction the better off you are, and the primary optimization criterion
is just instruction count.

Fred Wright

8-Aug-2006 16:59:00-PDT,2123;000000000000
Return-Path: <[email protected]>
Received: from pangtzu.panda.com ([206.124.149.117]) by lingling.panda.com with TCP/SMTP; Tue, 8 Aug 2006 16:56:38 -0700 (PDT)
X-Return-Path: <[email protected]>
X-Received: from a.mail.sonic.net ([64.142.16.245]) by lingling.panda.com with TCP/SMTP; Tue, 8 Aug 2006 16:53:31 -0700 (PDT)
X-Received: from Amiga.local (64-142-29-114.dsl.static.sonic.net [64.142.29.114])
by a.mail.sonic.net (8.13.8.Beta0-Sonic/8.13.7) with ESMTP id k78NrQk1000941
for <[email protected]>; Tue, 8 Aug 2006 16:53:26 -0700
Date: Tue, 8 Aug 2006 16:53:25 -0700 (PDT)
From: Fred Wright <[email protected]>
X-Sender: [email protected]
Reply-To: Fred Wright <[email protected]>
To: [email protected]
Subject: Re: MOVSLJ behavior in non-zero sections on a Toad
In-Reply-To: <[email protected]>
Message-ID: <[email protected]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
ReSent-Date: Tue, 8 Aug 2006 16:56:26 -0700 (PDT)
ReSent-From: TOPS-20 List Moderator <[email protected]>
ReSent-To: TOPS-20 Distribution: ;
ReSent-Subject: Re: MOVSLJ behavior in non-zero sections on a Toad
ReSent-Message-ID: <[email protected]>

On Mon, 7 Aug 2006 [email protected] wrote:

> Actually, may I ask you to clarify this a bit?
>
> ILDB/IPDB/ADJSP and the like work fine in a non-zero section with two
> word pointers. One word global byte pointers also work. One word
> global byte pointers stay one word when used with the above and two
> word global pointers stay two words.
>
> Are you saying that I could use the string instructions if I used
> single word global byte pointers? I thought that they always
> converted one word pointers to two word pointers.
>
> > I'm aware of problems in Toad string insructions
> > with two-word byte pointers.

I believe the conversion is purely a KLism, to get around the fact that
the KL's OWGBP implementation is so horrible. It certainly doesn't happen
on the SC-x0, and it's moot on the KS.

Fred Wright

8-Aug-2006 17:39:17-PDT,6158;000000000000
Return-Path: <[email protected]>
Received: from pangtzu.panda.com ([206.124.149.117]) by lingling.panda.com with TCP/SMTP; Tue, 8 Aug 2006 17:37:46 -0700 (PDT)
X-Return-Path: <[email protected]>
X-Received: from mxout7.cac.washington.edu ([140.142.32.178]) by lingling.panda.com with TCP/SMTP; Tue, 8 Aug 2006 17:36:41 -0700 (PDT)
X-Received: from smtp.washington.edu (smtp.washington.edu [140.142.32.139])
by mxout7.cac.washington.edu (8.13.7+UW06.06/8.13.7+UW06.03) with ESMTP id k790aZOu015873;
Tue, 8 Aug 2006 17:36:35 -0700
X-Auth-Received: from Tomobiki-Cho.CAC.Washington.EDU (tomobiki-cho.cac.washington.edu [128.95.135.58])
(authenticated authid=mrc)
by smtp.washington.edu (8.13.7+UW06.06/8.13.7+UW06.03) with ESMTP id k790aYKa031830
(version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT);
Tue, 8 Aug 2006 17:36:35 -0700
Date: Tue, 8 Aug 2006 17:36:35 -0700 (Pacific Daylight Time)
From: Mark Crispin <[email protected]>
To: Fred Wright <[email protected]>
cc: TOPS-20 Hackers and Yackers <[email protected]>
Subject: Re: Tops-20 Extended mode FTP Server Update
In-Reply-To: <[email protected]>
Message-ID: <[email protected]>
References: <[email protected]>
Organization: Networks & Distributed Computing
Sender: [email protected]
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
X-PMX-Version: 5.2.0.264296, Antispam-Engine: 2.4.0.264935, Antispam-Data: 2006.8.8.172432
X-Uwash-Spam: Gauge=IIIIIII, Probability=7%, Report='__CP_URI_IN_BODY 0, __CT 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0'
ReSent-Date: Tue, 8 Aug 2006 17:37:38 -0700 (PDT)
ReSent-From: TOPS-20 List Moderator <[email protected]>
ReSent-To: TOPS-20 Distribution: ;
ReSent-Subject: Re: Tops-20 Extended mode FTP Server Update
ReSent-Message-ID: <[email protected]>

On Tue, 8 Aug 2006, Fred Wright wrote:
>> I'm definitely agreeable to adding a bit-banger to the klh10 microcode;
>> perhaps something like the KS10 BLTBU/BLTUB instructions. Ideally, we
>> would get XKL and perhaps SC on board with its definition.
> At this point in time I wouldn't count on making any significant additions
> to the SC-x0 microcode. It wouldn't help anywhere near as much on the SC
> machines, anyway, since many simple operations approach the hardware's
> fundamental speed limits.

OK, thanks. Even so, it would be useful to have SC to review and agree to
the definition of a 36<->32 bitbanger instruction (as in "if we ever do
it, we'll do it this way").

As said above, my thoughts are along the line of the KS10 BLTBU/BLTUB
instructions. Here's a strawman:

EXTEND ac,[XBLTBW]
;; similar to XBLT
;; AC/ number of 32-bit words.
;; AC+1/ source block (32-bit words) address.
;; AC+2/ destination block (36-bit words) address.

EXTEND ac,[XBLTWB]
;; similar to XBLT
;; AC/ number of 36-bit words.
;; AC+1/ source block (36-bit words) address.
;; AC+2/ destination block (32-bit words) address.

Both instructions will null-pad as needed if the word count is not a
multiple of 9 32-bit words (XBLTBW) or 8 36-bit words (XBLTWB).

I thought about also defining BLTBW and BLTWB instructions. The problem
is that, to correspond with BLT, BLTBU, BLTUB, E would hold the
destination end address. But, unlike any BLT, you can't calculate that
address by adding the count to the initial destination address minus one;
you have to do the 9/8 or 8/9 factoring as well.

The upshot is that I don't think that BLTBW and BLTWB would be are
particularly useful. I'm open to having my mind changed with persuasive
evidence.

> And given the hassles of providing code alternatives for different
> processor models, you need a pretty significant savings for it to be
> justifiable. In the particular case of register save/restore, if you're
> calling a function that's doing that in a tight loop, then your code is
> badly designed to begin with. :-)

I think that the justification in the KC10 was that saving registers was
done often enough that it would be an overall win.

Of course, that presumes that every program is specially recompiled so
that it saves/restored registers with those instructions. The problem is
that such benefits are dwarfed by the attraction of porting user mode
binaries.

It took forever before use of ADJSP and ADJBP was widely accepted. I
don't think that either instruction ever caught on in the TOPS-10 or ITS
worlds. They did better in TOPS-20, since all TOPS-20 capable systems had
them. Still, for quite a while the Tenex community objected vociferously
to TOPS-20 programmers using these instructions. This got muted after
TOPS-20 release 3, as porting between Tenex and TOPS-20 became much less
feasible and Tenex started to fade from the picture.

> On the SC-x0, not necessarily. The fundamental shift operation is ROT,
> and turning it into LSH requires an additional masking step. In fact, on
> the SC-30, ROT/TRZ is actually faster than LSH

Wow. How is that possible?

> Double-precision shifts are especially expensive, since the hardware
> shifter is only single-precision.

Ouch. The bit-banger code that I suggested uses LSHC.

> And even then on the SC-x0, where the hardware is optimized for the simple
> instructions. It looks like MOVSLJ is about 50% slower than
> ILDB/IDPB/SOJG.

Ouch again. The TOPS-10/20 DECnet Phase IV code makes extensive use of
MOVSLJ because on the KL (and, I think, KS) it is generally faster than
the ILDB/IDPB/SOJG loop.

Is this optimization in the actual SC hardware, or in the microcode, or a
bit of both?

> It's very different in an interpretive emulator

Yup. I suspect that microcode extensions are always going to be a win
in klh10.

-- Mark --

http://staff.washington.edu/mrc
Science does not emerge from voting, party politics, or public debate.
Si vis pacem, para bellum.
8-Aug-2006 18:05:20-PDT,2676;000000000000
Return-Path: <[email protected]>
Received: from pangtzu.panda.com ([206.124.149.117]) by lingling.panda.com with TCP/SMTP; Tue, 8 Aug 2006 18:03:51 -0700 (PDT)
X-Return-Path: <[email protected]>
X-Received: from mxout1.cac.washington.edu ([140.142.32.134]) by lingling.panda.com with TCP/SMTP; Tue, 8 Aug 2006 18:03:23 -0700 (PDT)
X-Received: from smtp.washington.edu (smtp.washington.edu [140.142.32.139])
by mxout1.cac.washington.edu (8.13.7+UW06.06/8.13.7+UW06.03) with ESMTP id k7913Hus022417
(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
Tue, 8 Aug 2006 18:03:17 -0700
X-Auth-Received: from Tomobiki-Cho.CAC.Washington.EDU (tomobiki-cho.cac.washington.edu [128.95.135.58])
(authenticated authid=mrc)
by smtp.washington.edu (8.13.7+UW06.06/8.13.7+UW06.03) with ESMTP id k7913H5M002833
(version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT);
Tue, 8 Aug 2006 18:03:17 -0700
Date: Tue, 8 Aug 2006 18:03:17 -0700 (Pacific Daylight Time)
From: Mark Crispin <[email protected]>
To: Fred Wright <[email protected]>
cc: TOPS-20 Hackers and Yackers <[email protected]>
Subject: Re: MOVSLJ behavior in non-zero sections on a Toad
In-Reply-To: <[email protected]>
Message-ID: <[email protected]>
References: <[email protected]>
Organization: Networks & Distributed Computing
Sender: [email protected]
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
X-PMX-Version: 5.2.0.264296, Antispam-Engine: 2.4.0.264935, Antispam-Data: 2006.8.8.174932
X-Uwash-Spam: Gauge=IIIIIII, Probability=7%, Report='__CP_URI_IN_BODY 0, __CT 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0'
ReSent-Date: Tue, 8 Aug 2006 18:03:42 -0700 (PDT)
ReSent-From: TOPS-20 List Moderator <[email protected]>
ReSent-To: TOPS-20 Distribution: ;
ReSent-Subject: Re: MOVSLJ behavior in non-zero sections on a Toad
ReSent-Message-ID: <[email protected]>

On Tue, 8 Aug 2006, Fred Wright wrote:
> I believe the conversion is purely a KLism, to get around the fact that
> the KL's OWGBP implementation is so horrible. It certainly doesn't happen
> on the SC-x0, and it's moot on the KS.

XKL processors don't convert the pointers either. However, klh10
processors (in the name of KL compatibility) do.

I agree that it's better not to convert.

-- Mark --

http://staff.washington.edu/mrc
Science does not emerge from voting, party politics, or public debate.
Si vis pacem, para bellum.
9-Aug-2006 11:54:51-PDT,7380;000000000000
Return-Path: <[email protected]>
Received: from pangtzu.panda.com ([206.124.149.117]) by lingling.panda.com with TCP/SMTP; Wed, 9 Aug 2006 11:52:59 -0700 (PDT)
Mail-From: MRC created at 9-Aug-2006 11:49:37
Date: Wed, 9 Aug 2006 11:49:37 -0700 (PDT)
From: Mark Crispin <[email protected]>
Subject: GETCPU.MAC now detects SC-40 CPUs
To: [email protected]
Pithy-Thought: TOPS-20 was a great improvement over its successors
Message-ID: <[email protected]>
ReSent-Date: Wed, 9 Aug 2006 11:52:50 -0700 (PDT)
ReSent-From: TOPS-20 List Moderator <[email protected]>
ReSent-To: TOPS-20 Distribution: ;
ReSent-Subject: GETCPU.MAC now detects SC-40 CPUs
ReSent-Message-ID: <[email protected]>

It turns out that there is a detectable difference between the SC-40 and
klh10. KLH10 implements the (bizarre) KL10 behavior for OWGBPs in the
MOVSLJ instruction: in section 0 the pointer is unchanged and in non-zero
sections the pointer is changed to a two-word pointer. SC-40, XKL-1,
and presumably other SC processors implement the much more rational behavior
of always updating the OWGBP.

I have a copy of GETCPU.MAC available via anonymous FTP on <MRC>GETCPU.MAC
on xkleten.paulallen.com. Here is what is looks like now:

TITLE GETCPU Get CPU type
SUBTTL Mark Crispin 9 August 2006

; Special notes for ITS systems:
; On ITS, you need to set an illegal instruction trap handler. If an
; illegal instruction trap happens in EITSKL, jump to GTCKL; and if an
; illegal instruction trap happens in EITSKS, jump to GTCKS.

; PDP-10 CPU types for all to see.
; [*] means that the CPU type is recognized by this routine

$CPUKN==:0 ; [*] unknown

; The following CPU types actually exist or once existed

; 1-7 for Digital Equipment Corporation (R.I.P.)
$CP166==:1 ; [*] PDP-6
$CPKA==:2 ; [*] KA10
$CPKI==:3 ; [*] KI10
$CPKL==:4 ; [*] KL10
$CPKS==:5 ; [*] KS10
$CPKC==:6 ; [ ] KC10 (two were built)
; 10-17 for Xerox Corporation (inactive)
$CPMXC==:11 ; [ ] MAXC
$CPMX2==:12 ; [ ] MAXC 2
; 20-17 for Foonly/Tymshare (R.I.P.)
$CPFO1==:21 ; [ ] Foonly F1
$CPFO2==:22 ; [*] Foonly F2
$CPFO3==:23 ; [ ] Foonly F3
$CPFO4==:24 ; [ ] Foonly F4
$CPFO5==:25 ; [ ] Foonly F5
$CP26K==:27 ; [ ] Tymshare 26KL
; 30-37 for Systems Concepts (now SC Group)
$CPSC2==:32 ; [ ] SC-20
$CPSC3==:33 ; [ ] SC-30
$CPSC4==:34 ; [*] SC-40
; 40-47 for XKL Systems, LLC
$CPXK1==:41 ; [*] XKL-1 (TOAD)
; 50-57 for Ken Harrenstein
$CPKHL==:51 ; [*] KLH10 KN10-KL
$CPKHS==:52 ; [ ] KLH10 KN10-KS
; 60-67 for Bob Supnik
$CPSHS==:61 ; [ ] SIMH/KS
; 70-77 for Tim Stark (inactive?)
$CPTSS==:71 ; [ ] TS10/KS
; 100-107 for Stu Grossman (inactive)
$CPKXL==:101 ; [*] KX10/KL

; The CPU type codes on this page are known efforts, but are incomplete.
; If/when any of these become more real they will be assigned a $CPxxxx code.

; The following are believed to be works that are still in progress

$CXDCC==:660001 ; [ ] [David Conroy] hardware clone

; The following are believed to be incomplete and permanently abandoned

$XDCUC==:770001 ; [ ] [DEC] Unicorn
$XDCDL==:770002 ; [ ] [DEC] Dolphin
$XDCMN==:770003 ; [ ] [DEC] Minnow
$XFO1B==:770010 ; [ ] [Foonly] F1B
$XMGSM==:770020 ; [ ] [Megan Gentry] SIM10 (merged into TS10)
$XDSE1==:770030 ; [ ] [Daniel Seagraves] E10
$XESXX==:770040 ; [ ] [Eric Smith]

; Get CPU type
; PUSHJ 17,GETCPU
; Returns +1: Always, 1/ CPU type code, all other ACs preserved
;
; This routine is designed to be easy to modify/extend at the cost of some
; code size.

GETCPU::JUMPGE 17,GETCPN ; don't test for PDL overflow if underflow PDL
HLRE 1,17 ; get size of remaining PDL
ADDI 1,16 ; account for space used
JUMPGE 1,GTCUKN ; lose if PDL will overflow
GETCPN: PUSH 17,0 ; save AC0
ADD 17,[15,,15] ; seize stack space (can't use ADJSP)
HRLI 1,2 ; start saving at AC2
HRRI 1,-14(17) ; next stack location
BLT 1,(17) ; save ACs
PUSHJ 17,GETCP0
HRLI 16,-14(17) ; restore ACs
HRRI 16,2
BLT 16,16
SUB 17,[15,,15] ; return stack space (can't use ADJSP)
POP 17,0 ; restore AC0
POPJ 17,

; PDP-6 type processors
GETCP0: JFCL 17,.+1 ; clear flags
JRST .+1 ; change PC
JFCL 1,GTC166 ; PDP-6 has PC Change flag

; KA10 type processors
SETO 1, ; AOBJN of -1
AOBJN 1,.+1 ; KA10 and Foonly F2 carries to left half
JUMPE 1,GETCP1
HRLOI 1,010700 ; IBP of EA = -1
IBP 1
TLNE 1,17 ; KA10 overflows
JRST GTCKA
JRST GTCFO2 ;;; assume Foonly F2

; KI10 type processors, here with 1/0, always
GETCP1: BLT 1,0 ; AC must not be 0
JUMPE 1,GTCKI

; KL10 type processors
MOVSI 1,400000 ; ADJBP of normalized pointer by SETZ
ADJBP 1,[430100,,0]
CAME 1,[430100,,0] ; pointer changed?
JRST GETCP2 ; yes, not a KL10 type
SETOB 1,2 ; double-length -1
SETZ 3, ; unused but set zero just in case
MOVEI 4,1 ; string length of 1
SETZB 5,6 ; null byte pointer
;; KL10 with ITS microcode gets an illegal instruction trap here
EITSKL: EXTEND 1,[CVTBDO] ; test for KL10 vs. KX10
JRST GETC1A ; failed
TLC 4,300000 ; success, N and M bits set properly?
TLNN 4,777000
JRST GTCKL ; KL10 sets N and M bits
JRST GTCUKN ; unknown CPU

; CVTBDO failed
GETC1A: CAMN 4,[200000,,1] ; KX10 only sets N bit and doesn't clear 9:35
JRST GTCKXL
JRST GTCUKN ; unknown CPU

; KS10 type processors
GETCP2: MOVSI 1,450000 ; IBP of OWGBP
IBP 1
CAME 1,[450000,,0] ; KS10 doesn't do OWGBPs
JRST GETCP3 ; modern processors do OWGBP even in section 0
MOVEI 1,1 ; large binary integer
SETZB 2,3
MOVEI 4,1 ; string length of 1
SETZB 5,6 ; null byte pointer
;; KS10 with ITS microcode gets an illegal instruction trap here
;; KLH-KS-ITS gets an illegal instruction trap here
EITSKS: EXTEND 1,[CVTBDO] ; test for KL10 vs. KS10
JRST GETC2A ; should always fail
JRST GTCUKN ; unknown CPU

GETC2A: TLNE 4,200000 ; KS doesn't set N bit
JRST GETCP5 ; probably SC processor with KI paging
CAIN 4,1 ; SIMH leaves AC+3 untouched
JRST GTCSHS
JRST GTCKS

; XKL type processors
GETCP3: MOVSI 1,400000 ; SETZ divided by -1
SETO 2,
IDIVM 1,2
AOJE 2,GETCP4 ; KL-style No Divide and don't modify 2
JRST GTCXK1 ; XKL-1 does KS-style (SETZ in 2)

; KLH-KL and SC processors
GETCP4: DMOVE 1,[1 ; source 1 byte
610000,,10] ; section 0 OWGBP
SETZB 3,6
DMOVE 4,[1 ; destination similar to source
610000,,11]
EXTEND 1,[MOVSLJ]
JRST GTCUKN ; unknown CPU
CAMN 2,[620000,,10] ; SC40 [and XKL-1] always increments OWGBP
JRST GETCP5
; KLH-KL [and KL10] in section 0 leaves pointer unchanged; in non-zero
; sections converts to two-word pointer.
JRST GTCKHL ; assume KLH-KL

; SC processors
GETCP5: JRST GTCSC4 ; assume SC40

; Return values

GTCUKN: MOVEI 1,$CPUKN
POPJ 17,

GTC166: MOVEI 1,$CP166
POPJ 17,

GTCKA: MOVEI 1,$CPKA
POPJ 17,

GTCKI: MOVEI 1,$CPKI
POPJ 17,

GTCKL: MOVEI 1,$CPKL
POPJ 17,

GTCKS: MOVEI 1,$CPKS
POPJ 17,

GTCFO2: MOVEI 1,$CPFO2
POPJ 17,

GTCKHL: MOVEI 1,$CPKHL
POPJ 17,

GTCXK1: MOVEI 1,$CPXK1
POPJ 17,

GTCSC4: MOVEI 1,$CPSC4
POPJ 17,

GTCSHS: MOVEI 1,$CPSHS
POPJ 17,

GTCKXL: MOVEI 1,$CPKXL
POPJ 17,

END
-------
9-Aug-2006 18:58:00-PDT,2590;000000000000
Return-Path: <[email protected]>
Received: from pangtzu.panda.com ([206.124.149.117]) by lingling.panda.com with TCP/SMTP; Wed, 9 Aug 2006 18:56:06 -0700 (PDT)
X-Return-Path: <[email protected]>
X-Received: from mxout7.cac.washington.edu ([140.142.32.178]) by lingling.panda.com with TCP/SMTP; Wed, 9 Aug 2006 13:46:45 -0700 (PDT)
X-Received: from smtp.washington.edu (smtp.washington.edu [140.142.32.139])
by mxout7.cac.washington.edu (8.13.7+UW06.06/8.13.7+UW06.03) with ESMTP id k79KkeBl004139
(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK)
for <[email protected]>; Wed, 9 Aug 2006 13:46:40 -0700
X-Auth-Received: from Shimo-Tomobiki.panda.com ([65.122.177.186])
(authenticated authid=mrc)
by smtp.washington.edu (8.13.7+UW06.06/8.13.7+UW06.03) with ESMTP id k79Kkc3r016197
(version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT)
for <[email protected]>; Wed, 9 Aug 2006 13:46:39 -0700
Date: Wed, 9 Aug 2006 13:46:33 -0700
From: Mark Crispin <[email protected]>
To: TOPS-20 Hackers and Yackers <[email protected]>
Subject: OWGBPs in MOVSLJ instruction
Message-ID: <[email protected]>
Organization: Networks & Distributed Computing
Sender: [email protected]
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
X-PMX-Version: 5.2.0.264296, Antispam-Engine: 2.4.0.264935, Antispam-Data: 2006.8.9.132933
X-Uwash-Spam: Gauge=IIIIIII, Probability=7%, Report='__CP_URI_IN_BODY 0, __CT 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0'
ReSent-Date: Wed, 9 Aug 2006 18:55:58 -0700 (PDT)
ReSent-From: TOPS-20 List Moderator <[email protected]>
ReSent-To: TOPS-20 Distribution: ;
ReSent-Subject: OWGBPs in MOVSLJ instruction
ReSent-Message-ID: <[email protected]>

For the record, here is what I determined about the behavior of OWGBPs in
the MOVSLJ instruction.

My test was with a pair of 7-bit OWGBPs, each pointing to section 0 ACs,
and with a 1 byte count.

The KL10 does something completely stupid. In section 0 it does not
update the pointers at all. In a non-zero section, it replaces the OWGBPs
with updated two-word byte pointers.

klh10 faithfully implements this stupid behavior.

The SC40 and XKL-1 return updated OWGBPs, which is far more sensible
behavior.

-- Mark --

http://staff.washington.edu/mrc
Science does not emerge from voting, party politics, or public debate.
Si vis pacem, para bellum.
11-Aug-2006 20:32:11-PDT,6391;000000000000
Return-Path: <[email protected]>
Received: from pangtzu.panda.com ([206.124.149.117]) by lingling.panda.com with TCP/SMTP; Fri, 11 Aug 2006 20:29:52 -0700 (PDT)
X-Return-Path: <[email protected]>
X-Received: from mta6.srv.hcvlny.cv.net ([167.206.4.201]) by lingling.panda.com with TCP/SMTP; Fri, 11 Aug 2006 18:29:32 -0700 (PDT)
X-Received: from optonline.net (hamstr3.srv.hcvlny.cv.net [167.206.5.10])
by mta6.srv.hcvlny.cv.net
(Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006))
with ESMTP id <[email protected]>; Fri,
11 Aug 2006 21:29:21 -0400 (EDT)
X-Received: from [10.240.3.204] (Forwarded-For: [10.240.3.204])
by mstr3.srv.hcvlny.cv.net (mshttpd); Sat, 12 Aug 2006 01:29:20 +0000 (GMT)
Date: Sat, 12 Aug 2006 01:29:20 +0000 (GMT)
From: [email protected]
Subject: Re: Tops-20 Extended mode FTP Server Update
In-reply-to: <[email protected]>
To: Mark Crispin <[email protected]>
Cc: [email protected]
Message-id: <[email protected]>
MIME-version: 1.0
X-Mailer: Sun Java(tm) System Messenger Express 6.2-6.01 (built Apr 3 2006)
Content-type: text/plain; charset=us-ascii
Content-language: en
Content-transfer-encoding: 7BIT
Content-disposition: inline
X-Accept-Language: en
Priority: normal
References: <[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
ReSent-Date: Fri, 11 Aug 2006 20:29:42 -0700 (PDT)
ReSent-From: TOPS-20 List Moderator <[email protected]>
ReSent-To: TOPS-20 Distribution: ;
ReSent-Subject: Re: Tops-20 Extended mode FTP Server Update
ReSent-Message-ID: <[email protected]>

I've done some more work on the server, here's what I've got:

It turns out that the small buffer problem I had with writing TYPE I
(IMAGE, 36 bit buffers), was a false negative. I'm actually doing
everything fine.

Like your code, my 36 to 8 bit banger achieves its speed due to the
fact that it assumes that it can leave crud in the last four bits of
the words in the output buffer. When doing an eight bit SOUT% to the
TCP/IP network, this works fine.

However, when debugging and doing the exact same SOUT% to the disk,
Tops-20 will look to see if it can invoke BYTBLT (in IO.MAC) to
transfer words instead of bytes. This causes the crud in bits 32
through 35 to be written to disk. That isn't a big deal if you read
the file back in 8 bit mode, but FILCOM doesn't when you use the /W
(compare binary) switch. It's reading 36 bit bytes. So you get false
negatives. To prevent this and be able to properly test, you must
'scrub' every round with the following, viz:

MOVE T1,[777777777760]
ANDM T1,^D0(Q2)
ANDM T1,^D1(Q2)
ANDM T1,^D2(Q2)
ANDM T1,^D3(Q2)
ANDM T1,^D4(Q2)
ANDM T1,^D5(Q2)
ANDM T1,^D6(Q2)
ANDM T1,^D7(Q2)
ANDM T1,^D8(Q2)

Once I found this, I went and tested the code that you sent me. The
good news is that it's definately faster. The largest loop that I can
do is 29,127 288 bit rounds per 8 bit output section buffer. This
takes me 2.82789 seconds of CPU time. Your code is ten microseconds
faster ...

Unfortunately, it's not producing the right results and leaves a lot
of zeros in the output stream. I know it was gedanken, but thanks
anyway. I couldn't tell you what is wrong with it: as I've whined
before, bit banging is difficult for me. For the record, here is what
I am doing:

DMOVE T1,^D0(P2) ; Load input bits 0 through 71
MOVEM T1,^D0(Q2) ; Deposit Internet bytes 0 through 3
LSHC T1,^D32 ; Shift low nybble, top nybble, 3 bytes
MOVEM T1,^D1(Q2) ; Deposit Internet bytes 4 through 7
LSHC T1,^D4 ; Shift in the upper nybble
MOVE T2,^D2(P2) ; Load input bits 72 through 107
LSHC T1,^D28 ; Shift in three bytes and a nybble
MOVEM T1,^D2(Q2) ; Deposit Internet bytes 8 through 11
LSHC T1,^D8 ; Combine lower and upper nybble, next nybble
MOVE T2,^D3(P2) ; Load input bits 108 through 143
LSHC T1,^D24 ; Shift in nybble, two bytes and a nybble
MOVEM T1,^D3(Q2) ; Deposit Internet bytes 12 through 15
LSHC T1,^D12 ; Combine low and top nybble, plus another byte
MOVE T2,^D4(P2) ; Load input bits 144 through 179
LSHC T1,^D20 ; Shift in four bytes
MOVEM T1,^D4(Q2) ; Deposit Internet bytes 16 through 19
LSHC T1,^D16 ; Shift nybble, byte, nybble
MOVE T2,^D5(P2) ; Load input bits 180 through 215
LSHC T1,^D16 ; Shift nybble, byte, nybble
MOVEM T1,^D5(Q2) ; Deposit Internet bytes 20 through 23
LSHC T1,^D20 ; Pick up a nybble, two bytes
MOVE T2,^D6(P2) ; Load input bits 216 through 251
LSHC T1,^D12 ; Shift in a byte and a nybble
MOVEM T1,^D6(Q2) ; Deposit Internet bytes 24 through 27
LSHC T1,^D24 ; Shift in nybble, two bytes and a nybble
MOVE T2,^D7(P2) ; Load input bits 252 through 287
LSHC T1,^D4 ; Shift in final nybble
LSH T1,^D4 ; Position Internet word to bit 0
DMOVEM T1,^D7(Q2) ; Deposit Internet bytes 28 - 31, 32 - 35
XMOVEI P2,^D8(P2) ; Account for eight 36 bit words (288 bits)
XMOVEI Q2,^D9(Q2) ; Account for nine 32 bit words (288 bits)

Pretty straightforward, but it took me a long time to get it right.
If you (or anyone else) feel like tweaking either of these routines up
to get some more more speed, I will be delighted to use them.

I've also had some thoughts about your proposed bit banging
instructions, but I'd like to mull things over some more before
volunteering an opinion.

So it's down to linking the 8 bit to 36 bit banging code into the
(updated) buffering scheme, page file structures and I'll have an
alpha candidate.

11-Aug-2006 20:41:49-PDT,2249;000000000000
Return-Path: <[email protected]>
Received: from pangtzu.panda.com ([206.124.149.117]) by lingling.panda.com with TCP/SMTP; Fri, 11 Aug 2006 20:40:21 -0700 (PDT)
X-Return-Path: <[email protected]>
X-Received: from pangtzu.panda.com ([206.124.149.117]) by lingling.panda.com with TCP/SMTP; Fri, 11 Aug 2006 20:39:12 -0700 (PDT)
Date: Fri, 11 Aug 2006 20:39:07 -0700 (PDT)
From: Mark Crispin <[email protected]>
Sender: [email protected]
To: [email protected]
cc: [email protected]
Subject: Re: Tops-20 Extended mode FTP Server Update
In-Reply-To: <[email protected]>
Message-ID: <[email protected]>
References: <[email protected]>
<[email protected]> <[email protected]>
<[email protected]>
<[email protected]> <[email protected]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
ReSent-Date: Fri, 11 Aug 2006 20:40:12 -0700 (PDT)
ReSent-From: TOPS-20 List Moderator <[email protected]>
ReSent-To: TOPS-20 Distribution: ;
ReSent-Subject: Re: Tops-20 Extended mode FTP Server Update
ReSent-Message-ID: <[email protected]>

On Sat, 12 Aug 2006, [email protected] wrote:
> Once I found this, I went and tested the code that you sent me. The
> good news is that it's definately faster. The largest loop that I can
> do is 29,127 288 bit rounds per 8 bit output section buffer. This
> takes me 2.82789 seconds of CPU time. Your code is ten microseconds
> faster ...

Well, 10us in 2.8 seconds is not significant IMHO. I don't know why it
didn't work, but as I never tested it I'm not surprised that there isn't
some silly blunder in there. Anyway, with that small a performance
difference it isn't worth fixing if you have working code.

The 36->32 code assumed that the input was in multiples of 8, and the
32->36 code assumed that the input was in multiples of 9. But I guess
that your code does so as well.

-- Mark --

http://panda.com/tops-20
TOPS-20: a great improvement over its successors
13-Aug-2006 08:55:09-PDT,5643;000000000000
Return-Path: <[email protected]>
Received: from pangtzu.panda.com ([206.124.149.117]) by lingling.panda.com with TCP/SMTP; Sun, 13 Aug 2006 08:53:12 -0700 (PDT)
X-Return-Path: <[email protected]>
X-Received: from mta6.srv.hcvlny.cv.net ([167.206.4.201]) by lingling.panda.com with TCP/SMTP; Sun, 13 Aug 2006 05:54:33 -0700 (PDT)
X-Received: from optonline.net (hamstr3.srv.hcvlny.cv.net [167.206.5.10])
by mta6.srv.hcvlny.cv.net
(Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006))
with ESMTP id <[email protected]> for
[email protected]; Sun, 13 Aug 2006 08:54:27 -0400 (EDT)
X-Received: from [10.240.3.210] (Forwarded-For: [10.240.3.210])
by mstr3.srv.hcvlny.cv.net (mshttpd); Sun, 13 Aug 2006 12:54:26 +0000 (GMT)
Date: Sun, 13 Aug 2006 12:54:26 +0000 (GMT)
From: [email protected]
Subject: Re: OWGBPs in MOVSLJ instruction
In-reply-to: <[email protected]>
To: Mark Crispin <[email protected]>
Cc: TOPS-20 Hackers and Yackers <[email protected]>
Message-id: <[email protected]>
MIME-version: 1.0
X-Mailer: Sun Java(tm) System Messenger Express 6.2-6.01 (built Apr 3 2006)
Content-type: text/plain; charset=us-ascii
Content-language: en
Content-transfer-encoding: 7BIT
Content-disposition: inline
X-Accept-Language: en
Priority: normal
References: <[email protected]>
ReSent-Date: Sun, 13 Aug 2006 08:53:04 -0700 (PDT)
ReSent-From: TOPS-20 List Moderator <[email protected]>
ReSent-To: TOPS-20 Distribution: ;
ReSent-Subject: Re: OWGBPs in MOVSLJ instruction
ReSent-Message-ID: <[email protected]>

> The KL10 does something completely stupid. In section 0 it does not
> update the pointers at all.

How fortunate that I decided to make the server be an extended mode
program to begin with, using multiple sections for code and text.
However, I do use OWGP's all over the place to reference text in
section 0 (particularly as arguments to certain Jsyi), but they are
'read' only, meaning I don't do anything with the updated pointers.

> In a non-zero section, it replaces the OWGBPs with updated two-word
> byte pointers.

It is unfortunate behavior, but it IS documented on page 2-92 of the
June 1982 PRM. I think I remember seeing it it in earlier versions,
also. One speculates that it got done that way in part due to
microcode space constraints caused by the dedication of CRAM to the
nearly infinitely useless EDIT instruction. Oh well, at least they
didn't do EDIT AND MARK, PACK and PACK AND MARK ... Marketing!

> klh10 faithfully implements this stupid behavior.

Indeed. In fact, the server now DEPENDS on it. It enables me to be
lazy about certain operations and bum a few instructions by simply
doing an XMOVEI on the address offset and not have to seperately futz
with the position and field bits. A minor thing, but I do do it, not
that I couldn't go to using OWGP's: the code is straight forward
enough.

With regard to being 'faithful', I've toyed with the idea of making
KLH10 itself follow the SC40 and XKL-1 model. Provided that the two
unused accumulators were untouched, it would make scheduling the
register file a lot easier. But, at this point, it looks like
programs expect this behavior (see below).

For now, I've insured that I continue to work on an SC40 by converting
the single word pointers to double ones before I hit the EXTENDed
instruction and converting them back afterwards. MAPSER appears to
take a different approach: everything gets converted to single
pointers. If the EXTEND returns a single pointer, then simply it uses
that. If it notices a double result, it converts it to single.

I think this might be a better way to go and may change the extended
mode FTP server to follow this paradigm at some point, depending on
how much tinkering I have to do. I'd be able to go back to using
EXTENDed string instructions on the XKL and it would be interesting to
see how much they save.

At least on KLH10, they do save some CPU time, although I haven't
really sat down and thought about how to characterize the results. As
a base comparision, using no instructions at all to transfer a file (8
bit bytes), I take 3.483 seconds to retrieve a 1032 page listing.

To use MOVSLJ to 'convert' a 7 bit ASCII file to 8 bit ASCII, I take
about 6.8 seconds to do the same file. So, it looks like roughly half
of the additional processor time is being expended on shuttling
2,111,596 characters using EXTEND. When using 'classic' instructions
to do the same thing, I take 7.527 seconds. It would appear that
going 'classic' results in a 21% CPU time increase.

To use a MOVST to retrieve the same listing and convert it to Unix
format, I take 5.897 seconds of CPU time, which is most counter-
intuitive; perhaps some of the additional time may be due to the fact
that the output file is 20 pages smaller. Using 'classic'
instructions, I take 7.857 CPU seconds. This is an 81% CPU time
increase.

To use a MOVST to convert an 8 bit Unix file file to 7 bit ASCII, the
server uses 12.889 CPU seconds (this is a more processor intensive
activity). Using 'classic' instructions, the usage is 22.38 CPU
seconds, which is more in line with what I would have expected: it's a
200% CPU usage increase.

What do you think? I don't remember what we billed for CPU time for
commercial users, but I know that it was by the CPU second and
fractional portion thereof. Frank? Anybody?
13-Aug-2006 14:54:20-PDT,9056;000000000000
Return-Path: <[email protected]>
Received: from pangtzu.panda.com ([206.124.149.117]) by lingling.panda.com with TCP/SMTP; Sun, 13 Aug 2006 14:53:12 -0700 (PDT)
X-Return-Path: <[email protected]>
X-Received: from mta2.srv.hcvlny.cv.net ([167.206.4.197]) by lingling.panda.com with TCP/SMTP; Sun, 13 Aug 2006 13:05:16 -0700 (PDT)
X-Received: from optonline.net (hamstr3.srv.hcvlny.cv.net [167.206.5.10])
by mta2.srv.hcvlny.cv.net
(Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006))
with ESMTP id <[email protected]> for
[email protected]; Sun, 13 Aug 2006 16:05:10 -0400 (EDT)
X-Received: from [10.240.3.196] (Forwarded-For: [10.240.3.196])
by mstr3.srv.hcvlny.cv.net (mshttpd); Sun, 13 Aug 2006 20:05:09 +0000 (GMT)
Date: Sun, 13 Aug 2006 20:05:09 +0000 (GMT)
From: [email protected]
Subject: Re: Tops-20 Extended mode FTP Server Update
In-reply-to: <[email protected]>
To: Fred Wright <[email protected]>
Cc: [email protected]
Message-id: <[email protected]>
MIME-version: 1.0
X-Mailer: Sun Java(tm) System Messenger Express 6.2-6.01 (built Apr 3 2006)
Content-type: multipart/alternative;
boundary="Boundary_(ID_Xa0540o7om6G32OIVqmjCg)"
Content-language: en
X-Accept-Language: en
Priority: normal
References: <[email protected]>
<[email protected]>
ReSent-Date: Sun, 13 Aug 2006 14:52:48 -0700 (PDT)
ReSent-From: TOPS-20 List Moderator <[email protected]>
ReSent-To: TOPS-20 Distribution: ;
ReSent-Subject: Re: Tops-20 Extended mode FTP Server Update
ReSent-Message-ID: <[email protected]>

This is a multi-part message in MIME format.

--Boundary_(ID_Xa0540o7om6G32OIVqmjCg)
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7BIT
Content-disposition: inline

> In the particular case of register save/restore, if you're calling a
> function that's doing that in a tight loop, then your code is badly
> designed to begin with. :-)
Heh ... The following code from my favorite spooler comes to mind:
LPTE.1: SOSL J$DBCT(J) ;COUNT DOWN AND JUMP IF DATA IS THERE.
JRST LPTE.2 ;GO GET A DATA BYTE.
PUSHJ P,INPBUF ;ELSE, GET A BUFFER FULL
JUMPT LPTE.1 ;IF OK,,GET NEXT FOUR BYTES
$RETT ;ELSE RETURN.
LPTE.2: ILDB P1,J$DBPT(J) ;GET 4 BYTES TO PRINT
LDB C,[POINT 8,P1,17] ;GET THE FIRST BYTE
PUSHJ P,LPTE.3 ;PRINT IT
LDB C,[POINT 8,P1,9] ;GET SECOND BYTE
PUSHJ P,LPTE.3 ;PRINT IT
LDB C,[POINT 8,P1,35] ;GET THIRD BYTE
PUSHJ P,LPTE.3 ;PRINT IT
LDB C,[POINT 8,P1,27] ;GET FOURTH BYTE
PUSHJ P,LPTE.3 ;PRINT IT
JRST LPTE.1 ;GET THE NEXT FOUR BYTES
And remember, this isn't just amateurish dabbling folks, it's
COMMERCIAL quality programming; so don't this at home :-)
Actually it's not saving registers, but only doing a call for every
character ... Bad example ...
Oh well, I can have a good chuckle now, but Galaxy was nearly my full
time job for six years. We had six 20's and (a few?) Vaxen and
everybody wanted to print everywhere and do everything. Needless to
say, new releases could be challenging ...

--Boundary_(ID_Xa0540o7om6G32OIVqmjCg)
Content-type: text/html; charset=us-ascii
Content-transfer-encoding: quoted-printable
Content-disposition: inline

=3CP=3E=26gt=3B In the particular case of register save/restore=2C if yo=
u=27re calling a=3CBR=3E=26gt=3B function that=27s doing that in a tight=
loop=2C then your code is badly=3CBR=3E=26gt=3B designed to begin with=2E=
=3A-)=3C/P=3E
=3CP=3EHeh =2E=2E=2E=26nbsp=3B The following code from my favorite spool=
er comes to mind=3A=3C/P=3E
=3CP=3ELPTE=2E1=3A SOSL=26nbsp=3B=26nbsp=3B=26nbsp=3B J=24DBCT(J)=26nbsp=
=3B=26nbsp=3B=26nbsp=3B=26nbsp=3B=26nbsp=3B=26nbsp=3B=26nbsp=3B=26nbsp=3B=
=26nbsp=3B=26nbsp=3B=26nbsp=3B=26nbsp=3B=26nbsp=3B=26nbsp=3B =3BCOUNT DO=
WN AND JUMP IF DATA IS THERE=2E=3CBR=3E=26nbsp=3B=26nbsp=3B=26nbsp=3B=26=
nbsp=3B=26nbsp=3B=26nbsp=3B=26nbsp=3B JRST=26nbsp=3B=26nbsp=3B=26nbsp=3B=
LPTE=2E2=26nbsp=3B=26nbsp=3B=26nbsp=3B=26nbsp=3B=26nbsp=3B=26nbsp=3B=26=
nbsp=3B=26nbsp=3B=26nbsp=3B=26nbsp=3B=26nbsp=3B=26nbsp=3B=26nbsp=3B=26nb=
sp=3B=26nbsp=3B=26nbsp=3B=26nbsp=3B =3BGO GET A DATA BYTE=2E=3CBR=3E=26n=
bsp=3B=26nbsp=3B=26nbsp=3B=26nbsp=3B=26nbsp=3B=26nbsp=3B=26nbsp=3B PUSHJ=
=26nbsp=3B=26nbsp=3B P=2CINPBUF=26nbsp=3B=26nbsp=3B=26nbsp=3B=26nbsp=3B=26=
nbsp=3B=26nbsp=3B=26nbsp=3B=26nbsp=3B=26nbsp=3B=26nbsp=3B=26nbsp=3B=26nb=
sp=3B=26nbsp=3B=26nbsp=3B=26nbsp=3B =3BELSE=2C GET A BUFFER FULL=3CBR=3E=
=26nbsp=3B=26nbsp=3B=26nbsp=3B=26nbsp=3B=26nbsp=3B=26nbsp=3B=26nbsp=3B J=
UMPT=26nbsp=3B=26nbsp=3B LPTE=2E1=26nbsp=3B=26nbsp=3B=26nbsp=3B=26nbsp=3B=
=26nbsp=3B=26nbsp=3B=26nbsp=3B=26nbsp=3B=26nbsp=3B=26nbsp=3B=26nbsp=3B=26=
nbsp=3B=26nbsp=3B=26nbsp=3B=26nbsp=3B=26nbsp=3B=26nbsp=3B =3BIF OK=2C=2C=
GET NEXT FOUR BYTES=3CBR=3E=26nbsp=3B=26nbsp=3B=26nbsp=3B=26nbsp=3B=26nb=
sp=3B=26nbsp=3B=26nbsp=3B =24RETT=26nbsp=3B=26nbsp=3B=26nbsp=3B=26nbsp=3B=
=26nbsp=3B=26nbsp=3B=26nbsp=3B=26nbsp=3B=26nbsp=3B=26nbsp=3B=26nbsp=3B=26=
nbsp=3B=26nbsp=3B=26nbsp=3B=26nbsp=3B=26nbsp=3B=26nbsp=3B=26nbsp=3B=26nb=
sp=3B=26nbsp=3B=26nbsp=3B=26nbsp=3B=26nbsp=3B=26nbsp=3B=26nbsp=3B=26nbsp=
=3B =3BELSE RETURN=2E=3C/P=3E
=3CP=3ELPTE=2E2=3A ILDB=26nbsp=3B=26nbsp=3B=26nbsp=3B P1=2CJ=24DBPT(J)=26=
nbsp=3B=26nbsp=3B=26nbsp=3B=26nbsp=3B=26nbsp=3B=26nbsp=3B=26nbsp=3B=26nb=
sp=3B=26nbsp=3B=26nbsp=3B=26nbsp=3B =3BGET 4 BYTES TO PRINT=3CBR=3E=26nb=
sp=3B=26nbsp=3B=26nbsp=3B=26nbsp=3B=26nbsp=3B=26nbsp=3B=26nbsp=3B LDB=26=
nbsp=3B=26nbsp=3B=26nbsp=3B=26nbsp=3B C=2C=5BPOINT 8=2CP1=2C17=5D=26nbsp=
=3B=26nbsp=3B=26nbsp=3B=26nbsp=3B=26nbsp=3B=26nbsp=3B =3BGET THE FIRST B=
YTE=3CBR=3E=26nbsp=3B=26nbsp=3B=26nbsp=3B=26nbsp=3B=26nbsp=3B=26nbsp=3B=26=
nbsp=3B PUSHJ=26nbsp=3B=26nbsp=3B P=2CLPTE=2E3=26nbsp=3B=26nbsp=3B=26nbs=
p=3B=26nbsp=3B=26nbsp=3B=26nbsp=3B=26nbsp=3B=26nbsp=3B=26nbsp=3B=26nbsp=3B=
=26nbsp=3B=26nbsp=3B=26nbsp=3B=26nbsp=3B=26nbsp=3B =3BPRINT IT=3CBR=3E=26=
nbsp=3B=26nbsp=3B=26nbsp=3B=26nbsp=3B=26nbsp=3B=26nbsp=3B=26nbsp=3B LDB=26=
nbsp=3B=26nbsp=3B=26nbsp=3B=26nbsp=3B C=2C=5BPOINT 8=2CP1=2C9=5D=26nbsp=3B=
=26nbsp=3B=26nbsp=3B=26nbsp=3B=26nbsp=3B=26nbsp=3B=26nbsp=3B =3BGET SECO=
ND BYTE=3CBR=3E=26nbsp=3B=26nbsp=3B=26nbsp=3B=26nbsp=3B=26nbsp=3B=26nbsp=
=3B=26nbsp=3B PUSHJ=26nbsp=3B=26nbsp=3B P=2CLPTE=2E3=26nbsp=3B=26nbsp=3B=
=26nbsp=3B=26nbsp=3B=26nbsp=3B=26nbsp=3B=26nbsp=3B=26nbsp=3B=26nbsp=3B=26=
nbsp=3B=26nbsp=3B=26nbsp=3B=26nbsp=3B=26nbsp=3B=26nbsp=3B =3BPRINT IT=3C=
BR=3E=26nbsp=3B=26nbsp=3B=26nbsp=3B=26nbsp=3B=26nbsp=3B=26nbsp=3B=26nbsp=
=3B LDB=26nbsp=3B=26nbsp=3B=26nbsp=3B=26nbsp=3B C=2C=5BPOINT 8=2CP1=2C35=
=5D=26nbsp=3B=26nbsp=3B=26nbsp=3B=26nbsp=3B=26nbsp=3B=26nbsp=3B =3BGET T=
HIRD BYTE=3CBR=3E=26nbsp=3B=26nbsp=3B=26nbsp=3B=26nbsp=3B=26nbsp=3B=26nb=
sp=3B=26nbsp=3B PUSHJ=26nbsp=3B=26nbsp=3B P=2CLPTE=2E3=26nbsp=3B=26nbsp=3B=
=26nbsp=3B=26nbsp=3B=26nbsp=3B=26nbsp=3B=26nbsp=3B=26nbsp=3B=26nbsp=3B=26=
nbsp=3B=26nbsp=3B=26nbsp=3B=26nbsp=3B=26nbsp=3B=26nbsp=3B =3BPRINT IT=3C=
BR=3E=26nbsp=3B=26nbsp=3B=26nbsp=3B=26nbsp=3B=26nbsp=3B=26nbsp=3B=26nbsp=
=3B LDB=26nbsp=3B=26nbsp=3B=26nbsp=3B=26nbsp=3B C=2C=5BPOINT 8=2CP1=2C27=
=5D=26nbsp=3B=26nbsp=3B=26nbsp=3B=26nbsp=3B=26nbsp=3B=26nbsp=3B =3BGET F=
OURTH BYTE=3CBR=3E=26nbsp=3B=26nbsp=3B=26nbsp=3B=26nbsp=3B=26nbsp=3B=26n=
bsp=3B=26nbsp=3B PUSHJ=26nbsp=3B=26nbsp=3B P=2CLPTE=2E3=26nbsp=3B=26nbsp=
=3B=26nbsp=3B=26nbsp=3B=26nbsp=3B=26nbsp=3B=26nbsp=3B=26nbsp=3B=26nbsp=3B=
=26nbsp=3B=26nbsp=3B=26nbsp=3B=26nbsp=3B=26nbsp=3B=26nbsp=3B =3BPRINT IT=
=3CBR=3E=26nbsp=3B=26nbsp=3B=26nbsp=3B=26nbsp=3B=26nbsp=3B=26nbsp=3B=26n=
bsp=3B JRST=26nbsp=3B=26nbsp=3B=26nbsp=3B LPTE=2E1=26nbsp=3B=26nbsp=3B=26=
nbsp=3B=26nbsp=3B=26nbsp=3B=26nbsp=3B=26nbsp=3B=26nbsp=3B=26nbsp=3B=26nb=
sp=3B=26nbsp=3B=26nbsp=3B=26nbsp=3B=26nbsp=3B=26nbsp=3B=26nbsp=3B=26nbsp=
=3B =3BGET THE NEXT FOUR BYTES=3C/P=3E
=3CP=3EAnd remember=2C this isn=27t just amateurish dabbling folks=2C it=
=27s=3CBR=3ECOMMERCIAL quality programming=3B so don=27t this at home =3A=
-)=3C/P=3E
=3CP=3EActually it=27s not saving registers=2C but only doing a call for=
every=3CBR=3Echaracter =2E=2E=2E Bad example =2E=2E=2E=3C/P=3E
=3CP=3EOh well=2C I can have a good chuckle now=2C but Galaxy was nearly=
my full=3CBR=3Etime job for six years=2E=26nbsp=3B We had six 20=27s an=
d (a few=3F) Vaxen and=3CBR=3Eeverybody wanted to print everywhere and d=
o everything=2E=26nbsp=3B Needless to=3CBR=3Esay=2C new releases could b=
e challenging =2E=2E=2E=3CBR=3E=3C/P=3E

--Boundary_(ID_Xa0540o7om6G32OIVqmjCg)--
13-Aug-2006 14:56:46-PDT,2912;000000000000
Return-Path: <[email protected]>
Received: from pangtzu.panda.com ([206.124.149.117]) by lingling.panda.com with TCP/SMTP; Sun, 13 Aug 2006 14:55:19 -0700 (PDT)
X-Return-Path: <[email protected]>
X-Received: from pangtzu.panda.com ([206.124.149.117]) by lingling.panda.com with TCP/SMTP; Sun, 13 Aug 2006 14:54:19 -0700 (PDT)
X-Return-Path: <[email protected]>
X-Received: from sesame.cc.columbia.edu ([128.59.59.56]) by lingling.panda.com with TCP/SMTP; Sun, 13 Aug 2006 12:55:13 -0700 (PDT)
X-Received: from sesame.cc.columbia.edu (localhost [127.0.0.1])
by sesame.cc.columbia.edu (8.13.7/8.13.6) with ESMTP id k7DJsxWL012732;
Sun, 13 Aug 2006 15:54:59 -0400 (EDT)
X-Received: (from fdc@localhost)
by sesame.cc.columbia.edu (8.13.7/8.12.8/Submit) id k7DJsxCp012731;
Sun, 13 Aug 2006 15:54:59 -0400 (EDT)
Date: Sun, 13 Aug 2006 15:54:59 EDT
From: Frank da Cruz <[email protected]>
To: [email protected]
Cc: TOPS-20 List Moderator <[email protected]>
Subject: Re: OWGBPs in MOVSLJ instruction
In-Reply-To: <[email protected]>
Message-ID: <[email protected]>
X-ReSent-Date: Sun, 13 Aug 2006 14:54:12 -0700 (PDT)
X-ReSent-From: Mark Crispin <[email protected]>
X-ReSent-To: TOPS-20 Hackers and Yackers <[email protected]>
X-ReSent-Subject: Re: OWGBPs in MOVSLJ instruction
X-ReSent-Message-ID: <[email protected]>
ReSent-Date: Sun, 13 Aug 2006 14:55:10 -0700 (PDT)
ReSent-From: TOPS-20 List Moderator <[email protected]>
ReSent-To: TOPS-20 Distribution: ;
ReSent-Subject: Re: OWGBPs in MOVSLJ instruction
ReSent-Message-ID: <[email protected]>

> What do you think? I don't remember what we billed for CPU time for
> commercial users, but I know that it was by the CPU second and
> fractional portion thereof. Frank? Anybody?
>
We billed for (or regulated) everything we could get numbers for,
including CPU time. Paying users (funded researchers) were billed,
"free" users (like students) were limited. At first everything was
free for everybody but when the load average started sticking at 100
(perhaps we were second only to LOTS in that respect) and we couldn't
buy as many new DEC-20s as we wanted to, we had to do something! But
our tight little assembly language programs didn't cost anybody much
to run compared to MACSYMA, etc. Or even EMACS.

It's funny, I recall in the late 1970s, there were witch hunts against
"word processing" and other frivolous uses of the DEC-20s. You don't
need a computer to write a term paper, that's what typewriters are for.

John Von Neumann made a similar argument a few decades earlier about
assemblers... That's what graduate students are for!

http://www.columbia.edu/acis/history/index.html#ssec

(second blockquote in the Jan 1948 entry)

- Frank
13-Aug-2006 15:18:14-PDT,2189;000000000000
Return-Path: <[email protected]>
Received: from pangtzu.panda.com ([206.124.149.117]) by lingling.panda.com with TCP/SMTP; Sun, 13 Aug 2006 15:16:44 -0700 (PDT)
X-Return-Path: <[email protected]>
X-Received: from pangtzu.panda.com ([206.124.149.117]) by lingling.panda.com with TCP/SMTP; Sun, 13 Aug 2006 15:07:22 -0700 (PDT)
Date: Sun, 13 Aug 2006 15:07:17 -0700 (PDT)
From: Mark Crispin <[email protected]>
Sender: [email protected]
To: Frank da Cruz <[email protected]>
cc: TOPS-20 Hackers and Yackers <[email protected]>
Subject: Re: OWGBPs in MOVSLJ instruction
In-Reply-To: <[email protected]>
Message-ID: <[email protected]>
References: <[email protected]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
ReSent-Date: Sun, 13 Aug 2006 15:16:35 -0700 (PDT)
ReSent-From: TOPS-20 List Moderator <[email protected]>
ReSent-To: TOPS-20 Distribution: ;
ReSent-Subject: Re: OWGBPs in MOVSLJ instruction
ReSent-Message-ID: <[email protected]>

On Sun, 13 Aug 2006, Frank da Cruz wrote:
> It's funny, I recall in the late 1970s, there were witch hunts against
> "word processing" and other frivolous uses of the DEC-20s. You don't
> need a computer to write a term paper, that's what typewriters are for.

I remember being yelled at for using a typewriter, since everything was
supposed to be written out in longhand.

I remember being yelled at for writing what today would be considered a
very basic instant messaging program. Not only was it a "waste"; it was
"illegal" to use a computer for messaging and the phone company would send
the FBI after me...

What's particularly ironic today is that the uses that were roundly damned
in the 60s, 70s, and 80s as being frivolous wastes of computer time are
probably the primary usage of computers today. Gaming in particular has
probably instigated more advances in computer technology that even defense
spending.

-- Mark --

http://panda.com/tops-20
TOPS-20: a great improvement over its successors
16-Aug-2006 08:14:49-PDT,4585;000000000000
Return-Path: <[email protected]>
Received: from pangtzu.panda.com ([206.124.149.117]) by lingling.panda.com with TCP/SMTP; Wed, 16 Aug 2006 08:12:54 -0700 (PDT)
X-Return-Path: <[email protected]>
X-Received: from pop-tawny.atl.sa.earthlink.net ([207.69.195.67]) by lingling.panda.com with TCP/SMTP; Wed, 16 Aug 2006 02:47:23 -0700 (PDT)
X-Received: from cpe-24-221-177-162.ca.sprintbbd.net ([24.221.177.162] helo=[204.238.239.104])
by pop-tawny.atl.sa.earthlink.net with esmtp (Exim 3.36 #1)
id 1GDHzV-0005AE-00; Wed, 16 Aug 2006 05:47:13 -0400
In-Reply-To: <[email protected]>
References: <[email protected]> <[email protected]> <[email protected]>
Mime-Version: 1.0 (Apple Message framework v624)
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Message-Id: <[email protected]>
Content-Transfer-Encoding: quoted-printable
Cc: Fred Wright <[email protected]>,
[email protected]
From: Carl Baltrunas <[email protected]>
Subject: Re: Spoolers
Date: Wed, 16 Aug 2006 02:47:11 -0700
To: [email protected]
X-Mailer: Apple Mail (2.624)
ReSent-Date: Wed, 16 Aug 2006 08:12:43 -0700 (PDT)
ReSent-From: TOPS-20 List Moderator <[email protected]>
ReSent-To: TOPS-20 Distribution: ;
ReSent-Subject: Re: Spoolers
ReSent-Message-ID: <[email protected]>

I have an even better example, found in the SPOOL program
for the TYMCOM-X operating system while rewriting FORTRAN
printing controls. It WAS saving registers and I made up a little
award with the code to show it off.

The code went something like this:

LABEL: PUSH P,T1 ; Save registers
PUSH P,T2 ; 1-4
PUSH P,T3
PUSH P,T4
PUSHJ P,DOIT ; Go do whatever it was
JFCL ; Ignore any errors
POP P,T1 ; Restore registers
POP P,T2 ; 1-4
POP P,T3
POP P,T4
POPJ P, ; All done

This code was running for years in the form control logic
with no problems. Obviously, the registers didn't need to
be saved.

-Carl

On Aug 13, 2006, at 1:05 PM, [email protected] wrote:
> > In the particular case of register save/restore, if you're calling a
> > function that's doing that in a tight loop, then your code is badly
> > designed to begin with. :-)
>
> Heh ...=A0 The following code from my favorite spooler comes to mind:
>
> LPTE.1: SOSL=A0=A0=A0 J$DBCT(J)=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
;COUNT DOWN AND JUMP IF DATA=20
> IS THERE.
> =A0=A0=A0=A0=A0=A0=A0 JRST=A0=A0=A0 LPTE.2=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0 ;GO GET A DATA BYTE.
> =A0=A0=A0=A0=A0=A0=A0 PUSHJ=A0=A0 P,INPBUF=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0 ;ELSE, GET A BUFFER FULL
> =A0=A0=A0=A0=A0=A0=A0 JUMPT=A0=A0 LPTE.1=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0 ;IF OK,,GET NEXT FOUR BYTES
> =A0=A0=A0=A0=A0=A0=A0 $RETT=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 ;ELSE RETURN.
>
> LPTE.2: ILDB=A0=A0=A0 P1,J$DBPT(J)=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =
;GET 4 BYTES TO PRINT
> =A0=A0=A0=A0=A0=A0=A0 LDB=A0=A0=A0=A0 C,[POINT 8,P1,17]=A0=A0=A0=A0=A0=A0=
;GET THE FIRST BYTE
> =A0=A0=A0=A0=A0=A0=A0 PUSHJ=A0=A0 P,LPTE.3=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0 ;PRINT IT
> =A0=A0=A0=A0=A0=A0=A0 LDB=A0=A0=A0=A0 C,[POINT 8,P1,9]=A0=A0=A0=A0=A0=A0=
=A0 ;GET SECOND BYTE
> =A0=A0=A0=A0=A0=A0=A0 PUSHJ=A0=A0 P,LPTE.3=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0 ;PRINT IT
> =A0=A0=A0=A0=A0=A0=A0 LDB=A0=A0=A0=A0 C,[POINT 8,P1,35]=A0=A0=A0=A0=A0=A0=
;GET THIRD BYTE
> =A0=A0=A0=A0=A0=A0=A0 PUSHJ=A0=A0 P,LPTE.3=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0 ;PRINT IT
> =A0=A0=A0=A0=A0=A0=A0 LDB=A0=A0=A0=A0 C,[POINT 8,P1,27]=A0=A0=A0=A0=A0=A0=
;GET FOURTH BYTE
> =A0=A0=A0=A0=A0=A0=A0 PUSHJ=A0=A0 P,LPTE.3=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0 ;PRINT IT
> =A0=A0=A0=A0=A0=A0=A0 JRST=A0=A0=A0 LPTE.1=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0 ;GET THE NEXT FOUR BYTES
>
> And remember, this isn't just amateurish dabbling folks, it's
> COMMERCIAL quality programming; so don't this at home :-)
>
> Actually it's not saving registers, but only doing a call for every
> character ... Bad example ...
>
> Oh well, I can have a good chuckle now, but Galaxy was nearly my full
> time job for six years.=A0 We had six 20's and (a few?) Vaxen and
> everybody wanted to print everywhere and do everything.=A0 Needless to
> say, new releases could be challenging ...

19-Aug-2006 09:12:05-PDT,2488;000000000000
Return-Path: <[email protected]>
Received: from pangtzu.panda.com ([206.124.149.117]) by lingling.panda.com with TCP/SMTP; Sat, 19 Aug 2006 09:08:04 -0700 (PDT)
X-Return-Path: <[email protected]>
X-Received: from mta7.srv.hcvlny.cv.net ([167.206.4.202]) by lingling.panda.com with TCP/SMTP; Sat, 19 Aug 2006 07:36:34 -0700 (PDT)
X-Received: from optonline.net (hamstr3.srv.hcvlny.cv.net [167.206.5.10])
by mta7.srv.hcvlny.cv.net
(Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006))
with ESMTP id <[email protected]> for
[email protected]; Sat, 19 Aug 2006 10:36:28 -0400 (EDT)
X-Received: from [10.240.3.198] (Forwarded-For: [10.240.3.198])
by mstr3.srv.hcvlny.cv.net (mshttpd); Sat, 19 Aug 2006 14:36:24 +0000 (GMT)
Date: Sat, 19 Aug 2006 14:36:24 +0000 (GMT)
From: [email protected]
Subject: Re: MOVSLJ behavior in non-zero sections on a Toad
In-reply-to: <[email protected]>
To: Ralph Gorin <[email protected]>
Cc: [email protected]
Message-id: <[email protected]>
MIME-version: 1.0
X-Mailer: Sun Java(tm) System Messenger Express 6.2-6.01 (built Apr 3 2006)
Content-type: text/plain; charset=us-ascii
Content-language: en
Content-transfer-encoding: 7BIT
Content-disposition: inline
X-Accept-Language: en
Priority: normal
References: <[email protected]>
<[email protected]>
ReSent-Date: Sat, 19 Aug 2006 09:07:54 -0700 (PDT)
ReSent-From: TOPS-20 List Moderator <[email protected]>
ReSent-To: TOPS-20 Distribution: ;
ReSent-Subject: Re: MOVSLJ behavior in non-zero sections on a Toad
ReSent-Message-ID: <[email protected]>

> I am accumulating the failures so that we have diagnostics
> to display these problems if we ever have the opportunity
> to revisit the firmare.

Hi Ralph,

Do you think that it might be appropriate to post a beware file with cautions about certain instructions on a Toad? I seem to remember an *** OLD *** (1973) copy of SYSREF that said something like, "don't use foo when dismissing an interrupt, it does not work" (anybody else remember this?)

I have conditional run time code in the FTP server that knows what not to do on the Toad. If there are other things that I might bump into, it would probably be easier for me to know about them a priori rather than trying to chase them down.

--T

19-Aug-2006 09:15:50-PDT,5610;000000000000
Return-Path: <[email protected]>
Received: from pangtzu.panda.com ([206.124.149.117]) by lingling.panda.com with TCP/SMTP; Sat, 19 Aug 2006 09:08:20 -0700 (PDT)
X-Return-Path: <[email protected]>
X-Received: from mta10.srv.hcvlny.cv.net ([167.206.4.205]) by lingling.panda.com with TCP/SMTP; Sat, 19 Aug 2006 07:45:37 -0700 (PDT)
X-Received: from optonline.net (hamstr3.srv.hcvlny.cv.net [167.206.5.10])
by mta10.srv.hcvlny.cv.net
(Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006))
with ESMTP id <[email protected]>; Sat,
19 Aug 2006 10:43:54 -0400 (EDT)
X-Received: from [10.240.3.198] (Forwarded-For: [10.240.3.198])
by mstr3.srv.hcvlny.cv.net (mshttpd); Sat, 19 Aug 2006 14:44:46 +0000 (GMT)
Date: Sat, 19 Aug 2006 14:44:46 +0000 (GMT)
From: [email protected]
Subject: Re: Tops-20 Extended mode FTP Server Update
In-reply-to: <[email protected]>
To: Mark Crispin <[email protected]>
Cc: [email protected]
Message-id: <[email protected]>
MIME-version: 1.0
X-Mailer: Sun Java(tm) System Messenger Express 6.2-6.01 (built Apr 3 2006)
Content-type: text/plain; charset=us-ascii
Content-language: en
Content-transfer-encoding: 7BIT
Content-disposition: inline
X-Accept-Language: en
Priority: normal
References: <[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
ReSent-Date: Sat, 19 Aug 2006 09:08:10 -0700 (PDT)
ReSent-From: TOPS-20 List Moderator <[email protected]>
ReSent-To: TOPS-20 Distribution: ;
ReSent-Subject: Re: Tops-20 Extended mode FTP Server Update
ReSent-Message-ID: <[email protected]>

> > Also, the performance of the classic instruction set is even
> > poorer for doing the inverse operation (8 -> 36). Per 288 bit
> > round, I use 40 instructions per loop or about 7.2 bits per
> > instruction. For large files, this can burn up a lot of CPU time
> > with all the shifting, or'ing and instruction decode times. I
> > think that having an instruction to do this would be a real win.
>
> You shouldn't need to OR. I suspect, but don't know for a fact,
> that shifting is faster.

No IOR'ing?? Oh dear ... I'm doing an IOR and LSHC and percolating
the results up through the register file. I have two percolations per
288 bit loop. For the few tests that I've done, this has worked.
I'll have some more information on performance and accuracy once I've
finished linking this into the main buffer management logic. For now,
if you've got something else/better, let me know and I'll be delighted
to try it out.

DO. ; Now finally grunt through some data
SETZB T3,Q1 ; Ready up some scratch ACs so we can do
SETZB Q3,P2 ; the first four output words
DMOVE T1,^D0(P5) ; Load Internet bytes 0,1,2,3,4,5 and 7
LSHC T2,-^D32 ; Isolate and position bits 32 through 35
IOR T1,T2 ; Or with bits 0 through 31
MOVEM T1,^D0(P6) ; Store first 36 bit word
MOVE T4,^D2(P5) ; Load Internet bytes 8,9,10 and 11
LSHC T4,-^D28 ; Isolate and position bits 28 through 35
IOR T3,T4 ; Or with bits 0 through 27
MOVEM T3,^D1(P6) ; Store second 36 bit word
MOVE Q2,^D3(P5) ; Load Internet bytes 12,13,14 and 15
LSHC Q2,-^D24 ; Isolate and position bits 24 through 35
IOR Q1,Q2 ; Or with bits 0 through 23
MOVEM Q1,^D2(P6) ; Store third 36 bit word
MOVE P1,^D4(P5) ; Load Internet bytes 16,17,18 and 19
LSHC P1,-^D20 ; Isolate and position bits 20 through 35
IOR Q3,P1 ; Or with bits 0 through 19
MOVEM Q3,^D3(P6) ; Store fourth 36 bit word
MOVE T1,P2 ; Restart construction from the bottom of the
SETZB T3,Q1 ; register file and re-initialize the scratch
SETZ Q3, ; accumulators for 4 more 36 bit output words
MOVE T2,^D5(P5) ; Load Internet bytes 20,21,22 and 23
LSHC T2,-^D16 ; Isolate and position bits 16 through 35
IOR T1,T2 ; Or with bits 0 through 15
MOVEM T1,^D4(P6) ; Store fifth 36 bit word
MOVE T4,^D6(P5) ; Load Internet bytes 24,25,26 and 27
LSHC T4,-^D12 ; Isolate and position bits 12 through 35
IOR T3,T4 ; Or with bits 0 through 11
MOVEM T3,^D5(P6) ; Store sixth 36 bit word
MOVE Q2,^D7(P5) ; Load Internet bytes 28,29,30 and 31
LSHC Q2,-^D8 ; Isolate and position bits 8 through 35
IOR Q1,Q2 ; Or with bits 0 through 7
MOVEM Q1,^D6(P6) ; Store seventh 36 bit word
MOVE P1,^D8(P5) ; Load Internet bytes 32,33,34 and 35
LSH P1,-^D4 ; Isolate and position bits 4 through 35
IOR Q3,P1 ; Or with bits 0 through 3
MOVEM Q3,^D7(P6) ; Store eigth 36 bit word (final in round)
XMOVEI P5,B.W.RN(P5) ; Point to next input round
XMOVEI P6,W.P.RN(P6) ; Point to next output round
SOJG CX,TOP. ; Process another round
ENDDO. ; End 288 round processing

19-Aug-2006 09:19:26-PDT,5870;000000000000
Return-Path: <[email protected]>
Received: from pangtzu.panda.com ([206.124.149.117]) by lingling.panda.com with TCP/SMTP; Sat, 19 Aug 2006 09:09:36 -0700 (PDT)
X-Return-Path: <[email protected]>
X-Received: from mta8.srv.hcvlny.cv.net ([167.206.4.203]) by lingling.panda.com with TCP/SMTP; Sat, 19 Aug 2006 08:34:55 -0700 (PDT)
X-Received: from optonline.net (hamstr3.srv.hcvlny.cv.net [167.206.5.10])
by mta8.srv.hcvlny.cv.net
(Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006))
with ESMTP id <[email protected]> for
[email protected]; Sat, 19 Aug 2006 11:33:39 -0400 (EDT)
X-Received: from [10.240.3.198] (Forwarded-For: [10.240.3.198])
by mstr3.srv.hcvlny.cv.net (mshttpd); Sat, 19 Aug 2006 15:34:48 +0000 (GMT)
Date: Sat, 19 Aug 2006 15:34:48 +0000 (GMT)
From: [email protected]
Subject: Re: Tops-20 Extended mode FTP Server Update
In-reply-to: <[email protected]>
To: Mark Crispin <[email protected]>
Cc: Fred Wright <[email protected]>,
TOPS-20 Hackers and Yackers <[email protected]>
Message-id: <[email protected]>
MIME-version: 1.0
X-Mailer: Sun Java(tm) System Messenger Express 6.2-6.01 (built Apr 3 2006)
Content-type: text/plain; charset=us-ascii
Content-language: en
Content-transfer-encoding: 7BIT
Content-disposition: inline
X-Accept-Language: en
Priority: normal
References: <[email protected]>
<[email protected]>
ReSent-Date: Sat, 19 Aug 2006 09:09:26 -0700 (PDT)
ReSent-From: TOPS-20 List Moderator <[email protected]>
ReSent-To: TOPS-20 Distribution: ;
ReSent-Subject: Re: Tops-20 Extended mode FTP Server Update
ReSent-Message-ID: <[email protected]>

IFDEF MRC,<

EXTEND ac,[XBLTBW]
;; similar to XBLT
;; AC/ number of 32-bit words.
;; AC+1/ source block (32-bit words) address.
;; AC+2/ destination block (36-bit words) address.

EXTEND ac,[XBLTWB]
;; similar to XBLT
;; AC/ number of 36-bit words.
;; AC+1/ source block (36-bit words) address.
;; AC+2/ destination block (32-bit words) address.

Both instructions will null-pad as needed if the word count is not a
multiple of 9 32-bit words (XBLTBW) or 8 36-bit words (XBLTWB).

I thought about also defining BLTBW and BLTWB instructions. The
problem is that, to correspond with BLT, BLTBU, BLTUB, E would hold
the destination end address. But, unlike any BLT, you can't calculate
that address by adding the count to the initial destination address
minus one; you have to do the 9/8 or 8/9 factoring as well.

The upshot is that I don't think that BLTBW and BLTWB would be are
particularly useful. I'm open to having my mind changed with
persuasive evidence.

>

I've had some time to reflect on this and I believe that, assuming we
could speed up the internal microcode shifting enough, this could
yield a significant performance improvement, if the measurements that
I posted earlier about MOVSLJ and friends are any indication. If you
or anybody else wants to try this, I'll be happy to test it.

With respect to BLTUB and BLTBU, from what I understand from perusing
DEC124.DOC, these are supposed to translate between PDP-10 byte-string
format and Unibus (MACY11) format, where the bytes coming from the
remote machine are byte swapped whereas XBLTBW and XBLTWB and friends
assume that the byte stream is NOT swapped.

I don't know if any user program would have the need to byte swap a 32
bit stream, other than if it were coming via a remote 32 bit host that
insisted on sending it that way (my current experience shows that this
is absolutely NOT beyond the realm of possibility). In addition, as
DEC124 points out, BLTUB and BLTBU would appear to provide a
significant speed up in the ANF/DECnet drivers as well as for LAT.

I would like to start using LAT for performance reasons as I seem
remember that, when using it, it was faster than using a TELNET
connection. Also, you can still get LAT boxs (perhaps on eBay) and I
would like to use one to connect a few ancient terminals that I have
kicking around the house (ADDS Consul 520).

I don't know that I'd use four opcodes for all this, however.

I wonder if it might be more appropriate to use some spare bits in the
count word that will always be zero the way MOVST does. Since the
maximum number of 36 words that the machine can theoretically handle
is 30 bits, that would seem to indicate that, in this case, 6 bits are
available. Doing a 32 bit word count would need more bits, however.
In order to get 30 bits of 36 bit word from 32 words, you would need
31 bits to properly enumerate everything, so you'd have 5 spare bits.

I guess that means we'd have five bits to play with. That suggests
the following:

EXTEND ac,[XBLTBB] (Bit Bang)

;; similar to MOVST
;; AC/ flags + number of words.
;; AC+1/ 32-bit word block 30 bit address.
;; AC+2/ 36-bit word block 30 bit address.

;;Flags:

1B0 - If zero, convert from 32 bit words to 36, AC+1 is source and
AC+2 is destination. If this is the most common case, it would
allow you easily load AC with a MOVEI

If one, convert from 36 bit words to 32, AC+1 is the
destination and AC+2 is source.

1B1 - Byte swap the 32 bit words either coming or going. Change
initial bit offset as approprite.

As above, both instructions will null-pad as needed if the word count
is not an even multiple of 288 bits.

I don't have an informed opinion as to whether this particular
instruction definition would yield any difference in performance.
However, at least from what I've been coding, it might be easier to
remember and use.

Let me know what you think.

19-Aug-2006 10:37:15-PDT,1911;000000000000
Return-Path: <[email protected]>
Received: from pangtzu.panda.com ([206.124.149.117]) by lingling.panda.com with TCP/SMTP; Sat, 19 Aug 2006 10:33:45 -0700 (PDT)
X-Return-Path: <[email protected]>
X-Received: from nic.cafax.se ([192.71.228.17]) by lingling.panda.com with TCP/SMTP; Sat, 19 Aug 2006 10:21:57 -0700 (PDT)
X-Received: from nic.cafax.se (localhost [127.0.0.1])
by nic.cafax.se (8.13.7/8.12.11) with ESMTP id k7JHLnpM023732
for <[email protected]>; Sat, 19 Aug 2006 19:21:49 +0200 (MEST)
X-Received: (from bygg@localhost)
by nic.cafax.se (8.13.7/8.12.11/Submit) id k7JHLnmX010347
for [email protected]; Sat, 19 Aug 2006 19:21:49 +0200 (MEST)
Date: Sat, 19 Aug 2006 19:21:49 WET DST
From: Johnny Eriksson <[email protected]>
To: [email protected]
Subject: Re: MOVSLJ behavior in non-zero sections on a Toad
In-Reply-To: Your message of Sat, 19 Aug 2006 14:36:24 +0000 (GMT)
Message-ID: <[email protected]>
ReSent-Date: Sat, 19 Aug 2006 10:33:38 -0700 (PDT)
ReSent-From: TOPS-20 List Moderator <[email protected]>
ReSent-To: TOPS-20 Distribution: ;
ReSent-Subject: Re: MOVSLJ behavior in non-zero sections on a Toad
ReSent-Message-ID: <[email protected]>

[email protected] wrote:

> Do you think that it might be appropriate to post a beware file with
> cautions about certain instructions on a Toad? I seem to remember an
> *** OLD *** (1973) copy of SYSREF that said something like, "don't
> use foo when dismissing an interrupt, it does not work" (anybody else
> remember this?)

In my copy of the "phone book" there is, regarding interrupts, this text:

Caution

Neither an LUUO nor a BLT will function in a
reasonable manner as an interrupt instruction.
Therefore do not use them.

Is this what you were thinking of?

--Johnny
19-Aug-2006 10:40:49-PDT,2411;000000000000
Return-Path: <[email protected]>
Received: from pangtzu.panda.com ([206.124.149.117]) by lingling.panda.com with TCP/SMTP; Sat, 19 Aug 2006 10:36:32 -0700 (PDT)
X-Return-Path: <[email protected]>
X-Received: from nic.cafax.se ([192.71.228.17]) by lingling.panda.com with TCP/SMTP; Sat, 19 Aug 2006 10:31:02 -0700 (PDT)
X-Received: from nic.cafax.se (localhost [127.0.0.1])
by nic.cafax.se (8.13.7/8.12.11) with ESMTP id k7JHUtan019398
for <[email protected]>; Sat, 19 Aug 2006 19:30:55 +0200 (MEST)
X-Received: (from bygg@localhost)
by nic.cafax.se (8.13.7/8.12.11/Submit) id k7JHUtjY016084
for TOPS-20 Hackers and Yackers <[email protected]>; Sat, 19 Aug 2006 19:30:55 +0200 (MEST)
Date: Sat, 19 Aug 2006 19:30:55 WET DST
From: Johnny Eriksson <[email protected]>
To: TOPS-20 Hackers and Yackers <[email protected]>
Subject: Re: Tops-20 Extended mode FTP Server Update
In-Reply-To: Your message of Sat, 19 Aug 2006 15:34:48 +0000 (GMT)
Message-ID: <[email protected]>
ReSent-Date: Sat, 19 Aug 2006 10:36:24 -0700 (PDT)
ReSent-From: TOPS-20 List Moderator <[email protected]>
ReSent-To: TOPS-20 Distribution: ;
ReSent-Subject: Re: Tops-20 Extended mode FTP Server Update
ReSent-Message-ID: <[email protected]>

[email protected] wrote:

> With respect to BLTUB and BLTBU, from what I understand from perusing
> DEC124.DOC, these are supposed to translate between PDP-10 byte-string
> format and Unibus (MACY11) format, where the bytes coming from the
> remote machine are byte swapped whereas XBLTBW and XBLTWB and friends
> assume that the byte stream is NOT swapped.

BLTUB/BLTBU convert from/to the format resulting from unibus DMA on
a KS10. The unibus data format in a 36-bit word is:

0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|x|x|b|b|b|b|b|b|b|b|a|a|a|a|a|a|a|a|x|x|d|d|d|d|d|d|d|d|c|c|c|c|c|c|c|c|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

and you want aaaaaaaabbbbbbbbccccccccddddddddxxxx.

By the way, the KS10 microcode can be built to do:

* KI10 paging.
* KL10 paging, single section.
* BLTUB/BLTBU.

Space constraints dictate: select two.

--Johnny
19-Aug-2006 11:36:22-PDT,6011;000000000000
Return-Path: <[email protected]>
Received: from pangtzu.panda.com ([206.124.149.117]) by lingling.panda.com with TCP/SMTP; Sat, 19 Aug 2006 11:32:31 -0700 (PDT)
X-Return-Path: <[email protected]>
X-Received: from mta4.srv.hcvlny.cv.net ([167.206.4.199]) by lingling.panda.com with TCP/SMTP; Sat, 19 Aug 2006 10:39:15 -0700 (PDT)
X-Received: from optonline.net (hamstr3.srv.hcvlny.cv.net [167.206.5.10])
by mta4.srv.hcvlny.cv.net
(Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006))
with ESMTP id <[email protected]> for
[email protected]; Sat, 19 Aug 2006 13:38:26 -0400 (EDT)
X-Received: from [10.240.3.198] (Forwarded-For: [10.240.3.198])
by mstr3.srv.hcvlny.cv.net (mshttpd); Sat, 19 Aug 2006 17:38:19 +0000 (GMT)
Date: Sat, 19 Aug 2006 17:38:19 +0000 (GMT)
From: [email protected]
Subject: ASCII wire efficient and proposed TYPE L 7 RFC
In-reply-to: <[email protected]>
To: [email protected]
Message-id: <[email protected]>
MIME-version: 1.0
X-Mailer: Sun Java(tm) System Messenger Express 6.2-6.01 (built Apr 3 2006)
Content-type: text/plain; charset=us-ascii
Content-language: en
Content-transfer-encoding: 7BIT
Content-disposition: inline
X-Accept-Language: en
Priority: normal
References: <[email protected]>
<[email protected]>
<[email protected]>
ReSent-Date: Sat, 19 Aug 2006 11:32:23 -0700 (PDT)
ReSent-From: TOPS-20 List Moderator <[email protected]>
ReSent-To: TOPS-20 Distribution: ;
ReSent-Subject: ASCII wire efficient and proposed TYPE L 7 RFC
ReSent-Message-ID: <[email protected]>

L7 RFC

I've been pondering about doing something to the FTP client/server
data stream in order to increase wire transmission efficiency. The
rational is as follows.

I've researched TYPE A (ASCII mode) and I've come to the opinion that
this is really wasting a decent piece of bandwidth. When in this
mode, RFC959 specifies that a text file is to be sent as NVT-ASCII,
which is an 8 bit wire format. However, the storage format for
NVT-ASCII can really be fit into a 7 bit code as per RFC854 which
specifically states that,

"The code set is seven-bit US ASCII in an eight-bit field, except
as modified herein."

An analysis of 2,647,085 US ASCII (7 bit) byte file indicates the
following (this is the size of the current the current EFTPSR listing
with a CREF). The total number of bits that need to be moved on the
wire is 18,529,595. However, using TYPE A (ASCII), the total number
of bits is now 21,176,680. That is a 14% increase.

Why waste the bandwidth between 20's and other enlightened FTP
clients? By using the winning PDP-10 TYPE I (IMAGE or TYPE L 36)
format, the amount of bits put over the wire is now only 19,059,012,
or a 3% increase. In summary, the following table is useful:

36 Bit Words 529,417
7 Bit Bytes 2,647,085
Total US ASCII Bits 18,529,595
Type A wire bits 21,176,680
Percent increase 14%
Type L 36 wire bits 19,059,012
Percent increase 3%

This is why it is ALWAYS faster to use TYPE L 36 (or TYPE I) betwen
PDP10's for ALL transfers. In fact, if the Tops-20 FTP client detects
that it is talking to another PDP-10, it always selects TYPE I (and
FSTRU P [paged file structures], if possible). If a 20 ever beat out
a Unix, VMS or Windows box on a slow link, this is may be a reason
why. However, what about bumming that extra 529,414 bits? Why waste
66,177 bytes?

Using TYPE L 7 would get you no increase in wire time whatsoever.
However, few FTP clients or servers correctly implement L 7 or do it
at all. Although I have not checked, my experience with "TYPE L 1"
would lead me to believe that FTPSER (TCPSIM) doesn't do it right,
either. I haven't looked at the Tops-20 FTP client, yet.

I would simply augment the feature list (as required by RFC2389) to
return a new keyword, "L7" in response to a FEAT query. This would
assure the remote client that TYPE L 7 works instead of attempting to
use it and then trying to figure out the results.

In these days of ever increasing broadband speeds, where would this
realistically be useful, if anywhere? A couple of items come to mind:

1) Every so often, I get dragged to the beach during the summer. I
have double batteries on my laptop and go about 4.5 hours until I
run out of power. I plug my laptop into my cellphone (which is
free on the weekends), but I only get about a pitiful 9.6/15
kilobaud.

2) Transmissions to remote satellites and other distant objects in
space such as the space station?

3) Long wave communications with submarines (I don't know if they are
actually still doing this)

4) Palm or other hand held devices. My brother frequently logs into
the 20 via is Palm pilot. The use of COMND% makes it trivial to
use with the limited input methods (double tap can be bound to
escape)

5) Actual slow speed dial up. Broadband still isn't everywhere and
may never be all over. For 14.400 Kbs, doing that 21,176,680 8
bit wire transfer will take a minium of about 37 minutes. Using
an L 7 stream, that's going to go down by five minutes.

If you're paying by per-minute charge (such as a cellphone in
analog mode), you're going to save on the order of 3 bucks (if
you're getting charged the typical rate of 60 cents a minute).
Why spend the money?

Of course, if I had a hardware instruction (I.E., general purpose bit
banging) to do the packing, then ... :-)

PS: Noise, Noise, Noise,
Hardware SOUT%
Hardware SOUT%
Packin' bits,
Doin' BLTs
Hackin' Bytes
Holy Cripes!

19-Aug-2006 11:40:03-PDT,4782;000000000000
Return-Path: <[email protected]>
Received: from pangtzu.panda.com ([206.124.149.117]) by lingling.panda.com with TCP/SMTP; Sat, 19 Aug 2006 11:32:51 -0700 (PDT)
X-Return-Path: <[email protected]>
X-Received: from pangtzu.panda.com ([206.124.149.117]) by lingling.panda.com with TCP/SMTP; Sat, 19 Aug 2006 11:29:36 -0700 (PDT)
Date: Sat, 19 Aug 2006 11:29:31 -0700 (PDT)
From: Mark Crispin <[email protected]>
Sender: [email protected]
To: Johnny Eriksson <[email protected]>
cc: [email protected]
Subject: Re: MOVSLJ behavior in non-zero sections on a Toad
In-Reply-To: <[email protected]>
Message-ID: <[email protected]>
References: <[email protected]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
ReSent-Date: Sat, 19 Aug 2006 11:32:44 -0700 (PDT)
ReSent-From: TOPS-20 List Moderator <[email protected]>
ReSent-To: TOPS-20 Distribution: ;
ReSent-Subject: Re: MOVSLJ behavior in non-zero sections on a Toad
ReSent-Message-ID: <[email protected]>

On Sat, 19 Aug 2006, Johnny Eriksson wrote:
> Neither an LUUO nor a BLT will function in a
> reasonable manner as an interrupt instruction.
> Therefore do not use them.

I remember that warning. If you think about it, it makes sense. I
daresay that this applies to any non-atomic instruction; so ILDB and IDPB
are also out, as is EXTEND...

The most common interrupt instruction was JSR, which would dispatch to a
handler that would determine what interrupted, typically with a sequence
of CONSZ/JRST pairs, hence the term "CONSZ chain". KA10s with BB&N pagers
used JSYS, which (when E was greater than 1000) was a flavor of JSR that
took the old PC save location from one half of the location pointed by E,
and the new PC from the other half; that way the handler could be in
write-protected memory whereas a JSR handler could not be.

Today, we would use XPCW, but these days most devices don't go through the
interrupt instruction mechanism.

The reason why there were pairs is that you could use BLKI and BLKO. The
first instruction would be the BLKI/BLKO, and the second would be the JSR
when the BLKI/BLKO block was finished. Although implemented, both BLKI
and BLKO languished in obscurity on the KL; and of course the KS and XKL
don't use any of the traditional I/O instructions.

I actually did interrupt instruction programming with BLKI and BLKO, on
the WAITS IMP interface. The IMP was basically presented a serial line,
and the IMP interface would assemble it into words. The various PDP-10
IMP interfaces had both a 32-bit and a 36-bit mode, so it either read
32-bit or 36-bit words.

In NCP protocol, you would read two 36-bit words. The IMP header was
32-bits, and the NCP header was 40 bits (obviously, PDP-10 and Multics
guys had a strong influence on this, but this must have been terrible for
16-bit and 32-bit machines!). If the NCP message contained data, you
could determine whether it was 8-bit or 36-bit data from the NCP header,
and either leave it in 36-bit mode or switch to 32-bit mode. Either way,
you also knew from the NCP header how many 36-bit or 32-bit words to read.

So, you did two DATAI, possible CONO to switch modes, then successive BLKI
to read the rest of the packet. Output was the same. The BLKI could be
set as an interrupt instruction.

Going to NCP with long leaders, I recognized that you could still do the
same thing: read two 32-bit words, then switch to 36-bit mode and read two
36-bit words. Two DATAI, CONO, two more DATAI, possible CONO again, then
successive BLKI.

Dave Moon did the same thing on ITS, but somehow this technique couldn't
be done on the AN10/AN20 used in Tenex and TOPS-20. IIRC, Tenex and
TOPS-20 systems took quite a performance hit with long leaders.

What I do remember was that I rather embarrased BB&N by publicly annoucing
(and demonstrating) a PDP-10 long leader NCP about a week after I started
the project, whereas BB&N had been hemming and hawing to ARPA about it for
a couple of years. I was quite a young snit back then (some would say
that I still am, although I'm no longer young by anyone's reckoning...).

The byte-oriented people got their revenge with TCP, which had a thorough
32-bit orientation. I don't think that any of the PDP-10 implementations
were able to use the 36-bit mode of the IMP interface to spare doing the
32/36 conversions in software. I also don't think that any of the
Ethernet interfaces had a 36-bit mode.

-- Mark --

http://panda.com/tops-20
TOPS-20: a great improvement over its successors
19-Aug-2006 11:58:47-PDT,3585;000000000000
Return-Path: <[email protected]>
Received: from pangtzu.panda.com ([206.124.149.117]) by lingling.panda.com with TCP/SMTP; Sat, 19 Aug 2006 11:55:00 -0700 (PDT)
X-Return-Path: <[email protected]>
X-Received: from pangtzu.panda.com ([206.124.149.117]) by lingling.panda.com with TCP/SMTP; Sat, 19 Aug 2006 11:54:32 -0700 (PDT)
Date: Sat, 19 Aug 2006 11:54:28 -0700 (PDT)
From: Mark Crispin <[email protected]>
Sender: [email protected]
To: [email protected]
cc: [email protected]
Subject: Re: ASCII wire efficient and proposed TYPE L 7 RFC
In-Reply-To: <[email protected]>
Message-ID: <[email protected]>
References: <[email protected]>
<[email protected]> <[email protected]>
<[email protected]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
ReSent-Date: Sat, 19 Aug 2006 11:54:52 -0700 (PDT)
ReSent-From: TOPS-20 List Moderator <[email protected]>
ReSent-To: TOPS-20 Distribution: ;
ReSent-Subject: Re: ASCII wire efficient and proposed TYPE L 7 RFC
ReSent-Message-ID: <[email protected]>

On Sat, 19 Aug 2006, [email protected] wrote:
> I've researched TYPE A (ASCII mode) and I've come to the opinion that
> this is really wasting a decent piece of bandwidth.

IMHO, the most important use for TYPE A is to interchange text files
between PDP-10 and UNIX systems. This is because TYPE A turns on newline
conversion on the UNIX system.

A secondary use is to interchange text files between PDP-10 and Windows
systems; but this is only because TOPS-20 does not support 8-bit bytesize
text files well. If we supported 8-bit bytesize text files better, there
would be no need for this.

The problem is that almost all TOPS-20 that deals with text files ignores
the file bytesize. Instead, it just opens the file in 7-bit mode. This
is compounded by the fact that the operating system *also* ignores the
file bytesize on open; it uses the bytesize supplied by the user and
reads/writes successive bytes of that size left-adjusted in 36-bit words.

Ideally, user software would use the file bytesize for the open mode and
the I/O pointer; and the operating system would recognize mismatches and
do the adjustment (e.g., the 7 least-significant bits in each 8-bit byte).
But it doesn't and it doesn't.

This is all understandable, given the heritage from TOPS-10. In TOPS-10,
all files have a 36-bit bytesize. So TOPS-10 software running on TOPS-20
always reads/writes 36-bit bytes and for text just does the familiar
packing of 5 7-bit bytes left-adjusted in the word.

I recognized all this nearly 30 years ago, and looked into what would be
necessary to fix it. I found the task to be impossibly daunting, even for
the "obvious" "simple" cases such as opening an 8-bit file in 7-bit mode
where clearly nothing could possibly depend upon the current behavior.

Less ambitious would be EXEC hacks, such as fixing the TYPE command to
recognize file byte sizes, so you could do TYPE FOO.TXT for an 8-bit file
instead of COPY FOO.TXT TTY:, with a subcommand of BYTE 8. But it hardly
seemed worth it unless applications were also fixed.

I think about this from time to time, since I want to support UTF-9 text
files in TOPS-20. But that's an even more daunting task.

-- Mark --

http://panda.com/tops-20
TOPS-20: a great improvement over its successors
19-Aug-2006 16:13:37-PDT,3475;000000000000
Return-Path: <[email protected]>
Received: from pangtzu.panda.com ([206.124.149.117]) by lingling.panda.com with TCP/SMTP; Sat, 19 Aug 2006 16:09:46 -0700 (PDT)
X-Return-Path: <[email protected]>
X-Received: from pangtzu.panda.com ([206.124.149.117]) by lingling.panda.com with TCP/SMTP; Sat, 19 Aug 2006 16:08:46 -0700 (PDT)
X-Return-Path: <[email protected]>
X-Received: from sesame.cc.columbia.edu ([128.59.59.56]) by lingling.panda.com with TCP/SMTP; Sat, 19 Aug 2006 12:37:40 -0700 (PDT)
X-Received: from sesame.cc.columbia.edu (localhost [127.0.0.1])
by sesame.cc.columbia.edu (8.13.7/8.13.6) with ESMTP id k7JJbYU0017710;
Sat, 19 Aug 2006 15:37:34 -0400 (EDT)
X-Received: (from fdc@localhost)
by sesame.cc.columbia.edu (8.13.7/8.12.8/Submit) id k7JJbYiG017709;
Sat, 19 Aug 2006 15:37:34 -0400 (EDT)
Date: Sat, 19 Aug 2006 15:37:34 EDT
From: Frank da Cruz <[email protected]>
To: [email protected]
Cc: TOPS-20 List Moderator <[email protected]>
Subject: Re: ASCII wire efficient and proposed TYPE L 7 RFC
In-Reply-To: <[email protected]>
Message-ID: <[email protected]>
X-ReSent-Date: Sat, 19 Aug 2006 16:08:37 -0700 (PDT)
X-ReSent-From: Mark Crispin <[email protected]>
X-ReSent-To: TOPS-20 Hackers and Yackers <[email protected]>
X-ReSent-Subject: Re: ASCII wire efficient and proposed TYPE L 7 RFC
X-ReSent-Message-ID: <[email protected]>
ReSent-Date: Sat, 19 Aug 2006 16:09:39 -0700 (PDT)
ReSent-From: TOPS-20 List Moderator <[email protected]>
ReSent-To: TOPS-20 Distribution: ;
ReSent-Subject: Re: ASCII wire efficient and proposed TYPE L 7 RFC
ReSent-Message-ID: <[email protected]>

> I've been pondering about doing something to the FTP client/server
> data stream in order to increase wire transmission efficiency. The
> rational is as follows.
>
> I've researched TYPE A (ASCII mode) and I've come to the opinion that
> this is really wasting a decent piece of bandwidth. When in this
> mode, RFC959 specifies that a text file is to be sent as NVT-ASCII,
> which is an 8 bit wire format. However, the storage format for
> NVT-ASCII can really be fit into a 7 bit code as per RFC854 which
> specifically states that,
>
> "The code set is seven-bit US ASCII in an eight-bit field, except
> as modified herein."
>
But in real life, at least outside the USA, many files use 8-bit text
encodings such as ISO 8859. Now granted, these don't get along well with
the DEC-20 (there's just way too much "HRROI A, [ASCIZ/blah/]" built into
every application), but they *could* if we did away with the all-ones-in-the
left half trick. As much as I loved the 20, this was probably my biggest
gripe about it. If bytes can be any size, why bias it so much to a size
only Americans can use? This is one of the reasons ISO 646 had to exist.

Even leaving aside languages that use characters outside of ASCII, you
still have Microsoft to deal with. When you create text with a Microsoft
application, it changes all your ASCII quotes and apostrophes and hyphens
into godawful "smart quotes" and en-dashes and em-dashes, which it puts in
the C1 area (8th bit on). You don't even know this is happening until it
is too late.

Any marginal benefits derived from TYPE L 7 would be offset by all the
screwups and do-overs it could cause.

- Frank
19-Aug-2006 16:35:10-PDT,4271;000000000000
Return-Path: <[email protected]>
Received: from pangtzu.panda.com ([206.124.149.117]) by lingling.panda.com with TCP/SMTP; Sat, 19 Aug 2006 16:31:31 -0700 (PDT)
X-Return-Path: <[email protected]>
X-Received: from pangtzu.panda.com ([206.124.149.117]) by lingling.panda.com with TCP/SMTP; Sat, 19 Aug 2006 16:31:04 -0700 (PDT)
Date: Sat, 19 Aug 2006 16:30:59 -0700 (PDT)
From: Mark Crispin <[email protected]>
Sender: [email protected]
To: Frank da Cruz <[email protected]>
cc: TOPS-20 Hackers and Yackers <[email protected]>
Subject: Re: ASCII wire efficient and proposed TYPE L 7 RFC
In-Reply-To: <[email protected]>
Message-ID: <[email protected]>
References: <[email protected]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
ReSent-Date: Sat, 19 Aug 2006 16:31:22 -0700 (PDT)
ReSent-From: TOPS-20 List Moderator <[email protected]>
ReSent-To: TOPS-20 Distribution: ;
ReSent-Subject: Re: ASCII wire efficient and proposed TYPE L 7 RFC
ReSent-Message-ID: <[email protected]>

On Sat, 19 Aug 2006, Frank da Cruz wrote:
> But in real life, at least outside the USA, many files use 8-bit text
> encodings such as ISO 8859.

There is just as much of a problem with software and systems that assume
that 8-bit == ISO 8859-1 (or 8859-15).

> As much as I loved the 20, this was probably my biggest
> gripe about it. If bytes can be any size, why bias it so much to a size
> only Americans can use? This is one of the reasons ISO 646 had to exist.

Frank, you know better than that! Let's not contribute to the
miseducation of young'uns who think that there was some American
conspiracy to bias computing against the rest of the world.

At the time that this all was decided, EBCDIC and ASCII was all that there
was for serious codes (I'm omitting such things as 5-bit Telex code).
ASCII, which if you remember was the *American* Standard Code for
Information Exchange had parity. ASCII formed the basis of ISO 646; and
the assumption was that there would be various national variants, each to
suit the local conditions in that country.

EBCDIC was 8-bit, but you had to be of the IBM religion. What's more,
there were at least as many variants of EBCDIC as ASCII; and it was
hopelessly tied to punched card thinking (e.g., codepoints for alphabetics
were not monotonically ascending).

It wasn't until much later that the idea of document interchange between
computers in different countries crossed anyone's mind. When that time
case, just about every vendor choose its own 8-bit character set that had
some foreign script characters. Much to the dismay of people who
recognized that its inadequacies, ISO 8859 came to the forefront in the
1980s. For quite some time, the western Europeans did the same thing that
they accused the Americans of doing; the bias was hopelessly towards
western Europe. However, in short order, ISO 8859 started to accumulate
variants just as ISO 646 had done.

By the 1990s, most sensible people had concluded that this was not good,
and this (plus the desire to have email attachments) was the impetus of
MIME. The multimedia stuff was a hitchhiker to the MIME bandwagon; there
had been previous multimedia-mail proposals in the past, none of which
amounted to anything.

Even back then, most people had recognized that ISO 10646/Unicode was the
way to go. ISO 2022 was strong competition; but eventually even most of
its proponents came to the ISO 10646 side. At the time there were still
quite a few people in western Europe who advocated just sending 8-bit ISO
8859-1, and not worry about other languages -- fighting this was a major
battle.

IMHO, 8-bit formats have been hopelessly poisoned by the long history of
misuse. We really need UTF-9 and UTF-18. UTF-18 is particularly
attractive since it is almost a UCS, and it is extremely unlikely that
Unicode will assign codepoints outside of the space covered by UTF-18 in
our lifetimes.

-- Mark --

http://panda.com/tops-20
TOPS-20: a great improvement over its successors
19-Aug-2006 18:05:16-PDT,3587;000000000000
Return-Path: <[email protected]>
Received: from pangtzu.panda.com ([206.124.149.117]) by lingling.panda.com with TCP/SMTP; Sat, 19 Aug 2006 18:03:38 -0700 (PDT)
X-Return-Path: <[email protected]>
X-Received: from sesame.cc.columbia.edu ([128.59.59.56]) by lingling.panda.com with TCP/SMTP; Sat, 19 Aug 2006 17:20:57 -0700 (PDT)
X-Received: from sesame.cc.columbia.edu (localhost [127.0.0.1])
by sesame.cc.columbia.edu (8.13.7/8.13.6) with ESMTP id k7K0KoPw000803;
Sat, 19 Aug 2006 20:20:50 -0400 (EDT)
X-Received: (from fdc@localhost)
by sesame.cc.columbia.edu (8.13.7/8.12.8/Submit) id k7K0KooQ000802;
Sat, 19 Aug 2006 20:20:50 -0400 (EDT)
Date: Sat, 19 Aug 2006 20:20:50 EDT
From: Frank da Cruz <[email protected]>
To: Mark Crispin <[email protected]>
Cc: TOPS-20 Hackers and Yackers <[email protected]>
Subject: Re: ASCII wire efficient and proposed TYPE L 7 RFC
In-Reply-To: <[email protected]>
Message-ID: <[email protected]>
ReSent-Date: Sat, 19 Aug 2006 18:03:26 -0700 (PDT)
ReSent-From: TOPS-20 List Moderator <[email protected]>
ReSent-To: TOPS-20 Distribution: ;
ReSent-Subject: Re: ASCII wire efficient and proposed TYPE L 7 RFC
ReSent-Message-ID: <[email protected]>

> On Sat, 19 Aug 2006, Frank da Cruz wrote:
> > But in real life, at least outside the USA, many files use 8-bit text
> > encodings such as ISO 8859.
>
> There is just as much of a problem with software and systems that assume
> that 8-bit == ISO 8859-1 (or 8859-15).
>
> > As much as I loved the 20, this was probably my biggest
> > gripe about it. If bytes can be any size, why bias it so much to a size
> > only Americans can use? This is one of the reasons ISO 646 had to exist.
>
> Frank, you know better than that! Let's not contribute to the
> miseducation of young'uns who think that there was some American
> conspiracy to bias computing against the rest of the world.
>
I didn't mean it as an anti-American jibe, exactly. More like the
American-British-Dutch conspiracy :-) But still, decisions were made in
America by Americans (and, well, a lot of Swedes) what to do with this
wonderful hardware that was designed to accommodate any bytesize at all, and
they pretty much decided to mostly not use that capability for whatever
reason. One wonders where the architecture came from in the first place;
why variable length bytes if we weren't going to use them for characters?

Anyway, obviously, the gripe came later, when the 20s were fading out. I
spoke with people at more than one site in Europe, Japan, etc, who said "oh
well, we couldn't really use it with our language anyway..." But earlier
than that... When did the VT220 appear? Or more to the point, DEC's own
Multinational Character Set? (which was the "inspiration" for ISO 8859-1,
and hence the whole sequence of "Latin" alphabets ["Latin" in quotes because
some of them are Cyrillic, Hebrew, Greek, etc]...) I'm sure there was some
span of coexistence when DEC-20s couldn't even be used with DEC's own
terminals, at least not for German, Spanish, etc. I suspect this must have
been discussed within LCG but perhaps by then the writing was on the wall.
Converting all the HRROIs to load real byte pointers would have been a
massive task indeed (well maybe some people might have been able to do it
with a single TECO macro :-) not unlike TOPS-20'izing the many TOPS-10
programs in its repertoire, foremost among them LINK.

- Frank
19-Aug-2006 19:31:36-PDT,4191;000000000000
Return-Path: <[email protected]>
Received: from pangtzu.panda.com ([206.124.149.117]) by lingling.panda.com with TCP/SMTP; Sat, 19 Aug 2006 19:29:58 -0700 (PDT)
X-Return-Path: <[email protected]>
X-Received: from pangtzu.panda.com ([206.124.149.117]) by lingling.panda.com with TCP/SMTP; Sat, 19 Aug 2006 19:29:21 -0700 (PDT)
Date: Sat, 19 Aug 2006 19:29:16 -0700 (PDT)
From: Mark Crispin <[email protected]>
Sender: [email protected]
To: Frank da Cruz <[email protected]>
cc: TOPS-20 Hackers and Yackers <[email protected]>
Subject: Re: ASCII wire efficient and proposed TYPE L 7 RFC
In-Reply-To: <[email protected]>
Message-ID: <[email protected]>
References: <[email protected]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
ReSent-Date: Sat, 19 Aug 2006 19:29:46 -0700 (PDT)
ReSent-From: TOPS-20 List Moderator <[email protected]>
ReSent-To: TOPS-20 Distribution: ;
ReSent-Subject: Re: ASCII wire efficient and proposed TYPE L 7 RFC
ReSent-Message-ID: <[email protected]>

On Sat, 19 Aug 2006, Frank da Cruz wrote:
> One wonders where the architecture came from in the first place;
> why variable length bytes if we weren't going to use them for characters?

I think that the idea was that it could always be fixed later...in the
next operating system.

Remember that the original DEC operating system's clock expired in 1975.
In 1964, nobody considered that to be a problem; certainly it would have
been replaced by then. Who'da thunk there would have been a massive
DATE75 project to extend the life of the PDP-6 monitor (by then called
TOPS-10)?

> Anyway, obviously, the gripe came later, when the 20s were fading out. I
> spoke with people at more than one site in Europe, Japan, etc, who said "oh
> well, we couldn't really use it with our language anyway..."

Japan?!?

Why do you think that Japan used ISO 2022? It was so the 20s could
participate in JUNET and exchange Japanese email! There were several
important TOPS-20 systems in Japan at the time. I remember NTT-20 and the
system at ICOT, but there were others as well.

I also remember a 20 system in Paris that had largely been localized to
French using the French ISO 646 variant.

> I'm sure there was some
> span of coexistence when DEC-20s couldn't even be used with DEC's own
> terminals, at least not for German, Spanish, etc.

Not correct. I remember using a German terminal with TOPS-20. It looked
a bit wierd for the @ in email to be an umlauted lowercase character (I
think that it was umlaut-a, but we're talking over 20 years ago).

> I suspect this must have
> been discussed within LCG but perhaps by then the writing was on the wall.

All this was long after May 1983.

> Converting all the HRROIs to load real byte pointers would have been a
> massive task indeed

That wouldn't be the way to do it.

A little known feature of PSOUT (but not SOUT) is that a 0,,addr argument
is equivalent to -1,,addr. Similar code is in Tenex. It's quite
deliberate, as the code goes to some effort to make that work. It's not
documented in either the Tenex nor TOPS-20 JSYS manual.

Perhaps the intent was that 0,,addr would be for a new type of string
pointer.

You couldn't use it for values that take multiple types of designators
(e.g., for AC1 of SOUT) due to the overlap with other designators (JFN,
device designators, etc.), but for string-only pointers it could be used.

Of course, you'd want to get it right, since this would be the last type
of value that could be loaded with an immediate-argument instruction.

Note also that MACRO doesn't know about any type of string other than
SIXBIT and ASCII.

As tempting as it is to use UTF-9, UTF-18 has some compelling advantages.
Unlike UTF-9, UTF-18 characters are fixed-width (UTF-9 characters may be
1-3 nonets) and are guaranteed not to cross a word boundary.

-- Mark --

http://panda.com/tops-20
TOPS-20: a great improvement over its successors
20-Aug-2006 09:06:31-PDT,4131;000000000000
Return-Path: <[email protected]>
Received: from pangtzu.panda.com ([206.124.149.117]) by lingling.panda.com with TCP/SMTP; Sun, 20 Aug 2006 09:04:42 -0700 (PDT)
X-Return-Path: <[email protected]>
X-Received: from sesame.cc.columbia.edu ([128.59.59.56]) by lingling.panda.com with TCP/SMTP; Sun, 20 Aug 2006 07:38:44 -0700 (PDT)
X-Received: from sesame.cc.columbia.edu (localhost [127.0.0.1])
by sesame.cc.columbia.edu (8.13.7/8.13.6) with ESMTP id k7KEccs9010481;
Sun, 20 Aug 2006 10:38:38 -0400 (EDT)
X-Received: (from fdc@localhost)
by sesame.cc.columbia.edu (8.13.7/8.12.8/Submit) id k7KEcYHT010480;
Sun, 20 Aug 2006 10:38:34 -0400 (EDT)
Date: Sun, 20 Aug 2006 10:38:34 EDT
From: Frank da Cruz <[email protected]>
To: Mark Crispin <[email protected]>
Subject: Re: ASCII wire efficient and proposed TYPE L 7 RFC
In-Reply-To: <[email protected]>
Cc: [email protected]
Message-ID: <[email protected]>
ReSent-Date: Sun, 20 Aug 2006 09:04:33 -0700 (PDT)
ReSent-From: TOPS-20 List Moderator <[email protected]>
ReSent-To: TOPS-20 Distribution: ;
ReSent-Subject: Re: ASCII wire efficient and proposed TYPE L 7 RFC
ReSent-Message-ID: <[email protected]>

> > Anyway, obviously, the gripe came later, when the 20s were fading out. I
> > spoke with people at more than one site in Europe, Japan, etc, who said "oh
> > well, we couldn't really use it with our language anyway..."
>
> Japan?!?
>
> Why do you think that Japan used ISO 2022? It was so the 20s could
> participate in JUNET and exchange Japanese email! There were several
> important TOPS-20 systems in Japan at the time. I remember NTT-20 and the
> system at ICOT, but there were others as well.
>
Right (I was there too). But there was this big nativist movement going on,
remember Tron? The guys at NTT, or maybe KEK, as I recall, had some
applications on the -20 that used Kanji natively (by using a big bytesize).
The -20 was the perfect platform for such things. Meanwhile the NEC PC9801
also did Kanji; this was quite amazing. The OS was MS-DOS; the keyboard
driver was about a thousand times more powerful and sophisticated than the
OS. This is when we began to talk about how to transfer this stuff between
unlike platforms; within a couple years we were doing it (but,
unfortunately, not on the -20... Exercise for some reader who has entirely
too much time on her/his hands: port C-Kermit to TOPS-20!)

ISO 2022 was needed not (just) because the DEC-20 was stuck on 7-bit
character storage, but because communication channels were predominantly 7
bits wide.

> I also remember a 20 system in Paris that had largely been localized to
> French using the French ISO 646 variant.
>
Right but as you say ISO 646 was really awful. Did you ever try to write
a C program using an ISO 646 character set? :-)

(Speaking of French, our own Bill Schilit once created an EXEC Frangais
for TOPS-20. But he probably didn't bother with accents!)

Btw, my favorite 7-bit character set was Short KOI for Russian. In this
set, the Cyrillic letters were paired up with the Latin ones "by sound",
so if you received (say) an email in Short KOI but your display was ASCII
only, you could still read it. Also, it was easy to type on an ASCII
keyboard (except for the 7 extra letters!)

> As tempting as it is to use UTF-9, UTF-18 has some compelling advantages.
> Unlike UTF-9, UTF-18 characters are fixed-width (UTF-9 characters may be
> 1-3 nonets) and are guaranteed not to cross a word boundary.
>
Well, as the activity on this list rises almost to its former levels, maybe
the DEC-20 will once again become an important enough platform for the UTC
to consider these on some day other than April 1st! We like the -20 because
it's cool, but the trick is to create some application that the world will
crave, that is only practical on this architecture, so there will be some
popular support. Maybe something that massively uses variable-length bytes!

- Frank
20-Aug-2006 09:57:40-PDT,3340;000000000000
Return-Path: <[email protected]>
Received: from pangtzu.panda.com ([206.124.149.117]) by lingling.panda.com with TCP/SMTP; Sun, 20 Aug 2006 09:56:09 -0700 (PDT)
X-Return-Path: <[email protected]>
X-Received: from pangtzu.panda.com ([206.124.149.117]) by lingling.panda.com with TCP/SMTP; Sun, 20 Aug 2006 09:55:46 -0700 (PDT)
Date: Sun, 20 Aug 2006 09:55:41 -0700 (PDT)
From: Mark Crispin <[email protected]>
Sender: [email protected]
To: Frank da Cruz <[email protected]>
cc: [email protected]
Subject: Re: ASCII wire efficient and proposed TYPE L 7 RFC
In-Reply-To: <[email protected]>
Message-ID: <[email protected]>
References: <[email protected]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
ReSent-Date: Sun, 20 Aug 2006 09:56:00 -0700 (PDT)
ReSent-From: TOPS-20 List Moderator <[email protected]>
ReSent-To: TOPS-20 Distribution: ;
ReSent-Subject: Re: ASCII wire efficient and proposed TYPE L 7 RFC
ReSent-Message-ID: <[email protected]>

On Sun, 20 Aug 2006, Frank da Cruz wrote:
> Right (I was there too). But there was this big nativist movement going on,
> remember Tron?

Right, and the Fifth-Generation Computing Project which was going to save
the world for AI and the Prolog programming language. It gave a new
meaning to the term "abject failure"...

> Meanwhile the NEC PC9801
> also did Kanji; this was quite amazing. The OS was MS-DOS; the keyboard
> driver was about a thousand times more powerful and sophisticated than the
> OS.

I remember this, but IIRC the NEC wasn't exactly DOS.

There was, however DOS/V which was true DOS and which ran on ordinary PCs.
I have the floppies for it someplace, since I once had used an application
that required it.

> Right but as you say ISO 646 was really awful. Did you ever try to write
> a C program using an ISO 646 character set? :-)

No more awful than getting an ISO 8859-1 email in a Japanese email reader.

> Well, as the activity on this list rises almost to its former levels, maybe
> the DEC-20 will once again become an important enough platform for the UTC
> to consider these on some day other than April 1st! We like the -20 because
> it's cool, but the trick is to create some application that the world will
> crave, that is only practical on this architecture, so there will be some
> popular support. Maybe something that massively uses variable-length bytes!

For that, we would need a hardware implementation of the PDP-10 that runs
in the multi-GHz range. PDP-10s today are much faster than the old
hardware (DEC, XKL, even SC) but still run in the 10s of MHz.

Whatever can be done in a microcoded machine well can be done better in
microcode. In the past, microcode was obscure and difficult to develop;
there was also a limit on microcode code space.

Microcode today is C on byte-oriented machines (some call it a "high level
language"). Far more people today have programming skilled in this
microcode than do in PDP-10 macrocode, and the old code space limits on
microcode are gone.

-- Mark --

http://panda.com/tops-20
TOPS-20: a great improvement over its successors
21-Aug-2006 20:36:00-PDT,2597;000000000000
Return-Path: <[email protected]>
Received: from pangtzu.panda.com ([206.124.149.117]) by lingling.panda.com with TCP/SMTP; Mon, 21 Aug 2006 20:34:00 -0700 (PDT)
X-Return-Path: <[email protected]>
X-Received: from sj-iport-1.cisco.com ([171.71.176.70]) by lingling.panda.com with TCP/SMTP; Mon, 21 Aug 2006 20:29:46 -0700 (PDT)
X-Received: from sj-dkim-1.cisco.com ([171.71.179.21])
by sj-iport-1.cisco.com with ESMTP; 21 Aug 2006 20:29:40 -0700
X-Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254])
by sj-dkim-1.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k7M3TeWS002365;
Mon, 21 Aug 2006 20:29:40 -0700
X-Received: from cisco.com (pita.cisco.com [171.71.177.199])
by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k7M3TdYp007640;
Mon, 21 Aug 2006 20:29:39 -0700 (PDT)
X-Received: (from billw@localhost)
by cisco.com (8.8.8-Cisco List Logging/8.8.8) id UAA29091;
Mon, 21 Aug 2006 20:28:42 -0700 (PDT)
Sender: Bill Westfield <[email protected]>
Date: Mon, 21 Aug 2006 20:28:42 PDT
From: William "Chops" Westfield <[email protected]>
To: [email protected]
Cc: TOPS-20 List Moderator <[email protected]>,
[email protected]
Subject: Re: ASCII wire efficient and proposed TYPE L 7 RFC
In-Reply-To: Your message of Sat, 19 Aug 2006 17:38:19 +0000 (GMT)
Message-ID: <CMM.0.90.4.1156217322.billw@pita>
DKIM-Signature: a=rsa-sha1; q=dns; l=208; t=1156217380; x=1157081380;
c=relaxed/simple; s=sjdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version;
d=cisco.com; [email protected]; z=From:William=20=22Chops=22=20Westfield=20<[email protected]>
|Subject:Re=3A=20ASCII=20wire=20efficient=20and=20proposed=20TYPE=20L=207=20RFC
|Sender:Bill=20Westfield=20<[email protected]>;
X=v=3Dcisco.com=3B=20h=3DryuBeLQRfgFP5cCMUEKFB4q53QU=3D; b=FlgTedlL/B6cagzJijJNaq7OdZuiamRNXtrbLybOjHbiJTkRs2gJ8GrOKgZ9fr5lo2LjO6+1
9Fgqd9Ajo/M1yutQ4BNCFMxWxzEMqGtEjGSnbySogffe11J7+9U44dcw;
Authentication-Results: sj-dkim-1.cisco.com; [email protected]; dkim=pass (
sig from cisco.com verified; );
ReSent-Date: Mon, 21 Aug 2006 20:33:48 -0700 (PDT)
ReSent-From: TOPS-20 List Moderator <[email protected]>
ReSent-To: TOPS-20 Distribution: ;
ReSent-Subject: Re: ASCII wire efficient and proposed TYPE L 7 RFC
ReSent-Message-ID: <[email protected]>

There's a unix (?) ftp hack that automatically gzips the file on transmit
and g-unzips it on reception. If you really want to conserve bandwidth,
that'll save you a lot more than one bit of 8...

BillW
21-Aug-2006 20:55:06-PDT,2951;000000000000
Return-Path: <[email protected]>
Received: from pangtzu.panda.com ([206.124.149.117]) by lingling.panda.com with TCP/SMTP; Mon, 21 Aug 2006 20:53:32 -0700 (PDT)
X-Return-Path: <[email protected]>
X-Received: from pangtzu.panda.com ([206.124.149.117]) by lingling.panda.com with TCP/SMTP; Mon, 21 Aug 2006 20:53:09 -0700 (PDT)
Date: Mon, 21 Aug 2006 20:53:03 -0700 (PDT)
From: Mark Crispin <[email protected]>
Sender: [email protected]
To: William Chops Westfield <[email protected]>
cc: TOPS-20 Hackers and Yackers <[email protected]>
Subject: Re: ASCII wire efficient and proposed TYPE L 7 RFC
In-Reply-To: <CMM.0.90.4.1156217322.billw@pita>
Message-ID: <[email protected]>
References: <CMM.0.90.4.1156217322.billw@pita>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
ReSent-Date: Mon, 21 Aug 2006 20:53:24 -0700 (PDT)
ReSent-From: TOPS-20 List Moderator <[email protected]>
ReSent-To: TOPS-20 Distribution: ;
ReSent-Subject: Re: ASCII wire efficient and proposed TYPE L 7 RFC
ReSent-Message-ID: <[email protected]>

On Mon, 21 Aug 2006, William Chops Westfield wrote:
> There's a unix (?) ftp hack that automatically gzips the file on transmit
> and g-unzips it on reception. If you really want to conserve bandwidth,
> that'll save you a lot more than one bit of 8...

True enough.

Also, when I think about it,...

For text files, you are stuck with the waste of one bit of 8 going to UNIX
and other byte-oriented systems. They aren't going to change to
accomodate us. Furthermore, you have to use TYPE A with UNIX systems
since they need to convert newlines.

However, for PDP-10s, you wouldn't use TYPE A or any form of 8-bit
transfer for text files! When transferring files of any type to a Tenex
or TOPS-20 system, you'll use paged transfers. For ITS, TOPS-10, and
WAITS systems, you'll use 36-bit image transfers.

So, there is only one "wasted" bit per 36 bits, not 8, in a transfer
between PDP-10 systems. However, it's not really wasted; the bit is
significant. When reading text files, that bit being set indicates that
the entire word is a line number (for editors such as SOS) and thus
is disregarded when reading the file as pure text.

Of course, this depends upon knowing what OS is on the other system.
Sadly, this depends upon the host table or the DNS to provide that
information, rather than being negotiated in FTP. This isn't good; I
can't get my own DNS provider to include HINFO records in the DNS records
of my TOPS-20 systems because they think that HINFO is a "security hole".

However, I think that it is a safe bet that a server that accepts
TYPE L 36
is a PDP-10, and a server that accepts
STRU P
is a Tenex or TOPS-20.

-- Mark --

http://panda.com/tops-20
TOPS-20: a great improvement over its successors
23-Aug-2006 22:06:58-PDT,1907;000000000000
Return-Path: <[email protected]>
Received: from pangtzu.panda.com ([206.124.149.117]) by lingling.panda.com with TCP/SMTP; Wed, 23 Aug 2006 22:05:03 -0700 (PDT)
X-Return-Path: <[email protected]>
X-Received: from pangtzu.panda.com ([206.124.149.117]) by lingling.panda.com with TCP/SMTP; Wed, 23 Aug 2006 22:04:19 -0700 (PDT)
Date: Wed, 23 Aug 2006 22:04:12 -0700 (PDT)
From: Mark Crispin <[email protected]>
Sender: [email protected]
To: TOPS-20 Hackers and Yackers <[email protected]>
Subject: PDP-10 implementation of APL is really really bad
Message-ID: <[email protected]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
ReSent-Date: Wed, 23 Aug 2006 22:04:52 -0700 (PDT)
ReSent-From: TOPS-20 List Moderator <[email protected]>
ReSent-To: TOPS-20 Distribution: ;
ReSent-Subject: PDP-10 implementation of APL is really really bad
ReSent-Message-ID: <[email protected]>

I decided to play with APLSF on the PDP-10 a bit. After figuring out that
multiple was #, I tried a simple APL factorial problem
# / .IO 10
(which in APL is the multiply reduction of the values from 1 to 10) and
got 3628800 as expected. I then tried a few more complex values:
# / .IO 20
2.432902008E18
# / .IO 30
2.652528598E32
# / .IO 40

At this point, APLSF hung. I stopped it after a few CPU minutes.

OK, granted that APL has been out of fashion since the mid 1970s; but I
still find it rather unbelievable that it has a difficult time maintaining
a vector of 40 values, much less multiplying them. More likely, it
can't handle getting a floating point overflow. But why would it hang
instead of barfing?

LISP doesn't have this problem!

-- Mark --

http://panda.com/tops-20
TOPS-20: a great improvement over its successors
24-Aug-2006 04:10:03-PDT,2806;000000000000
Return-Path: <[email protected]>
Received: from pangtzu.panda.com ([206.124.149.117]) by lingling.panda.com with TCP/SMTP; Thu, 24 Aug 2006 04:08:09 -0700 (PDT)
X-Return-Path: <[email protected]>
X-Received: from sj-iport-5.cisco.com ([171.68.10.87]) by lingling.panda.com with TCP/SMTP; Wed, 23 Aug 2006 23:38:49 -0700 (PDT)
X-Received: from sj-dkim-6.cisco.com ([171.68.10.81])
by sj-iport-5.cisco.com with ESMTP; 23 Aug 2006 23:38:43 -0700
X-IronPort-AV: i="4.08,163,1154934000";
d="scan'208"; a="313441575:sNHT27285498"
X-Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137])
by sj-dkim-6.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k7O6chY1013526;
Wed, 23 Aug 2006 23:38:43 -0700
X-Received: from cisco.com (pita.cisco.com [171.71.177.199])
by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id k7O6cgw7020769;
Wed, 23 Aug 2006 23:38:43 -0700 (PDT)
X-Received: (from billw@localhost)
by cisco.com (8.8.8-Cisco List Logging/8.8.8) id XAA12747;
Wed, 23 Aug 2006 23:37:42 -0700 (PDT)
Sender: Bill Westfield <[email protected]>
Date: Wed, 23 Aug 2006 23:37:42 PDT
From: William "Chops" Westfield <[email protected]>
To: Mark Crispin <[email protected]>
Cc: TOPS-20 List Moderator <[email protected]>,
TOPS-20 Hackers and Yackers <[email protected]>
Subject: Re: PDP-10 implementation of APL is really really bad
In-Reply-To: Your message of Wed, 23 Aug 2006 22:04:12 -0700 (PDT)
Message-ID: <CMM.0.90.4.1156401462.billw@pita>
DKIM-Signature: a=rsa-sha1; q=dns; l=278; t=1156401523; x=1157265523;
c=relaxed/simple; s=sjdkim6002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version;
d=cisco.com; [email protected]; z=From:William=20=22Chops=22=20Westfield=20<[email protected]>
|Subject:Re=3A=20PDP-10=20implementation=20of=20APL=20is=20really=20really=20bad
|Sender:Bill=20Westfield=20<[email protected]>;
X=v=3Dcisco.com=3B=20h=3DZqF/hEUZ9E8hvH+5QBsUa7Et1IM=3D; b=my+gwSekeoNDtAVeciW5Gf0FYrwOe6IdZ5bfpPu+FJgIVEkECZcf0OmuaiG/Cqrw9865hrg1
Hiwq+BQewKDZW39WKqs5enWGQ/Pl7XMw4peAnhF17AdrckV2/mg0DLx7;
Authentication-Results: sj-dkim-6.cisco.com; [email protected]; dkim=pass (
sig from cisco.com verified; );
ReSent-Date: Thu, 24 Aug 2006 04:08:02 -0700 (PDT)
ReSent-From: TOPS-20 List Moderator <[email protected]>
ReSent-To: TOPS-20 Distribution: ;
ReSent-Subject: Re: PDP-10 implementation of APL is really really bad
ReSent-Message-ID: <[email protected]>

> But why would it hang instead of barfing?

Has the floating point exception handling been thoroughly tested on
the "x86 microcode" machines?

BillW

PS: I see that APL and APL-like languages are in fact still available
for modern operating systems. Impressive.
24-Aug-2006 04:20:23-PDT,1579;000000000000
Return-Path: <[email protected]>
Received: from pangtzu.panda.com ([206.124.149.117]) by lingling.panda.com with TCP/SMTP; Thu, 24 Aug 2006 04:18:41 -0700 (PDT)
X-Return-Path: <[email protected]>
X-Received: from pangtzu.panda.com ([206.124.149.117]) by lingling.panda.com with TCP/SMTP; Thu, 24 Aug 2006 04:13:11 -0700 (PDT)
Date: Thu, 24 Aug 2006 04:13:06 -0700 (PDT)
From: Mark Crispin <[email protected]>
Sender: [email protected]
To: William Chops Westfield <[email protected]>
cc: TOPS-20 Hackers and Yackers <[email protected]>
Subject: Re: PDP-10 implementation of APL is really really bad
In-Reply-To: <CMM.0.90.4.1156401462.billw@pita>
Message-ID: <[email protected]>
References: <CMM.0.90.4.1156401462.billw@pita>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
ReSent-Date: Thu, 24 Aug 2006 04:17:23 -0700 (PDT)
ReSent-From: TOPS-20 List Moderator <[email protected]>
ReSent-To: TOPS-20 Distribution: ;
ReSent-Subject: Re: PDP-10 implementation of APL is really really bad
ReSent-Message-ID: <[email protected]>

On Wed, 23 Aug 2006, William Chops Westfield wrote:
> Has the floating point exception handling been thoroughly tested on
> the "x86 microcode" machines?

Good point. I see that on an XKL-1, that operation in APLSF results in an
immediate DOMAIN ERROR instead of hanging. I'll take it up with KLH.

Thanks.

-- Mark --

http://panda.com/tops-20
TOPS-20: a great improvement over its successors
24-Aug-2006 04:41:43-PDT,3226;000000000000
Return-Path: <[email protected]>
Received: from pangtzu.panda.com ([206.124.149.117]) by lingling.panda.com with TCP/SMTP; Thu, 24 Aug 2006 04:39:54 -0700 (PDT)
X-Return-Path: <[email protected]>
X-Received: from pangtzu.panda.com ([206.124.149.117]) by lingling.panda.com with TCP/SMTP; Thu, 24 Aug 2006 04:30:31 -0700 (PDT)
X-Return-Path: <[email protected]>
X-Received: from mail.math.utah.edu ([155.101.98.135]) by lingling.panda.com with TCP/SMTP; Thu, 24 Aug 2006 04:26:41 -0700 (PDT)
X-Received: from psi.math.utah.edu (psi.math.utah.edu [155.101.96.19])
by mail.math.utah.edu (8.13.6/8.13.6) with ESMTP id k7OBQV8G017250;
Thu, 24 Aug 2006 05:26:31 -0600 (MDT)
X-Received: from psi.math.utah.edu (localhost [127.0.0.1])
by psi.math.utah.edu (8.13.6/8.13.6) with ESMTP id k7OBQVgp011790;
Thu, 24 Aug 2006 05:26:31 -0600 (MDT)
X-Received: (from beebe@localhost)
by psi.math.utah.edu (8.13.6/8.13.6/Submit) id k7OBQVqJ011789;
Thu, 24 Aug 2006 05:26:31 -0600 (MDT)
Date: Thu, 24 Aug 2006 05:26:31 -0600 (MDT)
From: "Nelson H. F. Beebe" <[email protected]>
To: Mark Crispin <[email protected]>
Cc: [email protected], TOPS-20 List Moderator <[email protected]>
X-US-Mail: "Department of Mathematics, 110 LCB, University of Utah, 155 S
1400 E RM 233, Salt Lake City, UT 84112-0090, USA"
X-Telephone: +1 801 581 5254
X-FAX: +1 801 585 1640, +1 801 581 4148
X-URL: http://www.math.utah.edu/~beebe
Subject: Re: PDP-10 implementation of APL is really really bad
In-Reply-To: <[email protected]>
Message-ID: <[email protected]>
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0 (mail.math.utah.edu [155.101.98.135]); Thu, 24 Aug 2006 05:26:31 -0600 (MDT)
X-ReSent-Date: Thu, 24 Aug 2006 04:30:22 -0700 (PDT)
X-ReSent-From: Mark Crispin <[email protected]>
X-ReSent-To: TOPS-20 Hackers and Yackers <[email protected]>
X-ReSent-Subject: Re: PDP-10 implementation of APL is really really bad
X-ReSent-Message-ID: <[email protected]>
ReSent-Date: Thu, 24 Aug 2006 04:38:16 -0700 (PDT)
ReSent-From: TOPS-20 List Moderator <[email protected]>
ReSent-To: TOPS-20 Distribution: ;
ReSent-Subject: Re: PDP-10 implementation of APL is really really bad
ReSent-Message-ID: <[email protected]>

Mark Crispin asks why factorial of 40 would hang APLSF in a CPU loop.

I suspect it has the same problem that kcc has (but not fortran): overflow
and underflow on the PDP-10 wrap to small and large values respectively.
For example,

-------------------------------------------------------------------------------
- Nelson H. F. Beebe Tel: +1 801 581 5254 -
- University of Utah FAX: +1 801 581 4148 -
- Department of Mathematics, 110 LCB Internet e-mail: [email protected] -
- 155 S 1400 E RM 233 [email protected] [email protected] -
- Salt Lake City, UT 84112-0090, USA URL: http://www.math.utah.edu/~beebe/ -
-------------------------------------------------------------------------------
24-Aug-2006 11:26:37-PDT,1637;000000000000
Return-Path: <[email protected]>
Received: from pangtzu.panda.com ([206.124.149.117]) by lingling.panda.com with TCP/SMTP; Thu, 24 Aug 2006 11:24:35 -0700 (PDT)
Mail-From: MRC created at 24-Aug-2006 11:23:26
Date: Thu, 24 Aug 2006 11:23:26 -0700 (PDT)
From: Mark Crispin <[email protected]>
Subject: Re: PDP-10 implementation of APL is really really bad
To: [email protected]
In-Reply-To: <[email protected]>
Pithy-Thought: TOPS-20 was a great improvement over its successors
Message-ID: <[email protected]>
ReSent-Date: Thu, 24 Aug 2006 11:24:25 -0700 (PDT)
ReSent-From: TOPS-20 List Moderator <[email protected]>
ReSent-To: TOPS-20 Distribution: ;
ReSent-Subject: Re: PDP-10 implementation of APL is really really bad
ReSent-Message-ID: <[email protected]>

> Good point. I see that on an XKL-1, that operation in APLSF results in an
> immediate DOMAIN ERROR instead of hanging. I'll take it up with KLH.

For what it's worth, an SC-40 has the same hanging problem as a
klh10. So this sounds like it may be some ambiguity in the PRM
that XKL did one way, and SC and KLH did the other way.

I want to try it on a real KL10, but the only KL that I have
access to is the Paul Allen machine, and Kermit barfs on
transferring the APLSF.EXE file. I don't know why, nor if the
APLSF-20 file will work on TOPS-10.

Rich, if you're reading this, could you either try installing
APLSF-10 or see if you can get the <MRC>APLSF.EXE file from
xkleten to the TOPS-10 machine via tapenet? Thanks.
-------
24-Aug-2006 18:35:36-PDT,1734;000000000000
Return-Path: <[email protected]>
Received: from pangtzu.panda.com ([206.124.149.117]) by lingling.panda.com with TCP/SMTP; Thu, 24 Aug 2006 18:33:53 -0700 (PDT)
X-Return-Path: <[email protected]>
X-Received: from ics.com (mx.ics.com [209.59.5.4]) by lingling.panda.com with TCP/SMTP; Thu, 24 Aug 2006 14:20:45 -0700 (PDT)
X-Received: from ultimate.com (c-66-30-204-193.hsd1.ma.comcast.net [66.30.204.193])
by ics.com (8.12.9p1/8.12.9) with SMTP id k7OLKVK3026955;
Thu, 24 Aug 2006 17:20:32 -0400 (EDT)
(envelope-from [email protected])
X-Received: (from phil@localhost)
by ultimate.com (8.13.6/8.13.6) id k7OLKVWu016354;
Thu, 24 Aug 2006 17:20:31 -0400 (EDT)
Date: Thu, 24 Aug 2006 17:20:31 -0400 (EDT)
From: Phil Budne <[email protected]>
Message-Id: <[email protected]>
To: [email protected], [email protected]
Subject: Re: ASCII wire efficient and proposed TYPE L 7 RFC
Cc: [email protected]
ReSent-Date: Thu, 24 Aug 2006 18:33:44 -0700 (PDT)
ReSent-From: TOPS-20 List Moderator <[email protected]>
ReSent-To: TOPS-20 Distribution: ;
ReSent-Subject: Re: ASCII wire efficient and proposed TYPE L 7 RFC
ReSent-Message-ID: <[email protected]>

On Mon, 21 Aug 2006 Mark Crispin <[email protected]> wrote:

> Of course, this depends upon knowing what OS is on the other system.
> Sadly, this depends upon the host table or the DNS to provide that
> information, rather than being negotiated in FTP. This isn't good; I
> can't get my own DNS provider to include HINFO records in the DNS records
> of my TOPS-20 systems because they think that HINFO is a "security hole".

Isn't this what "SYST" (RFC959) is for?
24-Aug-2006 18:37:02-PDT,1410;000000000000
Return-Path: <[email protected]>
Received: from pangtzu.panda.com ([206.124.149.117]) by lingling.panda.com with TCP/SMTP; Thu, 24 Aug 2006 18:34:03 -0700 (PDT)
Mail-From: MRC created at 24-Aug-2006 18:33:03
Date: Thu, 24 Aug 2006 18:33:03 -0700 (PDT)
From: Mark Crispin <[email protected]>
Subject: Re: ASCII wire efficient and proposed TYPE L 7 RFC
To: [email protected]
cc: [email protected], [email protected]
In-Reply-To: <[email protected]>
Pithy-Thought: TOPS-20 was a great improvement over its successors
Message-ID: <[email protected]>
ReSent-Date: Thu, 24 Aug 2006 18:33:56 -0700 (PDT)
ReSent-From: TOPS-20 List Moderator <[email protected]>
ReSent-To: TOPS-20 Distribution: ;
ReSent-Subject: Re: ASCII wire efficient and proposed TYPE L 7 RFC
ReSent-Message-ID: <[email protected]>

> > Of course, this depends upon knowing what OS is on the other system.
> > Sadly, this depends upon the host table or the DNS to provide that
> > information, rather than being negotiated in FTP. This isn't good; I
> > can't get my own DNS provider to include HINFO records in the DNS records
> > of my TOPS-20 systems because they think that HINFO is a "security hole".
> Isn't this what "SYST" (RFC959) is for?

Most versions of the TOPS-20 FTP server don't implement SYST.
-------
25-Aug-2006 10:06:49-PDT,4764;000000000000
Return-Path: <[email protected]>
Received: from pangtzu.panda.com ([206.124.149.117]) by lingling.panda.com with TCP/SMTP; Fri, 25 Aug 2006 10:04:39 -0700 (PDT)
X-Return-Path: <[email protected]>
X-Received: from mta3.srv.hcvlny.cv.net ([167.206.4.198]) by lingling.panda.com with TCP/SMTP; Fri, 25 Aug 2006 08:18:56 -0700 (PDT)
X-Received: from optonline.net (hamstr3.srv.hcvlny.cv.net [167.206.5.10])
by mta3.srv.hcvlny.cv.net
(Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006))
with ESMTP id <[email protected]>; Fri,
25 Aug 2006 11:18:21 -0400 (EDT)
X-Received: from [10.240.3.197] (Forwarded-For: [10.240.3.197])
by mstr3.srv.hcvlny.cv.net (mshttpd); Fri, 25 Aug 2006 15:18:21 +0000 (GMT)
Date: Fri, 25 Aug 2006 15:18:21 +0000 (GMT)
From: [email protected]
Subject: Re: ASCII wire efficient and proposed TYPE L 7 RFC
In-reply-to: <[email protected]>
To: Mark Crispin <[email protected]>
Cc: [email protected], [email protected], [email protected]
Message-id: <[email protected]>
MIME-version: 1.0
X-Mailer: Sun Java(tm) System Messenger Express 6.2-6.01 (built Apr 3 2006)
Content-type: text/plain; charset=us-ascii
Content-language: en
Content-transfer-encoding: 7BIT
Content-disposition: inline
X-Accept-Language: en
Priority: normal
References: <[email protected]>
<[email protected]>
ReSent-Date: Fri, 25 Aug 2006 10:04:30 -0700 (PDT)
ReSent-From: TOPS-20 List Moderator <[email protected]>
ReSent-To: TOPS-20 Distribution: ;
ReSent-Subject: Re: ASCII wire efficient and proposed TYPE L 7 RFC
ReSent-Message-ID: <[email protected]>

> > Isn't this what "SYST" (RFC959) is for?
>
> Most versions of the TOPS-20 FTP server don't implement SYST.

Actually, it's worse than this.

The base version of the BBN FTPSRT that came with my first PANDA distribution did NOT implement PWD, XPWD, SYST, SIZE and MDTM. This broke a lot of 'modern' FTP clients. I modified it to do all of these things and published the results on Tops-20. I don't know how far this was redistributed as I abandoned it when I began work on the new server about two years ago. For example, the last time I checked, TWENEX.ORG wasn't running it (or the updated FTP client, either).

For the two Toads that I've had access to, both will correctly handle SYST, but I don't know what their vintage is, having never had looked at that particular source. They report a different version than the stock BBN FTPSRT, so I would assume that somebody did something.

When ***NOT*** in TVFS mode, the new extended mode FTP server implements SYST and will report TOPS20.

So, if the remote FTP server reports TOPS20, it's safe to assume that you're talking to a 20.

However, when the new server is in TVFS mode, it has to lie about a number of things in order to not have certain cretinous ill-informed mis-featured FTP clients break. It responds to SYST by saying it is a UNIX L8, which is the only thing that most anybody wants to hear, these days.

The response to PWD is Unixified, dates from MDTM are clipped if necessary, the SIZE byte count is clipped to 31 bits and, for ASCII files, the number of seven bit bits is reported instead of the total number of bits in the file divided by 8 (a smaller number). This is in direct contradiction to RFC959 which says that you must do the former, but if you don't do this, another swell FTP client will chop off the end of the file!

Because of this, the only definitive way to know that you are talking to a 20 is to issue a FEAT and look for TOPS20 in the feature list. This informs you that the server supports the winning advanced features of TOPS20. The extended mode FTP server always reports this, even if it is in TVFS mode.

If FEAT does not exist, then do a SYST. If that works and it says TOPS20, then you're also good. Then do a GTHST% first to see if you've had to override a remote DNS. Then do a GTDOM%. Unfortunately, doing the last thing can take the longest (particularly if you are not in the DNS)) and sometimes you have no control over the results.

Using the response to STRU and TYPE L 36 will also currently work (I checked on Windows 2000, SCO Unix, Debian Unix and Mac OSX), but I wish to avoid this as that's not what these commands are for. I believe I recall hearing about some other OS wanting to try paged file structures, but I just can remember what it was.

Use FEAT first and then SYST.

The current Tops-20 FTP client only checks the DNS. When I have an alpha candidate of the new server, then I will update the FTP client to implement the above behavior.
25-Aug-2006 13:13:14-PDT,2152;000000000000
Return-Path: <[email protected]>
Received: from pangtzu.panda.com ([206.124.149.117]) by lingling.panda.com with TCP/SMTP; Fri, 25 Aug 2006 13:11:21 -0700 (PDT)
X-Return-Path: <[email protected]>
X-Received: from sesame.cc.columbia.edu ([128.59.59.56]) by lingling.panda.com with TCP/SMTP; Fri, 25 Aug 2006 11:06:40 -0700 (PDT)
X-Received: from sesame.cc.columbia.edu (localhost [127.0.0.1])
by sesame.cc.columbia.edu (8.13.7/8.13.6) with ESMTP id k7PI6X15018181;
Fri, 25 Aug 2006 14:06:33 -0400 (EDT)
X-Received: (from fdc@localhost)
by sesame.cc.columbia.edu (8.13.7/8.12.8/Submit) id k7PI6Tow018178;
Fri, 25 Aug 2006 14:06:29 -0400 (EDT)
Date: Fri, 25 Aug 2006 14:06:29 EDT
From: Frank da Cruz <[email protected]>
To: [email protected]
Cc: [email protected], [email protected], [email protected]
Subject: Re: ASCII wire efficient and proposed TYPE L 7 RFC
In-Reply-To: <[email protected]>
Message-ID: <[email protected]>
ReSent-Date: Fri, 25 Aug 2006 13:11:08 -0700 (PDT)
ReSent-From: TOPS-20 List Moderator <[email protected]>
ReSent-To: TOPS-20 Distribution: ;
ReSent-Subject: Re: ASCII wire efficient and proposed TYPE L 7 RFC
ReSent-Message-ID: <[email protected]>

> The response to PWD is Unixified...
>
The response to PWD should be in Unix format, of course, but don't bend
over backwards too far or pretty soon you'll be sending Unix-style "ls -l"
listings in response to LIST.

Out of curiosity, does your server support MLSD?

http://www.columbia.edu/kermit/ckermit80.html#x3.11.3

> dates from MDTM are clipped if necessary...
>
How can MDTM not include the date?

> ...the SIZE byte count is clipped to 31 bits and, for ASCII files...
>
What if the file is bigger than that? (Can that happen in TOPS-20?)
As you know, I've put some time in to make C-Kermit -- including its FTP
client -- handle "large files" (63-bit sizes). Unfortunately I haven't yet
found a single server that does this too without major screwups, except (can
you guess?)... the Tru64 Unix FTP server.

- Frank
25-Aug-2006 22:55:00-PDT,14900;000000000000
Return-Path: <[email protected]>
Received: from pangtzu.panda.com ([206.124.149.117]) by lingling.panda.com with TCP/SMTP; Fri, 25 Aug 2006 22:53:40 -0700 (PDT)
X-Return-Path: <[email protected]>
X-Received: from mta6.srv.hcvlny.cv.net ([167.206.4.201]) by lingling.panda.com with TCP/SMTP; Fri, 25 Aug 2006 17:33:39 -0700 (PDT)
X-Received: from optonline.net (hamstr3.srv.hcvlny.cv.net [167.206.5.10])
by mta6.srv.hcvlny.cv.net
(Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006))
with ESMTP id <[email protected]> for
[email protected]; Fri, 25 Aug 2006 20:33:30 -0400 (EDT)
X-Received: from [10.240.3.199] (Forwarded-For: [10.240.3.199])
by mstr3.srv.hcvlny.cv.net (mshttpd); Sat, 26 Aug 2006 00:33:29 +0000 (GMT)
Date: Sat, 26 Aug 2006 00:33:29 +0000 (GMT)
From: [email protected]
Subject: Re: ASCII wire efficient and proposed TYPE L 7 RFC
In-reply-to: <[email protected]>
To: Frank da Cruz <[email protected]>
Cc: [email protected], [email protected], [email protected]
Message-id: <[email protected]>
MIME-version: 1.0
X-Mailer: Sun Java(tm) System Messenger Express 6.2-6.01 (built Apr 3 2006)
Content-type: text/plain; charset=us-ascii
Content-language: en
Content-transfer-encoding: 7BIT
Content-disposition: inline
X-Accept-Language: en
Priority: normal
References: <[email protected]>
<[email protected]>
ReSent-Date: Fri, 25 Aug 2006 22:53:32 -0700 (PDT)
ReSent-From: TOPS-20 List Moderator <[email protected]>
ReSent-To: TOPS-20 Distribution: ;
ReSent-Subject: Re: ASCII wire efficient and proposed TYPE L 7 RFC
ReSent-Message-ID: <[email protected]>

Hi Frank,

Before I respond to this email (and possibly dismay you), I think I
should explicitly review why I'm doing a new FTP server (aside from
the fact that it's fun, which is surely reason enough).

About three years ago, I was busy happily using the BBN server to
transfer files to and from Tops-20. Most, if not all, character mode
FTP clients will still work with the BBN server, although some will
mutter bumping into its (many) unimplemented features.

This experience is why I don't think that using the responses from
STRU P and TYPE L 36 as a test of Tops-20'ishness is a winning
approach, although it certainly does get the job done. More
importantly, it is the ONLY way to definitively know that you are
talking to the BBN server if your system does not have an entry in the
DNS.

The typical reason that I transferred files was because I could not
fit them into TECO (er, EMACS). This included large program listings,
but was more usually because I had too many large buffers. That can
easily happen when you are juggling a few things, such as trying to
track a Galaxy issue through the Exec, monitor, GLXLIB and QUASAR.

I kept getting annoyed that I couldn't just read the files into
gnuEmacs because the stock ange-FTP mode doesn't grok Tops-20 file
specifications. It tries to grok foreign file specifications by
converting them into 'canonical' form which is fancy synonym for Unix.
I tried hacking the ange-FTP LISP source code, but that was very
difficult for me both because I'm not a LISP wizard and because
ange-FTP wants features that the stock BBN server doesn't have.

So I tried hacking bandaids and put a number of features into the BBN
FTP server: PWD, XPWD (the Windows FTP client wants this), SYST, CDUP,
SIZE, MDTM, FEAT and SITE CKM. Then I tried co-ercing ange-FTP into
talking to the new server. No go--I couldn't do it. Even when I got
the source code to an ange-FTP that handled VMS file specifications, I
still couldn't make it work.

I'm not saying whether hacking the LISP code is intrinsically hard or
not, just that I myself couldn't do it, even with some examples how.
I also wanted to use graphical FTP clients such as Internet Explorer,
Netscape Messenger, EFTP and Safari, with Tops-20. In additional, I
had begun to wonder about the performance limits of the performance of
the Tops-20 TCP/IP stack and whether the BBN server was achieving the
maximum throughput. MRC had cautioned me a number of times about
various issues associated with TCPSIM. It all got so hairy that I
eventually threw my hands up and started from scratch.

In summary, I wanted to:

1) Use ange-FTP
2) Use graphical FTP clients
3) Not hear any noise from 'modern' character mode FTP clients
4) Investigate the limits of transfer speeds
5) Have improved maintainability and a platform for future expansion
6) Impress friends and relatives

The extended mode server concentrates on these issues and those goals
have been achieved. It has a dynamic buffer scheme that can handle
moby sized buffers and I'm getting about a decimal order of magnitude
improvement in transfer speeds. It works with all graphical FTP
clients except Safari (Safari has seperate issues not related to FTP).
I don't hear any noise anymore from the character mode FTP clients
that I use. I have used ange-FTP mode with it every day for the past
18 months to read files and have been able to write files from
ange-FTP for the past three months.

However, not all features are complete nor do some follow explicit RFC
directives. For example, I only simulate a Unix file system enough to
make a graphical client happy. The TVFS code simply takes a Unix file
specification and frobinacates it to Tops-20 and vice-versa. Top
level requests "LIST /" and "LIST /FOO" must be simulated by a
baroque combination of GETAB%, MSTR% and RCDIR% and I don't fully
implement all pars-able cases.

At the time, I thought that anybody enlightened enough to use a
character mode client would be enlightened enough to handle Tops-20
file specifications. Since then, I have come to the conclusion that
this is not representative of the current Internet population and
probably never will be. So, I'll need to touch up the top-level
parsing to handle some more cases. For now, Anything that can get
turned into something that GTJFN% will be able to parse
(/DEV/DIR/FILE.TYPE -> DEV:<DIR>FILE.TYPE) is correctly handled.

RFC's and standards are nice, but either they aren't being followed
anymore, nothing is being documented or nobody is doing any regression
testing. Because of this, I have had to see what is going over the
wire in many cases and modify the server to replicate this behavior in
order to get something that works. Where such hackery becomes
particularly onerous, I put in run time configurable parameters to
manage the lossage.

Now on to your questions:

> > The response to PWD is Unixified...
> The response to PWD should be in Unix format, of course,

What's your rational for this opinion? Based on my experience, I
don't know if I would agree. Neither the MVS nor the ITS FTP servers
resond with Unix paths. They use "native" directory paths. Does
anybody know what the VMS FTP or other non-UNix servers do?

Therefore, I thought that if you are not in TVFS mode, that you should
respond with Tops-20 directory and file specification formats. The
latest Tops-20 FTP client knows about PWD and it would appear to be
wrong to have a remote Tops-20 FTP server respond to PWD with
"/PS/FOO" instead of PS:<FOO>.

Of course, when in TVFS mode, I do /PS/FOO or some FTP client breaks
(I forget which).

> but don't bend over backwards too far or pretty soon you'll be
> sending Unix-style "ls -l" listings in response to LIST.

Oh dear, I guess I'm already bent ... When in TVFS mode, STAT, NLST
and LIST will parse for a limited subset of 'ls' switches (-l and -a).
This is because ange-FTP does an "NLST -al" when doing certain things
and will break if you don't handle those switchs. ... Sigh ...

> Out of curiosity, does your server support MLSD?

I know about MLSD, have hooks to implement it and plan to do. It will
be trivial for me, given all of the other nonsense that I have to go
through to handle TVFS directory listings. It's just not on the front
burner because I don't (think that I) have any FTP clients that use
it. Do you have anything that I could test against?

I also have hooks to handle UTF-8 and UTF-9 but I really haven't done
any work on this both because there are some major implementation
issues to be resolved (file name storage) and I've been able to get by
thus far by just handling a normal NVT-ASCII control stream.

> > dates from MDTM are clipped if necessary...
> How can MDTM not include the date?

By "clipped", I mean the dynamic range of Tops-20 dates are reduced
(I.E., "clipped") to fit the Unix time_t type. Tops-20 allows for
dates that have FAR greater dynamic range than what is provided by the
standard (Unix) C library time_t type,viz:

Earliest Latest
======================== ========================
Tops-20: 17-NOV-1858 00:00:00-GMT 7-AUG-2576 23:59:59-GMT
Unix: 13-DEC-1901 20:45:52-GMT 19-JAN-2038 02:14:07-GMT

So, if you get something outside of roughly 1901 or 2038 from Tops-20,
then it clips it to the closest Unix date. I may put in some (run
time configurable) code to NOT clip dates after the year 2038, under
the assumption that, by then, any Unix or Windows client that is using
FTP will have been fixed.

By other responses, I mean that the modification times of directories
and directory files under Tops-20 are handled differently because
Tops-20 does not consistently update the write time of the directory
file nor does it store the last write time in the directory itself.
The extended mode FTP server implements a solution as follows:

1) MDTM will parse for a directory specification. If one is
recognized, the MDTM will return the last login time of
the directory.

This number may have no meaning for FILES-ONLY directories,
which do not allow login nor for a non-LOGIN structure. If
this is the case, then MDTM will report the actual last write
time of the directory file which is essentially the creation
time of the directory.

2) If MDTM determines (via inspecting the FDB) that the file in
question is a directory file, it will construct a
sub-directory specification and return the same result as for
#1 (a directory parse).

3) If the requested directory in question is ROOT-DIRECTORY, then
MDTM will report the boot time of the system.

> > ...the SIZE byte count is clipped to 31 bits and, for ASCII files...
> What if the file is bigger than that? (Can that happen in TOPS-20?)

Sure it can, but probably only in pathological cases.

The maximum number of bytes that a Tops-20 file can 'truthfully'
report is derived from the following calculation: assuming a file with
a byte size of 1, then 36 bits times 512 words per page times 512
pages per normal file times 512 'sections' per long file equals
4,831,838,208 one bit bytes. This is not a negative number, but since
the .FBSIZ field can be set to an arbitrary value by the programmer, I
clip anything higher and any negative number to the maxmimum (I.E.,
INFIN).

Again, note that Tops-20 stores the byte count in an UNsigned 36 bit
word. This has a dynamic range of 4 and half bits greater than many
implementations of long in the C libary, which typically use a 32 bit
SIGNED long (is this true on 64 bit platforms?). Thus, when the
server is running in TVS mode, I clip any numbers that are larger than
2,147,483,647 to 2,147,483,647

> As you know, I've put some time in to make C-Kermit -- including its
> FTP client -- handle "large files" (63-bit sizes). Unfortunately I
> haven't yet found a single server that does this too without major
> screwups, except (can you guess?)... the Tru64 Unix FTP server.

Try my new server when I have an alpha candidate up. The file sizes
aren't as large as 63 bits, but they're still flavorful.

As you might guess, having all of this anti-mis-featurization code
results in a great deal of extra special case code and just plain
code. The new server needs a minimum of 69 pages to load as compared
to 24 pages for the BBN server. With the built-in help it's 161
pages. With the built-in help and symbol table, it wants 203 pages.

A comparison of the source sizes is also instructive. The BBN server
is 95 pages of source code

Module Pages Bytes (7) Percent Purpose
========== ===== ========= ======= ==========
TCPSIM.MAC 11 28,035 11 TCP transport (JCN management)
FTPSER.MAC 82 209,813 86 RFC959 implementation
TCPUNV.MAC 2 2704 2 Transport externals

This should be compared to the 456 pages of Tops-20 extended mode FTP
source code which breaks out roughly as follows:

Module Pages Bytes (7) Percent Purpose
========== ===== ========= ======= ==========
EFTPSA.MAC 43 108,883 9 Auxiliary helpers
EFTPSC.MAC 57 143,565 12 Data conversion
EFTPSH.MAC 88 223,718 19 Built-In Online Help
EFTPSR.MAC 68 171,813 14 RFC959 parser
EFTPSS.MAC 61 155,201 13 Tops-20 SITE specific
EFTPST.MAC 61 153,847 13 TCP/IP transport (data fork)
EFTPSU.MAC 17 41,579 3 Assembly, Link and globals
EFTPSV.MAC 58 147,830 12 TVFS (Unix)
EFTPSZ.MAC 3 6,060 .6 .PSECT and global address fixup

Note that this does not include MRC's winning GETCPU and HSTNAM
modules which I also use.

There is undoubtedly a certain amount of second system effect, also.
Sometimes if I bumped into something I thought was interesting, I just
went ahead and implemented it. For example, the BBN server does
nothing with ALLO other than saying that you don't need to use it.
This is because ALLO is apparently only necessary when you are talking
to an MVS system.

The new FTP server uses the supplied arguments to ALLO to check
against structure remaining space, working and directory usage and
quotas. Maybe I'll have the Tops-20 client use this at some point,
but for now it's just really fluff.

I really have to laugh when I remember the Internet implementation
compatibility 'bake-offs' of yore. Now it would just seem to be a
horse race to see which FTP server could understand the nits of the
FTP client using it. Exactly the situation RFC959 was supposed to
prevent. Or maybe I should just break down and cry. Sigh.

Finally, the responses to L7 have been interesting, but not for the
reasons that I originally posted. I've been doing some thinking about
this and will reply further, later.

--T
25-Aug-2006 22:55:49-PDT,4269;000000000000
Return-Path: <[email protected]>
Received: from pangtzu.panda.com ([206.124.149.117]) by lingling.panda.com with TCP/SMTP; Fri, 25 Aug 2006 22:54:01 -0700 (PDT)
X-Return-Path: <[email protected]>
X-Received: from mta6.srv.hcvlny.cv.net ([167.206.4.201]) by lingling.panda.com with TCP/SMTP; Fri, 25 Aug 2006 19:06:39 -0700 (PDT)
X-Received: from optonline.net (hamstr3.srv.hcvlny.cv.net [167.206.5.10])
by mta6.srv.hcvlny.cv.net
(Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006))
with ESMTP id <[email protected]>; Fri,
25 Aug 2006 22:06:29 -0400 (EDT)
X-Received: from [10.240.3.199] (Forwarded-For: [10.240.3.199])
by mstr3.srv.hcvlny.cv.net (mshttpd); Sat, 26 Aug 2006 02:06:28 +0000 (GMT)
Date: Sat, 26 Aug 2006 02:06:28 +0000 (GMT)
From: [email protected]
Subject: Re: ASCII wire efficient and proposed TYPE L 7 RFC
In-reply-to: <CMM.0.90.4.1156217322.billw@pita>
To: William Chops Westfield <[email protected]>
Cc: TOPS-20 List Moderator <[email protected]>, [email protected]
Message-id: <[email protected]>
MIME-version: 1.0
X-Mailer: Sun Java(tm) System Messenger Express 6.2-6.01 (built Apr 3 2006)
Content-type: text/plain; charset=us-ascii
Content-language: en
Content-transfer-encoding: 7BIT
Content-disposition: inline
X-Accept-Language: en
Priority: normal
References: "19 Aug 2006 17:38:19 +0000" <CMM.0.90.4.1156217322.billw@pita>
ReSent-Date: Fri, 25 Aug 2006 22:53:44 -0700 (PDT)
ReSent-From: TOPS-20 List Moderator <[email protected]>
ReSent-To: TOPS-20 Distribution: ;
ReSent-Subject: Re: ASCII wire efficient and proposed TYPE L 7 RFC
ReSent-Message-ID: <[email protected]>

> There's a unix (?) ftp hack that automatically gzips the file on
> transmit and g-unzips it on reception. If you really want to
> conserve bandwidth, that'll save you a lot more than one bit of
> 8 ...

Yup, it sure would! I did an experimental L 7 pack to 8 bit with a
rather large ASCII file: PS:<DOCUMENTATION>JSYS_REFERENCE.MEM which is
1,794,319 7 bit bytes or 12,560,233 bits total. The resulting 8 bit
stream is 1,570,030 bytes, about 13% decrease in the byte count.
However, gzip scrunched this to 694,374 bytes; about a 56% decrease in
size.

For the same file transfered as ASCII, the results are even better.
The transfered file is 1,794,319 8 bit bytes or 14,354,552 bits, about
15% increase as expected. This time however, gzip does an even better
job, probably because it now recognizes the file as text. The file is
scruched by 77.5% to 394,594 bytes. Not bad.

However, I don't know if I'll ever do this.

First, I would need to port gzip to the 20, which might be problematic
for KCC (I'm not saying it would be, just might). GCC might be more
straightforward, but I have no experience with this on the 20 platform
(although I have used it under Debian and elsewhere). I'd also need
to figure out how I'd hook gzip into the data stream. One way might
be to use temporary files, but I then I might bump into working quota
limits.

Another obvious approach would be to use Tops-20 pipes, but I have run
into problems with them under PANDA (they seem to work better for what
I was doing under XKL). I haven't said anything about it, yet,
because I haven't had time to chase this down, being more occupied
with trying to get the extended FTP server out the door (it's been two
years, after all).

Use of gzip could also possibly incur (a substantial) increase in CPU
usage and that might slow down the system enough to make using it not
worth it. L7, on the other hand, can be very cheaply implemented. It
would be on the same order of efficiency as L 36 (or PDP-10 TYPE I)
which is not that bad (as compaged to using straight extended string
instructions).

Finally, given the 'viral' nature of gnu software, I'm not sure that I
would want to use gzip, anyway. MRC doesn't include any gnu licensed
software in the PANDA distribution because of this and, in this
regard, I am very much inclined to agree with him. It is possible
that I could implement Lempel-Ziv (in assembly), but I don't know
anything more about that at this point.

25-Aug-2006 22:57:03-PDT,9053;000000000000
Return-Path: <[email protected]>
Received: from pangtzu.panda.com ([206.124.149.117]) by lingling.panda.com with TCP/SMTP; Fri, 25 Aug 2006 22:54:27 -0700 (PDT)
X-Return-Path: <[email protected]>
X-Received: from mta9.srv.hcvlny.cv.net ([167.206.4.204]) by lingling.panda.com with TCP/SMTP; Fri, 25 Aug 2006 19:13:41 -0700 (PDT)
X-Received: from optonline.net (hamstr3.srv.hcvlny.cv.net [167.206.5.10])
by mta9.srv.hcvlny.cv.net
(Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006))
with ESMTP id <[email protected]>; Fri,
25 Aug 2006 22:13:02 -0400 (EDT)
X-Received: from [10.240.3.199] (Forwarded-For: [10.240.3.199])
by mstr3.srv.hcvlny.cv.net (mshttpd); Sat, 26 Aug 2006 02:13:32 +0000 (GMT)
Date: Sat, 26 Aug 2006 02:13:32 +0000 (GMT)
From: [email protected]
Subject: Re: ASCII wire efficient and proposed TYPE L 7 RFC
In-reply-to: <[email protected]>
To: Mark Crispin <[email protected]>
Cc: William Chops Westfield <[email protected]>,
TOPS-20 Hackers and Yackers <[email protected]>
Message-id: <[email protected]>
MIME-version: 1.0
X-Mailer: Sun Java(tm) System Messenger Express 6.2-6.01 (built Apr 3 2006)
Content-type: text/plain; charset=us-ascii
Content-language: en
Content-transfer-encoding: 7BIT
Content-disposition: inline
X-Accept-Language: en
Priority: normal
References: <CMM.0.90.4.1156217322.billw@pita>
<[email protected]>
ReSent-Date: Fri, 25 Aug 2006 22:54:11 -0700 (PDT)
ReSent-From: TOPS-20 List Moderator <[email protected]>
ReSent-To: TOPS-20 Distribution: ;
ReSent-Subject: Re: ASCII wire efficient and proposed TYPE L 7 RFC
ReSent-Message-ID: <[email protected]>

> For text files, you are stuck with the waste of one bit of 8 going
> to UNIX and other byte-oriented systems. They aren't going to
> change to accomodate us. Furthermore, you have to use TYPE A with
> UNIX systems since they need to convert newlines.

Yup, the FTP clients would need to be educated. But since we maintain
the Tops-20 FTP client and servers, it might be a reasonable win (but
see below). Also, there is nothing stopping us from enlightening an
open source FTP client. Finally, the 14% speed improvement might just
get them to adopt the format. Or not. .... Sigh ....

> However, for PDP-10s, you wouldn't use TYPE A or any form of 8-bit
> transfer for text files! When transferring files of any type to a
> Tenex or TOPS-20 system, you'll use paged transfers.

I'm not sure that I would agree with you. Based on my current
understanding of the paged file structure, I think a good case could
be made that it's a loser as compared to TYPE I all around, unless you
are sending either sending files with zeros at the end of the page or
files with holes in them.

With respect to computational efficiency, the current BBN server page
structure code is doing an RPACS% on EVERY single page it sends. It
also does a reverse scan of the page to see if it can clip zeros from
the end. Then it's got to put a header on each transmitted page
(which may or may not have the actual page protections). The extra
JSYS per page is a fair amount of overhead, if my experience with
large buffer sizes is any indication.

It may be possible, however, to get around the JSYS overhead by using
an XRMAP%, but you still have to grunt over all of the information and
shove headers around. In any case, the reciever still has to
investigate the header in order to figure out what to do with the page
(even if it is nothing). It then has to do something about taking
care of clipped zeros.

Then, at the end of the file, the entire FDB is shipped over along
with user strings and and date and times converted to text, so that's
even more bits on the wire in addition to bit 35 which may not have
anything of interest. For fairly short files, even ASCII (TYPE A)
might blow paged structures out of the water for bits sent and CPU
time used. TYPE I (L 36) would win for longer files.

The CPU time and wire utilisation are not to be sneezed at, even for
long listings. What is all the processing and extra wire bits buying
you?

However, since none of this is really documented, I may be
wrong. I'll know more once I implement it myself and do regression
testing.

> For ITS, TOPS-10, and WAITS systems, you'll use 36-bit image
> transfers.

We have the source to the ITS FTPU.MID (FTP client) and FTPS.MID (FTP
server) and there is nothing stopping us (besides time) from
'enlightening them'. Ditto WAITS. Or not. I really only care about
the majority of the intended transfers: 20 <-> 20, 20 <-> Windows and
20 <-> Unix. For other systems, I only care about passing regression
tests or fixing stuff that was (unknowingly?) broken.

> So, there is only one "wasted" bit per 36 bits, not 8, in a transfer
> between PDP-10 systems. However, it's not really wasted; the bit is
> significant. When reading text files, that bit being set indicates
> that the entire word is a line number (for editors such as SOS) and
> thus is disregarded when reading the file as pure text.

Oh, I think it is perfectly well wasted if you are doing a file
without LSNs. That is the majority of what I'm doing. It is possible
to detect LSNs at least as well as the monitor does, so why bother
sending the empty bits if there are no LSN's?

Open source implementations of FTP clients also exist and I think that
the 14% is definately worth it. With regard to handling (the losing
bogus mis-featured) LSNs in some files, I don't see why I can't do
what the monitor does:

1) Check the opened byte size of the file. If it's 7 bits, then
check for LSNs, otherwise, not.

2) Either,

a) On the first read of the first byte in the file, check bit 35
of the first (36) word or
b) On the first read of the byte positioned to by an SFPTR% (and
maybe RIN%), check bit 35 of the word containing the byte.

If an LSN is detected, then use them, otherwise don't (and set some
flags, PASLSN and maybe SKIPBY). From IO.MAC, a few lines after
BYTIA2, one sees the following:

;POSSIBLE LINE NUMBER. LET'S ALSO CHECK TO SEE IF WE ARE ON THE FIRST WORD
;OF THE FILE AND IT IT ISN'T A LINE #, THEN SET PASLSN TO SPEED THINGS UP
;IN THE FUTURE

HRRZ A,FILBYT(JFN) ;GET THE WORD WE GOT THE CHARACTER FROM
MOVE A,0(A) ;DO INDIRECT
TXNN A,1B35 ;BIT 35 ON? IF SO, CALL IT A LINE #

So, I don't see why I couldn't do this. The FTP client can check the
LSN status on server when doing a RETR and elect not to do an L 7.
Likewise it can check for LSNs before doing a STOR and still do the
right thing. Given that the Tops-20 FTP client is already doing some
special things when talking to a 20 (paged file structures and special
directory listings), I think this would be perfectly reasonable
behavior.

However, I didn't seen an 'LSN' bit in the FDB and one wonders why
they didn't define one (did they?). That could make the check
(actually avoiding it) definitive. I mean, they've got stuff in the
for all sorts of arcania (RMS files, etc), so why not?

> Of course, this depends upon knowing what OS is on the other system.
> Sadly, this depends upon the host table or the DNS to provide that
> information, rather than being negotiated in FTP. This isn't good;
> I can't get my own DNS provider to include HINFO records in the DNS
> records of my TOPS-20 systems because they think that HINFO is a
> "security hole".

That is, if you can trust the DNS to have the right thing. As you
know, it doesn't always do this (particularly if you are using NAT'ed
hosts). As above, SYST can't be depended on because of TVFS
operation. The only safe thing to do is use RFC2389 and do a FEAT.
If that doesn't tell you the answer, then you've got to do the
previous and also:

> However, I think that it is a safe bet that a server that accepts
> TYPE L 36 is a PDP-10, and a server that accepts STRU P is a Tenex
> or TOPS-20.

I tested this on Windows 2000 Server, SCO, Debian and Mac OSX. None
of them accepted a TYPE L 36 (they only handled L 8). None of them
would accept STRU P, either (or anything else but STRU F), so that's
probably good.

However, what about other 36 bit systems?

The Honeywell G635 processor is 36 bits. Multics used this, but I
don't think there are any more Multics machines on the Internet (are
there?). DTSS (Dartmouth) also ran on a G635 and I know that there
has been some work on resurrecting this, but I don't remember if it
ever did anything Internet'ish.

TYPE L 36 and STRU P are a definitive combination for Tops-20 and
Tenex (are there any flavors of Tenex floating around?). TYPE L 36
would appear to be an extremely good heuristic for assuming a PDP-10,
but at least at one point, I don't believe that it would have been
definitive.

25-Aug-2006 22:58:30-PDT,5098;000000000000
Return-Path: <[email protected]>
Received: from pangtzu.panda.com ([206.124.149.117]) by lingling.panda.com with TCP/SMTP; Fri, 25 Aug 2006 22:55:00 -0700 (PDT)
X-Return-Path: <[email protected]>
X-Received: from mta5.srv.hcvlny.cv.net ([167.206.4.200]) by lingling.panda.com with TCP/SMTP; Fri, 25 Aug 2006 19:16:00 -0700 (PDT)
X-Received: from optonline.net (hamstr3.srv.hcvlny.cv.net [167.206.5.10])
by mta5.srv.hcvlny.cv.net
(Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006))
with ESMTP id <[email protected]>; Fri,
25 Aug 2006 22:15:58 -0400 (EDT)
X-Received: from [10.240.3.199] (Forwarded-For: [10.240.3.199])
by mstr3.srv.hcvlny.cv.net (mshttpd); Sat, 26 Aug 2006 02:15:53 +0000 (GMT)
Date: Sat, 26 Aug 2006 02:15:53 +0000 (GMT)
From: [email protected]
Subject: Re: ASCII wire efficient and proposed TYPE L 7 RFC
In-reply-to: <[email protected]>
To: Mark Crispin <[email protected]>
Cc: TOPS-20 Hackers and Yackers <[email protected]>
Message-id: <[email protected]>
MIME-version: 1.0
X-Mailer: Sun Java(tm) System Messenger Express 6.2-6.01 (built Apr 3 2006)
Content-type: text/plain; charset=us-ascii
Content-language: en
Content-transfer-encoding: 7BIT
Content-disposition: inline
X-Accept-Language: en
Priority: normal
References: <CMM.0.90.4.1156217322.billw@pita>
<[email protected]>
ReSent-Date: Fri, 25 Aug 2006 22:54:52 -0700 (PDT)
ReSent-From: TOPS-20 List Moderator <[email protected]>
ReSent-To: TOPS-20 Distribution: ;
ReSent-Subject: Re: ASCII wire efficient and proposed TYPE L 7 RFC
ReSent-Message-ID: <[email protected]>

Folks,

I've read over all the comments to my original posting (thanks!) and
I've got a couple responses for a few things. First, I'd like clarify
a few things.

L7 is simply a mechanism to put less bits on the wire for NVT ASCII
files. Examples of such files are simple text and many, many source
files for various compilers and assemblers. Since this is the
majority of what I use the 20 for, I was interested in seeing if I
could 'cheaply' speed up the transfers (see below for what I think
cheap means).

L7 would not and could not be used for 'native' eight bit files. By
definition, these have all bits in use and I couldn't do any
stripping. The whole idea of UTF-8, etc., is moot. I wouldn't use L7
for these files.

Clients are expected to be 'enlightened' enough to use L7 both in
terms of what goes over the wire and when to use it. With respect to
the wire capability, one of the things that the new server does (which
the old server does not) is implement RFC2389, which is a
specification for "Feature negotiation mechanism for the File Transfer
Protocol".

The whole purpose of this is to have the server report about the
features that it has instead of having the client try to discover
them. This is particularly important given that, when running in TVFS
mode, the new server will lie when given a response to SYST: it says
that it is "UNIX Type: L8" of "TOPS20". Other responses are changed,
also.

The extended server has to lie about being a Unix box or certain
unmentionable graphical clients will immediately disconnect and refuse
to inter-operate (sigh). Given that TVFS mode must come on
automatically in response to Unix file paths or may even be forced by
system EFTPSR.CMD or user EFTPSR.CMD files, being told by the response
to FEAT is the only reliable way to know that you're talking to a 20.

In particular, the current Tops-20 FTP client tries to determine that
it is talking to a 20 by querying the DNS which doesn't always work.
It can also try doing a SYST, but not all Tops-20 FTP servers (I.E.,
the default BBN version) implement SYST. The current Toad version
implements SYST, but doesn't report it in the help list. Even then,
however, the extended mode FTP server still has to lie anyway (see
above).

Thus, the only definitive way to know whether you're talking to a 20
is to not try to discover this to begin with and do what RFC2389 is
designed for: issue a FEAT and parse for the keywords that you are
interested in. The current response from the extended server for FEAT
is SIZE, MDTM, TOPS20, EPRT and EPSV.

You have to have SIZE and MDTM (which the default BBN server and
current Toad FTP server don't have) to use gnuEmacs ange-ftp mode.
EPRT and EPSV are useful to talk to the Mac OSX ftp client which also
wants to use SIZE.

So, the Tops-20 FTP client is going to be changed to first try FEAT,
then try SYST and then use the DNS. I'm using the DNS last because
that is potentially the slowest. The FTP server will also report L7
as a feature so that clients will know to use it. My intention is to
change the Tops-20 FTP server to check for this (and correctly
implement it, if necessary) so that I can bum the extra bit in every
word. Hey 3% is 3% ... It's worth it to me on my cellphone.

25-Aug-2006 22:59:22-PDT,6300;000000000000
Return-Path: <[email protected]>
Received: from pangtzu.panda.com ([206.124.149.117]) by lingling.panda.com with TCP/SMTP; Fri, 25 Aug 2006 22:55:18 -0700 (PDT)
X-Return-Path: <[email protected]>
X-Received: from mta7.srv.hcvlny.cv.net ([167.206.4.202]) by lingling.panda.com with TCP/SMTP; Fri, 25 Aug 2006 19:17:52 -0700 (PDT)
X-Received: from optonline.net (hamstr3.srv.hcvlny.cv.net [167.206.5.10])
by mta7.srv.hcvlny.cv.net
(Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006))
with ESMTP id <[email protected]>; Fri,
25 Aug 2006 22:17:46 -0400 (EDT)
X-Received: from [10.240.3.199] (Forwarded-For: [10.240.3.199])
by mstr3.srv.hcvlny.cv.net (mshttpd); Sat, 26 Aug 2006 02:17:45 +0000 (GMT)
Date: Sat, 26 Aug 2006 02:17:45 +0000 (GMT)
From: [email protected]
Subject: Re: ASCII wire efficient and proposed TYPE L 7 RFC
In-reply-to: <[email protected]>
To: Mark Crispin <[email protected]>
Cc: TOPS-20 Hackers and Yackers <[email protected]>
Message-id: <[email protected]>
MIME-version: 1.0
X-Mailer: Sun Java(tm) System Messenger Express 6.2-6.01 (built Apr 3 2006)
Content-type: text/plain; charset=us-ascii
Content-language: en
Content-transfer-encoding: 7BIT
Content-disposition: inline
X-Accept-Language: en
Priority: normal
References: <CMM.0.90.4.1156217322.billw@pita>
<[email protected]>
ReSent-Date: Fri, 25 Aug 2006 22:55:11 -0700 (PDT)
ReSent-From: TOPS-20 List Moderator <[email protected]>
ReSent-To: TOPS-20 Distribution: ;
ReSent-Subject: Re: ASCII wire efficient and proposed TYPE L 7 RFC
ReSent-Message-ID: <[email protected]>

> IMHO, the most important use for TYPE A is to interchange text files
> between PDP-10 and UNIX systems. This is because TYPE A turns on
> newline conversion on the UNIX system.

Yup. I also seem to remember using TYPE A to send files to our EBCDIC
based systems. I did this because I was also the maintainer of IBMSPL
and the DN60 front end code at Columbia, but I don't remember much
about any of it at this point.

> A secondary use is to interchange text files between PDP-10 and
> Windows systems; but this is only because TOPS-20 does not support
> 8-bit bytesize text files well. If we supported 8-bit bytesize text
> files better, there would be no need for this.

Right now, the extended Tops-20 FTP server uses a heuristic to handle
8 bit files coming from from the Windows Explorer. In particular, it
has a pretty good idea of how figure out what to send when doing a
RETR and can guess fairly well when doing a STOR to a non-existing
file. I use this to store .JPGs, .MP3s and text files. I can double
click on them in Windows and the right thing always happens (thus
far).

> The problem is that almost all TOPS-20 that deals with text files
> ignores the file bytesize. Instead, it just opens the file in 7-bit
> mode. This is compounded by the fact that the operating system
> *also* ignores the file bytesize on open; it uses the bytesize
> supplied by the user and reads/writes successive bytes of that size
> left-adjusted in 36-bit words.

See above; if I do the same thing that the monitor does, I think I
would be safe with LSNs. It may also be possible to use a heuristic
to determine what to do with PA1050 output (like MACRO listings, etc).
The monitor may not exactly respect byte sizes, but I do, so I'm
pretty much always getting the right thing. The only place where I
guess is when I'm doing TVFS to send a 36 bit file.

In that case, I go under the assumption that no right thinking (or
wrong headed) Unix or Windows client is ever going to want 36 bit
files and send it as 7 bit bytes. I suppose I should check bit 35 to
get it more right in case some wiseguy tries to RETR an .EXE file,
but, thus far, I haven't gotten bitten by anything.

> Ideally, user software would use the file bytesize for the open mode
> and the I/O pointer; and the operating system would recognize
> mismatches and do the adjustment (e.g., the 7 least-significant bits
> in each 8-bit byte). But it doesn't and it doesn't.

Yes, but I do.

> This is all understandable, given the heritage from TOPS-10. In
> TOPS-10, all files have a 36-bit bytesize. So TOPS-10 software
> running on TOPS-20 always reads/writes 36-bit bytes and for text
> just does the familiar packing of 5 7-bit bytes left-adjusted in the
> word.

It is the intention of the new server to exploit features that don't
exist in other 36 bit operating systems. In that vein, I'm simply
going to dis-inherit Tenex and Tops-10 since the former's FTP client
will never ask for L7 and the later's FTP implementation appears to be
lost. Even if it were to be resurrected, the FTP client still
wouldn't ask for L7 as well as FTPU (the ITS client).

The heuristic of sending 36 bit files (PA1050) as ASCII when in TVFS
mode (see above) has worked well enough for me for about a year.

> Less ambitious would be EXEC hacks, such as fixing the TYPE command
> to recognize file byte sizes, so you could do TYPE FOO.TXT for an
> 8-bit file instead of COPY FOO.TXT TTY:, with a subcommand of BYTE
> 8. But it hardly seemed worth it unless applications were also
> fixed.

Yes. Perhaps the Exec should be changed to respect 8 bit when doing a
display on the terminal. Then again, that would really be bad for
JPG's and .MP3's (see above). EMACS would need some hacking also
(?). However, thus far, the heuristics that I have largely do a VERY
good job of guessing ASCII and inserting and stripping line feeds.

> I think about this from time to time, since I want to support UTF-9
> text files in TOPS-20. But that's an even more daunting task.

One of the goals for the parsing logic in the new server was to handle
UTF-9 by enabling intermediate code to hack the control byte stream.
However, I don't have an informed opinion about how to actually handle
this. The hooks are there, though. However, this is the 'only' thing
that keeps me from reporting TVFS in the FEAT list, which the Windows
Explorer specifically looks for. Maybe version 2 ....

25-Aug-2006 23:00:54-PDT,3529;000000000000
Return-Path: <[email protected]>
Received: from pangtzu.panda.com ([206.124.149.117]) by lingling.panda.com with TCP/SMTP; Fri, 25 Aug 2006 22:55:48 -0700 (PDT)
X-Return-Path: <[email protected]>
X-Received: from mta8.srv.hcvlny.cv.net ([167.206.4.203]) by lingling.panda.com with TCP/SMTP; Fri, 25 Aug 2006 19:19:54 -0700 (PDT)
X-Received: from optonline.net (hamstr3.srv.hcvlny.cv.net [167.206.5.10])
by mta8.srv.hcvlny.cv.net
(Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006))
with ESMTP id <[email protected]> for
[email protected]; Fri, 25 Aug 2006 22:18:34 -0400 (EDT)
X-Received: from [10.240.3.199] (Forwarded-For: [10.240.3.199])
by mstr3.srv.hcvlny.cv.net (mshttpd); Sat, 26 Aug 2006 02:19:47 +0000 (GMT)
Date: Sat, 26 Aug 2006 02:19:47 +0000 (GMT)
From: [email protected]
Subject: Re: ASCII wire efficient and proposed TYPE L 7 RFC
In-reply-to: <[email protected]>
To: Frank da Cruz <[email protected]>
Cc: [email protected]
Message-id: <[email protected]>
MIME-version: 1.0
X-Mailer: Sun Java(tm) System Messenger Express 6.2-6.01 (built Apr 3 2006)
Content-type: text/plain; charset=us-ascii
Content-language: en
Content-transfer-encoding: 7BIT
Content-disposition: inline
X-Accept-Language: en
Priority: normal
References: <[email protected]>
<[email protected]>
ReSent-Date: Fri, 25 Aug 2006 22:55:23 -0700 (PDT)
ReSent-From: TOPS-20 List Moderator <[email protected]>
ReSent-To: TOPS-20 Distribution: ;
ReSent-Subject: Re: ASCII wire efficient and proposed TYPE L 7 RFC
ReSent-Message-ID: <[email protected]>

> But in real life, at least outside the USA, many files use 8-bit text
> encodings such as ISO 8859.

Yup, but the point is that Tops-20 uses *a lot of* 7 bit ASCII which
is what L7 cares about. I'd also claim that there is still a lot of
ASCII files on Unix boxes in the form of source code.

However, I'd need to handle an 8 bit stream and perhaps change the
heuristics again. One really good way to guess would be to see if the
remote client asks for UTF-8 (which it has to do). The Windows
Explorer client does this. If that were the case, then I would skip
using L7. But then again, it's the client's job to decide whether to
use L7.

> Even leaving aside languages that use characters outside of ASCII,
> you still have Microsoft to deal with. When you create text with a
> Microsoft application, it changes all your ASCII quotes and
> apostrophes and hyphens into godawful "smart quotes" and en-dashes
> and em-dashes, which it puts in the C1 area (8th bit on). You don't
> even know this is happening until it is too late.

At least the Explorer asks for UTF-8 before it starts messing around.
I don't know if there are other cretinous implementations that simply
shove 8 bit code over the link. Right now, I'm already doing a MOVST
to handle 'translations' of 8 bit ASCII files. One assumes that I
could change this to handle the setting of the eigth bit and (somehow)
do the right thing.

> Any marginal benefits derived from TYPE L 7 would be offset by all
> the screwups and do-overs it could cause.

14% on a slow line isn't exactly marginal. Also, only 'enlighted'
clients would ask for it. I don't know if I could make the same case
for 3%, but when using my cellphone or other dial up, I'll take it.

25-Aug-2006 23:02:17-PDT,2462;000000000000
Return-Path: <[email protected]>
Received: from pangtzu.panda.com ([206.124.149.117]) by lingling.panda.com with TCP/SMTP; Fri, 25 Aug 2006 22:56:07 -0700 (PDT)
X-Return-Path: <[email protected]>
X-Received: from mta1.srv.hcvlny.cv.net ([167.206.4.196]) by lingling.panda.com with TCP/SMTP; Fri, 25 Aug 2006 19:21:10 -0700 (PDT)
X-Received: from optonline.net (hamstr3.srv.hcvlny.cv.net [167.206.5.10])
by mta1.srv.hcvlny.cv.net
(Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006))
with ESMTP id <[email protected]>; Fri,
25 Aug 2006 22:22:17 -0400 (EDT)
X-Received: from [10.240.3.199] (Forwarded-For: [10.240.3.199])
by mstr3.srv.hcvlny.cv.net (mshttpd); Sat, 26 Aug 2006 02:21:03 +0000 (GMT)
Date: Sat, 26 Aug 2006 02:21:03 +0000 (GMT)
From: [email protected]
Subject: Re: ASCII wire efficient and proposed TYPE L 7 RFC
In-reply-to: <[email protected]>
To: Mark Crispin <[email protected]>
Cc: [email protected]
Message-id: <[email protected]>
MIME-version: 1.0
X-Mailer: Sun Java(tm) System Messenger Express 6.2-6.01 (built Apr 3 2006)
Content-type: text/plain; charset=us-ascii
Content-language: en
Content-transfer-encoding: 7BIT
Content-disposition: inline
X-Accept-Language: en
Priority: normal
References: <[email protected]>
<[email protected]> <[email protected]>
ReSent-Date: Fri, 25 Aug 2006 22:55:55 -0700 (PDT)
ReSent-From: TOPS-20 List Moderator <[email protected]>
ReSent-To: TOPS-20 Distribution: ;
ReSent-Subject: Re: ASCII wire efficient and proposed TYPE L 7 RFC
ReSent-Message-ID: <[email protected]>

> IMHO, 8-bit formats have been hopelessly poisoned by the long
> history of misuse. We really need UTF-9 and UTF-18. UTF-18 is
> particularly attractive since it is almost a UCS, and it is
> extremely unlikely that Unicode will assign codepoints outside of
> the space covered by UTF-18 in our lifetimes.

The only implementation remark that I have about anything to do with
UTF-9 is that MOVST could probably be used to productively move
strings, breaking on certain 'tag' characters. Then again, this would
require the use of 256 word tables, so maybe there would be memory
utilization issues. MOVST couldn't handle UTF-18 at all because the
largest byte size it handles is 12 bits.

25-Aug-2006 23:03:41-PDT,2414;000000000000
Return-Path: <[email protected]>
Received: from pangtzu.panda.com ([206.124.149.117]) by lingling.panda.com with TCP/SMTP; Fri, 25 Aug 2006 22:56:29 -0700 (PDT)
X-Return-Path: <[email protected]>
X-Received: from mta7.srv.hcvlny.cv.net ([167.206.4.202]) by lingling.panda.com with TCP/SMTP; Fri, 25 Aug 2006 19:22:05 -0700 (PDT)
X-Received: from optonline.net (hamstr3.srv.hcvlny.cv.net [167.206.5.10])
by mta7.srv.hcvlny.cv.net
(Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006))
with ESMTP id <[email protected]> for
[email protected]; Fri, 25 Aug 2006 22:21:59 -0400 (EDT)
X-Received: from [10.240.3.199] (Forwarded-For: [10.240.3.199])
by mstr3.srv.hcvlny.cv.net (mshttpd); Sat, 26 Aug 2006 02:21:58 +0000 (GMT)
Date: Sat, 26 Aug 2006 02:21:58 +0000 (GMT)
From: [email protected]
Subject: Re: ASCII wire efficient and proposed TYPE L 7 RFC
In-reply-to: <[email protected]>
To: Frank da Cruz <[email protected]>
Cc: [email protected]
Message-id: <[email protected]>
MIME-version: 1.0
X-Mailer: Sun Java(tm) System Messenger Express 6.2-6.01 (built Apr 3 2006)
Content-type: text/plain; charset=us-ascii
Content-language: en
Content-transfer-encoding: 7BIT
Content-disposition: inline
X-Accept-Language: en
Priority: normal
References: <[email protected]>
<[email protected]>
ReSent-Date: Fri, 25 Aug 2006 22:56:21 -0700 (PDT)
ReSent-From: TOPS-20 List Moderator <[email protected]>
ReSent-To: TOPS-20 Distribution: ;
ReSent-Subject: Re: ASCII wire efficient and proposed TYPE L 7 RFC
ReSent-Message-ID: <[email protected]>

> Well, as the activity on this list rises almost to its former
> levels, maybe the DEC-20 will once again become an important enough
> platform for the UTC to consider these on some day other than April
> 1st! We like the -20 because it's cool, but the trick is to create
> some application that the world will crave, that is only practical
> on this architecture, so there will be some popular support. Maybe
> something that massively uses variable-length bytes!

Indeed, nothing could possibly make me happier. Then I'd have a
realistic chance of actually getting PAID to hack one again (JOY!)
instead of just indulging a hobby.

25-Aug-2006 23:05:23-PDT,2960;000000000000
Return-Path: <[email protected]>
Received: from pangtzu.panda.com ([206.124.149.117]) by lingling.panda.com with TCP/SMTP; Fri, 25 Aug 2006 22:57:02 -0700 (PDT)
X-Return-Path: <[email protected]>
X-Received: from mta3.srv.hcvlny.cv.net ([167.206.4.198]) by lingling.panda.com with TCP/SMTP; Fri, 25 Aug 2006 19:23:07 -0700 (PDT)
X-Received: from optonline.net (hamstr3.srv.hcvlny.cv.net [167.206.5.10])
by mta3.srv.hcvlny.cv.net
(Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006))
with ESMTP id <[email protected]>; Fri,
25 Aug 2006 22:23:01 -0400 (EDT)
X-Received: from [10.240.3.199] (Forwarded-For: [10.240.3.199])
by mstr3.srv.hcvlny.cv.net (mshttpd); Sat, 26 Aug 2006 02:23:01 +0000 (GMT)
Date: Sat, 26 Aug 2006 02:23:01 +0000 (GMT)
From: [email protected]
Subject: Re: ASCII wire efficient and proposed TYPE L 7 RFC
In-reply-to: <[email protected]>
To: Mark Crispin <[email protected]>
Cc: [email protected]
Message-id: <[email protected]>
MIME-version: 1.0
X-Mailer: Sun Java(tm) System Messenger Express 6.2-6.01 (built Apr 3 2006)
Content-type: text/plain; charset=us-ascii
Content-language: en
Content-transfer-encoding: 7BIT
Content-disposition: inline
X-Accept-Language: en
Priority: normal
References: <[email protected]>
<[email protected]> <[email protected]>
ReSent-Date: Fri, 25 Aug 2006 22:56:44 -0700 (PDT)
ReSent-From: TOPS-20 List Moderator <[email protected]>
ReSent-To: TOPS-20 Distribution: ;
ReSent-Subject: Re: ASCII wire efficient and proposed TYPE L 7 RFC
ReSent-Message-ID: <[email protected]>

> Right, and the Fifth-Generation Computing Project which was going to
> save the world for AI and the Prolog programming language. It gave
> a new meaning to the term "abject failure"...

I'm always reminded of a remark that McCarthy (?) makes on his web
site with respect to AI. He believes that machines of the 1960's had
enough capacity to implement try AI, but that the real problem is
that, cognitively, we really don't understand how to do it.

I was getting my master's degree in CS around when the Fifth
generation brouhaha cut loose. I couldn't see any way how the
Japanese were going to do it based on their (published) plans. There
was nothing specific (that I can remember) about the approach that
they were going to take other than apparently doing lots of
everything.

My only remark is that Winograd's SHRDLU was an extremely intriguing
approach that might have been much productively further pursued (even
though he has disavowed some of his conclusions). I think Cyc is very
interesting along those lines, but it unfortunately appears to have
had no recent activity. I don't hold with anything Searle has ever
said; I think he's got it completely wrong.

25-Aug-2006 23:06:52-PDT,2758;000000000000
Return-Path: <[email protected]>
Received: from pangtzu.panda.com ([206.124.149.117]) by lingling.panda.com with TCP/SMTP; Fri, 25 Aug 2006 22:57:23 -0700 (PDT)
X-Return-Path: <[email protected]>
X-Received: from sj-iport-6.cisco.com ([171.71.176.117]) by lingling.panda.com with TCP/SMTP; Fri, 25 Aug 2006 20:37:53 -0700 (PDT)
X-Received: from sj-dkim-1.cisco.com ([171.71.179.21])
by sj-iport-6.cisco.com with ESMTP; 25 Aug 2006 20:37:48 -0700
X-Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254])
by sj-dkim-1.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k7Q3bl3K017055;
Fri, 25 Aug 2006 20:37:47 -0700
X-Received: from cisco.com (pita.cisco.com [171.71.177.199])
by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k7Q3blYp022533;
Fri, 25 Aug 2006 20:37:47 -0700 (PDT)
X-Received: (from billw@localhost)
by cisco.com (8.8.8-Cisco List Logging/8.8.8) id UAA01727;
Fri, 25 Aug 2006 20:36:47 -0700 (PDT)
Sender: Bill Westfield <[email protected]>
Date: Fri, 25 Aug 2006 20:36:47 PDT
From: William "Chops" Westfield <[email protected]>
To: [email protected]
Cc: TOPS-20 List Moderator <[email protected]>,
[email protected]
Subject: Re: ASCII wire efficient and proposed TYPE L 7 RFC
In-Reply-To: Your message of Sat, 26 Aug 2006 02:06:28 +0000 (GMT)
Message-ID: <CMM.0.90.4.1156563407.billw@pita>
DKIM-Signature: a=rsa-sha1; q=dns; l=368; t=1156563467; x=1157427467;
c=relaxed/simple; s=sjdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version;
d=cisco.com; [email protected]; z=From:William=20=22Chops=22=20Westfield=20<[email protected]>
|Subject:Re=3A=20ASCII=20wire=20efficient=20and=20proposed=20TYPE=20L=207=20RFC
|Sender:Bill=20Westfield=20<[email protected]>;
X=v=3Dcisco.com=3B=20h=3DryuBeLQRfgFP5cCMUEKFB4q53QU=3D; b=mxHahQZfsMSqu9Gg55En9xhFVXFiKahfMF+BksBgvLIvcXSHYwCoDME7g+Feb5q3p2y/XeY4
SwO4cX4idfxeAzl24rfWiDFeACnc/9WZJRhwZxZhR99qe6xGZoBkYzNW;
Authentication-Results: sj-dkim-1.cisco.com; [email protected]; dkim=pass (
sig from cisco.com verified; );
ReSent-Date: Fri, 25 Aug 2006 22:57:08 -0700 (PDT)
ReSent-From: TOPS-20 List Moderator <[email protected]>
ReSent-To: TOPS-20 Distribution: ;
ReSent-Subject: Re: ASCII wire efficient and proposed TYPE L 7 RFC
ReSent-Message-ID: <[email protected]>

[unix gzip ftp hack]
However, I don't know if I'll ever do this.

Ah, go ahead. Implement a general purpose pipe/filter mechanism somewhere
in the ftp datastream, and I doubt you'll regret it. Not everything that
the unix weenies thought of was a bad idea :-)]

Do the tops20 binaries floating around support the stanford pipe extensions?

BillW
26-Aug-2006 08:54:49-PDT,2060;000000000000
Return-Path: <[email protected]>
Received: from pangtzu.panda.com ([206.124.149.117]) by lingling.panda.com with TCP/SMTP; Sat, 26 Aug 2006 08:52:51 -0700 (PDT)
X-Return-Path: <[email protected]>
X-Received: from va1exc02.SNAADS.sinenomine.net (va.sinenomine.net [192.204.203.218]) by lingling.panda.com with TCP/SMTP; Sat, 26 Aug 2006 03:07:19 -0700 (PDT)
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
Subject: RE: ASCII wire efficient and proposed TYPE L 7 RFC
MIME-Version: 1.0
Content-Type: text/plain;
charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Sat, 26 Aug 2006 06:04:47 -0400
Message-ID: <435B77BA27FC254099B1763E498DEF66103600@va1exc02.SNAADS.sinenomine.net>
In-Reply-To: <[email protected]>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: ASCII wire efficient and proposed TYPE L 7 RFC
Thread-Index: AcbI2z1mbQcyokSLRx2YKg7hOk33QgAGzuJg
From: "David Boyes" <[email protected]>
To: <[email protected]>
ReSent-Date: Sat, 26 Aug 2006 08:52:42 -0700 (PDT)
ReSent-From: TOPS-20 List Moderator <[email protected]>
ReSent-To: TOPS-20 Distribution: ;
ReSent-Subject: RE: ASCII wire efficient and proposed TYPE L 7 RFC
ReSent-Message-ID: <[email protected]>

> > IMHO, the most important use for TYPE A is to interchange text files
> > between PDP-10 and UNIX systems. This is because TYPE A turns on
> > newline conversion on the UNIX system.=20
> Yup. I also seem to remember using TYPE A to send files to our EBCDIC
> based systems. I did this because I was also the maintainer of IBMSPL
> and the DN60 front end code at Columbia, but I don't remember much
> about any of it at this point.

TYPE A is still widely used on VM, VSE and MVS systems. It triggers both
line-end conversion and ASCII/EBCDIC conversion for text files. TYPE E
is used for pure EBCDIC between IBM systems.=20

How does the new server handle MODE B?=20

-- db
26-Aug-2006 09:08:52-PDT,2383;000000000000
Return-Path: <[email protected]>
Received: from pangtzu.panda.com ([206.124.149.117]) by lingling.panda.com with TCP/SMTP; Sat, 26 Aug 2006 09:07:18 -0700 (PDT)
X-Return-Path: <[email protected]>
X-Received: from jalapeno.cc.columbia.edu ([128.59.29.5]) by lingling.panda.com with TCP/SMTP; Sat, 26 Aug 2006 08:55:06 -0700 (PDT)
X-Received: from [192.168.0.102] (pool-151-198-16-160.mad.east.verizon.net [151.198.16.160])
(user=rossman mech=PLAIN bits=0)
by jalapeno.cc.columbia.edu (8.13.7/8.13.6) with ESMTP id k7QFsxum011187
(version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT);
Sat, 26 Aug 2006 11:55:00 -0400 (EDT)
In-Reply-To: <[email protected]>
References: <[email protected]> <[email protected]> <[email protected]>
Mime-Version: 1.0 (Apple Message framework v752.2)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <[email protected]>
Content-Transfer-Encoding: 7bit
From: Ken Rossman <[email protected]>
Subject: Re: ASCII wire efficient and proposed TYPE L 7 RFC
Date: Sat, 26 Aug 2006 11:55:00 -0400
To: [email protected]
X-Mailer: Apple Mail (2.752.2)
X-No-Spam-Score: Local
X-Scanned-By: MIMEDefang 2.48 on 128.59.29.5
ReSent-Date: Sat, 26 Aug 2006 09:07:09 -0700 (PDT)
ReSent-From: TOPS-20 List Moderator <[email protected]>
ReSent-To: TOPS-20 Distribution: ;
ReSent-Subject: Re: ASCII wire efficient and proposed TYPE L 7 RFC
ReSent-Message-ID: <[email protected]>

Speaking of things that might cause TOPS-20 to make a comeback, and/or
become an indispensable quantity, I had heard awhile back (a LONG while
back now) that CompuServe had written their stuff all on TOPS-10/20
machines, and that they had to do something pretty drastic when the
DEC-20
line (well, Jupiter project, more specifically) was cancelled. They
found
it would have been much more expensive and difficult to port their
software
than to stay with the KL platform.

So to those of you who do know the real story in that bit of history
(or mis-information, depending), what did CIS end up doing? Did they
go over to XKL? Did they do some porting anyway? Did they implement
and run on top of something like KLH10? What?

KR

26-Aug-2006 10:40:51-PDT,6028;000000000000
Return-Path: <[email protected]>
Received: from pangtzu.panda.com ([206.124.149.117]) by lingling.panda.com with TCP/SMTP; Sat, 26 Aug 2006 10:39:04 -0700 (PDT)
X-Return-Path: <[email protected]>
X-Received: from sesame.cc.columbia.edu ([128.59.59.56]) by lingling.panda.com with TCP/SMTP; Sat, 26 Aug 2006 10:14:59 -0700 (PDT)
X-Received: from sesame.cc.columbia.edu (localhost [127.0.0.1])
by sesame.cc.columbia.edu (8.13.7/8.13.6) with ESMTP id k7QHErCW022576;
Sat, 26 Aug 2006 13:14:53 -0400 (EDT)
X-Received: (from fdc@localhost)
by sesame.cc.columbia.edu (8.13.7/8.12.8/Submit) id k7QHErpS022574;
Sat, 26 Aug 2006 13:14:53 -0400 (EDT)
Date: Sat, 26 Aug 2006 13:14:53 EDT
From: Frank da Cruz <[email protected]>
To: [email protected]
Cc: [email protected]
Subject: Re: ASCII wire efficient and proposed TYPE L 7 RFC
In-Reply-To: <[email protected]>
Message-ID: <[email protected]>
ReSent-Date: Sat, 26 Aug 2006 10:38:56 -0700 (PDT)
ReSent-From: TOPS-20 List Moderator <[email protected]>
ReSent-To: TOPS-20 Distribution: ;
ReSent-Subject: Re: ASCII wire efficient and proposed TYPE L 7 RFC
ReSent-Message-ID: <[email protected]>

Tom, congratulations on your young'un! You probably remember when I had
my first, in 1977 when CU20A still had "new car smell" -- I stayed home
for a week or two and Howard dragged over a Fox-1100 terminal and a 300 baud
rubber-cup modem so I could check email.

> > > The response to PWD is Unixified...
> > The response to PWD should be in Unix format, of course,
>
> What's your rational for this opinion?
>
The purpose of TVFS is to present a Unix-like file system to accommodate
all the FTP clients that think all FTP servers are on Unix, so if you throw
them a curve, they're likely mess up if they do anything with the PWD
response.

> > but don't bend over backwards too far or pretty soon you'll be
> > sending Unix-style "ls -l" listings in response to LIST.
>
> Oh dear, I guess I'm already bent ... When in TVFS mode, STAT, NLST
> and LIST will parse for a limited subset of 'ls' switches (-l and -a).
> This is because ange-FTP does an "NLST -al" when doing certain things
> and will break if you don't handle those switchs. ... Sigh ...
>
> > Out of curiosity, does your server support MLSD?
>
> I know about MLSD, have hooks to implement it and plan to do.
>
It's the right way to do LIST (30 years later!). But it's never going to
take off unless some servers offer it. It pains me to think of all the FTP
clients that try to "parse" those fractured ls listings, especially the
dates! You would be amused by the heated discussions over this some years
ago in the VMS newsgroup. As you might imagine, zero graphical FTP clients
worked with VMS FTP servers.

Everybody forgot that the underlying principal of the Internet was to
interconnect a multiplicity of platforms, hiding their differences by
putting only standard, agreed-upon, common intermediate representations on
the wire. The idea being that no platform should ever need to know the
details (e.g. text formats, character sets) of any other plaform, because if
this were the case, it would be an "O(n^2)" problem. But we don't care
about that any more, now that, for all practical purposes, n = 2.

> Again, note that Tops-20 stores the byte count in an UNsigned 36 bit
> word. This has a dynamic range of 4 and half bits greater than many
> implementations of long in the C libary, which typically use a 32 bit
> SIGNED long (is this true on 64 bit platforms?).
>
A 64-bit signed number, yes. It has to be signed because negative values
are used to indicate things like "file not found". But as you probably
know, it's not only 64-bit platforms that support large files; now almost
every current Unix does, using a relatively new (late 1990s) and standardized
API called LFS (Large File Support). 32-bit Windows supports large files
too, but of course in own special way.

> I really have to laugh when I remember the Internet implementation
> compatibility 'bake-offs' of yore. Now it would just seem to be a
> horse race to see which FTP server could understand the nits of the
> FTP client using it. Exactly the situation RFC959 was supposed to
> prevent. Or maybe I should just break down and cry. Sigh.
>
FTP is too hard for young people to understand, so either they don't bother
with it or they misimplement it. This leads to chaos and a general (and
completely undeserved) discrediting of FTP. Add to that the problems with
firewalls, proxies, and all the rest, and FTP is rapidly fading from the
scene. Everybody thinks it's "insecure", for example, so they ban it.
Well, of course it's insecure if you send passwords and data in the clear.
The cure for that is to install one of the many readily available FTP
servers secured by SSL/TLS or Kerberos. But those security methods are also
too complicated for people to deal with, so instead they switch to SFTP,
SCP, or HTTPS for file transfer.

Well, anything to do with SSH is inherently less secure than managed
protocols like SSL/TLS and Kerberos, but nobody cares. HTTPS is more secure
(since the underlying security method is, indeed SSL); people use it because
it's already in their browsers. But all of these are stupid protocols with
no distinction between text and binary data. They're only good for
transferring JPGs, tarballs, and Zip files, thus helping along the already
self-fulfilling prophecy that all the world is Unix or Windows.

Here at Columbia, where we've been serving up Kermit and other files over
FTP for well over 20 years, we're increasingly dealing with people who can't
get the files any more because of firewalls on their end, or other blockages
between there and here. First Telnet was driven out by SSH (for equally
inadequate reasons), and now FTP is going the same way.

- Frank
26-Aug-2006 13:40:23-PDT,3694;000000000000
Return-Path: <[email protected]>
Received: from pangtzu.panda.com ([206.124.149.117]) by lingling.panda.com with TCP/SMTP; Sat, 26 Aug 2006 13:38:42 -0700 (PDT)
X-Return-Path: <[email protected]>
X-Received: from mta5.srv.hcvlny.cv.net ([167.206.4.200]) by lingling.panda.com with TCP/SMTP; Sat, 26 Aug 2006 13:00:13 -0700 (PDT)
X-Received: from optonline.net (hamstr3.srv.hcvlny.cv.net [167.206.5.10])
by mta5.srv.hcvlny.cv.net
(Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006))
with ESMTP id <[email protected]> for
[email protected]; Sat, 26 Aug 2006 16:00:12 -0400 (EDT)
X-Received: from [10.240.3.198] (Forwarded-For: [10.240.3.198])
by mstr3.srv.hcvlny.cv.net (mshttpd); Sat, 26 Aug 2006 20:00:07 +0000 (GMT)
Date: Sat, 26 Aug 2006 20:00:07 +0000 (GMT)
From: [email protected]
Subject: Re: RE: ASCII wire efficient and proposed TYPE L 7 RFC
In-reply-to:
<435B77BA27FC254099B1763E498DEF66103600@va1exc02.SNAADS.sinenomine.net>
To: David Boyes <[email protected]>
Cc: [email protected]
Message-id: <[email protected]>
MIME-version: 1.0
X-Mailer: Sun Java(tm) System Messenger Express 6.2-6.01 (built Apr 3 2006)
Content-type: text/plain; charset=us-ascii
Content-language: en
Content-transfer-encoding: 7BIT
Content-disposition: inline
X-Accept-Language: en
Priority: normal
References: <[email protected]>
<435B77BA27FC254099B1763E498DEF66103600@va1exc02.SNAADS.sinenomine.net>
ReSent-Date: Sat, 26 Aug 2006 13:38:34 -0700 (PDT)
ReSent-From: TOPS-20 List Moderator <[email protected]>
ReSent-To: TOPS-20 Distribution: ;
ReSent-Subject: Re: RE: ASCII wire efficient and proposed TYPE L 7 RFC
ReSent-Message-ID: <[email protected]>

> TYPE A is still widely used on VM, VSE and MVS systems. It triggers
> both line-end conversion and ASCII/EBCDIC conversion for text files.
> TYPE E is used for pure EBCDIC between IBM systems.

I had toyed with the idea of doing TYPE E. For the way I've
architected the extended server, I think that it might be trivial.

For a retrieval of ASCII files (7 bit and 36 bit PA1050 output), I'd
simply push the data stream through a big MOVST like what I'm
currently doing for Unix data stream auto-de-frobinication (internally
known as TYPE U). For eight bit files, I might just ship them up with
no conversion.

For STOR, I could take the incoming data stream and push that through
a MOVST. However, see below.

> How does the new server handle MODE B?

It doesn't! :-) I have source to the BBN FTP server and the ITS
server (anybody have a WAITS one??) and none of them implement
anything but MODE S. I also have a few other systems that I do
regression testing against. Neither the SCO UNIX, Debian, Windows
2000 Server nor Mac OSX FTP servers do MODE B, either. One speculates
that this might be because the underlying file systems don't provide
the block mode functionality.

However, the Tops-20 FTP client can easily talk to IBM mainframes as
it implements both MODE B and MODE C. Because of this I thought that,
at one point, it might be winning to implement these modes in order to
be more friendly with the MVS systems. I'm really impressed with the
Tops-20 FTP client and have used its features as a guide of what and
how to do things in a number of cases. It's a fine piece of code.

If you know of an IBM mainframe on the Internet where I could get a
test id (ala TWENEX.ORG), I'd be delighted to pursue the matter
further once I get my first beta out. Second system effect is a
beautiful thing.
27-Aug-2006 09:07:06-PDT,3536;000000000000
Return-Path: <[email protected]>
Received: from pangtzu.panda.com ([206.124.149.117]) by lingling.panda.com with TCP/SMTP; Sun, 27 Aug 2006 09:05:11 -0700 (PDT)
X-Return-Path: <[email protected]>
X-Received: from va1exc02.SNAADS.sinenomine.net (va.sinenomine.net [192.204.203.218]) by lingling.panda.com with TCP/SMTP; Sun, 27 Aug 2006 06:18:27 -0700 (PDT)
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
Subject: RE: RE: ASCII wire efficient and proposed TYPE L 7 RFC
MIME-Version: 1.0
Content-Type: text/plain;
charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Sun, 27 Aug 2006 09:15:39 -0400
Message-ID: <435B77BA27FC254099B1763E498DEF66103606@va1exc02.SNAADS.sinenomine.net>
In-Reply-To: <[email protected]>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: RE: ASCII wire efficient and proposed TYPE L 7 RFC
Thread-Index: AcbJSloyYMTpwMYDRRKIuAM0T6cTBgAj1fJA
From: "David Boyes" <[email protected]>
To: <[email protected]>
Cc: <[email protected]>
ReSent-Date: Sun, 27 Aug 2006 09:05:02 -0700 (PDT)
ReSent-From: TOPS-20 List Moderator <[email protected]>
ReSent-To: TOPS-20 Distribution: ;
ReSent-Subject: RE: RE: ASCII wire efficient and proposed TYPE L 7 RFC
ReSent-Message-ID: <[email protected]>

>=20
> > TYPE A is still widely used on VM, VSE and MVS systems. It triggers
> > both line-end conversion and ASCII/EBCDIC conversion for text files.
> > TYPE E is used for pure EBCDIC between IBM systems.
>=20
> I had toyed with the idea of doing TYPE E. For the way I've
> architected the extended server, I think that it might be trivial.

It is. On a non-EBCDIC machine it's equivalent to 8 bit image mode. TYPE
E is really only a hack to tell the IBM server not to translate the
incoming stream from ASCII to EBCDIC, but still do the line-end
conversion from ASCII newline to EBCDIC newline. You couldn't use image
mode for this stuff because you might get RDWs and other weird stuff if
you do a true image mode open on MVS.

> > How does the new server handle MODE B?
>=20
> It doesn't! :-) I have source to the BBN FTP server and the ITS
> server (anybody have a WAITS one??) and none of them implement
> anything but MODE S. I also have a few other systems that I do
> regression testing against. Neither the SCO UNIX, Debian, Windows
> 2000 Server nor Mac OSX FTP servers do MODE B, either. One speculates
> that this might be because the underlying file systems don't provide
> the block mode functionality.

One is probably correct. Still, it's a handy thing in that if you choose
to do some packing in the front end and/or have really long latency
links, you can do some interesting things with blocking the transfers
and unpacking them at the other end. Probably lost in the distant past,
but there were mods on the CMS FTP client that took files and chopped
them up into larger record blocks, then transmitted those, with
appropriate unpacking in the CMS FTP server. Cut transfer time somewhat,
but probably not enough to carry them forward over time.=20

> If you know of an IBM mainframe on the Internet where I could get a
> test id (ala TWENEX.ORG), I'd be delighted to pursue the matter
> further once I get my first beta out. Second system effect is a
> beautiful thing.

Talk to me offlist. I can probably arrange such if you really get a wild
hair about this.=20
28-Aug-2006 21:19:56-PDT,2921;000000000000
Return-Path: <[email protected]>
Received: from pangtzu.panda.com ([206.124.149.117]) by lingling.panda.com with TCP/SMTP; Mon, 28 Aug 2006 21:18:01 -0700 (PDT)
X-Return-Path: <[email protected]>
X-Received: from mail1.panix.com ([166.84.1.72]) by lingling.panda.com with TCP/SMTP; Mon, 28 Aug 2006 17:17:21 -0700 (PDT)
X-Received: from panix5.panix.com (panix5.panix.com [166.84.1.5])
by mail1.panix.com (Postfix) with ESMTP id 0CD905882C
for <[email protected]>; Mon, 28 Aug 2006 20:17:13 -0400 (EDT)
X-Received: (from alderson@localhost)
by panix5.panix.com (8.11.6p3/8.8.8/PanixN1.1) id k7T0HDm00021;
Mon, 28 Aug 2006 20:17:13 -0400 (EDT)
Date: Mon, 28 Aug 2006 20:17:13 -0400 (EDT)
Message-Id: <[email protected]>
From: Rich Alderson <[email protected]>
To: [email protected]
In-reply-to: <[email protected]> (message from Mark
Crispin on Thu, 24 Aug 2006 11:23:26 -0700 (PDT))
Subject: Re: PDP-10 implementation of APL is really really bad
References: <[email protected]>
ReSent-Date: Mon, 28 Aug 2006 21:17:54 -0700 (PDT)
ReSent-From: TOPS-20 List Moderator <[email protected]>
ReSent-To: TOPS-20 Distribution: ;
ReSent-Subject: Re: PDP-10 implementation of APL is really really bad
ReSent-Message-ID: <[email protected]>

On 24 Aug 2006, Mark Crispin <[email protected]> wrote:

>> Good point. I see that on an XKL-1, that operation in APLSF results in an
>> immediate DOMAIN ERROR instead of hanging. I'll take it up with KLH.

> For what it's worth, an SC-40 has the same hanging problem as a
> klh10. So this sounds like it may be some ambiguity in the PRM
> that XKL did one way, and SC and KLH did the other way.

> I want to try it on a real KL10, but the only KL that I have
> access to is the Paul Allen machine, and Kermit barfs on
> transferring the APLSF.EXE file. I don't know why, nor if the
> APLSF-20 file will work on TOPS-10.

I tried this, too, just as an experiment. I don't know what it's barfing on.

> Rich, if you're reading this, could you either try installing
> APLSF-10 or see if you can get the <MRC>APLSF.EXE file from
> xkleten to the TOPS-10 machine via tapenet? Thanks.

I pulled the APLSF-10 image file from Tim Shoppa's archive onto our Toad-1 and
dropped the bits on a 9-track tape to install it on the 2065. Besides putting
the standard files in SYS: and HLP:, I've left the extra installation files
(like DAPLSF.EXE, with DDT installed) in DSKB:[10,7,APLSF], world read/execute.

I'd have done this Friday, but I didn't have a console (= laptop) for the
Toad-1 with me, and the 9-track tape drive goes away if it's not used for a
day or so, so I have to reboot to recover. Hard to diagnose.

Rich
28-Aug-2006 23:49:49-PDT,1356;000000000000
Return-Path: <[email protected]>
Received: from pangtzu.panda.com ([206.124.149.117]) by lingling.panda.com with TCP/SMTP; Mon, 28 Aug 2006 23:46:53 -0700 (PDT)
X-Return-Path: <[email protected]>
X-Received: from pangtzu.panda.com ([206.124.149.117]) by lingling.panda.com with TCP/SMTP; Mon, 28 Aug 2006 22:36:19 -0700 (PDT)
Date: Mon, 28 Aug 2006 22:36:14 -0700 (PDT)
From: Mark Crispin <[email protected]>
Sender: [email protected]
To: TOPS-20 Hackers and Yackers <[email protected]>
Subject: more on the APL overflow hanging problem
Message-ID: <[email protected]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
ReSent-Date: Mon, 28 Aug 2006 23:46:43 -0700 (PDT)
ReSent-From: TOPS-20 List Moderator <[email protected]>
ReSent-To: TOPS-20 Distribution: ;
ReSent-Subject: more on the APL overflow hanging problem
ReSent-Message-ID: <[email protected]>

Well, I've now tested APLSF on a KL10, an SC-40, an XKL-1, and a klh10.
The KL10 and XKL-1 both give a DOMAIN ERROR with the operation
# / .IO 34
The SC-40 and klh10 both hang. Interesting.

I guess that it's time to fire up my KS10 and see what it does.

-- Mark --

http://panda.com/tops-20
TOPS-20: a great improvement over its successors
29-Aug-2006 00:17:07-PDT,1974;000000000000
Return-Path: <[email protected]>
Received: from pangtzu.panda.com ([206.124.149.117]) by lingling.panda.com with TCP/SMTP; Tue, 29 Aug 2006 00:15:34 -0700 (PDT)
X-Return-Path: <[email protected]>
X-Received: from nic.cafax.se ([192.71.228.17]) by lingling.panda.com with TCP/SMTP; Tue, 29 Aug 2006 00:10:59 -0700 (PDT)
X-Received: from nic.cafax.se (localhost [127.0.0.1])
by nic.cafax.se (8.13.7/8.12.11) with ESMTP id k7T7ApuP021211
for <[email protected]>; Tue, 29 Aug 2006 09:10:51 +0200 (MEST)
X-Received: (from bygg@localhost)
by nic.cafax.se (8.13.7/8.12.11/Submit) id k7T7Ap13029677
for TOPS-20 Hackers and Yackers <[email protected]>; Tue, 29 Aug 2006 09:10:51 +0200 (MEST)
Date: Tue, 29 Aug 2006 9:10:51 WET DST
From: Johnny Eriksson <[email protected]>
To: TOPS-20 Hackers and Yackers <[email protected]>
Subject: Re: more on the APL overflow hanging problem
In-Reply-To: Your message of Mon, 28 Aug 2006 22:36:14 -0700 (PDT)
Message-ID: <[email protected]>
ReSent-Date: Tue, 29 Aug 2006 00:15:19 -0700 (PDT)
ReSent-From: TOPS-20 List Moderator <[email protected]>
ReSent-To: TOPS-20 Distribution: ;
ReSent-Subject: Re: more on the APL overflow hanging problem
ReSent-Message-ID: <[email protected]>

> Well, I've now tested APLSF on a KL10, an SC-40, an XKL-1, and a klh10.
> The KL10 and XKL-1 both give a DOMAIN ERROR with the operation
> # / .IO 34
> The SC-40 and klh10 both hang. Interesting.
>
> I guess that it's time to fire up my KS10 and see what it does.

Just to be complete:

I managed to find a copy of APLSF.EXE and xfered it to a simh/Tops10
system. Result:

.RUN APLSF

terminal..TTY
APL-10 DECSYSTEM-10 APLSF 2(504)
TTY40) 9:20:10 TUESDAY 29-AUG106 BYGG [10,335]
CLEAR WS

# / .IO 34
15 DOMAIN ERROR
#/.IO34
^
# / .IO 10
3628800

> -- Mark --

--Johnny
29-Aug-2006 20:20:56-PDT,4167;000000000000
Return-Path: <[email protected]>
Received: from pangtzu.panda.com ([206.124.149.117]) by lingling.panda.com with TCP/SMTP; Tue, 29 Aug 2006 20:18:26 -0700 (PDT)
X-Return-Path: <[email protected]>
X-Received: from alnrmhc11.comcast.net (alnrmhc13.comcast.net [206.18.177.53]) by lingling.panda.com with TCP/SMTP; Tue, 29 Aug 2006 10:38:42 -0700 (PDT)
X-Received: from [10.0.1.2] (c-24-91-108-249.hsd1.ma.comcast.net[24.91.108.249])
by comcast.net (alnrmhc13) with ESMTP
id <20060829173835b130030k9he>; Tue, 29 Aug 2006 17:38:35 +0000
Mime-Version: 1.0
Message-Id: <p06230900c11a2ade6a76@[10.0.1.2]>
In-Reply-To: <[email protected]>
References: <[email protected]>
Date: Tue, 29 Aug 2006 13:38:32 -0400
To: TOPS-20 Hackers and Yackers <[email protected]>
From: Paul Wexelblat <[email protected]>
Subject: List archives
Content-Type: multipart/alternative; boundary="============_-1055249381==_ma============"
ReSent-Date: Tue, 29 Aug 2006 20:18:19 -0700 (PDT)
ReSent-From: TOPS-20 List Moderator <[email protected]>
ReSent-To: TOPS-20 Distribution: ;
ReSent-Subject: List archives
ReSent-Message-ID: <[email protected]>

--============_-1055249381==_ma============
Content-Type: text/plain; charset="us-ascii" ; format="flowed"

I just noticed that I have, in my Eudora tops folder 893 messages
from this list dating back to 1999

(Plus 1 from 1990 copied below --

Sender: [email protected]
Date: Mon, 14 May 1990 07:06:21 -0500
From: George Markham <[email protected]>
Reply-To: [email protected]
To: Mark Crispin <[email protected]>
CC: TOPS-20 Hackers and Yackers <[email protected]>
Subject: Re: a dark day
X-Info: Mail gateway to the Futura

And the world was a more mediocre place ever after to be sure.

Mark Crispin wrote:

> 16 years ago today, DEC cancelled Project Jupiter and decided not
>to build any
> new PDP-10 models.

I'm not sure why I keep this stuff, but does anyone have an interest
(I'd send a CD) --

Best, Paul

a/k/a WEX on the TOPS-10 listings
--
P.M. Wexelblat PhD
Dept. of Computer Science
University of Massachusetts Lowell
One University Ave
Lowell, MA 01854
--============_-1055249381==_ma============
Content-Type: text/html; charset="us-ascii"

<!doctype html public "-//W3C//DTD W3 HTML//EN">
<html><head><style type="text/css"></style><title>List archives</title></head><body>
<div>I just noticed that I have, in my Eudora tops folder 893 messages
from this list dating back to 1999</div>
<div><br></div>
<div>(Plus 1 from 1990 copied below --</div>
<div><br></div>
<blockquote>Sender: [email protected]</blockquote>
<blockquote>Date: Mon, 14 May 1990 07:06:21 -0500</blockquote>
<blockquote>From: George Markham
<[email protected]></blockquote>
<blockquote>Reply-To: [email protected]</blockquote>
<blockquote>To: Mark Crispin <[email protected]></blockquote>
<blockquote>CC: TOPS-20 Hackers and Yackers
<[email protected]></blockquote>
<blockquote>Subject: Re: a dark day</blockquote>
<blockquote>X-Info: Mail gateway to the Futura</blockquote>
<blockquote><br></blockquote>
<blockquote>And the world was a more mediocre place ever after to be
sure.</blockquote>
<blockquote><br></blockquote>
<blockquote>Mark Crispin wrote:</blockquote>
<blockquote><br></blockquote>
<blockquote>> 16 years ago today, DEC cancelled Project Jupiter and
decided not to build any</blockquote>
<blockquote>> new PDP-10 models.</blockquote>
<div><br></div>
<div>I'm not sure why I keep this stuff, but does anyone have an
interest (I'd send a CD) --</div>
<div><br></div>
<div>Best, Paul</div>
<div><br></div>
<div>a/k/a WEX on the TOPS-10 listings</div>
<x-sigsep><pre>--
</pre></x-sigsep>
<div>P.M. Wexelblat PhD<br>
Dept. of Computer Science<br>
University of Massachusetts Lowell<br>
One University Ave<br>
Lowell, MA 01854</div>
</body>
</html>
--============_-1055249381==_ma============--
29-Aug-2006 20:22:29-PDT,1781;000000000000
Return-Path: <[email protected]>
Received: from pangtzu.panda.com ([206.124.149.117]) by lingling.panda.com with TCP/SMTP; Tue, 29 Aug 2006 20:19:04 -0700 (PDT)
X-Return-Path: <[email protected]>
X-Received: from mail1.panix.com ([166.84.1.72]) by lingling.panda.com with TCP/SMTP; Tue, 29 Aug 2006 12:37:19 -0700 (PDT)
X-Received: from panix5.panix.com (panix5.panix.com [166.84.1.5])
by mail1.panix.com (Postfix) with ESMTP id 4C97858B22
for <[email protected]>; Tue, 29 Aug 2006 15:37:09 -0400 (EDT)
X-Received: (from alderson@localhost)
by panix5.panix.com (8.11.6p3/8.8.8/PanixN1.1) id k7TJaxh05674;
Tue, 29 Aug 2006 15:36:59 -0400 (EDT)
Date: Tue, 29 Aug 2006 15:36:59 -0400 (EDT)
Message-Id: <[email protected]>
From: Rich Alderson <[email protected]>
To: [email protected]
In-reply-to: <[email protected]> (message from Johnny
Eriksson on Tue, 29 Aug 2006 9:10:51 WET DST)
Subject: Re: more on the APL overflow hanging problem
References: <[email protected]>
ReSent-Date: Tue, 29 Aug 2006 20:18:52 -0700 (PDT)
ReSent-From: TOPS-20 List Moderator <[email protected]>
ReSent-To: TOPS-20 Distribution: ;
ReSent-Subject: Re: more on the APL overflow hanging problem
ReSent-Message-ID: <[email protected]>

Johnny Eriksson gave us the Tops-10 results on KLH10; here they are on SimH
(a KS-only emulator) running 7.04:

.r aplsf

terminal..tty
APL-10 DECSYSTEM-10 APLSF 2(435)
CTY) 12:26:55 TUESDAY 29-AUG106 OPR [1,2]
CLEAR WS
# / .IO 10
3628800
# / .IO 34
15 DOMAIN ERROR
#/.IO34
^
)MON
MONITOR:
30-Aug-2006 08:05:16-PDT,6911;000000000000
Return-Path: <[email protected]>
Received: from pangtzu.panda.com ([206.124.149.117]) by lingling.panda.com with TCP/SMTP; Wed, 30 Aug 2006 08:03:28 -0700 (PDT)
X-Return-Path: <[email protected]>
X-Received: from pop-satin.atl.sa.earthlink.net ([207.69.195.63]) by lingling.panda.com with TCP/SMTP; Wed, 30 Aug 2006 00:49:44 -0700 (PDT)
X-Received: from cpe-24-221-177-162.ca.sprintbbd.net ([24.221.177.162] helo=[204.238.239.104])
by pop-satin.atl.sa.earthlink.net with esmtp (Exim 3.36 #1)
id 1GIKpN-00057W-00; Wed, 30 Aug 2006 03:49:38 -0400
In-Reply-To: <p06230900c11a2ade6a76@[10.0.1.2]>
References: <[email protected]> <p06230900c11a2ade6a76@[10.0.1.2]>
Mime-Version: 1.0 (Apple Message framework v624)
Content-Type: multipart/alternative; boundary=Apple-Mail-1-375833097
Message-Id: <[email protected]>
Cc: TOPS-20 Hackers and Yackers <[email protected]>
From: Carl Baltrunas <[email protected]>
Subject: Re: List archives
Date: Wed, 30 Aug 2006 00:49:35 -0700
To: Paul Wexelblat <[email protected]>
X-Mailer: Apple Mail (2.624)
ReSent-Date: Wed, 30 Aug 2006 08:03:19 -0700 (PDT)
ReSent-From: TOPS-20 List Moderator <[email protected]>
ReSent-To: TOPS-20 Distribution: ;
ReSent-Subject: Re: List archives
ReSent-Message-ID: <[email protected]>

--Apple-Mail-1-375833097
Content-Transfer-Encoding: 7bit
Content-Type: text/plain;
charset=US-ASCII;
format=flowed

Paul,

Hmmm. I might be interested. Your note drove me to check a couple of
my archived mailboxes, including my active PDP-10 mail folder and I
found that I have about 1031 messages dating back to 1994, and three
messages before that, one each from 1992, 1991, and 1990.

Of interest was one thread that was started by Mark on "May 14, 1999"
with the subject: "a dark day" with a reply from George Markham
dated "May 14, 1990". The header inside the message says 1990 instead
of 1999. Since it was a reply, I believe George's mailer somehow
munged the date to 1990.

The other two messages, I'd be happy to forward to the list, if anyone
is interested:

Clive put together a list of running DEC 10/20 systems at the time

From [email protected] Sat Jun 20 00:33:48 1992
Return-Path: <[email protected]>
Received: from WSMR-SIMTEL20.ARMY.MIL by tardis.tymnet.com
(4.1/SMI-4.1)
id AA05709; Sat, 20 Jun 92 00:33:48 PDT
Received: from MCC.COM by WSMR-SIMTEL20.ARMY.MIL with TCP; Fri, 19 Jun
92 14:10:25 MDT
Date: Fri, 19 Jun 92 15:06:36 CDT
From: Clive Dawson <[email protected]>
Subject: Survey of DEC-10/20's still in use.
To: [email protected]
Message-Id: <[email protected]>

and (a message that I thought I had lost)

the final email message from SAIL when it was supposedly shut down. I
don't know what date it was actually turned off, as I heard that it was
unofficially going to keep running until they found a replacement to
run the prancing pony (I think that's what it was called) vending
machine.

From [email protected] Fri Jun 7 22:18:40 1991
Return-Path: <[email protected]>
Received: from SAIL.Stanford.EDU by tardis.tymnet.com (4.1/SMI-4.1)
id AA11252; Fri, 7 Jun 91 22:18:33 PDT
From: SAIL Timesharing System <[email protected]>
Subject: life as a computer for a quarter of a century
To: "@BYEBYE.[1,SAI]"@SAIL.Stanford.EDU

TAKE ME, I'M YOURS
The autobiography of SAIL

-Carl

On Aug 29, 2006, at 10:38 AM, Paul Wexelblat wrote:

> I just noticed that I have, in my Eudora tops folder 893 messages from
> this list dating back to 1999
>
> (Plus 1 from 1990 copied below --
>
>
> I'm not sure why I keep this stuff, but does anyone have an interest
> (I'd send a CD) --
>
> Best, Paul
>
> a/k/a WEX on the TOPS-10 listings
> --
>
>
> P.M. Wexelblat PhD
> Dept. of Computer Science
> University of Massachusetts Lowell
> One University Ave
> Lowell, MA 01854

--Apple-Mail-1-375833097
Content-Transfer-Encoding: 7bit
Content-Type: text/enriched;
charset=US-ASCII

Paul,

Hmmm. I might be interested. Your note drove me to check a couple of
my archived mailboxes, including my active PDP-10 mail folder and I
found that I have about 1031 messages dating back to 1994, and three
messages before that, one each from 1992, 1991, and 1990.

Of interest was one thread that was started by Mark on "May 14, 1999"
with the subject: "a dark day" with a reply from George Markham
dated "May 14, 1990". The header inside the message says 1990
instead of 1999. Since it was a reply, I believe George's mailer
somehow munged the date to 1990.

The other two messages, I'd be happy to forward to the list, if anyone
is interested:

Clive put together a list of running DEC 10/20 systems at the time

From [email protected] Sat Jun 20 00:33:48 1992

Return-Path: <<[email protected]>

Received: from WSMR-SIMTEL20.ARMY.MIL by tardis.tymnet.com
(4.1/SMI-4.1)

id AA05709; Sat, 20 Jun 92 00:33:48 PDT

Received: from MCC.COM by WSMR-SIMTEL20.ARMY.MIL with TCP; Fri, 19
Jun 92 14:10:25 MDT

Date: Fri, 19 Jun 92 15:06:36 CDT

From: Clive Dawson <<[email protected]>

Subject: Survey of DEC-10/20's still in use.

To: [email protected]

Message-Id: <<[email protected]>

and (a message that I thought I had lost)

the final email message from SAIL when it was supposedly shut down. I
don't know what date it was actually turned off, as I heard that it
was unofficially going to keep running until they found a replacement
to run the prancing pony (I think that's what it was called) vending
machine.

From [email protected] Fri Jun 7 22:18:40 1991

Return-Path: <<[email protected]>

Received: from SAIL.Stanford.EDU by tardis.tymnet.com (4.1/SMI-4.1)

id AA11252; Fri, 7 Jun 91 22:18:33 PDT

From: SAIL Timesharing System <<[email protected]>

Subject: life as a computer for a quarter of a century

To: "@BYEBYE.[1,SAI]"@SAIL.Stanford.EDU

TAKE ME, I'M YOURS

The autobiography of SAIL

-Carl

On Aug 29, 2006, at 10:38 AM, Paul Wexelblat wrote:

<excerpt>I just noticed that I have, in my Eudora tops folder 893
messages from this list dating back to 1999

(Plus 1 from 1990 copied below --

I'm not sure why I keep this stuff, but does anyone have an interest
(I'd send a CD) --

Best, Paul

a/k/a WEX on the TOPS-10 listings

<fixed>--

</fixed>

P.M. Wexelblat PhD

Dept. of Computer Science

University of Massachusetts Lowell

One University Ave

Lowell, MA 01854

</excerpt>
--Apple-Mail-1-375833097--

30-Aug-2006 22:18:25-PDT,4396;000000000000
Return-Path: <[email protected]>
Received: from pangtzu.panda.com ([206.124.149.117]) by lingling.panda.com with TCP/SMTP; Wed, 30 Aug 2006 22:16:14 -0700 (PDT)
X-Return-Path: <[email protected]>
X-Received: from mta5.srv.hcvlny.cv.net ([167.206.4.200]) by lingling.panda.com with TCP/SMTP; Wed, 30 Aug 2006 22:07:12 -0700 (PDT)
X-Received: from optonline.net (hamstr3.srv.hcvlny.cv.net [167.206.5.10])
by mta5.srv.hcvlny.cv.net
(Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006))
with ESMTP id <[email protected]> for
[email protected]; Thu, 31 Aug 2006 01:07:10 -0400 (EDT)
X-Received: from [10.240.3.209] (Forwarded-For: [10.240.3.209])
by mstr3.srv.hcvlny.cv.net (mshttpd); Thu, 31 Aug 2006 05:07:05 +0000 (GMT)
Date: Thu, 31 Aug 2006 05:07:05 +0000 (GMT)
From: [email protected]
Subject: Interesting Netscape Navigator FTP behavior
To: [email protected]
Message-id: <[email protected]>
MIME-version: 1.0
X-Mailer: Sun Java(tm) System Messenger Express 6.2-6.01 (built Apr 3 2006)
Content-type: text/plain; charset=us-ascii
Content-language: en
Content-transfer-encoding: 7BIT
Content-disposition: inline
X-Accept-Language: en
Priority: normal
ReSent-Date: Wed, 30 Aug 2006 22:16:06 -0700 (PDT)
ReSent-From: TOPS-20 List Moderator <[email protected]>
ReSent-To: TOPS-20 Distribution: ;
ReSent-Subject: Interesting Netscape Navigator FTP behavior
ReSent-Message-ID: <[email protected]>

After I sent my last FTP server update in which I said that the
Netscape Navigator worked, I went and double checked what version I
was using (Netscape 7.2). Although it's running on a faster machine
than my laptop (where I do most of my development), the performance
wasn't as snappy as I thought it should be.

So, I had a look at the server log files to determine what the
Navigator was sending to me to see if I couldn't speed things up a
bit. I had done this in another case by implementing EPRT and EPSV to
make things a tiny bit quicker with the Macintosh OSX character mode
FTP client.

It turns out that the Navigator was trying to retrieve (I.E., sends a
RETR) in all cases for all files, including directory 'files'. If the
RETR fails, then it (apparently) assumes that the file in question is
a directory and then does a listing of it (I.E., sends a LIST or NLST).

Somewhere in a dusty back corner of my mind, I remembered a
presentation by Rob Pike about the first billion seconds of Unix
titled, "The Good, the Bad, and the Ugly: The Unix (TM) Legacy" in
which he mentions that "cat ." no longer works.

So I thought that the Navigator was doing this in order to get a
directory listing. Despite that "cat ." doesn't work anywhere on any
Unix machine that I have, I changed my FTP server to give a (unix)
directory listing for a retrieve of a directory file instead of
complaining about it. Pretty nifty, eh?

The Netscape Navigator promptly broke ... It got the listing of the
(simulated) Tops-20 root directory as a file and I couldn't get
anything else. So I changed it back and everything worked again.

It looks like the Navigator checks to see if something is a directory
by trying to retrieve it, first. On the other hand, the Windows
Internet Explorer and the EFTP3Client apparently parse the returned
Unix file mode to decide what to do.

Maybe the Navigator approach would work with more systems? I guess IE
and EFTP probably wouldn't really work well with something that
doesn't give file modes. Certainly IE doesn't work with the 'stock'
Tops-20 server (otherwise, I probably wouldn't have bothered doing a
new one!).

I've also had to put in even more code (since the last time) to handle
more script kiddie silliness. It's not that I think that any of that
stuff to break into Unix or Windows is going to work on my machine
(Ha!), I just really don't feel like having these boneheads sitting in
a loop hogging the CPU while I'm trying to get some work done.

So, I have a couple more (configurable) parameters to throw them off
as soon as I detect them. Gee, it almost makes me feel like I'm back
at Columbia trying to keep the undergraduate kiddies from zorching our
20's. Ah, memories ...

PS: Actually, I think it's pretty much all ugly ...

31-Aug-2006 07:27:15-PDT,3828;000000000000
Return-Path: <[email protected]>
Received: from pangtzu.panda.com ([206.124.149.117]) by lingling.panda.com with TCP/SMTP; Thu, 31 Aug 2006 07:25:22 -0700 (PDT)
X-Return-Path: <[email protected]>
X-Received: from mta10.srv.hcvlny.cv.net ([167.206.4.205]) by lingling.panda.com with TCP/SMTP; Thu, 31 Aug 2006 05:20:56 -0700 (PDT)
X-Received: from optonline.net (hamstr3.srv.hcvlny.cv.net [167.206.5.10])
by mta10.srv.hcvlny.cv.net
(Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006))
with ESMTP id <[email protected]> for
[email protected]; Thu, 31 Aug 2006 08:19:12 -0400 (EDT)
X-Received: from [10.240.3.209] (Forwarded-For: [10.240.3.209])
by mstr3.srv.hcvlny.cv.net (mshttpd); Thu, 31 Aug 2006 12:20:11 +0000 (GMT)
Date: Thu, 31 Aug 2006 12:20:11 +0000 (GMT)
From: [email protected]
Subject: Re: MOVSLJ behavior in non-zero sections on a Toad
In-reply-to: <[email protected]>
To: Johnny Eriksson <[email protected]>
Cc: [email protected]
Message-id: <[email protected]>
MIME-version: 1.0
X-Mailer: Sun Java(tm) System Messenger Express 6.2-6.01 (built Apr 3 2006)
Content-type: text/plain; charset=us-ascii
Content-language: en
Content-transfer-encoding: 7BIT
Content-disposition: inline
X-Accept-Language: en
Priority: normal
References: "19 Aug 2006 14:36:24 +0000"
<[email protected]>
ReSent-Date: Thu, 31 Aug 2006 07:25:10 -0700 (PDT)
ReSent-From: TOPS-20 List Moderator <[email protected]>
ReSent-To: TOPS-20 Distribution: ;
ReSent-Subject: Re: MOVSLJ behavior in non-zero sections on a Toad
ReSent-Message-ID: <[email protected]>

> > [email protected] wrote:
> >
> > Do you think that it might be appropriate to post a beware file
> > with cautions about certain instructions on a Toad? I seem to
> > remember an *** OLD *** (1973) copy of SYSREF that said something
> > like, "don't use foo when dismissing an interrupt, it does not
> > work" (anybody else remember this?)

> [email protected] wrote:
>
> In my copy of the "phone book" there is, regarding interrupts,
> this text:
> Caution
>
> Neither an LUUO nor a BLT will function in a
> reasonable manner as an interrupt instruction.
> Therefore do not use them.
>
> Is this what you were thinking of?

Ah yes, the phone book. I actually have two copies of this, a REALLY
beat up third addition from High School and an almost brand new second
addition that I picked up at WPI as a spare that I never used (I think
I got it from Tribble).

I finally remembered the reference: it's from the User Operations
section of the processor reference manual where XCT is being discussed
(on page 2-63). Here is what it says:

" Caution: In a private program (concealed or kernel mode) on the
KI1O, never give an XCT that executes an instruction in a public
page. It does not work."

So, it looks like I remembered the "It does not work" part correctly,
but I don't know how I got interrupt from all that public/private
hair. Probably because I really didn't understand either. That's
actually surprising, now that I think of it because the entrance to
GLXOTS routines goes through a PORTAL, which didn't do anything on
Tops-20. Or maybe it's not surprising ...

The early version of the processor reference manual that I have (I
seem to have wound up with three of these) also has the now famous
admonition to not let "guck" get into parts of the machine and the
observation that using a little Spic and Span is healthier by giving
you a little exercise.

I still think we should have some sort of a beware file, if nothing
else, things that we bump into should be preserved on the Tops-20
list.

31-Aug-2006 21:06:17-PDT,3818;000000000000
Return-Path: <[email protected]>
Received: from pangtzu.panda.com ([206.124.149.117]) by lingling.panda.com with TCP/SMTP; Thu, 31 Aug 2006 21:04:31 -0700 (PDT)
X-Return-Path: <[email protected]>
X-Received: from mta3.srv.hcvlny.cv.net ([167.206.4.198]) by lingling.panda.com with TCP/SMTP; Thu, 31 Aug 2006 13:08:43 -0700 (PDT)
X-Received: from optonline.net (hamstr3.srv.hcvlny.cv.net [167.206.5.10])
by mta3.srv.hcvlny.cv.net
(Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006))
with ESMTP id <[email protected]> for
[email protected]; Thu, 31 Aug 2006 16:08:25 -0400 (EDT)
X-Received: from [10.240.3.203] (Forwarded-For: [10.240.3.203])
by mstr3.srv.hcvlny.cv.net (mshttpd); Thu, 31 Aug 2006 20:08:24 +0000 (GMT)
Date: Thu, 31 Aug 2006 20:08:24 +0000 (GMT)
From: [email protected]
Subject: LAT and KEA! (and others)
In-reply-to: <[email protected]>
To: [email protected]
Message-id: <[email protected]>
MIME-version: 1.0
X-Mailer: Sun Java(tm) System Messenger Express 6.2-6.01 (built Apr 3 2006)
Content-type: text/plain; charset=us-ascii
Content-language: en
Content-transfer-encoding: 7BIT
Content-disposition: inline
X-Accept-Language: en
Priority: normal
References: "19 Aug 2006 14:36:24 +0000"
<[email protected]> <[email protected]>
ReSent-Date: Thu, 31 Aug 2006 21:04:19 -0700 (PDT)
ReSent-From: TOPS-20 List Moderator <[email protected]>
ReSent-To: TOPS-20 Distribution: ;
ReSent-Subject: LAT and KEA! (and others)
ReSent-Message-ID: <[email protected]>

Since I'm around the house a bit more these days (and not sleeping),
I've become increasingly disenchanted with the performance of TELNET
on my local LAN. I wish it were a little faster. But, I don't really
want to get into a rave about the whys and hows of the Tops-20 TELNET
server implementation; I guess everybody knows about it.

I seem to recall that when we got LAT at Columbia, that the throughput
to and from our 20's was faster, but I wouldn't absolutely swear to
it, seeing as this was over 20 years ago. Before LAT, the maximum
speed that we could normally go was 9600 baud through a DH11. In
fact, most people only had 4800 baud. I was one of the lucky few on
campus who could go 9600 because I had a local line and had my brother
(who was in SA at the time) borrow (ahh, almost pilfer) some different
equipment for me.

When we got a baby-VAX (micro-Vax?) in our building, I set up a local
line from it to my Ann Arbor Ambassador terminal. This was running at
19.2K baud. Heady stuff. The VAX was on our LAN and I used LAT on
the VAX to get into the 20. Seeing as I was just about always the
only user on the VAX, performance was pretty snappy.

I've wondering about using LAT again, but I really don't want to spend
any money on a hardware LAT terminal concentrator. Any of these
beasts are probably getting pretty long in the tooth. It also seems
counter productive to connect one of these beasts into a serial port
on my computer.

There is a free implementation of LAT under Linux, but I don't want to
use this because I normally wind up using Windows.

Does the server LAT implementation on Tops-20 still work under KLH10?
Has ANYBODY actually used this (or tried to)? Do I have to do
anything funny with the ethernet addresses?

What are my software solutions under Windows 2000? I came across a
product called KEA! that claims to do LAT, but it looks kind of pricey
(although I have seen copies for a great deal less). In any event,
I'd hate to spend the money if the 20 won't work anyway.

Whats the news? Any other reasonable alternatives? CTERM? NRT?

31-Aug-2006 21:15:41-PDT,2734;000000000000
Return-Path: <[email protected]>
Received: from pangtzu.panda.com ([206.124.149.117]) by lingling.panda.com with TCP/SMTP; Thu, 31 Aug 2006 21:14:05 -0700 (PDT)
X-Return-Path: <[email protected]>
X-Received: from pangtzu.panda.com ([206.124.149.117]) by lingling.panda.com with TCP/SMTP; Thu, 31 Aug 2006 21:13:04 -0700 (PDT)
Date: Thu, 31 Aug 2006 21:12:58 -0700 (PDT)
From: Mark Crispin <[email protected]>
Sender: [email protected]
To: [email protected]
cc: TOPS-20 Hackers and Yackers <[email protected]>
Subject: Re: LAT and KEA! (and others)
In-Reply-To: <[email protected]>
Message-ID: <[email protected]>
References: "19 Aug 2006 14:36:24 +0000" <[email protected]>
<[email protected]> <[email protected]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
ReSent-Date: Thu, 31 Aug 2006 21:13:37 -0700 (PDT)
ReSent-From: TOPS-20 List Moderator <[email protected]>
ReSent-To: TOPS-20 Distribution: ;
ReSent-Subject: Re: LAT and KEA! (and others)
ReSent-Message-ID: <[email protected]>

On Thu, 31 Aug 2006, [email protected] wrote:
> Does the server LAT implementation on Tops-20 still work under KLH10?
> Has ANYBODY actually used this (or tried to)? Do I have to do
> anything funny with the ethernet addresses?

Almost certainly, you need to make the Ethernet address (MAC address) be
one of the DECnet addresses.

Lingling has a dedicated Ethernet interface for the TOPS-20 system, and I
have set it to be a DECnet address. It involves some kludgery, as you can
not change the MAC address when the interface is up, but klh10 won't talk
to the interface unless it's up. So I ended up doing

/sbin/ifconfig eth1 hw ether aa:00:04:00:01:04
/sbin/ifconfig eth1 up

in the Linux system startup script

devdef ni0 564 ni20 dedic=true ifc=eth1

in the klt20.ini file, and finally

NODE PANDA 1.1
DECNET ROUTER-ENDNODE
ETHERNET 0 DECNET

in the SYSTEM:7-1-CONFIG.CMD file.

So far, so good; then I tried configuring Hsinghsing, which shares an
interface with the UNIX end (Mac OS X) to have a DECnet MAC address. I
spent quite a well fighting before I got it up and working, but ultimately
Lingling and Hsinghsing never talked DECnet to each other. According to
NCP, they sent their DECnet packets but never heard any DECnet packets.
However, TCP/IP worked.

I decided to give up until I could have another TOPS-20 system with a
dedicated interface.

-- Mark --

http://panda.com/tops-20
TOPS-20: a great improvement over its successors
31-Aug-2006 21:35:37-PDT,2374;000000000000
Return-Path: <[email protected]>
Received: from pangtzu.panda.com ([206.124.149.117]) by lingling.panda.com with TCP/SMTP; Thu, 31 Aug 2006 21:34:00 -0700 (PDT)
X-Return-Path: <[email protected]>
X-Received: from va1exc02.SNAADS.sinenomine.net (va.sinenomine.net [192.204.203.218]) by lingling.panda.com with TCP/SMTP; Thu, 31 Aug 2006 21:29:14 -0700 (PDT)
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: LAT and KEA! (and others)
Date: Fri, 1 Sep 2006 00:27:01 -0400
Message-ID: <435B77BA27FC254099B1763E498DEF6610371C@va1exc02.SNAADS.sinenomine.net>
In-Reply-To: <[email protected]>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: LAT and KEA! (and others)
Thread-Index: AcbNfUPRHedc42mLRKWX4Aql4pQtYAAAKWOA
From: "David Boyes" <[email protected]>
To: <[email protected]>,
<[email protected]>
ReSent-Date: Thu, 31 Aug 2006 21:33:52 -0700 (PDT)
ReSent-From: TOPS-20 List Moderator <[email protected]>
ReSent-To: TOPS-20 Distribution: ;
ReSent-Subject: RE: LAT and KEA! (and others)
ReSent-Message-ID: <[email protected]>

> I've wondering about using LAT again, but I really don't want to spend
> any money on a hardware LAT terminal concentrator.=20
> [snip]
> What are my software solutions under Windows 2000? I came across a
> product called KEA! that claims to do LAT, but it looks kind of pricey
> (although I have seen copies for a great deal less). In any event,
> I'd hate to spend the money if the 20 won't work anyway.

Dunno about the server side, but here's a cheap suggestion to get LAT on
the wire. Find a spare Cisco 25xx running IOS. You can telnet into them
using your fave network client, type 'lat <mumble>' and you're there.
IOS has a pretty decent LAT client implementation; don't remember
whether it could be a server too. 2501s are going for about $50 on eBay
these days, and you probably have the AUI-to-xBaseT converter somewhere.
A 2509 would give you serial ports to connect to the 20.=20

The 25xxs are reliable as hell, and have plenty of life left (and aren't
quite as cranky to configure as any of the DECservers).
1-Sep-2006 08:22:59-PDT,3081;000000000000
Return-Path: <[email protected]>
Received: from pangtzu.panda.com ([206.124.149.117]) by lingling.panda.com with TCP/SMTP; Fri, 1 Sep 2006 08:21:13 -0700 (PDT)
X-Return-Path: <[email protected]>
X-Received: from sj-iport-4.cisco.com ([171.68.10.86]) by lingling.panda.com with TCP/SMTP; Fri, 1 Sep 2006 00:43:59 -0700 (PDT)
X-Received: from sj-dkim-5.cisco.com ([171.68.10.79])
by sj-iport-4.cisco.com with ESMTP; 01 Sep 2006 00:43:54 -0700
X-IronPort-AV: i="4.08,197,1154934000";
d="scan'208"; a="1851626320:sNHT29282094"
X-Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137])
by sj-dkim-5.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k817hslE021359;
Fri, 1 Sep 2006 00:43:54 -0700
X-Received: from cisco.com (pita.cisco.com [171.71.177.199])
by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id k817hrw7003575;
Fri, 1 Sep 2006 00:43:53 -0700 (PDT)
X-Received: (from billw@localhost)
by cisco.com (8.8.8-Cisco List Logging/8.8.8) id AAA28487;
Fri, 1 Sep 2006 00:42:52 -0700 (PDT)
Sender: Bill Westfield <[email protected]>
Date: Fri, 1 Sep 2006 0:42:52 PDT
From: William "Chops" Westfield <[email protected]>
To: [email protected]
Cc: TOPS-20 List Moderator <[email protected]>,
[email protected]
Subject: Re: LAT and KEA! (and others)
In-Reply-To: Your message of Thu, 31 Aug 2006 20:08:24 +0000 (GMT)
Message-ID: <CMM.0.90.4.1157096572.billw@pita>
DKIM-Signature: a=rsa-sha1; q=dns; l=683; t=1157096634; x=1157960634;
c=relaxed/simple; s=sjdkim5002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version;
d=cisco.com; [email protected]; z=From:William=20=22Chops=22=20Westfield=20<[email protected]>
|Subject:Re=3A=20LAT=20and=20KEA!=20(and=20others)
|Sender:Bill=20Westfield=20<[email protected]>;
X=v=3Dcisco.com=3B=20h=3DpizDSlEhZ7wGIbIzdDFwMW0TPtU=3D; b=WjagzlEdSvwvj/lSFNyZipVZ6cK3UgWkv/ZjN2Qi06e/xfnNYXa8MAXO2JJ0+eryBF4rsqIS
6I9wgWmT/BD1iwFBfEGB3Uil6dc4Kj/m5VGH8dAgDW1Ijn8JdJynLFuE;
Authentication-Results: sj-dkim-5.cisco.com; [email protected]; dkim=pass (
sig from cisco.com verified; );
ReSent-Date: Fri, 1 Sep 2006 08:21:01 -0700 (PDT)
ReSent-From: TOPS-20 List Moderator <[email protected]>
ReSent-To: TOPS-20 Distribution: ;
ReSent-Subject: Re: LAT and KEA! (and others)
ReSent-Message-ID: <[email protected]>

Do the kernels you're running have the stanford TCP/TVT improvements?
You should certainly see better than 19.2kbps effective throughput; in
the early days cisco ran 38.4kbps graphics terminals via a tcp terminal
server to a KL10 tops20 system. The terminals that would support the
VTxxx graphics at that speed were a real find; there was a noticable
performance improvement over the earlier generation when running SUDS,
which was the hardware CAD system in those days. Likewise, kermit
and xmodem downloads to the PC from the 20 were faster at higher
async speeds. So I'd think that one of the 20 emulators OUGHT to
provide pretty zippy telnet performance...

BillW
1-Sep-2006 08:24:23-PDT,3615;000000000000
Return-Path: <[email protected]>
Received: from pangtzu.panda.com ([206.124.149.117]) by lingling.panda.com with TCP/SMTP; Fri, 1 Sep 2006 08:21:56 -0700 (PDT)
X-Return-Path: <[email protected]>
X-Received: from sj-iport-4.cisco.com ([171.68.10.86]) by lingling.panda.com with TCP/SMTP; Fri, 1 Sep 2006 00:52:43 -0700 (PDT)
X-Received: from sj-dkim-8.cisco.com ([171.68.10.93])
by sj-iport-4.cisco.com with ESMTP; 01 Sep 2006 00:52:37 -0700
X-IronPort-AV: i="4.08,197,1154934000";
d="scan'208"; a="1851626855:sNHT31864838"
X-Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137])
by sj-dkim-8.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k817qb6d019955;
Fri, 1 Sep 2006 00:52:37 -0700
X-Received: from cisco.com (pita.cisco.com [171.71.177.199])
by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id k817qbw7005900;
Fri, 1 Sep 2006 00:52:37 -0700 (PDT)
X-Received: (from billw@localhost)
by cisco.com (8.8.8-Cisco List Logging/8.8.8) id AAA28766;
Fri, 1 Sep 2006 00:51:35 -0700 (PDT)
Sender: Bill Westfield <[email protected]>
Date: Fri, 1 Sep 2006 0:51:35 PDT
From: William "Chops" Westfield <[email protected]>
To: "David Boyes" <[email protected]>
Cc: TOPS-20 List Moderator <[email protected]>, <[email protected]>,
<[email protected]>
Subject: RE: LAT and KEA! (and others)
In-Reply-To: Your message of Fri, 1 Sep 2006 00:27:01 -0400
Message-ID: <CMM.0.90.4.1157097095.billw@pita>
DKIM-Signature: a=rsa-sha1; q=dns; l=1144; t=1157097157; x=1157961157;
c=relaxed/relaxed; s=sjdkim8002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version;
d=cisco.com; [email protected]; z=From:William=20=22Chops=22=20Westfield=20<[email protected]>
|Subject:RE=3A=20LAT=20and=20KEA!=20(and=20others)
|Sender:Bill=20Westfield=20<[email protected]>;
X=v=3Dcisco.com=3B=20h=3Dl8rsJ2kMkjkg37i7e6sa42cc/J8=3D; b=GmfWb0pGdNU4IjqbE2x9nQleIo3SxhF4XCTQFEKfqwTtdKF0AedPunbGzb0FVmUwKcIBk63X
Id+fFVHiW3EelOuXZ6FuGajy3qNiCaEMuAzX1dRO2umEmbaFxtkVLc2C;
Authentication-Results: sj-dkim-8.cisco.com; [email protected]; dkim=pass (
sig from cisco.com verified; );
ReSent-Date: Fri, 1 Sep 2006 08:21:38 -0700 (PDT)
ReSent-From: TOPS-20 List Moderator <[email protected]>
ReSent-To: TOPS-20 Distribution: ;
ReSent-Subject: RE: LAT and KEA! (and others)
ReSent-Message-ID: <[email protected]>

Dunno about the server side, but here's a cheap suggestion to get LAT on
the wire. Find a spare Cisco 25xx running IOS. You can telnet into them
using your fave network client, type 'lat <mumble>' and you're there.

Hmm. Watch your software versions; not all of them had LAT. We had license
fees due DEC and passed them on to the customer, if the box had async ports.
If you get one with LAT, you should also have the "protocol translation"
featureset, which allows you to set up things on the cisco like:
translate tcp 10.4.5.6 lat mytops20
or translate lat myunix tcp 12.1.2.3
to remove the intermediate manual step.

The 25xxs are reliable as hell, and have plenty of life left
IOS has a pretty decent LAT client implementation; don't remember
whether it could be a server too.

Why thank you! The LAT code was mostly from a company "Meridian
Technology", who did a very nice job of writing LAT code portable to many
operating environments. At least, it dropped into IOS (which isn't like
anything else anywhere, AFAIK) pretty easilly. The cisco software does both
client AND server (and HIC) LAT...

BillW

1-Sep-2006 15:25:33-PDT,2020;000000000000
Return-Path: <[email protected]>
Received: from pangtzu.panda.com ([206.124.149.117]) by lingling.panda.com with TCP/SMTP; Fri, 1 Sep 2006 15:23:44 -0700 (PDT)
X-Return-Path: <[email protected]>
X-Received: from va1exc02.SNAADS.sinenomine.net (va.sinenomine.net [192.204.203.218]) by lingling.panda.com with TCP/SMTP; Fri, 1 Sep 2006 13:45:07 -0700 (PDT)
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: LAT and KEA! (and others)
Date: Fri, 1 Sep 2006 16:42:12 -0400
Message-ID: <435B77BA27FC254099B1763E498DEF6610375C@va1exc02.SNAADS.sinenomine.net>
In-Reply-To: <[email protected]>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: LAT and KEA! (and others)
Thread-Index: AcbN3bMrt+rKTAnZTW6GbQ/y8H92YAAKJ1UA
From: "David Boyes" <[email protected]>
To: "Bill Westfield" <[email protected]>
Cc: "TOPS-20 List Moderator" <[email protected]>,
<[email protected]>,
<[email protected]>
ReSent-Date: Fri, 1 Sep 2006 15:23:29 -0700 (PDT)
ReSent-From: TOPS-20 List Moderator <[email protected]>
ReSent-To: TOPS-20 Distribution: ;
ReSent-Subject: RE: LAT and KEA! (and others)
ReSent-Message-ID: <[email protected]>

> The 25xxs are reliable as hell, and have plenty of life left
> =20
> Why thank you!=20

You're welcome. The two 2509s I've got have both survived two direct
lightning hits on their rack. Other vendor equipment (i.e., DECservers)
didn't fare so well... 8-) Plenty horsepower, too. The 26xxs and later
weren't nearly as stable.=20

> At least, it dropped into IOS (which isn't like
> anything else anywhere, AFAIK) pretty easilly.=20

IOS always reminded me of RT-11 wearing a TOPS20 Halloween mask for the
command parser -- grotesque and distorted, but recognizable.=20

-- db

1-Sep-2006 21:23:17-PDT,2948;000000000000
Return-Path: <[email protected]>
Received: from pangtzu.panda.com ([206.124.149.117]) by lingling.panda.com with TCP/SMTP; Fri, 1 Sep 2006 21:21:46 -0700 (PDT)
X-Return-Path: <[email protected]>
X-Received: from mta4.srv.hcvlny.cv.net ([167.206.4.199]) by lingling.panda.com with TCP/SMTP; Fri, 1 Sep 2006 18:47:01 -0700 (PDT)
X-Received: from optonline.net (hamstr3.srv.hcvlny.cv.net [167.206.5.10])
by mta4.srv.hcvlny.cv.net
(Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006))
with ESMTP id <[email protected]> for
[email protected]; Fri, 01 Sep 2006 21:46:58 -0400 (EDT)
X-Received: from [10.240.3.201] (Forwarded-For: [10.240.3.201])
by mstr3.srv.hcvlny.cv.net (mshttpd); Sat, 02 Sep 2006 01:46:50 +0000 (GMT)
Date: Sat, 02 Sep 2006 01:46:50 +0000 (GMT)
From: [email protected]
Subject: Re: RE: LAT and KEA! (and others)
In-reply-to:
<435B77BA27FC254099B1763E498DEF6610375C@va1exc02.SNAADS.sinenomine.net>
To: [email protected]
Cc: [email protected]
Message-id: <[email protected]>
MIME-version: 1.0
X-Mailer: Sun Java(tm) System Messenger Express 6.2-6.01 (built Apr 3 2006)
Content-type: text/plain; charset=us-ascii
Content-language: en
Content-transfer-encoding: 7BIT
Content-disposition: inline
X-Accept-Language: en
Priority: normal
References: <[email protected]>
<435B77BA27FC254099B1763E498DEF6610375C@va1exc02.SNAADS.sinenomine.net>
ReSent-Date: Fri, 1 Sep 2006 21:21:37 -0700 (PDT)
ReSent-From: TOPS-20 List Moderator <[email protected]>
ReSent-To: TOPS-20 Distribution: ;
ReSent-Subject: Re: RE: LAT and KEA! (and others)
ReSent-Message-ID: <[email protected]>

Hey Frank,

Apropos of LAT, I just found the following in the documentation for
Kermit-95, which I was using to do speed tests off my 20:

" WARNING: Uploading files on a LAT connection is problematic due to
intrinsic limitations of LAT buffering. Using 90-byte packets and
1 window slot seems to work in most cases (tell VMS C-Kermit to
"set receive packet-length 90"); greater lengths tend to hang the
VMS session. Downloads can use any packet length or window size.
WARNING: Do NOT tell VMS or VMS C-Kermit to disable flow control.
VMS C-Kermit MUST have "set flow xon/xoff". "

Was this a problem with VMS LAT or LAT itself? What was your
experience with downloads? Did you ever get a chance to try Kermit
over LAT to CU20B before it was shut down? How about LAT into CUNIXC?
That had LAT, didn't it?

Even if LAT isn't faster than TELNET, I would probably still want to
run it because it would make a few things in my ACJ easier to write.
I'd like to allow certain things if the user is 'local'. Since we
don't have a DZ11 implementation (on the host system's COM ports), the
next best thing is LAT.

--T
1-Sep-2006 21:24:43-PDT,4770;000000000000
Return-Path: <[email protected]>
Received: from pangtzu.panda.com ([206.124.149.117]) by lingling.panda.com with TCP/SMTP; Fri, 1 Sep 2006 21:22:47 -0700 (PDT)
X-Return-Path: <[email protected]>
X-Received: from mta7.srv.hcvlny.cv.net ([167.206.4.202]) by lingling.panda.com with TCP/SMTP; Fri, 1 Sep 2006 17:32:27 -0700 (PDT)
X-Received: from optonline.net (hamstr3.srv.hcvlny.cv.net [167.206.5.10])
by mta7.srv.hcvlny.cv.net
(Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006))
with ESMTP id <[email protected]>; Fri,
01 Sep 2006 20:32:21 -0400 (EDT)
X-Received: from [10.240.3.201] (Forwarded-For: [10.240.3.201])
by mstr3.srv.hcvlny.cv.net (mshttpd); Sat, 02 Sep 2006 00:32:20 +0000 (GMT)
Date: Sat, 02 Sep 2006 00:32:20 +0000 (GMT)
From: [email protected]
Subject: Re: LAT and KEA! (and others)
In-reply-to: <[email protected]>
To: Mark Crispin <[email protected]>
Cc: TOPS-20 Hackers and Yackers <[email protected]>
Message-id: <[email protected]>
MIME-version: 1.0
X-Mailer: Sun Java(tm) System Messenger Express 6.2-6.01 (built Apr 3 2006)
Content-type: text/plain; charset=us-ascii
Content-language: en
Content-transfer-encoding: 7BIT
Content-disposition: inline
X-Accept-Language: en
Priority: normal
References: "19 Aug 2006 14:36:24 +0000"
<[email protected]>
<[email protected]> <[email protected]>
<[email protected]>
ReSent-Date: Fri, 1 Sep 2006 21:22:37 -0700 (PDT)
ReSent-From: TOPS-20 List Moderator <[email protected]>
ReSent-To: TOPS-20 Distribution: ;
ReSent-Subject: Re: LAT and KEA! (and others)
ReSent-Message-ID: <[email protected]>

TOMMYT (Tommy Timesharing) has a dedicated ethernet interface, but
I've never gotten anywhere with DECNET or LAT, either. However, do
let us know if you make any progress on it! Did you do any line
packet snooping? I have had to (very infrequently) do this while
hacking the initial version of the new FTP server and it helped a lot.
I'm clearly going to have to do it again to see what the problem is
with Mac OSX Safari.

There is a free version of LAT for Linux, called 'latd' under Debian.
I've never been able to talk to TOMMYT with it. I don't know where
the problem is. If I ever get to really looking at this, the first
thing that I would want to try would be to connect from my Linux box
to another Linux box to see if that worked. I have a Mac OSX box, but
I haven't checked to see whether I can run latd on it. Does anybody
have any experience with latd? On OSX?

Incidently, I should remark about my Lindows (Debian) host, which I
bought from Walmart for $200. I really think that this was quite a
reasonable price for a DEC20! I only have had two complaints with the
host hardware. The first is that it came with only a measly 128MB of
memory. If you boot it with the Lindows desktop, then you'd be pretty
tight on memory, but you'd still be able to bring up KLH10 micro-
engine. However, the eventual memory use by the Lindows desktop would
eventually grind the system to a halt.

One better approach would be to punt the Lindows graphical interface
altogether and simply boot Debian up in character mode. However, I
didn't remember/couldn't figure out how to do this, so I went to plan
B and bought a gigabyte of memory. This was a lot more than I needed:
as of right now, I'm running with over 250MB free. I thought I might
use the extra memory for a neat idea. At one point, I was considering
changing Tops-20 back to paging to a swapping drum and implementing
the drum in RAM. The IBM 390 does something like this with banked
memory. But, I've tried to concentrate on getting FTP done.

Guess what? The machine won't handle that much memory even though it
is socketed for it and the hardware documentation says you can do it!
I had to call the manufacturer (can't remember their name off hand)
and find out that the BIOS I had couldn't support that much memory.
That sounded like baloney, so I punted a 512MB DIMM and dropped the
host down to 640MB. The system has functioned flawlessly since then.

In fact, as of today, I have been up over 6472 hours; since December
5th of last year and that's with a gazillion MACRO runs and TON of
TCP/IP and FTP hacking. Not bad too shabby, I'd have to say.

The only other complaint I have is that the machine has exactly one
(1) expansion board. That's what has my second ethernet adaptor. I
would have liked to put some other stuff on it, but oh well ...

But hey, what do you want for $200?

1-Sep-2006 21:26:17-PDT,3461;000000000000
Return-Path: <[email protected]>
Received: from pangtzu.panda.com ([206.124.149.117]) by lingling.panda.com with TCP/SMTP; Fri, 1 Sep 2006 21:23:16 -0700 (PDT)
X-Return-Path: <[email protected]>
X-Received: from mta10.srv.hcvlny.cv.net ([167.206.4.205]) by lingling.panda.com with TCP/SMTP; Fri, 1 Sep 2006 17:56:39 -0700 (PDT)
X-Received: from optonline.net (hamstr3.srv.hcvlny.cv.net [167.206.5.10])
by mta10.srv.hcvlny.cv.net
(Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006))
with ESMTP id <[email protected]> for
[email protected]; Fri, 01 Sep 2006 20:55:33 -0400 (EDT)
X-Received: from [10.240.3.201] (Forwarded-For: [10.240.3.201])
by mstr3.srv.hcvlny.cv.net (mshttpd); Sat, 02 Sep 2006 00:56:32 +0000 (GMT)
Date: Sat, 02 Sep 2006 00:56:32 +0000 (GMT)
From: [email protected]
Subject: Re: RE: LAT and KEA! (and others)
In-reply-to:
<435B77BA27FC254099B1763E498DEF6610371C@va1exc02.SNAADS.sinenomine.net>
To: David Boyes <[email protected]>
Cc: [email protected]
Message-id: <[email protected]>
MIME-version: 1.0
X-Mailer: Sun Java(tm) System Messenger Express 6.2-6.01 (built Apr 3 2006)
Content-type: text/plain; charset=us-ascii
Content-language: en
Content-transfer-encoding: 7BIT
Content-disposition: inline
X-Accept-Language: en
Priority: normal
References: <[email protected]>
<435B77BA27FC254099B1763E498DEF6610371C@va1exc02.SNAADS.sinenomine.net>
ReSent-Date: Fri, 1 Sep 2006 21:23:08 -0700 (PDT)
ReSent-From: TOPS-20 List Moderator <[email protected]>
ReSent-To: TOPS-20 Distribution: ;
ReSent-Subject: Re: RE: LAT and KEA! (and others)
ReSent-Message-ID: <[email protected]>

> Dunno about the server side, but here's a cheap suggestion to get
> LAT on the wire. Find a spare Cisco 25xx running IOS. You can telnet
> into them using your fave network client, type 'lat ' and you're
> there.

The Linux LAT implementation (latd) is free and has a LAT client. I
have no information as to whether this would better than the IOS
implementation (or if it is even functional).

; IOS has a pretty decent LAT client implementation don't remember
; whether it could be a server too.

It's done by Meridian, which is the same company that did SuperLAT.
There are four Non-VAX/TOPS-20/TOPS-10 software LAT implementations
that I am aware of: PATHWORKS/32, KEA!, SuperLAT and latd. SuperLAT
is available for $165.

; 2501s are going for about $50 on eBay these days

Well, that's better than the $200 I spent on my 20, but not as good as
'free' (see above)

> you probably have the AUI-to-xBaseT converter somewhere.

Oh sure, but finding it? Don't ask about the celler ... Sigh ...

; A 2509 would give you serial ports to connect to the 20.

Yes, but wouldn't latd under Linux also do this for me?

> The 25xxs are reliable as hell,

Dunno about them, but I have no complaint about my 2600's. One time,
I had an APC UPS go completely crispy on me. It cycled the power on
and off every 3 minutes for over an hour before we finally figured out
what was going on. Zorched some stuff in the rack; 2600 was fine.
Phew!

> (and aren't quite as cranky to configure as any of the DECservers).

Well, is this saying all that much? Configuring IOS for VPNs and fail
over gave me a bad case of indigestion.

1-Sep-2006 21:27:43-PDT,3148;000000000000
Return-Path: <[email protected]>
Received: from pangtzu.panda.com ([206.124.149.117]) by lingling.panda.com with TCP/SMTP; Fri, 1 Sep 2006 21:23:36 -0700 (PDT)
X-Return-Path: <[email protected]>
X-Received: from mta2.srv.hcvlny.cv.net ([167.206.4.197]) by lingling.panda.com with TCP/SMTP; Fri, 1 Sep 2006 18:34:32 -0700 (PDT)
X-Received: from optonline.net (hamstr3.srv.hcvlny.cv.net [167.206.5.10])
by mta2.srv.hcvlny.cv.net
(Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006))
with ESMTP id <[email protected]>; Fri,
01 Sep 2006 21:34:25 -0400 (EDT)
X-Received: from [10.240.3.201] (Forwarded-For: [10.240.3.201])
by mstr3.srv.hcvlny.cv.net (mshttpd); Sat, 02 Sep 2006 01:34:25 +0000 (GMT)
Date: Sat, 02 Sep 2006 01:34:25 +0000 (GMT)
From: [email protected]
Subject: Re: LAT and KEA! (and others)
In-reply-to: <CMM.0.90.4.1157096572.billw@pita>
To: William Chops Westfield <[email protected]>
Cc: TOPS-20 List Moderator <[email protected]>, [email protected]
Message-id: <[email protected]>
MIME-version: 1.0
X-Mailer: Sun Java(tm) System Messenger Express 6.2-6.01 (built Apr 3 2006)
Content-type: text/plain; charset=us-ascii
Content-language: en
Content-transfer-encoding: 7BIT
Content-disposition: inline
X-Accept-Language: en
Priority: normal
References: "31 Aug 2006 20:08:24 +0000" <CMM.0.90.4.1157096572.billw@pita>
ReSent-Date: Fri, 1 Sep 2006 21:23:29 -0700 (PDT)
ReSent-From: TOPS-20 List Moderator <[email protected]>
ReSent-To: TOPS-20 Distribution: ;
ReSent-Subject: Re: LAT and KEA! (and others)
ReSent-Message-ID: <[email protected]>

> Do the kernels you're running have the Stanford TCP/TVT
> improvements?

Dunno ... How could I tell? The latest stuff I that have is MRC's
Panda distribution of May 2004. Mark?

> You should certainly see better than 19.2 Kbps effective throughput

Oh, I do! When Kermit'ing off my machine with a packet size of 3999
characters, I have cleared 68 Kbps. However, if I use my new FTP
server to transfer the same file, I typically clear over 1,726 Kbps.
I know that Kermit incurs more CPU overhead than FTP, but this is 25
times slower!

> Likewise, kermit and xmodem downloads to the PC from the 20 were
> faster at higher async speeds.

Yup. But ever since FdC put in large packets and SIN%/SOUT%, the
performance of Kermit has substantially improved. I would have liked
to have seen what it would have done on the terminal server. Maybe it
would have flooded them.

> So I'd think that one of the 20 emulators OUGHT to provide pretty
> zippy telnet performance...

It's certainly faster than anything I ever had (and I'm running
about 3x KL speed), but when ssh'ing into a Linux box, the gnuEmacs
literally blinks stuff into position (again, this is with ssh
overhead).

I know I'm comparing Apples and Pineapples, but the new Tops-20 FTP
server performance has made me wonder about how much oompf I'm getting
(or can get) out of the Tops-20 TELNET server and whether LAT would
have more gas.

1-Sep-2006 22:05:25-PDT,1745;000000000000
Return-Path: <[email protected]>
Received: from pangtzu.panda.com ([206.124.149.117]) by lingling.panda.com with TCP/SMTP; Fri, 1 Sep 2006 22:03:54 -0700 (PDT)
X-Return-Path: <[email protected]>
X-Received: from pangtzu.panda.com ([206.124.149.117]) by lingling.panda.com with TCP/SMTP; Fri, 1 Sep 2006 21:32:18 -0700 (PDT)
Date: Fri, 1 Sep 2006 21:32:13 -0700 (PDT)
From: Mark Crispin <[email protected]>
Sender: [email protected]
To: [email protected]
cc: William Chops Westfield <[email protected]>, [email protected]
Subject: Re: LAT and KEA! (and others)
In-Reply-To: <[email protected]>
Message-ID: <[email protected]>
References: "31 Aug 2006 20:08:24 +0000" <CMM.0.90.4.1157096572.billw@pita>
<[email protected]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
ReSent-Date: Fri, 1 Sep 2006 22:03:46 -0700 (PDT)
ReSent-From: TOPS-20 List Moderator <[email protected]>
ReSent-To: TOPS-20 Distribution: ;
ReSent-Subject: Re: LAT and KEA! (and others)
ReSent-Message-ID: <[email protected]>

On Sat, 2 Sep 2006, [email protected] wrote:
>> Do the kernels you're running have the Stanford TCP/TVT
>> improvements?
> Dunno ... How could I tell? The latest stuff I that have is MRC's
> Panda distribution of May 2004. Mark?

Yes (considering that I wrote many of the improvements) but it's possible
that there were further improvements at Stanford after Panda forked c.
1986.

TOPS-20 has truly tiny buffers for TTYs, and that's the big problem.

-- Mark --

http://panda.com/tops-20
TOPS-20: a great improvement over its successors
2-Sep-2006 09:09:47-PDT,2834;000000000000
Return-Path: <[email protected]>
Received: from pangtzu.panda.com ([206.124.149.117]) by lingling.panda.com with TCP/SMTP; Sat, 2 Sep 2006 09:08:05 -0700 (PDT)
X-Return-Path: <[email protected]>
X-Received: from sesame.cc.columbia.edu ([128.59.59.56]) by lingling.panda.com with TCP/SMTP; Sat, 2 Sep 2006 08:46:26 -0700 (PDT)
X-Received: from sesame.cc.columbia.edu (localhost [127.0.0.1])
by sesame.cc.columbia.edu (8.13.7/8.13.6) with ESMTP id k82FkK4E001026;
Sat, 2 Sep 2006 11:46:20 -0400 (EDT)
X-Received: (from fdc@localhost)
by sesame.cc.columbia.edu (8.13.7/8.12.8/Submit) id k82FkGhE001025;
Sat, 2 Sep 2006 11:46:16 -0400 (EDT)
Date: Sat, 2 Sep 2006 11:46:16 EDT
From: Frank da Cruz <[email protected]>
To: [email protected]
Cc: [email protected]
Subject: Re: RE: LAT and KEA! (and others)
In-Reply-To: <[email protected]>
Message-ID: <[email protected]>
ReSent-Date: Sat, 2 Sep 2006 09:07:56 -0700 (PDT)
ReSent-From: TOPS-20 List Moderator <[email protected]>
ReSent-To: TOPS-20 Distribution: ;
ReSent-Subject: Re: RE: LAT and KEA! (and others)
ReSent-Message-ID: <[email protected]>

> Apropos of LAT, I just found the following in the documentation for
> Kermit-95, which I was using to do speed tests off my 20:
>
> " WARNING: Uploading files on a LAT connection is problematic due to
> intrinsic limitations of LAT buffering. Using 90-byte packets and
> 1 window slot seems to work in most cases (tell VMS C-Kermit to
> "set receive packet-length 90"); greater lengths tend to hang the
> VMS session. Downloads can use any packet length or window size.
> WARNING: Do NOT tell VMS or VMS C-Kermit to disable flow control.
> VMS C-Kermit MUST have "set flow xon/xoff". "
>
> Was this a problem with VMS LAT or LAT itself?
>
Or the LAT box? Dunno, nothing to compare it with.

> What was your experience with downloads? Did you ever get a chance to
> try Kermit over LAT to CU20B before it was shut down? How about LAT
> into CUNIXC? That had LAT, didn't it?
>
Yes, they both had LAT, but Kermit didn't have it until much later.
Kermit didn't actually have LAT either, it just had an interface to the
various 3rd-party LAT products that existed at the time for Windows --
DEC PATHWORKS, Interconnections TES, Meridian SuperLAT -- all long-gone
as far as I know.

For the crowd: CUNIXC was our first timesharing system post TOPS-20. It
was a VAX 8650 running Ultrix. We chose it because (a) it could use many
of the DEC-20 peripherals, (b) it supported DECnet, and (c) DEC gave us a
good deal because they felt bad about cancelling the -20. There would be
a rather large DECnet on campus for some years to come.

- Frank
2-Sep-2006 09:11:12-PDT,2594;000000000000
Return-Path: <[email protected]>
Received: from pangtzu.panda.com ([206.124.149.117]) by lingling.panda.com with TCP/SMTP; Sat, 2 Sep 2006 09:08:32 -0700 (PDT)
X-Return-Path: <[email protected]>
X-Received: from sesame.cc.columbia.edu ([128.59.59.56]) by lingling.panda.com with TCP/SMTP; Sat, 2 Sep 2006 09:01:13 -0700 (PDT)
X-Received: from sesame.cc.columbia.edu (localhost [127.0.0.1])
by sesame.cc.columbia.edu (8.13.7/8.13.6) with ESMTP id k82G16ug001809;
Sat, 2 Sep 2006 12:01:06 -0400 (EDT)
X-Received: (from fdc@localhost)
by sesame.cc.columbia.edu (8.13.7/8.12.8/Submit) id k82G16rr001808;
Sat, 2 Sep 2006 12:01:06 -0400 (EDT)
Date: Sat, 2 Sep 2006 12:01:06 EDT
From: Frank da Cruz <[email protected]>
To: [email protected]
Cc: TOPS-20 List Moderator <[email protected]>,
William Chops Westfield <[email protected]>,
TOPS-20 List Moderator <[email protected]>,
[email protected]
Subject: Re: LAT and KEA! (and others)
In-Reply-To: <[email protected]>
Message-ID: <[email protected]>
ReSent-Date: Sat, 2 Sep 2006 09:08:24 -0700 (PDT)
ReSent-From: TOPS-20 List Moderator <[email protected]>
ReSent-To: TOPS-20 Distribution: ;
ReSent-Subject: Re: LAT and KEA! (and others)
ReSent-Message-ID: <[email protected]>

> > You should certainly see better than 19.2 Kbps effective throughput
>
> Oh, I do! When Kermit'ing off my machine with a packet size of 3999
> characters, I have cleared 68 Kbps. However, if I use my new FTP
> server to transfer the same file, I typically clear over 1,726 Kbps.
> I know that Kermit incurs more CPU overhead than FTP, but this is 25
> times slower!
>
Modern Kermits aren't slower, but DEC-10 and -20 Kermit were written in
the serial port days, where the connection speed itself was the bottleneck,
and were never tuned for high-speed connections, except for the little bit
that I did a few years ago, as you noted...

> ... ever since FdC put in large packets and SIN%/SOUT%, the
> performance of Kermit has substantially improved. I would have liked
> to have seen what it would have done on the terminal server. Maybe it
> would have flooded them.
>
Depends on what the terminal server does for flow control. That was always
a sore point, especially with DEC ones. Even the DEC ones that supported
RTS/CTS came with itty-bitty RJ connectors that didn't have enough wires, so
you had to choose between flow control and such things as CD and DTR.

- Frank
2-Sep-2006 17:36:19-PDT,5843;000000000000
Return-Path: <[email protected]>
Received: from pangtzu.panda.com ([206.124.149.117]) by lingling.panda.com with TCP/SMTP; Sat, 2 Sep 2006 17:34:26 -0700 (PDT)
X-Return-Path: <[email protected]>
X-Received: from mail.math.utah.edu ([155.101.98.135]) by lingling.panda.com with TCP/SMTP; Sat, 2 Sep 2006 11:17:27 -0700 (PDT)
X-Received: from psi.math.utah.edu (psi.math.utah.edu [155.101.96.19])
by mail.math.utah.edu (8.13.6/8.13.6) with ESMTP id k82IHLpR024752;
Sat, 2 Sep 2006 12:17:21 -0600 (MDT)
X-Received: from psi.math.utah.edu (localhost [127.0.0.1])
by psi.math.utah.edu (8.13.6/8.13.6) with ESMTP id k82IHLVC018035;
Sat, 2 Sep 2006 12:17:21 -0600 (MDT)
X-Received: (from beebe@localhost)
by psi.math.utah.edu (8.13.6/8.13.6/Submit) id k82IHL4p018034;
Sat, 2 Sep 2006 12:17:21 -0600 (MDT)
Date: Sat, 2 Sep 2006 12:17:21 -0600 (MDT)
From: "Nelson H. F. Beebe" <[email protected]>
To: [email protected]
Cc: [email protected], [email protected]
X-US-Mail: "Department of Mathematics, 110 LCB, University of Utah, 155 S
1400 E RM 233, Salt Lake City, UT 84112-0090, USA"
X-Telephone: +1 801 581 5254
X-FAX: +1 801 585 1640, +1 801 581 4148
X-URL: http://www.math.utah.edu/~beebe
Subject: [tops-20] Re: TOPS-20 FTP server
Message-ID: <[email protected]>
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0 (mail.math.utah.edu [155.101.98.135]); Sat, 02 Sep 2006 12:17:21 -0600 (MDT)
ReSent-Date: Sat, 2 Sep 2006 17:34:14 -0700 (PDT)
ReSent-From: TOPS-20 List Moderator <[email protected]>
ReSent-To: TOPS-20 Distribution: ;
ReSent-Subject: [tops-20] Re: TOPS-20 FTP server
ReSent-Message-ID: <[email protected]>

[email protected] has been keeping us nicely informed on the
development of a new FTP server for TOPS-20.

Many Internet FTP sites on Unix systems support getting a directory
tree in one or more archive formats. Ours does so, and here is an
example of several such retrievals:

% ncftp ftp://ftp.math.utah.edu
...
ncftp / > cd pub/
ncftp /pub > get pathfind.zip
pathfind.zip: 265098 bytes 550.78 kB/s
ncftp /pub > get pathfind.tar
pathfind.tar: 286720 bytes 696.49 kB/s
ncftp /pub > get pathfind.tar.gz
pathfind.tar.gz: 266240 bytes 2.01 MB/s
ncftp /pub > get pathfind.tar.bz2
pathfind.tar.bz2: 256000 bytes 647.48 kB/s
ncftp /pub > get pathfind.tgz
pathfind.tgz: 266240 bytes 2.52 MB/s
ncftp /pub > get pathfind.jar
pathfind.jar: 263033 bytes 1.69 MB/s
ncftp /pub > get pathfind.pax
get pathfind.pax: server said: pathfind.pax: No such file or directory.

In each case, the returned archive files did not exist at the time of
the initial connection, but instead were created on the fly. Here is
what they look like at the receiving end:

% file *
pathfind.jar: Zip archive data, at least v1.0 to extract
pathfind.tar: POSIX tar archive
pathfind.tar.bz2: bzip2 compressed data, block size = 900k
pathfind.tar.gz: gzip compressed data, from Unix
pathfind.tgz: gzip compressed data, from Unix
pathfind.zip: Zip archive data, at least v1.0 to extract
pathfind.zoo: Zoo archive data, v2.10, modify: v2.0+, extract: v1.0+

ncftp can also do recursive directory retrievals:

ncftp /pub > get -r pathfind
pathfind (TAR): 286720 bytes 1.08 MB/s

ncftp discovered that a tar file was returned, and unpacked it
on-the-fly, creating a subdirectory with the mirrored contents. Had
the server not returned a tar file, ncftp would have parsed the
returned listing, and recursively fetched files one at a time.

Would it make sense, and be feasible, for the new TOPS-20 FTP server
to be able to support something like that? For example, for text-only
directories, a tar file could be a reasonable thing to ask for.

At present, this is what happens when I ftp fro Unix to our TOPS-20
system:

ncftp / > ls
TOPS20:<BEEBE>
...
TMP.DIRECTORY.1
..

ncftp / > get tmp
get tmp: server said: File not accessable. No such file type
ncftp / > get tmp.directory
tmp.directory: 4608 bytes 4.37 kB/s
ncftp / > get tmp.directory.1
tmp.directory.1: 4608 bytes 4.37 kB/s

Back on Unix, I find:

% file tmp*
tmp.directory: 8086 relocatable (Microsoft)
tmp.directory.1: 8086 relocatable (Microsoft)

A peak at that file with emacs shows an unintelligible mess of binary
data, and it probably isn't good for anything other than an argument
of the rm command.

As far as I recall, TOPS-20 never really had a good archive exchange
format other than DUMPER tapes, and they were not portable to other
systems, except in a limited fashion, via the read20 utility,
available at

ftp://ftp.math.utah.edu/pub/read20

Maybe we should also be discussing on this list whether something like
a tar20 utility should be designed and developed, or the

TOPS20:<UNSUPPORTED>TAR.EXE.73

tool reexamined and possibly extended, and then moved to
TOPS20:<SYSTEM>.

-------------------------------------------------------------------------------
- Nelson H. F. Beebe Tel: +1 801 581 5254 -
- University of Utah FAX: +1 801 581 4148 -
- Department of Mathematics, 110 LCB Internet e-mail: [email protected] -
- 155 S 1400 E RM 233 [email protected] [email protected] -
- Salt Lake City, UT 84112-0090, USA URL: http://www.math.utah.edu/~beebe/ -
-------------------------------------------------------------------------------
2-Sep-2006 17:39:07-PDT,3521;000000000000
Return-Path: <[email protected]>
Received: from pangtzu.panda.com ([206.124.149.117]) by lingling.panda.com with TCP/SMTP; Sat, 2 Sep 2006 17:37:39 -0700 (PDT)
X-Return-Path: <[email protected]>
X-Received: from b.mail.sonic.net ([64.142.19.5]) by lingling.panda.com with TCP/SMTP; Sat, 2 Sep 2006 17:30:52 -0700 (PDT)
X-Received: from Amiga.local (64-142-29-114.dsl.static.sonic.net [64.142.29.114])
by b.mail.sonic.net (8.13.8.Beta0-Sonic/8.13.7) with ESMTP id k830UhL7020877
for <[email protected]>; Sat, 2 Sep 2006 17:30:43 -0700
Date: Sat, 2 Sep 2006 17:30:43 -0700 (PDT)
From: Fred Wright <[email protected]>
X-Sender: [email protected]
Reply-To: Fred Wright <[email protected]>
To: TOPS-20 Hackers and Yackers <[email protected]>
Subject: Re: more on the APL overflow hanging problem
In-Reply-To: <[email protected]>
Message-ID: <[email protected]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
ReSent-Date: Sat, 2 Sep 2006 17:37:25 -0700 (PDT)
ReSent-From: TOPS-20 List Moderator <[email protected]>
ReSent-To: TOPS-20 Distribution: ;
ReSent-Subject: Re: more on the APL overflow hanging problem
ReSent-Message-ID: <[email protected]>

On Thu, 24 Aug 2006, Nelson H. F. Beebe wrote:
>
> Mark Crispin asks why factorial of 40 would hang APLSF in a CPU loop.
>
> I suspect it has the same problem that kcc has (but not fortran): overflow
> and underflow on the PDP-10 wrap to small and large values respectively.
> For example,

It can't be that simple. The control flow of factorial is unaffected by
the results, so the only effect of different overflow results would be to
determine which wrong answer comes out. :-) It's conceivable (though not
all that likely) that there's an overflow handler that behaves differently
depending on the result, though.

The "problem" you describe isn't necessarily a problem at all, depending
on what you want to do with overflow cases. One might imagine a setup
that extends range by keeping a high-order exponent in software. In that
case, exponent wraparound (with no effect on the mantissa) is actually
desirable. Since no single FP operation can overflow or underflow more
than once, all it takes is a value that counts up on overflow and down on
underflow.

On Mon, 28 Aug 2006, Mark Crispin wrote:

> Well, I've now tested APLSF on a KL10, an SC-40, an XKL-1, and a klh10.
> The KL10 and XKL-1 both give a DOMAIN ERROR with the operation
> # / .IO 34
> The SC-40 and klh10 both hang. Interesting.

The most intersting part is the difference between the SC-40 and KL, since
SC-x0s try fairly hard to be KL-compatible. But there also seems to be an
assumption here that the behavior depends solely on the CPU, even though
the OS is involved as well. I'm pretty sure APL is too old to understand
the concept of trap instructions, so I'd expect it to use an OS mechanism
originally designed around the old interrupt-style traps (even on TOPS-20,
since TENEX was designed around the KA). It's clearly too old to know
about G format, or else 34! wouldn't be a problem. :-)

One could always start by looking at the trap instruction while APL is
running, preferably while in a legitimate computational loop in case it
"context switches" the trap setup between running and waiting for
commands.

I don't seem to have APL here for either system.

Fred Wright

3-Sep-2006 21:11:37-PDT,2010;000000000000
Return-Path: <[email protected]>
Received: from pangtzu.panda.com ([206.124.149.117]) by lingling.panda.com with TCP/SMTP; Sun, 3 Sep 2006 21:09:40 -0700 (PDT)
X-Return-Path: <[email protected]>
X-Received: from sesame.cc.columbia.edu ([128.59.59.56]) by lingling.panda.com with TCP/SMTP; Sun, 3 Sep 2006 08:48:07 -0700 (PDT)
X-Received: from sesame.cc.columbia.edu (localhost [127.0.0.1])
by sesame.cc.columbia.edu (8.13.7/8.13.6) with ESMTP id k83Fm1v9007291;
Sun, 3 Sep 2006 11:48:01 -0400 (EDT)
X-Received: (from fdc@localhost)
by sesame.cc.columbia.edu (8.13.7/8.12.8/Submit) id k83FlutN007271;
Sun, 3 Sep 2006 11:47:56 -0400 (EDT)
Date: Sun, 3 Sep 2006 11:47:56 EDT
From: Frank da Cruz <[email protected]>
To: "Nelson H. F. Beebe" <[email protected]>
Cc: TOPS-20 List Moderator <[email protected]>,
[email protected], [email protected], [email protected]
Subject: Re: [tops-20] Re: TOPS-20 FTP server
In-Reply-To: <[email protected]>
Message-ID: <[email protected]>
ReSent-Date: Sun, 3 Sep 2006 21:09:30 -0700 (PDT)
ReSent-From: TOPS-20 List Moderator <[email protected]>
ReSent-To: TOPS-20 Distribution: ;
ReSent-Subject: Re: [tops-20] Re: TOPS-20 FTP server
ReSent-Message-ID: <[email protected]>

> Would it make sense, and be feasible, for the new TOPS-20 FTP server
> to be able to support something like that? For example, for text-only
> directories, a tar file could be a reasonable thing to ask for.
>
But when transferring between platforms with different text formats, you get
the foreign text format after unpacking the Zip archive or tarball. These
are platform-specific archive formats that really should not be used between
unlike file systems, and should not be used as a transport format on a
platform-neutral computer network. It's especially bad when you mix text and
binary files in the same archive.

- Frank
3-Sep-2006 21:13:01-PDT,2616;000000000000
Return-Path: <[email protected]>
Received: from pangtzu.panda.com ([206.124.149.117]) by lingling.panda.com with TCP/SMTP; Sun, 3 Sep 2006 21:10:08 -0700 (PDT)
X-Return-Path: <[email protected]>
X-Received: from mail2.panix.com ([166.84.1.73]) by lingling.panda.com with TCP/SMTP; Sun, 3 Sep 2006 18:49:39 -0700 (PDT)
X-Received: from panix5.panix.com (panix5.panix.com [166.84.1.5])
by mail2.panix.com (Postfix) with ESMTP id EAB3A9D8A9
for <[email protected]>; Sun, 3 Sep 2006 21:49:30 -0400 (EDT)
X-Received: (from alderson@localhost)
by panix5.panix.com (8.11.6p3/8.8.8/PanixN1.1) id k841nVb20086;
Sun, 3 Sep 2006 21:49:31 -0400 (EDT)
Date: Sun, 3 Sep 2006 21:49:31 -0400 (EDT)
Message-Id: <[email protected]>
From: Rich Alderson <[email protected]>
To: [email protected]
In-reply-to: <[email protected]>
Subject: Re: [tops-20] Re: TOPS-20 FTP server
References: <[email protected]>
ReSent-Date: Sun, 3 Sep 2006 21:10:01 -0700 (PDT)
ReSent-From: TOPS-20 List Moderator <[email protected]>
ReSent-To: TOPS-20 Distribution: ;
ReSent-Subject: Re: [tops-20] Re: TOPS-20 FTP server
ReSent-Message-ID: <[email protected]>

> Date: Sat, 2 Sep 2006 12:17:21 -0600 (MDT)
> From: "Nelson H. F. Beebe" <[email protected]>

> As far as I recall, TOPS-20 never really had a good archive exchange
> format other than DUMPER tapes, and they were not portable to other
> systems, except in a limited fashion, via the read20 utility,
> available at

> ftp://ftp.math.utah.edu/pub/read20

> Maybe we should also be discussing on this list whether something like
> a tar20 utility should be designed and developed, or the

> TOPS20:<UNSUPPORTED>TAR.EXE.73

> tool reexamined and possibly extended, and then moved to TOPS20:<SYSTEM>.

I have for a number of years toyed with the idea of, and spent occasional hours
on, adding a disk-file output option to DUMPER (and, once I started taking care
of a Tops-10 system, BACKUP). It has always seemed to me that this could be
done by checking a flag at the time the DUMPO% (or DUMPI%) was to be executed,
and calling a write-to-disk routine if the flag is set. This gets us the best
of all worlds--a disk file in a format known to older tools (which can be made
to understand it easily).

Making the output file compatible with the tape format used by SimH and KLH10
would be very useful, hmm?

Rich
3-Sep-2006 21:14:33-PDT,8900;000000000000
Return-Path: <[email protected]>
Received: from pangtzu.panda.com ([206.124.149.117]) by lingling.panda.com with TCP/SMTP; Sun, 3 Sep 2006 21:12:08 -0700 (PDT)
X-Return-Path: <[email protected]>
X-Received: from a.mail.sonic.net ([64.142.16.245]) by lingling.panda.com with TCP/SMTP; Sun, 3 Sep 2006 14:51:41 -0700 (PDT)
X-Received: from Amiga.local (64-142-29-114.dsl.static.sonic.net [64.142.29.114])
by a.mail.sonic.net (8.13.8.Beta0-Sonic/8.13.7) with ESMTP id k83LpZIr010619
for <[email protected]>; Sun, 3 Sep 2006 14:51:35 -0700
Date: Sun, 3 Sep 2006 14:51:35 -0700 (PDT)
From: Fred Wright <[email protected]>
X-Sender: [email protected]
Reply-To: Fred Wright <[email protected]>
To: TOPS-20 Hackers and Yackers <[email protected]>
Subject: Re: LAT and KEA! (and others)
In-Reply-To: <[email protected]>
Message-ID: <[email protected]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
ReSent-Date: Sun, 3 Sep 2006 21:12:00 -0700 (PDT)
ReSent-From: TOPS-20 List Moderator <[email protected]>
ReSent-To: TOPS-20 Distribution: ;
ReSent-Subject: Re: LAT and KEA! (and others)
ReSent-Message-ID: <[email protected]>

On Thu, 31 Aug 2006, Mark Crispin wrote:
> On Thu, 31 Aug 2006, [email protected] wrote:

> > Does the server LAT implementation on Tops-20 still work under KLH10?
> > Has ANYBODY actually used this (or tried to)? Do I have to do
> > anything funny with the ethernet addresses?
>
> Almost certainly, you need to make the Ethernet address (MAC address) be
> one of the DECnet addresses.

Nope. LAT has nothing to do with DECnet, and doesn't require DECnet
Ethernet addresses. I've even seen a case where setting the Ethernet
address to the DECnet value *broke* LAT. :-) However, that had nothing to
do with the particular address - it's just that that particular "server"
implementation blacklisted any host that was fickle about its Ethernet
address. To get around it, I had to add a delay before starting LAT
multicasts, so that there was time to switch the address before the first
one.

*Booting* a DECserver uses MOP, which is part of DECnet, but I'm not sure
MOP is picky about the Ethernet address. In fact, I'm inclined to doubt
it, since there's a "mopd" for *nix kicking around (which I haven't
tried), and I expect that most *nix systems would take a dim view of
clobbering their Ethernet addresses (especially to easily conflicting
values) just to boot a DECserver.

[...]
> So far, so good; then I tried configuring Hsinghsing, which shares an
> interface with the UNIX end (Mac OS X) to have a DECnet MAC address. I
> spent quite a well fighting before I got it up and working, but ultimately
> Lingling and Hsinghsing never talked DECnet to each other. According to
> NCP, they sent their DECnet packets but never heard any DECnet packets.
> However, TCP/IP worked.

Tcpdump is your friend. :-)

On Sat, 2 Sep 2006 [email protected] wrote:

> One better approach would be to punt the Lindows graphical interface
> altogether and simply boot Debian up in character mode. However, I
> didn't remember/couldn't figure out how to do this, so I went to plan

Can't you boot it in single-user mode?

> B and bought a gigabyte of memory. This was a lot more than I needed:
> as of right now, I'm running with over 250MB free. I thought I might
> use the extra memory for a neat idea. At one point, I was considering
> changing Tops-20 back to paging to a swapping drum and implementing
> the drum in RAM. The IBM 390 does something like this with banked

That's only useful when you're stuck with the old 4 meg limit. :-)

> Guess what? The machine won't handle that much memory even though it
> is socketed for it and the hardware documentation says you can do it!
> I had to call the manufacturer (can't remember their name off hand)
> and find out that the BIOS I had couldn't support that much memory.
> That sounded like baloney, so I punted a 512MB DIMM and dropped the
> host down to 640MB. The system has functioned flawlessly since then.

If it's really the BIOS that's the problem, then they're idiots, but what
do you expect from a WalMart computer? But note that there are *many*
more parameters of RAM than just size and speed, all of which have to meet
certain requirements in order to work, and none of which are readily
provided by the manufactureres of either motherboards or RAM modules. You
might check crucial.com.

And if the BIOS is the only issue, then there's no reason why the OS
couldn't ignore the BIOS configuration and set up its own. After all, if
Windows can manage to ignore BIOS settings and do its own configuration of
RAM that *doesn't* work, why couldn't another OS set up its own
configuration for RAM that does. :-)

On Sat, 2 Sep 2006 [email protected] wrote:

> Oh, I do! When Kermit'ing off my machine with a packet size of 3999
> characters, I have cleared 68 Kbps. However, if I use my new FTP
> server to transfer the same file, I typically clear over 1,726 Kbps.
> I know that Kermit incurs more CPU overhead than FTP, but this is 25
> times slower!

What makes you think CPU overhead is the main issue?

> I know I'm comparing Apples and Pineapples, but the new Tops-20 FTP
> server performance has made me wonder about how much oompf I'm getting
> (or can get) out of the Tops-20 TELNET server and whether LAT would
> have more gas.

Don't count on it. LAT is timer-driven, which caps the speed at the
product of the packet rate and the maximum characters per line per
packet. It was primarily optimized for handling large numbers of
simultaneous sessions with reasonable speed and overhead, not running a
single session really fast.

On Fri, 1 Sep 2006, Mark Crispin wrote:

> TOPS-20 has truly tiny buffers for TTYs, and that's the big problem.

Exactly. I did quite a bit of speedup in the TVTSRV/SCSNER area in the
TOPS-10 case, for a customer that was doing large upload bursts from
emulations of block-mode terminals. Although some of the improvements
were applicable to TOPS-20 as well, TOPS-10 already had its terminal
buffers in an extended section, while TOPS-20 still has them stuck in
section 0. That seriously limits the allowable receive window (especially
once one has fixed the crock where it would offer window without
corresponding buffers, and then just discard the extra packets when they
arrived). I believe extendifying DTESRV is the main prerequisite for
fixing TOPS-20's terminal buffering.

In my (well, SC's) version of TOPS-20, there are only three kinds of code
that still run in section 0:

1) Various stuff in initialization, shutdown, and BUGxxx handling.

2) A small bit in the cluster JSYS that does the "remote" MTOPR% in
section 0 to keep the device designator from being misinterpreted as a
OWGBP.

3) Substantial portions of DTESRV.

On Sat, 2 Sep 2006, Frank da Cruz wrote:

> Modern Kermits aren't slower, but DEC-10 and -20 Kermit were written in
> the serial port days, where the connection speed itself was the bottleneck,
> and were never tuned for high-speed connections, except for the little bit
> that I did a few years ago, as you noted...

Well, both the original 94-character packet size limit and the original
lockstep acknowledgment mechanism were *more* serious limitations (at
least in terms of absolute speed) on serial lines than on net connections.
So I'd hardly call the original Kermit "serial optimized". It was known
more for robustness than performance.

> > ... ever since FdC put in large packets and SIN%/SOUT%, the
> > performance of Kermit has substantially improved. I would have liked
> > to have seen what it would have done on the terminal server. Maybe it
> > would have flooded them.
> >
> Depends on what the terminal server does for flow control. That was always
> a sore point, especially with DEC ones. Even the DEC ones that supported
> RTS/CTS came with itty-bitty RJ connectors that didn't have enough wires, so
> you had to choose between flow control and such things as CD and DTR.

According to the DECserver pinouts I found, it had CTS, RTS, DTR, and
DSR. The only real deficiency there is in having DSR instead of CD, since
DSR might be more or less equivalent to CD, or might be more or less
always on, depending on the modem. Hence CD is a better choice when
you're short on pins.

Thus, any conflict between CTS/RTS flow control and modem control may have
been due to internal hardware deficiencies, or may have been due to
software deficiencies, but certainly wasn't due to a pin shortage. After
all, a DB-9 only has one more pin than an RJ-45, and it includes RI.

Fred Wright

4-Sep-2006 09:10:03-PDT,2308;000000000000
Return-Path: <[email protected]>
Received: from pangtzu.panda.com ([206.124.149.117]) by lingling.panda.com with TCP/SMTP; Mon, 4 Sep 2006 09:08:15 -0700 (PDT)
X-Return-Path: <[email protected]>
X-Received: from sesame.cc.columbia.edu ([128.59.59.56]) by lingling.panda.com with TCP/SMTP; Mon, 4 Sep 2006 08:37:34 -0700 (PDT)
X-Received: from sesame.cc.columbia.edu (localhost [127.0.0.1])
by sesame.cc.columbia.edu (8.13.7/8.13.6) with ESMTP id k84FbQaD008289;
Mon, 4 Sep 2006 11:37:26 -0400 (EDT)
X-Received: (from fdc@localhost)
by sesame.cc.columbia.edu (8.13.7/8.12.8/Submit) id k84FbQiN008288;
Mon, 4 Sep 2006 11:37:26 -0400 (EDT)
Date: Mon, 4 Sep 2006 11:37:26 EDT
From: Frank da Cruz <[email protected]>
To: Rich Alderson <[email protected]>
Cc: TOPS-20 List Moderator <[email protected]>,
[email protected]
Subject: Re: [tops-20] Re: TOPS-20 FTP server
In-Reply-To: <[email protected]>
Message-ID: <[email protected]>
ReSent-Date: Mon, 4 Sep 2006 09:08:03 -0700 (PDT)
ReSent-From: TOPS-20 List Moderator <[email protected]>
ReSent-To: TOPS-20 Distribution: ;
ReSent-Subject: Re: [tops-20] Re: TOPS-20 FTP server
ReSent-Message-ID: <[email protected]>

> I have for a number of years toyed with the idea of, and spent occasional
> hours on, adding a disk-file output option to DUMPER (and, once I started
> taking care of a Tops-10 system, BACKUP). It has always seemed to me that
> this could be done by checking a flag at the time the DUMPO% (or DUMPI%)
> was to be executed, and calling a write-to-disk routine if the flag is
> set. This gets us the best of all worlds--a disk file in a format known
> to older tools (which can be made to understand it easily).
>
> Making the output file compatible with the tape format used by SimH and
> KLH10 would be very useful, hmm?
>
On VMS, BACKUP savesets have variable length records on disk, so
transferring them over the Internet usually ends in tears. On on-disk
DUMPER or BACKUP saveset would, hopefully, be a "simple stream of bytes".
If the internal format has records, they should be encoded in some manner,
perhaps similar to ANSI D tape formatting.

- Frank
4-Sep-2006 09:11:29-PDT,4456;000000000000
Return-Path: <[email protected]>
Received: from pangtzu.panda.com ([206.124.149.117]) by lingling.panda.com with TCP/SMTP; Mon, 4 Sep 2006 09:08:54 -0700 (PDT)
X-Return-Path: <[email protected]>
X-Received: from sesame.cc.columbia.edu ([128.59.59.56]) by lingling.panda.com with TCP/SMTP; Mon, 4 Sep 2006 08:59:34 -0700 (PDT)
X-Received: from sesame.cc.columbia.edu (localhost [127.0.0.1])
by sesame.cc.columbia.edu (8.13.7/8.13.6) with ESMTP id k84FxSOL009279;
Mon, 4 Sep 2006 11:59:28 -0400 (EDT)
X-Received: (from fdc@localhost)
by sesame.cc.columbia.edu (8.13.7/8.12.8/Submit) id k84FxOR9009278;
Mon, 4 Sep 2006 11:59:24 -0400 (EDT)
Date: Mon, 4 Sep 2006 11:59:24 EDT
From: Frank da Cruz <[email protected]>
To: Fred Wright <[email protected]>
Cc: TOPS-20 List Moderator <[email protected]>,
TOPS-20 Hackers and Yackers <[email protected]>
Subject: Re: LAT and KEA! (and others)
In-Reply-To: <[email protected]>
Message-ID: <[email protected]>
ReSent-Date: Mon, 4 Sep 2006 09:08:46 -0700 (PDT)
ReSent-From: TOPS-20 List Moderator <[email protected]>
ReSent-To: TOPS-20 Distribution: ;
ReSent-Subject: Re: LAT and KEA! (and others)
ReSent-Message-ID: <[email protected]>

> On Sat, 2 Sep 2006, Frank da Cruz wrote:
>
> > Modern Kermits aren't slower, but DEC-10 and -20 Kermit were written in
> > the serial port days, where the connection speed itself was the bottleneck,
> > and were never tuned for high-speed connections, except for the little bit
> > that I did a few years ago, as you noted...
>
> Well, both the original 94-character packet size limit and the original
> lockstep acknowledgment mechanism were *more* serious limitations (at
> least in terms of absolute speed) on serial lines than on net connections.
> So I'd hardly call the original Kermit "serial optimized". It was known
> more for robustness than performance.
>
The 94-character packets and the stop-and-wait nature of the original
protocol were dictated by the DEC-20 (and to some extent by the IBM
mainframe, where connections were half duplex). You can't send a continuous
stream of bytes into the DEC-20 front end. We discovered this even before
Kermit, one night when one of our programmers fell asleep with his head on
the keyboard, causing the keys to autorepeat. The DEC-20 crashed, came up,
crashed, came up, over and over again all night until somebody found him and
woke him up.

We talked to the RSX20F guy about this. Apparently he had never seen a
terminal with an autorepeat feature before. He came to down to see for
himself. Sure enough, anybody could crash the DEC-20 with one finger. His
solution: if characters arrive on a port faster than buffers can be
allocated for them, set the port's speed to 0 for a second. He was kind
of a scary guy.

Anyway, experimentation showed that 94-character packets were safe,
128-character ones were not. So 94 it was.

Now of course, Kermit supports not only long packets, but also sliding
windows and, more recently (2000), streaming:

http://www.columbia.edu/kermit/ckermit70.html#x4.20

> > Depends on what the terminal server does for flow control. That was
> > always a sore point, especially with DEC ones. Even the DEC ones that
> > supported RTS/CTS came with itty-bitty RJ connectors that didn't have
> > enough wires, so you had to choose between flow control and such things
> > as CD and DTR.
>
> According to the DECserver pinouts I found, it had CTS, RTS, DTR, and
> DSR. The only real deficiency there is in having DSR instead of CD, since
> DSR might be more or less equivalent to CD, or might be more or less
> always on, depending on the modem. Hence CD is a better choice when
> you're short on pins.
>
> Thus, any conflict between CTS/RTS flow control and modem control may have
> been due to internal hardware deficiencies, or may have been due to
> software deficiencies, but certainly wasn't due to a pin shortage. After
> all, a DB-9 only has one more pin than an RJ-45, and it includes RI.
>
The DECserver 700-16 had RJ-45 (MMJ) connectors, and in the port
configuration setup you had to choose whether you wanted to have
CTS-DSR-RTS-DTR or RI-DCD-DSR-DTR. I have some notes about this here:

http://www.columbia.edu/kermit/ckvins.html#x3.4

- Frank
4-Sep-2006 09:54:22-PDT,2780;000000000000
Return-Path: <[email protected]>
Received: from pangtzu.panda.com ([206.124.149.117]) by lingling.panda.com with TCP/SMTP; Mon, 4 Sep 2006 09:52:39 -0700 (PDT)
X-Return-Path: <[email protected]>
X-Received: from pangtzu.panda.com ([206.124.149.117]) by lingling.panda.com with TCP/SMTP; Mon, 4 Sep 2006 09:52:06 -0700 (PDT)
Date: Mon, 4 Sep 2006 09:52:01 -0700 (PDT)
From: Mark Crispin <[email protected]>
Sender: [email protected]
To: Frank da Cruz <[email protected]>
cc: TOPS-20 Hackers and Yackers <[email protected]>
Subject: Re: LAT and KEA! (and others)
In-Reply-To: <[email protected]>
Message-ID: <[email protected]>
References: <[email protected]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
ReSent-Date: Mon, 4 Sep 2006 09:52:30 -0700 (PDT)
ReSent-From: TOPS-20 List Moderator <[email protected]>
ReSent-To: TOPS-20 Distribution: ;
ReSent-Subject: Re: LAT and KEA! (and others)
ReSent-Message-ID: <[email protected]>

On Mon, 4 Sep 2006, Frank da Cruz wrote:
> The 94-character packets and the stop-and-wait nature of the original
> protocol were dictated by the DEC-20

In all fairness, that limit was in the RSX-20F software running in the
PDP-11/40 front end (also known as "the gutless wonder"). TOPS-20 didn't
"crash" so much as RSX-20F committed murder-suicide.

My theory is that they had a large stash of unsold 11/40 inventory left
over when they discontinued it, and so they decided to use them as KL
front ends rather than install a more competant front end.

It became particular bad with TOPS-20 release 4. Some of us who field
tested release 4 punted on the release 4 version of RSX-20F, and instead
kludged things together to run the release 3A RSX-20F, because it was
impossible to keep the system up for long enough otherwise. DEC was
livid, but there really was no choice: it was either that or abandon the
field test entirely (and I was under *considerable* pressure to do the
latter).

I never quite understood why RSX-20F became so much worse in release 4; it
was something about making it respond faster to XOFF from a VT100.

Another thing that caused a problem was that on unlogged-in lines, TOPS-20
would ring the line's bell whenever some character other than CTRL/C or
RETURN was entered. That back-flow exacerbated the problems caused by an
open line. I removed that beep early on.

DEC later added the TTYSTP feature at the TOPS-20 end to detect open lines
and set their speed to 0.

-- Mark --

http://panda.com/tops-20
TOPS-20: a great improvement over its successors
4-Sep-2006 12:05:35-PDT,2544;000000000000
Return-Path: <[email protected]>
Received: from pangtzu.panda.com ([206.124.149.117]) by lingling.panda.com with TCP/SMTP; Mon, 4 Sep 2006 12:03:47 -0700 (PDT)
X-Return-Path: <[email protected]>
X-Received: from sesame.cc.columbia.edu ([128.59.59.56]) by lingling.panda.com with TCP/SMTP; Mon, 4 Sep 2006 10:07:10 -0700 (PDT)
X-Received: from sesame.cc.columbia.edu (localhost [127.0.0.1])
by sesame.cc.columbia.edu (8.13.7/8.13.6) with ESMTP id k84H74FI012467;
Mon, 4 Sep 2006 13:07:04 -0400 (EDT)
X-Received: (from fdc@localhost)
by sesame.cc.columbia.edu (8.13.7/8.12.8/Submit) id k84H74WG012466;
Mon, 4 Sep 2006 13:07:04 -0400 (EDT)
Date: Mon, 4 Sep 2006 13:07:04 EDT
From: Frank da Cruz <[email protected]>
To: Mark Crispin <[email protected]>
Subject: Re: LAT and KEA! (and others)
In-Reply-To: <[email protected]>
Cc: TOPS-20 Hackers and Yackers <[email protected]>
Message-ID: <[email protected]>
ReSent-Date: Mon, 4 Sep 2006 12:03:40 -0700 (PDT)
ReSent-From: TOPS-20 List Moderator <[email protected]>
ReSent-To: TOPS-20 Distribution: ;
ReSent-Subject: Re: LAT and KEA! (and others)
ReSent-Message-ID: <[email protected]>

> In all fairness, that limit was in the RSX-20F software running in the
> PDP-11/40 front end (also known as "the gutless wonder"). TOPS-20 didn't
> "crash" so much as RSX-20F committed murder-suicide.
>
Right. Death by "ringing the doorbell" (incessantly).

> My theory is that they had a large stash of unsold 11/40 inventory left
> over when they discontinued it, and so they decided to use them as KL
> front ends rather than install a more competant front end.
>
I think they must have had a LOT of them because later they used them in
some of the big VAXes too. As I recall our 8650 looked exactly like a KL
(except for the color), even when you opened the door.

> I never quite understood why RSX-20F became so much worse in release 4; it
> was something about making it respond faster to XOFF from a VT100.
>
Oh right, I forgot about that. When the VT100 was first announced (I think
this was actually before TOPS-20 V4), they proudly brought a demo model by.
The thing they were most proud of was smooth scrolling. Of course the
minute they turned on that feature, the 20 crashed. Talk about embarrassing.

At one point we put a line monitor on the cable and the amount of
Xon/Xoffing was quite amazing.

- Frank
5-Sep-2006 20:28:05-PDT,7278;000000000000
Return-Path: <[email protected]>
Received: from pangtzu.panda.com ([206.124.149.117]) by lingling.panda.com with TCP/SMTP; Tue, 5 Sep 2006 20:26:40 -0700 (PDT)
X-Return-Path: <[email protected]>
X-Received: from mta9.srv.hcvlny.cv.net ([167.206.4.204]) by lingling.panda.com with TCP/SMTP; Tue, 5 Sep 2006 16:30:38 -0700 (PDT)
X-Received: from optonline.net (hamstr3.srv.hcvlny.cv.net [167.206.5.10])
by mta9.srv.hcvlny.cv.net
(Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006))
with ESMTP id <[email protected]> for
[email protected]; Tue, 05 Sep 2006 19:29:47 -0400 (EDT)
X-Received: from [10.240.3.208] (Forwarded-For: [10.240.3.208])
by mstr3.srv.hcvlny.cv.net (mshttpd); Tue, 05 Sep 2006 23:30:21 +0000 (GMT)
Date: Tue, 05 Sep 2006 23:30:21 +0000 (GMT)
From: [email protected]
Subject: Re: [tops-20] Re: TOPS-20 FTP server
In-reply-to: <[email protected]>
To: "Nelson H. F. Beebe" <[email protected]>
Cc: [email protected], [email protected]
Message-id: <[email protected]>
MIME-version: 1.0
X-Mailer: Sun Java(tm) System Messenger Express 6.2-6.01 (built Apr 3 2006)
Content-type: text/plain; charset=us-ascii
Content-language: en
Content-transfer-encoding: 7BIT
Content-disposition: inline
X-Accept-Language: en
Priority: normal
References: <[email protected]>
ReSent-Date: Tue, 5 Sep 2006 20:26:31 -0700 (PDT)
ReSent-From: TOPS-20 List Moderator <[email protected]>
ReSent-To: TOPS-20 Distribution: ;
ReSent-Subject: Re: [tops-20] Re: TOPS-20 FTP server
ReSent-Message-ID: <[email protected]>

> Many Internet FTP sites on Unix systems support getting a directory
> tree in one or more archive formats. Ours does so, and here is an
> example of several such retrievals:
>
> ....
>
> ncftp discovered that a tar file was returned, and unpacked it
> on-the-fly, creating a subdirectory with the mirrored contents. Had
> the server not returned a tar file, ncftp would have parsed the
> returned listing, and recursively fetched files one at a time.
>
> Would it make sense, and be feasible, for the new TOPS-20 FTP server
> to be able to support something like that? For example, for text-
> only directories, a tar file could be a reasonable thing to ask for.

It's an interesting idea.

However, as I read the input example you sent, I wondered if the ncftp
client itself might not be doing the packaging for you. In other
words, was it determining that it was doing a directory, doing an NLST
of the directory, possibly doing an MDTM and SIZE of each file in the
directory and then seperately retrieving each one via RETR commands
that pipe their output into a local archive?

I was unable to determine what commands your FTP server has, if
anything, to support this. It does not provide a FEAT command, so I
don't see what features it implements. When I looked at the command
responses to the HELP command, I didn't immediately see anything that
would support archives, so maybe this stuff is triggered on the fly.

If that is the case, then the Netscape Navigator might break on it
(see my previous post concerning directories). So, I would have to do
some research to understand how to have it invoked. If the server is
doing the packaging, then ncftp might have to condition it somehow to
do this.

For right now, doing an NLST and then asking for each file is the way
FTP was designed. Other than saving the TCP socket set up and tear
down time, using a tar archive isn't going to buy you much as it isn't
compressed. You need another filter to do the compression. For
binary files, executables or files with holes in them, TYPE I (or TYPE
L 36) and STRU P is the way to go.

For ASCII files, doing NLST and seperate retrieves might get you the
files faster, given the extra CPU time involved with the compression
(see below) and OS overhead. Absent compression, TYPE L 7 (see my
previous post) would get you some less bits on the wire.

If you have some time, please turn debugging information on in your
ftp client and send me the output off list. I'd also like to see what
your server is doing if you have logging for this. Be sure to scrub
the output! A number of ftp clients will display the password in
clear text when debugging is turned on!

With respect to the actual nuts and bolts: as I've said earlier, there
are two ways for the new Tops-20 FTP server to do this. The faster
one would most likely be by implementing the archive formats (perhaps
as file structures?) directly in the server itself. That could be
some work, but I don't know enough about these formats to have an
informed opinion as to the magnitude of that effort.

Another way would be to use Tops-20 pipes and port the archive
programs themselves. As I've said earlier, there may be compiler
porting issues (I don't specifically know of any, but one would need
to check) and performance viz-a'-viz straight assembler to be
concerned about. I've also run into some issues with Tops-20 pipes on
PANDA, but I am not pursuing these for the time being.

> At present, this is what happens when I ftp from Unix to our TOPS-20
> system:
>
> ncftp / > ls
> TOPS20:
> ...
> TMP.DIRECTORY.1
> ..

I don't understand what this example means. It looks like you are
getting root and appending this to a file named 'ls'.

> ncftp / > get tmp
> get tmp: server said: File not accessable. No such file type
> ncftp / > get tmp.directory
> tmp.directory: 4608 bytes 4.37 kB/s
> ncftp / > get tmp.directory.1
> tmp.directory.1: 4608 bytes 4.37 kB/s
>
> Back on Unix, I find:
>
> % file tmp*
> tmp.directory: 8086 relocatable (Microsoft)
> tmp.directory.1: 8086 relocatable (Microsoft)
>
> A peak at that file with emacs shows an unintelligible mess of binary
> data, and it probably isn't good for anything other than an argument
> of the rm command.

That's to be expected.

Normally, I believe that a Tops-20 directory file can never be opened
by an ordinary user. I can't remember what reading Tops-20 directory
file is good for, other than when running CHECKD. MRC? However, when
you are running as an enabled wheel or operator, the BBN server will
open the directory file and transfer it anyway.

I don't think this will get you anything immediately useful on a Unix
system, but at least it's good for rm! The new FTP server checks
FB%DIR before doing a transfer and gronks if a directory file is
detected. Netscape Navigator will break if it does not do this.

> As far as I recall, TOPS-20 never really had a good archive exchange
> format other than DUMPER tapes, and they were not portable to other
> systems, except in a limited fashion,

Dumper tapes were portable to other 36 bit systems via interchange
format. DECtapes (the Great Pumpkin had these) were portable to other
PDP systems. What else was there?

> Maybe we should also be discussing on this list whether
> something like a tar20 utility should be designed and developed, or
> the TOPS20:TAR.EXE.73 tool reexamined and possibly extended

Maybe so.

5-Sep-2006 20:28:50-PDT,3572;000000000000
Return-Path: <[email protected]>
Received: from pangtzu.panda.com ([206.124.149.117]) by lingling.panda.com with TCP/SMTP; Tue, 5 Sep 2006 20:26:52 -0700 (PDT)
X-Return-Path: <[email protected]>
X-Received: from mta5.srv.hcvlny.cv.net ([167.206.4.200]) by lingling.panda.com with TCP/SMTP; Tue, 5 Sep 2006 16:41:49 -0700 (PDT)
X-Received: from optonline.net (hamstr3.srv.hcvlny.cv.net [167.206.5.10])
by mta5.srv.hcvlny.cv.net
(Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006))
with ESMTP id <[email protected]>; Tue,
05 Sep 2006 19:41:48 -0400 (EDT)
X-Received: from [10.240.3.208] (Forwarded-For: [10.240.3.208])
by mstr3.srv.hcvlny.cv.net (mshttpd); Tue, 05 Sep 2006 23:41:42 +0000 (GMT)
Date: Tue, 05 Sep 2006 23:41:42 +0000 (GMT)
From: [email protected]
Subject: Re: [tops-20] Re: TOPS-20 FTP server
In-reply-to: <[email protected]>
To: Frank da Cruz <[email protected]>
Cc: "Nelson H. F. Beebe" <[email protected]>,
TOPS-20 List Moderator <[email protected]>, [email protected],
[email protected]
Message-id: <[email protected]>
MIME-version: 1.0
X-Mailer: Sun Java(tm) System Messenger Express 6.2-6.01 (built Apr 3 2006)
Content-type: text/plain; charset=us-ascii
Content-language: en
Content-transfer-encoding: 7BIT
Content-disposition: inline
X-Accept-Language: en
Priority: normal
References: <[email protected]>
<[email protected]>
ReSent-Date: Tue, 5 Sep 2006 20:26:44 -0700 (PDT)
ReSent-From: TOPS-20 List Moderator <[email protected]>
ReSent-To: TOPS-20 Distribution: ;
ReSent-Subject: Re: [tops-20] Re: TOPS-20 FTP server
ReSent-Message-ID: <[email protected]>

> > Would it make sense, and be feasible, for the new TOPS-20 FTP
> > server to be able to support something like that? For example,
> > for text-only directories, a tar file could be a reasonable thing
> > to ask for.

> But when transferring between platforms with different text formats,
> you get the foreign text format after unpacking the Zip archive or
> tarball. These are platform-specific archive formats that really
> should not be used between unlike file systems, and should not be
> used as a transport format on a platform-neutral computer network.
> It's especially bad when you mix text and binary files in the same
> archive.

Indeed. I agree.

However, right now, when in TVFS mode, I have to figure out what kind
of file I'm sending and convert that on the fly to the target platform
which is in practice, either Windows or Unix.

I don't see why I couldn't do the same thing when shoving these things
into an archive.

But all this is anti-mis-featurization to get the FTP server to
produce something sensible when talking to an otherwise brain-damaged
FTP client. Or, to put it bluntly, it's a hack. Better than a
kludge.

Graphical FTP clients are the real problem (but they sure are swell to
use)! I have yet to find a character mode client that doesn't get it
right with some amount of coaxing. Unfortunately, programs that drive
them (such as ange-FTP), don't do the right thing so you're still
hosed.

I don't believe that there were ever anything other than 36 or 8 bit
file systems on the Internet. Since everything is 8 bit, using an 8
bit gzip'ed tar file might not be an immediate catastrophe.

But, it would have been unthinkable not so very long ago.

5-Sep-2006 20:30:16-PDT,8693;000000000000
Return-Path: <[email protected]>
Received: from pangtzu.panda.com ([206.124.149.117]) by lingling.panda.com with TCP/SMTP; Tue, 5 Sep 2006 20:28:03 -0700 (PDT)
X-Return-Path: <[email protected]>
X-Received: from mail.math.utah.edu ([155.101.98.135]) by lingling.panda.com with TCP/SMTP; Tue, 5 Sep 2006 17:31:52 -0700 (PDT)
X-Received: from psi.math.utah.edu (psi.math.utah.edu [155.101.96.19])
by mail.math.utah.edu (8.13.6/8.13.6) with ESMTP id k860Vjcm007179;
Tue, 5 Sep 2006 18:31:45 -0600 (MDT)
X-Received: from psi.math.utah.edu (localhost [127.0.0.1])
by psi.math.utah.edu (8.13.6/8.13.6) with ESMTP id k860VjH3016220;
Tue, 5 Sep 2006 18:31:45 -0600 (MDT)
X-Received: (from beebe@localhost)
by psi.math.utah.edu (8.13.6/8.13.6/Submit) id k860Vj62016219;
Tue, 5 Sep 2006 18:31:45 -0600 (MDT)
Date: Tue, 5 Sep 2006 18:31:45 -0600 (MDT)
From: "Nelson H. F. Beebe" <[email protected]>
To: [email protected]
Cc: [email protected], "Nelson H. F. Beebe" <[email protected]>,
[email protected], [email protected]
X-US-Mail: "Department of Mathematics, 110 LCB, University of Utah, 155 S
1400 E RM 233, Salt Lake City, UT 84112-0090, USA"
X-Telephone: +1 801 581 5254
X-FAX: +1 801 585 1640, +1 801 581 4148
X-URL: http://www.math.utah.edu/~beebe
Subject: Re: [tops-20] Re: TOPS-20 FTP server
In-Reply-To: <[email protected]>
Message-ID: <[email protected]>
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0 (mail.math.utah.edu [155.101.98.135]); Tue, 05 Sep 2006 18:31:45 -0600 (MDT)
ReSent-Date: Tue, 5 Sep 2006 20:27:54 -0700 (PDT)
ReSent-From: TOPS-20 List Moderator <[email protected]>
ReSent-To: TOPS-20 Distribution: ;
ReSent-Subject: Re: [tops-20] Re: TOPS-20 FTP server
ReSent-Message-ID: <[email protected]>

[email protected] asks about my comments on the new TOPS-20 FTP
server:

>> ...
>> However, as I read the input example you sent, I wondered if the ncftp
>> client itself might not be doing the packaging for you. In other
>> words, was it determining that it was doing a directory, doing an NLST
>> of the directory, possibly doing an MDTM and SIZE of each file in the
>> directory and then seperately retrieving each one via RETR commands
>> that pipe their output into a local archive?
>> ...

No, that is the Washington University in St. Louis (WUSTL) ftp server;
I set it up on ftp.math.utah.edu many years ago, and co-manage it.

>> I was unable to determine what commands your FTP server has, if
>> anything, to support this.

Here is what it knows about:

% ncftp ftp.math.utah.edu
...
ncftp / > quote site help
The following SITE commands are recognized (* =>'s unimplemented).
UMASK GROUP INDEX GROUPS
IDLE GPASS EXEC CHECKMETHOD
CHMOD NEWER ALIAS CHECKSUM
HELP MINFO CDPATH
Direct comments to [email protected].

ncftp / > quote site index read20
index read20
/pub/misc/read20.html
/pub/misc/read20.jar
/pub/misc/read20.jar-lst
/pub/misc/read20.jar.sig
...

/pub/read20/index.html
*** Truncated ***
(end of 'index read20')

>> ...
>> For right now, doing an NLST and then asking for each file is the way
>> FTP was designed. Other than saving the TCP socket set up and tear
>> down time, using a tar archive isn't going to buy you much as it isn't
>> compressed. You need another filter to do the compression. For
>> binary files, executables or files with holes in them, TYPE I (or TYPE
>> L 36) and STRU P is the way to go.
>> ...

Yes, but that design was before compression utilities like arc, bzip2,
jar, gzip, zip, and zoo came into wide use. The WUSTL server treats a
GET on a directory name followed by one of several extensions as a
request to run a program that returns a stream to be returned. The
configuration file /usr/local/etc/ftpconversions has lines like this:

:.bz2: : :/usr/local/bin/bunzip2 -d -c %s:T_REG|T_ASCII:O_UNCOMPRESS:UNCOMPRESS
:.Z: : :/usr/local/bin/compress -d -c %s:T_REG|T_ASCII:O_UNCOMPRESS:UNCOMPRESS
:-z: : :/usr/local/bin/compress -d -c %s:T_REG|T_ASCII:O_UNCOMPRESS:UNCOMPRESS
:.z: : :/usr/local/bin/gunzip -d -c %s:T_REG|T_ASCII:O_UNCOMPRESS:UNCOMPRESS
:.gz: : :/usr/local/bin/gunzip -d -c %s:T_REG|T_ASCII:O_UNCOMPRESS:UNCOMPRESS
:.tgz: :.tar:/usr/local/bin/gunzip -d -c %s:T_REG|T_ASCII:O_UNCOMPRESS:UNCOMPRESS
...

The nice thing is that WU-FTP doesn't have to know about any of them:
a single line in this file is enough to add support for yet another
archive format. The on-the-fly archiving of course takes time, and if
a .notar file exists in the directory, WU-FTP refuses to do the
archiving. The big win, however, is that the network traffic is cut
to about 1/3 for typical text file trees.

>> ...
>> If you have some time, please turn debugging information on in your
>> ftp client and send me the output off list. I'd also like to see what
>> your server is doing if you have logging for this. Be sure to scrub
>> the output! A number of ftp clients will display the password in
>> clear text when debugging is turned on!
>> ...

I'll look at that tomorrow, since I have to leave soon. I know about
the password problem, and added code to WU-FTP years ago to scrub them
so they don't show up in log files. A surprising number of people use
their local usernames and passwords when talking to FTP servers.

>> ...
>> With respect to the actual nuts and bolts: as I've said earlier, there
>> are two ways for the new Tops-20 FTP server to do this. The faster
>> one would most likely be by implementing the archive formats (perhaps
>> as file structures?) directly in the server itself. That could be
>> some work, but I don't know enough about these formats to have an
>> informed opinion as to the magnitude of that effort.
>> ...

I think the KISS principle applies here: provide a configuration file
mechanism like WU-FTP does, and let TOPS-20 FTPD talk to whatever
programs that file defines.

>> ...
>> > At present, this is what happens when I ftp from Unix to our TOPS-20
>> > system:
>> >
>> > ncftp / > ls
>> > TOPS20:
>> > ...
>> > TMP.DIRECTORY.1
>> > ..
>>
>> I don't understand what this example means. It looks like you are
>> getting root and appending this to a file named 'ls'.
>>
>> > ncftp / > get tmp
>> > get tmp: server said: File not accessable. No such file type
>> > ncftp / > get tmp.directory
>> > tmp.directory: 4608 bytes 4.37 kB/s
>> > ncftp / > get tmp.directory.1
>> > tmp.directory.1: 4608 bytes 4.37 kB/s
>> >
>> > Back on Unix, I find:
>> >
>> > % file tmp*
>> > tmp.directory: 8086 relocatable (Microsoft)
>> > tmp.directory.1: 8086 relocatable (Microsoft)
>> >
>> > A peak at that file with emacs shows an unintelligible mess of binary
>> > data, and it probably isn't good for anything other than an argument
>> > of the rm command.
>> ...

My sample was intended to show what the current TOPS-20 FTP server on
the PANDA distribution does when asked to return a directory from an
Unix ftp client. I didn't expect anything useful back.

>> ...
>> > As far as I recall, TOPS-20 never really had a good archive exchange
>> > format other than DUMPER tapes, and they were not portable to other
>> > systems, except in a limited fashion,
>>
>> Dumper tapes were portable to other 36 bit systems via interchange
>> format. DECtapes (the Great Pumpkin had these) were portable to other
>> PDP systems. What else was there?
>> ...

Well, I shipped many hundreds of 9-track tapes to PLOT79 customers
made with my tputil utility. It supported production of multifile
ANSI-labeled tapes. Today, a single .tar file provides a much more
convenient solution.

-------------------------------------------------------------------------------
- Nelson H. F. Beebe Tel: +1 801 581 5254 -
- University of Utah FAX: +1 801 581 4148 -
- Department of Mathematics, 110 LCB Internet e-mail: [email protected] -
- 155 S 1400 E RM 233 [email protected] [email protected] -
- Salt Lake City, UT 84112-0090, USA URL: http://www.math.utah.edu/~beebe/ -
-------------------------------------------------------------------------------
5-Sep-2006 20:31:49-PDT,6990;000000000000
Return-Path: <[email protected]>
Received: from pangtzu.panda.com ([206.124.149.117]) by lingling.panda.com with TCP/SMTP; Tue, 5 Sep 2006 20:28:49 -0700 (PDT)
X-Return-Path: <[email protected]>
X-Received: from mta8.srv.hcvlny.cv.net ([167.206.4.203]) by lingling.panda.com with TCP/SMTP; Tue, 5 Sep 2006 17:45:36 -0700 (PDT)
X-Received: from optonline.net (hamstr3.srv.hcvlny.cv.net [167.206.5.10])
by mta8.srv.hcvlny.cv.net
(Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006))
with ESMTP id <[email protected]> for
[email protected]; Tue, 05 Sep 2006 20:43:44 -0400 (EDT)
X-Received: from [10.240.3.208] (Forwarded-For: [10.240.3.208])
by mstr3.srv.hcvlny.cv.net (mshttpd); Wed, 06 Sep 2006 00:45:07 +0000 (GMT)
Date: Wed, 06 Sep 2006 00:45:07 +0000 (GMT)
From: [email protected]
Subject: Re: [tops-20] Re: TOPS-20 FTP server
In-reply-to: <[email protected]>
To: Rich Alderson <[email protected]>
Cc: [email protected]
Message-id: <[email protected]>
MIME-version: 1.0
X-Mailer: Sun Java(tm) System Messenger Express 6.2-6.01 (built Apr 3 2006)
Content-type: text/plain; charset=us-ascii
Content-language: en
Content-transfer-encoding: 7BIT
Content-disposition: inline
X-Accept-Language: en
Priority: normal
References: <[email protected]>
<[email protected]>
ReSent-Date: Tue, 5 Sep 2006 20:28:40 -0700 (PDT)
ReSent-From: TOPS-20 List Moderator <[email protected]>
ReSent-To: TOPS-20 Distribution: ;
ReSent-Subject: Re: [tops-20] Re: TOPS-20 FTP server
ReSent-Message-ID: <[email protected]>

> I have for a number of years toyed with the idea of, and spent
> occasional hours on, adding a disk-file output option to DUMPER
> (and, once I started taking care of a Tops-10 system, BACKUP). It
> has always seemed to me that this could be done by checking a flag
> at the time the DUMPO% (or DUMPI%) was to be executed, and calling a
> write-to-disk routine if the flag is set. This gets us the best of
> all worlds--a disk file in a format known to older tools (which can
> be made to understand it easily).

When I was at Marlboro, my project was to do certain enhancements to
DUMPER. Our specific task was to build a database of backup
information. Instead of (or in addition to) a DUMPER listing, data
about backups would be entered into a database. If you zorched a
file, you could then query the data base and it would tell you which
DUMPER tapes the file would be on (and eventually even issue mount
requests for those tapes).

A proof of concept had been done earlier, but it was implemented as a
flat file in COBOL which was sequentially parsed. It rapidly became
too large to parse efficiently and it was huge. Our job was to turn
this in a real data base.

For those who are familiar with Veritas Backup Exec, this idea is
exactly like a catalogued tape, except that the database was not in a
relational format.

We got as far as designing a GREAT database and wrote a big paper
about it. I still have the design paper some place. It took us about
six months to do this, in part because we got some extremely poor
advice from our manager as to how to do an initial lay out.

As far as I am aware, our work never went any further. Surely it
never became a product. However, this experience caused me to become
the local DUMPER maven at Columbia and we had a number of ideas that
never really went anywhere.

One was to change DUMPER to save where it was and to update the FDB's
of all the files it had saved to tape after every reel of tape. Due
to the stunning reliability of our TU45 tape drives, it was not
unusual for a backup to break on the 10th reel of a 15 reel backup.
It would all have to be started from scratch with much teeth nashing.

DUMPER would detect when a reel switch was done (it already does
this), update all of the FDB's and proceed. If you needed to restart,
you could issue an additional switch to DUMPER to tell it which file
to start with on a wildcard. FdC really pined for this.

Another was to have DUMPER save files over the network. Changing the
DUMPI%/DUMPO%'s to SINR%/SOUTR% wouldn't have been that big a problem.
The real issue was handling the tape MTOPR%'s and having a protocol to
send these over the network. Then we would have had to write some
sort of a server to handle all of this on the foreign system along
with tape mounts, etc. We didn't do it because our DN20's clearly
didn't have the bandwidth (and probably wouldn't have been up to that
kind of load, anyway).

We also looked at making DUMPER be a multi-forking program. An
inferior fork would run along faulting stuff into memory and DUMPER
would cheerfully write this to tape. We decided that we didn't need
to do this because DUMPI%/DUMPO% was providing enough asynchronicity.
Tuning the data fork to know how much to pre-fault would have been an
issue. Too little and you don't maximize your performance. Too much
and Tops-20 puts you away while it handles others.

This is one problem with the current FTP server. I'd like to have it
automatically configure the buffer size based on current memory usage,
but I don't know how to put the pieces of information that I have
together well enough to get a good answer. OS/2 1.x had a nice call
called DosMemAvail which would tell you what the largest chunk of
memory was in the system. If you took this number and divided it by
two (or some other number), you could be assured of getting the memory
without swapping and still being a good citizen.

But the real culpret was that our systems were so loaded, sometimes
even during third shift when we ran backups, that nothing would have
really speeded up the backup enough to have made all this worthwhile.

I seem to remember having a look at a DEC supplied multi-forking
DUMPER. I think this was in some beta-test that we had. As I recall
(and this was over 20 years ago, so don't nail me), it was very
preliminary. The synchronization between the tape fork and the disk
fork didn't seem to be finished. I don't remember it using ENQ/DEQ to
handle the queue between the two forks. I think it used spin locks
with DISMS% Anybody know more about this?

We also looked at using DUMPER to write to disk files, but (RP06) disk
storage was expensive enough (including the media), that we never
pursued it. Another problem was also figuring out what to do with the
MTOPR%s. It's probably worth another look. Let me know if you ever
get anywhere with this, I'd love to help out.

> Making the output file compatible with the tape format used by SimH
> and KLH10 would be very useful, hmm?

That doesn't seem like bad idea. I don't remember how efficient these
formats are in terms of packing bits.
6-Sep-2006 08:49:01-PDT,2966;000000000000
Return-Path: <[email protected]>
Received: from pangtzu.panda.com ([206.124.149.117]) by lingling.panda.com with TCP/SMTP; Wed, 6 Sep 2006 08:47:10 -0700 (PDT)
X-Return-Path: <[email protected]>
X-Received: from pangtzu.panda.com ([206.124.149.117]) by lingling.panda.com with TCP/SMTP; Wed, 6 Sep 2006 08:46:55 -0700 (PDT)
X-Return-Path: <[email protected]>
X-Received: from sj-iport-1.cisco.com ([171.71.176.70]) by lingling.panda.com with TCP/SMTP; Wed, 6 Sep 2006 08:38:02 -0700 (PDT)
X-Received: from sj-dkim-1.cisco.com ([171.71.179.21])
by sj-iport-1.cisco.com with ESMTP; 06 Sep 2006 08:37:53 -0700
X-Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254])
by sj-dkim-1.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k86FbrZ8028975;
Wed, 6 Sep 2006 08:37:53 -0700
X-Received: from cisco.com (pita.cisco.com [171.71.177.199])
by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k86FbqYp006204;
Wed, 6 Sep 2006 08:37:52 -0700 (PDT)
X-Received: (from billw@localhost)
by cisco.com (8.8.8-Cisco List Logging/8.8.8) id IAA03790;
Wed, 6 Sep 2006 08:36:48 -0700 (PDT)
Sender: Bill Westfield <[email protected]>
Date: Wed, 6 Sep 2006 8:36:48 PDT
From: William "Chops" Westfield <[email protected]>
To: [email protected]
Cc: TOPS-20 List Moderator <[email protected]>
Subject: Re: [tops-20] Re: TOPS-20 FTP server
In-Reply-To: Your message of Wed, 06 Sep 2006 00:45:07 +0000 (GMT)
Message-ID: <CMM.0.90.4.1157557008.billw@pita>
DKIM-Signature: a=rsa-sha1; q=dns; l=187; t=1157557073; x=1158421073;
c=relaxed/simple; s=sjdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version;
d=cisco.com; [email protected]; z=From:William=20=22Chops=22=20Westfield=20<[email protected]>
|Subject:Re=3A=20[tops-20]=20Re=3A=20TOPS-20=20FTP=20server
|Sender:Bill=20Westfield=20<[email protected]>;
X=v=3Dcisco.com=3B=20h=3D0gz6RTC4ZXi/+i19pO1uoteFdPM=3D; b=Egy7UxOg2/GPgsnOIq9v73HXNF3DVgyqw6VqlR3B1+XnkSefba0NkWl3MVDOo29lTwZDx1ab
m1g49n5CR4o5BcL3TF4KOcqbh5YTxhirJD+L7WJccf2FqY6ctc7mQVUX;
Authentication-Results: sj-dkim-1.cisco.com; [email protected]; dkim=pass (
sig from cisco.com verified; );
X-ReSent-Date: Wed, 6 Sep 2006 08:46:26 -0700 (PDT)
X-ReSent-From: Mark Crispin <[email protected]>
X-ReSent-To: TOPS-20 Hackers and Yackers <[email protected]>
X-ReSent-Subject: Re: [tops-20] Re: TOPS-20 FTP server
X-ReSent-Message-ID: <[email protected]>
ReSent-Date: Wed, 6 Sep 2006 08:47:00 -0700 (PDT)
ReSent-From: TOPS-20 List Moderator <[email protected]>
ReSent-To: TOPS-20 Distribution: ;
ReSent-Subject: Re: [tops-20] Re: TOPS-20 FTP server
ReSent-Message-ID: <[email protected]>

FLAIR had an archive system (remember archived files? What a good idea!)
that stored the files by FTPing them to a unix system (with cheap disks.)
It was written in LISP :-(

BillW
6-Sep-2006 13:39:51-PDT,3281;000000000000
Return-Path: <[email protected]>
Received: from pangtzu.panda.com ([206.124.149.117]) by lingling.panda.com with TCP/SMTP; Wed, 6 Sep 2006 13:37:51 -0700 (PDT)
X-Return-Path: <[email protected]>
X-Received: from mail1.panix.com ([166.84.1.72]) by lingling.panda.com with TCP/SMTP; Wed, 6 Sep 2006 12:27:57 -0700 (PDT)
X-Received: from panix5.panix.com (panix5.panix.com [166.84.1.5])
by mail1.panix.com (Postfix) with ESMTP id EDCD858849
for <[email protected]>; Wed, 6 Sep 2006 15:27:46 -0400 (EDT)
X-Received: (from alderson@localhost)
by panix5.panix.com (8.11.6p3/8.8.8/PanixN1.1) id k86JRkb26925;
Wed, 6 Sep 2006 15:27:46 -0400 (EDT)
Date: Wed, 6 Sep 2006 15:27:46 -0400 (EDT)
Message-Id: <[email protected]>
From: Rich Alderson <[email protected]>
To: [email protected]
In-reply-to: <[email protected]> ([email protected])
Subject: Re: [tops-20] Re: TOPS-20 FTP server
References: <[email protected]> <[email protected]>
ReSent-Date: Wed, 6 Sep 2006 13:37:44 -0700 (PDT)
ReSent-From: TOPS-20 List Moderator <[email protected]>
ReSent-To: TOPS-20 Distribution: ;
ReSent-Subject: Re: [tops-20] Re: TOPS-20 FTP server
ReSent-Message-ID: <[email protected]>

> Date: Tue, 05 Sep 2006 23:30:21 +0000 (GMT)
> From: [email protected]

>> ncftp / > get tmp
>> get tmp: server said: File not accessable. No such file type
>> ncftp / > get tmp.directory
>> tmp.directory: 4608 bytes 4.37 kB/s
>> ncftp / > get tmp.directory.1
>> tmp.directory.1: 4608 bytes 4.37 kB/s

>> Back on Unix, I find:

>> % file tmp*
>> tmp.directory: 8086 relocatable (Microsoft)
>> tmp.directory.1: 8086 relocatable (Microsoft)

>> A peak at that file with emacs shows an unintelligible mess of binary
>> data, and it probably isn't good for anything other than an argument
>> of the rm command.

> That's to be expected.

> Normally, I believe that a Tops-20 directory file can never be opened
> by an ordinary user. I can't remember what reading Tops-20 directory
> file is good for, other than when running CHECKD. MRC? However, when
> you are running as an enabled wheel or operator, the BBN server will
> open the directory file and transfer it anyway.

And a bit of history: SCORE (the Computer Science 20) was the central
repository of Tops-20 sources at Stanford, with other sites maintaining those
things that they were locally licensed for. At some point, someone updated
SCORE from Sierra (the EE 20) without ensuring that paged mode was in effect
(due to lossage in the DNS information base, it was often not set
automagically), and SCORE ended up with <ROOT-DIRECTORY>FTP.DIRECTORY.2 and
no FTP sources for a long time. An examination of the file in FILDDT showed
that it was very likely an exact binary copy of the Sierra directory--but the
latter no longer existed, as Sierra was decomissioned before the damage was
discovered by the LOTS systems programmer looking to fix a problem at his site,
and backup tapes could not be obtained from the 36-bit hostile new management.

Rich
6-Sep-2006 14:08:06-PDT,4145;000000000000
Return-Path: <[email protected]>
Received: from pangtzu.panda.com ([206.124.149.117]) by lingling.panda.com with TCP/SMTP; Wed, 6 Sep 2006 14:06:33 -0700 (PDT)
X-Return-Path: <[email protected]>
X-Received: from mxout7.cac.washington.edu ([140.142.32.178]) by lingling.panda.com with TCP/SMTP; Wed, 6 Sep 2006 14:05:09 -0700 (PDT)
X-Received: from smtp.washington.edu (smtp.washington.edu [140.142.33.9])
by mxout7.cac.washington.edu (8.13.7+UW06.06/8.13.7+UW06.03) with ESMTP id k86L53sa028231
(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
Wed, 6 Sep 2006 14:05:03 -0700
X-Auth-Received: from Tomobiki-Cho.CAC.Washington.EDU (tomobiki-cho.cac.washington.edu [128.95.135.58])
(authenticated authid=mrc)
by smtp.washington.edu (8.13.7+UW06.06/8.13.7+UW06.03) with ESMTP id k86L52pc001845
(version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT);
Wed, 6 Sep 2006 14:05:02 -0700
Date: Wed, 6 Sep 2006 14:07:05 -0700 (Pacific Daylight Time)
From: Mark Crispin <[email protected]>
To: Rich Alderson <[email protected]>
cc: TOPS-20 Hackers and Yackers <[email protected]>
Subject: Re: [tops-20] Re: TOPS-20 FTP server
In-Reply-To: <[email protected]>
Message-ID: <[email protected]>
References: <[email protected]>
<[email protected]> <[email protected]>
Organization: Networks & Distributed Computing
Sender: [email protected]
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
X-PMX-Version: 5.2.0.264296, Antispam-Engine: 2.4.0.264935, Antispam-Data: 2006.9.6.134442
X-Uwash-Spam: Gauge=IIIIIII, Probability=7%, Report='__CT 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0'
ReSent-Date: Wed, 6 Sep 2006 14:06:25 -0700 (PDT)
ReSent-From: TOPS-20 List Moderator <[email protected]>
ReSent-To: TOPS-20 Distribution: ;
ReSent-Subject: Re: [tops-20] Re: TOPS-20 FTP server
ReSent-Message-ID: <[email protected]>

On Wed, 6 Sep 2006, Rich Alderson wrote:
> And a bit of history: SCORE (the Computer Science 20) was the central
> repository of Tops-20 sources at Stanford, with other sites maintaining those
> things that they were locally licensed for.

That was my doing. I put in a lot of effort to make that happen, along
with the TOPS-20 list which survives to this day). As far as I can tell,
nobody really took on the responsibility afterwards.

A lot of strange things happened at about that time. Quite a few things
went missing, ranging from hardware to personal property from my office in
MJH (which I had not yet officially vacated since I was supposedly still
1/8 time there).

Most of the Panda distribution descends from backup tapes that I made in
the late spring of 1984. Panda existed as a separate fork of TOPS-20 5.4
by 1985. I was mostly out of the loop of Stanford TOPS-20 development
after 1984, although I kept half an eye on what was going on. Panda
updated to DEC release 6.1 independently, although clearly Stanford 6.1
was consulted. I don't know if Stanford ever updated to release 7, and in
any case Panda did that on its own.

I suspect that the XKL sources followed cisco, which forked from Stanford
at about the same time as Panda did. Unlike Panda, XKL doesn't have the
very last set of DEC edits to release 7; but of course XKL has quite a bit
more of other stuff.

It appears that I updated my copy of the Stanford FTP sources from Score
in 1986. I had observed (and was appalled by) the rapid deterioration of
the Score sources. Fortunately, my 2020 was operational by then, and
hence tapenet. I went to considerable effort to make sure that Panda was
as complete as possible. In spite of that, some things were lost; but
most was preserved.

> backup tapes could not be obtained from the 36-bit hostile new management.

That was quite a problem in the latter part of the 1980s.

-- Mark --
30-Sep-2006 21:30:22-PDT,2535;000000000000
Return-Path: <[email protected]>
Received: from pangtzu.panda.com ([206.124.149.117]) by lingling.panda.com with TCP/SMTP; Sat, 30 Sep 2006 21:28:29 -0700 (PDT)
X-Return-Path: <[email protected]>
X-Received: from smtpout.mac.com ([17.250.248.185]) by lingling.panda.com with TCP/SMTP; Sat, 30 Sep 2006 21:09:44 -0700 (PDT)
X-Received: from mac.com (smtpin03-en2 [10.13.10.148])
by smtpout.mac.com (Xserve/8.12.11/smtpout15/MantshX 4.0) with ESMTP id k9149do3026911
for <[email protected]>; Sat, 30 Sep 2006 21:09:39 -0700 (PDT)
X-Received: from [192.168.1.51] (c-24-147-40-233.hsd1.nh.comcast.net [24.147.40.233])
(authenticated bits=0)
by mac.com (Xserve/smtpin03/MantshX 4.0) with ESMTP id k9149ZMb020469
for <[email protected]>; Sat, 30 Sep 2006 21:09:37 -0700 (PDT)
Mime-Version: 1.0
Message-Id: <p06230916c144ee9b4897@[192.168.1.51]>
In-Reply-To: <[email protected]>
References: <[email protected]>
<[email protected]>
<[email protected]>
Date: Sun, 1 Oct 2006 00:09:55 -0400
To: [email protected]
From: John Francini <[email protected]>
Subject: Anyone want some ancient PDP-10 history?
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Brightmail-Tracker: AAAAAA==
X-Brightmail-scanned: yes
ReSent-Date: Sat, 30 Sep 2006 21:28:14 -0700 (PDT)
ReSent-From: TOPS-20 List Moderator <[email protected]>
ReSent-To: TOPS-20 Distribution: ;
ReSent-Subject: Anyone want some ancient PDP-10 history?
ReSent-Message-ID: <[email protected]>

I've got two pieces of 'ancient PDP-10 history' for anyone who wants them.

1. A PDP-10 Reference Handbook (Phone Book) from 1971, includes:

System Reference Manual
MACRO-10 Assembler
TOPS-10 Monitor
EDITOR/TECO
LOADER/DDT
PIP/SRCCOM/BINCOM/TENDMP/FUDGE2/CREF/GLOB

2. An RH10(?) lights panel -- just the silk-screened plastic panel
with translucent circles where the lights would show through,
labelled with all sorts of information. It definitely was from some
sort of disk controller -- possibly fixed disks? Not sure.

Either of these are available for the asking. Just send me a full
mailing address.

John Francini
Nashua, NH

--
John Francini, [email protected]

"The journey is more important than the destination-that's part of
life. If you only live for getting to the end, you're almost always
disappointed." -Donald Knuth
1-Oct-2006 05:02:38-PDT,3116;000000000000
Return-Path: <[email protected]>
Received: from pangtzu.panda.com ([206.124.149.117]) by lingling.panda.com with TCP/SMTP; Sun, 1 Oct 2006 04:58:40 -0700 (PDT)
X-Return-Path: <[email protected]>
X-Received: from smtpout.mac.com ([17.250.248.172]) by lingling.panda.com with TCP/SMTP; Sat, 30 Sep 2006 23:10:18 -0700 (PDT)
X-Received: from mac.com (smtpin03-en2 [10.13.10.148])
by smtpout.mac.com (Xserve/8.12.11/smtpout02/MantshX 4.0) with ESMTP id k916AC4l008234
for <[email protected]>; Sat, 30 Sep 2006 23:10:12 -0700 (PDT)
X-Received: from [192.168.1.51] (c-24-147-40-233.hsd1.nh.comcast.net [24.147.40.233])
(authenticated bits=0)
by mac.com (Xserve/smtpin03/MantshX 4.0) with ESMTP id k916A7xL011301
for <[email protected]>; Sat, 30 Sep 2006 23:10:11 -0700 (PDT)
Mime-Version: 1.0
Message-Id: <p0623091ac1450b998177@[192.168.1.51]>
In-Reply-To: <p06230916c144ee9b4897@[192.168.1.51]>
References: <[email protected]>
<[email protected]>
<[email protected]>
<p06230916c144ee9b4897@[192.168.1.51]>
Date: Sun, 1 Oct 2006 02:10:18 -0400
To: [email protected]
From: John Francini <[email protected]>
Subject: Re: Anyone want some ancient PDP-10 history?
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Brightmail-Tracker: AAAAAA==
X-Brightmail-scanned: yes
ReSent-Date: Sun, 1 Oct 2006 04:58:31 -0700 (PDT)
ReSent-From: TOPS-20 List Moderator <[email protected]>
ReSent-To: TOPS-20 Distribution: ;
ReSent-Subject: Re: Anyone want some ancient PDP-10 history?
ReSent-Message-ID: <[email protected]>

Thanks, folks -- already got a bunch of responses.

The first respondent (and therefore the winner) was Tom DeBellis
([email protected]).

I _may_ have some other stuff to offer if as I find it.

Thanks,

John Francini
Nashua, NH

At 0:09 -0400 10/1/06, John Francini wrote:
>I've got two pieces of 'ancient PDP-10 history' for anyone who wants them.
>
>1. A PDP-10 Reference Handbook (Phone Book) from 1971, includes:
>
> System Reference Manual
> MACRO-10 Assembler
> TOPS-10 Monitor
> EDITOR/TECO
> LOADER/DDT
> PIP/SRCCOM/BINCOM/TENDMP/FUDGE2/CREF/GLOB
>
>2. An RH10(?) lights panel -- just the silk-screened plastic panel
>with translucent circles where the lights would show through,
>labelled with all sorts of information. It definitely was from some
>sort of disk controller -- possibly fixed disks? Not sure.
>
>Either of these are available for the asking. Just send me a full
>mailing address.
>
>John Francini
>Nashua, NH
>
>--
>John Francini, [email protected]
>
>"The journey is more important than the destination-that's part of
>life. If you only live for getting to the end, you're almost always
>disappointed." -Donald Knuth

--
John Francini, [email protected]

"The journey is more important than the destination-that's part of
life. If you only live for getting to the end, you're almost always
disappointed." -Donald Knuth
14-Oct-2006 15:39:49-PDT,2219;000000000000
Return-Path: <[email protected]>
Received: from pangtzu.panda.com ([206.124.149.117]) by lingling.panda.com with TCP/SMTP; Sat, 14 Oct 2006 15:34:44 -0700 (PDT)
X-Return-Path: <[email protected]>
X-Received: from mta2.srv.hcvlny.cv.net ([167.206.4.197]) by lingling.panda.com with TCP/SMTP; Sat, 14 Oct 2006 14:29:28 -0700 (PDT)
X-Received: from optonline.net (hamstr3.srv.hcvlny.cv.net [167.206.5.10])
by mta2.srv.hcvlny.cv.net
(Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006))
with ESMTP id <[email protected]> for
[email protected]; Sat, 14 Oct 2006 17:29:21 -0400 (EDT)
X-Received: from [10.240.3.201] (Forwarded-For: 69.114.1.48, [10.240.3.201])
by mstr3.srv.hcvlny.cv.net (mshttpd); Sat, 14 Oct 2006 21:29:21 +0000 (GMT)
Date: Sat, 14 Oct 2006 21:29:21 +0000 (GMT)
From: [email protected]
Subject: DMON
To: [email protected]
Message-id: <[email protected]>
MIME-version: 1.0
X-Mailer: Sun Java(tm) System Messenger Express 6.2-6.01 (built Apr 3 2006)
Content-type: text/plain; charset=us-ascii
Content-language: en
Content-transfer-encoding: 7BIT
Content-disposition: inline
X-Accept-Language: en
Priority: normal
ReSent-Date: Sat, 14 Oct 2006 15:34:33 -0700 (PDT)
ReSent-From: TOPS-20 List Moderator <[email protected]>
ReSent-To: TOPS-20 Distribution: ;
ReSent-Subject: DMON
ReSent-Message-ID: <[email protected]>

I was debugging an FTP control protocol issue when something jogged a
memory.

At Columbia, we used to have a utility that would show us the entire
BIGBUF, or what I thought was the global TTY input queue. It would
show all the input on all the lines and this was very useful to have
when chasing down a problem with open lines or line ringing.

I went looking around in the PANDA distribution and found a program
called DMON. The output is similar to what I remember, but it only
shows 'physical' lines, in this case the CTY (TTY5).

I'd REALLY like to see what is coming in on TVT's. Is there anything
that does this? I know I can use packet analysers, etc., etc., but
this would make certain things much easier.

15-Oct-2006 11:17:42-PDT,1903;000000000000
Return-Path: <[email protected]>
Received: from pangtzu.panda.com ([206.124.149.117]) by lingling.panda.com with TCP/SMTP; Sun, 15 Oct 2006 11:13:25 -0700 (PDT)
X-Return-Path: <[email protected]>
X-Received: from sesame.cc.columbia.edu ([128.59.59.56]) by lingling.panda.com with TCP/SMTP; Sun, 15 Oct 2006 09:04:44 -0700 (PDT)
X-Received: from sesame.cc.columbia.edu (localhost [127.0.0.1])
by sesame.cc.columbia.edu (8.13.7/8.13.6) with ESMTP id k9FG4blW021606;
Sun, 15 Oct 2006 12:04:37 -0400 (EDT)
X-Received: (from fdc@localhost)
by sesame.cc.columbia.edu (8.13.7/8.12.8/Submit) id k9FG4Xt3021605;
Sun, 15 Oct 2006 12:04:33 -0400 (EDT)
Date: Sun, 15 Oct 2006 12:04:33 EDT
From: Frank da Cruz <[email protected]>
To: [email protected], [email protected]
Cc: TOPS-20 List Moderator <[email protected]>
Subject: Re: DMON
In-Reply-To: <[email protected]>
Message-ID: <[email protected]>
ReSent-Date: Sun, 15 Oct 2006 11:13:16 -0700 (PDT)
ReSent-From: TOPS-20 List Moderator <[email protected]>
ReSent-To: TOPS-20 Distribution: ;
ReSent-Subject: Re: DMON
ReSent-Message-ID: <[email protected]>

> I was debugging an FTP control protocol issue when something jogged a
> memory.
>
> At Columbia, we used to have a utility that would show us the entire
> BIGBUF, or what I thought was the global TTY input queue. It would
> show all the input on all the lines and this was very useful to have
> when chasing down a problem with open lines or line ringing.
>
It was called ISPY. We fixed it up locally to use what's-his-name's
terminal-type database, the same that was used by SYSDPY, so we could
watch everybody typing at once, even on our Concept-100s. (Disclaimer:
we only did this for legitimate reasons of troubleshooting and security.)

- Frank
15-Oct-2006 20:35:13-PDT,2463;000000000000
Return-Path: <[email protected]>
Received: from pangtzu.panda.com ([206.124.149.117]) by lingling.panda.com with TCP/SMTP; Sun, 15 Oct 2006 20:30:47 -0700 (PDT)
X-Return-Path: <[email protected]>
X-Received: from mta10.srv.hcvlny.cv.net ([167.206.4.205]) by lingling.panda.com with TCP/SMTP; Sun, 15 Oct 2006 20:22:43 -0700 (PDT)
X-Received: from optonline.net (hamstr3.srv.hcvlny.cv.net [167.206.5.10])
by mta10.srv.hcvlny.cv.net
(Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006))
with ESMTP id <[email protected]> for
[email protected]; Sun, 15 Oct 2006 23:15:42 -0400 (EDT)
X-Received: from [10.240.3.196] (Forwarded-For: 69.114.1.48, [10.240.3.196])
by mstr3.srv.hcvlny.cv.net (mshttpd); Mon, 16 Oct 2006 03:17:13 +0000 (GMT)
Date: Mon, 16 Oct 2006 03:17:13 +0000 (GMT)
From: [email protected]
Subject: Typographic error in TVTSRV?
To: [email protected]
Message-id: <[email protected]>
MIME-version: 1.0
X-Mailer: Sun Java(tm) System Messenger Express 6.2-6.01 (built Apr 3 2006)
Content-type: text/plain; charset=us-ascii
Content-language: en
Content-transfer-encoding: 7BIT
Content-disposition: inline
X-Accept-Language: en
X-Priority: 5 (Lowest)
ReSent-Date: Sun, 15 Oct 2006 20:30:40 -0700 (PDT)
ReSent-From: TOPS-20 List Moderator <[email protected]>
ReSent-To: TOPS-20 Distribution: ;
ReSent-Subject: Typographic error in TVTSRV?
ReSent-Message-ID: <[email protected]>

I was glancing through TVTSRV, wondering about DMON/ISPY, when I
happened across the following:

NVTWIL - ;PROCESS "WILL"

;ACCEPTS:
; T1/ OPTION
; T2/ ADDRESS OF DYNAMIC DATA

;RETURN +1: ALWAYS

NVTWIL: CAIL T1,WILOPT ;ONLY WILOPT OPTIONS

Note that the first NVTWIL is NOT preceded by a semi-colon. If one
looks at a previous routine, one sees.

;NVTDNT - PROCESS "DONT"

;ACCEPTS:
; T1/ OPTION
; T2/ ADDRESS OF DYNAMIC DATA

;RETURN +1: ALWAYS

I believe that the NVTWIL should be written as follows:

; NVTWIL - PROCESS "WILL"

;ACCEPTS:
; T1/ OPTION
; T2/ ADDRESS OF DYNAMIC DATA

;RETURN +1: ALWAYS

NVTWIL: CAIL T1,WILOPT ;ONLY WILOPT OPTIONS

As it stands now, this error merely involves the address of the NVTWIL
routine being put before the routine itself. This hardly appears to
be a major problem.

But I fixed it in my sources.

15-Oct-2006 21:35:44-PDT,1483;000000000000
Return-Path: <[email protected]>
Received: from pangtzu.panda.com ([206.124.149.117]) by lingling.panda.com with TCP/SMTP; Sun, 15 Oct 2006 21:31:56 -0700 (PDT)
X-Return-Path: <[email protected]>
X-Received: from pangtzu.panda.com ([206.124.149.117]) by lingling.panda.com with TCP/SMTP; Sun, 15 Oct 2006 20:40:29 -0700 (PDT)
Date: Sun, 15 Oct 2006 20:40:24 -0700 (PDT)
From: Mark Crispin <[email protected]>
Sender: [email protected]
To: [email protected]
cc: [email protected]
Subject: Re: Typographic error in TVTSRV?
In-Reply-To: <[email protected]>
Message-ID: <[email protected]>
References: <[email protected]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
ReSent-Date: Sun, 15 Oct 2006 21:31:49 -0700 (PDT)
ReSent-From: TOPS-20 List Moderator <[email protected]>
ReSent-To: TOPS-20 Distribution: ;
ReSent-Subject: Re: Typographic error in TVTSRV?
ReSent-Message-ID: <[email protected]>

On Mon, 16 Oct 2006, [email protected] wrote:
> As it stands now, this error merely involves the address of the NVTWIL
> routine being put before the routine itself. This hardly appears to
> be a major problem.

I agree; it's a bug, and it's in the DEC monitor.

I'll fix it in Panda too.

-- Mark --

http://panda.com/tops-20
TOPS-20: a great improvement over its successors
29-Oct-2006 20:24:59-PST,2471;000000000000
Return-Path: <[email protected]>
Received: from pangtzu.panda.com ([206.124.149.117]) by lingling.panda.com with TCP/SMTP; Sun, 29 Oct 2006 20:19:38 -0800 (PST)
X-Return-Path: <[email protected]>
X-Received: from pangtzu.panda.com ([206.124.149.117]) by lingling.panda.com with TCP/SMTP; Sun, 29 Oct 2006 20:17:33 -0800 (PST)
Date: Sun, 29 Oct 2006 20:17:28 -0800 (PST)
From: Mark Crispin <[email protected]>
Sender: [email protected]
To: TOPS-20 Hackers and Yackers <[email protected]>
Subject: Remember: update your summer time rules!
Message-ID: <[email protected]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
ReSent-Date: Sun, 29 Oct 2006 20:19:30 -0800 (PST)
ReSent-From: TOPS-20 List Moderator <[email protected]>
ReSent-To: TOPS-20 Distribution: ;
ReSent-Subject: Remember: update your summer time rules!
ReSent-Message-ID: <[email protected]>

Today marked the last summer time shift under the old US rules. Newer
Panda systems have already been taught about the new rules, which take
effect in 2007. If you have an older Panda system, contact me and I'll
send you the updated DATIME.MAC.

Non-Panda TOPS-20 systems can update to the new DST rules by patching
DSTBGN/ 2007.
DSTON/ 73.
DSTOFF/ 311.

If you have a TOPS-20 release 7 system with DEC edit 9098 to DATIME.MAC
(which, by the way, I wrote), the following will add the new rules:

(1) After the definition of LSTFEB, add:

SNDMAR==31+29+14-1 ; Second Sunday in March

(2) After the defintion of LSTOCT, add:

FSTNOV==31+29+31+30+31+30+31+31+30+31+7-1 ; First Sunday in November

(3) In the RULES macro, add the following as the first rule (right after
the XLIST):

DST 2007,SNDMAR,FSTNOV ; 2005 Energy bill

There is also a bugfix to NLSS that you should make if you have edit 9098
but not a Panda monitor. Right before the instruction that reads:
MOVE A,DSTBFN(F) ;[9098] Load the year back
you should save F someplace, since it'll get clobbered by an IDIVI of E.
Restore F right before the instruction that reads:
MOVE F,DSTOFF(F) ;[9098] Get last day for DST in this year

Or you can PUSH P,DSTOFF(F) on the stack and then POP P,F instead of the
MOVE F,DSTOFF(F). That's what I did in Panda 5.5.

-- Mark --

http://panda.com/tops-20
TOPS-20: a great improvement over its successors
29-Oct-2006 21:51:43-PST,2854;000000000000
Return-Path: <[email protected]>
Received: from pangtzu.panda.com ([206.124.149.117]) by lingling.panda.com with TCP/SMTP; Sun, 29 Oct 2006 21:47:32 -0800 (PST)
X-Return-Path: <[email protected]>
X-Received: from pangtzu.panda.com ([206.124.149.117]) by lingling.panda.com with TCP/SMTP; Sun, 29 Oct 2006 21:45:57 -0800 (PST)
X-Return-Path: <[email protected]>
X-Received: from pop-siberian.atl.sa.earthlink.net ([207.69.195.71]) by lingling.panda.com with TCP/SMTP; Sun, 29 Oct 2006 21:29:17 -0800 (PST)
X-Received: from cpe-24-221-177-162.ca.sprintbbd.net ([24.221.177.162] helo=[204.238.239.104])
by pop-siberian.atl.sa.earthlink.net with esmtp (Exim 3.36 #1)
id 1GePhm-0004gV-00
for [email protected]; Mon, 30 Oct 2006 00:29:02 -0500
Mime-Version: 1.0 (Apple Message framework v624)
In-Reply-To: <[email protected]>
References: <[email protected]>
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <[email protected]>
Content-Transfer-Encoding: 7bit
From: Carl Baltrunas <[email protected]>
Subject: Re: Remember: update your summer time rules!
Date: Sun, 29 Oct 2006 21:29:00 -0800
To: Mark Crispin <[email protected]>
X-Mailer: Apple Mail (2.624)
X-ReSent-Date: Sun, 29 Oct 2006 21:45:45 -0800 (PST)
X-ReSent-From: Mark Crispin <[email protected]>
X-ReSent-To: TOPS-20 Hackers and Yackers <[email protected]>
X-ReSent-Subject: Re: Remember: update your summer time rules!
X-ReSent-Message-ID: <[email protected]>
ReSent-Date: Sun, 29 Oct 2006 21:47:20 -0800 (PST)
ReSent-From: TOPS-20 List Moderator <[email protected]>
ReSent-To: TOPS-20 Distribution: ;
ReSent-Subject: Re: Remember: update your summer time rules!
ReSent-Message-ID: <[email protected]>

Hmmm. Guess I'll have to keep this around till the next time I bring
up the TOAD.

And RATS! It means that even though the Tymcom-X OS daylight savings
table expires in 2008, It will be wrong next year. AFAIK no one is
running one under emulation since it never had a TCP stack. It only
talked to the front end via KLDCP (no RSX-20F) or directly through
Tymnet.

Does anyone know if any of the emulation packages also emulates a
front-end terminal running either KLDCP or RSX-20F???

-Carl

On Oct 29, 2006, at 8:17 PM, Mark Crispin wrote:
> Today marked the last summer time shift under the old US rules. Newer
> Panda systems have already been taught about the new rules, which take
> effect in 2007. If you have an older Panda system, contact me and
> I'll send you the updated DATIME.MAC.
> ...

> -- Mark --
>
> http://panda.com/tops-20
> TOPS-20: a great improvement over its successors

29-Oct-2006 22:03:11-PST,1889;000000000000
Return-Path: <[email protected]>
Received: from pangtzu.panda.com ([206.124.149.117]) by lingling.panda.com with TCP/SMTP; Sun, 29 Oct 2006 21:59:11 -0800 (PST)
X-Return-Path: <[email protected]>
X-Received: from pangtzu.panda.com ([206.124.149.117]) by lingling.panda.com with TCP/SMTP; Sun, 29 Oct 2006 21:58:48 -0800 (PST)
Date: Sun, 29 Oct 2006 21:58:42 -0800 (PST)
From: Mark Crispin <[email protected]>
Sender: [email protected]
To: Carl Baltrunas <[email protected]>
cc: TOPS-20 Hackers and Yackers <[email protected]>
Subject: Re: Remember: update your summer time rules!
In-Reply-To: <[email protected]>
Message-ID: <[email protected]>
References: <[email protected]>
<[email protected]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
ReSent-Date: Sun, 29 Oct 2006 21:59:03 -0800 (PST)
ReSent-From: TOPS-20 List Moderator <[email protected]>
ReSent-To: TOPS-20 Distribution: ;
ReSent-Subject: Re: Remember: update your summer time rules!
ReSent-Message-ID: <[email protected]>

On Sun, 29 Oct 2006, Carl Baltrunas wrote:
> Does anyone know if any of the emulation packages also emulates a
> front-end terminal running either KLDCP or RSX-20F???

KLH10 supports DTE primary and secondary protocol, but for the most part
this is only to drive the CTY and negotiate time. There's no support for
KLINIK, DL11 terminal lines, other DTEs, 10/11 file transfer, etc.

I've thought about implemented DL11 lines, interfacing with a host-based
SSH server to provide SSH service capabilities to TOPS-20. However, that
is not a small task.

-- Mark --

http://panda.com/tops-20
TOPS-20: a great improvement over its successors
30-Oct-2006 09:29:21-PST,3671;000000000000
Return-Path: <[email protected]>
Received: from pangtzu.panda.com ([206.124.149.117]) by lingling.panda.com with TCP/SMTP; Mon, 30 Oct 2006 09:22:27 -0800 (PST)
X-Return-Path: <[email protected]>
X-Received: from pop-borzoi.atl.sa.earthlink.net ([207.69.195.70]) by lingling.panda.com with TCP/SMTP; Sun, 29 Oct 2006 23:16:20 -0800 (PST)
X-Received: from cpe-24-221-177-162.ca.sprintbbd.net ([24.221.177.162] helo=[204.238.239.104])
by pop-borzoi.atl.sa.earthlink.net with esmtp (Exim 3.36 #1)
id 1GeRNS-0006sE-00; Mon, 30 Oct 2006 02:16:10 -0500
In-Reply-To: <[email protected]>
References: <[email protected]> <[email protected]> <[email protected]>
Mime-Version: 1.0 (Apple Message framework v624)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <[email protected]>
Content-Transfer-Encoding: 7bit
Cc: TOPS-20 Hackers and Yackers <[email protected]>
From: Carl Baltrunas <[email protected]>
Subject: Re: Remember: update your summer time rules!
Date: Sun, 29 Oct 2006 23:16:07 -0800
To: Mark Crispin <[email protected]>
X-Mailer: Apple Mail (2.624)
ReSent-Date: Mon, 30 Oct 2006 09:22:19 -0800 (PST)
ReSent-From: TOPS-20 List Moderator <[email protected]>
ReSent-To: TOPS-20 Distribution: ;
ReSent-Subject: Re: Remember: update your summer time rules!
ReSent-Message-ID: <[email protected]>

I'm not up on the details of the protocols enough to be able to make an
intelligent comment.

Are you saying that KLH10 provides a simple CTY 'as if' there was a
black-box in the path between the KL and the CTY, and character data is
transferred in both directions as the KL thinks it is talking to
'whatever it needs' to pass the data?

I truly do not know the details of the differences between KLDCP and
RSX-20F as far as how they communicate with the KL. I do know that if
the FE booted from a KLAD pack, they could run the diagnostics on the
DEC-only hardware, but had to do other things to test the SA-10 and the
I/O peripherals connected through the SA-10. I don't recall the name
of the SA-10 diagnostic. To bring up TYMCOM-X after running
diagnostics, they had to reload KLDCP, as our monitor did not know how
to communicate via RSX-20F, and IIRC our boot sequence required
operator intervention to issue the right startup from ONCE-only. It's
been awhile. Joe or Vance may remember.

I ask, because one of these days, I'd like to try and bring up TYMCOM-X
under KLH10, and I'm wondering if I will be able to do anything, since
once we've gone through the ONCE-only module, the console becomes
output only (except for KLDCP commands) and cannot currently be used as
a terminal under general timesharing.

-Carl

On Oct 29, 2006, at 9:58 PM, Mark Crispin wrote:
> On Sun, 29 Oct 2006, Carl Baltrunas wrote:
>> Does anyone know if any of the emulation packages also emulates a
>> front-end terminal running either KLDCP or RSX-20F???
>
> KLH10 supports DTE primary and secondary protocol, but for the most
> part this is only to drive the CTY and negotiate time. There's no
> support for KLINIK, DL11 terminal lines, other DTEs, 10/11 file
> transfer, etc.
>
> I've thought about implemented DL11 lines, interfacing with a
> host-based SSH server to provide SSH service capabilities to TOPS-20.
> However, that is not a small task.
>
> -- Mark --
>
> http://panda.com/tops-20
> TOPS-20: a great improvement over its successors

30-Oct-2006 10:04:19-PST,4328;000000000000
Return-Path: <[email protected]>
Received: from pangtzu.panda.com ([206.124.149.117]) by lingling.panda.com with TCP/SMTP; Mon, 30 Oct 2006 09:59:07 -0800 (PST)
X-Return-Path: <[email protected]>
X-Received: from pangtzu.panda.com ([206.124.149.117]) by lingling.panda.com with TCP/SMTP; Mon, 30 Oct 2006 09:57:50 -0800 (PST)
Date: Mon, 30 Oct 2006 09:57:45 -0800 (PST)
From: Mark Crispin <[email protected]>
Sender: [email protected]
To: Carl Baltrunas <[email protected]>
cc: TOPS-20 Hackers and Yackers <[email protected]>
Subject: Re: Remember: update your summer time rules!
In-Reply-To: <[email protected]>
Message-ID: <[email protected]>
References: <[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
ReSent-Date: Mon, 30 Oct 2006 09:58:59 -0800 (PST)
ReSent-From: TOPS-20 List Moderator <[email protected]>
ReSent-To: TOPS-20 Distribution: ;
ReSent-Subject: Re: Remember: update your summer time rules!
ReSent-Message-ID: <[email protected]>

On Sun, 29 Oct 2006, Carl Baltrunas wrote:
> Are you saying that KLH10 provides a simple CTY 'as if' there was a
> black-box in the path between the KL and the CTY, and character data is
> transferred in both directions as the KL thinks it is talking to
> 'whatever it needs' to pass the data?

I'm not sure what you mean by a "black-box in the path between the KL and
the CTY". KLH10 implements enough of the 10/11 protocols to do everything
that TOPS-20 routinely does on a KL system that only has the a CTY
connected to the front end. TOPS-20 basically is told that there are no
other devices on the front end: no TTYs (no DH11s), no LPTs, no CDRs.
There are no secondary front ends (for DECnet) either.

TOPS-20 assumes that there are 5 DL11 lines:
(1) The first one simultaneously TTY0 and the CTY. Normally, TTY0 is
shadowed, but on a real KL you could map the CTY elsewhere (by a boot
procedure that I have not used for over 20 years and hence have long
forgotten) and then TTY0 is uncovered. The CTY line number is
TTY<#DH lines>+5. In the Panda distribution, it is TTY5.
(2) The second is the KLINIK. In user mode, the KLINIK line number is
TTY<#DH lines>+1. In the Panda distribution, it is TTY1. The KLINIK
can also map to the CTY.
(3) The remaining three are the DL11 lines (consoles) for secondary front
ends. These are TTY<#DH lines>+2 through TTY<#DH lines+4>; in the
Panda distribution, these are TTY2 through TTY4.

The KLINIK is not currently implemented in KLH10. I implemented the KS
KLINIK in a very old version of KLH10 to gain me TCP access, but haven't
done so yet in a modern KLH10. My old KLINIK code would have to be
completely redone; it's not at all useful for modern KLH10. IMHO, the
only point to implementing KLINIK would be to allow remote rebooting,
which is a complex project; I've never tried rebooting TOPS-20.
Currently, I always shutdown TOPS-20 and exit KLH10, then re-run it from
UNIX (effectively a power cycle) rather than reboot TOPS-20 within KLH10.

As there are no secondary front ends, the other three DL11 lines aren't
implemented either.

As the text above indicates, DH11 lines are not implemented at all, and in
the Panda distribution the number of DH11 lines is set to 0. Assuming
that TYMCOM-X supported DH11s (these were the normal TTY lines), this is
probably what you would need to do especially since you said that the CTY
in TYMCOM-X can't be used as a terminal under timesharing.

However, since you also say that TYMCOM-X used KLDCP instead of RSX-20F,
that leaves open the question of what TYMCOM-X used for TTY lines. It
could have used something like a DCA MUX which couldn't have gone through
the front end at all (that's what SAIL used). I don't remember if KLDCP
supported TTY lines at all.

-- Mark --

http://panda.com/tops-20
TOPS-20: a great improvement over its successors
30-Oct-2006 20:41:34-PST,7459;000000000000
Return-Path: <[email protected]>
Received: from pangtzu.panda.com ([206.124.149.117]) by lingling.panda.com with TCP/SMTP; Mon, 30 Oct 2006 20:36:39 -0800 (PST)
X-Return-Path: <[email protected]>
X-Received: from pop-canoe.atl.sa.earthlink.net ([207.69.195.66]) by lingling.panda.com with TCP/SMTP; Mon, 30 Oct 2006 20:18:34 -0800 (PST)
X-Received: from cpe-24-221-177-162.ca.sprintbbd.net ([24.221.177.162] helo=[204.238.239.104])
by pop-canoe.atl.sa.earthlink.net with esmtp (Exim 3.36 #1)
id 1Gel51-0002rA-00; Mon, 30 Oct 2006 23:18:27 -0500
In-Reply-To: <[email protected]>
References: <[email protected]> <[email protected]> <[email protected]> <[email protected]> <[email protected]>
Mime-Version: 1.0 (Apple Message framework v624)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <[email protected]>
Content-Transfer-Encoding: 7bit
Cc: TOPS-20 Hackers and Yackers <[email protected]>
From: Carl Baltrunas <[email protected]>
Subject: Re: Remember: update your summer time rules!
Date: Mon, 30 Oct 2006 20:18:22 -0800
To: Mark Crispin <[email protected]>
X-Mailer: Apple Mail (2.624)
ReSent-Date: Mon, 30 Oct 2006 20:36:31 -0800 (PST)
ReSent-From: TOPS-20 List Moderator <[email protected]>
ReSent-To: TOPS-20 Distribution: ;
ReSent-Subject: Re: Remember: update your summer time rules!
ReSent-Message-ID: <[email protected]>

On Oct 30, 2006, at 9:57 AM, Mark Crispin wrote:

> On Sun, 29 Oct 2006, Carl Baltrunas wrote:
>> Are you saying that KLH10 provides a simple CTY 'as if' there was a
>> black-box in the path between the KL and the CTY, and character data
>> is transferred in both directions as the KL thinks it is talking to
>> 'whatever it needs' to pass the data?
>
> I'm not sure what you mean by a "black-box in the path between the KL
> and the CTY". KLH10 implements enough of the 10/11 protocols to do
> everything that TOPS-20 routinely does on a KL system that only has
> the a CTY connected to the front end. TOPS-20 basically is told that
> there are no other devices on the front end: no TTYs (no DH11s), no
> LPTs, no CDRs. There are no secondary front ends (for DECnet) either.

Sorry for not being more descriptive about the 'black-box'.
I was using the term lightly, as whatever hardware or software sat
between the KL and the physical console line on the PDP-11 front-end.

TYMCOM-X has compile-time feature settings to indicate whether it is
talking to a physical console line such as was found on the KA, KI, or
F3, and a logical console on the KS and KL via the PDP-11 interfaces.
Interactive communication between the console terminal and the OS is
only available during the ONCE-only dialog (ONCE-only is a portion of
the OS that allows for formatting and making changes to the disk
structures prior to opening the system to timesharing, taken from
TOPS-10). Once the TYMCOM-X comes up for timesharing, the console is
an output only device, except that KLDCP can be entered from the
console, and the KL can be halted, booted, have memory examined, etc.
TYMCOM-X has no physical TTY lines. All of the TTYs are network ports
via a custom DMA interface that connects to a hardware and software
interface to the TYMNET data network. The KS-10 and F3 could be
networked to a special PDP-11 'node' that could speak the TYMNET
protocol and connect to other TYMNET nodes or regular PDP-11/LSI-11
network and terminal cards.

So, unlike just about every other PDP-10 operating system, TYMCOM-X,
has no regular TTY ports. I'd have to look through the microfiche I
have squirreled away somewhere to see if there's an easy 'hook' to rely
on to get a bi-directional CTY. The whole time I worked at Tymshare
and it's successors, our only connection to a running server was via
TYMNET, which meant trips to the data center when a problem was serious
enough that we couldn't talk an operator through the procedure on the
phone. Except for a few X.25 to Tandem single-node networks, TYMNET is
now defunct. [RIP April 1, 2003 & Feb 2004]

And, YES, we all knew this situation was going to happen, since there
are probably only 3 or 4 people anywhere that would really want to see
TYMCOM-X up and running again. Joe Smith and I are probably the only
two people who have copies of the code, (if Joe took his copy home),
that on 4mm DAT cartridge tapes.

TYMCOM-X is a parallel development that split off from DEC TOPS-10 at
the 5.02 monitor and implemented many of the same features as TOPS-10,
TENEX (and TOPS-20), and XDS-930/940 systems. Terminal services
similar to TOPS-10 TRMOP. were implemented for TYMNET ports via
AUXCAL's (for AUXiliary circuit CALLs through TYMNET). Forking was
done via FRMOP where we called each process a FRAME. It also had an
interesting feature with multiple levels of privilege, where a user
could have specific privileges (nothing new to TENEX/TOPS-10), but it
also could place the same set of privileges on an executable. TYMCOM-X
used a marriage of the process and file privileges to determine actual
privileges during execution, and the process could enable or disable
them to it's maximum as desired. Any unused pages on disk were able to
be used for memory mapping and a process could access memory mapped to
a file, to a private segment, or a shared segment with other processes
based on whether a disk page was mapped to memory, to a file or both
simultaneously. There are others, but in my opinion, these were some
of the features of TYMCOM-X that made it unique.

The lack of a CTY during timesharing, and no real single user mode are
two of it's biggest hassles as far as getting it up and running via an
emulation package. It is possible that some unused code still exists
in some feature setting that could be enabled to make the console work,
but Ernie/Vance Socci would be the only one I know who has looked at
that code in nearly 2 decades.

> Assuming that TYMCOM-X supported DH11s (these were the normal TTY
> lines), this is probably what you would need to do especially since
> you said that the CTY in TYMCOM-X can't be used as a terminal under
> timesharing.

I'd have to review the microfiche sometime, looking at SCNSER most
likely, but I don't think there's any code to talk to a DH11.
Even on the KS, TTY ports were all off on a networked LSI-11 that
connected to TYMNET on one interface, and to the KS on another.
I don't remember if we could use other ports directly off the KS. It's
been too long since I looked at the code (OMG 17+ years already).
>
> However, since you also say that TYMCOM-X used KLDCP instead of
> RSX-20F, that leaves open the question of what TYMCOM-X used for TTY
> lines. It could have used something like a DCA MUX which couldn't
> have gone through the front end at all (that's what SAIL used). I
> don't remember if KLDCP supported TTY lines at all.

If KLDCP supported additional lines, we never used them unless KLINIK
was connected that way. Vance was likely the last one at Tymshare to
use it, if it was ever used.

-Carl

30-Oct-2006 22:42:44-PST,2135;000000000000
Return-Path: <[email protected]>
Received: from pangtzu.panda.com ([206.124.149.117]) by lingling.panda.com with TCP/SMTP; Mon, 30 Oct 2006 22:38:09 -0800 (PST)
X-Return-Path: <[email protected]>
X-Received: from pangtzu.panda.com ([206.124.149.117]) by lingling.panda.com with TCP/SMTP; Mon, 30 Oct 2006 22:37:05 -0800 (PST)
Date: Mon, 30 Oct 2006 22:37:00 -0800 (PST)
From: Mark Crispin <[email protected]>
Sender: [email protected]
To: Carl Baltrunas <[email protected]>
cc: TOPS-20 Hackers and Yackers <[email protected]>
Subject: Re: Remember: update your summer time rules!
In-Reply-To: <[email protected]>
Message-ID: <[email protected]>
References: <[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
ReSent-Date: Mon, 30 Oct 2006 22:37:58 -0800 (PST)
ReSent-From: TOPS-20 List Moderator <[email protected]>
ReSent-To: TOPS-20 Distribution: ;
ReSent-Subject: Re: Remember: update your summer time rules!
ReSent-Message-ID: <[email protected]>

On Mon, 30 Oct 2006, Carl Baltrunas wrote:
> TYMCOM-X has no physical TTY lines. All of the TTYs are network ports
> via a custom DMA interface that connects to a hardware and software
> interface to the TYMNET data network.

OK, then what you probably need to do is to create a module in KLH10 that
implements this DMA interface. I suggest that it have a TELNET server at
the other end, so you can TELNET to the TYMCOM-X server.

That seems like the path of least resistance to me; and probably also
what's right. You probably don't need to worry about any of the KLDCP
details.

-- Mark --

http://panda.com/tops-20
TOPS-20: a great improvement over its successors
31-Oct-2006 08:27:19-PST,4052;000000000000
Return-Path: <[email protected]>
Received: from pangtzu.panda.com ([206.124.149.117]) by lingling.panda.com with TCP/SMTP; Tue, 31 Oct 2006 08:22:42 -0800 (PST)
X-Return-Path: <[email protected]>
X-Received: from smtpout.mac.com ([17.250.248.184]) by lingling.panda.com with TCP/SMTP; Tue, 31 Oct 2006 05:23:18 -0800 (PST)
X-Received: from mac.com (smtpin05-en2 [10.13.10.150])
by smtpout.mac.com (Xserve/8.12.11/smtpout14/MantshX 4.0) with ESMTP id k9VDNCUx010905;
Tue, 31 Oct 2006 05:23:13 -0800 (PST)
X-Received: from [192.168.1.52] (c-24-147-40-233.hsd1.nh.comcast.net [24.147.40.233])
(authenticated bits=0)
by mac.com (Xserve/smtpin05/MantshX 4.0) with ESMTP id k9VDN5mY028585;
Tue, 31 Oct 2006 05:23:08 -0800 (PST)
Mime-Version: 1.0
Message-Id: <p06230901c16cf9821c7b@[192.168.1.52]>
In-Reply-To: <[email protected]>
References: <[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
Date: Tue, 31 Oct 2006 08:23:00 -0500
To: Mark Crispin <[email protected]>
From: John Francini <[email protected]>
Subject: Re: Remember: update your summer time rules!
Cc: TOPS-20 Hackers and Yackers <[email protected]>
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Brightmail-Tracker: AAAAAA==
X-Brightmail-scanned: yes
ReSent-Date: Tue, 31 Oct 2006 08:22:34 -0800 (PST)
ReSent-From: TOPS-20 List Moderator <[email protected]>
ReSent-To: TOPS-20 Distribution: ;
ReSent-Subject: Re: Remember: update your summer time rules!
ReSent-Message-ID: <[email protected]>

That's a good idea for solving the TYMCOM-X problem, but doesn't help
us TOPS-10 users out there. From what I've seen so far, the choices
are:

a) use DECnet or LAT if the host computer supports it (only viable
really on Tru64/Digial UNIX)

b) Teach KLH10's FE code how to emulate DH-11s (with a TELNET front end)

c) Implement software emulation of the old KA/KI I/O bus and
something like the wretched DC-10 mux. (This would require rebuilding
your Monitor with DCSER (if I recall correctly) included, if it still
works under 7.04.)

d) Add a second FE to KLH10 that speaks ANF-10 protocol to TOPS-10
out one end and provides a TELNET-based multi-terminal interface out
the other.

e) Add a second FE to KLH10 (as above), but have it speak ANF-10 to
an emulated PDP-11 sync device (which speaks over Ethernet). Then
run ANF-10 code on one or more instances of Bob Supnik's PDP-11
emulator, which already knows how to emulate DZ-11 terminals through
TELNET.

Without something like this, it'll be rather difficult to use TOPS-10
as anything more than a CTY-bound plaything.

Other ideas would be welcome!

John

At 10:37 PM -0800 10/30/06, Mark Crispin wrote:
>On Mon, 30 Oct 2006, Carl Baltrunas wrote:
>>TYMCOM-X has no physical TTY lines. All of the TTYs are network
>>ports via a custom DMA interface that connects to a hardware and
>>software interface to the TYMNET data network.
>
>OK, then what you probably need to do is to create a module in KLH10
>that implements this DMA interface. I suggest that it have a TELNET
>server at the other end, so you can TELNET to the TYMCOM-X server.
>
>That seems like the path of least resistance to me; and probably
>also what's right. You probably don't need to worry about any of
>the KLDCP details.
>
>-- Mark --
>
>http://panda.com/tops-20
>TOPS-20: a great improvement over its successors

--
John Francini, [email protected]

"The journey is more important than the destination-that's part of
life. If you only live for getting to the end, you're almost always
disappointed." -Donald Knuth
31-Oct-2006 08:34:06-PST,1924;000000000000
Return-Path: <[email protected]>
Received: from pangtzu.panda.com ([206.124.149.117]) by lingling.panda.com with TCP/SMTP; Tue, 31 Oct 2006 08:30:28 -0800 (PST)
X-Return-Path: <[email protected]>
X-Received: from pangtzu.panda.com ([206.124.149.117]) by lingling.panda.com with TCP/SMTP; Tue, 31 Oct 2006 08:26:28 -0800 (PST)
Date: Tue, 31 Oct 2006 08:26:23 -0800 (PST)
From: Mark Crispin <[email protected]>
Sender: [email protected]
To: John Francini <[email protected]>
cc: TOPS-20 Hackers and Yackers <[email protected]>
Subject: Re: Remember: update your summer time rules!
In-Reply-To: <p06230901c16cf9821c7b@[192.168.1.52]>
Message-ID: <[email protected]>
References: <[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
<p06230901c16cf9821c7b@[192.168.1.52]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
ReSent-Date: Tue, 31 Oct 2006 08:30:20 -0800 (PST)
ReSent-From: TOPS-20 List Moderator <[email protected]>
ReSent-To: TOPS-20 Distribution: ;
ReSent-Subject: Re: Remember: update your summer time rules!
ReSent-Message-ID: <[email protected]>

On Tue, 31 Oct 2006, John Francini wrote:
> b) Teach KLH10's FE code how to emulate DH-11s (with a TELNET front end)

SIMH emulates a KS10 with DZ11s, using a TELNET front end. That's what
most TOPS-10 people use.

Conversely, for most TOPS-20 people a KS10 version is little more than a
toy.

-- Mark --

http://panda.com/tops-20
TOPS-20: a great improvement over its successors
31-Oct-2006 12:47:16-PST,2952;000000000000
Return-Path: <[email protected]>
Received: from pangtzu.panda.com ([206.124.149.117]) by lingling.panda.com with TCP/SMTP; Tue, 31 Oct 2006 12:42:02 -0800 (PST)
X-Return-Path: <[email protected]>
X-Received: from smtpout.mac.com ([17.250.248.171]) by lingling.panda.com with TCP/SMTP; Tue, 31 Oct 2006 10:15:35 -0800 (PST)
X-Received: from mac.com (smtpin07-en2 [10.13.10.152])
by smtpout.mac.com (Xserve/8.12.11/smtpout01/MantshX 4.0) with ESMTP id k9VIFSLs005188;
Tue, 31 Oct 2006 10:15:28 -0800 (PST)
X-Received: from [10.68.15.8] ([12.0.44.46])
(authenticated bits=0)
by mac.com (Xserve/smtpin07/MantshX 4.0) with ESMTP id k9VIFP9P008199;
Tue, 31 Oct 2006 10:15:26 -0800 (PST)
In-Reply-To: <[email protected]>
References: <[email protected]> <[email protected]> <[email protected]> <[email protected]> <[email protected]> <[email protected]> <[email protected]> <p06230901c16cf9821c7b@[192.168.1.52]> <[email protected]>
Mime-Version: 1.0 (Apple Message framework v752.2)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <[email protected]>
Cc: TOPS-20 Hackers and Yackers <[email protected]>
Content-Transfer-Encoding: 7bit
From: John Francini <[email protected]>
Subject: Re: Remember: update your summer time rules!
Date: Tue, 31 Oct 2006 13:16:03 -0500
To: Mark Crispin <[email protected]>
X-Mailer: Apple Mail (2.752.2)
X-Brightmail-Tracker: AAAAAA==
X-Brightmail-scanned: yes
ReSent-Date: Tue, 31 Oct 2006 12:41:54 -0800 (PST)
ReSent-From: TOPS-20 List Moderator <[email protected]>
ReSent-To: TOPS-20 Distribution: ;
ReSent-Subject: Re: Remember: update your summer time rules!
ReSent-Message-ID: <[email protected]>

Right, but SIMH in KS-10 mode has all the limits of a KS (Monitor and
user memory, disk I/O constraints, etc), save for CPU speed.

I always felt the KS was a toy (or, more charitably, a limited PDP-10
implementation) 'back in the day' when I worked on the real iron.
This was especially true once 7.03 came out which allowed user-mode
extended addressing and KLNI/KLIPA support.

john

On 31 Oct 2006, at 11:26, Mark Crispin wrote:

> On Tue, 31 Oct 2006, John Francini wrote:
>> b) Teach KLH10's FE code how to emulate DH-11s (with a TELNET
>> front end)
>
> SIMH emulates a KS10 with DZ11s, using a TELNET front end. That's
> what most TOPS-10 people use.
>
> Conversely, for most TOPS-20 people a KS10 version is little more
> than a toy.
>
> -- Mark --
>
> http://panda.com/tops-20
> TOPS-20: a great improvement over its successors

31-Oct-2006 13:22:14-PST,2678;000000000000
Return-Path: <[email protected]>
Received: from pangtzu.panda.com ([206.124.149.117]) by lingling.panda.com with TCP/SMTP; Tue, 31 Oct 2006 13:18:35 -0800 (PST)
X-Return-Path: <[email protected]>
X-Received: from pangtzu.panda.com ([206.124.149.117]) by lingling.panda.com with TCP/SMTP; Tue, 31 Oct 2006 13:18:07 -0800 (PST)
Date: Tue, 31 Oct 2006 13:18:01 -0800 (PST)
From: Mark Crispin <[email protected]>
Sender: [email protected]
To: John Francini <[email protected]>
cc: TOPS-20 Hackers and Yackers <[email protected]>
Subject: Re: Remember: update your summer time rules!
In-Reply-To: <[email protected]>
Message-ID: <[email protected]>
References: <[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
<[email protected]> <p06230901c16cf9821c7b@[192.168.1.52]>
<[email protected]>
<[email protected]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
ReSent-Date: Tue, 31 Oct 2006 13:18:26 -0800 (PST)
ReSent-From: TOPS-20 List Moderator <[email protected]>
ReSent-To: TOPS-20 Distribution: ;
ReSent-Subject: Re: Remember: update your summer time rules!
ReSent-Message-ID: <[email protected]>

On Tue, 31 Oct 2006, John Francini wrote:
> Right, but SIMH in KS-10 mode has all the limits of a KS (Monitor and
> user memory, disk I/O constraints, etc), save for CPU speed.

True, and those limits are crippling for TOPS-20. The KS made a fine
personal computer in the mid-1980s but a growing body of software would
not run on it...and of course no TCP/IP. I tried to make TCP/IP run on
the KS but I got screwed by the wretched memory routines.

> I always felt the KS was a toy (or, more charitably, a limited PDP-10
> implementation) 'back in the day' when I worked on the real iron.
> This was especially true once 7.03 came out which allowed user-mode
> extended addressing and KLNI/KLIPA support.

How many TOPS-10 applications actually used extended addressing? Although
it surprised me that the TOPS-10 people seemed to prefer using SIMH,
apparently they were much less KL-dependent than the TOPS-20 people.

-- Mark --

http://panda.com/tops-20
TOPS-20: a great improvement over its successors
31-Oct-2006 13:46:34-PST,6900;000000000000
Return-Path: <[email protected]>
Received: from pangtzu.panda.com ([206.124.149.117]) by lingling.panda.com with TCP/SMTP; Tue, 31 Oct 2006 13:42:39 -0800 (PST)
X-Return-Path: <[email protected]>
X-Received: from smtpout.mac.com ([17.250.248.175]) by lingling.panda.com with TCP/SMTP; Tue, 31 Oct 2006 13:33:37 -0800 (PST)
X-Received: from mac.com (smtpin07-en2 [10.13.10.152])
by smtpout.mac.com (Xserve/8.12.11/smtpout05/MantshX 4.0) with ESMTP id k9VLXWGX028840;
Tue, 31 Oct 2006 13:33:32 -0800 (PST)
X-Received: from [10.68.15.8] ([12.0.44.46])
(authenticated bits=0)
by mac.com (Xserve/smtpin07/MantshX 4.0) with ESMTP id k9VLXTHP027602;
Tue, 31 Oct 2006 13:33:30 -0800 (PST)
In-Reply-To: <[email protected]>
References: <[email protected]> <[email protected]> <[email protected]> <[email protected]> <[email protected]> <[email protected]> <[email protected]> <p06230901c16cf9821c7b@[192.168.1.52]> <[email protected]> <[email protected]> <[email protected]>
Mime-Version: 1.0 (Apple Message framework v752.2)
Content-Type: multipart/alternative; boundary=Apple-Mail-3--660345579
Message-Id: <[email protected]>
Cc: TOPS-20 Hackers and Yackers <[email protected]>
From: John Francini <[email protected]>
Subject: Re: Remember: update your summer time rules!
Date: Tue, 31 Oct 2006 16:34:08 -0500
To: Mark Crispin <[email protected]>
X-Mailer: Apple Mail (2.752.2)
X-Brightmail-Tracker: AAAAAA==
X-Brightmail-scanned: yes
ReSent-Date: Tue, 31 Oct 2006 13:42:31 -0800 (PST)
ReSent-From: TOPS-20 List Moderator <[email protected]>
ReSent-To: TOPS-20 Distribution: ;
ReSent-Subject: Re: Remember: update your summer time rules!
ReSent-Message-ID: <[email protected]>

--Apple-Mail-3--660345579
Content-Transfer-Encoding: 7bit
Content-Type: text/plain;
charset=US-ASCII;
delsp=yes;
format=flowed

On 31 Oct 2006, at 16:18, Mark Crispin wrote:

> On Tue, 31 Oct 2006, John Francini wrote:
>> Right, but SIMH in KS-10 mode has all the limits of a KS (Monitor
>> and user memory, disk I/O constraints, etc), save for CPU speed.
>
> True, and those limits are crippling for TOPS-20. The KS made a
> fine personal computer in the mid-1980s but a growing body of
> software would not run on it...and of course no TCP/IP. I tried to
> make TCP/IP run on the KS but I got screwed by the wretched memory
> routines.
>
>> I always felt the KS was a toy (or, more charitably, a limited
>> PDP-10 implementation) 'back in the day' when I worked on the real
>> iron. This was especially true once 7.03 came out which allowed
>> user-mode extended addressing and KLNI/KLIPA support.
>
> How many TOPS-10 applications actually used extended addressing?
> Although it surprised me that the TOPS-10 people seemed to prefer
> using SIMH, apparently they were much less KL-dependent than the
> TOPS-20 people.

A very good question. I don't know for sure, as I wasn't much in
customer contact. I _do_ know that we fixed a fair number of SPRs
from LLNL Oak Ridge (quint SMP) and other large KL shops for problems
with user-mode extended addressing. So some of our customers did
indeed use it, because it helped them to preserve their investment in
large PDP-10 iron for several years longer than otherwise possible.

John Francini

--Apple-Mail-3--660345579
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
charset=ISO-8859-1

<HTML><BODY style=3D"word-wrap: break-word; -khtml-nbsp-mode: space; =
-khtml-line-break: after-white-space; "><BR><DIV><SPAN =
class=3D"Apple-style-span"><DIV>On 31 Oct 2006, at 16:18, Mark Crispin =
wrote:</DIV><BR class=3D"Apple-interchange-newline"><BLOCKQUOTE =
type=3D"cite"><DIV style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; ">On Tue, 31 Oct 2006, John =
Francini wrote:</DIV> <BLOCKQUOTE type=3D"cite"><DIV style=3D"margin-top: =
0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">Right, =
but SIMH in KS-10 mode has all the limits of a KS (Monitor and user =
memory, disk I/O constraints, etc), save for CPU speed.</DIV> =
</BLOCKQUOTE><DIV style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; min-height: 14px; "><BR></DIV><DIV =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; ">True, and those limits are crippling for =
TOPS-20.<SPAN class=3D"Apple-converted-space">=A0 </SPAN>The KS made a =
fine personal computer in the mid-1980s but a growing body of software =
would not run on it...and of course no TCP/IP.<SPAN =
class=3D"Apple-converted-space">=A0 </SPAN>I tried to make TCP/IP run on =
the KS but I got screwed by the wretched memory routines.</DIV><DIV =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; min-height: 14px; "><BR></DIV> <BLOCKQUOTE =
type=3D"cite"><DIV style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; ">I always felt the KS was a toy =
(or, more charitably, a limited PDP-10 implementation) 'back in the day' =
when I worked on the real iron. This was especially true once 7.03 came =
out which allowed user-mode extended addressing and KLNI/KLIPA =
support.</DIV> </BLOCKQUOTE><DIV style=3D"margin-top: 0px; margin-right: =
0px; margin-bottom: 0px; margin-left: 0px; min-height: 14px; =
"><BR></DIV><DIV style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; ">How many TOPS-10 applications =
actually used extended addressing?<SPAN class=3D"Apple-converted-space">=A0=
</SPAN>Although it surprised me that the TOPS-10 people seemed to =
prefer using SIMH, apparently they were much less KL-dependent than the =
TOPS-20 people.</DIV></BLOCKQUOTE><DIV><BR =
class=3D"khtml-block-placeholder"></DIV>A very good question.=A0 I don't =
know for sure, as I wasn't much in customer contact.=A0 I _do_ know that =
we fixed a fair number of SPRs from LLNL Oak Ridge (quint SMP) and other =
large KL shops for problems with user-mode extended addressing.=A0 So =
<I>some </I>of our customers did indeed use it, because it helped them =
to preserve their investment in large PDP-10 iron for several years =
longer than otherwise possible.</SPAN></DIV><DIV><BR =
class=3D"khtml-block-placeholder"></DIV>John Francini<BR><DIV><BR =
class=3D"khtml-block-placeholder"></DIV></BODY></HTML>=

--Apple-Mail-3--660345579--
31-Oct-2006 13:50:14-PST,2510;000000000000
Return-Path: <[email protected]>
Received: from pangtzu.panda.com ([206.124.149.117]) by lingling.panda.com with TCP/SMTP; Tue, 31 Oct 2006 13:43:06 -0800 (PST)
X-Return-Path: <[email protected]>
X-Received: from smtpout.mac.com ([17.250.248.175]) by lingling.panda.com with TCP/SMTP; Tue, 31 Oct 2006 13:38:20 -0800 (PST)
X-Received: from mac.com (smtpin07-en2 [10.13.10.152])
by smtpout.mac.com (Xserve/8.12.11/smtpout05/MantshX 4.0) with ESMTP id k9VLcENj001713;
Tue, 31 Oct 2006 13:38:14 -0800 (PST)
X-Received: from [10.68.15.8] ([12.0.44.46])
(authenticated bits=0)
by mac.com (Xserve/smtpin07/MantshX 4.0) with ESMTP id k9VLcCBa029514;
Tue, 31 Oct 2006 13:38:13 -0800 (PST)
In-Reply-To: <[email protected]>
References: <[email protected]> <[email protected]> <[email protected]> <[email protected]> <[email protected]> <[email protected]> <[email protected]> <p06230901c16cf9821c7b@[192.168.1.52]> <[email protected]> <[email protected]> <[email protected]>
Mime-Version: 1.0 (Apple Message framework v752.2)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <[email protected]>
Cc: TOPS-20 Hackers and Yackers <[email protected]>
Content-Transfer-Encoding: 7bit
From: John Francini <[email protected]>
Subject: Re: Remember: update your summer time rules!
Date: Tue, 31 Oct 2006 16:38:50 -0500
To: Mark Crispin <[email protected]>
X-Mailer: Apple Mail (2.752.2)
X-Brightmail-Tracker: AAAAAA==
X-Brightmail-scanned: yes
ReSent-Date: Tue, 31 Oct 2006 13:42:55 -0800 (PST)
ReSent-From: TOPS-20 List Moderator <[email protected]>
ReSent-To: TOPS-20 Distribution: ;
ReSent-Subject: Re: Remember: update your summer time rules!
ReSent-Message-ID: <[email protected]>

Of course, to return back to the topic of this thread, TOPS-10
continues to be blissfully ignorant of time zones, DST, and all that
sort of stuff.

(I remember having a pair of each-submitting-the-other batch jobs
that would move the system time forward one hour in the spring and
back one hour in the fall on KL1026.)

j

29-Nov-2006 20:45:25-PST,4437;000000000000
Return-Path: <[email protected]>
Received: from pangtzu.panda.com ([206.124.149.117]) by lingling.panda.com with TCP/SMTP; Wed, 29 Nov 2006 20:40:51 -0800 (PST)
X-Return-Path: <[email protected]>
X-Received: from mta5.srv.hcvlny.cv.net ([167.206.4.200]) by lingling.panda.com with TCP/SMTP; Wed, 29 Nov 2006 17:45:05 -0800 (PST)
X-Received: from optonline.net (hamstr3.srv.hcvlny.cv.net [167.206.5.10])
by mta5.srv.hcvlny.cv.net
(Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006))
with ESMTP id <[email protected]> for
[email protected]; Wed, 29 Nov 2006 20:44:59 -0500 (EST)
X-Received: from [10.240.3.208] (Forwarded-For: 69.114.1.48, [10.240.3.208])
by mstr3.srv.hcvlny.cv.net (mshttpd); Thu, 30 Nov 2006 01:44:59 +0000 (GMT)
Date: Thu, 30 Nov 2006 01:44:59 +0000 (GMT)
From: [email protected]
Subject: MM Examine/Get Status display
In-reply-to: <[email protected]>
To: [email protected]
Message-id: <[email protected]>
MIME-version: 1.0
X-Mailer: Sun Java(tm) System Messenger Express 6.2-6.01 (built Apr 3 2006)
Content-type: text/plain; charset=us-ascii
Content-language: en
Content-transfer-encoding: 7BIT
Content-disposition: inline
X-Accept-Language: en
Priority: normal
References: <[email protected]>
ReSent-Date: Wed, 29 Nov 2006 20:40:40 -0800 (PST)
ReSent-From: TOPS-20 List Moderator <[email protected]>
ReSent-To: TOPS-20 Distribution: ;
ReSent-Subject: MM Examine/Get Status display
ReSent-Message-ID: <[email protected]>

I recently put a small (and hopefully innocuous) change into MM that I
thought might be of use or interest to others.

I spend a bit of time sorting my mail file into different files and
then accessing these files at later dates. Once the mail is sorted, I
generally never modify the files again, protecting them ;P420000 and
only accessing them with the EXAMINE command.

However, those few times that I've reprotected these files in order to
work on them, I've gotten mixed up, meant to do a GET but still used
EXAMINE. While I type STATUS a lot to make sure I'm in the right
file, STATUS unfortunately does not display whether the file is
read-only or not.

As far as I can tell, nothing in MM tells you that you have a
read-only file open until you try to actually do something with that
file. Then you are presented with an error message; I.E., I do some
hairy HEADER stuff, then do a MOVE and become annoyed.

So, I knocked together a few lines of code to make things a little
more explicit, perhaps in the spirit of what EMACS does:

STATF: HRROI A,MAUSRS ;If an alias is in effect
TXNE F,F%ALIA ;Then let user know to whom
CIETYP < Alias: %1S>
SKIPG A,MSGJFN
ERROR <No current file>
CIETYP < File: %1J> ;Say what file we are using
;[T39] Begin code addition
GTSTS% ; Get the file status
IFJN. S ; Ignore error, preserve A
ANDXN. B,GS%NAM ; Is there anything there?
ANDXN. B,GS%OPN ; and are we doing anything with it?
ANDXE. B,GS%WRF ; and are we NOT writing?
ANDXN. F,F%RONL ; and do we think it is read-only?
TMSG < (RO)> ; Yes, say something about it
ENDIF. ; End case of successful GTSTS%
;[T39] End code addition

It may be remarked that the code is redundant: I probably only really
need to check F%RONL. However since I'm in no way an MM Hero, I tried
to be (perhaps overly) defensive. I'll certainly differ to others as
to the usefulness and appropriateness of the code.

But I think the idea itself, or something like it, may be useful, viz:

MM>; Case of writable access
MM>GET MAIL.TXT

Last read: 29-Nov-2006 20:16:59, 5 messages, 3 pages
MM>STATUS
FILE: TOMMYT:<SLOGIN>MAIL.TXT.1
Last read: 29-Nov-2006 20:08:30, 5 messages, 3 pages
Currently at message 5.

MM>; Case of read-only access
MM>EXAMINE MAIL.TXT

Last read: 29-Nov-2006 20:16:59, 5 messages, 3 pages
MM>STATUS
File: TOMMYT:<SLOGIN>MAIL.TXT.1 (RO)
Last read: 29-Nov-2006 20:16:59, 5 messages, 3 pages
Currently at message 5.

2-Dec-2006 10:41:20-PST,6526;000000000000
Return-Path: <[email protected]>
Received: from pangtzu.panda.com ([206.124.149.117]) by lingling.panda.com with TCP/SMTP; Sat, 2 Dec 2006 10:34:18 -0800 (PST)
X-Return-Path: <[email protected]>
X-Received: from mta3.srv.hcvlny.cv.net ([167.206.4.198]) by lingling.panda.com with TCP/SMTP; Fri, 1 Dec 2006 19:00:52 -0800 (PST)
X-Received: from optonline.net (hamstr3.srv.hcvlny.cv.net [167.206.5.10])
by mta3.srv.hcvlny.cv.net
(Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006))
with ESMTP id <[email protected]> for
[email protected]; Fri, 01 Dec 2006 22:00:46 -0500 (EST)
X-Received: from [10.240.3.197] (Forwarded-For: 66.114.69.214, [10.240.3.197])
by mstr3.srv.hcvlny.cv.net (mshttpd); Sat, 02 Dec 2006 03:00:45 +0000 (GMT)
Date: Sat, 02 Dec 2006 03:00:45 +0000 (GMT)
From: [email protected]
Subject: Tomorrow is Yesterday
In-reply-to: <[email protected]>
To: [email protected]
Message-id: <[email protected]>
MIME-version: 1.0
X-Mailer: Sun Java(tm) System Messenger Express 6.2-6.01 (built Apr 3 2006)
Content-type: text/plain; charset=us-ascii
Content-language: en
Content-transfer-encoding: 7BIT
Content-disposition: inline
X-Accept-Language: en
Priority: normal
References: <[email protected]>
<[email protected]>
ReSent-Date: Sat, 2 Dec 2006 10:34:08 -0800 (PST)
ReSent-From: TOPS-20 List Moderator <[email protected]>
ReSent-To: TOPS-20 Distribution: ;
ReSent-Subject: Tomorrow is Yesterday
ReSent-Message-ID: <[email protected]>

Problem:

MM will nicely parse an arbitrary date and/or time for the /AFTER:
switch parameter when sending mail, but it doesn't find the fact
that the specified value is in the past to be particularly
remarkable.

I get nailed by this a lot when I forget to specify the full four
digit year for the date (and I also do mis-type). For example,
7-DEC-06 is 7-DEC-1906, not 7-DEC-2006. So, I hit send and feel
foolish.

Cure:

Check the parsed value for the /AFTER: switch parameter and ensure
that it at least has a CHANCE of being in the future.

Code:

Around .AFTER:, do the following:

;[T40] Begin code addition

DEFINE UCASTL (REG,ADDR) < ;;Cast an unsigned word to a signed long

IFNB <ADDR>,<.FATAL 'ADDR Can only cast values in registers!>
IFG REG-^O16,<.FATAL Register 'REG is out of bounds>

MOVE REG+1,REG ;;Put unsigned single in low order
TXZE REG+1,<1B0> ;;Does low order look negative?
SKIPA REG,[1] ;;Yes, put the high order bit in the high
SETZ REG, ;;Otherwise zero high order word
>;;UCASTL

DEFINE DCAML (R,A,%N,%S,%L) < ;;Double compare and skip if less

IFB <A>,<.FATAL Not comparing to anything!>
IFG R-^O16,<.FATAL Register 'R is out of bounds>

CAMN R,A ;;Compare high order
JRST %L ;; Equal, check low order
CAML R,A ;;Compare high order, skip if less
JRST %N ;;Not less, non-skip
JRST %S ;;Less, skip
%L:! CAML R+1,A+1 ;;Compare low order
%N:! ;;Not less, Non-skip return
%S==%N+1 ;;Less, Skip return
.XCREF %L,%N,%S ;;Useless in CREF
>;;DCAML

;[T40] End of code addition

AFTER: SAVEAC <D,E> ;[T40] Just in case
NOISE (DATE)
MOVEI B,[FLDDB. .CMTAD,,CM%IDA!CM%ITM,,,<[
FLDDB. .CMTAD,,CM%IDA,,,<[
FLDDB. .CMTAD,,CM%ITM]>]>]
CALL CMDFLD
PUSH P,B ;Remember date/time
CONFRM
POP P,E ;[T40] Restore a safe copy of the parsed time
GTAD% ;[T40] Get current system time
IFJE. R ;[T40] If it failed
SETO A, ;[T40] Say that the date and time aren't set
ENDIF. ;[T40] But it actually shouldn't ever fail...
CAMN A,[-1] ;[T40] Do we have anything useful to work with?
IFSKP. ;[T40] Yes, is the parsed time in the future?
UCASTL A, ;[T40] Cast unsigned system time to long
MOVE C,E ;[T40] Load a working copy of parsed time
UCASTL C, ;[T40] Cast unsigned parsed time to long
DCAML A,C ;[T40] Any chance the parsed time is passed?
ERROR (The specified AFTER: parameter is not in the future)
ENDIF. ;[T40] End case of valid system time
MOVEM E,AFTDAT ;[T40] Set date/time
RET

Example:

@MM
TOMMYT.#Internet MM-20 7.1(1178)-6
Last read: 1-Dec-2006 21:10:58, 11 messages, 5 pages
MM>daytime
Friday, December 1, 2006 21:13:33
MM>send SLogin
Subject: Past
Message:
(End with ESCAPE or CTRL/D or CTRL/Z)

Show operation of /AFTER: checking

MM Send>>After 1-jan-2002
?The specified AFTER: parameter is not in the future
MM Send>>
MM Send>>after 1-jan-2020
MM Send>>display all

From: Thomas DeBellis <Slogin@TOMMYT.#Internet>
Subject: After Test
To: Slogin@TOMMYT.#Internet
After: Wed, 1 Jan 2020 00:00:01 -0500 (EST)

Show operation of /AFTER: checking

Comments:

It may be a matter of taste as to whether checking the /AFTER:
switch should produce an actual program error or not. It might be
more appropriate to merely comment about the value via "%" instead
of generating an error via "?" (ESOUT%) and possibly gronking a
Batch job.

The current code only checks for /AFTER: parameters that were in
the past when the time value was actually parsed. If the user
sending mail types the /AFTER: first and then does some lengthy
editing, then you'll still have the situation of the message
immediately going out which might not be what was intended.

Given the above, it may be appropriate to put some sort of auto-
cuteness in the code to comment on the fact that the specified
future date will not be very long in coming ...

The use of 72 bit signed arithmatic is to ensure that MM remains
nice and healthy even after September 27th 2217 passes, when the
unsigned internal date and time number will begin to 'look
negative'. One assumes that by this point, the world will have
come to its collective senses and switched all computer use over
to Tops-20.

I have an entire set of DCAMX macros which I (tediously) coded for
the Extended mode FTP server which has to do a lot of date
frobinicating to handle 32 bit UNIX times. It is possible that I
will put these in a seperate UNIVERSAL file for later usage by
others (like HSTNAM or CMD)

PS: Of course "Beam me up"

3-Dec-2006 11:18:57-PST,3967;000000000000
Return-Path: <[email protected]>
Received: from pangtzu.panda.com ([206.124.149.117]) by lingling.panda.com with TCP/SMTP; Sun, 3 Dec 2006 11:14:35 -0800 (PST)
X-Return-Path: <[email protected]>
X-Received: from mta4.srv.hcvlny.cv.net ([167.206.4.199]) by lingling.panda.com with TCP/SMTP; Sun, 3 Dec 2006 10:58:02 -0800 (PST)
X-Received: from optonline.net (hamstr3.srv.hcvlny.cv.net [167.206.5.10])
by mta4.srv.hcvlny.cv.net
(Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006))
with ESMTP id <[email protected]> for
[email protected]; Sun, 03 Dec 2006 13:57:48 -0500 (EST)
X-Received: from [10.240.3.214] (Forwarded-For: 66.114.69.214, [10.240.3.214])
by mstr3.srv.hcvlny.cv.net (mshttpd); Sun, 03 Dec 2006 18:57:48 +0000 (GMT)
Date: Sun, 03 Dec 2006 18:57:48 +0000 (GMT)
From: [email protected]
Subject: Multi-module parsing with CMD.MAC
In-reply-to: <[email protected]>
To: [email protected]
Message-id: <[email protected]>
MIME-version: 1.0
X-Mailer: Sun Java(tm) System Messenger Express 6.2-6.01 (built Apr 3 2006)
Content-type: text/plain; charset=us-ascii
Content-language: en
Content-transfer-encoding: 7BIT
Content-disposition: inline
X-Accept-Language: en
Priority: normal
References: <[email protected]>
<[email protected]> <[email protected]>
ReSent-Date: Sun, 3 Dec 2006 11:14:26 -0800 (PST)
ReSent-From: TOPS-20 List Moderator <[email protected]>
ReSent-To: TOPS-20 Distribution: ;
ReSent-Subject: Multi-module parsing with CMD.MAC
ReSent-Message-ID: <[email protected]>

Problem:
========

CMD provides a handy macro called CMDSTG to generate COMND JSYS
storage. Unfortunately, this MACRO can only be invoked once in the
entire program or else there will be global symbol conflicts.

In complex programs, more than one module may be doing parsing and
there is no convenient way to declare CMD's external symbols, storage
locations and routine addresses.

Doing so piecemeal can lead to errors, exactly the situation CMDSTG is
designed to prevent.

Background:
===========

I bumped into this while coding the new Tops-20 extended mode FTP
server. While the main loop (EFTPSR) does nearly all of the top-level
RFC959 verb parsing, an auxiliary module (EFTPSA) exists for certain
complex secondary cases. In addition all of the TVFS parsing code
resides in another module (EFTPSV) while all of the SITE local parsing
is in yet another module (EFTPSS).

This design is appropriate in terms of compartmentalizing various
parsing paradigms and necessary because some modules are getting
'large': the combined source code is now close to 500 pages; a
complete assembly takes more time than I care to wait. Further code
rearrangement was also needed because the extensive number of macro
(not MACRO) generated symbols was causing the assembler to run out of
space.

Cure:
=====

Create a macro for CMD to have in case the programmer wants to do
this. In CMD.MAC, insert the following:

DEFINE CMDSYM < ;;External symbols used by CMD

REMARK Storage area symbols and lengths declared by CMDSTG

IFNDEF CMDBLN,<CMDBLN==<^D80*6>/5+1> ;;ROOM FOR SIX LINE COMMAND
IFNDEF ATMBLN,<ATMBLN==CMDBLN> ;;
IFNDEF CJFNLN,<CJFNLN==20> ;;Length of GTJFN block
IFNDEF CMDPLN,<CMDPLN==200> ;;AMOUNT OF STACK WE CAN SAVE

REMARK Storage areas declared by CMDSTG

EXTERNAL SBK ;;STATE BLOCK
EXTERNAL CMDACS ;;BLOCK TO STORE AC'S WHEN COMMAND STARTS
EXTERNAL CMDBUF ;;USER'S COMMAND BUFFER AND LENGTH
EXTERNAL ATMBUF ;;ATOM BUFFER AND LENGTH
EXTERNAL CJFNBK ;;JFN BLOCK
EXTERNAL REPARA ;;HOLDS REPARSE ADDRESS
EXTERNAL CMDPDL ;;PLACE TO SAVE STACK WHEN COMMAND STARTS
EXTERNAL CMDFRM ;;HOLDS BOTTOM OF STACK
EXTERNAL CMDERR ;;Handles a parse error
>

6-Dec-2006 08:14:21-PST,4182;000000000000
Return-Path: <[email protected]>
Received: from pangtzu.panda.com ([206.124.149.117]) by lingling.panda.com with TCP/SMTP; Wed, 6 Dec 2006 08:09:21 -0800 (PST)
X-Return-Path: <[email protected]>
X-Received: from mta5.srv.hcvlny.cv.net ([167.206.4.200]) by lingling.panda.com with TCP/SMTP; Tue, 5 Dec 2006 22:38:21 -0800 (PST)
X-Received: from optonline.net (hamstr3.srv.hcvlny.cv.net [167.206.5.10])
by mta5.srv.hcvlny.cv.net
(Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006))
with ESMTP id <[email protected]> for
[email protected]; Wed, 06 Dec 2006 01:38:15 -0500 (EST)
X-Received: from [10.240.3.214] (Forwarded-For: 66.114.69.214, [10.240.3.214])
by mstr3.srv.hcvlny.cv.net (mshttpd); Wed, 06 Dec 2006 06:38:14 +0000 (GMT)
Date: Wed, 06 Dec 2006 06:38:14 +0000 (GMT)
From: [email protected]
Subject: Year 2000 Queue display issue for /AFTER: parameter
In-reply-to: <[email protected]>
To: [email protected]
Message-id: <[email protected]>
MIME-version: 1.0
X-Mailer: Sun Java(tm) System Messenger Express 6.2-6.01 (built Apr 3 2006)
Content-type: text/plain; charset=us-ascii
Content-language: en
Content-transfer-encoding: 7BIT
Content-disposition: inline
X-Accept-Language: en
Priority: normal
References: <[email protected]>
<[email protected]> <[email protected]>
<[email protected]>
ReSent-Date: Wed, 6 Dec 2006 08:08:56 -0800 (PST)
ReSent-From: TOPS-20 List Moderator <[email protected]>
ReSent-To: TOPS-20 Distribution: ;
ReSent-Subject: Year 2000 Queue display issue for /AFTER: parameter
ReSent-Message-ID: <[email protected]>

Problem:
========

Display of batch (and other) jobs queued with the /AFTER:
parameter is not Year 2000 compliant.

Symptom:
========

Batch Queue:
Job Name Req# Run Time User
-------- ------ -------- ------------------------
UPTIME 21 00:05:00 SLOGIN /After: 6-Dec-2006 01:
HAPPY 22 00:05:00 SLOGIN /After:11-Dec-2006 07:
There are 2 jobs in the queue (none in progress)

Analysis:
=========

GLXTXT is properly rendering an internal time, but needs two more
characters to fit the year text into a field that the Quasar queue
display module has restricted to 15 characters.

Cure:
=====

Either fix GLXTXT to clip the first two digits of the year so that
Quasar will display the right thing or leave GLXTXT alone and
increase the field widths in Quasar. I've chosen the later
approach.

Code:
=====

File 1) DSK:QSRDSP.MAC[4,106] created: 0050 06-Dec-06
File 2) DSK:QSRDSP.BAK[4,106] created: 1651 10-Jun-90

1)1 ;[TOMMYT]STAR:<GALAXY-SOURCES>QSRDSP.MAC.2, 6-Dec-2006 00:48:48, Edit by SLOGIN
1) ;[T42] Make queue display Year 2000 compliant
1) TITLE QSRDSP - OPERATOR DISPLAY ROUTINES.
****
2)1 TITLE QSRDSP - OPERATOR DISPLAY ROUTINES.
**************
1)57 MOVEI S1,^D26 ;[T42] ;GET LENGTH FOR NEXT FIELD
1) PUSHJ P,CHKSPC ;MAKE SURE THERE IS ROOM
1) $TEXT (DEPBYT,< /After:^H17/.QECRE(AP)/^A>) ;[T42] ;YES,,SAY SO
1)
1) DMP.12: SKIPG LISTYP ;IS THIS AN EVERYTHING LIST ??
****
2)57 MOVEI S1,^D24 ;GET LENGTH FOR NEXT FIELD
2) PUSHJ P,CHKSPC ;MAKE SURE THERE IS ROOM
2) $TEXT (DEPBYT,< /After:^H15/.QECRE(AP)/^A>) ;YES,,SAY SO
2)
2) DMP.12: SKIPG LISTYP ;IS THIS AN EVERYTHING LIST ??
**************

Result:
=======

Batch Queue:
Job Name Req# Run Time User
-------- ------ -------- ------------------------
UPTIME 1 00:05:00 SLOGIN /After: 6-Dec-2006 01:47
HAPPY 2 00:05:00 SLOGIN /After:11-Dec-2006 07:00
There are 2 jobs in the queue (none in progress)

8-Dec-2006 09:49:10-PST,7558;000000000000
Return-Path: <[email protected]>
Received: from pangtzu.panda.com ([206.124.149.117]) by lingling.panda.com with TCP/SMTP; Fri, 8 Dec 2006 09:43:38 -0800 (PST)
X-Return-Path: <[email protected]>
X-Received: from mta2.srv.hcvlny.cv.net ([167.206.4.197]) by lingling.panda.com with TCP/SMTP; Thu, 7 Dec 2006 14:03:53 -0800 (PST)
X-Received: from optonline.net (hamstr3.srv.hcvlny.cv.net [167.206.5.10])
by mta2.srv.hcvlny.cv.net
(Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006))
with ESMTP id <[email protected]> for
[email protected]; Thu, 07 Dec 2006 17:03:47 -0500 (EST)
X-Received: from [10.240.3.211] (Forwarded-For: 66.114.69.214, [10.240.3.211])
by mstr3.srv.hcvlny.cv.net (mshttpd); Thu, 07 Dec 2006 22:03:47 +0000 (GMT)
Date: Thu, 07 Dec 2006 22:03:47 +0000 (GMT)
From: [email protected]
Subject: Tommy Timesharing joins the Tops-20 365 Club!
In-reply-to: <[email protected]>
To: [email protected]
Message-id: <[email protected]>
MIME-version: 1.0
X-Mailer: Sun Java(tm) System Messenger Express 6.2-6.01 (built Apr 3 2006)
Content-type: text/plain; charset=us-ascii
Content-language: en
Content-transfer-encoding: 7BIT
Content-disposition: inline
X-Accept-Language: en
Priority: normal
References: <[email protected]>
<[email protected]> <[email protected]>
<[email protected]> <[email protected]>
ReSent-Date: Fri, 8 Dec 2006 09:43:28 -0800 (PST)
ReSent-From: TOPS-20 List Moderator <[email protected]>
ReSent-To: TOPS-20 Distribution: ;
ReSent-Subject: Tommy Timesharing joins the Tops-20 365 Club!
ReSent-Message-ID: <[email protected]>

Tommy Timesharing has just set an uptime record of over one year in
continuous operation--that's 365/24/7 service without a reboot. The
monitor was started on December 6th of 2005 (last year!) at 1:47:11 in
the morning.

This is obviously impressive given the performance of certain other
'modern' operating systems, but what makes it PARTICULARLY impressive
is that this uptime record has occurred despite some very, VERY active
software development on the Extended mode Tops-20 FTP server.

Such first line software development under other 'modern' systems
carries the great risk of system crashes and hangs. Oh yeah, the
system also sends buckets of email. But it's still not the same as
having 70 users signed on. :-(

I celebrated by hacking together a small program to display when the
UP2LNG BUGHLT will occur along with a help file. This is to help me
set a shutdown time, which I prefer to the bug halt.

Example:
========

@TIMET2
Tops-20 will crash with an UP2LNG BUGHLT on 7-Jan-2007 18:09:28 (local time).

Source Code
===========

TITLE TIMET2 - Time to UP2LNG BUGHLT
SUBTTL Thomas DeBellis, 12:25pm Thursday, 7 December 2006

SEARCH MONSYM,MACSYM
STDAC.
.REQUIRE SYS:MACREL

UTCDAY==<1,,0> ; UTC ticks in a day
MS1DAY==<^D1000*^D60*^D60*^D24> ; Milliseconds in a full day
PDLLEN==^D100
DEFINE JERROR <ERCALS ERROR>

DEFINE .FATAL (MESSAGE) <
PASS2
PRINTX ?'MESSAGE
END
>;;DEFINE .FATAL

DEFINE UCASTL (REG,ADDR) < ;;Cast an unsigned word to a signed long

IFNB <ADDR>,<.FATAL 'ADDR Can only cast values in registers!>
IFG REG-^O16,<.FATAL Register 'REG is out of bounds>

MOVE REG+1,REG ;;Put unsigned single in low order
TXZE REG+1,<1B0> ;;Does low order look negative?
SKIPA REG,[1] ;;Yes, put the high order bit in the high
SETZ REG, ;;Otherwise zero high order word
>;;UCASTL

DEFINE LCASTU (REG,ADDR) < ;;Cast signed long to an unsigned word

IFNB <ADDR>,<.FATAL 'ADDR Can only cast values in registers!>
IFG REG-^O16,<.FATAL Register 'REG is out of bounds>

CAXE REG,0 ;;Any high order?
TXOA REG+1,<1B0> ;;Cast down to unsigned word
TXZ REG+1,<1B0> ;;Otherwise scrub low order long to word
>;;UCASTL

TIMET2: MOVE P,[IOWD PDLLEN,PDL] ;Set up stack
RESET% ; House cleaning
JERROR ; Didn't know it CAN fail ...
TIME% ; Get milliseconds since boot
JERROR ; Shouldn't ever fail either, but ...
UCASTL T1, ; Cast unsigned word to signed long
DMOVE P1,[EXP 0,.INFIN] ;Maximum MS allowed by APRSRV
DSUB P1,T1 ; Calculate elapsed MS until UP2LNG
CAXE P1,0 ; But more than 397 days, 16:22:18 ??
CALL ERROR ; Must be a new APRSRV ...

MOVE P3,P2 ; Load low order MS to UP2LNG
MULX P3,UTCDAY ; Convert X ms to UTC * X ms
DIVX P3,MS1DAY ; Strip off the milliseconds
CAXL P4,MS1DAY/^D2 ; Are we over half a tick?
ADDX P3,^D1 ; Add in a UTC tick
UCASTL P3, ; Cast to long UTC ticks to UP2LNG

GTAD% ; Get the current time of day
JERROR ; Can't fail, but just in case ...
CAMN T1,[-1] ; Is the system time set?
CALL ERROR ; No! Don't say we know it.
UCASTL T1, ; Cast unsigned UTC TOD to signed long

DMOVE P5,T1 ; Load UTC TOD
DADD P5,P3 ; Calculate time to UP2LNG
CAXLE P5,^D1 ; UP2LNG is past 7-Aug-2576 19:59:59 EST?
DMOVE P5,[EXP 1,.INFIN] ;Won't be winning for much longer ...

DMOVE T1,P5 ; Load signed long UP2LNG TOD
LCASTU T1, ; Cast to unsigned word
CAMN T2,[-1] ; Is this ODTIM% magic NOW value?
MOVX T2,.INFIN-1 ; Round down to highest unsigned TOD

TMSG <Tops-20 will crash with an UP2LNG BUGHLT on >
MOVX T1,.PRIOU
SETZ T3, ; Default flags
ODTIM% ; Finally!
JERROR ; Or not ...
TMSG < (local time).
>
HALTF% ; All done
JRST TIMET2 ; But do it again (shouldn't change)

ERROR: HRROI T1,[ASCIZ /Program error - /]
ESOUT%
ERJMPS .+1
GETER%
MOVE T2,T1
MOVX T1,.PRIOU
SETZ T3,
ERSTR%
ERJMPR .+2
ERJMPR .+1
HALTF%
JRST TIMET2 ; Try it again

PDL: BLOCK PDLLEN

END 1,,TIMET2

Help File
=========

TIMET2 tells you when the system is going to crash with an UP2LNG bug
halt.

Tops-20 maintains an elapsed count of milliseconds from the time it is
booted. This counter is stored in TODCLK.

Although the milliseconds from system boot counter itself is unsigned,
various code in Tops-20 (such as in SCHED and APRSRV) treats it as a
signed value, particularly via the use of signed arithmetic compare
instructions (I.E., the CAI and CAM group).

Once TODCLK increases from a 35 bit count into 36 bit count, its value
will appear to be negative to these routines which will then produce
(possibly wildly) inappropriate answers.

Tops-20 prevents this by crashing with an UP2LNG bug halt when the
wrap is detected. Thus, the maximum that Tops-20 can be up is
34,359,738,367 milliseonds or 397 days, 16 hours, 22 minutes and 18
seconds.

TIMET2 calculates the number of milliseconds to UP2LNG bug halt and
adds this into the current date and time, producing the date and time
when this bug halt will occur which is then displayed.

It is suggested that an orderly system shutdown be scheduled (via the
HSYS%) approximately ten to fifteen minutes before the value typed by
TIMET2 in order to not risk file system corruption.

Notes:

1) It makes no sense to repeatedly run or continue TIMET2 as the
output will never change during any particular run of the
operating system.

2) It is probably inappropriate to keep the current pre-UP2LNG
shutdown value in a list of queued shutdowns.

3) Further information on UP2LNG can be gleaned from the UPDTCK
routine in APRSRV.

8-Dec-2006 10:15:24-PST,2632;000000000000
Return-Path: <[email protected]>
Received: from pangtzu.panda.com ([206.124.149.117]) by lingling.panda.com with TCP/SMTP; Fri, 8 Dec 2006 10:11:21 -0800 (PST)
X-Return-Path: <[email protected]>
X-Received: from pangtzu.panda.com ([206.124.149.117]) by lingling.panda.com with TCP/SMTP; Fri, 8 Dec 2006 10:09:05 -0800 (PST)
Date: Fri, 8 Dec 2006 10:08:57 -0800 (PST)
From: Mark Crispin <[email protected]>
Sender: [email protected]
To: [email protected]
cc: [email protected]
Subject: Re: Tommy Timesharing joins the Tops-20 365 Club!
In-Reply-To: <[email protected]>
Message-ID: <[email protected]>
References: <[email protected]> <[email protected]>
<[email protected]> <[email protected]>
<[email protected]>
<[email protected]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
ReSent-Date: Fri, 8 Dec 2006 10:11:14 -0800 (PST)
ReSent-From: TOPS-20 List Moderator <[email protected]>
ReSent-To: TOPS-20 Distribution: ;
ReSent-Subject: Re: Tommy Timesharing joins the Tops-20 365 Club!
ReSent-Message-ID: <[email protected]>

On Thu, 7 Dec 2006, [email protected] wrote:
> Tommy Timesharing has just set an uptime record of over one year in
> continuous operation--that's 365/24/7 service without a reboot. The
> monitor was started on December 6th of 2005 (last year!) at 1:47:11 in
> the morning.

Congratulations. That beats Lingling's record; but then again one of the
disadvantages of living on an island with lots of trees is that there
isn't such a thing as reliable power. I forget how far Lingling got; it
was in the 6000-7000 hour range.

Lingling's current uptime is a mere 3145 hours (yup, even in August we
have power outages). Since we're now in windstorm season I suspect it
won't get much higher. If by some miracle the Puget Sound Energy gods
spare Lingling, it won't be until September 1 at 02:02:09.

XKL has hit UP2LNG, and I think that they extended the timers so that
their monitor can run for longer.

A Panda monitor running as a virtual machine under Windows (but that was
hibernated onto disk most of the time, so it wasn't really "up") also hit
UP2LNG, and I discovered that the DEC code for it was buggy -- instead of
crashing, it wrapped! That's fixed in current Panda monitors.

-- Mark --

http://panda.com/tops-20
TOPS-20: a great improvement over its successors

8-Dec-2006 10:41:05-PST,8063;000000000000
Return-Path: <[email protected]>
Received: from pangtzu.panda.com ([206.124.149.117]) by lingling.panda.com with TCP/SMTP; Fri, 8 Dec 2006 10:37:03 -0800 (PST)
X-Return-Path: <[email protected]>
X-Received: from smtpout.mac.com ([17.250.248.184]) by lingling.panda.com with TCP/SMTP; Fri, 8 Dec 2006 10:18:00 -0800 (PST)
X-Received: from mac.com (smtpin07-en2 [10.13.10.152])
by smtpout.mac.com (Xserve/8.12.11/smtpout14/MantshX 4.0) with ESMTP id kB8IHo7O009445;
Fri, 8 Dec 2006 10:17:50 -0800 (PST)
X-Received: from [10.68.15.8] ([12.0.44.46])
(authenticated bits=0)
by mac.com (Xserve/smtpin07/MantshX 4.0) with ESMTP id kB8IHk3n023369;
Fri, 8 Dec 2006 10:17:47 -0800 (PST)
In-Reply-To: <[email protected]>
References: <[email protected]> <[email protected]> <[email protected]> <[email protected]> <[email protected]> <[email protected]>
Mime-Version: 1.0 (Apple Message framework v752.2)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <[email protected]>
Cc: [email protected]
Content-Transfer-Encoding: 7bit
From: John Francini <[email protected]>
Subject: Re: Tommy Timesharing joins the Tops-20 365 Club!
Date: Fri, 8 Dec 2006 13:17:44 -0500
To: [email protected]
X-Mailer: Apple Mail (2.752.2)
X-Brightmail-Tracker: AAAAAA==
X-Brightmail-scanned: yes
ReSent-Date: Fri, 8 Dec 2006 10:36:53 -0800 (PST)
ReSent-From: TOPS-20 List Moderator <[email protected]>
ReSent-To: TOPS-20 Distribution: ;
ReSent-Subject: Re: Tommy Timesharing joins the Tops-20 365 Club!
ReSent-Message-ID: <[email protected]>

Okay, a wild-ass question here: How much work would it be to fix the
various users of the TODCLK value in the Monitor to use it as an
unsigned value?

j

On 7 Dec 2006, at 17:03, [email protected] wrote:

> Tommy Timesharing has just set an uptime record of over one year in
> continuous operation--that's 365/24/7 service without a reboot. The
> monitor was started on December 6th of 2005 (last year!) at 1:47:11 in
> the morning.
>
> This is obviously impressive given the performance of certain other
> 'modern' operating systems, but what makes it PARTICULARLY impressive
> is that this uptime record has occurred despite some very, VERY active
> software development on the Extended mode Tops-20 FTP server.
>
> Such first line software development under other 'modern' systems
> carries the great risk of system crashes and hangs. Oh yeah, the
> system also sends buckets of email. But it's still not the same as
> having 70 users signed on. :-(
>
> I celebrated by hacking together a small program to display when the
> UP2LNG BUGHLT will occur along with a help file. This is to help me
> set a shutdown time, which I prefer to the bug halt.
>
> Example:
> ========
>
> @TIMET2
> Tops-20 will crash with an UP2LNG BUGHLT on 7-Jan-2007 18:09:28
> (local time).
>
>
> Source Code
> ===========
>
> TITLE TIMET2 - Time to UP2LNG BUGHLT
> SUBTTL Thomas DeBellis, 12:25pm Thursday, 7 December 2006
>
> SEARCH MONSYM,MACSYM
> STDAC.
> .REQUIRE SYS:MACREL
>
> UTCDAY==<1,,0> ; UTC ticks in a day
> MS1DAY==<^D1000*^D60*^D60*^D24> ; Milliseconds in a full day
> PDLLEN==^D100
> DEFINE JERROR <ERCALS ERROR>
>
> DEFINE .FATAL (MESSAGE) <
> PASS2
> PRINTX ?'MESSAGE
> END
>> ;;DEFINE .FATAL
>
>
> DEFINE UCASTL (REG,ADDR) < ;;Cast an unsigned word to a signed long
>
> IFNB <ADDR>,<.FATAL 'ADDR Can only cast values in registers!>
> IFG REG-^O16,<.FATAL Register 'REG is out of bounds>
>
> MOVE REG+1,REG ;;Put unsigned single in low order
> TXZE REG+1,<1B0> ;;Does low order look negative?
> SKIPA REG,[1] ;;Yes, put the high order bit in the high
> SETZ REG, ;;Otherwise zero high order word
>> ;;UCASTL
>
>
> DEFINE LCASTU (REG,ADDR) < ;;Cast signed long to an unsigned word
>
> IFNB <ADDR>,<.FATAL 'ADDR Can only cast values in registers!>
> IFG REG-^O16,<.FATAL Register 'REG is out of bounds>
>
> CAXE REG,0 ;;Any high order?
> TXOA REG+1,<1B0> ;;Cast down to unsigned word
> TXZ REG+1,<1B0> ;;Otherwise scrub low order long to word
>> ;;UCASTL
>
>
> TIMET2: MOVE P,[IOWD PDLLEN,PDL] ;Set up stack
> RESET% ; House cleaning
> JERROR ; Didn't know it CAN fail ...
> TIME% ; Get milliseconds since boot
> JERROR ; Shouldn't ever fail either, but ...
> UCASTL T1, ; Cast unsigned word to signed long
> DMOVE P1,[EXP 0,.INFIN] ;Maximum MS allowed by APRSRV
> DSUB P1,T1 ; Calculate elapsed MS until UP2LNG
> CAXE P1,0 ; But more than 397 days, 16:22:18 ??
> CALL ERROR ; Must be a new APRSRV ...
>
> MOVE P3,P2 ; Load low order MS to UP2LNG
> MULX P3,UTCDAY ; Convert X ms to UTC * X ms
> DIVX P3,MS1DAY ; Strip off the milliseconds
> CAXL P4,MS1DAY/^D2 ; Are we over half a tick?
> ADDX P3,^D1 ; Add in a UTC tick
> UCASTL P3, ; Cast to long UTC ticks to UP2LNG
>
> GTAD% ; Get the current time of day
> JERROR ; Can't fail, but just in case ...
> CAMN T1,[-1] ; Is the system time set?
> CALL ERROR ; No! Don't say we know it.
> UCASTL T1, ; Cast unsigned UTC TOD to signed long
>
> DMOVE P5,T1 ; Load UTC TOD
> DADD P5,P3 ; Calculate time to UP2LNG
> CAXLE P5,^D1 ; UP2LNG is past 7-Aug-2576 19:59:59 EST?
> DMOVE P5,[EXP 1,.INFIN] ;Won't be winning for much longer ...
>
> DMOVE T1,P5 ; Load signed long UP2LNG TOD
> LCASTU T1, ; Cast to unsigned word
> CAMN T2,[-1] ; Is this ODTIM% magic NOW value?
> MOVX T2,.INFIN-1 ; Round down to highest unsigned TOD
>
> TMSG <Tops-20 will crash with an UP2LNG BUGHLT on >
> MOVX T1,.PRIOU
> SETZ T3, ; Default flags
> ODTIM% ; Finally!
> JERROR ; Or not ...
> TMSG < (local time).
>>
> HALTF% ; All done
> JRST TIMET2 ; But do it again (shouldn't change)
>
> ERROR: HRROI T1,[ASCIZ /Program error - /]
> ESOUT%
> ERJMPS .+1
> GETER%
> MOVE T2,T1
> MOVX T1,.PRIOU
> SETZ T3,
> ERSTR%
> ERJMPR .+2
> ERJMPR .+1
> HALTF%
> JRST TIMET2 ; Try it again
>
> PDL: BLOCK PDLLEN
>
> END 1,,TIMET2
>
> Help File
> =========
>
> TIMET2 tells you when the system is going to crash with an UP2LNG bug
> halt.
>
> Tops-20 maintains an elapsed count of milliseconds from the time it is
> booted. This counter is stored in TODCLK.
>
> Although the milliseconds from system boot counter itself is unsigned,
> various code in Tops-20 (such as in SCHED and APRSRV) treats it as a
> signed value, particularly via the use of signed arithmetic compare
> instructions (I.E., the CAI and CAM group).
>
> Once TODCLK increases from a 35 bit count into 36 bit count, its value
> will appear to be negative to these routines which will then produce
> (possibly wildly) inappropriate answers.
>
> Tops-20 prevents this by crashing with an UP2LNG bug halt when the
> wrap is detected. Thus, the maximum that Tops-20 can be up is
> 34,359,738,367 milliseonds or 397 days, 16 hours, 22 minutes and 18
> seconds.
>
> TIMET2 calculates the number of milliseconds to UP2LNG bug halt and
> adds this into the current date and time, producing the date and time
> when this bug halt will occur which is then displayed.
>
> It is suggested that an orderly system shutdown be scheduled (via the
> HSYS%) approximately ten to fifteen minutes before the value typed by
> TIMET2 in order to not risk file system corruption.
>
> Notes:
>
> 1) It makes no sense to repeatedly run or continue TIMET2 as the
> output will never change during any particular run of the
> operating system.
>
> 2) It is probably inappropriate to keep the current pre-UP2LNG
> shutdown value in a list of queued shutdowns.
>
> 3) Further information on UP2LNG can be gleaned from the UPDTCK
> routine in APRSRV.
>
>

8-Dec-2006 11:08:51-PST,4153;000000000000
Return-Path: <[email protected]>
Received: from pangtzu.panda.com ([206.124.149.117]) by lingling.panda.com with TCP/SMTP; Fri, 8 Dec 2006 11:05:01 -0800 (PST)
X-Return-Path: <[email protected]>
X-Received: from e2.ny.us.ibm.com ([32.97.182.142]) by lingling.panda.com with TCP/SMTP; Fri, 8 Dec 2006 10:57:11 -0800 (PST)
X-Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236])
by e2.ny.us.ibm.com (8.13.8/8.12.11) with ESMTP id kB8IuXsx002483;
Fri, 8 Dec 2006 13:56:33 -0500
X-Received: from d01av04.pok.ibm.com (d01av04.pok.ibm.com [9.56.224.64])
by d01relay04.pok.ibm.com (8.13.6/8.13.6/NCO v8.1.1) with ESMTP id kB8IuVB8195618;
Fri, 8 Dec 2006 13:56:33 -0500
X-Received: from d01av04.pok.ibm.com (loopback [127.0.0.1])
by d01av04.pok.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id kB8IuVp4021586;
Fri, 8 Dec 2006 13:56:31 -0500
X-Received: from taktmesser ([9.2.35.233])
by d01av04.pok.ibm.com (8.12.11.20060308/8.12.11) with SMTP id kB8IuUDO021574;
Fri, 8 Dec 2006 13:56:31 -0500
Message-ID: <[email protected]>
From: "David F. Bacon" <[email protected]>
To: "Mark Crispin" <[email protected]>, <[email protected]>
Cc: <[email protected]>
References: <[email protected]> <[email protected]> <[email protected]> <[email protected]> <[email protected]> <[email protected]> <[email protected]>
Subject: Re: Tommy Timesharing joins the Tops-20 365 Club!
Date: Fri, 8 Dec 2006 13:56:30 -0500
MIME-Version: 1.0
Content-Type: text/plain;
format=flowed;
charset="iso-8859-1";
reply-type=response
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.2869
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962
ReSent-Date: Fri, 8 Dec 2006 11:04:54 -0800 (PST)
ReSent-From: TOPS-20 List Moderator <[email protected]>
ReSent-To: TOPS-20 Distribution: ;
ReSent-Subject: Re: Tommy Timesharing joins the Tops-20 365 Club!
ReSent-Message-ID: <[email protected]>

I'm curious... how big (in terms of LOC and loaded binary image) is TOPS-20?
Or to put the question another way: is it able to stay up for a year because
the codebase is much smaller than Windows' 40 MLOC? or are there more
fundamental design issues involved, and if so, what are they?

david
----- Original Message -----
From: "Mark Crispin" <[email protected]>
To: <[email protected]>
Cc: <[email protected]>
Sent: Friday, December 08, 2006 1:08 PM
Subject: Re: Tommy Timesharing joins the Tops-20 365 Club!

> On Thu, 7 Dec 2006, [email protected] wrote:
>> Tommy Timesharing has just set an uptime record of over one year in
>> continuous operation--that's 365/24/7 service without a reboot. The
>> monitor was started on December 6th of 2005 (last year!) at 1:47:11 in
>> the morning.
>
> Congratulations. That beats Lingling's record; but then again one of the
> disadvantages of living on an island with lots of trees is that there
> isn't such a thing as reliable power. I forget how far Lingling got; it
> was in the 6000-7000 hour range.
>
> Lingling's current uptime is a mere 3145 hours (yup, even in August we
> have power outages). Since we're now in windstorm season I suspect it
> won't get much higher. If by some miracle the Puget Sound Energy gods
> spare Lingling, it won't be until September 1 at 02:02:09.
>
> XKL has hit UP2LNG, and I think that they extended the timers so that
> their monitor can run for longer.
>
> A Panda monitor running as a virtual machine under Windows (but that was
> hibernated onto disk most of the time, so it wasn't really "up") also hit
> UP2LNG, and I discovered that the DEC code for it was buggy -- instead of
> crashing, it wrapped! That's fixed in current Panda monitors.
>
> -- Mark --
>
> http://panda.com/tops-20
> TOPS-20: a great improvement over its successors
>
>

8-Dec-2006 11:14:44-PST,1833;000000000000
Return-Path: <[email protected]>
Received: from pangtzu.panda.com ([206.124.149.117]) by lingling.panda.com with TCP/SMTP; Fri, 8 Dec 2006 11:11:01 -0800 (PST)
X-Return-Path: <[email protected]>
X-Received: from pangtzu.panda.com ([206.124.149.117]) by lingling.panda.com with TCP/SMTP; Fri, 8 Dec 2006 11:10:32 -0800 (PST)
Date: Fri, 8 Dec 2006 11:10:27 -0800 (PST)
From: Mark Crispin <[email protected]>
Sender: [email protected]
To: John Francini <[email protected]>
cc: [email protected], [email protected]
Subject: Re: Tommy Timesharing joins the Tops-20 365 Club!
In-Reply-To: <[email protected]>
Message-ID: <[email protected]>
References: <[email protected]> <[email protected]>
<[email protected]> <[email protected]>
<[email protected]> <[email protected]>
<[email protected]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
ReSent-Date: Fri, 8 Dec 2006 11:10:53 -0800 (PST)
ReSent-From: TOPS-20 List Moderator <[email protected]>
ReSent-To: TOPS-20 Distribution: ;
ReSent-Subject: Re: Tommy Timesharing joins the Tops-20 365 Club!
ReSent-Message-ID: <[email protected]>

On Fri, 8 Dec 2006, John Francini wrote:
> Okay, a wild-ass question here: How much work would it be to fix the
> various users of the TODCLK value in the Monitor to use it as an
> unsigned value?

I wouldn't do that. It's a lot of work just to double the maximum uptime.

Better would be to make TODCLK be a doubleword.

-- Mark --

http://panda.com/tops-20
TOPS-20: a great improvement over its successors

8-Dec-2006 11:32:07-PST,3962;000000000000
Return-Path: <[email protected]>
Received: from pangtzu.panda.com ([206.124.149.117]) by lingling.panda.com with TCP/SMTP; Fri, 8 Dec 2006 11:27:39 -0800 (PST)
X-Return-Path: <[email protected]>
X-Received: from pangtzu.panda.com ([206.124.149.117]) by lingling.panda.com with TCP/SMTP; Fri, 8 Dec 2006 11:26:51 -0800 (PST)
Date: Fri, 8 Dec 2006 11:26:46 -0800 (PST)
From: Mark Crispin <[email protected]>
Sender: [email protected]
To: "David F. Bacon" <[email protected]>
cc: [email protected], [email protected]
Subject: Re: Tommy Timesharing joins the Tops-20 365 Club!
In-Reply-To: <[email protected]>
Message-ID: <[email protected]>
References: <[email protected]> <[email protected]>
<[email protected]> <[email protected]>
<[email protected]> <[email protected]>
<[email protected]>
<[email protected]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
ReSent-Date: Fri, 8 Dec 2006 11:27:32 -0800 (PST)
ReSent-From: TOPS-20 List Moderator <[email protected]>
ReSent-To: TOPS-20 Distribution: ;
ReSent-Subject: Re: Tommy Timesharing joins the Tops-20 365 Club!
ReSent-Message-ID: <[email protected]>

On Fri, 8 Dec 2006, David F. Bacon wrote:
> I'm curious... how big (in terms of LOC and loaded binary image) is TOPS-20?

The sources for the Panda monitor weigh in at 14,348,292 characters. A
vanilla DEC 7.0 monitor is smaller, since the Panda changes are all in
conditions (hence you can build vanilla DEC by turning off PANDASW).

The current MONITR.EXE is 643 pages, which is 329,216 36-bit words. Just
going by bits, that's a bit less than 1.5 MB.

However, this is just the kernel. As in all other modern operating
systems, the shell (EXEC) is a separate user program, plus there are the
various system utilities and daemons.

By the standards of the 1970s, TOPS-20 was massively huge. Today's UNIX
and Windows systems are much larger.

> Or to put the question another way: is it able to stay up for a year because
> the codebase is much smaller than Windows' 40 MLOC? or are there more
> fundamental design issues involved, and if so, what are they?

I don't think so. Uptime is directly impacted by the demands put on it.

I doubt very much that an heavily-loaded TOPS-20 timesharing system with
several dozen random user jobs would live long enough to reach UP2LNG.

At UW, we have numerous Linux servers which run without stopping from
deployment to their mandatory retirement 3 years later (we use commodity
hardware for our servers, and thus retire when the warranty expires).
Mind you, these are servers which are dedicated for a particular task and
do nothing other than that task.

The host Linux system that supports Lingling runs from CD-ROM, and it
rarely necessitates a reboot. It just runs, being a Linux that has little
else to do besides running klh10.

On the other hand, our Linux timesharing systems have much shorter
uptimes, on the order of months, not years.

Modern Windows is actually a very reliable operating system. The two
major reasons for a Windows reboot are software updates and device driver
issues. This happens a lot because it's a desktop/laptop system, and such
systems have a lot of things going on that don't happen on servers.

The same is the case on Mac (I know -- I have one as my desktop at home).
It gets rebooted less just because Apple does fewer software updates and
it supports far fewer devices than my Windows system (so I'm less likely
to use devices with it!).

-- Mark --

http://panda.com/tops-20
TOPS-20: a great improvement over its successors

8-Dec-2006 11:35:45-PST,2743;000000000000
Return-Path: <[email protected]>
Received: from pangtzu.panda.com ([206.124.149.117]) by lingling.panda.com with TCP/SMTP; Fri, 8 Dec 2006 11:27:54 -0800 (PST)
X-Return-Path: <[email protected]>
X-Received: from smtpout.mac.com ([17.250.248.171]) by lingling.panda.com with TCP/SMTP; Fri, 8 Dec 2006 11:22:24 -0800 (PST)
X-Received: from mac.com (smtpin07-en2 [10.13.10.152])
by smtpout.mac.com (Xserve/8.12.11/smtpout01/MantshX 4.0) with ESMTP id kB8JMIOY028621;
Fri, 8 Dec 2006 11:22:18 -0800 (PST)
X-Received: from [10.68.15.8] ([12.0.44.46])
(authenticated bits=0)
by mac.com (Xserve/smtpin07/MantshX 4.0) with ESMTP id kB8JMEhY021671;
Fri, 8 Dec 2006 11:22:16 -0800 (PST)
In-Reply-To: <[email protected]>
References: <[email protected]> <[email protected]> <[email protected]> <[email protected]> <[email protected]> <[email protected]> <[email protected]> <[email protected]>
Mime-Version: 1.0 (Apple Message framework v752.2)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <[email protected]>
Cc: [email protected], [email protected]
Content-Transfer-Encoding: 7bit
From: John Francini <[email protected]>
Subject: Re: Tommy Timesharing joins the Tops-20 365 Club!
Date: Fri, 8 Dec 2006 14:22:12 -0500
To: Mark Crispin <[email protected]>
X-Mailer: Apple Mail (2.752.2)
X-Brightmail-Tracker: AAAAAA==
X-Brightmail-scanned: yes
ReSent-Date: Fri, 8 Dec 2006 11:27:46 -0800 (PST)
ReSent-From: TOPS-20 List Moderator <[email protected]>
ReSent-To: TOPS-20 Distribution: ;
ReSent-Subject: Re: Tommy Timesharing joins the Tops-20 365 Club!
ReSent-Message-ID: <[email protected]>

yeah, that makes more sense. Why do all that for just double uptime
when you can go for 36! (factorial) more uptime!

Not having the source in front of me, how many places is TODCLK
referenced? And are there JSYI that would need to be changed so as
not to break user-mode code?

j
On 8 Dec 2006, at 14:10, Mark Crispin wrote:

> On Fri, 8 Dec 2006, John Francini wrote:
>> Okay, a wild-ass question here: How much work would it be to fix
>> the various users of the TODCLK value in the Monitor to use it as
>> an unsigned value?
>
> I wouldn't do that. It's a lot of work just to double the maximum
> uptime.
>
> Better would be to make TODCLK be a doubleword.
>
> -- Mark --
>
> http://panda.com/tops-20
> TOPS-20: a great improvement over its successors

8-Dec-2006 11:40:41-PST,1943;000000000000
Return-Path: <[email protected]>
Received: from pangtzu.panda.com ([206.124.149.117]) by lingling.panda.com with TCP/SMTP; Fri, 8 Dec 2006 11:36:55 -0800 (PST)
X-Return-Path: <[email protected]>
X-Received: from pangtzu.panda.com ([206.124.149.117]) by lingling.panda.com with TCP/SMTP; Fri, 8 Dec 2006 11:29:01 -0800 (PST)
Date: Fri, 8 Dec 2006 11:28:56 -0800 (PST)
From: Mark Crispin <[email protected]>
Sender: [email protected]
To: John Francini <[email protected]>
cc: [email protected], [email protected]
Subject: Re: Tommy Timesharing joins the Tops-20 365 Club!
In-Reply-To: <[email protected]>
Message-ID: <[email protected]>
References: <[email protected]> <[email protected]>
<[email protected]> <[email protected]>
<[email protected]> <[email protected]>
<[email protected]> <[email protected]>
<[email protected]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
ReSent-Date: Fri, 8 Dec 2006 11:36:43 -0800 (PST)
ReSent-From: TOPS-20 List Moderator <[email protected]>
ReSent-To: TOPS-20 Distribution: ;
ReSent-Subject: Re: Tommy Timesharing joins the Tops-20 365 Club!
ReSent-Message-ID: <[email protected]>

On Fri, 8 Dec 2006, John Francini wrote:
> Not having the source in front of me, how many places is TODCLK
> referenced? And are there JSYI that would need to be changed so as
> not to break user-mode code?

A quick count comes up with 406 references to TODCLK in the sources,
although some of these are undoubtably in comments.

-- Mark --

http://panda.com/tops-20
TOPS-20: a great improvement over its successors

8-Dec-2006 11:52:09-PST,1966;000000000000
Return-Path: <[email protected]>
Received: from pangtzu.panda.com ([206.124.149.117]) by lingling.panda.com with TCP/SMTP; Fri, 8 Dec 2006 11:48:10 -0800 (PST)
X-Return-Path: <[email protected]>
X-Received: from pangtzu.panda.com ([206.124.149.117]) by lingling.panda.com with TCP/SMTP; Fri, 8 Dec 2006 11:47:51 -0800 (PST)
Date: Fri, 8 Dec 2006 11:47:46 -0800 (PST)
From: Mark Crispin <[email protected]>
Sender: [email protected]
To: John Francini <[email protected]>
cc: [email protected], [email protected]
Subject: Re: Tommy Timesharing joins the Tops-20 365 Club!
In-Reply-To: <[email protected]>
Message-ID: <[email protected]>
References: <[email protected]> <[email protected]>
<[email protected]> <[email protected]>
<[email protected]> <[email protected]>
<[email protected]> <[email protected]>
<[email protected]>
<[email protected]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
ReSent-Date: Fri, 8 Dec 2006 11:48:02 -0800 (PST)
ReSent-From: TOPS-20 List Moderator <[email protected]>
ReSent-To: TOPS-20 Distribution: ;
ReSent-Subject: Re: Tommy Timesharing joins the Tops-20 365 Club!
ReSent-Message-ID: <[email protected]>

On Fri, 8 Dec 2006, Mark Crispin wrote:
> > And are there JSYI that would need to be changed so as
> > not to break user-mode code?

TIME% returns the TODCLK value, although in theory applications are
supposed to use the scale factor in AC2 rather than assuming that TODCLK
is in ms units.

-- Mark --

http://panda.com/tops-20
TOPS-20: a great improvement over its successors

8-Dec-2006 16:57:19-PST,2732;000000000000
Return-Path: <[email protected]>
Received: from pangtzu.panda.com ([206.124.149.117]) by lingling.panda.com with TCP/SMTP; Fri, 8 Dec 2006 16:53:11 -0800 (PST)
X-Return-Path: <[email protected]>
X-Received: from smtpout.mac.com ([17.250.248.182]) by lingling.panda.com with TCP/SMTP; Fri, 8 Dec 2006 12:39:11 -0800 (PST)
X-Received: from mac.com (smtpin07-en2 [10.13.10.152])
by smtpout.mac.com (Xserve/8.12.11/smtpout12/MantshX 4.0) with ESMTP id kB8Kd56a014186;
Fri, 8 Dec 2006 12:39:05 -0800 (PST)
X-Received: from [10.68.15.8] ([12.0.44.46])
(authenticated bits=0)
by mac.com (Xserve/smtpin07/MantshX 4.0) with ESMTP id kB8Kcnrj021708;
Fri, 8 Dec 2006 12:39:02 -0800 (PST)
In-Reply-To: <[email protected]>
References: <[email protected]> <[email protected]> <[email protected]> <[email protected]> <[email protected]> <[email protected]> <[email protected]> <[email protected]> <[email protected]> <[email protected]> <[email protected]>
Mime-Version: 1.0 (Apple Message framework v752.2)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <[email protected]>
Cc: [email protected]
Content-Transfer-Encoding: 7bit
From: John Francini <[email protected]>
Subject: Re: Tommy Timesharing joins the Tops-20 365 Club!
Date: Fri, 8 Dec 2006 15:38:47 -0500
To: TOPS-20 Hackers and Yackers <[email protected]>
X-Mailer: Apple Mail (2.752.2)
X-Brightmail-Tracker: AAAAAA==
X-Brightmail-scanned: yes
ReSent-Date: Fri, 8 Dec 2006 16:52:56 -0800 (PST)
ReSent-From: TOPS-20 List Moderator <[email protected]>
ReSent-To: TOPS-20 Distribution: ;
ReSent-Subject: Re: Tommy Timesharing joins the Tops-20 365 Club!
ReSent-Message-ID: <[email protected]>

Which would mean that the JSYS service code would need to somehow
'normalize' the TODCLK value to not break userland code, or the code
would need to change.

j

On 8 Dec 2006, at 14:47, Mark Crispin wrote:

> On Fri, 8 Dec 2006, Mark Crispin wrote:
>> > And are there JSYI that would need to be changed so as > not to
>> break user-mode code?
>
> TIME% returns the TODCLK value, although in theory applications are
> supposed to use the scale factor in AC2 rather than assuming that
> TODCLK is in ms units.
>
> -- Mark --
>
> http://panda.com/tops-20
> TOPS-20: a great improvement over its successors
>

8-Dec-2006 17:01:30-PST,1794;000000000000
Return-Path: <[email protected]>
Received: from pangtzu.panda.com ([206.124.149.117]) by lingling.panda.com with TCP/SMTP; Fri, 8 Dec 2006 16:53:34 -0800 (PST)
X-Return-Path: <[email protected]>
X-Received: from zipcon.net ([209.221.136.5]) by lingling.panda.com with TCP/SMTP; Fri, 8 Dec 2006 13:06:20 -0800 (PST)
X-Received: (qmail 16854 invoked by uid 4824); 8 Dec 2006 21:10:42 -0000
Message-ID: <[email protected]>
Date: 8 Dec 2006 13:10:42 -0800
From: kkt <[email protected]>
To: [email protected]
In-reply-to: <[email protected]> (message from John
Francini on Fri, 8 Dec 2006 14:22:12 -0500)
Subject: Re: Tommy Timesharing joins the Tops-20 365 Club!
References: <[email protected]> <[email protected]> <[email protected]> <[email protected]> <[email protected]> <[email protected]> <[email protected]> <[email protected]> <[email protected]>
ReSent-Date: Fri, 8 Dec 2006 16:53:25 -0800 (PST)
ReSent-From: TOPS-20 List Moderator <[email protected]>
ReSent-To: TOPS-20 Distribution: ;
ReSent-Subject: Re: Tommy Timesharing joins the Tops-20 365 Club!
ReSent-Message-ID: <[email protected]>

From: John Francini <[email protected]>
Date: Fri, 8 Dec 2006 14:22:12 -0500

yeah, that makes more sense. Why do all that for just double uptime
when you can go for 36! (factorial) more uptime!

36 factorial is a lot. Wouldn't it be 2^36 times more uptime?

(But if that were done, how would anyone be able to brag about getting
an UP2LNG?)

-- Patrick

8-Dec-2006 17:05:24-PST,3604;000000000000
Return-Path: <[email protected]>
Received: from pangtzu.panda.com ([206.124.149.117]) by lingling.panda.com with TCP/SMTP; Fri, 8 Dec 2006 16:53:57 -0800 (PST)
X-Return-Path: <[email protected]>
X-Received: from outbound4-dub-R.bigfish.com ([213.199.154.16]) by lingling.panda.com with TCP/SMTP; Fri, 8 Dec 2006 15:47:53 -0800 (PST)
X-Received: from outbound4-dub.bigfish.com (localhost.localdomain [127.0.0.1])
by outbound4-dub-R.bigfish.com (Postfix) with ESMTP id 41A50E619A3;
Fri, 8 Dec 2006 23:47:46 +0000 (UTC)
X-Received: from mail59-dub-R.bigfish.com (unknown [10.5.252.3])
by outbound4-dub.bigfish.com (Postfix) with ESMTP id 361751800085;
Fri, 8 Dec 2006 23:47:46 +0000 (UTC)
X-Received: from mail59-dub (localhost.localdomain [127.0.0.1])
by mail59-dub-R.bigfish.com (Postfix) with ESMTP id E29125583AF;
Fri, 8 Dec 2006 23:47:45 +0000 (UTC)
X-BigFish: VP
X-Received: by mail59-dub (MessageSwitch) id 1165621665752284_20827; Fri, 8 Dec 2006 23:47:45 +0000 (UCT)
X-Received: from amdext4.amd.com (amdext4.amd.com [163.181.251.6])
by mail59-dub.bigfish.com (Postfix) with ESMTP id 52142810072;
Fri, 8 Dec 2006 23:47:45 +0000 (UTC)
X-Received: from SAUSGW01.amd.com (sausgw01.amd.com [163.181.250.21])
by amdext4.amd.com (8.12.11/8.12.11/AMD) with ESMTP id kB8NlXxY013708;
Fri, 8 Dec 2006 17:47:44 -0600
X-Received: from 163.181.22.101 by SAUSGW02.amd.com with ESMTP (AMD SMTP
Relay (Email Firewall v6.1.0)); Fri, 08 Dec 2006 17:47:36 -0600
X-Server-Uuid: 5FC0E2DF-CD44-48CD-883A-0ED95B391E89
X-Received: from optimon.amd.com ([163.181.34.104]) by sausexbh1.amd.com
with Microsoft SMTPSVC(6.0.3790.2499); Fri, 8 Dec 2006 17:47:35 -0600
X-Received: from labuena.amd.com (labuena.amd.com [163.181.10.243]) by
optimon.amd.com (8.12.10/8.12.10) with ESMTP id kB8NlZZD001447; Fri, 8
Dec 2006 17:47:35 -0600
X-Received: from labuena.amd.com (localhost.localdomain [127.0.0.1]) by
labuena.amd.com (8.12.11.20060308/8.12.11) with ESMTP id
kB8NlZg7019993; Fri, 8 Dec 2006 17:47:35 -0600
X-Received: (from clive@localhost) by labuena.amd.com (
8.12.11.20060308/8.12.11/Submit) id kB8NlZSN019988; Fri, 8 Dec 2006
17:47:35 -0600
Date: Fri, 8 Dec 2006 17:47:35 -0600
Message-ID: <[email protected]>
From: "Clive Dawson" <[email protected]>
To: [email protected]
cc: [email protected], [email protected], [email protected]
In-Reply-To: <[email protected]> (
[email protected])
Subject: Re: Tommy Timesharing joins the Tops-20 365 Club!
X-Virus-Scanned: ClamAV version 0.87.1, clamav-milter version 0.87 on
optimon.amd.com
X-Virus-Status: Clean
X-OriginalArrivalTime: 08 Dec 2006 23:47:35.0946 (UTC)
FILETIME=[3CB21EA0:01C71B23]
MIME-Version: 1.0
X-WSS-ID: 696726122MC2272324-01-01
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
ReSent-Date: Fri, 8 Dec 2006 16:53:45 -0800 (PST)
ReSent-From: TOPS-20 List Moderator <[email protected]>
ReSent-To: TOPS-20 Distribution: ;
ReSent-Subject: Re: Tommy Timesharing joins the Tops-20 365 Club!
ReSent-Message-ID: <[email protected]>

>yeah, that makes more sense. Why do all that for just double uptime
>when you can go for 36! (factorial) more uptime!

Ummmm, that may be a wee bit overly ambitious! To multiply the uptime
by 36! would require the use of six 36-bit words. Using a double word
multiplies the uptime by 2^35 (each word has its own sign bit, IIRC),
which is what you probably intended to say.

Clive Dawson
AMD
Austin, TX

8-Dec-2006 17:23:36-PST,2611;000000000000
Return-Path: <[email protected]>
Received: from pangtzu.panda.com ([206.124.149.117]) by lingling.panda.com with TCP/SMTP; Fri, 8 Dec 2006 17:19:48 -0800 (PST)
X-Return-Path: <[email protected]>
X-Received: from pangtzu.panda.com ([206.124.149.117]) by lingling.panda.com with TCP/SMTP; Fri, 8 Dec 2006 17:15:24 -0800 (PST)
Date: Fri, 8 Dec 2006 17:15:17 -0800 (PST)
From: Mark Crispin <[email protected]>
Sender: [email protected]
To: John Francini <[email protected]>
cc: TOPS-20 Hackers and Yackers <[email protected]>,
[email protected]
Subject: Re: Tommy Timesharing joins the Tops-20 365 Club!
In-Reply-To: <[email protected]>
Message-ID: <[email protected]>
References: <[email protected]> <[email protected]>
<[email protected]> <[email protected]>
<[email protected]> <[email protected]>
<[email protected]> <[email protected]>
<[email protected]> <[email protected]>
<[email protected]>
<[email protected]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
ReSent-Date: Fri, 8 Dec 2006 17:19:39 -0800 (PST)
ReSent-From: TOPS-20 List Moderator <[email protected]>
ReSent-To: TOPS-20 Distribution: ;
ReSent-Subject: Re: Tommy Timesharing joins the Tops-20 365 Club!
ReSent-Message-ID: <[email protected]>

On Fri, 8 Dec 2006, John Francini wrote:
> Which would mean that the JSYS service code would need to somehow
> 'normalize' the TODCLK value to not break userland code, or the code
> would need to change.

No, not really. TIME% returns the uptime in AC1, and the number of uptime
units/second in AC2. In both Tenex and TOPS-20, the AC2 value is ^D1000,
thus AC1 is in miliseconds.

Supposedly, we could make TIME% return 1/10 second values (changing AC2 to
return ^D10) and thus prevent an UP2LNG bughlt for any system running for
less than 100 years. Internally, we'd use a double precision value in ms
for the stuff that needs that resolution.

But that would assume that application software actually pays attention to
the AC2 value instead of just assuming that the uptime is in ms.

-- Mark --

http://panda.com/tops-20
TOPS-20: a great improvement over its successors

8-Dec-2006 20:39:17-PST,3821;000000000000
Return-Path: <[email protected]>
Received: from pangtzu.panda.com ([206.124.149.117]) by lingling.panda.com with TCP/SMTP; Fri, 8 Dec 2006 20:34:52 -0800 (PST)
X-Return-Path: <[email protected]>
X-Received: from mail.math.utah.edu ([155.101.98.135]) by lingling.panda.com with TCP/SMTP; Fri, 8 Dec 2006 17:25:17 -0800 (PST)
X-Received: from psi.math.utah.edu (psi.math.utah.edu [155.101.96.19])
by mail.math.utah.edu (8.13.6/8.13.6) with ESMTP id kB91PBsa027283;
Fri, 8 Dec 2006 18:25:11 -0700 (MST)
X-Received: from psi.math.utah.edu (localhost [127.0.0.1])
by psi.math.utah.edu (8.13.6/8.13.6) with ESMTP id kB91PB64007723;
Fri, 8 Dec 2006 18:25:11 -0700 (MST)
X-Received: (from beebe@localhost)
by psi.math.utah.edu (8.13.6/8.13.6/Submit) id kB91PBfh007722;
Fri, 8 Dec 2006 18:25:11 -0700 (MST)
Date: Fri, 8 Dec 2006 18:25:11 -0700 (MST)
From: "Nelson H. F. Beebe" <[email protected]>
To: [email protected]
Cc: [email protected]
X-US-Mail: "Department of Mathematics, 110 LCB, University of Utah, 155 S
1400 E RM 233, Salt Lake City, UT 84112-0090, USA"
X-Telephone: +1 801 581 5254
X-FAX: +1 801 585 1640, +1 801 581 4148
X-URL: http://www.math.utah.edu/~beebe
Subject: Re: Tommy Timesharing joins the Tops-20 365 Club!
Message-ID: <[email protected]>
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0 (mail.math.utah.edu [155.101.98.135]); Fri, 08 Dec 2006 18:25:11 -0700 (MST)
ReSent-Date: Fri, 8 Dec 2006 20:34:39 -0800 (PST)
ReSent-From: TOPS-20 List Moderator <[email protected]>
ReSent-To: TOPS-20 Distribution: ;
ReSent-Subject: Re: Tommy Timesharing joins the Tops-20 365 Club!
ReSent-Message-ID: <[email protected]>

Congrats on hitting the UP2LNG limit on the Tommy Timesharing system.

A Web search for UP2LNG turned up this:

http://72.14.253.104/search?q=cache:PI9AfWULDlMJ:neil.franklin.ch/Usenet/alt.sys.pdp10/20010807_Historic_Event_UP2LNG_BUGHLT_on_Mathom_XKL_COM+UP2LNG&hl=en&gl=us&ct=clnk&cd=1&client=firefox-a

It claims the "very first ever recorded UP2LNG BUGHLT", posted on
7-Aug-2001.

That first posting unleashed almost three dozen responses:

http://groups.google.com/group/alt.sys.pdp10/index/browse_frm/month/2001-08?_done=%2Fgroup%2Falt.sys.pdp10%2Fbrowse_frm%2Fmonth%2F2001-08%3F&
Historic Event: UP2LNG BUGHLT on Mathom.XKL.COM!

There is a follow-on posting at

http://www.techiegroups.com/archive/index.php/t-52089.html

from 04-06-2004 (whatever that means) claiming the impending second
UP2LNG in history (posted by none other than our friend Mark Crispin).

I find it quite amusing that it could be considered an error for a
machine to be ``up too long'', and that the error caused the machine
to halt. Our own DECsystem 20/40 (science.utah.edu) and its 20/60
successor used to be taken down for care, feeding, and maintenance
every Tuesday morning for about four hours. I think in later years,
that interval might have been changed to monthly. We were blessed
with two outstanding DEC field engineers who for 12.5 years kept our
system available almost without interruption outside the scheduled
maintenance periods.

-------------------------------------------------------------------------------
- Nelson H. F. Beebe Tel: +1 801 581 5254 -
- University of Utah FAX: +1 801 581 4148 -
- Department of Mathematics, 110 LCB Internet e-mail: [email protected] -
- 155 S 1400 E RM 233 [email protected] [email protected] -
- Salt Lake City, UT 84112-0090, USA URL: http://www.math.utah.edu/~beebe/ -
-------------------------------------------------------------------------------

8-Dec-2006 20:42:55-PST,3521;000000000000
Return-Path: <[email protected]>
Received: from pangtzu.panda.com ([206.124.149.117]) by lingling.panda.com with TCP/SMTP; Fri, 8 Dec 2006 20:35:21 -0800 (PST)
X-Return-Path: <[email protected]>
X-Received: from newcheshire.xkl.com (clare.xkl.com [192.94.202.41]) by lingling.panda.com with TCP/SMTP; Fri, 8 Dec 2006 18:54:50 -0800 (PST)
X-Received: from tardis.xkl.com (tardis.xkl.com [10.1.0.29])
by newcheshire.xkl.com (8.13.3/8.13.3/SuSE Linux 0.7) with ESMTP id kB92oTQI023796;
Fri, 8 Dec 2006 18:50:31 -0800
X-Received: from tardis.xkl.com (tardis.xkl.com [10.1.0.29])
by tardis.xkl.com (8.13.3/8.13.3/SuSE Linux 0.7) with ESMTP id kB92rCRr015607;
Fri, 8 Dec 2006 18:53:14 -0800
Subject: Re: Tommy Timesharing joins the Tops-20 365 Club!
From: Ralph Gorin <[email protected]>
Reply-To: [email protected]
To: Mark Crispin <[email protected]>
Cc: John Francini <[email protected]>,
TOPS-20 Hackers and Yackers <[email protected]>,
[email protected]
In-Reply-To: <[email protected]>
References: <[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
<[email protected]> <[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
Content-Type: text/plain
Organization: XKL, LLC; Redmond, WA
Date: Fri, 08 Dec 2006 18:53:12 -0800
Message-Id: <[email protected]>
Mime-Version: 1.0
X-Mailer: Evolution 2.2.1
Content-Transfer-Encoding: 7bit
X-Spam-Status: No, hits=-2.5 required=5.0
tests=ALL_TRUSTED,AWL,BAYES_00,PHARM_GAP
version=3.0.4
X-Spam-Level:
X-Spam-Checker-Version: SpamAssassin 3.000004 (2005-06-05)
X-Scanned-By: MIMEDefang 2.57 on 10.5.0.1
ReSent-Date: Fri, 8 Dec 2006 20:35:13 -0800 (PST)
ReSent-From: TOPS-20 List Moderator <[email protected]>
ReSent-To: TOPS-20 Distribution: ;
ReSent-Subject: Re: Tommy Timesharing joins the Tops-20 365 Club!
ReSent-Message-ID: <[email protected]>

Folks,

It's a misfortune that the charming TIME JSYS is
documented as returning the constant ^D1000 in AC2.
There's no user code that I've seen that actually
performs the division.

There isn't any good way to move forward that
doesn't break existing user programs. Either
you tell them a lie or you halt them because
they've asked for a number that can't be
represented.

For what it's worth, we've hacked that JSYS to
return different formats if the user supplies
the "right" argument in the call. (This also
breaks the interface: formerly there was no
argument. But if you choose the
value carefully, it isn't likely a program
will get a recognized value by accident.)
In one case, TIME returns a double word
of milliseconds; in the other, it returns
the uptime in seconds in AC1 and the millisecond
remainder in AC2. If the argument isn't recognized and
the uptime exceeds the threshold, a JSYS error
ensues... Then you can work
on how to find all the programs that use TIME
and fix them. It was a merry chase.

Ralph

8-Dec-2006 20:46:56-PST,2731;000000000000
Return-Path: <[email protected]>
Received: from pangtzu.panda.com ([206.124.149.117]) by lingling.panda.com with TCP/SMTP; Fri, 8 Dec 2006 20:36:04 -0800 (PST)
X-Return-Path: <[email protected]>
X-Received: from mta1.srv.hcvlny.cv.net ([167.206.4.196]) by lingling.panda.com with TCP/SMTP; Fri, 8 Dec 2006 18:56:19 -0800 (PST)
X-Received: from optonline.net (hamstr3.srv.hcvlny.cv.net [167.206.5.10])
by mta1.srv.hcvlny.cv.net
(Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006))
with ESMTP id <[email protected]> for
[email protected]; Fri, 08 Dec 2006 21:56:13 -0500 (EST)
X-Received: from [10.240.3.200] (Forwarded-For: 66.114.69.214, [10.240.3.200])
by mstr3.srv.hcvlny.cv.net (mshttpd); Sat, 09 Dec 2006 02:56:12 +0000 (GMT)
Date: Sat, 09 Dec 2006 02:56:12 +0000 (GMT)
From: [email protected]
Subject: Re: Tommy Timesharing joins the Tops-20 365 Club!
In-reply-to: <optj9fgydb3n3e18@amd2>
To: Rick Ace <[email protected]>
Cc: [email protected]
Message-id: <[email protected]>
MIME-version: 1.0
X-Mailer: Sun Java(tm) System Messenger Express 6.2-6.01 (built Apr 3 2006)
Content-type: text/plain; charset=us-ascii
Content-language: en
Content-transfer-encoding: 7BIT
Content-disposition: inline
X-Accept-Language: en
Priority: normal
References: <optj9fgydb3n3e18@amd2>
ReSent-Date: Fri, 8 Dec 2006 20:35:41 -0800 (PST)
ReSent-From: TOPS-20 List Moderator <[email protected]>
ReSent-To: TOPS-20 Distribution: ;
ReSent-Subject: Re: Tommy Timesharing joins the Tops-20 365 Club!
ReSent-Message-ID: <[email protected]>

Thanks! But it wasn't a cut and paste, it was a copy to a TECO q register and then a copy back out of it (ha!)

More important was the bug that is already there... At the end, I check to make sure that I don't bump into the ODTIM% magic value and load T2 with .INFIN-1. This is wrong. The correct value is -2, thus:

LCASTU T1, ; Cast to unsigned word
CAMN T2,[-1] ; Is this ODTIM% magic NOW value?
SUBX T2,^D1 ; Round down to highest unsigned TOD

So, if I hit the magic value, I'd type 27-Sep-2217 19:59:59 EST instead of 7-Aug-2576 19:59:59, a 359 year error. Unsigned arithmatic. Bah Humbug !!!

----- Original Message -----
From: Rick Ace
Date: Friday, December 8, 2006 4:32 pm
Subject: Re: Tommy Timesharing joins the Tops-20 365 Club!
To: [email protected]

> Tom,
>
> Very impressive!
>
> BTW looks like you have a copy & paste error in TIMET2.MAC. The closing
> angle bracket for the definition of LCASTU bears the comment ;;UCASTL
>
> Rick
>

8-Dec-2006 21:56:53-PST,1550;000000000000
Return-Path: <[email protected]>
Received: from pangtzu.panda.com ([206.124.149.117]) by lingling.panda.com with TCP/SMTP; Fri, 8 Dec 2006 21:52:29 -0800 (PST)
X-Return-Path: <[email protected]>
X-Received: from pangtzu.panda.com ([206.124.149.117]) by lingling.panda.com with TCP/SMTP; Fri, 8 Dec 2006 21:39:03 -0800 (PST)
Date: Fri, 8 Dec 2006 21:38:58 -0800 (PST)
From: Mark Crispin <[email protected]>
Sender: [email protected]
To: "Nelson H. F. Beebe" <[email protected]>
cc: [email protected]
Subject: Re: Tommy Timesharing joins the Tops-20 365 Club!
In-Reply-To: <[email protected]>
Message-ID: <[email protected]>
References: <[email protected]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
ReSent-Date: Fri, 8 Dec 2006 21:52:20 -0800 (PST)
ReSent-From: TOPS-20 List Moderator <[email protected]>
ReSent-To: TOPS-20 Distribution: ;
ReSent-Subject: Re: Tommy Timesharing joins the Tops-20 365 Club!
ReSent-Message-ID: <[email protected]>

On Fri, 8 Dec 2006, Nelson H. F. Beebe wrote:
> I find it quite amusing that it could be considered an error for a
> machine to be ``up too long'', and that the error caused the machine
> to halt.

I wonder how most UNIX systems of today will do on January 19, 2038 at
03:14:08 UTC. ;-)

-- Mark --

http://panda.com/tops-20
TOPS-20: a great improvement over its successors

8-Dec-2006 22:00:45-PST,3568;000000000000
Return-Path: <[email protected]>
Received: from pangtzu.panda.com ([206.124.149.117]) by lingling.panda.com with TCP/SMTP; Fri, 8 Dec 2006 21:52:53 -0800 (PST)
X-Return-Path: <[email protected]>
X-Received: from pangtzu.panda.com ([206.124.149.117]) by lingling.panda.com with TCP/SMTP; Fri, 8 Dec 2006 21:52:07 -0800 (PST)
Date: Fri, 8 Dec 2006 21:52:02 -0800 (PST)
From: Mark Crispin <[email protected]>
Sender: [email protected]
To: Ralph Gorin <[email protected]>
cc: John Francini <[email protected]>,
TOPS-20 Hackers and Yackers <[email protected]>,
[email protected]
Subject: Re: Tommy Timesharing joins the Tops-20 365 Club!
In-Reply-To: <[email protected]>
Message-ID: <[email protected]>
References: <[email protected]> <[email protected]>
<[email protected]> <[email protected]>
<[email protected]> <[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
ReSent-Date: Fri, 8 Dec 2006 21:52:45 -0800 (PST)
ReSent-From: TOPS-20 List Moderator <[email protected]>
ReSent-To: TOPS-20 Distribution: ;
ReSent-Subject: Re: Tommy Timesharing joins the Tops-20 365 Club!
ReSent-Message-ID: <[email protected]>

On Fri, 8 Dec 2006, Ralph Gorin wrote:
> It's a misfortune that the charming TIME JSYS is
> documented as returning the constant ^D1000 in AC2.

For what it's worth, the Tenex JSYS manual says no such thing; instead, it
says:

RETURNS +1: with time right justified in 1,
divisor to convert to seconds in 2

It was clear from the design that it was intended that this could change.
I actually expected on Tenex for AC2 to contain ^D60 and ^D50, as I though
that the KA10 only had a line-frequency clock. However, Tenex sources
definitely have ^D1000, so perhaps there was a better clock (maybe part of
the BBN pager?).

Sadly, the TOPS-20 JSYS manual says the following:

RETURNS +1: always, with time (in milliseconds) right-justified
in AC1, and divisor to convert the time to seconds in
AC2. AC2 always contains 1000; thus, it is not
necessary to examine its contents.

Sigh...

> There's no user code that I've seen that actually
> performs the division.

I was afraid that you were going to say that.

> There isn't any good way to move forward that
> doesn't break existing user programs. Either
> you tell them a lie or you halt them because
> they've asked for a number that can't be
> represented.

Well, doing the latter would definitely be the "DEC way" of doing things;
remember STDIR and CNDIR? I've actually thought of reimplementing both
jsi in the Panda monitor, doing the Tenex action (thus PS-only).

> Then you can work
> on how to find all the programs that use TIME
> and fix them. It was a merry chase.

I can imagine!

-- Mark --

http://panda.com/tops-20
TOPS-20: a great improvement over its successors

9-Dec-2006 09:15:22-PST,3076;000000000000
Return-Path: <[email protected]>
Received: from pangtzu.panda.com ([206.124.149.117]) by lingling.panda.com with TCP/SMTP; Sat, 9 Dec 2006 09:11:05 -0800 (PST)
X-Return-Path: <[email protected]>
X-Received: from mta5.srv.hcvlny.cv.net ([167.206.4.200]) by lingling.panda.com with TCP/SMTP; Sat, 9 Dec 2006 08:07:51 -0800 (PST)
X-Received: from theta (ool-18b9d8b2.dyn.optonline.net [24.185.216.178])
by mta5.srv.hcvlny.cv.net
(Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006))
with ESMTP id <[email protected]> for
[email protected]; Sat, 09 Dec 2006 11:07:45 -0500 (EST)
Date: Sat, 09 Dec 2006 11:07:44 -0500
From: Rick Ace <[email protected]>
Subject: UP2LNG
In-reply-to: <[email protected]>
To: [email protected]
Message-id: <[email protected]>
MIME-version: 1.0
X-Mailer: Evolution 2.2.2 (2.2.2-5)
Content-type: text/plain
Content-transfer-encoding: 7BIT
References: <[email protected]>
<[email protected]>
ReSent-Date: Sat, 9 Dec 2006 09:10:57 -0800 (PST)
ReSent-From: TOPS-20 List Moderator <[email protected]>
ReSent-To: TOPS-20 Distribution: ;
ReSent-Subject: UP2LNG
ReSent-Message-ID: <[email protected]>

On Fri, 2006-12-08 at 21:38 -0800, Mark Crispin wrote:
> On Fri, 8 Dec 2006, Nelson H. F. Beebe wrote:
> > I find it quite amusing that it could be considered an error for a
> > machine to be ``up too long'', and that the error caused the machine
> > to halt.

As I recall, BUGHLT means

"Our internal safety apparatus just observed that something happened
that we didn't expect, and our professional opinion is that letting you
continue to use your DEC-20 in its current state is highly likely to be
detrimental to your business. We are therefore making an immediate
executive decision on your behalf to remove the risk and restore your
computing environment to an uncompromised state. Yes, it's a major
inconvenience, and yes, it's our fault; please send us a dump and we'll
work to make ensure it doesn't trouble you again."

So, the only errors in evidence are the failure to accommodate an
extended period of uptime, and the misnaming of the BUGHLT. A more
accurate name would have been something like CLKOVF (clock overflow).
In lieu of the "right" implementation, peppering the CTY with BUGINFs or
BUGCHKs during the week or two preceding the anticipated overflow would
have been a thoughtfully conceived feature too.

> I wonder how most UNIX systems of today will do on January 19, 2038 at
> 03:14:08 UTC. ;-)

Most UNIX systems of today will be history thirty years from now. The
vendors of those that survive will have upgraded the system software and
language tools long in advance to defuse the well-known UNIX analogue of
the Y2K bug. Folks running legacy apps will probably stand the greatest
risk. Think of it as thinning the herd a bit :-)

rick

9-Dec-2006 09:46:37-PST,1893;000000000000
Return-Path: <[email protected]>
Received: from pangtzu.panda.com ([206.124.149.117]) by lingling.panda.com with TCP/SMTP; Sat, 9 Dec 2006 09:42:29 -0800 (PST)
X-Return-Path: <[email protected]>
X-Received: from pangtzu.panda.com ([206.124.149.117]) by lingling.panda.com with TCP/SMTP; Sat, 9 Dec 2006 09:30:36 -0800 (PST)
Date: Sat, 9 Dec 2006 09:30:31 -0800 (PST)
From: Mark Crispin <[email protected]>
Sender: [email protected]
To: TOPS-20 Hackers and Yackers <[email protected]>
Subject: ironic thing about UP2LNG...
Message-ID: <[email protected]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
ReSent-Date: Sat, 9 Dec 2006 09:42:23 -0800 (PST)
ReSent-From: TOPS-20 List Moderator <[email protected]>
ReSent-To: TOPS-20 Distribution: ;
ReSent-Subject: ironic thing about UP2LNG...
ReSent-Message-ID: <[email protected]>

..is that, as I noted in 2004, the BUGHLT couldn't actually happen on a
vanilla DEC TOPS-20 system.

The DEC code does
RDTIME T1
DIV T1,BASDIV
and expects that T1 will go negative. However, once the value of T1 from
the RDTIME doubleword reaches the value of BASDIV, the DIV will set
overflow and no-divide and leave T1 unchanged. Since T1 is subsequently
stored in TODCLK, that sets uptime back to shortly after boot time.

I doubt that any KL actually ran for over a year without a reboot. This
was probably a gedanken exercise. If anyone knows the current whereabouts
of Mike Raspuzzi we could ask him.

XKL and Panda both fixed this. XKL does an extra step which is probably
related to their facility to allow longer uptimes; Panda just implements
the UP2LNG crash as was intended.

-- Mark --

http://panda.com/tops-20
TOPS-20: a great improvement over its successors

10-Dec-2006 09:52:32-PST,929;000000000000
Return-Path: <[email protected]>
Received: from pangtzu.panda.com ([206.124.149.117]) by lingling.panda.com with TCP/SMTP; Sun, 10 Dec 2006 09:47:39 -0800 (PST)
Mail-From: MRC created at 10-Dec-2006 09:43:08
Date: Sun, 10 Dec 2006 09:43:08 -0800 (PST)
From: Mark Crispin <[email protected]>
Subject: sad news
To: [email protected]
Pithy-Thought: TOPS-20 was a great improvement over its successors
Message-ID: <[email protected]>
ReSent-Date: Sun, 10 Dec 2006 09:47:14 -0800 (PST)
ReSent-From: TOPS-20 List Moderator <[email protected]>
ReSent-To: TOPS-20 Distribution: ;
ReSent-Subject: sad news
ReSent-Message-ID: <[email protected]>

I just learned that Greg Scott passed away about 3 months ago. Greg was one
of the TOPS-20 release 7 developers, and thus was there when the lights were
turned off for the last time.
-------

10-Dec-2006 23:38:46-PST,1599;000000000000
Return-Path: <[email protected]>
Received: from pangtzu.panda.com ([206.124.149.117]) by lingling.panda.com with TCP/SMTP; Sun, 10 Dec 2006 23:33:57 -0800 (PST)
X-Return-Path: <[email protected]>
X-Received: from a.mail.sonic.net ([64.142.16.245]) by lingling.panda.com with TCP/SMTP; Sun, 10 Dec 2006 20:09:15 -0800 (PST)
X-Received: from Amiga.local (64-142-29-114.dsl.static.sonic.net [64.142.29.114])
by a.mail.sonic.net (8.13.8.Beta0-Sonic/8.13.7) with ESMTP id kBB496RG027331;
Sun, 10 Dec 2006 20:09:06 -0800
Date: Sun, 10 Dec 2006 20:09:06 -0800 (PST)
From: Fred Wright <[email protected]>
X-Sender: [email protected]
Reply-To: Fred Wright <[email protected]>
To: Mark Crispin <[email protected]>
cc: [email protected]
Subject: Re: sad news
In-Reply-To: <[email protected]>
Message-ID: <[email protected]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
ReSent-Date: Sun, 10 Dec 2006 23:33:46 -0800 (PST)
ReSent-From: TOPS-20 List Moderator <[email protected]>
ReSent-To: TOPS-20 Distribution: ;
ReSent-Subject: Re: sad news
ReSent-Message-ID: <[email protected]>

On Sun, 10 Dec 2006, Mark Crispin wrote:

> I just learned that Greg Scott passed away about 3 months ago. Greg was one
> of the TOPS-20 release 7 developers, and thus was there when the lights were
> turned off for the last time.

That's too bad. I knew Greg before he worked for DEC, back when he worked
for one of the service bureaus (I forget which).

Fred Wright

10-Dec-2006 23:44:12-PST,3465;000000000000
Return-Path: <[email protected]>
Received: from pangtzu.panda.com ([206.124.149.117]) by lingling.panda.com with TCP/SMTP; Sun, 10 Dec 2006 23:40:10 -0800 (PST)
X-Return-Path: <[email protected]>
X-Received: from pangtzu.panda.com ([206.124.149.117]) by lingling.panda.com with TCP/SMTP; Sun, 10 Dec 2006 23:35:22 -0800 (PST)
X-Return-Path: <[email protected]>
X-Received: from mta4.srv.hcvlny.cv.net ([167.206.4.199]) by lingling.panda.com with TCP/SMTP; Sun, 10 Dec 2006 20:45:39 -0800 (PST)
X-Received: from optonline.net (hamstr3.srv.hcvlny.cv.net [167.206.5.10])
by mta4.srv.hcvlny.cv.net
(Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006))
with ESMTP id <[email protected]> for
[email protected]; Sun, 10 Dec 2006 23:45:18 -0500 (EST)
X-Received: from [10.240.3.196] (Forwarded-For: 66.114.69.214, [10.240.3.196])
by mstr3.srv.hcvlny.cv.net (mshttpd); Mon, 11 Dec 2006 04:45:18 +0000 (GMT)
Date: Mon, 11 Dec 2006 04:45:18 +0000 (GMT)
From: [email protected]
Subject: Re: sad news
In-reply-to: <[email protected]>
To: Mark Crispin <[email protected]>
Message-id: <[email protected]>
MIME-version: 1.0
X-Mailer: Sun Java(tm) System Messenger Express 6.2-6.01 (built Apr 3 2006)
Content-type: text/plain; charset=us-ascii
Content-language: en
Content-transfer-encoding: 7BIT
Content-disposition: inline
X-Accept-Language: en
Priority: normal
References: <[email protected]>
X-ReSent-Date: Sun, 10 Dec 2006 23:35:14 -0800 (PST)
X-ReSent-From: Mark Crispin <[email protected]>
X-ReSent-To: TOPS-20 Hackers and Yackers <[email protected]>
X-ReSent-Subject: Re: sad news
X-ReSent-Message-ID: <[email protected]>
ReSent-Date: Sun, 10 Dec 2006 23:40:02 -0800 (PST)
ReSent-From: TOPS-20 List Moderator <[email protected]>
ReSent-To: TOPS-20 Distribution: ;
ReSent-Subject: Re: sad news
ReSent-Message-ID: <[email protected]>

If memory serves correctly, this is more than 'just' the loss of great Tops-20 hacker.

Greg was about two or three years ahead of me at WPI and had one of the very few, very coveted Systems Programming jobs at WACCC and a local (1200 baud!!!) terminal. He also did a lot of operator work, decolating and the like.

Operators at WPI were a tough bunch. Not BOFH, but a click that did not suffer even a wiff of foolishness gladly.

Not Greg. He had one of the highest student positions there and could have lorded it all over us all. He didn't. He was one of the most genuinely kind and patient people I ever came across. I ran into a few problems with a couple of programs that I wrote and I remember him taking the time to sort some things out for me, something he need never have done for a freshman.

In that way, he was an inspiration to me at Columbia to take the power that I had and to be beyond reproach and as diplomatic as possible.

When the world loses a kind understanding man, we all lose. This is a sad day indeed.

----- Original Message -----
From: Mark Crispin
Date: Sunday, December 10, 2006 1:03 pm
Subject: sad news
To: [email protected]

> I just learned that Greg Scott passed away about 3 months ago. Greg was one
> of the TOPS-20 release 7 developers, and thus was there when the lights were
> turned off for the last time.

11-Dec-2006 22:58:59-PST,5009;000000000000
Return-Path: <[email protected]>
Received: from pangtzu.panda.com ([206.124.149.117]) by Lingling.Panda.COM with TCP/SMTP; Mon, 11 Dec 2006 22:55:08 -0800 (PST)
X-Return-Path: <[email protected]>
X-Received: from a.mail.sonic.net ([64.142.16.245]) by lingling.panda.com with TCP/SMTP; Mon, 11 Dec 2006 16:00:53 -0800 (PST)
X-Received: from Amiga.local (64-142-29-114.dsl.static.sonic.net [64.142.29.114])
by a.mail.sonic.net (8.13.8.Beta0-Sonic/8.13.7) with ESMTP id kBC00lKc020109
for <[email protected]>; Mon, 11 Dec 2006 16:00:47 -0800
Date: Mon, 11 Dec 2006 16:00:47 -0800 (PST)
From: Fred Wright <[email protected]>
X-Sender: [email protected]
Reply-To: Fred Wright <[email protected]>
To: TOPS-20 Hackers and Yackers <[email protected]>
Subject: Re: Tommy Timesharing joins the Tops-20 365 Club!
In-Reply-To: <[email protected]>
Message-ID: <[email protected]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
ReSent-Date: Mon, 11 Dec 2006 22:55:00 -0800 (PST)
ReSent-From: TOPS-20 List Moderator <[email protected]>
ReSent-To: TOPS-20 Distribution: ;
ReSent-Subject: Re: Tommy Timesharing joins the Tops-20 365 Club!
ReSent-Message-ID: <[email protected]>

On Fri, 8 Dec 2006, Mark Crispin wrote:
> On Fri, 8 Dec 2006, John Francini wrote:
> > Okay, a wild-ass question here: How much work would it be to fix the
> > various users of the TODCLK value in the Monitor to use it as an
> > unsigned value?
>
> I wouldn't do that. It's a lot of work just to double the maximum uptime.

Indeed.

> Better would be to make TODCLK be a doubleword.

Which could get into lots of difficulties expanding one word to two,
whether it's a register, a field in a structure (some of which are known
to user programs), or an array (which would then need a doubled index).

On Fri, 8 Dec 2006, Mark Crispin wrote:
> On Fri, 8 Dec 2006, David F. Bacon wrote:
> > I'm curious... how big (in terms of LOC and loaded binary image) is TOPS-20?
>
> The sources for the Panda monitor weigh in at 14,348,292 characters. A
> vanilla DEC 7.0 monitor is smaller, since the Panda changes are all in
> conditions (hence you can build vanilla DEC by turning off PANDASW).
>
> The current MONITR.EXE is 643 pages, which is 329,216 36-bit words. Just
> going by bits, that's a bit less than 1.5 MB.

Running wc on the unmodified DEC sources (7.0TSU04, monitor only) gives:

355825 1830730 12367520 total

On Fri, 8 Dec 2006, Mark Crispin wrote:

> On Fri, 8 Dec 2006, John Francini wrote:
> > Which would mean that the JSYS service code would need to somehow
> > 'normalize' the TODCLK value to not break userland code, or the code
> > would need to change.
>
> No, not really. TIME% returns the uptime in AC1, and the number of uptime
> units/second in AC2. In both Tenex and TOPS-20, the AC2 value is ^D1000,
> thus AC1 is in miliseconds.
>
> Supposedly, we could make TIME% return 1/10 second values (changing AC2 to
> return ^D10) and thus prevent an UP2LNG bughlt for any system running for
> less than 100 years. Internally, we'd use a double precision value in ms
> for the stuff that needs that resolution.

Millisecond resolution is already severely marginal on modern
systems. Aside from the compatibility issues, further degrading the
resolution is undesirable.

The best solution to the problem is to recognize that the time value is
neither signed nor unsigned, but modular. This is similar to the way TCP
gets by with 32-bit sequence numbers without imposing a 4GiB limit on the
length of a transfer. It's also the approach that's already used in some
places in TOPS-20 that use the 10-microsecond flavor of time (with a
period of about 76 hours).

Implementing that would require lots of code changes, but no more than any
other approach, and meanwhile would gain an infinite range without
expanding to a doubleword.

On Fri, 8 Dec 2006, Mark Crispin wrote:
> On Fri, 8 Dec 2006, Ralph Gorin wrote:
> > It's a misfortune that the charming TIME JSYS is
> > documented as returning the constant ^D1000 in AC2.
>
> For what it's worth, the Tenex JSYS manual says no such thing; instead, it
> says:
>
> RETURNS +1: with time right justified in 1,
> divisor to convert to seconds in 2
>
> It was clear from the design that it was intended that this could change.
> I actually expected on Tenex for AC2 to contain ^D60 and ^D50, as I though
> that the KA10 only had a line-frequency clock. However, Tenex sources
> definitely have ^D1000, so perhaps there was a better clock (maybe part of
> the BBN pager?).

AFAIK there was no clock in the BBN pager, though perhaps the DK-10 was
available in the KA-10 era. But it wouldn't have been the only time a
timer was designed for future expansion to finer granularity.

Fred Wright

11-Dec-2006 23:02:29-PST,3135;000000000000
Return-Path: <[email protected]>
Received: from pangtzu.panda.com ([206.124.149.117]) by Lingling.Panda.COM with TCP/SMTP; Mon, 11 Dec 2006 22:56:24 -0800 (PST)
X-Return-Path: <[email protected]>
X-Received: from b.mail.sonic.net ([64.142.19.5]) by Lingling.Panda.COM with TCP/SMTP; Mon, 11 Dec 2006 22:40:38 -0800 (PST)
X-Received: from Amiga.local (64-142-29-114.dsl.static.sonic.net [64.142.29.114])
by b.mail.sonic.net (8.13.8.Beta0-Sonic/8.13.7) with ESMTP id kBC6eXrd032209
for <[email protected]>; Mon, 11 Dec 2006 22:40:33 -0800
Date: Mon, 11 Dec 2006 22:40:32 -0800 (PST)
From: Fred Wright <[email protected]>
X-Sender: [email protected]
Reply-To: Fred Wright <[email protected]>
To: TOPS-20 Hackers and Yackers <[email protected]>
Subject: Re: ironic thing about UP2LNG...
In-Reply-To: <[email protected]>
Message-ID: <[email protected]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
ReSent-Date: Mon, 11 Dec 2006 22:56:16 -0800 (PST)
ReSent-From: TOPS-20 List Moderator <[email protected]>
ReSent-To: TOPS-20 Distribution: ;
ReSent-Subject: Re: ironic thing about UP2LNG...
ReSent-Message-ID: <[email protected]>

On Sat, 9 Dec 2006, Mark Crispin wrote:

> ...is that, as I noted in 2004, the BUGHLT couldn't actually happen on a
> vanilla DEC TOPS-20 system.
>
> The DEC code does
> RDTIME T1
> DIV T1,BASDIV
> and expects that T1 will go negative. However, once the value of T1 from
> the RDTIME doubleword reaches the value of BASDIV, the DIV will set
> overflow and no-divide and leave T1 unchanged. Since T1 is subsequently
> stored in TODCLK, that sets uptime back to shortly after boot time.

There's another possible bug in the above code, depending on where the
routine is called from. There's a KL microcode bug having to do with
RDTIME addressing a pair of ACs when running in a nonzero section. It may
be limited to non-0/1 sections, since I think the bug is that AC+1 gets
misinterpreted as a memory location due to bogus globality. The
workaround for it is to do "RDTIME @[T1]" instead, which forces section 0
addressing for the ACs.

> I doubt that any KL actually ran for over a year without a reboot. This
> was probably a gedanken exercise. If anyone knows the current whereabouts
> of Mike Raspuzzi we could ask him.

I suspect that the UP2LNG code may have been originally written for a
pre-KL system where TODCLK was computed incrementally, and hence the
overflow would have been observable.

> XKL and Panda both fixed this. XKL does an extra step which is probably
> related to their facility to allow longer uptimes; Panda just implements
> the UP2LNG crash as was intended.

Merely comparing the timebase to BASDIV *before* the DIV would work
fine. But in reality, the UP2LNG should be triggered earlier anyway, to
insure that computed *future* times for normally expected delays can't
overflow. For the "early warning" test, checking the quotient is fine.

Fred Wright

11-Dec-2006 23:22:14-PST,2689;000000000000
Return-Path: <[email protected]>
Received: from pangtzu.panda.com ([206.124.149.117]) by Lingling.Panda.COM with TCP/SMTP; Mon, 11 Dec 2006 23:18:34 -0800 (PST)
X-Return-Path: <[email protected]>
X-Received: from pangtzu.panda.com ([206.124.149.117]) by Lingling.Panda.COM with TCP/SMTP; Mon, 11 Dec 2006 23:13:14 -0800 (PST)
Date: Mon, 11 Dec 2006 23:13:10 -0800 (PST)
From: Mark Crispin <[email protected]>
Sender: [email protected]
To: Fred Wright <[email protected]>
cc: TOPS-20 Hackers and Yackers <[email protected]>
Subject: Re: Tommy Timesharing joins the Tops-20 365 Club!
In-Reply-To: <[email protected]>
Message-ID: <[email protected]>
References: <[email protected]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
ReSent-Date: Mon, 11 Dec 2006 23:18:27 -0800 (PST)
ReSent-From: TOPS-20 List Moderator <[email protected]>
ReSent-To: TOPS-20 Distribution: ;
ReSent-Subject: Re: Tommy Timesharing joins the Tops-20 365 Club!
ReSent-Message-ID: <[email protected]>

On Mon, 11 Dec 2006, Fred Wright wrote:
> > Supposedly, we could make TIME% return 1/10 second values (changing AC2 to
> > return ^D10) and thus prevent an UP2LNG bughlt for any system running for
> > less than 100 years. Internally, we'd use a double precision value in ms
> > for the stuff that needs that resolution.
> Millisecond resolution is already severely marginal on modern
> systems. Aside from the compatibility issues, further degrading the
> resolution is undesirable.

However, I suspect that most things that uses the TIME% JSYS immediately
divides it by ^D1000 (sadly, not by AC2) to get seconds.

GTAD% JSYS time is in 1/(2^18) day units, which comes to about 1/3 second.

When I was doing stuff with the KL performance meters, I put the fork into
user I/O mode and did RDPERF/RDTIME calls directly. Although the
calculations were in RDTIME units, I rounded them to ms units.

Although klh10 doesn't have RDPERF, I would still use user I/O and RDTIME
rather than any JSYS if I cared about measuring time more accurately.
However, then you run into a different issue, which is that on some host
processors (especially VMware) time can run backwards! To avoid freaking
out TOPS-20, klh10 detects this and slows down time until the host
processor catches back up.

So real-time applications aren't going to work too well on klh10 anyway...

-- Mark --

http://panda.com/tops-20
TOPS-20: a great improvement over its successors

11-Dec-2006 23:25:51-PST,1418;000000000000
Return-Path: <[email protected]>
Received: from pangtzu.panda.com ([206.124.149.117]) by Lingling.Panda.COM with TCP/SMTP; Mon, 11 Dec 2006 23:18:48 -0800 (PST)
X-Return-Path: <[email protected]>
X-Received: from pangtzu.panda.com ([206.124.149.117]) by Lingling.Panda.COM with TCP/SMTP; Mon, 11 Dec 2006 22:59:29 -0800 (PST)
Date: Mon, 11 Dec 2006 22:59:24 -0800 (PST)
From: Mark Crispin <[email protected]>
Sender: [email protected]
To: TOPS-20 Hackers and Yackers <[email protected]>
Subject: speaking of power outages
Message-ID: <[email protected]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
ReSent-Date: Mon, 11 Dec 2006 23:18:41 -0800 (PST)
ReSent-From: TOPS-20 List Moderator <[email protected]>
ReSent-To: TOPS-20 Distribution: ;
ReSent-Subject: speaking of power outages
ReSent-Message-ID: <[email protected]>

Lingling (and the rest of the panda.com zoo) got whacked by a 2 hour power
outage Monday afternoon. A short one as these things go, and undoubtable
the first of several this winter. Of course, it happened while I was at
work in Seattle, so it was several hours before it all came back up.

I'll never have to worry about an UP2LNG... :-(

-- Mark --

http://panda.com/tops-20
TOPS-20: a great improvement over its successors

11-Dec-2006 23:29:25-PST,2571;000000000000
Return-Path: <[email protected]>
Received: from pangtzu.panda.com ([206.124.149.117]) by Lingling.Panda.COM with TCP/SMTP; Mon, 11 Dec 2006 23:19:03 -0800 (PST)
X-Return-Path: <[email protected]>
X-Received: from pangtzu.panda.com ([206.124.149.117]) by Lingling.Panda.COM with TCP/SMTP; Mon, 11 Dec 2006 23:18:21 -0800 (PST)
Date: Mon, 11 Dec 2006 23:18:16 -0800 (PST)
From: Mark Crispin <[email protected]>
Sender: [email protected]
To: Fred Wright <[email protected]>
cc: TOPS-20 Hackers and Yackers <[email protected]>
Subject: Re: ironic thing about UP2LNG...
In-Reply-To: <[email protected]>
Message-ID: <[email protected]>
References: <[email protected]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
ReSent-Date: Mon, 11 Dec 2006 23:18:56 -0800 (PST)
ReSent-From: TOPS-20 List Moderator <[email protected]>
ReSent-To: TOPS-20 Distribution: ;
ReSent-Subject: Re: ironic thing about UP2LNG...
ReSent-Message-ID: <[email protected]>

On Mon, 11 Dec 2006, Fred Wright wrote:
> > I doubt that any KL actually ran for over a year without a reboot. This
> > was probably a gedanken exercise. If anyone knows the current whereabouts
> > of Mike Raspuzzi we could ask him.
> I suspect that the UP2LNG code may have been originally written for a
> pre-KL system where TODCLK was computed incrementally, and hence the
> overflow would have been observable.

Nope, Mike Raspuzzi added the UP2LNG bughlt in the final days of DEC
TOPS-20 (February 16, 1989) based upon some tests that he and Greg Scott
did.

> > XKL and Panda both fixed this. XKL does an extra step which is probably
> > related to their facility to allow longer uptimes; Panda just implements
> > the UP2LNG crash as was intended.
> Merely comparing the timebase to BASDIV *before* the DIV would work
> fine.

Yup, that's the fix.

> But in reality, the UP2LNG should be triggered earlier anyway, to
> insure that computed *future* times for normally expected delays can't
> overflow. For the "early warning" test, checking the quotient is fine.

In the one test that I did, there weren't too many problems. I think
there was a FLKTIM or two. The really bizarre behavior happened after the
overflow (since due to the bug the crash didn't happen).

-- Mark --

http://panda.com/tops-20
TOPS-20: a great improvement over its successors

12-Dec-2006 09:19:21-PST,4496;000000000000
Return-Path: <[email protected]>
Received: from pangtzu.panda.com ([206.124.149.117]) by Lingling.Panda.COM with TCP/SMTP; Tue, 12 Dec 2006 09:15:34 -0800 (PST)
X-Return-Path: <[email protected]>
X-Received: from pop-scotia.atl.sa.earthlink.net ([207.69.195.65]) by Lingling.Panda.COM with TCP/SMTP; Tue, 12 Dec 2006 01:05:15 -0800 (PST)
X-Received: from cpe-24-221-177-162.ca.sprintbbd.net ([24.221.177.162] helo=[204.238.239.104])
by pop-scotia.atl.sa.earthlink.net with esmtp (Exim 3.36 #1)
id 1Gu3ZV-0006GR-00
for [email protected]; Tue, 12 Dec 2006 04:05:09 -0500
Mime-Version: 1.0 (Apple Message framework v624)
In-Reply-To: <[email protected]>
References: <[email protected]> <[email protected]> <[email protected]> <[email protected]> <[email protected]> <[email protected]>
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <[email protected]>
Content-Transfer-Encoding: 7bit
X-Image-Url: http://www.goldenstategiftbaskets.com/minibasket.jpg
From: Carl Baltrunas <[email protected]>
Subject: Re: Tommy Timesharing joins the Tops-20 365 Club!
Date: Tue, 12 Dec 2006 01:05:07 -0800
To: TOPS-20 Hackers and Yackers <[email protected]>
X-Mailer: Apple Mail (2.624)
ReSent-Date: Tue, 12 Dec 2006 09:15:26 -0800 (PST)
ReSent-From: TOPS-20 List Moderator <[email protected]>
ReSent-To: TOPS-20 Distribution: ;
ReSent-Subject: Re: Tommy Timesharing joins the Tops-20 365 Club!
ReSent-Message-ID: <[email protected]>

All this talk about the 365 club now has me curious. (I'm replying to
the
first message, instead of using a snippet from any particular response).

When I first brought the XKL Toad home and set it up in my garage, I
did do several reboots when reconfiguring the networks, and several
others due to the infrequent power outages we have here in CA. I ran
it continuously from Feb 1999 till we experienced the fallout from the
rolling power outages in CA due to the power mismanagement and
the price of electricity began to skyrocket. I would not doubt that at
one
time, it did run for more than 365 days, but I didn't know it was such a
big deal, so didn't record it.

Next time I bring up the system (oops! Drat! I was supposed to do
that on Dec 10th, in honor of DEC 10 day, being a Tops-10 Wizard
in a previous life. Maybe I'll get a chance before DEC 20th?) I will
have to look at the logs and the attempted emails which were to be
sent on reboots, to see if we do indeed have a span of 365 days or
more. I'll let you know.

Ralph, or anyone familiar with the XKL monitor, know what they did
as far as the UP2LNG bughalt? I don't recall seeing that one, but
you never know. It's possible that was why I had to reboot it. However
since I had it set to auto-reboot, it is possible it went down and came
back up without me knowing about it.

It has been an interesting dialog on the state of TOPS-20, its uptime
and that of these unix upstarts. Anyone care to venture a guess at
how much of the TOPS-10, WAITS, TYMCOM-X, TENEX, TOPS-20,
or ITS kernel algorithms are still kicking around in another form in
one of the popular UNIX or LINUX systems?

Give me an ANF-10 network anyday.
Never liked that DECnet upstart.

-Carl

On Dec 7, 2006, at 2:03 PM, [email protected] wrote:
> Tommy Timesharing has just set an uptime record of over one year in
> continuous operation--that's 365/24/7 service without a reboot. The
> monitor was started on December 6th of 2005 (last year!) at 1:47:11 in
> the morning.
>
> This is obviously impressive given the performance of certain other
> 'modern' operating systems, but what makes it PARTICULARLY impressive
> is that this uptime record has occurred despite some very, VERY active
> software development on the Extended mode Tops-20 FTP server.
>
> Such first line software development under other 'modern' systems
> carries the great risk of system crashes and hangs. Oh yeah, the
> system also sends buckets of email. But it's still not the same as
> having 70 users signed on. :-(
>
> I celebrated by hacking together a small program to display when the
> UP2LNG BUGHLT will occur along with a help file. This is to help me
> set a shutdown time, which I prefer to the bug halt.
>

12-Dec-2006 16:35:42-PST,1834;000000000000
Return-Path: <[email protected]>
Received: from pangtzu.panda.com ([206.124.149.117]) by Lingling.Panda.COM with TCP/SMTP; Tue, 12 Dec 2006 16:31:37 -0800 (PST)
X-Return-Path: <[email protected]>
X-Received: from ics.com (mx.ics.com [209.59.5.4]) by Lingling.Panda.COM with TCP/SMTP; Tue, 12 Dec 2006 14:37:56 -0800 (PST)
X-Received: from ultimate.com (c-66-30-204-193.hsd1.ma.comcast.net [66.30.204.193])
by ics.com (8.12.9p1/8.12.9) with SMTP id kBCMbmhT029868
for <[email protected]>; Tue, 12 Dec 2006 17:37:49 -0500 (EST)
(envelope-from [email protected])
X-Received: (from phil@localhost)
by ultimate.com (8.13.6/8.13.6) id kBCMbkG6007675;
Tue, 12 Dec 2006 17:37:46 -0500 (EST)
Date: Tue, 12 Dec 2006 17:37:46 -0500 (EST)
From: Phil Budne <[email protected]>
Message-Id: <[email protected]>
To: [email protected]
Subject: SDS930 rescued
ReSent-Date: Tue, 12 Dec 2006 16:31:30 -0800 (PST)
ReSent-From: TOPS-20 List Moderator <[email protected]>
ReSent-To: TOPS-20 Distribution: ;
ReSent-Subject: SDS930 rescued
ReSent-Message-ID: <[email protected]>

The Berkeley T/S system was born on a modified version of the SDS 930
(marketed as the SDS 940), and was supposed to have influenced the
design of TENEX;

Dig the red aligator clip "jumper" on the backplane!

In article <19F49A6EFCA3D849A4C1C46C3566EBF2010A1C00@ALA-MAIL03.corp.ad.wrs.com>,
"Courtney, Lee" <[email protected]> writes:

> The Computer History Museum recently acquired a SDS 910, 920, and
> accepted donation of a SDS 930 (940 predecessor) from History San Jose.
> See pics at
> http://www.flickr.com/photos/lee_courtney/sets/72157594391790915/ and
> http://www.flickr.com/photos/lee_courtney/sets/72157594391722530/.

12-Dec-2006 19:42:31-PST,2279;000000000000
Return-Path: <[email protected]>
Received: from pangtzu.panda.com ([206.124.149.117]) by Lingling.Panda.COM with TCP/SMTP; Tue, 12 Dec 2006 19:38:27 -0800 (PST)
X-Return-Path: <[email protected]>
X-Received: from rwcrmhc12.comcast.net ([204.127.192.82]) by Lingling.Panda.COM with TCP/SMTP; Tue, 12 Dec 2006 18:54:22 -0800 (PST)
X-Received: from [10.0.1.2] (c-24-91-193-59.hsd1.ma.comcast.net[24.91.193.59])
by comcast.net (rwcrmhc12) with ESMTP
id <20061213025414m1200squq4e>; Wed, 13 Dec 2006 02:54:15 +0000
Mime-Version: 1.0
Message-Id: <p06230902c1a51b92b267@[10.0.1.2]>
In-Reply-To: <[email protected]>
References: <[email protected]>
Date: Tue, 12 Dec 2006 21:54:01 -0500
To: Phil Budne <[email protected]>, [email protected]
From: Paul Wexelblat <[email protected]>
Subject: Re: SDS930 rescued
Content-Type: text/plain; charset="us-ascii"
ReSent-Date: Tue, 12 Dec 2006 19:38:03 -0800 (PST)
ReSent-From: TOPS-20 List Moderator <[email protected]>
ReSent-To: TOPS-20 Distribution: ;
ReSent-Subject: Re: SDS930 rescued
ReSent-Message-ID: <[email protected]>

At 5:37 PM -0500 12/12/06, Phil Budne wrote:
>The Berkeley T/S system was born on a modified version of the SDS 930
>(marketed as the SDS 940), and was supposed to have influenced the
>design of TENEX;

My memory may be shaky here, but I think BBN got the SDS 940 (later XDS 940) when the Sigma 7 they had on order kept being delayed. The OS development for that system did, indeed contribute to the OS that was done for the DEC PDP-10 that became TENEX ( the "TEN" in "TENEX" was from the PDP -"10").

>
>Dig the red aligator clip "jumper" on the backplane!
>
>In article <19F49A6EFCA3D849A4C1C46C3566EBF2010A1C00@ALA-MAIL03.corp.ad.wrs.com>,
> "Courtney, Lee" <[email protected]> writes:
>
>> The Computer History Museum recently acquired a SDS 910, 920, and
>> accepted donation of a SDS 930 (940 predecessor) from History San Jose.
>> See pics at
>> http://www.flickr.com/photos/lee_courtney/sets/72157594391790915/ and
>> http://www.flickr.com/photos/lee_courtney/sets/72157594391722530/.

--
--
...wex

13-Dec-2006 12:36:41-PST,9744;000000000000
Return-Path: <[email protected]>
Received: from pangtzu.panda.com ([206.124.149.117]) by Lingling.Panda.COM with TCP/SMTP; Wed, 13 Dec 2006 12:33:10 -0800 (PST)
X-Return-Path: <[email protected]>
X-Received: from mta5.srv.hcvlny.cv.net ([167.206.4.200]) by lingling.panda.com with TCP/SMTP; Wed, 13 Dec 2006 02:39:38 -0800 (PST)
X-Received: from optonline.net (hamstr3.srv.hcvlny.cv.net [167.206.5.10])
by mta5.srv.hcvlny.cv.net
(Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006))
with ESMTP id <[email protected]> for
[email protected]; Wed, 13 Dec 2006 05:39:32 -0500 (EST)
X-Received: from [10.240.3.214] (Forwarded-For: 66.114.69.214, [10.240.3.214])
by mstr3.srv.hcvlny.cv.net (mshttpd); Wed, 13 Dec 2006 10:39:31 +0000 (GMT)
Date: Wed, 13 Dec 2006 10:39:31 +0000 (GMT)
From: [email protected]
Subject: Re: Tommy Timesharing joins the Tops-20 365 Club!
In-reply-to: <[email protected]>
To: "David F. Bacon" <[email protected]>
Cc: [email protected]
Message-id: <[email protected]>
MIME-version: 1.0
X-Mailer: Sun Java(tm) System Messenger Express 6.2-6.01 (built Apr 3 2006)
Content-type: text/plain; charset=us-ascii
Content-language: en
Content-transfer-encoding: 7BIT
Content-disposition: inline
X-Accept-Language: en
Priority: normal
References: <[email protected]>
<[email protected]> <[email protected]>
<[email protected]> <[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
ReSent-Date: Wed, 13 Dec 2006 12:33:04 -0800 (PST)
ReSent-From: TOPS-20 List Moderator <[email protected]>
ReSent-To: TOPS-20 Distribution: ;
ReSent-Subject: Re: Tommy Timesharing joins the Tops-20 365 Club!
ReSent-Message-ID: <[email protected]>

dfb,

I've been mulling over your message for a few days and I thought I'd
share what I've found and what I know. For myself, I find it
difficult to make a straightforward comparison between Tops-20 and
Windows in this regard for a number of reasons.

The missions of these two beasts are different.

For example, Windows Workstation might be considered to be at least a
single user multi-processor workstation with a profoundly rich set of
graphics and multi-media primitives, many, many device drivers and
networking. Yes, I know that this is a gross oversimplication.

Tops-20 was designed as a multiple user character mode timesharing
system that eventually grew to provide clustering, extensive
networking and modern process and memory management control, operating
in a data center.

It had the beginnings of graphics, but that plug was pulled before
this went anywhere. However, I am fairly certain I saw something like
a local Tops-20 SUPDUP server (not a Tops-20 to ITS SUPDUP client)
that was put together on MIT-EECS while I was being interviewed by CPR
for FdC.

Also, the meaning of "operating system" has become increasingly
blurred over the years, particularly during and after the Microsoft
anti-trust case. At least from 1977 to 1988 when I was formally
studying computer science at WPI and Columbia, the operating systems
texts and courses really only dwelled on 2/3 of the resident
'kernal'--that is the process and memory management. One wonders
whether this might have been the case because this is where the most
theoretical (and hence teachable) material is.

The other 1/3 of the kernal would be the file system. This is pretty
messy stuff that historically almost nobody taught, let alone talked
about. Indeed, I'm only aware of one textbook that discusses it in
any detail at all: Zolk and Polleck (sp?) wonderful "File Structures".
Joy's (?) 4.2 file system design and Murphy's CFS paper are also
notable departures. The published code for the various Linux
installable file systems are of great interest in this regard.

Networking used to be seperate, but let's include that. My PANDA
Tops-20 sources weigh in at 401,758 lines of assembler. I think the
total memory foot print might perhaps be in the neighborhood of 600
odd pages, but MRC would have better info on that. But you can't
really do anything without a shell (EXEC), so thats another 52,938
lines.

The in-memory foot print of the EXEC is about 195 pages or something
short of 100K. To Tops-10 hackers of the day (particularly those from
WPI who had rewritten just about every DEC cusp there was to save
memory), this was an incomprehensible amount of memory. Indeed, when
I first came to Marlboro, this caused me to utter one of the more
remarkably stupid things that I've ever said: "Gee, a seperate per-
process SCNSER? That's a terrible idea. Can you imagine what would
happen if somebody PUSHed up a couple of 50K EXECs? The system would
run out of memory".

In the machine room. Next to 2102. Right across the hall from
Tops-20 development. .... Sigh ...

You can get a whole lot of real work done with these two, but
increasingly, Tops-20 really wanted to have Galaxy around--a number of
things won't be happy (or even work) without it. Actually, that's not
quite true, you can run a Galaxy-less system, but you'd really want to
have a bona fide Galaxy hero (like me!) around to do so. But Why?

So Galaxy is another 160,778 lines of code. However, I am sure that
this number would have been much higher at Columbia due to all the
additional functionality that we had (to print everything everywhere,
for example). GLXLIB, Quasar, ORION, MOUNTR, NEBULA, OPR, LPTSPL,
BATCON, the list goes on; my ballpark is that's an easy 470 memory
pages there. We're up to 615,474 (over half a million lines) of
assembler.

All of this memory usage in the latest '70's and early 1980's was
nearly incomprehensible. Don't even ask about the Extended mode FTP
server. I would have gotten lynched. Now it's incomprehensibly
small. As a matter of fact, a legitimate case could probably be made
for Tops-20 being re-targeted as an embedded operating system ...

But how to compare the two? A fair bit of the low level Windows
drivers (like the clock driver) are in a assembly. But a lot isn't
and Windows was ported to different architectures with lots of
different devices. Tops-20 was only 'ported' from a (modified) KA to
a KI and then to a KL--these machines have essentially the same ISA.
The number of different devices that Tops-20 can support is miniscule
compared to Windows.

So what about Windows' 40 MLOC? That's over 60 times the 'necessary'
Tops-20 sources. What's in there? The window manager? NTFS? ODBC?
Networking? Multi-media? Buckets of device drivers? Where does the
line stop? How to compare the high language windows to the Tops-20
bit bangery?

Tops-20 is probably proof against a lot of attacks because of the
restricted device set and because it got pounded on for a lot of
years. However, every beta-test that we did sent the reliability
right back down. I don't have any more smart college students (like
CCK and friends) intelligently poking around. They would surely have
bumped into the IPGCOL issue that I discovered over a year ago and had
much fun clobbering the network (that is until TC or MK clobbered
them).

Somewhat in contrast to what MRC says, even in the 1980's, Tops-20
would stand up to a lot of usage by a 'small' group of people. One
summer while porting our monitor, Exec and Galaxy changes to version
6, I cracked over 400 minutes of CPU time in one week. Keng was
pretty impressed with this. We did this on CU20C and stayed up over a
month and a half until Warren (the FE) yelled at us to do a PM. I
think the rest of you user services people were over on CU20D which is
where we did our actual monitor testing.

So yes, I'm doing a lot of hacking and getting attacked a good amount
(over 200 script-kiddie penetration attempts in past four days), but
things only get unstable when you really, REALLY crank up the load and
users. My load rarely crosses 4 ... How to get back to the 1980's?
Well, one thing you can do is kick off a bunch of simultaneous batch
jobs.

When I first got Tommy Timesharing, I did some load testing by
assembling GLXLIB and then doing a simultaneous assembly of Quasar,
OPR, ORION, LPTSPL, BATCON, MOUNTR and the rest of the Galaxy clan
while also doing a full system backup.

Tommy Timesharing nearly ground to a complete halt. The load cleared
40. I started getting boatloads of FLKTIM and other bug thingies on
the CTY. The CFS code started complaining about losing shared devices
and then the file service code started reporting file errors. Sound
familiar? It was just like the good old days on CU20A (before the
memory upgrade)!

By then however, I had gotten cold feet, torpedoed everything,
rebooted and had done a CHKDSK. Didn't have to worry about 70 PACX
users trying to jump back on, either ...

----- Original Message -----
From: "David F. Bacon"
Date: Friday, December 8, 2006 1:56 pm
Subject: Re: Tommy Timesharing joins the Tops-20 365 Club!
To: Mark Crispin , [email protected]
Cc: [email protected]

> I'm curious... how big (in terms of LOC and loaded binary image) is
> TOPS-20? Or to put the question another way: is it able to stay up
> for a year because the codebase is much smaller than Windows' 40
> MLOC? or are there more fundamental design issues involved, and if
> so, what are they?
>
> david

13-Dec-2006 12:40:16-PST,9191;000000000000
Return-Path: <[email protected]>
Received: from pangtzu.panda.com ([206.124.149.117]) by Lingling.Panda.COM with TCP/SMTP; Wed, 13 Dec 2006 12:34:08 -0800 (PST)
X-Return-Path: <[email protected]>
X-Received: from mta4.srv.hcvlny.cv.net ([167.206.4.199]) by lingling.panda.com with TCP/SMTP; Wed, 13 Dec 2006 02:44:13 -0800 (PST)
X-Received: from optonline.net (hamstr3.srv.hcvlny.cv.net [167.206.5.10])
by mta4.srv.hcvlny.cv.net
(Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006))
with ESMTP id <[email protected]> for
[email protected]; Wed, 13 Dec 2006 05:44:07 -0500 (EST)
X-Received: from [10.240.3.214] (Forwarded-For: 66.114.69.214, [10.240.3.214])
by mstr3.srv.hcvlny.cv.net (mshttpd); Wed, 13 Dec 2006 10:44:07 +0000 (GMT)
Date: Wed, 13 Dec 2006 10:44:07 +0000 (GMT)
From: [email protected]
Subject: Re: Tommy Timesharing joins the Tops-20 365 Club!
In-reply-to: <[email protected]>
To: John Francini <[email protected]>
Cc: [email protected]
Message-id: <[email protected]>
MIME-version: 1.0
X-Mailer: Sun Java(tm) System Messenger Express 6.2-6.01 (built Apr 3 2006)
Content-type: text/plain; charset=us-ascii
Content-language: en
Content-transfer-encoding: 7BIT
Content-disposition: inline
X-Accept-Language: en
Priority: normal
References: <[email protected]>
<[email protected]> <[email protected]>
<[email protected]> <[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
ReSent-Date: Wed, 13 Dec 2006 12:34:02 -0800 (PST)
ReSent-From: TOPS-20 List Moderator <[email protected]>
ReSent-To: TOPS-20 Distribution: ;
ReSent-Subject: Re: Tommy Timesharing joins the Tops-20 365 Club!
ReSent-Message-ID: <[email protected]>

> > On Fri, 8 Dec 2006, John Francini wrote:
> >
> > Okay, a wild-ass question here: How much work would it be to fix
> > the various users of the TODCLK value in the Monitor to use it as
> > an unsigned value?

> On Fri, 8 Dec 2006, MRC responded
>
> I wouldn't do that. It's a lot of work just to double the
> maximum uptime.
>
> Better would be to make TODCLK be a doubleword.

I strongly agree with MRC for two reasons:

First, if you change the maximum uptime of Tops-20 from a 35 bit value
to a 36 bit value, you go from about a year and a month to something
like two years, two months and change. For the amount of effort that
it would take, I'd rather not have to worry about uptime wrap at all.
That argues for a double word value.

At BIG BANK, where BIG BLUE BIG IRON machines were all known and
loved, I used to hear an awful lot from operations about how various
390 LPARs had been going for over three years. Those uptimes
FREQUENTLY got compared to Digital Unix's.

Second, part of the effort needed to handle unsigned elapsed times
would probably involve having the working values being manipulated as
signed longs.

One of the small beefs that I have with the PDP-10 instruction set
architecture (ISA) is that you can't do an unsigned compare quite as
easily as you can in other ISAs. For example, take the following
80x86 assembly (PLEASE!):

CMP EAX,SVALUE ; Compare accumulator to signed value
JG GREATER ; Jump if accumulator was larger

CMP EAX,UVALUE ; Compare accumulator to unsigned value
JA GREATER ; Jump if accumulator was larger

If you want an unsigned compare, you just change the jump on
condition. It is noted that CMP is exactly the same as a SUB, but the
resulting value is thrown away.

It's difficult to do something analogous on the PDP-10, although you
could actually do a SUB and then do some flavor of a JFCL to get
(roughly?) the same sort of behavior.

I have to do a bunch of unsigned arithmatic in the extended mode FTP
server (not just to handle the unsigned UTC values) and I finally gave
up on using JFCL. I should clarify here that I don't mean that using
JFCL is intrinsically hard, just that I didn't have the patience to
use it.

I coded up a bunch of double compare macros which would skip like the
single word CAMx group. While these macros themselves (see below)
eliminated the JFCL learning curve (or mind block in my case), they
aren't skipable themselves.

It seems to me that if you are going to go to all that trouble of
handling unsigned values and are handling them internally as signed
longs, then you might as well go the extra yard and store the working
values and redo the rest of the code to handle them.

Then I could go tell BIG BLUE heros to shut up.

But I don't know if Unix has an uptime restriction nor what that is.
It doesn't matter, they need to shut up, too.

OS/2 1.x kept a 32 bit millisecond uptime count in the global
information segment. This wrapped after 7 weeks, 17 hours, 2 minutes,
47 seconds and 295 milliseconds (I wrote a small assembler program to
break out and display the various pieces). But nothing happened when
it wrapped.

Windows 2000 (and NT but not XP) also implements the 16 bit OS/2
global information segment and the value wraps here, also. I don't
know if anything intrinsically forces Windows down. Thus far, I
haven't had a long enough run of the operating system to bump into it,
yet.

SUBTTL Signed double word compares (non-skippable)

DEFINE UCASTL (REG,ADDR) < ;;Cast an unsigned word to a signed long

IFNB <ADDR>,<.FATAL 'ADDR Can only cast values in registers!>
IFG REG-^O16,<.FATAL Register 'REG is out of bounds>

MOVE REG+1,REG ;;Put unsigned single in low order
TXZE REG+1,<1B0> ;;Does low order look negative?
SKIPA REG,[1] ;;Yes, put the high order bit in the high
SETZ REG, ;;Otherwise zero high order word
>;;UCASTL

DEFINE LCASTU (REG,ADDR) < ;;Cast signed long to an unsigned word

IFNB <ADDR>,<.FATAL 'ADDR Can only cast values in registers!>
IFG REG-^O16,<.FATAL Register 'REG is out of bounds>

CAXE REG,0 ;;Any high order?
TXOA REG+1,<1B0> ;;Cast down to unsigned word
TXZ REG+1,<1B0> ;;Otherwise scrub low order long to word
>;;LCASTU

DEFINE DCAME (R,A,%N) < ;;Double compare and skip if equal

IFB <A>,<.FATAL Not comparing to anything!>
IFG R-^O16,<.FATAL Register 'R is out of bounds>

CAME R,A ;;Compare high order
JRST %N ;; Not equal, don't skip
CAME R+1,A+1 ;;Compare low order
%N:! ;;Non-skip return
.XCREF %N ;;Useless in CREF
>;;DCAME

DEFINE DCAMN (R,A,%N,%S) < ;;Double compare and skip if NOT equal

IFB <A>,<.FATAL Not comparing to anything!>
IFG R-^O16,<.FATAL Register 'R is out of bounds>

CAME R,A ;;Compare high order
JRST %S ;; Not equal--skip
CAMN R+1,A+1 ;;Compare low order
%N:! ;;Non-skip return
%S==%N+1 ;;Skip return
.XCREF %N,%S ;;Useless in CREF
>;;DCAMN

DEFINE DCAML (R,A,%N,%S,%L) < ;;Double compare and skip if less

IFB <A>,<.FATAL Not comparing to anything!>
IFG R-^O16,<.FATAL Register 'R is out of bounds>

CAMN R,A ;;Compare high order
JRST %L ;; Equal, check low order
CAML R,A ;;Compare high order, skip if less
JRST %N ;;Not less, non-skip
JRST %S ;;Less, skip
%L:! CAML R+1,A+1 ;;Compare low order
%N:! ;;Not less, Non-skip return
%S==%N+1 ;;Less, Skip return
.XCREF %L,%N,%S ;;Useless in CREF
>;;DCAML

DEFINE DCAMLE (R,A,%N,%S,%L) < ;;Double compare and skip if less or equal

IFB <A>,<.FATAL Not comparing to anything!>
IFG R-^O16,<.FATAL Register 'R is out of bounds>

CAMN R,A ;;Compare high order
JRST %L ;; Equal, check low order
CAML R,A ;;Compare high order, skip if less
JRST %N ;;Not less, non-skip
JRST %S ;;Less, skip
%L:! CAMLE R+1,A+1 ;;Compare low order
%N:! ;;Not less, Non-skip return
%S==%N+1 ;;Less or equal, Skip return
.XCREF %L,%N,%S ;;Useless in CREF
>;;DCAMLE

DEFINE DCAMG (R,A,%N,%S,%L) < ;;Double compare and skip if greater

IFB <A>,<.FATAL Not comparing to anything!>
IFG R-^O16,<.FATAL Register 'R is out of bounds>

CAMN R,A ;;Compare high order
JRST %L ;; Equal, check low order
CAMG R,A ;;Compare high order, skip if greater
JRST %N ;;Not greater, non-skip
JRST %S ;;Greater, skip
%L:! CAMG R+1,A+1 ;;Compare low order, skip if greater
%N:! ;;Not greater, Non-skip return
%S==%N+1 ;;Greater, Skip return
.XCREF %L,%N,%S ;;Useless in CREF
>;;DCAMG

DEFINE DCAMGE (R,A,%N,%S,%L) < ;;Double compare and skip if greater or equal

IFB <A>,<.FATAL Not comparing to anything!>
IFG R-^O16,<.FATAL Register 'R is out of bounds>

CAMN R,A ;;Compare high order
JRST %L ;; Equal, check low order
CAMG R,A ;;Compare high order, skip if greater
JRST %N ;;Not greater, non-skip
JRST %S ;;Greater, skip
%L:! CAMGE R+1,A+1 ;;Compare low order, skip if greater
%N:! ;;Not greater, Non-skip return
%S==%N+1 ;;Greater or equal, Skip return
.XCREF %L,%N,%S ;;Useless in CREF
>;;DCAMG

13-Dec-2006 12:43:50-PST,4112;000000000000
Return-Path: <[email protected]>
Received: from pangtzu.panda.com ([206.124.149.117]) by Lingling.Panda.COM with TCP/SMTP; Wed, 13 Dec 2006 12:34:51 -0800 (PST)
X-Return-Path: <[email protected]>
X-Received: from mta5.srv.hcvlny.cv.net ([167.206.4.200]) by lingling.panda.com with TCP/SMTP; Wed, 13 Dec 2006 03:24:49 -0800 (PST)
X-Received: from optonline.net (hamstr3.srv.hcvlny.cv.net [167.206.5.10])
by mta5.srv.hcvlny.cv.net
(Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006))
with ESMTP id <[email protected]> for
[email protected]; Wed, 13 Dec 2006 06:24:43 -0500 (EST)
X-Received: from [10.240.3.214] (Forwarded-For: 66.114.69.214, [10.240.3.214])
by mstr3.srv.hcvlny.cv.net (mshttpd); Wed, 13 Dec 2006 11:24:43 +0000 (GMT)
Date: Wed, 13 Dec 2006 11:24:43 +0000 (GMT)
From: [email protected]
Subject: Re: Tommy Timesharing joins the Tops-20 365 Club!
In-reply-to: <[email protected]>
To: Fred Wright <[email protected]>
Cc: TOPS-20 Hackers and Yackers <[email protected]>
Message-id: <[email protected]>
MIME-version: 1.0
X-Mailer: Sun Java(tm) System Messenger Express 6.2-6.01 (built Apr 3 2006)
Content-type: text/plain; charset=us-ascii
Content-language: en
Content-transfer-encoding: 7BIT
Content-disposition: inline
X-Accept-Language: en
Priority: normal
References: <[email protected]>
<[email protected]>
ReSent-Date: Wed, 13 Dec 2006 12:34:45 -0800 (PST)
ReSent-From: TOPS-20 List Moderator <[email protected]>
ReSent-To: TOPS-20 Distribution: ;
ReSent-Subject: Re: Tommy Timesharing joins the Tops-20 365 Club!
ReSent-Message-ID: <[email protected]>

> > Better would be to make TODCLK be a doubleword.
>
> Which could get into lots of difficulties expanding one word to two,
> whether it's a register, a field in a structure (some of which are
> known to user programs), or an array (which would then need a
> doubled index).

I don't have an informed opinion about how many difficulties you'd
have expanding the uptime millisecond count from one to two words.
However, one advantage is that you wouldn't have to change the
'philosophy' of those routines that do things with TODCLK (see
below).

> Running wc on the unmodified DEC sources (7.0TSU04, monitor
> only) gives:
>
> 355825 1830730 12367520 total

Yeah, but EXEC and Galaxy are necessary. See my previous post: it's
REALLY difficult to make an apples to apples comparison because we
don't know what the 40 MLOC contains and some of that is not in
assembly.

> Millisecond resolution is already severely marginal on modern
> systems. Aside from the compatibility issues, further degrading the
> resolution is undesirable.

I wasn't sure what you meant by marginal? I haven't seen this to be
the case in OS/2 global information segment (1.x and 2.x) and Windows
(which also implements this).

> The best solution to the problem is to recognize that the time value
> is neither signed nor unsigned, but modular. This is similar to the
> way TCP gets by with 32-bit sequence numbers without imposing a 4GiB
> limit on the length of a transfer.

I'm not sure that I understand. Not all code that uses the value
returned by TIME% is doing elapsed measurement. Some things really
want to know how much time the system has been up. Wouldn't going
modular eliminate this information? How would it be recovered?

> Implementing that would require lots of code changes, but no more
> than any other approach, and meanwhile would gain an infinite range
> without expanding to a doubleword.

Maybe more changes than would be involved with 'just' increasing the
width of the millisecond uptime field? You wouldn't have to rethink
the philosphy of the associated routines, just re-engineer them.
Going with a modular approach likely means you've got to use different
algorithms which is a different thing entirely.

13-Dec-2006 12:47:30-PST,11294;000000000000
Return-Path: <[email protected]>
Received: from pangtzu.panda.com ([206.124.149.117]) by Lingling.Panda.COM with TCP/SMTP; Wed, 13 Dec 2006 12:35:53 -0800 (PST)
X-Return-Path: <[email protected]>
X-Received: from mta2.srv.hcvlny.cv.net ([167.206.4.197]) by lingling.panda.com with TCP/SMTP; Wed, 13 Dec 2006 02:48:40 -0800 (PST)
X-Received: from optonline.net (hamstr3.srv.hcvlny.cv.net [167.206.5.10])
by mta2.srv.hcvlny.cv.net
(Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006))
with ESMTP id <[email protected]> for
[email protected]; Wed, 13 Dec 2006 05:48:34 -0500 (EST)
X-Received: from [10.240.3.214] (Forwarded-For: 66.114.69.214, [10.240.3.214])
by mstr3.srv.hcvlny.cv.net (mshttpd); Wed, 13 Dec 2006 10:48:33 +0000 (GMT)
Date: Wed, 13 Dec 2006 10:48:33 +0000 (GMT)
From: [email protected]
Subject: Re: UP2LNG
In-reply-to: <[email protected]>
To: Rick Ace <[email protected]>
Cc: [email protected]
Message-id: <[email protected]>
MIME-version: 1.0
X-Mailer: Sun Java(tm) System Messenger Express 6.2-6.01 (built Apr 3 2006)
Content-type: text/plain; charset=us-ascii
Content-language: en
Content-transfer-encoding: 7BIT
Content-disposition: inline
X-Accept-Language: en
Priority: normal
References: <[email protected]>
<[email protected]>
<[email protected]>
ReSent-Date: Wed, 13 Dec 2006 12:35:47 -0800 (PST)
ReSent-From: TOPS-20 List Moderator <[email protected]>
ReSent-To: TOPS-20 Distribution: ;
ReSent-Subject: Re: UP2LNG
ReSent-Message-ID: <[email protected]>

> So, the only errors in evidence are the failure to accommodate an
> extended period of uptime, and the misnaming of the BUGHLT. A more
> accurate name would have been something like CLKOVF (clock
> overflow).

> In lieu of the "right" implementation, peppering the CTY with
> BUGINFs or BUGCHKs during the week or two preceding the anticipated
> overflow would have been a thoughtfully conceived feature too.

It's funny you should mention this, it's along the lines of something
that I was thinking about. My feeling that you shouldn't just crash
the machine, but rather try to do something more 'graceful' about it.
So peppering the CTY is good, but you still have that UP2LNG crash
which means that you may have problems with local file system
consistency (and other CFS issues). You might crash the cluster.

The thing to do is bring the system down before which means that
you've got to detect the UP2LNG situation and do something before you
can't run Tops-20 any further. The system should shut itself down
(via a self-issued HSYS%) if it detects an impending UP2LNG bug halt.

But you can't have an HSYS% itself be issued internally, because as
currently coded, this would you get queued shutdown on PANDA. If you
rebooted with the queued shutdown set, you'd do the wrong thing.

I wandered over to the Department of Largely Unnecessary Code (they're
right next to the BLISS group) and came up with the following. In
MEXEC.MAC, there is the CHKR routine which does the periodic check of
things and kicks off various activities. Tops-20 checks for impending
system shutdown and does the system shutdown by doing the following on
the second page of CHKR (note my addition)

CALL CHKUP2 ;;;; ;See if we need to handle an UP2LNG
SKIPE A,HSYST1 ;SHUTDOWN PROCESS ACTIVE?
CAMN A,[-1] ;OR IS SYSTEM SHUTDOWN
SKIPA ;SYSTEM SHUTDOWN OR PROCESS NOT ACTIVE
CALL CHKHSY ;YES, CHECK IT

So CHKR decides if CHKHSY needs to run and, if so, runs it. My change
is that this check in CHKR might directly be preceded with a call to a
routine in JSYSM.MAC which would set up the self shutdown. A couple
of notes:

1) The code below is my SUGGESTION (I.E., a straw object), so
let's not quibble about the precise details.

2) HSYS% itself would need to do a SETZM HSYST9 someplace so that
the checking code would catch the case of an intervening HSYS%
setting a shutdown that was further in the future.

3) HSYS% could probably use some more recoding. I had some
suggested changes that I sent to MRC a (few?) years ago to
handle the case of a shutdown being set after 27-Sep-2217
while you were still before 27-Sep-2217.

4) SIGNED long UTC is used in order for the code to work after
27-Sep-2217.

5) I haven't really thought through error handling, much

6) I seem to remember a way to shutdown Tops-20 and have it
auto-reboot itself. If that is the case, then HSYST4 could
probably be set to a more informed value.

7) TADDIF in JSYSM.MAC also needs to be recoded to handle large
differences in shutdown time and wrap issues on 27-Sep-2217.
I've also done this and sent the changes to MRC, but I believe
he's going to do something different.

SUBTTL Determine whether we need to issue a self-shutdown and do it

INTERN CHKUP2 ; See if we need to force a shutdown
; Or does the symbol go in GLOBS?
CHKUP2: MOVE A,UP2INI ; Load initialization talisman
CAMN A,HSYST6 ; Have we initialized our UP2LNG value?
IFSKP. ; Nope, compute some trigger times
MOVEM A,HSYST6 ; Say we're initialized
MOVX A,UP2SLF ; When should we start a self shutdown
CALL UP2TIM ; Convert millisecond offset to double UTC
DMOVEM A,HSYST7 ; Set shutdown self initiate time
MOVX A,UP2DWN ; Load offset for must be down time
CALL UP2TIM ; Convert to double UTC
DMOVEM A,HSYST8 ; Set UP2LNG to be done by this time
ENDIF. ; End of initialization
; Now check to see if we need to get safe
CALL LGTAD ; Get the current time of day, UTC
CAMN T1,[-1] ; Is the system time set?
CALL ERROR ; No! Don't bother with any of this
UCASTL T1, ; Cast unsigned UTC TOD to signed long
DCAMGE T1,HSYST7 ; Should we be getting worried?
IFSKP. ; Yup, better see if we're prepared
MOVE T1,HSYST1 ; Load current system shutdown time
UCASTL T1, ; Cast unsigned UTC TOD to signed long
DCAMG T1,HSYST8 ; Are we shutting down before we need to?
ANSKP. ; Yup, we'll be safely down, then
SKIPE HSYST9 ; Have we already done this?
ANSKP. ; Yup, no need to waste any more cycles
DMOVE T1,HSYST8 ; Load must-be-down time
LCASTU T1, ; Cast signed long to unsigned short UTC
MOVEM T2,HSYST1 ; Set a self forced system down time
SETZM HSYST4 ; For now, don't guess about when we'll be back
IFN PANDASW,< ; PANDA has friendly reason string
XMOVEI T1,HSYST5 ; Destination is reason string GETAB% table
XMOVEI T2,UP2TXT ; Source is explanation of self shutdown
MOVX T3,UP2LEN ; Load length of reason string
XBLT. T1 ; Set the shutdown reason string
> ; End of PANDA conditional
SETOM HSYST9 ; Say we've completed self-shutdown
ENDIF. ; End case of possible self shutdown
RET ; Return to CHKR

REMARK Storage and definitions

; Auto-UP2LNG self-shutdown constants

UP2DWN==<^D1000*^D60*^D15> ; Must be down 15 minutes before UP2LNG
UP2SLF==UP2DWN+<^D1000*^D60*^D60*^D2>
; Must start self shutdown 2 hours before that
UP2INI: ASCIZ /Plugh/ ; UP2LNG time value initialized talisman
IFN PANDASW,< ; PANDA reason text
UP2TXT: ASCIZ /Impending UP2LNG BUGHLT self initiated shutdown/
UP2LEN==.-UP2TXT
> ; End of PANDA conditional

; Auto-UP2LNG self-shutdown variables

NR HSYST6,1 ; Set if UP2LNG shutdown time configured
NR HSYST7,2 ; Double word TODCLK shutdown self initiate
NR HSYST8,2 ; Double word TODCLK shutdown time
NR HSYST9,1 ; Set if doing a self shutdown

SUBTTL UP2TIM Convert millisecond offset from UP2LNG to UTC

REMARK Would need to redfine the register usage

UTCDAY==<1,,0> ; UTC ticks in a day
MS1DAY==<^D1000*^D60*^D60*^D24> ; Milliseconds in a full day

UP2TIM: SAVEAC <P1,P2,P3,P4,P5,P6>

UCASTL T1, ; Convert unsigned milliseconds to unsigned long
DMOVE P5,T1 ; And save for later
MOVE T1,TODCLK ; Get milliseconds since boot
UCASTL T1, ; Cast unsigned word to signed long
DMOVE P1,[EXP 0,.INFIN] ;Maximum MS allowed by APRSRV
DSUB P1,T1 ; Calculate elapsed MS until UP2LNG
CAXE P1,0 ; But more than 397 days, 16:22:18 ??
CALL ERROR ; Must be a new APRSRV ...
DSUB P1,P5 ; Calculate negative offset from this time
CAXE P1,0 ; Rolled it anyhow?
CALL ERROR ; Oh well
; Now convert elapsed time to UTC
MOVE P3,P2 ; Load low order MS to UP2LNG
MULX P3,UTCDAY ; Convert X ms to UTC * X ms
DIVX P3,MS1DAY ; Strip off the milliseconds
CAXL P4,MS1DAY/^D2 ; Are we over half a tick?
ADDX P3,^D1 ; Add in an unsigned UTC tick
UCASTL P3, ; Cast to double long UTC ticks to UP2LNG

CALL LGTAD ; Get the current time of day, UTC
CAMN T1,[-1] ; Is the system time set?
CALL ERROR ; No! Don't say we know it.
UCASTL T1, ; Cast unsigned UTC TOD to signed long

DADD T1,P3 ; Calculate UTC time offset
CAXLE T1,^D1 ; UP2LNG is past 7-Aug-2576 19:59:59 EST?
DMOVE T1,[EXP 1,.INFIN] ;Won't be winning for much longer ...
RET ; Return double UTC converted millisecond offset

SUBTTL Macros to handle double arithmatic

DEFINE UCASTL (REG,ADDR) < ;;Cast an unsigned word to a signed long

IFNB <ADDR>,<.FATAL 'ADDR Can only cast values in registers!>
IFG REG-^O16,<.FATAL Register 'REG is out of bounds>

MOVE REG+1,REG ;;Put unsigned single in low order
TXZE REG+1,<1B0> ;;Does low order look negative?
SKIPA REG,[1] ;;Yes, put the high order bit in the high
SETZ REG, ;;Otherwise zero high order word
>;;UCASTL

DEFINE LCASTU (REG,ADDR) < ;;Cast signed long to an unsigned word

IFNB <ADDR>,<.FATAL 'ADDR Can only cast values in registers!>
IFG REG-^O16,<.FATAL Register 'REG is out of bounds>

CAXE REG,0 ;;Any high order?
TXOA REG+1,<1B0> ;;Cast down to unsigned word
TXZ REG+1,<1B0> ;;Otherwise scrub low order long to word
>;;LCASTU

DEFINE DCAMGE (R,A,%N,%S,%L) < ;;Double compare and skip if greater or equal

IFB <A>,<.FATAL Not comparing to anything!>
IFG R-^O16,<.FATAL Register 'R is out of bounds>

CAMN R,A ;;Compare high order
JRST %L ;; Equal, check low order
CAMG R,A ;;Compare high order, skip if greater
JRST %N ;;Not greater, non-skip
JRST %S ;;Greater, skip
%L:! CAMGE R+1,A+1 ;;Compare low order, skip if greater
%N:! ;;Not greater, Non-skip return
%S==%N+1 ;;Greater or equal, Skip return
.XCREF %L,%N,%S ;;Useless in CREF
>;;DCAMG

DEFINE DCAMG (R,A,%N,%S,%L) < ;;Double compare and skip if greater

IFB <A>,<.FATAL Not comparing to anything!>
IFG R-^O16,<.FATAL Register 'R is out of bounds>

CAMN R,A ;;Compare high order
JRST %L ;; Equal, check low order
CAMG R,A ;;Compare high order, skip if greater
JRST %N ;;Not greater, non-skip
JRST %S ;;Greater, skip
%L:! CAMG R+1,A+1 ;;Compare low order, skip if greater
%N:! ;;Not greater, Non-skip return
%S==%N+1 ;;Greater, Skip return
.XCREF %L,%N,%S ;;Useless in CREF
>;;DCAMG

13-Dec-2006 12:51:08-PST,6496;000000000000
Return-Path: <[email protected]>
Received: from pangtzu.panda.com ([206.124.149.117]) by Lingling.Panda.COM with TCP/SMTP; Wed, 13 Dec 2006 12:37:41 -0800 (PST)
X-Return-Path: <[email protected]>
X-Received: from mta2.srv.hcvlny.cv.net ([167.206.4.197]) by lingling.panda.com with TCP/SMTP; Wed, 13 Dec 2006 02:55:15 -0800 (PST)
X-Received: from optonline.net (hamstr3.srv.hcvlny.cv.net [167.206.5.10])
by mta2.srv.hcvlny.cv.net
(Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006))
with ESMTP id <[email protected]> for
[email protected]; Wed, 13 Dec 2006 05:55:09 -0500 (EST)
X-Received: from [10.240.3.214] (Forwarded-For: 66.114.69.214, [10.240.3.214])
by mstr3.srv.hcvlny.cv.net (mshttpd); Wed, 13 Dec 2006 10:55:09 +0000 (GMT)
Date: Wed, 13 Dec 2006 10:55:09 +0000 (GMT)
From: [email protected]
Subject: Re: UP2LNG
In-reply-to: <[email protected]>
To: Rick Ace <[email protected]>
Cc: [email protected]
Message-id: <[email protected]>
MIME-version: 1.0
X-Mailer: Sun Java(tm) System Messenger Express 6.2-6.01 (built Apr 3 2006)
Content-type: text/plain; charset=us-ascii
Content-language: en
Content-transfer-encoding: 7BIT
Content-disposition: inline
X-Accept-Language: en
Priority: normal
References: <[email protected]>
<[email protected]>
<[email protected]>
ReSent-Date: Wed, 13 Dec 2006 12:37:33 -0800 (PST)
ReSent-From: TOPS-20 List Moderator <[email protected]>
ReSent-To: TOPS-20 Distribution: ;
ReSent-Subject: Re: UP2LNG
ReSent-Message-ID: <[email protected]>

> > MRC
> >
> > I wonder how most UNIX systems of today will do on January 19,
> > 2038 at 03:14:08 UTC. ;-)

> R.Ace
>
> Most UNIX systems of today will be history thirty years from now.
> The vendors of those that survive will have upgraded the system
> software and language tools long in advance to defuse the well-known
> UNIX analogue of the Y2K bug. Folks running legacy apps will
> probably stand the greatestrisk. Think of it as thinning the herd a
> bit :-)

Conspiracy theorists might say that the nearly complete absence of
coverage of the impending time_t debacle is a big cover up. However,
some reflection is perhaps more instructive.

Back in 1999, when I was working at BIG BANK, we did a LOT of business
with DEC using Digital Unix (DU) on the Alpha platform. One, day we
went to Maynard to see the latest Dog and Pony in the Big Corporate
Presentation Room with cushy seats, lots of DEC engineers, sales suits
and other Important People.

On a number of occasions, presenters had gotten pretty gushy about how
DU didn't and wouldn't suffer from *any* Y2K problems because it was
UNIX and how they were verifying this anyway because they were
wonderful. Also, the port of VAX C to DU would make a just perfect
system even more 64 bitly perfect.

One of our operations technical leads then said, "Great, what sort of
performance improvement have you seen in DU?". Dead silence. "You
did recompile DU with VAX C? Didn't you? This would give us the
greatest overall visible performance boost that would be independent
of application type--we wouldn't have any work to do." More dead
silence. "Uh, we haven't done that, yet".

I followed up with another question, "Great, since you're on a 64 bit
platform, what have you done about the 2038 issue?" Dead silence.
"Is 'time_t' it a 32 bit or a 64 bit long? If it's still 32 bit, then
your library isn't precisely 64 bit pure and you're going to have an
issue in 2038 just like every other 32 bit platform." More dead
silence.

So you might say that the engineering staff really wasn't thinking
ahead, perhaps like what happened with various two character year
fields everywhere. Or maybe it was likely that the bean counters
decided that so many resources were decked against addressing the year
field issues, that the 'time_t' issue could be solved, "later".

I always thought this was a lost opporunity to 'synergistically' solve
'time_t' while a lot of eyeballs were scanning code for two digit year
issues. At least at BIG BANK, one of our applications protocoles
communicated times using a 'tm' structure (time.h). But risk
management can get you funny answers ...

Take other operating systems, for example. BIOS (Int 1aH, function
04h), DOS (Int 21h, function 2ah), Windows and OS/2 (DosGetDateTime
and DosGetInfoSeg,offset year_) all give you four character year
fields. However, the semantics of their C library implementations
will still cause code to be generated which does the wrong thing (see
dtoxtime). So stuff is still going to break there. Interestingly,
kcc does not have this problem.

Meanwhile, a good bit of code in the extended mode FTP server has to
worry about this. When eftpsr comes up, it discovers internal UTC
values for:

BEPOCH: ASCIZ /13-DEC-1901 20:45:52-GMT/ ; Beginning of epoch
MEPOCH: ASCIZ / 1-Jan-1970 00:00:00-GMT/ ; Middle of epoch
EEPOCH: ASCIZ /19-JAN-2038 03:14:07-GMT/ ; End of epoch

Tops-20 dates that are after EEPOCH are clipped to EEPOCH. Dates that
are before BEPOCH are rounded up to BEPOCH. Unknown dates that are
set to MEPOCH. Actually, this isn't quite true. You can't exactly
use the beginning nor end of the epoch because a couple of FTP clients
break when trying to display these two dates.

Finally, if memory serves correctly, that Maynard session was also
memorable because I requested a set of washable Crayolas be given to
the lead DEC sales representative on the BIG BANK account so that he
could contribute by coloring his paper copy of the power point slides
while the technical presentation itself being given.

The BIG BANK technical heros almost split their sides laughing, but
the DEC engineers reaction was even stronger: one of them laughed so
hard that tears were coming down his face. I thought he was going to
choke. The lead DEC sales rep turned a very bright beet red and I
felt so guilty that I wound up privately apologizing to him very
carefully during a break out session.

I don't see 2038 just as a thinning of the herd. While it's a global
risk, I'll also see it as an opportunity for another big belly laugh,
only this time I won't be apologizing.

13-Dec-2006 20:38:15-PST,5589;000000000000
Return-Path: <[email protected]>
Received: from pangtzu.panda.com ([206.124.149.117]) by Lingling.Panda.COM with TCP/SMTP; Wed, 13 Dec 2006 20:34:18 -0800 (PST)
X-Return-Path: <[email protected]>
X-Received: from mta5.srv.hcvlny.cv.net ([167.206.4.200]) by Lingling.Panda.COM with TCP/SMTP; Wed, 13 Dec 2006 14:37:47 -0800 (PST)
X-Received: from optonline.net (hamstr3.srv.hcvlny.cv.net [167.206.5.10])
by mta5.srv.hcvlny.cv.net
(Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006))
with ESMTP id <[email protected]> for
[email protected]; Wed, 13 Dec 2006 17:37:43 -0500 (EST)
X-Received: from [10.240.3.214] (Forwarded-For: 66.114.69.214, [10.240.3.214])
by mstr3.srv.hcvlny.cv.net (mshttpd); Wed, 13 Dec 2006 22:37:42 +0000 (GMT)
Date: Wed, 13 Dec 2006 22:37:42 +0000 (GMT)
From: [email protected]
Subject: DDTIN/DDTOUT UUOs or the perils of debuging SPJFN% programs
In-reply-to: <[email protected]>
To: [email protected]
Message-id: <[email protected]>
MIME-version: 1.0
X-Mailer: Sun Java(tm) System Messenger Express 6.2-6.01 (built Apr 3 2006)
Content-type: text/plain; charset=us-ascii
Content-language: en
Content-transfer-encoding: 7BIT
Content-disposition: inline
X-Accept-Language: en
Priority: normal
References: <[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
ReSent-Date: Wed, 13 Dec 2006 20:34:12 -0800 (PST)
ReSent-From: TOPS-20 List Moderator <[email protected]>
ReSent-To: TOPS-20 Distribution: ;
ReSent-Subject: DDTIN/DDTOUT UUOs or the perils of debuging SPJFN% programs
ReSent-Message-ID: <[email protected]>

Problem
=======

Single stepping the following code hangs DDT

DMOVE T1,[EXP .FHSLF, <.NULIO,,.NULIO>]
SPJFN%

Background
==========

The amount of attacks that I'm getting on the extended mode FTP
server on Tommy Timesharing seems to be always increasing. So
much for SPAM and other legislation ...

Frequently, these attacks can leave an FTP server job in a wedged
state. This leaves jobs lying around that need to be cleaned up,
blah. Cleaning up the mess by hand is getting really annoying. I
have to do a lot of code to detect, prevent and fix this.

The code above is one of the things that I'm doing. However, this
is starting to get crockish, so I'm probably going to think about
punting and do a complete redesign at some point.

I'll also want to consider SPJFN% for future expansion of the
server. One possible architectural decision is to use some more
forks to do things (like encrypt the FTP control and data
connections) and then pipe things between them as appropriate.

Analysis
========

DDT is hanging because it is using .PRIIN and .PRIOU to do output
which I'm changing with SPJFN%.

Proposal
========

In DDT.MAC at CHIN2, DDT is using a TEXTI% which is using .PRIIN
and .PRIOU as the terminal JFNs. This could be changed to either
a .CTTRM (or a .TTDES+line# which would work but probably not
survice a DTACH%/ATACH%).

A number of other things would have to be changed, the
implementation of TMSG being one of them, TOUT, TOUTB, ECHO, ECHOB
and LISTEN being others.

Ideally, DDT might have the idea of the debugging terminal which
could be set/poked to be something useful, but see below.

It is speculative but possible as to whether the code change above
would allow more easier debugging of routines that do graphics
input and output to the terminal.

This sounds like it might be fun, so maybe I'll do it after I get
the alpha version of the extended mode FTP server out. Despite
having to address the clowns above, I continue to make progress.

Workarounds
===========

1) "Don't do it that way". Don't use SPJFN% to handle the pipes,
pass in PIP: JFNs and use these directly (set .CMIOJ, etc).

2) Code the affected routines in a seperate module and then debug
this as a single section (classic) program with IDDT.

DDTIN (CALLI 1) and DDTOUT (CALLI 3) to the Rescue?
===================================================

Don't ask me why I remember these two arcane UUOs, I never used
them, directly.

All versions of Tops-10 documentation that I have describe them as
being there for DDT submode which apparently allows you to debug
even when you've INIT'ed a TTY on another channel and/or perhaps
have gotten creative with SETLCH. They appear to still work on
Tops-10.

These UUO's seemed to be the thing to use, so I had a look at how
PA1050 implements them. In fact in PAT.MAC, the implementation of
DDTIN and DDTOUT are using .PRIIN and .PRIOU which means they'd
break, too.

What's also of interest is that the version of DDT that comes with
Tops-20 would appear to be a 'one size fits all'; I.E., it has
Tops-10/EXEC mode conditionals. The Tops-10 user mode code is
doing an OUTCHR instead of a DDTOUT, etc.

I wonder why isn't it doing a DDTOUT? Or maybe this is something
like what I bumped into with DPY.MAC? It may be remember that
DPY.MAC had a few Tops-10 conditionals, but I eventually found out
that Tops-10 was running quite a different module.

13-Dec-2006 22:57:13-PST,2139;000000000000
Return-Path: <[email protected]>
Received: from pangtzu.panda.com ([206.124.149.117]) by Lingling.Panda.COM with TCP/SMTP; Wed, 13 Dec 2006 22:53:29 -0800 (PST)
X-Return-Path: <[email protected]>
X-Received: from pangtzu.panda.com ([206.124.149.117]) by Lingling.Panda.COM with TCP/SMTP; Wed, 13 Dec 2006 22:40:39 -0800 (PST)
Date: Wed, 13 Dec 2006 22:40:36 -0800 (PST)
From: Mark Crispin <[email protected]>
Sender: [email protected]
To: [email protected]
cc: [email protected]
Subject: Re: DDTIN/DDTOUT UUOs or the perils of debuging SPJFN% programs
In-Reply-To: <[email protected]>
Message-ID: <[email protected]>
References: <[email protected]>
<[email protected]>
<[email protected]> <[email protected]>
<[email protected]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
ReSent-Date: Wed, 13 Dec 2006 22:53:22 -0800 (PST)
ReSent-From: TOPS-20 List Moderator <[email protected]>
ReSent-To: TOPS-20 Distribution: ;
ReSent-Subject: Re: DDTIN/DDTOUT UUOs or the perils of debuging SPJFN%
programs
ReSent-Message-ID: <[email protected]>

TOPS-10 didn't have the concept of primary input or output. DDTIN and
DDTOUT were from PDP-6 days, and were completely replaced by the TTCALL
UUO (INCHRW, INCHWL, OUTCHR, OUTSTR, etc.).

There's no particular to reason for any TOPS-10 application written after
1967 or thereabouts to use DDTIN/DDTOUT. In more recent monitors, DDTOUT
is just a jacket to OUTSTR; DDTIN does some stuff but it uses the same low
level routines as TTCALL.

Even if DDTIN/DDTOUT still were independent (which they still were in
3-series TOPS-10 monitors, although TTCALL/TTYUUO was already there),
there's no way that TOPS-20 would implement them with anything other than
calls using primary I/O.

-- Mark --

http://panda.com/tops-20
TOPS-20: a great improvement over its successors

14-Dec-2006 08:15:38-PST,5124;000000000000
Return-Path: <[email protected]>
Received: from pangtzu.panda.com ([206.124.149.117]) by Lingling.Panda.COM with TCP/SMTP; Thu, 14 Dec 2006 08:12:18 -0800 (PST)
X-Return-Path: <[email protected]>
X-Received: from mta3.srv.hcvlny.cv.net ([167.206.4.198]) by Lingling.Panda.COM with TCP/SMTP; Thu, 14 Dec 2006 00:12:40 -0800 (PST)
X-Received: from optonline.net (hamstr3.srv.hcvlny.cv.net [167.206.5.10])
by mta3.srv.hcvlny.cv.net
(Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006))
with ESMTP id <[email protected]> for
[email protected]; Thu, 14 Dec 2006 03:12:35 -0500 (EST)
X-Received: from [10.240.3.209] (Forwarded-For: 66.114.69.214, [10.240.3.209])
by mstr3.srv.hcvlny.cv.net (mshttpd); Thu, 14 Dec 2006 08:12:35 +0000 (GMT)
Date: Thu, 14 Dec 2006 08:12:35 +0000 (GMT)
From: [email protected]
Subject: MM /AFTER: parameter does not work for SYSTEM and local files
In-reply-to: <[email protected]>
To: [email protected]
Message-id: <[email protected]>
MIME-version: 1.0
X-Mailer: Sun Java(tm) System Messenger Express 6.2-6.01 (built Apr 3 2006)
Content-type: text/plain; charset=us-ascii
Content-language: en
Content-transfer-encoding: 7BIT
Content-disposition: inline
X-Accept-Language: en
Priority: normal
References: <[email protected]>
<[email protected]>
<[email protected]>
<[email protected]> <[email protected]>
<[email protected]>
ReSent-Date: Thu, 14 Dec 2006 08:12:11 -0800 (PST)
ReSent-From: TOPS-20 List Moderator <[email protected]>
ReSent-To: TOPS-20 Distribution: ;
ReSent-Subject: MM /AFTER: parameter does not work for SYSTEM and local
files
ReSent-Message-ID: <[email protected]>

Problem
=======

When using the /AFTER: parameter to send differed mail, mail to
special mail boxes such as SYSTEM and local files is always sent
immediately, no matter what the setting of /AFTER: is.

Workaround
==========

Make a .CTL file to send the mail, then use the /AFTER: parameter
on the SUBMIT so that Quasar starts the batch job to send the text
at the appropriate time. My previous fix to QSRDSP to properly
display the /AFTER: parameter is of use, but strictly speaking is
not absolutely necessary.

Background
==========

I wanted to send some mail that would automatically post a system
message once I had been up over a year. The BCC: to myself was
appropriately queued, but the message to SYSTEM immediately showed
up no matter what I did.

Analysis
========

In the SNDLCL routine in MM.MAC, local mail to special mail boxes
is processed. The mail is immediately sent, with no consideration
of /AFTER:

Fix
===

Make SNDLCL respect /AFTER: and queue even local mail for
delivery.

Code
====

File 1) DSK:MM.MAC[4,37] created: 2006 03-Dec-06
File 2) DSK:MM.BAK[4,37] created: 0342 01-Mar-02

1)1 ;[TOMMYT]STAR:<MM>MM.MAC.1193, 3-Dec-2006 18:14:44, Edit by SLOGIN
1) ;[T41] When sending local mail (like to SYSTEM), respect AFTER!
1) TITLE MM Mail Munger -- TOPS-20 mailsystem
****
2)1 TITLE MM Mail Munger -- TOPS-20 mailsystem
**************

1)184 SKIPE AFTDAT ;[T41] After parameter in effect?
1) ANSKP. ;[T41] Yes, do CC: when actually sent
1) TXON F,F%F2 ;Yes, setup as saved.messages file
****
2)183 TXON F,F%F2 ;Yes, setup as saved.messages file
**************

1)184 SKIPE AFTDAT ;[T41] After parameter in effect?
1) ANSKP. ;[T41] Yes, queue this for later
1) MOVX A,GJ%OLD!GJ%DEL!GJ%PHY!GJ%SHT ;Verify it exists
****
2)183 MOVX A,GJ%OLD!GJ%DEL!GJ%PHY!GJ%SHT ;Verify it exists
**************

Notes
=====

The code above is a PROPOSAL, not the final word. The problem is
that it still doesn't fix the entire problem due to some
interaction with MMAILR. In particular, MMAILR views mail to
SYSTEM as mail to a file, not a user.

Thus, it appears that the protection of POBOX:<SYSTEM>MAIL.TXT.1
is checked and if world append does not exist, a OPNX6 (append
access required) is generated. Since this is considered to be a
soft error, the mail isn't rejected immediately, but will
ultimately fail.

That problem can be fixed by protecting POBOX:<SYSTEM>MAIL.TXT.1
to 775656, which allows world append (among other things). But
this can immediately be seen as a case of the cure being worse
than the disease: now anybody can append 'stuff' to SYSTEM. It's
hard to see how this is a good idea.

My guess is that the code in SNLFCK might be reworked to allow the
send to SYSTEM to work for WHEELs or OPERATORS or other people in
the group list, but I thought I'd post this first before I started
really digging into those details.

14-Dec-2006 10:20:05-PST,2563;000000000000
Return-Path: <[email protected]>
Received: from pangtzu.panda.com ([206.124.149.117]) by Lingling.Panda.COM with TCP/SMTP; Thu, 14 Dec 2006 10:16:11 -0800 (PST)
X-Return-Path: <[email protected]>
X-Received: from pangtzu.panda.com ([206.124.149.117]) by Lingling.Panda.COM with TCP/SMTP; Thu, 14 Dec 2006 10:15:44 -0800 (PST)
Date: Thu, 14 Dec 2006 10:15:40 -0800 (PST)
From: Mark Crispin <[email protected]>
Sender: [email protected]
To: [email protected]
cc: [email protected]
Subject: Re: MM /AFTER: parameter does not work for SYSTEM and local files
In-Reply-To: <[email protected]>
Message-ID: <[email protected]>
References: <[email protected]>
<[email protected]>
<[email protected]> <[email protected]>
<[email protected]> <[email protected]>
<[email protected]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
ReSent-Date: Thu, 14 Dec 2006 10:16:05 -0800 (PST)
ReSent-From: TOPS-20 List Moderator <[email protected]>
ReSent-To: TOPS-20 Distribution: ;
ReSent-Subject: Re: MM /AFTER: parameter does not work for SYSTEM and local
files
ReSent-Message-ID: <[email protected]>

SYSTEM isn't a user. It's a FILES-ONLY directory. Mail to SYSTEM is
implemented via a separate mechanism and does not go through MMAILR.

I'm surprised to see that half-hearted attempt in MMAILR to support mail
to SYSTEM, since the code otherwise goes to considerable effort to
disallow such a thing. It may work if you make SYSTEM be a user (that is,
turn off FILES-ONLY) and/or create an entry for it in MAILING-LISTS.TXT.
It isn't enough just to set the file protection to 775656.

I wouldn't though. Mail to SYSTEM via the mailer queues was disabled for
a reason. The track of sender was always seen as advisory and never
something to use for a security check. Remember that anybody can write
into the queues; all you need to do is figure out how to set the last
writer to what you want.

I would use a batch file to send the mail, not the mailer queues, to send
a future SYSTEM message. Or even better, a daemon, since the purpose is
to send a message at the one-year uptime point.

-- Mark --

http://panda.com/tops-20
TOPS-20: a great improvement over its successors

14-Dec-2006 10:34:16-PST,2175;000000000000
Return-Path: <[email protected]>
Received: from pangtzu.panda.com ([206.124.149.117]) by Lingling.Panda.COM with TCP/SMTP; Thu, 14 Dec 2006 10:30:41 -0800 (PST)
X-Return-Path: <[email protected]>
X-Received: from pangtzu.panda.com ([206.124.149.117]) by Lingling.Panda.COM with TCP/SMTP; Thu, 14 Dec 2006 10:28:37 -0800 (PST)
Date: Thu, 14 Dec 2006 10:28:33 -0800 (PST)
From: Mark Crispin <[email protected]>
Sender: [email protected]
To: [email protected]
cc: [email protected]
Subject: Re: MM /AFTER: parameter does not work for SYSTEM and local files
In-Reply-To: <[email protected]>
Message-ID: <[email protected]>
References: <[email protected]>
<[email protected]>
<[email protected]> <[email protected]>
<[email protected]> <[email protected]>
<[email protected]>
<[email protected]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
ReSent-Date: Thu, 14 Dec 2006 10:30:33 -0800 (PST)
ReSent-From: TOPS-20 List Moderator <[email protected]>
ReSent-To: TOPS-20 Distribution: ;
ReSent-Subject: Re: MM /AFTER: parameter does not work for SYSTEM and local
files
ReSent-Message-ID: <[email protected]>

On Thu, 14 Dec 2006, Mark Crispin wrote:
> I would use a batch file to send the mail, not the mailer queues, to send
> a future SYSTEM message. Or even better, a daemon, since the purpose is
> to send a message at the one-year uptime point.

In particular, you don't want to post the message at a particular date and
time; you want to post it at a particular uptime. The two are not the
same. You can predict that a particular uptime may be reached at a
particular date and time, but you don't know that it will happen until
that time comes.

-- Mark --

http://panda.com/tops-20
TOPS-20: a great improvement over its successors

14-Dec-2006 18:38:21-PST,3658;000000000000
Return-Path: <[email protected]>
Received: from pangtzu.panda.com ([206.124.149.117]) by lingling.panda.com with TCP/SMTP; Thu, 14 Dec 2006 18:34:28 -0800 (PST)
X-Return-Path: <[email protected]>
X-Received: from mail1.panix.com ([166.84.1.72]) by lingling.panda.com with TCP/SMTP; Thu, 14 Dec 2006 12:50:05 -0800 (PST)
X-Received: from panix5.panix.com (panix5.panix.com [166.84.1.5])
by mail1.panix.com (Postfix) with ESMTP id 7F5DF58B30
for <[email protected]>; Thu, 14 Dec 2006 15:50:00 -0500 (EST)
X-Received: (from alderson@localhost)
by panix5.panix.com (8.11.6p3/8.8.8/PanixN1.1) id kBEKo0d22574;
Thu, 14 Dec 2006 15:50:00 -0500 (EST)
Date: Thu, 14 Dec 2006 15:50:00 -0500 (EST)
Message-Id: <[email protected]>
From: Rich Alderson <[email protected]>
To: [email protected]
Subject: [[email protected]: Re: ironic thing about UP2LNG...]
ReSent-Date: Thu, 14 Dec 2006 18:34:23 -0800 (PST)
ReSent-From: TOPS-20 List Moderator <[email protected]>
ReSent-To: TOPS-20 Distribution: ;
ReSent-Subject: [[email protected]: Re: ironic thing about
UP2LNG...]
ReSent-Message-ID: <[email protected]>

Trying once again to send this. --rma

------- Start of forwarded message -------
X-Coding-System: nil
Mail-from: From alderson Tue Dec 12 22:36:25 -0500 2006
Date: Tue, 12 Dec 2006 22:36:25 -0500
From: Rich Alderson <[email protected]>
To: [email protected]
In-reply-to: <[email protected]> (message
from Mark Crispin on Mon, 11 Dec 2006 23:18:16 -0800 (PST))
Subject: Re: ironic thing about UP2LNG...
References: <[email protected]> <[email protected]>

> Date: Mon, 11 Dec 2006 23:18:16 -0800 (PST)
> From: Mark Crispin <[email protected]>

> On Mon, 11 Dec 2006, Fred Wright wrote:

>>> I doubt that any KL actually ran for over a year without a reboot. This
>>> was probably a gedanken exercise. If anyone knows the current whereabouts
>>> of Mike Raspuzzi we could ask him.

KLs under maintenance contract certainly did not run for a year without reboot.
The FS standard was a 4-hour PM every month; LOTS negotiated a quarterly PM,
scheduled between academic quarters, to avoid intentional interruption to
student computing.

>> I suspect that the UP2LNG code may have been originally written for a
>> pre-KL system where TODCLK was computed incrementally, and hence the
>> overflow would have been observable.

> Nope, Mike Raspuzzi added the UP2LNG bughlt in the final days of DEC
> TOPS-20 (February 16, 1989) based upon some tests that he and Greg Scott
> did.

And the original implementation was incorrect--XKL hit an UP2LNG a couple of
years before the one I reported out to the world, a pointer to which Dr. Beebe
has kincly provided. However, it was not *really* UP2LNG as described in the
BUGHLT documentation, because the programmer who did the work used "a large
enough" value for the comparison, rather than the correct value, and the halt
occurred roughly half as soon as it should.

Ralph diagnosed the problem and fixed the XKL code; the announced halt was on a
system running that fixed code.

NB: The XKL code was never brought up to TSU04 levels, so there may have been
a late DEC fix for that problem, explaining the difference between Panda and
XKL behaviours.

Rich
------- End of forwarded message -------

14-Dec-2006 18:44:37-PST,6922;000000000000
Return-Path: <[email protected]>
Received: from pangtzu.panda.com ([206.124.149.117]) by lingling.panda.com with TCP/SMTP; Thu, 14 Dec 2006 18:41:07 -0800 (PST)
X-Return-Path: <[email protected]>
X-Received: from pangtzu.panda.com ([206.124.149.117]) by lingling.panda.com with TCP/SMTP; Thu, 14 Dec 2006 18:39:34 -0800 (PST)
Date: Thu, 14 Dec 2006 18:39:30 -0800 (PST)
From: Mark Crispin <[email protected]>
Sender: [email protected]
To: TOPS-20 Hackers and Yackers <[email protected]>
Subject: Fwd: Re: LAT and KEA! (and others) (fwd)
Message-ID: <[email protected]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
ReSent-Date: Thu, 14 Dec 2006 18:40:59 -0800 (PST)
ReSent-From: TOPS-20 List Moderator <[email protected]>
ReSent-To: TOPS-20 Distribution: ;
ReSent-Subject: Fwd: Re: LAT and KEA! (and others) (fwd)
ReSent-Message-ID: <[email protected]>

Tom's message got sent during the second windstorm-induced power outage
that hit Panda this week. The third, and reputedly largest, windstorm is
in progress now so I don't know if another power outage will hit. For all
I know, Panda may be on battery backup now since one of my computers on a
different UPS is not responding. I'm currently in Seattle and can't
check; I'll know in about two hours.

-- Mark --

http://panda.com/tops-20
TOPS-20: a great improvement over its successors

---------- Forwarded message ----------
Date: Thu, 14 Dec 2006 20:19:52 +0000 (GMT)
From: [email protected]
To: Mark Crispin <[email protected]>
Subject: Fwd: Re: LAT and KEA! (and others)

This is a multi-part message in MIME format.

--Boundary_(ID_0zS5wr2K372pczABe1y/nw)
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7BIT
Content-disposition: inline

Hey Mark,

I sent this out a day or so ago and havn't seen it show up on the Tops-20 mailing list while I've seen other things posted after it show up.

Did I make some sort of a mistake or did this get swallowed? I'm anxious for what information I can get, particularly on PowerTerm which is going to turn itself off in a couple of weeks.

Payware!

--T

--Boundary_(ID_0zS5wr2K372pczABe1y/nw)
Content-type: message/rfc822
Content-disposition: inline

Received: from [10.240.3.214] (Forwarded-For: 66.114.69.214, [10.240.3.214])
by mstr3.srv.hcvlny.cv.net (mshttpd); Wed, 13 Dec 2006 11:56:26 +0000 (GMT)
Date: Wed, 13 Dec 2006 11:56:26 +0000 (GMT)
From: [email protected]
Subject: Re: LAT and KEA! (and others)
In-reply-to: <[email protected]>
To: Mark Crispin <[email protected]>
Cc: [email protected]
Message-id: <[email protected]>
MIME-version: 1.0
X-Mailer: Sun Java(tm) System Messenger Express 6.2-6.01 (built Apr 3 2006)
Content-type: text/plain; charset=us-ascii
Content-language: en
Content-transfer-encoding: 7BIT
Content-disposition: inline
X-Accept-Language: en
Priority: normal
References: <[email protected]>
<[email protected]>

I had some more updates about this that I wanted to report. A copy of
COMPAQ Pathworks/32 came up on eBay, so I bid on it and won. I got
around to installing it on my laptop and here is what I found:

1) The PowerTerm utility that comes with Pathworks can immediately
see any published service on Tops-20, but I can't connect to
anything. No usable error tracing or other help is given.

2) A network trace shows that Tops-20 seems to be detecting the
connection attempt and is sending the sign on banner. My version
of Ethereal can't really crack LAT packets. Does anything do
this? I didn't find that Tops-20 provides anything for trouble
shooting LAT, either, besides the OPR LCP submode. Is there
anything?

3) PowerTerm was able to IMMEDIATELY connect to my Linux box (which
is running latd). I haven't done any performance tests.

4) Kermit 95 doesn't talk to Pathworks or doesn't do anything useful.
Kermit can use use something called 'superlat', but I don't know
what that is.

5) The PowerTerm that was included on the Pathworks/32 CD-ROM is
payware. I don't really like it (I prefer PuTTY). Is there
anything else that can talk to LAT? Maybe it would be possible
to port llogin (part of Linux latd) to Windows. Or not ...

6) The Pathworks/32 DECnet file transfer utility didn't work,
either.

Has anybody anywhere gotten Tops-20 LAT to work with anything? When
was the last time this worked? Here is some speculation:

1) Maybe Digital/Compaq 'enhanced' LAT enough so that it no longer
works with Tops-20?

2) While the Tommy Timesharing hardware itself has two seperate
ethernet interfaces, eth0 is still shared between the 20 and the
host operating system.

3) My intention is to reconfigure Tommy Timesharing once it comes
back from the UP2LNG shutdown (a couple of weeks). Maybe I'll
have something more to report then.

================================================================

> Subject Re: LAT and KEA! (and others)
> From: Mark Crispin <[email protected]>
> Date: Friday, September 1, 2006 12:12 am
> To: Thomas DeBellis <[email protected]>
> Cc: TOPS-20 Hackers and Yackers <[email protected]>
>
> Almost certainly, you need to make the Ethernet address (MAC address)
> be one of the DECnet addresses.
>
> Lingling has a dedicated Ethernet interface for the TOPS-20 system,
> and I have set it to be a DECnet address. It involves some
> kludgery, as you can not change the MAC address when the interface
> is up, but klh10 won't talk to the interface unless it's up. So I
> ended up doing
>
> /sbin/ifconfig eth1 hw ether aa:00:04:00:01:04
> /sbin/ifconfig eth1 up
>
> in the Linux system startup script
>
> devdef ni0 564 ni20 dedic=true ifc=eth1
>
> in the klt20.ini file, and finally
>
> NODE PANDA 1.1
> DECNET ROUTER-ENDNODE
> ETHERNET 0 DECNET
>
> in the SYSTEM:7-1-CONFIG.CMD file.
>
> So far, so good; then I tried configuring Hsinghsing, which shares
> an interface with the UNIX end (Mac OS X) to have a DECnet MAC
> address. I spent quite a well fighting before I got it up and
> working, but ultimately Lingling and Hsinghsing never talked DECnet
> to each other. According to NCP, they sent their DECnet packets but
> never heard any DECnet packets. However, TCP/IP worked.
>
> I decided to give up until I could have another TOPS-20 system with
> a dedicated interface.
>
> -- Mark --

--Boundary_(ID_0zS5wr2K372pczABe1y/nw)--

14-Dec-2006 21:13:45-PST,8376;000000000000
Return-Path: <[email protected]>
Received: from pangtzu.panda.com ([206.124.149.117]) by lingling.panda.com with TCP/SMTP; Thu, 14 Dec 2006 21:09:58 -0800 (PST)
X-Return-Path: <[email protected]>
X-Received: from pop-scotia.atl.sa.earthlink.net ([207.69.195.65]) by lingling.panda.com with TCP/SMTP; Thu, 14 Dec 2006 18:58:58 -0800 (PST)
X-Received: from cpe-24-221-177-162.ca.sprintbbd.net ([24.221.177.162] helo=[204.238.239.104])
by pop-scotia.atl.sa.earthlink.net with esmtp (Exim 3.36 #1)
id 1Gv3Hb-0005Ts-00; Thu, 14 Dec 2006 21:58:47 -0500
In-Reply-To: <[email protected]>
References: <[email protected]> <[email protected]> <[email protected]> <[email protected]> <[email protected]> <[email protected]> <[email protected]> <[email protected]> <[email protected]>
Mime-Version: 1.0 (Apple Message framework v624)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <[email protected]>
Content-Transfer-Encoding: 7bit
Cc: "David F. Bacon" <[email protected]>,
[email protected]
X-Image-Url: http://www.goldenstategiftbaskets.com/minibasket.jpg
From: Carl Baltrunas <[email protected]>
Subject: Re: Tommy Timesharing joins the Tops-20 365 Club!
Date: Thu, 14 Dec 2006 18:58:42 -0800
To: [email protected]
X-Mailer: Apple Mail (2.624)
ReSent-Date: Thu, 14 Dec 2006 21:09:48 -0800 (PST)
ReSent-From: TOPS-20 List Moderator <[email protected]>
ReSent-To: TOPS-20 Distribution: ;
ReSent-Subject: Re: Tommy Timesharing joins the Tops-20 365 Club!
ReSent-Message-ID: <[email protected]>

On Dec 13, 2006, at 2:39 AM, [email protected] wrote:
> Somewhat in contrast to what MRC says, even in the 1980's, Tops-20
> would stand up to a lot of usage by a 'small' group of people. One
> summer while porting our monitor, Exec and Galaxy changes to version
> 6, I cracked over 400 minutes of CPU time in one week. Keng was
> pretty impressed with this. We did this on CU20C and stayed up over a
> month and a half until Warren (the FE) yelled at us to do a PM. I
> think the rest of you user services people were over on CU20D which is
> where we did our actual monitor testing.
>
> So yes, I'm doing a lot of hacking and getting attacked a good amount
> (over 200 script-kiddie penetration attempts in past four days), but
> things only get unstable when you really, REALLY crank up the load and
> users. My load rarely crosses 4 ... How to get back to the 1980's?
> Well, one thing you can do is kick off a bunch of simultaneous batch
> jobs.
>
> When I first got Tommy Timesharing, I did some load testing by
> assembling GLXLIB and then doing a simultaneous assembly of Quasar,
> OPR, ORION, LPTSPL, BATCON, MOUNTR and the rest of the Galaxy clan
> while also doing a full system backup.
>
> Tommy Timesharing nearly ground to a complete halt. The load cleared
> 40. I started getting boatloads of FLKTIM and other bug thingies on
> the CTY. The CFS code started complaining about losing shared devices
> and then the file service code started reporting file errors. Sound
> familiar? It was just like the good old days on CU20A (before the
> memory upgrade)!

Prior to getting our pair of XKL TOAD-1s, the majority of my experience
with TOPS-20 or TENEX was a guest account, or a free-login by virtue
of being in front of a physical terminal on a visit to Stanford LOTS.
I was
much more at home with TOPS-10, and as a user of ITS by virtue of
guest accounts on the ARPAnet from the mid '70s. Then the '80s had
me neck deep working on TYMCOM-X and reworking DEC CUSPS to
run on a system with AUXCALs instead of TRMOP.s or TTCALLs, and
our own variant of GETTABs since we implemented things differently
than DEC did and often before. Joe Smith and I were responsible for
creating STOPCDs in our OS, rather than require an OS person to read
a crash dump to find out why it went down. TYMCOM-X forked off
of DEC TOPS-10 at the 5.02 version of the monitor, and COMPIL was
still called RPG, with original comments from William F Wehir (WFW).

Great fun. It was the first time that I remember ever falling asleep
trying to read a technical manual. Really! Somewhere between
page 5 and 6. I never read any more user guides.

Anyway, that said, I got involved with TOPS-20 when we were looking
at buying 2 XKLs to replace 2 KL-10s that were costing us $30,000
on the books each per month to maintain. These systems, running
TYMCOM-X which had a job capacity of 127, ran a FORTRAN-IV
program with the 1022 database package to track trouble tickets.

We used an ancient F40, which IIRC predates FOROTS and any
shared high segments. We had .SHR files, but since they were all
read-only, we swapped (cough, paged) directly off the SHR file and
not in separate swapping space. (TYMCOM-X used any unused
disk pages as swap space, so a page was marked as in memory,
in a file, or both. If we ran low on disk space, and tried to run too
many processes, we ran out of memory.)

It took me a month to port the program to FORTRAN-10 and thanks
to Ralph or Dick at XKL we got 1022 which was already on their
machine, toad.xkl.com, up and running as a proof of concept.

We installed the sytems, and then we found the limits.

Then we added users. We kept running into TOPS-20's job limit
and between killing off idle jobs, and monitoring the load level
which was rarely below 10, we had to make sure we didn't go
above 25 or it would just keep climbing, requiring a reboot, some
1022 database management, and then opening up the system
for users again.

So, creating too many processes was not difficult, and hanging
the system, or making it utterly useless was possible, with 60-80
users all doing database queries, running reports, and statusing
(is that a word?) tickets to get them closed or out of their queue.
Everyone, except for the standard base operator jobs, and one
or two people like me, logged in to monitor things, were running
the same application. Due to issues with 1022, we had to take
the server down once a day for 1022 database updates which
took about an hour, and backups were done daily and weekly.

We had the second server up with a batch job that created a
transaction log of everything new, every so many hours and
ftp'd the data to the backup host via 2 of the 4-port ethernet
links, 3 of which were host to host for more bandwidth. So, in
case of a catastrophic failure, we eventually were backed up
to an hour behind.

Not bad on a TOPS-20 system with a 1022 database that was
up nearly 24 hours a day, 7 days a week for customer and
support users worldwide. In fact, picking an hour or two on
a weekly basis for scheduled downtime was not easy. On
Saturday around 4 PM we could manage an hour or so, but
anything more and we ran into problems with Australian or
Japanese users.

We offset the user load by an ingenious product that Dick
Helliwell made available, 'httpd' version 1.3. I wrote some
cgi-bin programs in Fortran-10 using the 1022 Fortran
library routines, and created a read-only web access form
so users who only needed to login to look for tickets to
work on, could do so without logging in.

We had only one problem, which was that ASCIZ strings
did not work too well when the httpd process attempted to
send them to users with browsers written in C. The data
was actually sent from the XKL in all but one or two cases,
but most browsers choked on the nulls, and didn't paint the
screen too well. A once over of all the code to make sure
everything was padded with spaces, or was a multiple
of 5 characters solved it. FORTRAN by default filled with
spaces, but the interface routines didn't.

We shut the systems down when Worldcom forced all the
users to use a different ticket system. And that's when one
of the servers found a home in my garage.

-carl

>
> By then however, I had gotten cold feet, torpedoed everything,
> rebooted and had done a CHKDSK. Didn't have to worry about 70 PACX
> users trying to jump back on, either ...

18-Dec-2006 23:34:55-PST,1892;000000000000
Return-Path: <[email protected]>
Received: from pangtzu.panda.com ([206.124.149.117]) by Lingling.Panda.COM with TCP/SMTP; Mon, 18 Dec 2006 23:28:52 -0800 (PST)
Mail-From: MRC created at 18-Dec-2006 22:31:38
Date: Mon, 18 Dec 2006 22:31:38 -0800 (PST)
From: Mark Crispin <[email protected]>
Subject: Lingling is back up
To: [email protected]
Pithy-Thought: TOPS-20 was a great improvement over its successors
Message-ID: <[email protected]>
ReSent-Date: Mon, 18 Dec 2006 23:28:45 -0800 (PST)
ReSent-From: TOPS-20 List Moderator <[email protected]>
ReSent-To: TOPS-20 Distribution: ;
ReSent-Subject: Lingling is back up
ReSent-Message-ID: <[email protected]>

A series of three windstorms from December 11 to December 14 hit
the Puget Sound area. Each one caused a power outage; the third
windstorm on December 14 being the most severe. Power was out
here from the evening of December 14 until the evening of
December 18, nearly 4 full days.

In addition to the generalized problems with trees down on power
lines, my neighborhood was hit with a fault in the underground
wiring, so there was some question as to whether power would come
back this week at all. Fortunately, Puget Sound Energy was able
to find and resolve the problem without having to bring in a Cat
to dig up the lines.

Although I had generator power, it's not clean enough for
computer use, and as my ISP was also out, my only access was by
dialup from my laptop. Talk about taking a trip down memory
lane...

Anyway, Lingling is back, and with it the TOPS-20 list. But so
much for any chance of Lingling hitting an UP2LNG...

I just hope that it's a while before the next windstorm. We're
just starting windstorm season....

-- Mark --

TOPS-20: a great improvement over its successors
-------

19-Dec-2006 17:26:18-PST,3247;000000000000
Return-Path: <[email protected]>
Received: from pangtzu.panda.com ([206.124.149.117]) by Lingling.Panda.COM with TCP/SMTP; Tue, 19 Dec 2006 17:19:49 -0800 (PST)
X-Return-Path: <[email protected]>
X-Received: from mta1.srv.hcvlny.cv.net ([167.206.4.196]) by Lingling.Panda.COM with TCP/SMTP; Tue, 19 Dec 2006 08:52:59 -0800 (PST)
X-Received: from optonline.net (hamstr3.srv.hcvlny.cv.net [167.206.5.10])
by mta1.srv.hcvlny.cv.net
(Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006))
with ESMTP id <[email protected]> for
[email protected]; Tue, 19 Dec 2006 11:52:54 -0500 (EST)
X-Received: from [10.240.3.196] (Forwarded-For: 66.114.69.214, [10.240.3.196])
by mstr3.srv.hcvlny.cv.net (mshttpd); Tue, 19 Dec 2006 16:52:53 +0000 (GMT)
Date: Tue, 19 Dec 2006 16:52:53 +0000 (GMT)
From: [email protected]
Subject: SYSREF sleeping aids
In-reply-to: <[email protected]>
To: [email protected]
Message-id: <[email protected]>
MIME-version: 1.0
X-Mailer: Sun Java(tm) System Messenger Express 6.2-6.01 (built Apr 3 2006)
Content-type: text/plain; charset=us-ascii
Content-language: en
Content-transfer-encoding: 7BIT
Content-disposition: inline
X-Accept-Language: en
Priority: normal
References: <[email protected]>
<[email protected]> <[email protected]>
<[email protected]> <[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
ReSent-Date: Tue, 19 Dec 2006 17:19:42 -0800 (PST)
ReSent-From: TOPS-20 List Moderator <[email protected]>
ReSent-To: TOPS-20 Distribution: ;
ReSent-Subject: SYSREF sleeping aids
ReSent-Message-ID: <[email protected]>

From: Carl Baltrunas

> Great fun. It was the first time that I remember ever falling
> asleep trying to read a technical manual. Really! Somewhere
> between page 5 and 6. I never read any more user guides.

Whaaay back in High School and College, I was the proud owner of my
very own copy of the 1973 edition of the DECsystem-10 Assembly
Language Handbook (the orange 'Phonebook'). It was typically kept on
the night table right next to my bed.

Why?

Whenever I couldn't get to sleep (say because I was zorched from a
moby hacking session, but still amped out on Mountain Dew), I'd flip
open SYSREF and start reading; I usually fell asleep right around the
half word instruction descriptions.

It was far more efficacious than counting sheep and undoubtedly more
accurate. However, what is disturbing to me now is that reading
SYSREF is no longer putting me to sleep! I need to review it to
remember lots of stuff for EFTPSR--but it used to put me right out for
ANY reason.

Is this some sort of an age thing? Now Gorin's assembler book, that
was different. Very readable! I covet mine and in moments of
weakness think impure thoughts about it.

19-Dec-2006 17:31:59-PST,1562;000000000000
Return-Path: <[email protected]>
Received: from pangtzu.panda.com ([206.124.149.117]) by Lingling.Panda.COM with TCP/SMTP; Tue, 19 Dec 2006 17:20:04 -0800 (PST)
X-Return-Path: <[email protected]>
X-Received: from TheWorld.com (pcls5.std.com [192.74.137.145]) by Lingling.Panda.COM with TCP/SMTP; Tue, 19 Dec 2006 16:50:27 -0800 (PST)
X-Received: from shell.TheWorld.com ([email protected] [192.74.137.71])
by TheWorld.com (8.13.6/8.13.6) with ESMTP id kBK0j00Y013548;
Tue, 19 Dec 2006 19:45:02 -0500
X-Received: from shell01.TheWorld.com (localhost [127.0.0.1])
by shell.TheWorld.com (8.13.6/8.12.8) with ESMTP id kBK0SQXh3349131;
Tue, 19 Dec 2006 19:28:26 -0500 (EST)
X-Received: (from jsol@localhost)
by shell01.TheWorld.com (8.13.6/8.13.6/Submit) id kBK0SQvi3271230;
Tue, 19 Dec 2006 19:28:26 -0500 (EST)
Date: Tue, 19 Dec 2006 19:28:26 -0500 (EST)
Message-Id: <[email protected]>
From: "Jonathan A. Solomon" <[email protected]>
To: [email protected], [email protected]
Subject: weather..
X-Virus-Scanned: ClamAV 0.88.4/2358/Tue Dec 19 11:15:46 2006 on pcls5.std.com
X-Virus-Status: Clean
ReSent-Date: Tue, 19 Dec 2006 17:19:58 -0800 (PST)
ReSent-From: TOPS-20 List Moderator <[email protected]>
ReSent-To: TOPS-20 Distribution: ;
ReSent-Subject: weather..
ReSent-Message-ID: <[email protected]>

Yeah, my tv news says that your area is going to be hit even
harder... just let the list about the shorter.

--jsol

19-Dec-2006 17:39:37-PST,1756;000000000000
Return-Path: <[email protected]>
Received: from pangtzu.panda.com ([206.124.149.117]) by Lingling.Panda.COM with TCP/SMTP; Tue, 19 Dec 2006 17:33:39 -0800 (PST)
X-Return-Path: <[email protected]>
X-Received: from pangtzu.panda.com ([206.124.149.117]) by Lingling.Panda.COM with TCP/SMTP; Tue, 19 Dec 2006 17:27:46 -0800 (PST)
Date: Tue, 19 Dec 2006 17:27:42 -0800 (PST)
From: TOPS-20 List Moderator <[email protected]>
Sender: [email protected]
To: "Jonathan A. Solomon" <[email protected]>
cc: [email protected]
Subject: Re: weather..
In-Reply-To: <[email protected]>
Message-ID: <[email protected]>
References: <[email protected]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
ReSent-Date: Tue, 19 Dec 2006 17:33:22 -0800 (PST)
ReSent-From: TOPS-20 List Moderator <[email protected]>
ReSent-To: TOPS-20 Distribution: ;
ReSent-Subject: Re: weather..
ReSent-Message-ID: <[email protected]>

On Tue, 19 Dec 2006, Jonathan A. Solomon wrote:
> Yeah, my tv news says that your area is going to be hit even
> harder... just let the list about the shorter.

That's news to me. A mild storm is forecast to hit on Wednesday, but
winds are only predicted to be 10-20 MPH with up to 30 MPH in outlying
areas. That's completely normal for this area this time of year, and
isn't even gale force.

I guess it might be the straw that broke the camel's back for a tree that
is already on its last legs.

Have you heard of something else?

-- Mark --

http://panda.com/tops-20
TOPS-20: a great improvement over its successors

19-Dec-2006 19:25:50-PST,3146;000000000000
Return-Path: <[email protected]>
Received: from pangtzu.panda.com ([206.124.149.117]) by Lingling.Panda.COM with TCP/SMTP; Tue, 19 Dec 2006 19:19:40 -0800 (PST)
X-Return-Path: <[email protected]>
X-Received: from sdf.lonestar.org (mx.freeshell.ORG [192.94.73.18]) by Lingling.Panda.COM with TCP/SMTP; Tue, 19 Dec 2006 18:06:35 -0800 (PST)
X-Received: from [10.0.0.4] (c-67-168-47-156.hsd1.wa.comcast.net [67.168.47.156])
(authenticated (0 bits))
by sdf.lonestar.org (8.13.5.20060308/8.13.8) with ESMTP id kBK26NR9028060;
Wed, 20 Dec 2006 02:06:24 GMT
In-Reply-To: <[email protected]>
References: <[email protected]> <[email protected]>
Mime-Version: 1.0 (Apple Message framework v752.2)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <[email protected]>
Cc: "Jonathan A. Solomon" <[email protected]>, [email protected]
Content-Transfer-Encoding: 7bit
From: Stephen Jones <[email protected]>
Subject: Re: weather.. is absolutely normal
Date: Tue, 19 Dec 2006 18:06:23 -0800
To: TOPS-20 List Moderator <[email protected]>
X-Mailer: Apple Mail (2.752.2)
ReSent-Date: Tue, 19 Dec 2006 19:19:33 -0800 (PST)
ReSent-From: TOPS-20 List Moderator <[email protected]>
ReSent-To: TOPS-20 Distribution: ;
ReSent-Subject: Re: weather.. is absolutely normal
ReSent-Message-ID: <[email protected]>

On Dec 19, 2006, at 5:27 PM, TOPS-20 List Moderator wrote:

> On Tue, 19 Dec 2006, Jonathan A. Solomon wrote:
>> Yeah, my tv news says that your area is going to be hit even
>> harder... just let the list about the shorter.
>
> That's news to me. A mild storm is forecast to hit on Wednesday,
> but winds are only predicted to be 10-20 MPH with up to 30 MPH in
> outlying areas. That's completely normal for this area this time
> of year, and isn't even gale force.

Thats all I've heard Mark. I went to Factoria today to go to the
office and there was a huge explosion
and the diesel generators kicked in. Apparently a substation blew.
I don't think the small storm
coming through Wednesday is going to really effect us at all except
for the fact that there are still
loads of half fallen trees that are being supported by power lines.
I saw a lot of those on the eastside.
Fortunately for us we've had power since Thursday night, but I have
friends who are still without power
in areas like Sultan, Carnation, Maple Valley and Woodinville. PSE
of course, but then they've got the
most green to deal with for sure. I wasn't too worried about you,
MRC, because you're pretty self sufficient
and I'm sure survival savvy... not like our newbie residents from the
3rd world who keep passing out from
running charcoal grills in their apartments!! I just can't get over
that...

Now hopefully the Californians and Arizonans will see how miserable
and dreadful this place can be and
get packing. ;-) More rain is coming and its perfectly normal.

19-Dec-2006 20:02:41-PST,2287;000000000000
Return-Path: <[email protected]>
Received: from pangtzu.panda.com ([206.124.149.117]) by Lingling.Panda.COM with TCP/SMTP; Tue, 19 Dec 2006 19:56:58 -0800 (PST)
X-Return-Path: <[email protected]>
X-Received: from zipcon.net ([209.221.136.5]) by Lingling.Panda.COM with TCP/SMTP; Tue, 19 Dec 2006 19:40:53 -0800 (PST)
X-Received: (qmail 12407 invoked by uid 4824); 20 Dec 2006 03:40:50 -0000
Message-ID: <[email protected]>
Date: 19 Dec 2006 19:40:50 -0800
From: kkt <[email protected]>
To: [email protected]
CC: [email protected], TOPS-20 Distribution: ;, [email protected]
In-reply-to: <[email protected]> (message
from TOPS-20 List Moderator on Tue, 19 Dec 2006 17:27:42 -0800 (PST))
Subject: Re: weather..
References: <[email protected]> <[email protected]>
ReSent-Date: Tue, 19 Dec 2006 19:56:51 -0800 (PST)
ReSent-From: TOPS-20 List Moderator <[email protected]>
ReSent-To: TOPS-20 Distribution: ;
ReSent-Subject: Re: weather..
ReSent-Message-ID: <[email protected]>

Date: Tue, 19 Dec 2006 17:27:42 -0800 (PST)
From: TOPS-20 List Moderator <[email protected]>
Sender: [email protected]
cc: [email protected]
ReSent-From: TOPS-20 List Moderator <[email protected]>
ReSent-To: TOPS-20 Distribution: ;
ReSent-Subject: Re: weather..

On Tue, 19 Dec 2006, Jonathan A. Solomon wrote:
> Yeah, my tv news says that your area is going to be hit even
> harder... just let the list about the shorter.

That's news to me. A mild storm is forecast to hit on Wednesday, but
winds are only predicted to be 10-20 MPH with up to 30 MPH in outlying
areas. That's completely normal for this area this time of year, and
isn't even gale force.

I guess it might be the straw that broke the camel's back for a tree that
is already on its last legs.

In my neighborhood, there are several fallen trees that are leaning on
power lines. Rather than removing the tree, City Light has just
patched around it. I'd be very surprised if there weren't more power
failures in our future.

-- Patrick

19-Dec-2006 20:08:18-PST,3977;000000000000
Return-Path: <[email protected]>
Received: from pangtzu.panda.com ([206.124.149.117]) by Lingling.Panda.COM with TCP/SMTP; Tue, 19 Dec 2006 19:58:01 -0800 (PST)
X-Return-Path: <[email protected]>
X-Received: from smtpout.mac.com ([17.250.248.183]) by Lingling.Panda.COM with TCP/SMTP; Tue, 19 Dec 2006 19:40:10 -0800 (PST)
X-Received: from mac.com (smtpin05-en2 [10.13.10.150])
by smtpout.mac.com (Xserve/8.12.11/smtpout13/MantshX 4.0) with ESMTP id kBK3e19d002870;
Tue, 19 Dec 2006 19:40:02 -0800 (PST)
X-Received: from [192.168.1.52] (c-24-147-40-233.hsd1.nh.comcast.net [24.147.40.233])
(authenticated bits=0)
by mac.com (Xserve/smtpin05/MantshX 4.0) with ESMTP id kBK3dtF1026006;
Tue, 19 Dec 2006 19:39:59 -0800 (PST)
Mime-Version: 1.0
Message-Id: <p06230900c1ae607a63dc@[192.168.1.52]>
In-Reply-To: <[email protected]>
References: <[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
Date: Tue, 19 Dec 2006 22:40:02 -0500
To: [email protected], [email protected]
From: John Francini <[email protected]>
Subject: Re: SYSREF sleeping aids
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Brightmail-Tracker: AAAAAA==
X-Brightmail-scanned: yes
ReSent-Date: Tue, 19 Dec 2006 19:57:53 -0800 (PST)
ReSent-From: TOPS-20 List Moderator <[email protected]>
ReSent-To: TOPS-20 Distribution: ;
ReSent-Subject: Re: SYSREF sleeping aids
ReSent-Message-ID: <[email protected]>

For me it was the TOPS-10 6.03 Monitor Calls manual that I kept by my
bed in college. I really did manage to get through it from beginning
to end, but it took (I think) an entire school year of reading a few
pages and falling asleep.

You also know you've been up too late hacking away at a software
project when you'd dream that you had to log in to your digital alarm
clock in order to stop it from going off, and then you'd wake up to
the darn thing beeping away much like an LA-36 being sent 1,000 ^G's.

j

At 16:52 +0000 12/19/06, [email protected] wrote:
>From: Carl Baltrunas
>
>> Great fun. It was the first time that I remember ever falling
>> asleep trying to read a technical manual. Really! Somewhere
>> between page 5 and 6. I never read any more user guides.
>
>Whaaay back in High School and College, I was the proud owner of my
>very own copy of the 1973 edition of the DECsystem-10 Assembly
>Language Handbook (the orange 'Phonebook'). It was typically kept on
>the night table right next to my bed.
>
>Why?
>
>Whenever I couldn't get to sleep (say because I was zorched from a
>moby hacking session, but still amped out on Mountain Dew), I'd flip
>open SYSREF and start reading; I usually fell asleep right around the
>half word instruction descriptions.
>
>It was far more efficacious than counting sheep and undoubtedly more
>accurate. However, what is disturbing to me now is that reading
>SYSREF is no longer putting me to sleep! I need to review it to
>remember lots of stuff for EFTPSR--but it used to put me right out for
>ANY reason.
>
>Is this some sort of an age thing? Now Gorin's assembler book, that
>was different. Very readable! I covet mine and in moments of
>weakness think impure thoughts about it.

--
John Francini, [email protected]

"The journey is more important than the destination-that's part of
life. If you only live for getting to the end, you're almost always
disappointed." -Donald Knuth

19-Dec-2006 20:29:28-PST,2815;000000000000
Return-Path: <[email protected]>
Received: from pangtzu.panda.com ([206.124.149.117]) by Lingling.Panda.COM with TCP/SMTP; Tue, 19 Dec 2006 20:23:27 -0800 (PST)
X-Return-Path: <[email protected]>
X-Received: from pangtzu.panda.com ([206.124.149.117]) by Lingling.Panda.COM with TCP/SMTP; Tue, 19 Dec 2006 20:22:12 -0800 (PST)
Date: Tue, 19 Dec 2006 20:22:08 -0800 (PST)
From: Mark Crispin <[email protected]>
Sender: [email protected]
To: Stephen Jones <[email protected]>
cc: TOPS-20 Hackers and Yackers <[email protected]>
Subject: Re: weather.. is absolutely normal
In-Reply-To: <[email protected]>
Message-ID: <[email protected]>
References: <[email protected]>
<[email protected]>
<[email protected]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
ReSent-Date: Tue, 19 Dec 2006 20:23:21 -0800 (PST)
ReSent-From: TOPS-20 List Moderator <[email protected]>
ReSent-To: TOPS-20 Distribution: ;
ReSent-Subject: Re: weather.. is absolutely normal
ReSent-Message-ID: <[email protected]>

On Tue, 19 Dec 2006, Stephen Jones wrote:
> Fortunately for us we've had power since Thursday night, but I have
> friends who are still without power in areas like Sultan, Carnation,
> Maple Valley and Woodinville.

My boss at UW lives in Carnation and he's still without power. Everybody
else on the hill got power 2AM Sunday morning (as did my neighborhood
until 4:47AM...) but something blew underground and it wasn't until Monday
night that they got us back up.

Underground electric power lines sound like a really good idea for
reliability, but they fail too. Kinda neat seeing soil turned to glass...

> I wasn't too worried about you, MRC, because you're pretty self
> sufficient and I'm sure survival savvy... not like our newbie residents
> from the 3rd world who keep passing out from running charcoal grills in
> their apartments!! I just can't get over that...

Don't forget the fools who were running generators indoors and died due to
carbon monoxide. These weren't immigrants; they were clueless urbanites
who bought a generator after the outage hit and didn't realize that it's
supposed to be outdoors.

CO is not your friend!

> Now hopefully the Californians and Arizonans will see how miserable and
> dreadful this place can be and get packing. ;-) More rain is coming and
> its perfectly normal.

A commonly held, but sadly too-optimistic a desire. I fear that they are
here to stay.

-- Mark --

http://panda.com/tops-20
TOPS-20: a great improvement over its successors

20-Dec-2006 10:53:27-PST,2851;000000000000
Return-Path: <[email protected]>
Received: from pangtzu.panda.com ([206.124.149.117]) by lingling.panda.com with TCP/SMTP; Wed, 20 Dec 2006 10:46:22 -0800 (PST)
X-Return-Path: <[email protected]>
X-Received: from mta2.srv.hcvlny.cv.net ([167.206.4.197]) by lingling.panda.com with TCP/SMTP; Wed, 20 Dec 2006 01:21:42 -0800 (PST)
X-Received: from optonline.net (hamstr3.srv.hcvlny.cv.net [167.206.5.10])
by mta2.srv.hcvlny.cv.net
(Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006))
with ESMTP id <[email protected]> for
[email protected]; Wed, 20 Dec 2006 04:21:37 -0500 (EST)
X-Received: from [10.240.3.201] (Forwarded-For: 66.114.69.214, [10.240.3.201])
by mstr3.srv.hcvlny.cv.net (mshttpd); Wed, 20 Dec 2006 09:21:37 +0000 (GMT)
Date: Wed, 20 Dec 2006 09:21:37 +0000 (GMT)
From: [email protected]
Subject: TENEX FTP client sources?
In-reply-to: <[email protected]>
To: [email protected]
Message-id: <[email protected]>
MIME-version: 1.0
X-Mailer: Sun Java(tm) System Messenger Express 6.2-6.01 (built Apr 3 2006)
Content-type: text/plain; charset=us-ascii
Content-language: en
Content-transfer-encoding: 7BIT
Content-disposition: inline
X-Accept-Language: en
Priority: normal
References: <[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
ReSent-Date: Wed, 20 Dec 2006 10:46:15 -0800 (PST)
ReSent-From: TOPS-20 List Moderator <[email protected]>
ReSent-To: TOPS-20 Distribution: ;
ReSent-Subject: TENEX FTP client sources?
ReSent-Message-ID: <[email protected]>

Does anybody know where I can find the sources for the TENEX FTP
client? I'd like to use these for 36 bit regression analysis (not
testing).

I have sources to the ITS FTP server and client and these have helped
me catch a couple of misconceptions. Regression testing against ITS
has also been fruitful.

The 'standard' Tops-20 FTP server that is included in the PANDA
distribution will still run on TENEX (actually, that's "I am pretty
sure that it will run under TENEX"). The FTP client is much newer and
does not appear to have any TENEX specific code.

The TENEX FTP client should also implement paged file structures (STRU
P), which I'm currently working on. I'm hoping that, when comparing
this source code against the 'new' FTP client and the current FTP
server, any questions that I have might be more easily resolved.

Of course, I'd also be interested in sources for any other PDP-10
based FTP client and/or server including anything that ever ran on
Tops-10 (any flavor) and WAITS.

20-Dec-2006 11:26:32-PST,1741;000000000000
Return-Path: <[email protected]>
Received: from pangtzu.panda.com ([206.124.149.117]) by lingling.panda.com with TCP/SMTP; Wed, 20 Dec 2006 11:20:34 -0800 (PST)
X-Return-Path: <[email protected]>
X-Received: from pangtzu.panda.com ([206.124.149.117]) by lingling.panda.com with TCP/SMTP; Wed, 20 Dec 2006 10:47:36 -0800 (PST)
Date: Wed, 20 Dec 2006 10:47:32 -0800 (PST)
From: TOPS-20 List Moderator <[email protected]>
Sender: [email protected]
To: [email protected]
cc: [email protected]
Subject: Re: TENEX FTP client sources?
In-Reply-To: <[email protected]>
Message-ID: <[email protected]>
References: <[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
ReSent-Date: Wed, 20 Dec 2006 11:20:28 -0800 (PST)
ReSent-From: TOPS-20 List Moderator <[email protected]>
ReSent-To: TOPS-20 Distribution: ;
ReSent-Subject: Re: TENEX FTP client sources?
ReSent-Message-ID: <[email protected]>

On Wed, 20 Dec 2006, [email protected] wrote:
> Does anybody know where I can find the sources for the TENEX FTP
> client? I'd like to use these for 36 bit regression analysis (not
> testing).

The contents of <FTP.OLD> in the Panda distribution are the sources to the
Tenex FTP client, and SYS:OLDFTP.EXE is its binary.

-- Mark --

http://panda.com/tops-20
TOPS-20: a great improvement over its successors

20-Dec-2006 15:17:13-PST,1614;000000000000
Return-Path: <[email protected]>
Received: from pangtzu.panda.com ([206.124.149.117]) by lingling.panda.com with TCP/SMTP; Wed, 20 Dec 2006 15:11:18 -0800 (PST)
X-Return-Path: <[email protected]>
X-Received: from TheWorld.com (pcls5.std.com [192.74.137.145]) by lingling.panda.com with TCP/SMTP; Wed, 20 Dec 2006 13:26:34 -0800 (PST)
X-Received: from shell.TheWorld.com ([email protected] [192.74.137.71])
by TheWorld.com (8.13.6/8.13.6) with ESMTP id kBKLQ0RV006865
for <[email protected]>; Wed, 20 Dec 2006 16:26:03 -0500
X-Received: from shell01.TheWorld.com (localhost.theworld.com [127.0.0.1])
by shell.TheWorld.com (8.13.6/8.12.8) with ESMTP id kBKLKqR53445632
for <[email protected]>; Wed, 20 Dec 2006 16:20:53 -0500 (EST)
X-Received: (from jsol@localhost)
by shell01.TheWorld.com (8.13.6/8.13.6/Submit) id kBKLKqTp3416309;
Wed, 20 Dec 2006 16:20:52 -0500 (EST)
Date: Wed, 20 Dec 2006 16:20:52 -0500 (EST)
Message-Id: <[email protected]>
From: "Jonathan A. Solomon" <[email protected]>
To: [email protected]
Subject: happy DEC-20 day..
X-Virus-Scanned: ClamAV version 0.88.4, clamav-milter version 0.88.4 on pcls5.std.com
X-Virus-Status: Clean
ReSent-Date: Wed, 20 Dec 2006 15:11:10 -0800 (PST)
ReSent-From: TOPS-20 List Moderator <[email protected]>
ReSent-To: TOPS-20 Distribution: ;
ReSent-Subject: happy DEC-20 day..
ReSent-Message-ID: <[email protected]>

I am surprised that someone else hasn't said that.

I know I forgot DEC-10 day.

--jsol

20-Dec-2006 17:55:01-PST,4026;000000000000
Return-Path: <[email protected]>
Received: from pangtzu.panda.com ([206.124.149.117]) by lingling.panda.com with TCP/SMTP; Wed, 20 Dec 2006 17:49:09 -0800 (PST)
X-Return-Path: <[email protected]>
X-Received: from mta2.srv.hcvlny.cv.net ([167.206.4.197]) by lingling.panda.com with TCP/SMTP; Wed, 20 Dec 2006 15:54:04 -0800 (PST)
X-Received: from optonline.net (hamstr3.srv.hcvlny.cv.net [167.206.5.10])
by mta2.srv.hcvlny.cv.net
(Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006))
with ESMTP id <[email protected]> for
[email protected]; Wed, 20 Dec 2006 18:53:59 -0500 (EST)
X-Received: from [10.240.3.198] (Forwarded-For: 66.114.69.214, [10.240.3.198])
by mstr3.srv.hcvlny.cv.net (mshttpd); Wed, 20 Dec 2006 23:53:58 +0000 (GMT)
Date: Wed, 20 Dec 2006 23:53:58 +0000 (GMT)
From: [email protected]
Subject: Re: TENEX FTP client sources?
In-reply-to: <[email protected]>
To: John Wilson <[email protected]>
Cc: [email protected]
Message-id: <[email protected]>
MIME-version: 1.0
X-Mailer: Sun Java(tm) System Messenger Express 6.2-6.01 (built Apr 3 2006)
Content-type: text/plain; charset=us-ascii
Content-language: en
Content-transfer-encoding: 7BIT
Content-disposition: inline
X-Accept-Language: en
Priority: normal
References: <[email protected]>
ReSent-Date: Wed, 20 Dec 2006 17:49:03 -0800 (PST)
ReSent-From: TOPS-20 List Moderator <[email protected]>
ReSent-To: TOPS-20 Distribution: ;
ReSent-Subject: Re: TENEX FTP client sources?
ReSent-Message-ID: <[email protected]>

> John Wilson <[email protected]>
>
> It could take me quite a while to find it (I've moved since the last
> time I saw it), but somewhere I have a hardcopy listing of the FTP
> client from MIT-OZ, which I believe was written from scratch by GZ
> (um, Gail Zacharias I think?) but maybe I'm mistaken and it was just
> a local hack of some standard version. Worth looking for? It might
> not implement the more exotic 36-bittish modes though, I forget.

Yes, these sources are most definately worth looking for, even if they
are local hacks, because a bunch of stuff that was implemented for FTP
servers wasn't exactly documented. There's also some leftover cruft
from RFC765 that is of interest (sometimes to make sure it's avoided
and to know why--MLFL, for example).

Additionally, RFC959 wasn't 100% specific about saying how certain
things should have been done nor saying that they had to be done in a
particular way (I.E., MUST and SHOULD). The 'suggested' responses in
the RFC have been a particular bane to me. Thus far, any 'suggestion'
has categorically resulted in NOBODY doing the same thing. If I ever
do an RFC (which I might do for the TYPE L7/ASCII speed increase), I'm
going to make REALLY SURE that there are little or no 'suggestions'.

When I'm into TVFS mode, I have no problem seeing what a UNIX system
does and faking that, no matter how brain dwamaged I may think it may
be. Actually, that's not exactly true, EPRT has managed to come up
with such a convoluted syntax that not even COMND% can fully parse it.
LPRT (see next letter) is a close second, but is difficult, not
impossible.

However, my main initial release goal is to make sure as I possibly
can than I can talk to another 36 bit machine exactly as previously on
all platforms. Reviewing different sources has been quite
instructive. So, yes, even a hard copy print out of FTP sources
(server or client) would be of value.

The local MIT-OZ, MIT-EECS and MIT-XX DECSYSTEM-20's are of particular
interest because a lot of very nice ideas got tried out there. Part
of architecting the extended mode FTP server for additional features
(additional protocols, UTF-9 and the like) has been helped by looking
at how the Standford FTP client does Chaos, etc. You never know what
kind of tidbits I might run across ...

20-Dec-2006 19:33:21-PST,4180;000000000000
Return-Path: <[email protected]>
Received: from pangtzu.panda.com ([206.124.149.117]) by lingling.panda.com with TCP/SMTP; Wed, 20 Dec 2006 19:27:16 -0800 (PST)
X-Return-Path: <[email protected]>
X-Received: from mta1.srv.hcvlny.cv.net ([167.206.4.196]) by lingling.panda.com with TCP/SMTP; Wed, 20 Dec 2006 18:36:39 -0800 (PST)
X-Received: from optonline.net (hamstr3.srv.hcvlny.cv.net [167.206.5.10])
by mta1.srv.hcvlny.cv.net
(Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006))
with ESMTP id <[email protected]> for
[email protected]; Wed, 20 Dec 2006 21:36:35 -0500 (EST)
X-Received: from [10.240.3.198] (Forwarded-For: 66.114.69.214, [10.240.3.198])
by mstr3.srv.hcvlny.cv.net (mshttpd); Thu, 21 Dec 2006 02:36:34 +0000 (GMT)
Date: Thu, 21 Dec 2006 02:36:34 +0000 (GMT)
From: [email protected]
Subject: Tops-20 extended mode FTP server update
In-reply-to: <[email protected]>
To: [email protected]
Message-id: <[email protected]>
MIME-version: 1.0
X-Mailer: Sun Java(tm) System Messenger Express 6.2-6.01 (built Apr 3 2006)
Content-type: text/plain; charset=us-ascii
Content-language: en
Content-transfer-encoding: 7BIT
Content-disposition: inline
X-Accept-Language: en
Priority: normal
References: <[email protected]>
<[email protected]>
ReSent-Date: Wed, 20 Dec 2006 19:27:09 -0800 (PST)
ReSent-From: TOPS-20 List Moderator <[email protected]>
ReSent-To: TOPS-20 Distribution: ;
ReSent-Subject: Tops-20 extended mode FTP server update
ReSent-Message-ID: <[email protected]>

Summary:

Steady progress hampered by many attacks.

Details:

1) Fix a bug in third party host name resolution error handling.

2) Allow unrestricted passive data port connection. Fixes a flaw in
my third party data transfer code that got tickled by OS/2 PM-FTP
(see below)

3) Fix a bug in the ANONYMOUS sub-directory access security policy
code.

4) More fixes to handle DOS attacks and sign off wedging!!!!! I'm
probably going to have to flush my current NVT-anti-constipation
code and rewrite another or additional approach from scratch.

5) Some auto-nicification when using CWD/CDUP while in non-server
interactive mode (REENTER) to prevent common user input errors.

6) Reworked numeric formating routines to allow easier reading of
large numbers. Better post transfer reporting.

7) Reworked FEAT (feature reporting mechanism) to automatically
handle new verbs.

7) Additional Commands:

LPRT, LPSV RFC1639 port data allocation.
Active port, long (Parse error code is not 100% correct)
Passive mode, long

SPSV Simple Passive Data Port Allocation
No RFC, discovered from Pure-FTPd documentation
Implemented in conjunction with #2 above

REST, RFC959 data stream positioning
The Kermit FTP client likes this, but I can't remember any
other FTP client which uses it. However, I may modify the
Tops-20 FTP client to do so (although it should typically use
paged file structure)

This is an initial implementation, only, based on the single
client that I have that uses it. It has yet to be tested
against other clients.

9) Regression testing with OS/2 Warp. My brother built me an OS/2
system out of some spare ISA parts he had lying around. The OS/2
character mode FTP client works fine. The OS/2 graphical
(presentation manager) FTP client mostly works, but exposes a
small bug in the top-level disk/directory simulation.

PM-FTP is also of note because it is the only FTP client that I
have that will actually orchestrate a so called 'third party'
transfer. This is a transfer from system A to system B while
you're signed on to system C and NOT running an FTP client locally
on either A or B.

See figure 2 on page 9 of RFC959 for more information on what
appears to be a little used feature of the FTP protocol.

20-Dec-2006 20:52:44-PST,1560;000000000000
Return-Path: <[email protected]>
Received: from pangtzu.panda.com ([206.124.149.117]) by lingling.panda.com with TCP/SMTP; Wed, 20 Dec 2006 20:46:49 -0800 (PST)
X-Return-Path: <[email protected]>
X-Received: from dbit.com ([208.238.226.25] -- may be forged) by lingling.panda.com with TCP/SMTP; Wed, 20 Dec 2006 20:07:16 -0800 (PST)
X-Received: from dbit.com (localhost [127.0.0.1])
by dbit.com (8.13.8/8.13.8) with ESMTP id kBL46UQ1007903
for <[email protected]>; Wed, 20 Dec 2006 23:06:30 -0500
X-Received: (from wilson@localhost)
by dbit.com (8.13.8/8.13.8/Submit) id kBL46UhG007902
for [email protected]; Wed, 20 Dec 2006 23:06:30 -0500
Date: Wed, 20 Dec 2006 23:06:30 -0500
From: John Wilson <[email protected]>
Message-Id: <[email protected]>
To: [email protected]
Subject: Re: TENEX FTP client sources?
ReSent-Date: Wed, 20 Dec 2006 20:46:40 -0800 (PST)
ReSent-From: TOPS-20 List Moderator <[email protected]>
ReSent-To: TOPS-20 Distribution: ;
ReSent-Subject: Re: TENEX FTP client sources?
ReSent-Message-ID: <[email protected]>

Might as well post this to the list in case anyone else cares too ...
I scanned the MIT-OZ gateway FTP client source and put it at:

http://www.dbit.com/wilson/gzftp.pdf

Unfortunately the columns are all messed up, I printed it on an IBM mainframe
(I was working on an FTP client for that at the time) and I was in a hurry
so I just substituted 8 blanks for each tab. Sorry!

John Wilson
D Bit

21-Dec-2006 09:38:05-PST,4354;000000000000
Return-Path: <[email protected]>
Received: from pangtzu.panda.com ([206.124.149.117]) by lingling.panda.com with TCP/SMTP; Thu, 21 Dec 2006 09:32:01 -0800 (PST)
X-Return-Path: <[email protected]>
X-Received: from pop-knobcone.atl.sa.earthlink.net ([207.69.195.64]) by lingling.panda.com with TCP/SMTP; Thu, 21 Dec 2006 01:07:22 -0800 (PST)
X-Received: from cpe-24-221-177-162.ca.sprintbbd.net ([24.221.177.162] helo=[204.238.239.104])
by pop-knobcone.atl.sa.earthlink.net with esmtp (Exim 3.36 #1)
id 1GxJtT-0002YT-00; Thu, 21 Dec 2006 04:07:16 -0500
In-Reply-To: <p06230900c1ae607a63dc@[192.168.1.52]>
References: <[email protected]> <[email protected]> <[email protected]> <[email protected]> <[email protected]> <[email protected]> <[email protected]> <[email protected]> <[email protected]> <[email protected]> <[email protected]> <[email protected]> <p06230900c1ae607a63dc@[192.168.1.52]>
Mime-Version: 1.0 (Apple Message framework v624)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <[email protected]>
Content-Transfer-Encoding: 7bit
Cc: [email protected],
[email protected]
X-Image-Url: http://www.goldenstategiftbaskets.com/minibasket.jpg
From: Carl Baltrunas <[email protected]>
Subject: Re: SYSREF sleeping aids
Date: Thu, 21 Dec 2006 01:07:12 -0800
To: John Francini <[email protected]>
X-Mailer: Apple Mail (2.624)
ReSent-Date: Thu, 21 Dec 2006 09:31:55 -0800 (PST)
ReSent-From: TOPS-20 List Moderator <[email protected]>
ReSent-To: TOPS-20 Distribution: ;
ReSent-Subject: Re: SYSREF sleeping aids
ReSent-Message-ID: <[email protected]>

On Dec 19, 2006, at 7:40 PM, John Francini wrote:

> For me it was the TOPS-10 6.03 Monitor Calls manual that I kept by my
> bed in college. I really did manage to get through it from beginning
> to end, but it took (I think) an entire school year of reading a few
> pages and falling asleep.
>
Well, I guess I didn't find my initial reading of the 2 phonebooks
particularly boring, and after studying the instruction set the first
year I owned them ('72/'73) I only read something in detail when I
wanted to know something about a particular instruction or behavior.

When I went from the TOPS-10 6.03a world (had 7.01 on my desk to
install, but left it for the new guy) to the TYMCOM-X world, I found
they had a lot of things mimicked from the SDS-940 TYMCOM-IX monitor.
We had TYMCOM mode with a dash (-) prompt for the majority of the users
and customers, and PDP mode with the familiar dot (.) prompt for the
rest of us.

Anyway, I was supposed to read the user guides to see what was
different between TOPS-10 and TYMCOM-X, and after falling asleep once,
I found it was better to see if there was a DOC,INF,MAN or HLP file to
see what the command options were. If that wasn't enough, I read the
source code, sometimes fixing obvious typos that no one had noticed
yet.

> You also know you've been up too late hacking away at a software
> project when you'd dream that you had to log in to your digital alarm
> clock in order to stop it from going off, and then you'd wake up to
> the darn thing beeping away much like an LA-36 being sent 1,000 ^G's.
>
> j
I don't know about up too late, but I recall a few mornings in the late
'70s where in my sleep, I tried several times to hit ^C over and over
again to shut off the alarm. It never worked, at least not that I
remember

-Carl.
>
>
> At 16:52 +0000 12/19/06, [email protected] wrote:
>> From: Carl Baltrunas
>>
>>> Great fun. It was the first time that I remember ever falling
>>> asleep trying to read a technical manual. Really! Somewhere
>>> between page 5 and 6. I never read any more user guides.
>>
>> Whaaay back in High School and College, I was the proud owner of my
>> very own copy of the 1973 edition of the DECsystem-10 Assembly
>> Language Handbook (the orange 'Phonebook'). It was typically kept on
>> the night table right next to my bed.

21-Dec-2006 11:12:15-PST,12888;000000000000
Return-Path: <[email protected]>
Received: from pangtzu.panda.com ([206.124.149.117]) by lingling.panda.com with TCP/SMTP; Thu, 21 Dec 2006 11:06:06 -0800 (PST)
X-Return-Path: <[email protected]>
X-Received: from smtpout.mac.com ([17.250.248.172]) by lingling.panda.com with TCP/SMTP; Thu, 21 Dec 2006 10:59:59 -0800 (PST)
X-Received: from mac.com (smtpin07-en2 [10.13.10.152])
by smtpout.mac.com (Xserve/8.12.11/smtpout02/MantshX 4.0) with ESMTP id kBLIxqBU002591;
Thu, 21 Dec 2006 10:59:52 -0800 (PST)
X-Received: from [10.68.15.8] ([12.0.44.46])
(authenticated bits=0)
by mac.com (Xserve/smtpin07/MantshX 4.0) with ESMTP id kBLIxcb4022685;
Thu, 21 Dec 2006 10:59:46 -0800 (PST)
In-Reply-To: <[email protected]>
References: <[email protected]> <[email protected]> <[email protected]> <[email protected]> <[email protected]> <[email protected]> <[email protected]> <[email protected]> <[email protected]> <[email protected]> <[email protected]> <[email protected]> <p06230900c1ae607a63dc@[192.168.1.52]> <[email protected]>
Mime-Version: 1.0 (Apple Message framework v752.2)
Content-Type: multipart/alternative; boundary=Apple-Mail-17--558183720
Message-Id: <[email protected]>
Cc: [email protected], [email protected]
From: John Francini <[email protected]>
Subject: Re: SYSREF sleeping aids
Date: Thu, 21 Dec 2006 13:59:37 -0500
To: Carl Baltrunas <[email protected]>
X-Mailer: Apple Mail (2.752.2)
X-Brightmail-Tracker: AAAAAA==
X-Brightmail-scanned: yes
ReSent-Date: Thu, 21 Dec 2006 11:05:59 -0800 (PST)
ReSent-From: TOPS-20 List Moderator <[email protected]>
ReSent-To: TOPS-20 Distribution: ;
ReSent-Subject: Re: SYSREF sleeping aids
ReSent-Message-ID: <[email protected]>

--Apple-Mail-17--558183720
Content-Transfer-Encoding: 7bit
Content-Type: text/plain;
charset=US-ASCII;
delsp=yes;
format=flowed

It wasn't that the books were boring -- I was fascinated by all the
facilities available in the Monitor -- but because it was rather dry
reading, and because such reading was at the end of a fairly long
day, the brain just couldn't sustain the activity level necessary to
soak up the book's info without falling asleep.

j

On 21 Dec 2006, at 4:07, Carl Baltrunas wrote:

>
> On Dec 19, 2006, at 7:40 PM, John Francini wrote:
>
>> For me it was the TOPS-10 6.03 Monitor Calls manual that I kept by
>> my bed in college. I really did manage to get through it from
>> beginning to end, but it took (I think) an entire school year of
>> reading a few pages and falling asleep.
>>
> Well, I guess I didn't find my initial reading of the 2 phonebooks
> particularly boring, and after studying the instruction set the
> first year I owned them ('72/'73) I only read something in detail
> when I wanted to know something about a particular instruction or
> behavior.
>
> When I went from the TOPS-10 6.03a world (had 7.01 on my desk to
> install, but left it for the new guy) to the TYMCOM-X world, I
> found they had a lot of things mimicked from the SDS-940 TYMCOM-IX
> monitor. We had TYMCOM mode with a dash (-) prompt for the
> majority of the users and customers, and PDP mode with the familiar
> dot (.) prompt for the rest of us.
>
> Anyway, I was supposed to read the user guides to see what was
> different between TOPS-10 and TYMCOM-X, and after falling asleep
> once, I found it was better to see if there was a DOC,INF,MAN or
> HLP file to see what the command options were. If that wasn't
> enough, I read the source code, sometimes fixing obvious typos that
> no one had noticed yet.
>
>> You also know you've been up too late hacking away at a software
>> project when you'd dream that you had to log in to your digital
>> alarm clock in order to stop it from going off, and then you'd
>> wake up to the darn thing beeping away much like an LA-36 being
>> sent 1,000 ^G's.
>>
>> j
> I don't know about up too late, but I recall a few mornings in the
> late '70s where in my sleep, I tried several times to hit ^C over
> and over again to shut off the alarm. It never worked, at least
> not that I remember
>
> -Carl.
>>
>>
>> At 16:52 +0000 12/19/06, [email protected] wrote:
>>> From: Carl Baltrunas
>>>
>>>> Great fun. It was the first time that I remember ever falling
>>>> asleep trying to read a technical manual. Really! Somewhere
>>>> between page 5 and 6. I never read any more user guides.
>>>
>>> Whaaay back in High School and College, I was the proud owner of my
>>> very own copy of the 1973 edition of the DECsystem-10 Assembly
>>> Language Handbook (the orange 'Phonebook'). It was typically
>>> kept on
>>> the night table right next to my bed.
>
>

--Apple-Mail-17--558183720
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
charset=ISO-8859-1

<HTML><BODY style=3D"word-wrap: break-word; -khtml-nbsp-mode: space; =
-khtml-line-break: after-white-space; "><SPAN =
class=3D"Apple-style-span">It wasn't that the books were boring -- I was =
fascinated by all the facilities available in the Monitor -- but because =
it was rather <I>dry </I>reading, and because such reading was at the =
end of a fairly long day, the brain just couldn't sustain the activity =
level necessary to soak up the book's info without falling =
asleep.</SPAN><DIV><BR class=3D"khtml-block-placeholder"></DIV><DIV><SPAN =
class=3D"Apple-style-span">j</SPAN></DIV><DIV><SPAN =
class=3D"Apple-style-span"><BR><DIV><DIV>On 21 Dec 2006, at 4:07, Carl =
Baltrunas wrote:</DIV><BR class=3D"Apple-interchange-newline"><BLOCKQUOTE =
type=3D"cite"><DIV style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; min-height: 14px; "><BR></DIV><DIV =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; ">On Dec 19, 2006, at 7:40 PM, John Francini =
wrote:</DIV><DIV style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; min-height: 14px; "><BR></DIV> =
<BLOCKQUOTE type=3D"cite"><DIV style=3D"margin-top: 0px; margin-right: =
0px; margin-bottom: 0px; margin-left: 0px; ">For me it was the TOPS-10 =
6.03 Monitor Calls manual that I kept by my bed in college.<SPAN =
class=3D"Apple-converted-space">=A0 </SPAN>I really did manage to get =
through it from beginning to end, but it took (I think) an entire school =
year of reading a few pages and falling asleep.</DIV><DIV =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; min-height: 14px; "><BR></DIV> </BLOCKQUOTE><DIV =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; ">Well, I guess I didn't find my initial reading of =
the 2 phonebooks particularly boring, and after studying the instruction =
set the first year I owned them ('72/'73) I only read something in =
detail when I wanted to know something about a particular instruction or =
behavior.</DIV><DIV style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; min-height: 14px; "><BR></DIV><DIV =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; ">When I went from the TOPS-10 6.03a world (had 7.01 =
on my desk to install, but left it for the new guy) to the TYMCOM-X =
world, I found they had a lot of things mimicked from the SDS-940 =
TYMCOM-IX monitor.<SPAN class=3D"Apple-converted-space">=A0 </SPAN>We =
had TYMCOM mode with a dash (-) prompt for the majority of the users and =
customers, and PDP mode with the familiar dot (.) prompt for the rest of =
us.</DIV><DIV style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; min-height: 14px; "><BR></DIV><DIV =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; ">Anyway, I was supposed to read the user guides to =
see what was different between TOPS-10 and TYMCOM-X, and after falling =
asleep once, I found it was better to see if there was a DOC,INF,MAN or =
HLP file to see what the command options were.<SPAN =
class=3D"Apple-converted-space">=A0 </SPAN>If that wasn't enough, I read =
the source code, sometimes fixing obvious typos that no one had noticed =
yet.</DIV><DIV style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; min-height: 14px; "><BR></DIV> =
<BLOCKQUOTE type=3D"cite"><DIV style=3D"margin-top: 0px; margin-right: =
0px; margin-bottom: 0px; margin-left: 0px; ">You also know you've been =
up too late hacking away at a software project when you'd dream that you =
had to log in to your digital alarm clock in order to stop it from going =
off, and then you'd wake up to the darn thing beeping away much like an =
LA-36 being sent 1,000 ^G's.</DIV><DIV style=3D"margin-top: 0px; =
margin-right: 0px; margin-bottom: 0px; margin-left: 0px; min-height: =
14px; "><BR></DIV><DIV style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; ">j</DIV> </BLOCKQUOTE><DIV =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; ">I don't know about up too late, but I recall a few =
mornings in the late '70s where in my sleep, I tried several times to =
hit ^C over and over again to shut off the alarm.<SPAN =
class=3D"Apple-converted-space">=A0 </SPAN>It never worked, at least not =
that I remember</DIV><DIV style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; min-height: 14px; "><BR></DIV><DIV =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; ">-Carl.</DIV> <BLOCKQUOTE type=3D"cite"><DIV =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; min-height: 14px; "><BR></DIV><DIV style=3D"margin-top: =
0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; =
min-height: 14px; "><BR></DIV><DIV style=3D"margin-top: 0px; =
margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">At 16:52 =
+0000 12/19/06, <A =
href=3D"mailto:[email protected]">[email protected]</A> =
wrote:</DIV> <BLOCKQUOTE type=3D"cite"><DIV style=3D"margin-top: 0px; =
margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">From: Carl =
Baltrunas</DIV><DIV style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; min-height: 14px; "><BR></DIV> =
<BLOCKQUOTE type=3D"cite"><DIV style=3D"margin-top: 0px; margin-right: =
0px; margin-bottom: 0px; margin-left: 0px; "><SPAN =
class=3D"Apple-converted-space">=A0</SPAN>Great fun.<SPAN =
class=3D"Apple-converted-space">=A0 </SPAN>It was the first time that I =
remember ever falling</DIV><DIV style=3D"margin-top: 0px; margin-right: =
0px; margin-bottom: 0px; margin-left: 0px; "><SPAN =
class=3D"Apple-converted-space">=A0</SPAN>asleep trying to read a =
technical manual.<SPAN class=3D"Apple-converted-space">=A0 =
</SPAN>Really!<SPAN class=3D"Apple-converted-space">=A0 =
</SPAN>Somewhere</DIV><DIV style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; "><SPAN =
class=3D"Apple-converted-space">=A0</SPAN>between page 5 and 6.<SPAN =
class=3D"Apple-converted-space">=A0 </SPAN>I never read any more user =
guides.</DIV> </BLOCKQUOTE><DIV style=3D"margin-top: 0px; margin-right: =
0px; margin-bottom: 0px; margin-left: 0px; min-height: 14px; =
"><BR></DIV><DIV style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; ">Whaaay back in High School and =
College, I was the proud owner of my</DIV><DIV style=3D"margin-top: 0px; =
margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">very own copy =
of the 1973 edition of the DECsystem-10 Assembly</DIV><DIV =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; ">Language Handbook (the orange 'Phonebook').<SPAN =
class=3D"Apple-converted-space">=A0 </SPAN>It was typically kept =
on</DIV><DIV style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: =
0px; margin-left: 0px; ">the night table right next to my bed.</DIV> =
</BLOCKQUOTE></BLOCKQUOTE><DIV style=3D"margin-top: 0px; margin-right: =
0px; margin-bottom: 0px; margin-left: 0px; min-height: 14px; =
"><BR></DIV><DIV style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; min-height: 14px; "><BR></DIV> =
</BLOCKQUOTE></DIV><BR></SPAN></DIV></BODY></HTML>=

--Apple-Mail-17--558183720--