1-Jan-2004 18:26:52-PST,1344;000000000001
Mail-From: MRC created at  1-Jan-2004 18:18:17
Date: Thu, 1 Jan 2004 18:18:17 -0800 (PST)
From: Mark Crispin <[email protected]>
Subject: record TOPS-20 list traffic and 40th anniversary
To: [email protected]
Pithy-Thought: TOPS-20 was a great improvement over its successors
Message-ID: <[email protected]>

Happy New Year to all TOPS-20 list members!

2003 marked the most activity on the TOPS-20 mailing list (110 pages, 280,311
characters) since 1988 (123 pages, 312,566 characters).  This does not include
a single MIME message of 346 pages (884,161 characters); had that message been
included it would have been an all-time record.

The nadir was in 1997 (3 pages, 5,641 characters).

As a reminder, the post address for this list is:
       [email protected]
This mailing list is not moderated or spam-protected in any way; so please do
not mention it in newsgroup postings or on web pages.

Also, as this year marks the 40th anniversary of 36-bits, we should have some
sort of celebration.  My earliest PDP-6 document is the PDP-6 price list,
dated February 1964.

Seattle seems to be a hotbed of PDP-10 activity, what with Panda, Vulcan (Paul
Allen), and XKL all being located here.  Perhaps we could all get together for
a meal at the Space Needle some time?
-------
2-Jan-2004 10:37:35-PST,2966;000000000000
Return-Path: <[email protected]>
Received: from rwcrmhc13.comcast.net ([204.127.198.39]) by lingling.panda.com with TCP/SMTP; Fri, 2 Jan 2004 10:28:19 -0800 (PST)
Received: from [10.0.1.4] (h000393e155ff.ne.client2.attbi.com[24.63.6.9])
         by comcast.net (rwcrmhc13) with ESMTP
         id <2004010218281601500rdo5te>; Fri, 2 Jan 2004 18:28:17 +0000
Mime-Version: 1.0
X-Sender:  (Unverified)
Message-Id: <p05200f02bc1b687dc92b@[10.0.1.4]>
In-Reply-To: <[email protected]>
References: <[email protected]>
Date: Fri, 2 Jan 2004 13:28:17 -0500
To: Mark Crispin <[email protected]>, [email protected]
From: Paul Wexelblat <[email protected]>
Subject: Too much disk space...Re: record TOPS-20 list traffic and 40th
anniversary
Content-Type: text/plain; charset="us-ascii" ; format="flowed"

FYI, I seem to have saved all the list email since ...

>Return-Path: <[email protected]>
Sender: [email protected]
Reminder: To post to the list, send mail to [email protected]
Reminder: To [un]subscribe, send mail to [email protected]
Date: Wed, 13 Nov 1996 11:14:15 -0800
From: Rich Alderson <[email protected]>
Subject: Accounts on toad.xkl.com
To: [email protected]

We at XKL Systems would like to invite the members of the (dwindling) Tops-20
community to try out their favourite programs on a ToaD-1, our implementation
of the PDP-10 architecture.  I administer this system, which is owned by
Customer Service.

If you are interested, please contact me, by e-mail or by calling XKL Systems
at (206) 869-9050, to set up an account.

                                                               Rich Alderson
-------


any interest on anyone's part


Best, ...wex

At 6:18 PM -0800 1/1/04, Mark Crispin wrote:
>Happy New Year to all TOPS-20 list members!
>
>2003 marked the most activity on the TOPS-20 mailing list (110 pages, 280,311
>characters) since 1988 (123 pages, 312,566 characters).  This does not include
>a single MIME message of 346 pages (884,161 characters); had that message been
>included it would have been an all-time record.
>
>The nadir was in 1997 (3 pages, 5,641 characters).
>
>As a reminder, the post address for this list is:
>       [email protected]
>This mailing list is not moderated or spam-protected in any way; so please do
>not mention it in newsgroup postings or on web pages.
>
>Also, as this year marks the 40th anniversary of 36-bits, we should have some
>sort of celebration.  My earliest PDP-6 document is the PDP-6 price list,
>dated February 1964.
>
>Seattle seems to be a hotbed of PDP-10 activity, what with Panda, Vulcan (Paul
>Allen), and XKL all being located here.  Perhaps we could all get together for
>a meal at the Space Needle some time?
>-------
>
>
>  E3-I: This message has been scanned for viruses and dangerous
>content by UML's antivirus scanning services.


--
--
        ...wex
5-Jan-2004 19:38:28-PST,3157;000000000000
Return-Path: <[email protected]>
Received: from epsilon3.corestore.org ([66.108.221.212]) by lingling.panda.com with TCP/SMTP; Mon, 5 Jan 2004 19:28:55 -0800 (PST)
Return-Path: <[email protected] ([66.65.143.33])>
Received: from 66-65-143-33.nyc.rr.com ([66.65.143.33]) by epsilon3.corestore.org id 615 ; Mon, 5 Jan 2004 23:53:44 -0500
From: Michael Ross <[email protected]>
To: [email protected]
Subject: Re: Happy DEC-20 day!
Date: Mon, 05 Jan 2004 22:29:27 -0500
Message-ID: <[email protected] ([66.65.143.33])>
References: <[email protected] ([206.124.149.115])>
In-Reply-To: <[email protected] ([206.124.149.115])>
X-Mailer: Forte Agent 1.93/32.576 English (American)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable

On Sat, 20 Dec 2003 12:01:18 -0800 (PST), you wrote:

>Happy DEC-20 day to everybody on the TOPS-20 list.  If you still have a
>DEC-20, even if its powered off, give it a hug and tell it you still =
love
>it.=20

No -20 involved in the transmission of this message, but it contains
Good News all the same (announced to alt.sys.pdp10 late last year).
Within a few weeks, I'll have taken delivery of another DEC-20 :-)

I've recently acquired Heinz Wolters 2065, which is in nice shape, and
very complete. The hope is, one day, to bring it up - at least
occasionally - on the net. It was a fairly late KL, the QC labels
proclaim a 'final integration test' on 10-04-84 - a year after the
Jupiter anouncement.=20

It contains an NIA20, 2x MG20 memory boxes (that's 2MW I think,
judging by how many of the slots in them are populated...), single
DTE20, ?single? RH20 (I thought it was at least two, one for disk, one
for tape...), and the FE 11/40 has a DH11 and DM11.

I've put some quick & dirty pics up at:
http://www.corestore.org/2065.htm

I've also negotiated to acquire a quantity of Setasi RP12
Massbus-replacement drives, and the special never-officially-released
36-bit software disks to operate them. Any other -10 owners out there,
who are looking for an alternative to RP06s etc, feel free to get in
touch - I'll be making all the Setasi material freely available to the
-10 community. Hopefully it will include the emulation s/w source
code, and the chip layout/design files for the Xilinx FPGA massbus
emulation.

I've seen the RCSRI page with a serial number list, and IIRC someone
posted to this group, trying to compile a serial number list. I'm
hoping to get some input from someone who can provide more information
on the history of this unit. The curiosity is, it appears to have two
serial numbers... the printed labels say MRR3545. but the '45' is
overwritten in pen with '26'. Neither 3545 nor 3526 are listed at:

http://starfish.rcsri.org/rcs/DECsystem/FAQ/Serial_Number_Master.pdf

Can anyone shed any light? I know the 'MR' refers to Marlboro, but
'MRR'? R =3D refurbished?

Mike

http://www.corestore.org

'The avalanche has already started
It is too late for the pebbles to vote'
12-Jan-2004 13:32:42-PST,914;000000000000
Return-Path: <[email protected]>
Received: from nw.com ([64.142.30.60]) by lingling.panda.com with TCP/SMTP; Mon, 12 Jan 2004 13:23:44 -0800 (PST)
Received: (from mkl@localhost)
       by nw.com (8.11.0/8.11.0) id i0CLNcs05034
       for [email protected]; Mon, 12 Jan 2004 13:23:38 -0800 (PST)
Date: Mon, 12 Jan 2004 13:23:38 PST
From: Mark Lottor <[email protected]>
To: [email protected]
Subject: chives/jeeves
Message-ID: <[email protected]>

Hi, if you have this, please contact him.

thanks,
Mark
               ---------------

Date: Mon, 12 Jan 2004 22:11:33 +0100 (CET)
From: Roy Arends <[email protected]>
To: Mark Lottor <[email protected]>
Subject: chives/jeeves

Mark,

Do you know where we could lay our hands on/who we have to bribe for old
chives/jeeves sources ?

Just for fun, we'd like to include fingerprints of both implementations to
the tool.

Thanks,

Roy

12-Jan-2004 13:57:57-PST,1309;000000000000
Return-Path: <[email protected]>
Received: from thrintun.hactrn.net ([66.92.66.67]) by lingling.panda.com with TCP/SMTP; Mon, 12 Jan 2004 13:48:53 -0800 (PST)
Received: from thrintun.hactrn.net (localhost [IPv6:::1])
       by thrintun.hactrn.net (Postfix) with ESMTP id CA44D18E6
       for <[email protected]>; Mon, 12 Jan 2004 16:48:51 -0500 (EST)
Date: Mon, 12 Jan 2004 16:48:51 -0500
From: Rob Austein <[email protected]>
To: [email protected]
Subject: Re: chives/jeeves
In-Reply-To: <[email protected]>
References: <[email protected]>
User-Agent: Wanderlust/2.10.1 (Watching The Wheels) Emacs/21.3 Mule/5.0 (SAKAKI)
MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen")
Content-Type: text/plain; charset=US-ASCII
Message-Id: <[email protected]>

At Mon, 12 Jan 2004 13:23:38 PST, Mark Lottor wrote:
>
> Hi, if you have this, please contact him.
>
> Date: Mon, 12 Jan 2004 22:11:33 +0100 (CET)
> From: Roy Arends <[email protected]>
>
> Do you know where we could lay our hands on/who we have to bribe for old
> chives/jeeves sources ?
>
> Just for fun, we'd like to include fingerprints of both implementations to
> the tool.

Roy already asked me this and I already answered, but I'll refresh his
memory.
12-Jan-2004 14:13:02-PST,924;000000000000
Return-Path: <[email protected]>
Received: from thrintun.hactrn.net ([66.92.66.67]) by lingling.panda.com with TCP/SMTP; Mon, 12 Jan 2004 14:04:04 -0800 (PST)
Received: from thrintun.hactrn.net (localhost [IPv6:::1])
       by thrintun.hactrn.net (Postfix) with ESMTP id E187B18E8
       for <[email protected]>; Mon, 12 Jan 2004 17:04:03 -0500 (EST)
Date: Mon, 12 Jan 2004 17:04:03 -0500
From: Rob Austein <[email protected]>
To: [email protected]
Subject: Re: chives/jeeves
In-Reply-To: <[email protected]>
References: <[email protected]>
User-Agent: Wanderlust/2.10.1 (Watching The Wheels) Emacs/21.3 Mule/5.0 (SAKAKI)
MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen")
Content-Type: text/plain; charset=US-ASCII
Message-Id: <[email protected]>

Oh yeah: for anybody who actually wants these sources, try

http://www.hactrn.net/hacks/
12-Jan-2004 14:25:49-PST,1205;000000000000
Return-Path: <[email protected]>
Received: from sdf.lonestar.org (ol.freeshell.org [192.94.73.20]) by lingling.panda.com with TCP/SMTP; Mon, 12 Jan 2004 14:16:49 -0800 (PST)
Received: from sdf.lonestar.org (IDENT:[email protected] [192.94.73.20])
       by sdf.lonestar.org (8.12.10/8.12.10) with ESMTP id i0CMGkNw002710
       for <[email protected]>; Mon, 12 Jan 2004 22:16:46 GMT
Received: (from smj@localhost)
       by sdf.lonestar.org (8.12.10/8.12.8/Submit) id i0CMGkY0002708
       for [email protected]; Mon, 12 Jan 2004 22:16:46 GMT
From: Stephen Jones <[email protected]>
Message-Id: <[email protected]>
Subject: Seattle based get together?
In-Reply-To: <[email protected]>
To: [email protected]
Date: Mon, 12 Jan 2004 22:16:46 +0000 (UTC)
X-Mailer: ELM [version 2.4ME+ PL93 (25)]
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=US-ASCII

Hey there MRC -

Did anyone else respond to you?  I didn't see any responses on the list, so
I'm guessing it probably won't happen.  Migiwa and I would attend an event
at the space needle if one was planned ..

[email protected]
12-Jan-2004 16:12:46-PST,1500;000000000000
Return-Path: <[email protected]>
Received: from mxout4.cac.washington.edu ([140.142.33.19]) by lingling.panda.com with TCP/SMTP; Mon, 12 Jan 2004 16:04:02 -0800 (PST)
Received: from shiva1.cac.washington.edu (shiva1.cac.washington.edu [140.142.100.201])
       by mxout4.cac.washington.edu (8.12.10+UW03.09/8.12.10+UW03.09) with ESMTP id i0D040Y2009810;
       Mon, 12 Jan 2004 16:04:01 -0800
Received: from localhost (mrc@localhost)
       by shiva1.cac.washington.edu (8.12.10+UW03.09/8.12.10+UW03.09) with ESMTP id i0D040fk015596;
       Mon, 12 Jan 2004 16:04:00 -0800
Date: Mon, 12 Jan 2004 16:04:00 -0800 (PST)
From: Mark Crispin <[email protected]>
Sender: [email protected]
To: Stephen Jones <[email protected]>
cc: [email protected]
Subject: Re: Seattle based get together?
In-Reply-To: <[email protected]>
Message-ID: <[email protected]>
References: <[email protected]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

On Mon, 12 Jan 2004, Stephen Jones wrote:
> Did anyone else respond to you?  I didn't see any responses on the list, so
> I'm guessing it probably won't happen.  Migiwa and I would attend an event
> at the space needle if one was planned ..

Indeed, the silence has been deafening.  It would be great to put
something together for the 40th anniversary of 36-bits, but so far there
haven't been many nibbles...

-- Mark --
28-Jan-2004 12:53:28-PST,1337;000000000000
Return-Path: <[email protected]>
Received: from mta3.srv.hcvlny.cv.net ([167.206.5.69]) by lingling.panda.com with TCP/SMTP; Wed, 28 Jan 2004 12:44:40 -0800 (PST)
Received: from optonline.net (ool-182f33c4.dyn.optonline.net [24.47.51.196])
by mta3.srv.hcvlny.cv.net
(iPlanet Messaging Server 5.2 HotFix 1.16 (built May 14 2003))
with ESMTP id <[email protected]> for
[email protected]; Wed, 28 Jan 2004 15:44:33 -0500 (EST)
Date: Wed, 28 Jan 2004 15:44:25 -0500
From: Thomas DeBellis <[email protected]>
Subject: SORT
To: Tops-20 Wizards <[email protected]>
Message-id: <[email protected]>
MIME-version: 1.0
X-Mailer: Mozilla 4.5 [en]C-CCK-MCD BA45DSL  (WinNT; U)
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7BIT
X-Accept-Language: en

Does anybody remember what the commands are to sort
to take a list of sorted files, combine them and
punt the duplicate lines? I know it's something like:

SORT> /recORD-SIZE:58 /keY:2,17 /seQUENTIAL FOO,BAR,BAZ OUTPUT

That works fine, but  it doesn't get rid of the
duplicates.  I don't see what the switch is to do
that.

Alternatively, is there some other utility like in
EMACA or something?  I remember doing this all the time,
but I sure can't remember what the heck I did!

28-Jan-2004 15:37:40-PST,2585;000000000000
Return-Path: <[email protected]>
Received: from sunshine.math.utah.edu ([128.110.198.2]) by lingling.panda.com with TCP/SMTP; Wed, 28 Jan 2004 15:29:10 -0800 (PST)
Received: from psi.math.utah.edu (IDENT:[email protected] [128.110.198.32])
       by sunshine.math.utah.edu (8.12.10/8.12.10) with ESMTP id i0SNT4Qo014185;
       Wed, 28 Jan 2004 16:29:04 -0700 (MST)
Received: from psi.math.utah.edu (IDENT:P46tDwQDC8c1B/JZEdQU4czA1Vl3aM9C@localhost [127.0.0.1])
       by psi.math.utah.edu (8.12.10/8.12.10) with ESMTP id i0SNT4CC017416;
       Wed, 28 Jan 2004 16:29:04 -0700 (MST)
Received: (from beebe@localhost)
       by psi.math.utah.edu (8.12.10/8.12.10/Submit) id i0SNT2QB017414;
       Wed, 28 Jan 2004 16:29:02 -0700 (MST)
Date: Wed, 28 Jan 2004 16:29:02 -0700 (MST)
From: "Nelson H. F. Beebe" <[email protected]>
To: Tops-20 Wizards <[email protected]>
Cc: [email protected], Thomas DeBellis <[email protected]>
X-US-Mail: "Center for Scientific Computing, 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: removing duplicate records during sorting
Message-ID: <[email protected]>

Thomas DeBellis <[email protected]> asks about removing duplicate
records during sorting.

The UNIX way is simple: either

       sort -u

or

       sort | uniq

I don't recall if TOPS-20 sort had a similar flag.

In GNU Emacs, for text files, where the whole line is the key, M-x
flush-lines (or its alias, M-x delete-matching-lines) will do the
trick.  In TOPS-20 emacs, a scan of my own old TECO code turns up M.M
Unique_Lines.

A good sort tool is extremely handy, and the GNU implementation of
UNIX sort is excellent: perhaps it can be built on TOPS-20: it can be
found in the packages here:

       ftp://ftp.gnu.org/gnu/coreutils/

-------------------------------------------------------------------------------
- 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-Feb-2004 09:20:01-PST,1257;000000000000
Return-Path: <[email protected]>
Received: from mta7.srv.hcvlny.cv.net ([167.206.5.74]) by lingling.panda.com with TCP/SMTP; Fri, 13 Feb 2004 09:11:20 -0800 (PST)
Received: from optonline.net (ool-182f33c4.dyn.optonline.net [24.47.51.196])
by mta7.srv.hcvlny.cv.net
(iPlanet Messaging Server 5.2 HotFix 1.16 (built May 14 2003))
with ESMTP id <[email protected]> for
[email protected]; Fri, 13 Feb 2004 12:11:26 -0500 (EST)
Date: Fri, 13 Feb 2004 12:11:16 -0500
From: Thomas DeBellis <[email protected]>
Subject: 9 track and DECtape data recovery
To: Tops-20 Wizards <[email protected]>
Message-id: <[email protected]>
MIME-version: 1.0
X-Mailer: Mozilla 4.5 [en]C-CCK-MCD BA45DSL  (WinNT; U)
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7BIT
X-Accept-Language: en

While searching through my basement, I found a stack
of 9 track tapes back from when I used to work at
Columbia University in the 1980.

Oh, the hidden treasures of lost Tops-20 lore!

Has anybody been in a situation like this?  Where
did you get your tapes read?  I wonder what sort of
goodies I put on there...

I can't go to a recovery service; they are thousands
of $$$
13-Feb-2004 09:34:41-PST,2518;000000000000
Return-Path: <[email protected]>
Received: from mta6.srv.hcvlny.cv.net ([167.206.5.72]) by lingling.panda.com with TCP/SMTP; Fri, 13 Feb 2004 09:26:22 -0800 (PST)
Received: from optonline.net (ool-182f33c4.dyn.optonline.net [24.47.51.196])
by mta6.srv.hcvlny.cv.net
(iPlanet Messaging Server 5.2 HotFix 1.16 (built May 14 2003))
with ESMTP id <[email protected]> for
[email protected]; Fri, 13 Feb 2004 12:26:28 -0500 (EST)
Date: Fri, 13 Feb 2004 12:26:17 -0500
From: Thomas DeBellis <[email protected]>
Subject: Multi-homed systems
To: Tops-20 Wizards <[email protected]>
Message-id: <[email protected]>
MIME-version: 1.0
X-Mailer: Mozilla 4.5 [en]C-CCK-MCD BA45DSL  (WinNT; U)
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7BIT
X-Accept-Language: en

I have a Tops-20 machine that I would like to bring up on the
public Internet, but I have a small issue that I was wondering
how to resolve.

Basically, the system is currently behind a firewall and is
NAT'ed.  My router is set to forward various ports (Telnet,
FTP, Finger) to the 20, but I'd like it up for real so that
I can get email (and just, well, BECAUSE!)

The problem is, I would still like my other machines (which
are NATed scattered over numerous VPN's, etc) to be able get
to the 20 without going over the public internet.

This suggests having a machine with two interfaces.  I believe
(although I am not sure), that DEC did not support more than
one hardware NI per box.  Is this true?  I don't know if the
monitor code will handle multiple NI's...

I am pretty sure, however, that a KL could run an IMP and an NI.
I think CUCS20 did this and maybe XX and SCORE?  So, what I was
thinking of doing was binding the local area address to the NI
and then putting in the IMP and binding THAT to a seperate
network adaptor and giving that the public IP address.

Comments?  I seem to remember that the KLH-10 IMP code works,
because Ken used that to bring up ITS which (at least on
AI, DM, ML and MC) doesn't know about the NI (because the
hardware didn't exist for the KA and KL-10A processors).
I don't know what was used for the 2020 based versions of ITS.

Finally, if anyone is interested, SRA helped me hack together
a short simple REVERSE.ZONE file that lets chives know about
all my internal hosts, so I don't have that annoying wait for
MM and other GTDOM% friends.  I'll be hapyy to email it to
whomever.
13-Feb-2004 10:09:37-PST,1045;000000000000
Return-Path: <[email protected]>
Received: from Ikkoku-Kan.Panda.COM (panda.com [206.124.149.114]) by lingling.panda.com with TCP/SMTP; Fri, 13 Feb 2004 10:01:16 -0800 (PST)
Received: from Ikkoku-Kan.Panda.COM (Ikkoku-Kan.Panda.COM [192.107.14.50]) by Ikkoku-Kan.Panda.COM id KAA03415; Fri, 13 Feb 2004 10:01:13 -0800 (PST)
Date: Fri, 13 Feb 2004 09:58:35 -0800 (PST)
From: Mark Crispin <[email protected]>
Sender: Mark Crispin <[email protected]>
Subject: re: Multi-homed systems
To: Thomas DeBellis <[email protected]>
cc: Tops-20 Wizards <[email protected]>
In-Reply-To: <[email protected]>
Message-ID: <[email protected]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII

AFAIK, TOPS-20 only supports one NI since KL hardware only supported one NI.

The KLH-10 IMP code emulates a KS IMP interface (probably an AN22), and
supports the KS versions of the ITS systems.  KLH-10 does not support the old
KA and KLa versions of the ITS systems.

13-Feb-2004 10:23:28-PST,7295;000000000000
Return-Path: <[email protected]>
Received: from mta1.srv.hcvlny.cv.net ([167.206.5.67]) by lingling.panda.com with TCP/SMTP; Fri, 13 Feb 2004 10:15:05 -0800 (PST)
Received: from optonline.net (ool-182f33c4.dyn.optonline.net [24.47.51.196])
by mta1.srv.hcvlny.cv.net
(iPlanet Messaging Server 5.2 HotFix 1.16 (built May 14 2003))
with ESMTP id <[email protected]> for
[email protected]; Fri, 13 Feb 2004 13:15:10 -0500 (EST)
Date: Fri, 13 Feb 2004 13:14:59 -0500
From: Thomas DeBellis <[email protected]>
Subject: SC%MNT Shutdown
To: Tops-20 Wizards <[email protected]>
Message-id: <[email protected]>
MIME-version: 1.0
X-Mailer: Mozilla 4.5 [en]C-CCK-MCD BA45DSL  (WinNT; U)
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7BIT
X-Accept-Language: en

Does anybody remember how somebody with SC%MNT capability (i.e., the
F-S id) used to be able shut down the system?  I'm probably luckier
than most Tops-20 hackers these days as I have a nearly real Field
Service type who handles the hardware for my KLH-10 microengine (my
brother).

He wanted to have Wheel or Operator to take the system down, but YEARS
of experience reminded me that this was probably Not A Good Idea.  I
remembered that Field Service could shut down the system and went and
had a look in JSYSM.MAC and at .HSYS+1, I found:

       MOVE T3,CAPENB          ;[9041] Check user capabilities
       TXNN T3,SC%WHL+SC%OPR+SC%MNT ;[9041] User allowed to do halt?

So, suspicions confirmed: Field Service CAN do this.  I went and built
him an Id with maintainence capability (SC%MNT) and ... he couldn't
shut down the system!

I don't remember what program to run and, when he enabled, he couldn't
get to the ^E cease command.  MRC remarked to me that these commands
were only for Wheels and Operators.  However, since I couldn't
remember what other program to run, I punted and made some simple
changes to EXECSU and EXECCA, which I inclose below in case anybody
wants them:

1)1  ;[TOMMYT]STAR:<EXEC-SOURCES>EXECSU.MAC.4,  8-Sep-2003 01:35:07, Edit by SLOGIN
1)   ;[TT9] Allow SC%MNT to do an ^Ecease and a few other commands
1)   ;PANDA changes:
****
2)1  ;PANDA changes:
***********
1)20 PRVCK:  TXNN B,WHLU+OPRU+ERRU+MNTU ;[TT9] ANY PRIVILEGES WANTED?
1)           RETSKP                ;NO - RETURN SUCCESS
****
2)20 PRVCK:  TXNN B,WHLU+OPRU+ERRU ;ANY PRIVILEGES WANTED?
2)           RETSKP                ;NO - RETURN SUCCESS
***********
1)20         DEFINE PRVTST (KEYWB,T20CAP,%NEXT) <
1)           TXNN D,KEYWB         ;;[TT9] CHECKING FOR THIS KEYWORD BIT?
1)           JRST %NEXT           ;;[TT9] NO, SO DON'T CHECK CAPABILITY
1)           TXNE C,T20CAP        ;;[TT9] HAS THE USER GOT THE CAPABILITY?
1)           RETSKP               ;;[TT9] YES, ALLOW THE KEYWORD TO PARSE
1)   %NEXT:! REMARK FAILURE PATH  ;;[TT9] HERE TO FAIL OR SKIP THE TEST
1)   >;;END OF PRVTST
1)           PRVTST (WHLU,SC%WHL) ;[TT9] CHECKING FOR WHEEL?
1)           PRVTST (OPRU,SC%OPR) ;[[T9] CHECKING FOR OPERATOR?
1)           PRVTST (ERRU,SC%CNF) ;[TT9] CHECKING FOR "CONFIDENTIAL INFORMATION"?
1)           PRVTST (MNTU,SC%MNT) ;[TT9] CHECKING FOR MAINTAINANCE?
1)           RET                  ;[TT9] WANTS AND DOESN'T HAVE - FAILURE
1)21 ;USUBCO UUO, INVOKED BY SUBCOM MACRO
****
2)20         TXNN D,WHLU          ;CHECKING FOR WHEEL?
2)           JRST PRVCK1          ;NO - SKIP THIS
2)           TXNE    C,SC%WHL     ;YES - HAS USER GOT WHEEL?
2)           RETSKP               ;YES - SUCCESS
2)   PRVCK1: TXNN D,OPRU          ;CHECKING FOR OPERATOR?
2)           JRST PRVCK2          ;NO - SKIP THIS
2)           TXNE    C,SC%OPR     ;YES - HAS USER GOT OPERATOR?
2)           RETSKP               ;YES - SUCCESS
2)   PRVCK2: TXNE D,ERRU          ;CHECKING FOR "CONFIDENTIAL INFORMATION"?
2)           TXNN    C,SC%CNF     ;YES - HAS USER GOT IT?
2)           RET                  ;WANTS AND DOESN'T HAVE - FAILURE
2)           RETSKP               ;WANTS AND HAS - SUCCESS
2)21 ;USUBCO UUO, INVOKED BY SUBCOM MACRO
***********


1)1  ;[TOMMYT]STAR:<EXEC-SOURCES>EXECCA.MAC.4,  8-Sep-2003 02:04:25, Edit by SLOGIN
1)   ;[TT9] Allow SC%MNT to do an ^Ecease and a few other commands
1)   ;PANDA changes:
****
2)1  ;PANDA changes:
***********
1)6          T CREATE,WHLU+OPRU         ;[TT9] CREAT/MODIFY DIRECTORY
1)           T DEFINE,WHLU+OPRU,EDEFIN  ;[TT9] CREATE LOGICAL NAME
1)           T EDDT,ONEWRD+WHLU         ;GO TO DDT LOOKING AT EXEC
1)   IFN PANDASW,<   ;[1]
1)           T PEEK,WHLU                ;[TT9] SPY ON ANOTHER LINE
1)   >;IFN PANDASW
1)           T PRINT,WHLU+OPRU,EPRINT   ;[TT9] PRINT DIRECTORY INFORMATION
1)           T QUIT,ONEWRD+WHLU         ;QUIT: EXIT TO SUPERIOR EXEC
1)   IFN PANDASW,<   ;[1]
1)           T REPLACE,ONEWRD+WHLU      ;[TT9] REPLACE EXEC
1)   >;IFN PANDASW
1)           T SEND                     ;SEND (MESSAGE) TO ALL
1)           T SET,WHLU+OPRU,ESET       ;[TT9] SET DATE AND TIME
1)           T SPEAK,WHLU+OPRU          ;[TT9] SPEAK (TO SYSJOB)
1)           TEND
****
2)6          T CREATE                   ;CREAT/MODIFY DIRECTORY
2)           T DEFINE,,EDEFIN           ;CREATE LOGICAL NAME
2)           T EDDT,ONEWRD+WHLU         ;GO TO DDT LOOKING AT EXEC
2)   IFN PANDASW,<   ;[1]
2)           T PEEK                     ;SPY ON ANOTHER LINE
2)   >;IFN PANDASW
2)           T PRINT,,EPRINT            ;PRINT DIRECTORY INFORMATION
2)           T QUIT,ONEWRD+WHLU         ;QUIT: EXIT TO SUPERIOR EXEC
2)   IFN PANDASW,<   ;[1]
2)           T REPLACE                  ;REPLACE EXEC
2)   >;IFN PANDASW
2)           T SEND                     ;SEND (MESSAGE) TO ALL
2)           T SET,,ESET                ;SET DATE AND TIME
2)           T SPEAK                    ;SPEAK (TO SYSJOB)
2)           TEND
***********


This, of course, works fine, but I still can't remember how to shut
the machine down without the Exec.  System shutdown code is not in
Galaxy, so where?  Any takers?  Finally, a couple of random things:

1) I wrote up a nice .DOC file with lots of examples of how to shut
   down a machine.  If anybody wants a copy, please feel free to
   email me.

2) The ACJ as shipped with the PANDA monitor does *NOT* allow anyone
   but a Wheel or an Operator to log into the CTY.  Since the machine
   is commonly shut down via the CTY for hardware work, it makes
   sense to allow this.  In ACJ.MAC at LOGCHK+19 (decimal), change:

   MOVE A,GTDBLK+.CDPRV        ; fool WOPR
   MOVEM A,RCVBLK+.RCCAP
   JRST WOPR
                To:

   MOVE A,GTDBLK+.CDPRV        ;[TT8] Load user's potential capabilities
   TXNE A,SC%WHL!SC%OPR!SC%MNT ;[TT8] Wheel, OPR or F-S?
    JRST GRANT                 ;[TT8]  Allow it
   JRST DENY                   ;[TT8] Get out of my machine room!!

3) If anyone is using shutdown queueing and getting odd results,
   please contact me for an analysis and a non-PANDA patch.  This
   involves modifying the monitor and the (series 5) ACJ.  MRC
   considers the correct approach to completely punt the old ACJ and
   use the new DEC one, and has rightfully rejected my proposed
   changes.
13-Feb-2004 10:32:24-PST,2617;000000000000
Return-Path: <[email protected]>
Received: from thrintun.hactrn.net ([66.92.66.67]) by lingling.panda.com with TCP/SMTP; Fri, 13 Feb 2004 10:17:58 -0800 (PST)
Received: from thrintun.hactrn.net (localhost [IPv6:::1])
       by thrintun.hactrn.net (Postfix) with ESMTP id BB7E218E3
       for <[email protected]>; Fri, 13 Feb 2004 13:17:56 -0500 (EST)
Date: Fri, 13 Feb 2004 13:17:56 -0500
From: Rob Austein <[email protected]>
To: Tops-20 Wizards <[email protected]>
Subject: Re: Multi-homed systems
In-Reply-To: <[email protected]>
References: <[email protected]>
User-Agent: Wanderlust/2.10.1 (Watching The Wheels) Emacs/21.3 Mule/5.0 (SAKAKI)
MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen")
Content-Type: text/plain; charset=US-ASCII
Message-Id: <[email protected]>

At Fri, 13 Feb 2004 12:26:17 -0500, Thomas DeBellis wrote:
> ...
> I am pretty sure, however, that a KL could run an IMP and an NI.
> I think CUCS20 did this and maybe XX and SCORE?

Certainly XX did.  10.0.0.44 and 18.26.0.36.

> So, what I was thinking of doing was binding the local area address
> to the NI and then putting in the IMP and binding THAT to a seperate
> network adaptor and giving that the public IP address.

The tricky bit is likely to be figuring out how the packets flow
through the host (unix) machine.  Different versions of the KLH-10
network "hardware" do it in different ways, some use a mechanism like
/dev/bpf to glom onto the low level host system interface, some just
hand packets to a mechanism like /dev/tun and let the host system's
network code sort it out.  (Those are the BSD device names, there are
roughly equivilent mechanisms for a Linux host machine but I don't
recall their names offhand.)

> Comments?  I seem to remember that the KLH-10 IMP code works,
> because Ken used that to bring up ITS which (at least on
> AI, DM, ML and MC) doesn't know about the NI (because the
> hardware didn't exist for the KA and KL-10A processors).
> I don't know what was used for the 2020 based versions of ITS.

The 2020 ITS boxes had some kind of unibus ethernet card (forget the
manufacturuer) but only spoke Chaosnet over those interfaces.  The two
which also spoke IP did so via some kind of 1822 IMP interface box
which some nice people at, um, AMD (?) gave us on a semi-permanent
loan because they appreciated the hack value of it all.

Certainly the KLH10 IMP code used to work.  Haven't tried it recently,
but if it doesn't work now, it shouldn't be hard to fix, it's not very
complicated.
13-Feb-2004 11:25:10-PST,1461;000000000000
Return-Path: <[email protected]>
Received: from rwcrmhc11.comcast.net ([204.127.198.35]) by lingling.panda.com with TCP/SMTP; Fri, 13 Feb 2004 11:16:04 -0800 (PST)
Received: from h525405f6161e.ne.client2.attbi.com ([66.30.204.193])
         by comcast.net (rwcrmhc11) with ESMTP
         id <2004021319160201300g7uvve>; Fri, 13 Feb 2004 19:16:03 +0000
Received: (from phil@localhost)
       by ultimate.com (8.12.10/8.12.10) id i1DJG25N022576
       for [email protected]; Fri, 13 Feb 2004 14:16:02 -0500 (EST)
Date: Fri, 13 Feb 2004 14:16:02 -0500 (EST)
From: Phil Budne <[email protected]>
Message-Id: <[email protected]>
To: [email protected]
Subject: Re: Multi-homed systems

SRA wrote;
> The 2020 ITS boxes had some kind of unibus ethernet card (forget the
> manufacturuer) but only spoke Chaosnet over those interfaces.

I thought they used CH11 (Unibus to physical chaosnet) interfaces.
When the IMPs went away the only way to get to the KSs was to supdup
from a system running chaosnet.  I wondered if it would have been
possible to tunnel IP in chaosnet packets...

There was work on an Interlan NI1010A driver, but I didn't think it
ever got used for anything...  The real bitch was that the ITS TCP
code assumed that the first (and all subsequent) 4-octet group of an
IP packet came packed in an 36-bit word, and the 14-octet ethernet
header left the packets mis-aligned.

phil
(BUDD@AI)
13-Feb-2004 11:43:07-PST,1623;000000000000
Return-Path: <[email protected]>
Received: from mercury.lcs.mit.edu ([18.26.0.122]) by lingling.panda.com with TCP/SMTP; Fri, 13 Feb 2004 11:34:50 -0800 (PST)
Received: from [10.59.1.4] (napalm.ima.umn.edu [128.101.10.146])
       (using TLSv1 with cipher RC4-SHA (128/128 bits))
       (No client certificate requested)
       by mercury.lcs.mit.edu (Postfix) with ESMTP
       id 9EAFC86AE8; Fri, 13 Feb 2004 14:34:48 -0500 (EST)
Mime-Version: 1.0
X-Sender: [email protected]
Message-Id: <p06010216bc52d661d2a9@[10.59.1.4]>
In-Reply-To: <[email protected]>
References: <[email protected]>
<[email protected]>
Date: Fri, 13 Feb 2004 13:34:18 -0600
To: Rob Austein <[email protected]>,
       Tops-20 Wizards <[email protected]>
From: John Wroclawski <[email protected]>
Subject: Re: Multi-homed systems
Content-Type: text/plain; charset="us-ascii" ; format="flowed"

At 1:17 PM -0500 2/13/04, Rob Austein wrote:

>
>The 2020 ITS boxes had some kind of unibus ethernet card (forget the
>manufacturuer) but only spoke Chaosnet over those interfaces.

Sigh - I wish. The problem is that any card that used DMA was
hopeless because of the 18bit issue. The KS's all had old original
MIT-built unibus chaosnet (phy-layer) cards, which never heard of DMA
and thus worked fine, if slowly.

>The two
>which also spoke IP did so via some kind of 1822 IMP interface box
>which some nice people at, um, AMD (?) gave us on a semi-permanent
>loan because they appreciated the hack value of it all.

ACC, cnce they stopped laughing.

cheers,
john
13-Feb-2004 11:57:37-PST,1036;000000000000
Return-Path: <[email protected]>
Received: from thrintun.hactrn.net ([66.92.66.67]) by lingling.panda.com with TCP/SMTP; Fri, 13 Feb 2004 11:48:39 -0800 (PST)
Received: from thrintun.hactrn.net (localhost [IPv6:::1])
       by thrintun.hactrn.net (Postfix) with ESMTP id 97B1418E6
       for <[email protected]>; Fri, 13 Feb 2004 14:48:38 -0500 (EST)
Date: Fri, 13 Feb 2004 14:48:38 -0500
From: Rob Austein <[email protected]>
To: [email protected]
Subject: Re: Multi-homed systems
In-Reply-To: <[email protected]>
References: <[email protected]>
User-Agent: Wanderlust/2.10.1 (Watching The Wheels) Emacs/21.3 Mule/5.0 (SAKAKI)
MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen")
Content-Type: text/plain; charset=US-ASCII
Message-Id: <[email protected]>

Right, right, the ITS machines were on subnet 6, which was one of the
last two surviving physical Chaosnet subnets (the other was subnet 1,
which went to main campus).  Silly me.
13-Feb-2004 12:06:32-PST,2406;000000000000
Return-Path: <[email protected]>
Received: from mta10.srv.hcvlny.cv.net ([167.206.5.85]) by lingling.panda.com with TCP/SMTP; Fri, 13 Feb 2004 11:53:33 -0800 (PST)
Received: from optonline.net (ool-182f33c4.dyn.optonline.net [24.47.51.196])
by mta10.srv.hcvlny.cv.net
(iPlanet Messaging Server 5.2 HotFix 1.16 (built May 14 2003))
with ESMTP id <[email protected]> for
[email protected]; Fri, 13 Feb 2004 14:53:32 -0500 (EST)
Date: Fri, 13 Feb 2004 14:53:26 -0500
From: Thomas DeBellis <[email protected]>
Subject: Re: SC%MNT Shutdown
To: "Alan H. Martin" <[email protected]>
Cc: Tops-20 Wizards <[email protected]>
Message-id: <[email protected]>
MIME-version: 1.0
X-Mailer: Mozilla 4.5 [en]C-CCK-MCD BA45DSL  (WinNT; U)
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7BIT
X-Accept-Language: en
References: <[email protected]> <[email protected]>

By Golly, you're right! In order for this to work, you need

MNTU==1B10                      ;[TT9] Ditto maintainance

to be defined in EXECDE.MAC.  Whoops!  As can be seen, I
made these changes several months ago and only now finally
got around to asking where SC%MNT user code is.  I plum
forgot about poor little EXECDE!

I'm far from an Exec maven also.  As a matter of fact,
as some of my colleagues at Columbia would probably have
punned: "the farther the better" :-)  I only messed around
with the Exec when I needed to put features in for our
(much hacked) Galaxy and even thing, the changes were
always reviewed by our Exec/Monitor heros.

"Alan H. Martin" wrote:
>
> Thomas DeBellis wrote:
>
> > I don't remember what program to run and, when he enabled, he couldn't
> > get to the ^E cease command.  MRC remarked to me that these commands
> > were only for Wheels and Operators.  However, since I couldn't
> > remember what other program to run, I punted and made some simple
> > changes to EXECSU and EXECCA, which I inclose below in case anybody
> > wants them:
>
> I'm no EXEC-20 maven, but did you omit a diff for adding MNTU to
> EXECDE.MAC?  Or is that bit pre-existing in the Panda code base?
>
>                                 Hope this helps,
>                                 /AHM/THX
> --
> Alan Howard Martin                      [email protected]
13-Feb-2004 13:18:31-PST,1299;000000000000
Return-Path: <[email protected]>
Received: from dbit.com ([208.238.226.25]) by lingling.panda.com with TCP/SMTP; Fri, 13 Feb 2004 13:10:11 -0800 (PST)
Received: (from wilson@localhost)
       by dbit.com (8.11.4/8.11.4) id i1DLBfp11650
       for [email protected]; Fri, 13 Feb 2004 16:11:41 -0500
Date: Fri, 13 Feb 2004 16:11:41 -0500
From: John Wilson <[email protected]>
Message-Id: <[email protected]>
To: [email protected]
Subject: Re: Multi-homed systems

From: John Wroclawski <[email protected]>

>At 1:17 PM -0500 2/13/04, Rob Austein wrote:
>
>>The 2020 ITS boxes had some kind of unibus ethernet card (forget the
>>manufacturuer) but only spoke Chaosnet over those interfaces.
>
>Sigh - I wish. The problem is that any card that used DMA was
>hopeless because of the 18bit issue.

Huh, why did I have it in my head that you were the one working on that
(i.e. an ITS driver for the Interlan NI1010A board).  If so, was the 18-bit
thing what stopped you?  BLTUB/BLTBU weren't a good enough solution?

I started work on a DELUA driver ages ago, but lost access to the machine
before finishing it, anyway I always figured I'd use BLTUB/BLTBU to do the
repacking.

So what ran Chaos over Ethernet?  Just lispms, or not even them?

John Wilson
13-Feb-2004 15:00:38-PST,1707;000000000000
Return-Path: <[email protected]>
Received: from sj-iport-4.cisco.com ([171.68.10.86]) by lingling.panda.com with TCP/SMTP; Fri, 13 Feb 2004 14:51:33 -0800 (PST)
Received: from cisco.com (cypher.cisco.com [171.69.11.143])
       by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id i1DMpTvV001696;
       Fri, 13 Feb 2004 14:51:30 -0800 (PST)
Received: (from billw@localhost)
       by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) id OAA06106;
       Fri, 13 Feb 2004 14:51:29 -0800 (PST)
Sender: Bill Westfield <[email protected]>
Date: Fri, 13 Feb 2004 14:51:29 PST
From: William "Chops" Westfield <[email protected]>
To: Thomas DeBellis <[email protected]>
Cc: Tops-20 Wizards <[email protected]>
Subject: Re: Multi-homed systems
In-Reply-To: Your message of Fri, 13 Feb 2004 12:26:17 -0500
Message-ID: <CMM.0.90.4.1076712689.billw@cypher>

   This suggests having a machine with two interfaces.  I believe
   (although I am not sure), that DEC did not support more than
   one hardware NI per box.  Is this true?  I don't know if the
   monitor code will handle multiple NI's...

The stanford monitor code surely handles multiple MEIS (massbus ethernet)
interfaces.  There's nothing above the driver level (ie in IP or TCP) that
stops a 20 from working correctly with more than one network interface.  I
think it will even happily route packets (hmm.  Which you'll want to watch
out for, I guess.)  IIRC, the stanford monitor may also have had assorted
hacks (ie in DNS) to help it make better decisions about WHICH interface
to use when talking to other hosts...

Do the 20 emulators create a virtual NI interface, or do they have their
own drivers for the PC hardware?

BillW

13-Feb-2004 15:09:33-PST,2670;000000000000
Return-Path: <[email protected]>
Received: from out003.verizon.net ([206.46.170.103]) by lingling.panda.com with TCP/SMTP; Fri, 13 Feb 2004 14:54:16 -0800 (PST)
Received: from bellatlantic.net ([138.88.65.116]) by out003.verizon.net
         (InterMail vM.5.01.06.06 201-253-122-130-106-20030910) with ESMTP
         id <[email protected]>;
         Fri, 13 Feb 2004 16:54:15 -0600
Message-ID: <[email protected]>
Date: Fri, 13 Feb 2004 17:54:14 -0500
From: bob <[email protected]>
Reply-To:  [email protected]
User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.6) Gecko/20040113
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Thomas DeBellis <[email protected]>
CC: Tops-20 Wizards <[email protected]>
Subject: Re: Multi-homed systems
References: <[email protected]>
In-Reply-To: <[email protected]>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Authentication-Info: Submitted using SMTP AUTH at out003.verizon.net from [138.88.65.116] at Fri, 13 Feb 2004 16:54:14 -0600

Tom,
if I can offer a couple of suggestions.
you are correct, you are talking about a machine with multiple
interfaces, but reading your note, I do not think you are restricting it
to the 20 to be the machine with two interfaces.

I am not sure what your network looks like from your text description -
especially the issue of where your other nat'd vpn machines are located.
You do say you have a router but don't provide any specifics as to the
type, number of ports, etc.

Let me make an assumption, the router is ont a cisco with many ports,
and let me assume the other machines are local to your lan and running
on netwrok bits you control.  You have a single internet connection thru
your router and want to allow your machines to talk to the vpn endpoints
out there in internt land and you want them to be able to talk to the 20.

If this is correct, and I could be wrong, they you could plug in a hub
behind the router to give you more ports, or a switch - maybe onne of
the intel switches or a cisco or an equiv or a linksys or a cheap pc
with some OS that supports multi nic routing and filtering - and set
that up to allow you to share the connection behind the router.

You could set up the router to allow all traffic to the 20 only,
filtering all others the way you want.

Don't know if this helps, but if it starts a train of though or if I can
help better, give  shout
bob



--
"Only the paranoid survive..." Andy Grove


13-Feb-2004 15:30:56-PST,2739;000000000000
Mail-From: MRC created at 13-Feb-2004 15:22:39
Date: Fri, 13 Feb 2004 15:22:39 -0800 (PST)
From: Mark Crispin <[email protected]>
Subject: Re: Multi-homed systems
To: [email protected]
In-Reply-To: <CMM.0.90.4.1076712689.billw@cypher>
Pithy-Thought: TOPS-20 was a great improvement over its successors
Message-ID: <[email protected]>

> From: William "Chops" Westfield <[email protected]>
>
> The stanford monitor code surely handles multiple MEIS (massbus ethernet)
> interfaces.  There's nothing above the driver level (ie in IP or TCP) that
> stops a 20 from working correctly with more than one network interface.

I didn't mean to imply otherwise.  The limitation on the number of
KLNI/NIA20s was a hardware limitation, not a software limitation.  As I
recall, the one and only KLNI/NIA20 was on channel 5, displacing RH20 4 and
5; and the one and only CI20 was on channel 7, displacing RH20 6 and 7.

KLH10 claims to support 7 RH20s if an NI is in use; evidentally TOPS-20 will
grok this but no real KL would ever have such a configuration.

I don't know how much work it would take to have more than one NI in KLH10
and TOPS-20.  There are probably places which assumes that the unit number
is always zero, and those would have to be changed.

> I
> think it will even happily route packets

Yes, although I believe that there was a way to tell TOPS-20 not to route
packets for third parties.

> IIRC, the stanford monitor may also have had assorted
> hacks (ie in DNS) to help it make better decisions about WHICH interface
> to use when talking to other hosts...

Not that I know of.  DNS was done in Chives.  Later versions of DEC TOPS-20
had a monitor-based DNS but it had bugs (some of which I've fixed, some
which remain unfixed) sufficient to warrant staying with Chives.

TOPS-20 has a route table based upon the obsolete class-routing (A/B/C).
You can add other networks to the table to force a particular route (by
the gateway contacted) but it still assumes class-routing.  For single-homed
systems this isn't a problem since you usually only have one gateway, but
for multi-homed systems this is an issue that has to be addressed.

XKL addressed the problem in their monitor, and I have some information
(courtesy of Ralph) on how to go about doing it.  But once I realized that
the problem didn't need to be solved in the single-home case I lost interest.

> Do the 20 emulators create a virtual NI interface, or do they have their
> own drivers for the PC hardware?

KLH-10 has a virtual NIA20 for the KL version, and a virtual ACC LH-DH (ITS
IMP interface) for the KS version.  There's no MEIS, AN20, or AN22 emulator.
-------
13-Feb-2004 15:39:51-PST,2310;000000000000
Return-Path: <[email protected]>
Received: from sj-iport-5.cisco.com ([171.68.10.87]) by lingling.panda.com with TCP/SMTP; Fri, 13 Feb 2004 15:24:48 -0800 (PST)
Received: from sj-core-2.cisco.com (171.71.177.254)
 by sj-iport-5.cisco.com with ESMTP; 13 Feb 2004 15:25:58 -0800
Received: from cisco.com (cypher.cisco.com [171.69.11.143])
       by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i1DNOj4U001042;
       Fri, 13 Feb 2004 15:24:45 -0800 (PST)
Received: (from billw@localhost)
       by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) id PAA18579;
       Fri, 13 Feb 2004 15:24:44 -0800 (PST)
Sender: Bill Westfield <[email protected]>
Date: Fri, 13 Feb 2004 15:24:44 PST
From: William "Chops" Westfield <[email protected]>
To: John Wroclawski <[email protected]>
Cc: Rob Austein <[email protected]>, Tops-20 Wizards <[email protected]>
Subject: Re: Multi-homed systems
In-Reply-To: Your message of Fri, 13 Feb 2004 13:34:18 -0600
Message-ID: <CMM.0.90.4.1076714684.billw@cypher>

   > The two which also spoke IP did so via some kind of 1822 IMP interface
   > box which some nice people at, um, AMD (?) gave us on a semi-permanent
   > loan because they appreciated the hack value of it all.

   ACC, cnce they stopped laughing.

ACC made unibus 1822 interfaces that were used in quite a few arpa
projects (and some early routers as well.)  The original packet radio
"things" were pdp-11s, for example.  SRI had "SRIIMPs", which were
little LSI11 qbus/unibus kludges that spoke 1822 to assorted arpanet
hosts (PDP11s, etc) and ethernet out the back.  Not quite routers, these
were more "port expanders", I think.  It was such a pain trying to find
ethernet interfaces, or support for them, back in the bad old days.
1822 at least had funded support from DoD, albeit at DoD style prices...

ACC also made the multibus 1822 interface that cisco used to sell in the
early AGS routers.  They must have been good people, if perhaps a bit
complacent in their niche of building expensive DoD gear...

It's really a bit shocking to remember how difficult networking used to be,
back before vendors could come close to agreeing on what sort of protocols
to use (and just how long that lasted, too.)  "Get your code from a
university, and maybe your hardware too."  Sigh.

BillW

15-Feb-2004 12:31:28-PST,4806;000000000000
Return-Path: <[email protected]>
Received: from mta2.srv.hcvlny.cv.net ([167.206.5.68]) by lingling.panda.com with TCP/SMTP; Sun, 15 Feb 2004 12:22:44 -0800 (PST)
Received: from optonline.net (ool-182f33c4.dyn.optonline.net [24.47.51.196])
by mta2.srv.hcvlny.cv.net
(iPlanet Messaging Server 5.2 HotFix 1.16 (built May 14 2003))
with ESMTP id <[email protected]>; Sun,
15 Feb 2004 15:22:40 -0500 (EST)
Date: Sun, 15 Feb 2004 15:22:37 -0500
From: Thomas DeBellis <[email protected]>
Subject: Re: Multi-homed systems
To: Mark Crispin <[email protected]>
Cc: [email protected]
Message-id: <[email protected]>
MIME-version: 1.0
X-Mailer: Mozilla 4.5 [en]C-CCK-MCD BA45DSL  (WinNT; U)
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7BIT
X-Accept-Language: en
References: <[email protected]>

MRC,

I don't think I ever heard of a 20 with more than one NI, but I'm not
sure that it absolutely can not be done, electrically.  In fact, I
have some sort of a vague recollection of a brief conversation that I
had nearly 20 years ago with either our F-S guy or a (rare,
non-idiotic) sales person.

The gist of the conversation was that it was, in fact, electrically
possible to have multiple NI's per machine.  You would just burn up 4
RH slots doing it.  As the 20 only had 7 RH slots, this was not
something that you wanted to do.  In fact, I remember part of the
conversation being me grumbling about the CI and NI combo taking up so
much room.

I don't remember exactly how many years we had NI's at Columbia.  I
know that we got the CI hardware fairly early as part of DEC's attempt
to keep us in the fold (we eventually moved to Sun4s, etc).  As I
recall, the common file system software was too late for us to do a
summer beta test, so I don't think we got things into production for
another six months to a year.  I guess we had an NI for about three
years, though.

With respect to managing multiple NI's: at the minimum, it would
appear that there would be a number of changes that would need to be
made to the available management interfaces.

The NI and CI can be set on and off line with Galaxy.  Allowing
mutiple NI's would mean modifications to OPRSCM to change the parse
tables.  I guess between 6 and 7, they moved the SETFDB stuff there,
out of OPRCMD.  This must imply cooresponding modifications to OPRQSR
to grovel the new token stream and execute the appropriate semantic
actions with the NI% JSYS.

IPHOST is, of course, another and perhaps more logical place to put
this stuff, but I don't know much about it.  It wasn't clear where DEC
was going to finally architect the actual management interface.  It
might have made sense to put this functionality into Galaxy, as this
would then have allowed tweaking one system's NI via communications
coming over the CI from another machine.

With respect to the NI% JSYS, itself, I did a little poking around to
see what it would need.  The direct dispatching and some logic
implementation are in NIUSR.MAC.  My understanding is that the jsys
allows you to allocate multiple handles, called 'portals' on the NI.
Once you have one of these, you can then read and write stuff.  How
come they didn't make an NI device and use JFN's like the FE?  That
seems more intuitive.

Part of the NI% JSYS request block that is passed into the monitor
contains a field called .EICHN which appears to be for the RH channel.
NIUOPN: in NIUSR.MAC dutifully loads into UNCHN field of a NI portal
structure.  This gets handed off to NISRV.MAC where DLLOPN does the
actual work.  So the high level routines look like they would handle
things correctly.

Since the channel field is defined and populated, it may very well be
that PI service code would pull the information out and use it
properly.  The problem appears to be in PHYKNI when we start getting
closer to the actual 'metal'.  NIINI:, the NI initialization logic,
appears to be HARDWARED to assume that only one (1) NI exists and that
it is in channel five (5).  There aren't even any definitions--it's a
MOVX T1,5 to set the index for CHNTAB...

                           ... Poopers ...

So anyway, to get back to the virtual ACC LH-DH (ITS IMP interface)
for the KS version: how close is one of these to an AN20?  Maybe the
easier thing to do would be to modify it to turn it into an AN20?
Columbia had at least one AN20, but I can't remember where the heck it
plugged in.  I don't think it sat on the RH.  I think it either
plugged into a DTE slot or (this is some real crufty recollections
here), was plugged into the card eater ports on the front end?

Of course, maybe I'm going about this the whole wrong way ...

                                --T
15-Feb-2004 13:02:09-PST,2611;000000000000
Return-Path: <[email protected]>
Received: from jalapeno.cc.columbia.edu ([128.59.59.238]) by lingling.panda.com with TCP/SMTP; Sun, 15 Feb 2004 12:53:48 -0800 (PST)
Received: from columbia.edu (pcp08508164pcs.verona01.nj.comcast.net [68.37.79.45])
       (user=rossman mech=PLAIN bits=0)
       by jalapeno.cc.columbia.edu (8.12.11/8.12.11) with ESMTP id i1FKrhjU008352
       (version=TLSv1/SSLv3 cipher=DES-CBC3-SHA bits=168 verify=NOT);
       Sun, 15 Feb 2004 15:53:44 -0500 (EST)
Date: Sun, 15 Feb 2004 15:53:41 -0500
Subject: Re: Multi-homed systems
Content-Type: text/plain; charset=US-ASCII; format=flowed
Mime-Version: 1.0 (Apple Message framework v553)
Cc: Ken Rossman <[email protected]>
To: [email protected]
From: Ken Rossman <[email protected]>
In-Reply-To: <[email protected]>
Message-Id: <[email protected]>
Content-Transfer-Encoding: 7bit
X-Mailer: Apple Mail (2.553)
X-No-Spam-Score: Local
X-Scanned-By: MIMEDefang 2.35

> Thomas DeBellis wrote:
>
> I don't think I ever heard of a 20 with more than one NI, but I'm not
> sure that it absolutely can not be done, electrically...

I think it was much more a case of not enough space in there.  Things
were
much bigger back then.

> I don't remember exactly how many years we had NI's at Columbia.

I don't recall it being all that long, actually.  Seems to me they got
installed very late in the game -- I'll bet we only had them a couple of
years before the whole KL thing was canned by DEC, and we started
looking
at VAXen, and later on, at Suns.

> I know that we got the CI hardware fairly early as part of DEC's
> attempt
> to keep us in the fold (we eventually moved to Sun4s, etc).  As I
> recall,
> the common file system software was too late for us to do a summer beta
> test, so I don't think we got things into production for another six
> months
> to a year.  I guess we had an NI for about three years, though.

Sounds about right.  I don't think we ever really did anything truly
fancy with the CI, like real file sharing and such.  I seem to remember
only using it to get at those spiffy new (at the time) RA disks, in a
host-to-dedicated-disk type assignment.

Did TOPS-20 ever really allow true filesharing over the CI?  I don't
recall.

> How come they didn't make an NI device and use JFN's like the FE?
> That seems more intuitive.

Same here.  There were certain design decisions, especially towards the
end, that I never really understood.  But I am probably oversimplifying
the problem in my own mind...

KR

15-Feb-2004 14:46:12-PST,1506;000000000000
Return-Path: <[email protected]>
Received: from sj-iport-2.cisco.com ([171.71.176.71]) by lingling.panda.com with TCP/SMTP; Sun, 15 Feb 2004 14:37:06 -0800 (PST)
Received: from sj-core-2.cisco.com (171.71.177.254)
 by sj-iport-2.cisco.com with ESMTP; 15 Feb 2004 14:45:28 +0000
Received: from cisco.com (cypher.cisco.com [171.69.11.143])
       by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i1FMb24U009843;
       Sun, 15 Feb 2004 14:37:02 -0800 (PST)
Received: (from billw@localhost)
       by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) id OAA22933;
       Sun, 15 Feb 2004 14:37:02 -0800 (PST)
Sender: Bill Westfield <[email protected]>
Date: Sun, 15 Feb 2004 14:37:02 PST
From: William "Chops" Westfield <[email protected]>
To: Thomas DeBellis <[email protected]>
Cc: Mark Crispin <[email protected]>, [email protected]
Subject: Re: Multi-homed systems
In-Reply-To: Your message of Sun, 15 Feb 2004 15:22:37 -0500
Message-ID: <CMM.0.90.4.1076884622.billw@cypher>

   The gist of the conversation was that it was, in fact, electrically
   possible to have multiple NI's per machine.  You would just burn up 4
   RH slots doing it.  As the 20 only had 7 RH slots, this was not
   something that you wanted to do.

I thought the NI/CI prep required that you use up the RH slots for
the other one anyway.  You got an add-on box that used 4 slots, and
you could put either NI, CI, or both, in it...  However, I was only
on the periphery of those decisions/debates.

BillW

15-Feb-2004 15:01:22-PST,1388;000000000000
Return-Path: <[email protected]>
Received: from sj-iport-5.cisco.com ([171.68.10.87]) by lingling.panda.com with TCP/SMTP; Sun, 15 Feb 2004 14:52:26 -0800 (PST)
Received: from sj-core-4.cisco.com (171.68.223.138)
 by sj-iport-5.cisco.com with ESMTP; 15 Feb 2004 14:52:33 -0800
Received: from cisco.com (cypher.cisco.com [171.69.11.143])
       by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id i1FMqNcw022052;
       Sun, 15 Feb 2004 14:52:24 -0800 (PST)
Received: (from billw@localhost)
       by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) id OAA23879;
       Sun, 15 Feb 2004 14:52:23 -0800 (PST)
Sender: Bill Westfield <[email protected]>
Date: Sun, 15 Feb 2004 14:52:23 PST
From: William "Chops" Westfield <[email protected]>
To: Ken Rossman <[email protected]>
Cc: [email protected], Ken Rossman <[email protected]>
Subject: Re: Multi-homed systems
In-Reply-To: Your message of Sun, 15 Feb 2004 15:53:41 -0500 -0500
Message-ID: <CMM.0.90.4.1076885543.billw@cypher>

>> Did TOPS-20 ever really allow true filesharing over the CI?

Didn't Stanford LOTS end up doing CI/CFS sharing between their three
dec-20s?  (four?  There was a system used for testing, and I don't recall
whether it was tied to the same filesystem as the production machines.  Then
there was the Systems Concept machine, which I think was supposed to
participate in CFS as well.)

BillW



6-Mar-2004 11:24:56-PST,2678;000000000000
Return-Path: <[email protected]>
Received: from mta10.srv.hcvlny.cv.net ([167.206.5.85]) by lingling.panda.com with TCP/SMTP; Sat, 6 Mar 2004 11:17:40 -0800 (PST)
Received: from optonline.net (ool-182f33c4.dyn.optonline.net [24.47.51.196])
by mta10.srv.hcvlny.cv.net
(iPlanet Messaging Server 5.2 HotFix 1.16 (built May 14 2003))
with ESMTP id <[email protected]> for
[email protected]; Sat, 06 Mar 2004 14:17:39 -0500 (EST)
Date: Sat, 06 Mar 2004 14:17:35 -0500
From: Thomas DeBellis <[email protected]>
Subject: FR.NOS or Your system clock really isn't slowing down, is it?
To: Tops-20 Wizards <[email protected]>
Message-id: <[email protected]>
MIME-version: 1.0
X-Mailer: Mozilla 4.5 [en]C-CCK-MCD BA45DSL  (WinNT; U)
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7BIT
X-Accept-Language: en
X-Priority: 4 (Low)

I often leave a window running SYSDPY overnight to keep an eye on
things.  What I've noticed is that no matter what sampling interval is
that one choses, SYSDPY always slows the wait time down to about three
minutes by the morning.  Was the KLH10 clock losing time while the
system was idle??

I quickly knocked together a Tops-20 assembler version of the non-
intuitively named Unix 'sleep' command.  My WAIT cusp takes the number
of seconds to wait from the rescan buffer, does a DISMS% for that many
milliseconds and then sees how much time has passed when it next runs
again.

On an otherwise unloaded system, I did a large number of runs with a
couple of simultaneous batch streams.  The results were that the wall
times that I measured were, with one exception, always within a second
granularity (my algorithm rounds the difference of GTAD% times to the
half second).  Where WAIT did not pause for the exact amount of time,
it was usually a second early, which happened in about 1/3 of the
cases.

So, I finally had a look at SYSDPY.  It's supposed to do what it is
doing...  No matter what wait interval you set, it degrades the wait
time to three minutes.  So, it's a feature: if you want the wait time
to be consistent, then you must type the number followed by a trailing
exclaimation point: w15!, for example.

That's kind of groovy: it seems to me that the obvious purpose of the
command is to keep impatient people from ruining the response time on
already loaded systems.  However, I don't remember this feature of
SYSDPY, although it looks like it's been in there since at least 1982.
I didn't see it documented in any of the SWSKIT stuff that I have,
either.  Anybody have any SYSDPY lore to share on this?
6-Mar-2004 21:08:32-PST,1373;000000000000
Return-Path: <[email protected]>
Received: from Ikkoku-Kan.Panda.COM (panda.com [206.124.149.114]) by lingling.panda.com with TCP/SMTP; Sat, 6 Mar 2004 21:02:04 -0800 (PST)
Received: from Ikkoku-Kan.Panda.COM (Ikkoku-Kan.Panda.COM [192.107.14.50]) by Ikkoku-Kan.Panda.COM id VAA18071; Sat, 6 Mar 2004 21:01:59 -0800 (PST)
Date: Sat, 6 Mar 2004 20:59:12 -0800 (PST)
From: Mark Crispin <[email protected]>
Sender: Mark Crispin <[email protected]>
Subject: re: FR.NOS or Your system clock really isn't slowing down, is it?
To: Thomas DeBellis <[email protected]>
cc: Tops-20 Wizards <[email protected]>
In-Reply-To: <[email protected]>
Message-ID: <[email protected]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII

On Sat, 06 Mar 2004 14:17:35 -0500, Thomas DeBellis wrote:
> However, I don't remember this feature of
> SYSDPY, although it looks like it's been in there since at least 1982.
> I didn't see it documented in any of the SWSKIT stuff that I have,
> either.  Anybody have any SYSDPY lore to share on this?

As far as I know, SYSDPY has always gradually increased its wait interval as
it runs without any further command input.  Or, at least, I don't recall it
operating in any other way.  Of course, as the years go by, our memories can
become defective.

16-Mar-2004 07:25:36-PST,1586;000000000000
Return-Path: <[email protected]>
Received: from out012.verizon.net ([206.46.170.137]) by lingling.panda.com with TCP/SMTP; Tue, 16 Mar 2004 07:17:31 -0800 (PST)
Received: from bellatlantic.net ([141.156.146.205]) by out012.verizon.net
         (InterMail vM.5.01.06.06 201-253-122-130-106-20030910) with ESMTP
         id <[email protected]>
         for <[email protected]>; Tue, 16 Mar 2004 09:17:29 -0600
Message-ID: <[email protected]>
Date: Tue, 16 Mar 2004 10:17:28 -0500
From: bob <[email protected]>
Reply-To:  [email protected]
User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.6) Gecko/20040113
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Tops-20 Wizards <[email protected]>
Subject: really dumb question
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Authentication-Info: Submitted using SMTP AUTH at out012.verizon.net from [141.156.146.205] at Tue, 16 Mar 2004 09:17:29 -0600

Apologies, this is really dumb:
I forgot the operator password that I set on KLH/Tops20 box.
I have tried all the passwords I can think of that I would have used.
I have searched the news archives, and I can't seem to find what my
memory says was a way to do this at boot up time.
I am looking thru the manuals, to see if I can find what I think I
remember but no luck.
Does any one have a hint on how to do this without reinstalling?
thanks
bob
--
"Only the paranoid survive..." Andy Grove


16-Mar-2004 08:24:05-PST,1303;000000000000
Return-Path: <[email protected]>
Received: from Ikkoku-Kan.Panda.COM (panda.com [206.124.149.114]) by lingling.panda.com with TCP/SMTP; Tue, 16 Mar 2004 08:16:51 -0800 (PST)
Received: from Ikkoku-Kan.Panda.COM (Ikkoku-Kan.Panda.COM [192.107.14.50]) by Ikkoku-Kan.Panda.COM id IAA25072; Tue, 16 Mar 2004 08:16:19 -0800 (PST)
Date: Tue, 16 Mar 2004 07:58:32 -0800 (PST)
From: Mark Crispin <[email protected]>
Sender: Mark Crispin <[email protected]>
Subject: re: really dumb question
To: [email protected]
cc: Tops-20 Wizards <[email protected]>
In-Reply-To: <[email protected]>
Message-ID: <[email protected]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII

The easiest way around the problem is to boot the system with password
checking disabled, then change the OPERATOR password.

Start the system in EDDT
Set DBUGSW/2 and EDDTF/1
Set a breakpoint at GOTSWM
Start at 147
When the breakpoint hits, look at location CHKPSX.  Make sure that it contains
JSP CX,SAVQ then patch it to be JRST RSKP  You may have to do $W first.
Remove the breakpoint with 0$1B, then resume the system with 1,,GOTSWM$G
(*not* with $P or GOTSWM$G).
Once started, you should be able to log in as any user with any password.

16-Mar-2004 14:24:22-PST,625;000000000000
Mail-From: MRC created at 16-Mar-2004 14:16:56
Date: Tue, 16 Mar 2004 14:16:56 -0800 (PST)
From: Mark Crispin <[email protected]>
Subject: another TOPS-20 system heading for an UP2LNG...
To: [email protected]
Pithy-Thought: TOPS-20 was a great improvement over its successors
Message-ID: <[email protected]>

I have a TOPS-20 system running on a VMware virtual machine with an uptime
of 9041 hours, meaning that in a little over 20 days it will crash with an
UP2LNG.  I believe that this will be the second UP2LNG in history (the first
happened at XKL a few years ago).
-------
19-Mar-2004 20:05:55-PST,2015;000000000000
Return-Path: <[email protected]>
Received: from mta10.srv.hcvlny.cv.net ([167.206.5.85]) by Lingling.Panda.COM with TCP/SMTP; Fri, 19 Mar 2004 19:57:33 -0800 (PST)
Received: from optonline.net (ool-182f33c4.dyn.optonline.net [24.47.51.196])
by mta10.srv.hcvlny.cv.net
(iPlanet Messaging Server 5.2 HotFix 1.16 (built May 14 2003))
with ESMTP id <[email protected]> for
[email protected]; Fri, 19 Mar 2004 22:57:15 -0500 (EST)
Date: Fri, 19 Mar 2004 22:57:10 -0500
From: Thomas DeBellis <[email protected]>
Subject: TECO, Symbols and TEXTI%
To: Tops-20 Wizards <[email protected]>
Message-id: <[email protected]>
MIME-version: 1.0
X-Mailer: Mozilla 4.5 [en]C-CCK-MCD BA45DSL  (WinNT; U)
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7BIT
X-Accept-Language: en

This is a two part question.  It is basically concerned with the
operation of EMACS under a PANDA monitor when logged in on a TVT--the
typical case these days.

I happened to be doing a SYSDPY while looking at something else and
noticed that my EMACS fork was waiting in a PBIN%.  I thought that
Emacs was supposed to be using the TEXTI% Emacs mode?

Anyway, I had a look at the obvious stuff.  The COMND module shows
that the monitor has support for RD%EMC.  I searched the TECO
executable with DDT and found JSYS 524 just like it's supposed to be
there ...

 1) Why isn't TEXTI% being used?

I started looking at the Midas code and built a new version of TECO
with symbols.  I reviewed CONV.INFO and did some dumpage.  However, I
can't remember how to build a useful TECO executable with symbols.  I
don't remember how to generate TECPUR, either.  I can't remember how
to do anything useful with the TECO.SYMBOLS file, either.  FILDDT
won't load it.

2) How do I build a Teco/Emacs with symbols so I can do the XDDT
   thing?

Where is all this documented?  I nosed around in INFO; I guess I
overlooked something...

20-Mar-2004 00:18:56-PST,1200;000000000000
Return-Path: <[email protected]>
Received: from Ikkoku-Kan.Panda.COM (panda.com [206.124.149.114]) by lingling.panda.com with TCP/SMTP; Sat, 20 Mar 2004 00:11:32 -0800 (PST)
Received: from Ikkoku-Kan.Panda.COM (Ikkoku-Kan.Panda.COM [192.107.14.50]) by Ikkoku-Kan.Panda.COM id AAA10682; Sat, 20 Mar 2004 00:11:28 -0800 (PST)
Date: Sat, 20 Mar 2004 00:06:38 -0800 (PST)
From: Mark Crispin <[email protected]>
Sender: Mark Crispin <[email protected]>
Subject: re: TECO, Symbols and TEXTI%
To: Thomas DeBellis <[email protected]>
cc: Tops-20 Wizards <[email protected]>
In-Reply-To: <[email protected]>
Message-ID: <[email protected]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII

If you look at the PC, you'll see that it's at TYIIOT, whereas the TEXTI is
being done in the RRECIN routine (at RRECI7).  A little bit of empirical
testing shows that it does a TEXTI if a printable character was the last one
input *and* it's at the end of the line, and a PBIN otherwise.  So it looks
like it's doing the right thing.

There's a CTL file in the <EMACS> directory which shows how the build is done.

20-Mar-2004 12:56:44-PST,2954;000000000000
Return-Path: <[email protected]>
Received: from mta2.srv.hcvlny.cv.net ([167.206.5.68]) by lingling.panda.com with TCP/SMTP; Sat, 20 Mar 2004 12:49:12 -0800 (PST)
Received: from optonline.net (mstr3.srv.hcvlny.cv.net [167.206.5.14])
by mta2.srv.hcvlny.cv.net
(iPlanet Messaging Server 5.2 HotFix 1.16 (built May 14 2003))
with ESMTP id <[email protected]>; Sat,
20 Mar 2004 15:49:05 -0500 (EST)
Received: from [167.206.5.73] by mstr3.srv.hcvlny.cv.net (mshttpd); Sat,
20 Mar 2004 15:48:39 -0500
Date: Sat, 20 Mar 2004 15:48:39 -0500
From: [email protected]
Subject: Re: re: TECO, Symbols and TEXTI%
To: Mark Crispin <[email protected]>
Cc: Tops-20 Wizards <[email protected]>
Message-id: <[email protected]>
MIME-version: 1.0
X-Mailer: iPlanet Messenger Express 5.2 HotFix 1.16 (built May 14 2003)
Content-type: text/plain; charset=us-ascii
Content-language: en
Content-transfer-encoding: 7BIT
Content-disposition: inline
X-Accept-Language: en
Priority: normal

Oh yeah...  Anyway, in the interests of possibly saving some other
people time:

The TEXTI% must have slipped past me because I used the old KA-10
tried and true method of program break.  You deposit a 0 in the
location you want to stop at.  When the program hits the zero, it
'breaks'...  So, I dropped in a 0 at 13671 and ...

There is an ERJMP after the TEXTI% that I didn't notice (because all
the symbols were purged).  So, TECO took the error jump, properly
saw that nothing was read and then landed into the PBIN%.

Using regular XDDT to set a breakpoint didn't work either, although I
cain't say why...  I put DDT in section 30, so I didn't gronk
EMACS.:EJ, that shouldn't have done anything, should it?  Anyway, I
wonder why the breakpoint didn't work.

I don't know why I didn't think to use a SET TRAP JSYS TEXTI from the
Exec.  That picked it up right away.  Late night hacking...


The control file that you mention is there, but it didn't look like it
would have worked.  It asked for nmidas which I don't have.  I assume
that I could just use regular midas?  It also asks for nddt, which I
don't have.

I looked around at every DDT in PS:<SUBSYS> and none of them handle
;y.  It's IDDT, right?  The TECO dumps it's symbols into TECO.SYMBOLS
and then tosses them.  To debug, you run IDDT and use yank to get
those symbols in, right.  I forgot about that.

However, I thought that IDDT was an Exec command (at least it was at
Columbia).  This it caused the EXEC to splice a fork containing IDDT
in between itself and the program to be debugged.  With the PANDA
Exec, you have to do a ;y and ;o to get everything.

So, how do I IDDT a fork that is gronked now?  At Columbia, we had an
extra ^E command called SPLICE.  It enabled you to move forks around
and change who's superior (or inferior) was what.  It was quite
useful for random hacking.


20-Mar-2004 21:50:07-PST,974;000000000000
Return-Path: <[email protected]>
Received: from Ikkoku-Kan.Panda.COM (panda.com [206.124.149.114]) by lingling.panda.com with TCP/SMTP; Sat, 20 Mar 2004 21:42:48 -0800 (PST)
Received: from Ikkoku-Kan.Panda.COM (Ikkoku-Kan.Panda.COM [192.107.14.50]) by Ikkoku-Kan.Panda.COM id VAA11263; Sat, 20 Mar 2004 21:42:46 -0800 (PST)
Date: Sat, 20 Mar 2004 21:40:45 -0800 (PST)
From: Mark Crispin <[email protected]>
Sender: Mark Crispin <[email protected]>
Subject: Re: re: TECO, Symbols and TEXTI%
To: TOPS-20 Hackers and Yackers <[email protected]>
In-Reply-To: <[email protected]>
Message-ID: <[email protected]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII

On Sat, 20 Mar 2004 15:48:39 -0500, [email protected] wrote:
> I looked around at every DDT in PS:<SUBSYS> and none of them handle
> ;y.  It's IDDT, right?

IDDT is in PS:<UNSUPPORTED>, which is part of SYS:

27-Mar-2004 17:25:16-PST,1576;000000000000
Return-Path: <[email protected]>
Received: from out014.verizon.net ([206.46.170.46]) by lingling.panda.com with TCP/SMTP; Sat, 27 Mar 2004 17:16:59 -0800 (PST)
Received: from bellatlantic.net ([141.156.146.205]) by out014.verizon.net
         (InterMail vM.5.01.06.06 201-253-122-130-106-20030910) with ESMTP
         id <[email protected]>
         for <[email protected]>; Sat, 27 Mar 2004 19:16:57 -0600
Message-ID: <[email protected]>
Date: Sat, 27 Mar 2004 20:16:57 -0500
From: bob <[email protected]>
Reply-To:  [email protected]
User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.6) Gecko/20040113
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Tops-20 Wizards <[email protected]>
Subject: Slightly off topic
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Authentication-Info: Submitted using SMTP AUTH at out014.verizon.net from [141.156.146.205] at Sat, 27 Mar 2004 19:16:57 -0600

Is anyone using a sony PS2 as an emulator host?
I am just installing linux on it now, plan to compile KLH on it, and see
if I can bring it up as a TOPS 20 machine.
bob
--
Good intentions will always be pleaded for any assumption of power. The
Constitution was made to guard the people against the dangers of good
intentions. There are men in all ages who mean to govern well, but they
mean to govern. They promise to be good masters ... but they mean to be
masters.

Daniel Webster


6-Apr-2004 15:00:33-PDT,589;000000000000
Mail-From: MRC created at  6-Apr-2004 14:53:10
Date: Tue, 6 Apr 2004 14:53:10 -0700 (PDT)
From: Mark Crispin <[email protected]>
Subject: what happens when TOPS-20 on a KLH-10 system hits UP2LNG
To: [email protected]
Pithy-Thought: TOPS-20 was a great improvement over its successors
Message-ID: <[email protected]>

Well, the appointed time came, and TOPS-20 did not crash.  As soon as
RDTIME T1 started to return greater than 17,,477777 777777,,777777, the
DIV T1,BASTIM (where BASTIM/ 17,,500000) set No Divide.  Time then stopped.
-------
6-Apr-2004 15:33:16-PDT,1147;000000000000
Mail-From: MRC created at  6-Apr-2004 15:26:14
Date: Tue, 6 Apr 2004 15:26:14 -0700 (PDT)
From: Mark Crispin <[email protected]>
Subject: more on failed UP2LNG
To: [email protected]
Pithy-Thought: TOPS-20 was a great improvement over its successors
Message-ID: <[email protected]>

Well, I now see why that system did not crash with an UP2LNG, but XKL's
system did.  The code as distributed by DEC is buggy and an UP2LNG can't
happen!

The DEC code reads:
UPDTCK: RDTIME T1
       DIV T1,BASDIV
       MOVEM T1,TODCLK
       MOVEM T1,TODPWL
       JUMPGE T1,R
       XCT UP2LNG

This code can never actually trigger an UP2LNG, because when T1
reaches BASDIV, DIV will set overflow and no divide and leave T1
unchanged.  This, in turn, will cause TODCLK and TODPWL to jump
backwards in time over a year.

The XKL code reads:

UPDTCK: RDTIME T1
       DSUB T1,TIMBAS
       SKIPL T1
        CAML T1,BASDIV
         XCT UP2LNG
       DIV T1,BASDIV

I don't understand what subtracting TIMBAS is for, since TIMBAS
is continuously updated, but perhaps XKL processors work
differently.  However, XKL's version is definitely correct.
-------
6-Apr-2004 15:44:57-PDT,1268;000000000000
Return-Path: <[email protected]>
Received: from service0 ([68.162.234.181]) by Lingling.Panda.COM with TCP/SMTP; Tue, 6 Apr 2004 15:37:15 -0700 (PDT)
Received: from RCN.Com (ralfie.etnus.com [192.168.68.75])
       by service0 (Postfix) with ESMTP
       id 3F9B9FC009; Tue,  6 Apr 2004 18:36:33 -0400 (EDT)
Sender: [email protected]
Message-ID: <[email protected]>
Date: Tue, 06 Apr 2004 18:36:27 -0400
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: Mark Crispin <[email protected]>
Cc: [email protected]
Subject: Re: what happens when TOPS-20 on a KLH-10 system hits UP2LNG
References: <[email protected]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Mark Crispin wrote:
>
> Well, the appointed time came, and TOPS-20 did not crash.  As soon as
> RDTIME T1 started to return greater than 17,,477777 777777,,777777, the
> DIV T1,BASTIM (where BASTIM/ 17,,500000) set No Divide.  Time then stopped.
> -------

http://www.hatori42.com/lib/The%20Nine%20Billion%20Names%20of%20God.htm
                               /AHM
--
Alan Howard Martin                      [email protected]
6-Apr-2004 15:52:28-PDT,1953;000000000000
Return-Path: <[email protected]>
Received: from out004.verizon.net ([206.46.170.142]) by Lingling.Panda.COM with TCP/SMTP; Tue, 6 Apr 2004 15:38:41 -0700 (PDT)
Received: from bellatlantic.net ([141.156.146.205]) by out004.verizon.net
         (InterMail vM.5.01.06.06 201-253-122-130-106-20030910) with ESMTP
         id <[email protected]>
         for <[email protected]>; Tue, 6 Apr 2004 17:38:40 -0500
Message-ID: <[email protected]>
Date: Tue, 06 Apr 2004 18:38:39 -0400
From: bob <[email protected]>
Reply-To:  [email protected]
User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.6) Gecko/20040113
X-Accept-Language: en-us, en
MIME-Version: 1.0
To:  [email protected]
Subject: Re: what happens when TOPS-20 on a KLH-10 system hits UP2LNG
References: <[email protected]>
In-Reply-To: <[email protected]>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Authentication-Info: Submitted using SMTP AUTH at out004.verizon.net from [141.156.146.205] at Tue, 6 Apr 2004 17:38:40 -0500

Cool, now what happens if you start rolling the clock backwards, do you
go back in time?
Sorry Mark, Could not resist, but you know that!!
bad bob

Mark Crispin wrote:

> Well, the appointed time came, and TOPS-20 did not crash.  As soon as
> RDTIME T1 started to return greater than 17,,477777 777777,,777777, the
> DIV T1,BASTIM (where BASTIM/ 17,,500000) set No Divide.  Time then stopped.
> -------
>

--
Good intentions will always be pleaded for any assumption of power. The
Constitution was made to guard the people against the dangers of good
intentions. There are men in all ages who mean to govern well, but they
mean to govern. They promise to be good masters ... but they mean to be
masters.

Daniel Webster

11-Apr-2004 18:14:32-PDT,1280;000000000000
Return-Path: <[email protected]>
Received: from jalapeno.cc.columbia.edu ([128.59.59.238]) by lingling.panda.com with TCP/SMTP; Sun, 11 Apr 2004 18:07:05 -0700 (PDT)
Received: from columbia.edu (pcp09163523pcs.verona01.nj.comcast.net [69.141.118.203])
       (user=rossman mech=PLAIN bits=0)
       by jalapeno.cc.columbia.edu (8.12.11/8.12.11) with ESMTP id i3C173XL003630
       (version=TLSv1/SSLv3 cipher=DES-CBC3-SHA bits=168 verify=NOT)
       for <[email protected]>; Sun, 11 Apr 2004 21:07:04 -0400 (EDT)
Date: Sun, 11 Apr 2004 21:07:03 -0400
Subject: RSX20F
Content-Type: text/plain; charset=US-ASCII; format=flowed
Mime-Version: 1.0 (Apple Message framework v553)
From: Ken Rossman <[email protected]>
To: [email protected]
Content-Transfer-Encoding: 7bit
In-Reply-To: <[email protected]>
Message-Id: <[email protected]>
X-Mailer: Apple Mail (2.553)
X-No-Spam-Score: Local
X-Scanned-By: MIMEDefang 2.40

OK, so we're going well back way past the KL emulators running on Linux
to the real DEC-20 systems now...

Who all out there worked much with the RSX20F front end stuff on a
DEC-20?
Anyone remember what exactly the task named TKTN.EXE did?  How about
KLXFER.EXE?

K

11-Apr-2004 20:12:28-PDT,1774;000000000000
Return-Path: <[email protected]>
Received: from scaup.mail.pas.earthlink.net ([207.217.120.49]) by lingling.panda.com with TCP/SMTP; Sun, 11 Apr 2004 20:05:18 -0700 (PDT)
Received: from cpe-24-221-177-162.ca.sprintbbd.net ([24.221.177.162] helo=reststop.com)
       by scaup.mail.pas.earthlink.net with esmtp (Exim 3.33 #1)
       id 1BCrl7-0000sw-00; Sun, 11 Apr 2004 20:05:17 -0700
Date: Sun, 11 Apr 2004 20:05:12 -0700
Subject: Re: RSX20F
Content-Type: text/plain; charset=US-ASCII; format=flowed
Mime-Version: 1.0 (Apple Message framework v553)
Cc: [email protected] (Tops-20 Wizards)
To: Ken Rossman <[email protected]>
From: Carl Baltrunas <[email protected]>
In-Reply-To: <[email protected]>
Message-Id: <[email protected]>
Content-Transfer-Encoding: 7bit
X-Mailer: Apple Mail (2.553)

Being more of a TOPS-10 person rather than TOPS-20 I must ask, is the
EXE file you're asking about residing on the TOPS-20 disk or on the
RSX20F disk?

KLXFER was a program that allowed cooperating processes to transfer
files from the front-end file system to the TOPS-10/20 file system
while the OS is up and running.
On the console, you could enter commands to switch back and forth to
talking to RSX20F and the KL, but I haven't used them for 24+ years, so
my memory is foggy.

I have no idea what TKTN is.

-Carl

On Sunday, April 11, 2004, at 06:07 PM, Ken Rossman wrote:

> OK, so we're going well back way past the KL emulators running on Linux
> to the real DEC-20 systems now...
>
> Who all out there worked much with the RSX20F front end stuff on a
> DEC-20?
> Anyone remember what exactly the task named TKTN.EXE did?  How about
> KLXFER.EXE?
>
> K
>

11-Apr-2004 21:21:40-PDT,2307;000000000000
Return-Path: <[email protected]>
Received: from epsilon3.corestore.org ([216.220.114.27]) by lingling.panda.com with TCP/SMTP; Sun, 11 Apr 2004 21:13:53 -0700 (PDT)
Return-Path: <[email protected] ([68.198.25.144])>
Received: from ool-44c61990.dyn.optonline.net ([68.198.25.144]) by epsilon3.corestore.org id 849 ; Mon, 12 Apr 2004 00:43:40 -0400
From: Michael Ross <[email protected]>
To: Carl Baltrunas <[email protected]>
Cc: Ken Rossman <[email protected]>, [email protected] (Tops-20 Wizards)
Subject: Re: RSX20F
Date: Mon, 12 Apr 2004 00:11:02 -0400
Message-ID: <[email protected] ([68.198.25.144])>
References: <[email protected]> <[email protected] ([206.124.149.115])>
In-Reply-To: <[email protected] ([206.124.149.115])>
X-Mailer: Forte Agent 1.93/32.576 English (American)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable

On Sun, 11 Apr 2004 20:05:12 -0700, you wrote:


>I have no idea what TKTN is.
>
>-Carl
>
>On Sunday, April 11, 2004, at 06:07 PM, Ken Rossman wrote:
>> Anyone remember what exactly the task named TKTN.EXE did?  How about=20
>> KLXFER.EXE?

=46rom the TOPS-20 System Manager's Guide:

TKTN.TSK Terminates tasks, reports errors, and requests reloads.

Also, from generic RSX-11 documentation:

help tktn

TKTN is the Task Termination Notification program.  When a task
aborts, TKTN displays the cause of the abort and the contents of the
task's registers on the terminal from which the task was running.

TKTN also displays device driver messages on the console, notifying
the operator when a device is not ready or when a device has been
dismounted.

See the RSX-11M-PLUS MCR Operations Manual or the RSX-11M-PLUS
Command Language Manual for a description of the TKTN messages.

In other words, it's not specific to RSX-20F.

<drastic topic-switch: Help. Anyone got any spare Massbus tape drives?
TU45? TU77?. I've got two dodgy TE16s, and two dodgy TU45s, and
they're all 4,000 miles from my 2065... Thanks!>

Mike
http://www.corestore.org

'As I walk along these shores
I am the history within'
11-Apr-2004 21:32:20-PDT,1008;000000000000
Return-Path: <[email protected]>
Received: from Ikkoku-Kan.Panda.COM (panda.com [206.124.149.114]) by lingling.panda.com with TCP/SMTP; Sun, 11 Apr 2004 21:25:10 -0700 (PDT)
Received: from Ikkoku-Kan.Panda.COM (Ikkoku-Kan.Panda.COM [192.107.14.50]) by Ikkoku-Kan.Panda.COM id VAA05565; Sun, 11 Apr 2004 21:25:09 -0700 (PDT)
Date: Sun, 11 Apr 2004 21:21:12 -0700 (PDT)
From: Mark Crispin <[email protected]>
Sender: Mark Crispin <[email protected]>
Subject: Re: RSX20F
To: Tops-20 Wizards <[email protected]>
In-Reply-To: <[email protected]>
Message-ID: <[email protected]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII

TKTN.TSK (not .EXE) was an RSX task that terminates tasks, reports errors, and
requests reboots.

I don't remember KLXFER.  Maybe it was TOPS-10 only.  On TOPS-20, you copied
files between the 10 and the 11 by running FE on the PDP-10 side, and PIP on
the PDP-11 side.

12-Apr-2004 16:54:14-PDT,2035;000000000000
Return-Path: <[email protected]>
Received: from brazilnut.cc.columbia.edu ([128.59.59.203]) by lingling.panda.com with TCP/SMTP; Mon, 12 Apr 2004 16:47:03 -0700 (PDT)
Received: from columbia.edu (pcp09163523pcs.verona01.nj.comcast.net [69.141.118.203])
       (user=rossman mech=PLAIN bits=0)
       by brazilnut.cc.columbia.edu (8.12.11/8.12.11) with ESMTP id i3CNl13M012576
       (version=TLSv1/SSLv3 cipher=DES-CBC3-SHA bits=168 verify=NOT)
       for <[email protected]>; Mon, 12 Apr 2004 19:47:01 -0400 (EDT)
Date: Mon, 12 Apr 2004 19:47:01 -0400
Subject: Re: RSX20F
Content-Type: text/plain; charset=US-ASCII; format=flowed
Mime-Version: 1.0 (Apple Message framework v553)
From: Ken Rossman <[email protected]>
To: Tops-20 Wizards <[email protected]>
Content-Transfer-Encoding: 7bit
In-Reply-To: <[email protected]>
Message-Id: <[email protected]>
X-Mailer: Apple Mail (2.553)
X-No-Spam-Score: Local
X-Scanned-By: MIMEDefang 2.40

On Monday, April 12, 2004, at 12:21 AM, Mark Crispin wrote:
> TKTN.TSK (not .EXE) was an RSX task that terminates tasks, reports
> errors,
> and requests reboots.

Ah, yes, thanks...  and (as Carl Baltrunas also already pointed out
earlier),
RSX tasks do not live in .EXE files, but in .TSK files...  I don't
think I
ever remembered this

> I don't remember KLXFER.  Maybe it was TOPS-10 only.  On TOPS-20, you
> copied
> files between the 10 and the 11 by running FE on the PDP-10 side, and
> PIP on
> the PDP-11 side.

Could well be KLXFER was TOPS-10 only, now that you mention it.  I
remember
doing some transfers to/from the Columbia FE's using FE and PIP (or at
least
I do remember the PIP part anyway, and FE sound familiar).

Oh, wait, I think KLXFER was not a manual task you ran, but an
automated one
that handled ALL normal communications tasks between the -11 and the
-10...
or something like that.  Weren't normal PDP-11 to PDP-10 transfers done
DMA?

KR

26-Apr-2004 18:23:00-PDT,6538;000000000000
Return-Path: <[email protected]>
Received: from mta9.srv.hcvlny.cv.net ([167.206.5.42]) by lingling.panda.com with TCP/SMTP; Mon, 26 Apr 2004 18:15:00 -0700 (PDT)
Received: from optonline.net (ool-182f33c4.dyn.optonline.net [24.47.51.196])
by mta9.srv.hcvlny.cv.net
(iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar  3 2004))
with ESMTP id <[email protected]>; Mon,
26 Apr 2004 21:14:54 -0400 (EDT)
Date: Mon, 26 Apr 2004 21:09:27 -0400
From: Thomas DeBellis <[email protected]>
Subject: Re: Multi-homed systems
To: Mark Crispin <[email protected]>
Cc: [email protected]
Message-id: <[email protected]>
MIME-version: 1.0
X-Mailer: Mozilla 4.5 [en]C-CCK-MCD BA45DSL  (WinNT; U)
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7BIT
X-Accept-Language: en
References: <[email protected]>

I've had some more time to think about this and I'm wondering if I
might have come up with an alternate, simpler approach.

At one time, Columbia's computer center had four (sigh) DECSYSTEM-20's
on a CI: CU20A, CU20B, CU20C and CU20D.  Very imaginative names, eh?
We always wanted something cool like SCORE or XX, but at least these
names weren't as awful as some other machines that we knew of.
Anyway, A, C and D were mainly for student class use, with some
limited faculty use and staff monitoring.  CU20B was the staff,
faculty and paying customer system.

As I recall, all of these machines eventually wound up with TCP/IP.
At least, when I looked at some of the transport code that I wrote for
Viking, I can see that I had put in hooks for TCP/IP.  I wouldn't have
bothered doing that if none of the student machines were ever going to
run TCP/IP.

I know that CU20B had an NI, otherwise we would never have had
Internet connectivity (via the computer science department).  However,
I don't seem to remember CU20A, CU20C or CU20D having NI's (did they,
Ken?  Frank?).  That would have cost too much.  However, I seem to
remember these machines still having IP connectivity via the CI.  I've
had a look at the version 7 monitor and it looks like CI IP *does*
exist--the module is IPCIDV.MAC.

That suggests a fairly straightforward approach.  Have two KLH-10
machines hosted by the same Unix box with two NIC's: one on the
internal (NAT'ed) LAN and one on the external public Internet LAN (or
WAN).  One KLH-10 would have its NI hosted by one NIC and so the other
would have its NI hosted by the other NIC.  The two machines would
then be connected via a new piece of KLH-10 hardware: a CI.

At least from its hardware interface, the CI seems to be a fairly
straightforward device.  It is completely point to point, so you pick
the machine that you want some data to go to and start the I/O.  There
are some other gotcha's, of course, but if my recollection is correct,
that is basically it.  For the purposes of this particular
configuration, the CI could probably be implemented entirely in shared
memory.

So I wonder if a CI implementation might not seem to be simpler than
the current NI KLH-10 implementation, which has to do a lot of things
to share the NIC with the host.  Perhaps it would be possible to just
take the KLH-10 NI module as a start and throw out a great deal of
stuff and then change the device interface to match that of the CI?
Maybe that might simpler than trying to implement an AN20.

Perhaps this approach might be easier than trying to configure and/or
modify KLH-10 to implement more than one NI.  It would also eliminate
the issues of modifying the monitor to support more than one NI.
Implementing a CI would mean that the monitor would potentially not
have to be modified at all, along with the related interface commands
in Galaxy, etc.

Of course, once the CI was up, then one would assume that CFS would
start working, also.  That would enable trivial file transfer between
the public and 'private' Tops-20 machines.  Just a simple PIP, er,
copy command.

I couldn't say anything about an HSC50, though.  I don't believe we
ever had any sort of source to the code running in one.  As a matter
of fact, I don't even remember what kind of processor was running in
there...  We may have had some sort of a preliminary interface
specification as part of our non-disclosure with 6.0, but either it
was vague or (more likely) I am vague about it.

Mark Crispin wrote:
>
> > From: William "Chops" Westfield <[email protected]>
> >
> > The stanford monitor code surely handles multiple MEIS (massbus ethernet)
> > interfaces.  There's nothing above the driver level (ie in IP or TCP) that
> > stops a 20 from working correctly with more than one network interface.
>
> I didn't mean to imply otherwise.  The limitation on the number of
> KLNI/NIA20s was a hardware limitation, not a software limitation.  As I
> recall, the one and only KLNI/NIA20 was on channel 5, displacing RH20 4 and
> 5; and the one and only CI20 was on channel 7, displacing RH20 6 and 7.
>
> KLH10 claims to support 7 RH20s if an NI is in use; evidentally TOPS-20 will
> grok this but no real KL would ever have such a configuration.
>
> I don't know how much work it would take to have more than one NI in
> KLH10 and TOPS-20.  There are probably places which assumes that the
> unit number is always zero, and those would have to be changed.
>
> > I think it will even happily route packets
>
> Yes, although I believe that there was a way to tell TOPS-20 not to route
> packets for third parties.
>
> TOPS-20 has a route table based upon the obsolete class-routing
> (A/B/C).  You can add other networks to the table to force a
> particular route (by the gateway contacted) but it still assumes
> class-routing.  For (single-homed systems this isn't a problem since
> you usually only (have one gateway, but for multi-homed systems this
> is an issue that has to be addressed.
>
> XKL addressed the problem in their monitor, and I have some
> (information courtesy of Ralph) on how to go about doing it.  But
> (once I realized that the problem didn't need to be solved in the
> (single-home case I lost interest.
>
> > Do the 20 emulators create a virtual NI interface, or do they have
> > (their own drivers for the PC hardware?
>
> KLH-10 has a virtual NIA20 for the KL version, and a virtual ACC LH-DH (ITS
> IMP interface) for the KS version.  There's no MEIS, AN20, or AN22 emulator.
> -------

3-May-2004 10:29:11-PDT,7008;000000000000
Return-Path: <[email protected]>
Received: from mta7.srv.hcvlny.cv.net ([167.206.5.74]) by lingling.panda.com with TCP/SMTP; Mon, 3 May 2004 10:19:41 -0700 (PDT)
Received: from optonline.net (ool-182f33c4.dyn.optonline.net [24.47.51.196])
by mta7.srv.hcvlny.cv.net
(iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar  3 2004))
with ESMTP id <[email protected]> for
[email protected]; Mon, 03 May 2004 13:20:04 -0400 (EDT)
Date: Mon, 03 May 2004 13:19:24 -0400
From: Thomas DeBellis <[email protected]>
Subject: Fun with the mail system AFTER feature
To: Tops-20 Wizards <[email protected]>
Message-id: <[email protected]>
MIME-version: 1.0
X-Mailer: Mozilla 4.5 [en]C-CCK-MCD BA45DSL  (WinNT; U)
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7BIT
X-Accept-Language: en
X-Priority: 5 (Lowest)

One of the things that I've been using the winning Tops-20 mail system
for is to remind myself to do things.  I've found that I need to get
nagged more often as the years advance (sigh).  So, I use the AFTER
parameter and then send the message to my Tops-20 mailbox, an ISP
mailbox and my cellphone (i.e., [email protected]).  It's helped me
to get my car inspected on time, renew the registration, etc.

However, I didn't see how to display the AFTER parameter nor how to
obviously erase it in MM.  I looked in the MM source and I couldn't
figure how to do it there, either.  In fact, it looked like these
functions weren't done.  So, I implemented them.  Here is an
abbreviated example:

      MM Send>>AFTER (DATE) 5-20-2004 10:00
      MM Send>>DISPLAY (MESSAGE FIELD) all

      From: Thomas DeBellis <Slogin@TOMMYT.#Internet>
      Subject: MM AFTER parameter usage example
      To: SLOGIN@TOMMYT.#Internet
      After: Thu, 20 May 2004 10:00:00 -0400 (EDT)

      Did we start winning, yet?
      -------
      MM Send>>ERASE (MESSAGE FIELD) AFTER
      MM Send>>DISPLAY (MESSAGE FIELD) AFTER
      MM Send>>AFTER (DATE) 5-20-2004 11:00
      MM Send>>DISPLAY (MESSAGE FIELD) HEADER

      From: Thomas DeBellis <Slogin@TOMMYT.#Internet>
      Subject: MM AFTER parameter usage example
      To: SLOGIN@TOMMYT.#Internet
      After: Thu, 20 May 2004 11:00:00 -0400 (EDT)

I wasn't sure whether I should have put the AFTER parameter in as a
keyword in the display and erase header commands or put it some place
else.  I don't remember AFTER being a keyword in RFC822.  So, it
technically isn't a header, is it?  It's something more like a local
option or a pseudo header.  That might mean that having it parsed and
displayed as a header is non-RFC822 compliant or appears so.
However, as it was easier to just hack it in there ...

Of course, I can well imagine students at Columbia and elsewhere then
using this to fill up PS:!  I can't remember if they after did or not
..  So, for real production, I guess you'd want to have a local
GETOK% request whose function denies a queued email if the user
already has too many.

One odd thing that I've noticed is that mail doesn't seemed to get
queued in all cases.  I haven't really verified this, but when I tried
sending mail to SYSTEM with the AFTER parameter set, it didn't seem to
work.  The mail was immediately delivered.  I'm not sure if this is a
feature or a mis-feature.  Perhaps it might be a nice to implement
queued SYSTEM mail as a complement to queued shutdowns (which I've
also hacked up a bit)?  You could set a shutdown to happen a few days
in the future and then send a queued system message about it sometime
before hand.

FILCOM:

File 1) MMS:[4,37]      created: 1203 03-May-104
File 2) MMB:[4,37]      created: 0342 01-Mar-102

1)1     ;[TOMMYT]STAR:<MM>MM.MAC.1170,  3-May-2004 11:25:14, Edit by SLOGIN
1)      ;[T14] Have MM display the quite useful AFTER parameter
1)              TITLE MM Mail Munger -- TOPS-20 mailsystem
****
2)1             TITLE MM Mail Munger -- TOPS-20 mailsystem
**************
1)1     VWHO==6                         ;Who last edited (0=MM developers)
1)                                      ;[T14] 6 is Tommy Timesharing
1)      VMAJ==7                         ;Major version (same as TOPS-20)
1)      VMIN==1                         ;Minor version
1)      VEDIT==^D1170                   ;Edit number, MM.EXE should be same
1)      ;  The original version of MM was written by Michael McMahon at SRI
****
2)1     VWHO==0                         ;Who last edited (0=MM developers)
2)      VMAJ==7                         ;Major version (same as TOPS-20)
2)      VMIN==1                         ;Minor version
2)      VEDIT==^D1169                   ;Edit number, MM.EXE should be same
2)      ;  The original version of MM was written by Michael McMahon at SRI
**************
1)14            CMD AFTER,.ERAFT        ;[T14] Need to be able to erase an after parameter
1)              CMD BCC,.ERSBC
****
2)14            CMD ALL,.ERSAL
2)              CMD BCC,.ERSBC
**************
1)14            CMD AFTER,.DSAFT        ;[T14] Display winning after parameter
1)              CMD ALL,.DSALL
****
2)14            CMD ALL,.DSALL
**************
1)135   .ERAFT: SETZM AFTDAT            ;[T14] No after date
1)              RET
1)      .ERSSB: SETZM SUBBUF
****
2)135   .ERSSB: SETZM SUBBUF
**************
1)135   .DSAFT: SKIPA AFTDAT            ;[T14] Is there an after date?
1)               RET                    ;[T14]  Well, THAT was easy ...
1)              CALLRET MOVAFT          ;[T14] Display after date
1)      .DSHDR: CALL DISHDR
****
2)135   .DSHDR: CALL DISHDR
**************
1)135           CALL MOVAFT             ;[T14] Display after date
1)              CALLRET MOVUS1
****
2)135           CALLRET MOVUS1
**************
1)138   ;[T14] Display deliver AFTER date, mostly hacked out of display reply date
1)      MOVAFT: SKIPG AFTDAT            ;[T14] Has an AFTER date?
1)               RET                    ;[T14]  No, how did we wind up here ??
1)              MOVEI B,[ASCIZ/
1)      After: /]                       ;[T14] Present the pseudo header
1)              CALL MOVSB2
1)              SETZ A,
1)              MOVE B,MOVDSP           ;Get instruction
1)              CAMN B,[IDPB A,O]       ;Output to string?
1)               MOVE A,O               ;Yes, get current BP
1)              CAMN B,[PBOUT%]         ;Output to TTY?
1)               MOVX A,.PRIOU          ;Yes, select terminal output
1)              MOVE B,AFTDAT           ;[T14] Load the after date
1)              MOVX C,OT%DAY!OT%SPA!OT%TMZ!OT%SCL!OT%822 ; RFC 822 standard date/time
1)              ODTIM%
1)              CAIE A,.PRIOU           ;Unless going to current output
1)               MOVE O,A               ;Set byte pointer to value from ODTIM%
1)              RET
1)139   ;;;Get some more text
****
2)138   ;;;Get some more text
**************

3-May-2004 12:07:51-PDT,1120;000000000000
Return-Path: <[email protected]>
Received: from Ikkoku-Kan.Panda.COM (panda.com [206.124.149.114]) by lingling.panda.com with TCP/SMTP; Mon, 3 May 2004 11:58:29 -0700 (PDT)
Received: from Ikkoku-Kan.Panda.COM (Ikkoku-Kan.Panda.COM [192.107.14.50]) by Ikkoku-Kan.Panda.COM id LAA03640; Mon, 3 May 2004 11:58:26 -0700 (PDT)
Date: Mon, 3 May 2004 11:17:41 -0700 (PDT)
From: Mark Crispin <[email protected]>
Sender: Mark Crispin <[email protected]>
Subject: re: Fun with the mail system AFTER feature
To: Thomas DeBellis <[email protected]>
cc: Tops-20 Wizards <[email protected]>
In-Reply-To: <[email protected]>
Message-ID: <[email protected]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII

You're right; SYSTEM mail is not queued, and even if it is it won't get
delivered by mmailr.  It's a bug in mmailbox that SYSTEM mail is accepted
(that RETSKP should be a RET, and while you're at it delete the reference to
[email protected]).

There's no AFTER: parameter in RFC 2822; it's strictly a mail transport issue.

4-May-2004 06:58:46-PDT,2214;000000000000
Return-Path: <[email protected]>
Received: from mta9.srv.hcvlny.cv.net ([167.206.5.42]) by lingling.panda.com with TCP/SMTP; Tue, 4 May 2004 06:48:47 -0700 (PDT)
Received: from optonline.net (ool-182f33c4.dyn.optonline.net [24.47.51.196])
by mta9.srv.hcvlny.cv.net
(iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar  3 2004))
with ESMTP id <[email protected]> for
[email protected]; Tue, 04 May 2004 09:48:38 -0400 (EDT)
Date: Tue, 04 May 2004 09:48:44 -0400
From: Thomas DeBellis <[email protected]>
Subject: SOML, SAML and friends
To: Tops-20 Wizards <[email protected]>
Message-id: <[email protected]>
MIME-version: 1.0
X-Mailer: Mozilla 4.5 [en]C-CCK-MCD BA45DSL  (WinNT; U)
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7BIT
X-Accept-Language: en

I recently got asked what the delivery options meant in MM, to which I
gave my standard, remarkably helpful reply: "Go away.  Read the
documentation."  About five minutes later: "I can't find anything.
Waaa!  What do SOML and SAML mean?"  As I couldn't remember (or didn't
ever know) what they meant, I went and tried to find out.

I had a very quick peek at the MM.HLP and MM.DOC files, but didn't
find anything obvious.  The MM built-in help doesn't seem to explain
them, either.  So, I went and had a look at the source code in MM.MAC
and MMAILR.MAC.  I'm not sure that I fully understood the processing
of D%SOML, but here is what I wrote to stick into MMHELP.MAC at
HDELI:.  Did I get this right?

-------

The DELIVERY-OPTIONS command takes one argument, a delivery option name.
This decides whether to mail the message and/or send it to the recipient's
terminal.  These options are:

       MAIL    -- Mail the message to the recipient's mailbox
       SAML    -- Send the message to the recipient's terminal *AND*
                  Mail the message to the recipient's mailbox
       SEND    -- Send the message to the recipient's terminal
       SOML    -- Send the message to the recipient's terminal.
                  If this fails, then mail the message to the
                  recipient's mailbox.
-------
4-May-2004 07:31:19-PDT,2774;000000000000
Return-Path: <[email protected]>
Received: from durian.cc.columbia.edu ([128.59.59.93]) by lingling.panda.com with TCP/SMTP; Tue, 4 May 2004 07:23:33 -0700 (PDT)
Received: from durian.cc.columbia.edu (localhost [127.0.0.1])
       by durian.cc.columbia.edu (8.12.11/8.12.10) with ESMTP id i44ENWTr017756
       for <[email protected]>; Tue, 4 May 2004 10:23:32 -0400 (EDT)
Received: (from www@localhost)
       by durian.cc.columbia.edu (8.12.11/8.12.3/Submit) id i44ENT6F017755
       for [email protected]; Tue, 4 May 2004 10:23:29 -0400 (EDT)
Received: from 198.4.159.5 ( [198.4.159.5])
       as user [email protected] by cubmail.cc.columbia.edu with HTTP;
       Tue,  4 May 2004 10:23:29 -0400
Message-ID: <[email protected]>
Date: Tue,  4 May 2004 10:23:29 -0400
From: [email protected]
To: Tops-20 Wizards <[email protected]>
Subject: Re: SOML, SAML and friends
References: <[email protected]>
In-Reply-To: <[email protected]>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
User-Agent: Internet Messaging Program (IMP) 3.1
X-Originating-IP: 198.4.159.5

Quoting Thomas DeBellis <[email protected]>:
> I recently got asked what the delivery options meant in MM...
> ...The MM built-in help doesn't seem to explain them, either.
> So, I went and had a look at the source code in MM.MAC and
> MMAILR.MAC.  I'm not sure that I fully understood the
> processing of D%SOML, but here is what I wrote to stick
> into MMHELP.MAC at .HDELI:.
>
> Did I get this right?
>
> -------
>
> The DELIVERY-OPTIONS command takes one argument, a delivery
> option name.
> This decides whether to mail the message and/or send it to the
> recipient's
> terminal.  These options are:
>
>         MAIL    -- Mail the message to the recipient's mailbox
>         SAML    -- Send the message to the recipient's terminal
> *AND*
>                    Mail the message to the recipient's mailbox
>         SEND    -- Send the message to the recipient's terminal
>         SOML    -- Send the message to the recipient's terminal.
>                    If this fails, then mail the message to the
>                    recipient's mailbox.


Yes, Tom, that's correct.  I remember messing with this stuff a
bit myself while at CU (a long, long time ago, in a land far,
far away...)

SEND, SAML, and SOML never really had the same gratifying results
that the (separately written) SEND command(s) did, since the SMTP
SEND, SAML, and SOML all used the mail queueing system to deliver
even the "live" terminal messages, and thus, were susceptible to
the usual mail queueing delays that are common to that system.

KR
4-May-2004 09:37:37-PDT,3667;000000000000
Return-Path: <[email protected]>
Received: from rwcrmhc13.comcast.net ([204.127.198.39]) by lingling.panda.com with TCP/SMTP; Tue, 4 May 2004 09:29:47 -0700 (PDT)
Received: from h525405f6161e.ne.client2.attbi.com ([66.30.204.193])
         by comcast.net (rwcrmhc13) with ESMTP
         id <200405041629460150091mlne>; Tue, 4 May 2004 16:29:46 +0000
Received: (from phil@localhost)
       by ultimate.com (8.12.10/8.12.10) id i44GTjxX019337;
       Tue, 4 May 2004 12:29:45 -0400 (EDT)
Date: Tue, 4 May 2004 12:29:45 -0400 (EDT)
From: Phil Budne <[email protected]>
Message-Id: <[email protected]>
To: [email protected], [email protected]
Subject: Re: SOML, SAML and friends

Ken Rossman write:
> SEND, SAML, and SOML never really had the same gratifying results
> that the (separately written) SEND command(s) did, since the SMTP
> SEND, SAML, and SOML all used the mail queueing system to deliver
> even the "live" terminal messages, and thus, were susceptible to
> the usual mail queueing delays that are common to that system.

I seem to recall one SEND command that worked by making a direct SMTP
connection to the destination machine (in a world before DNS and MX
records), eliminating one MTA/queue transit.

It's always bugged me that SEND/SAML/SOML got such short shrift, and
people always tried to invent new SEND protocols, which never took off
(at BU the "rsend" program ended up being the one used most, at least
for a while).

There was a SEND patch for sendmail c.1986 (see below), but I wonder
if it had been part of sendmail from the start if would have been more
popular (of course we all would have turned it off when spamming
started!)?

I regard this as one more thing the Berkeley folks got wrong (along
with "q" not quitting the FTP client, and not being able to "bind" a
socket to listen for connections only from a particular source
address/port, which makes it easier (possible) to implement FTP
without resorting to the "PORT" command.

Ironicly, I'm now a BSDite (or perhaps it's the logical extension of
my stubborn connection with old, but superior software)!

   Subject: SMTP SEND command for Sendmail
   Newsgroups: mod.sources
   Approved: [email protected]

   Mod.sources:  Volume 5, Issue 13
   Submitted by: Greg Satz <talcott!mojave.stanford.edu:satz>


   Since I saw a request for this on Unix-Wizards and someone asked me for
   it, I thought I would send it here for others who may be interested.

   The following shell archive contains context diffs that support the
   SMTP send command.  These diffs were extracted from the 4.3beta
   sendmail and extraneous patches removed, so don't believe the line
   numbers at all.

   The only change to the configuration files is in localm.m4 where a TTY
   mailer needs to be defined. I included an example as localm.m4.

   Also included is the program we use to send messages, to.  It is a
   simple program that was originally written by Stuart Cracraft.  I
   hacked it up to use Sendmail/SMTP.  It isn't much but it will deliver
   tty messages.

   This code has been in use here at Stanford for over a year.  It is
   known to work with the TOPS-20 implementation for sending and receiving
   messages.

   If anyone makes any changes to these things, I would appreciate it if
   you could send them back to me.  I have always wanted to add a reply
   command and "what are the last N messages" command, but have never
   found the time.  Manual pages are needed too.

   Enjoy!

   Greg Satz       [email protected]
                   Shasta!satz
4-May-2004 10:55:59-PDT,1531;000000000000
Return-Path: <[email protected]>
Received: from thrintun.hactrn.net ([66.92.66.67]) by lingling.panda.com with TCP/SMTP; Tue, 4 May 2004 10:47:59 -0700 (PDT)
Received: from thrintun.hactrn.net (localhost [IPv6:::1])
       by thrintun.hactrn.net (Postfix) with ESMTP id 9028842B2
       for <[email protected]>; Tue,  4 May 2004 13:47:58 -0400 (EDT)
Date: Tue, 04 May 2004 13:47:58 -0400
From: Rob Austein <[email protected]>
To: [email protected]
Subject: Re: SOML, SAML and friends
In-Reply-To: <[email protected]>
References: <[email protected]>
User-Agent: Wanderlust/2.10.1 (Watching The Wheels) Emacs/21.3 Mule/5.0 (SAKAKI)
MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen")
Content-Type: text/plain; charset=US-ASCII
Message-Id: <[email protected]>

SEND, SAML, and SOML were right out of the SMTP spec, but were were
eventually deprecated by the Host Requirements RFCs.  I fought that,
but lost the argument, because (a) by that point, sendmail had already
taken over the email world, so almost nobody remembered those
operations anymore, and (b) I was not able to refute the assertion
that, in a world with multiple layers of MX relays, UUCP mail
gateways, and so forth, and one in which host admins were starting to
turn off FINGER (which one could construe as an early "presence"
protocol) due to security concerns, the SEND/SAML/SOML operations were
somewhat out of step with what naive users expected.  Sigh.
6-May-2004 00:55:18-PDT,1244;000000000000
Mail-From: MRC created at  6-May-2004 00:47:57
Date: Thu, 6 May 2004 00:47:57 -0700 (PDT)
From: Mark Crispin <[email protected]>
Subject: lights and switches
To: [email protected]
Pithy-Thought: TOPS-20 was a great improvement over its successors
Message-ID: <[email protected]>

I am implementing lights and switches on Lingling.  Actually, I have already
implemented switches, and lights are coming.

klh10 has always supported KLDCP switches, but that value isn't accessible
unless you are in KLDCP secondary protocol.  I've extended the host device
(which does microcode idle) so DATAI 700,<adr> returns the switches, and now
once again the SWTCH% JSYS works.  [To answer the question of why I don't use
DATAI APR, which is the traditional RSW machine instruction -- the KL10 uses
that instruction for something else.]

DATAO 700,<adr> will be the lights instruction.  Although DATAO PI, is not
used on the KL, it is used on XKL processors for other purposes.

Currently, I have the lights and the switches be separate registers, as they
were on the PDP-6, KA10, and KI10.  I wonder if they should be the same
register, so that outputting the lights also sets the switches?
-------
6-May-2004 18:09:18-PDT,1193;000000000000
Mail-From: MRC created at  6-May-2004 18:01:58
Date: Thu, 6 May 2004 18:01:58 -0700 (PDT)
From: Mark Crispin <[email protected]>
Subject: bug in PA1050 handling of LIGHTS and SWITCH UUOs
To: [email protected]
Pithy-Thought: TOPS-20 was a great improvement over its successors
Message-ID: <[email protected]>

As distributed, the LIGHTS and SWITCH UUOs don't work on TOPS-20
even if the underlying LITES and SWTCH jsi are working and do
something useful.

The support code for LIGHTS in PAT.MAC was never updated for the
Tenex to TOPS-20 transition.  In Tenex, the LITES JSYS itraps if
not WOPR/MAINT; on TOPS-20 it returns +1 if not WOPR/MAINT and +2
on success.

Fix: In PAT.MAC at LIGHTS+4, insert "ERJMP .+1" between the LITES
and the JRST MRETN.  A JFCL is OK here too.

The support code for SWITCH in PAT.MAC was updated for the Tenex
to TOPS-20 transition; in Tenex, SWTCH is unprivileged; in
TOPS-20, it returns +1 if not WOPR/MAINT and +2 on success.
Thus, there is a JFCL after the SWTCH call.  However, it never
returned its argument to the caller.

Fix: In PAT.MAC at SWITCH+2, change JRST MRETN to JRST STOTAC.
-------
6-May-2004 18:26:04-PDT,540;000000000000
Mail-From: MRC created at  6-May-2004 18:19:35
Date: Thu, 6 May 2004 18:19:35 -0700 (PDT)
From: Mark Crispin <[email protected]>
Subject: more on SWITCH UUO in PA1050
To: [email protected]
Pithy-Thought: TOPS-20 was a great improvement over its successors
Message-ID: <[email protected]>

Actually, the JFCL at SWITCH+1 should be changed to be ERJMP RETZER, since
otherwise the JSYS error code would be returned as the "switches" value to
an unprivileged caller that does a SWITCH UUO.
-------
7-May-2004 10:12:28-PDT,4468;000000000000
Return-Path: <[email protected]>
Received: from mta2.srv.hcvlny.cv.net ([167.206.5.68]) by lingling.panda.com with TCP/SMTP; Fri, 7 May 2004 10:05:01 -0700 (PDT)
Received: from optonline.net (mstr3.srv.hcvlny.cv.net [167.206.5.14])
by mta2.srv.hcvlny.cv.net
(iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar  3 2004))
with ESMTP id <[email protected]>; Fri,
07 May 2004 13:04:18 -0400 (EDT)
Received: from [167.206.5.76] (Forwarded-For: [24.47.51.196])
by mstr3.srv.hcvlny.cv.net (mshttpd); Fri, 07 May 2004 13:02:58 -0400
Date: Fri, 07 May 2004 13:02:58 -0400
From: [email protected]
Subject: Re: lights and switches
To: Mark Crispin <[email protected]>
Cc: [email protected]
Message-id: <[email protected]>
MIME-version: 1.0
X-Mailer: iPlanet Messenger Express 5.2 HotFix 1.25 (built Mar  3 2004)
Content-type: text/plain; charset=us-ascii
Content-language: en
Content-transfer-encoding: 7BIT
Content-disposition: inline
X-Accept-Language: en
Priority: normal

> Currently, I have the lights and the switches be separate registers,
> as they were on the PDP-6, KA10, and KI10.  I wonder if they should
> be the same register, so that outputting the lights also sets the
> switches?
-------

MRC,

I'm not sure if I've understood everything, but this message jogged a
VERY OLD memory of one of the very few times that I ever used the
KI-10 console (in Marlboro).  Most of my (limited) console experience
involved poking around on KA-10's, but I did get to play with the
PDP-6 on the ninth floor, once.  My recollection is that it is true
that--on the PDP-6 and the KA-10--there is nothing that any program
can do to set the console switches.  They are mechanical, so you can
only set the lights.

However, I don't remember this also being the case on the winning
KI-10 console.  There, the switches are push buttons which toggled
flip flops.  You would push a button and the light underneath the
button would come on (or go off).  At any rate, a user I/O program
could also set these flip flops, if the appropriate switch was set (MI
program disable).  The output device that you used was PTR, the paper
tape READER.  The assignments are as follows:

 DATAI APR, - Data In,  Console - Read Switches
 DATAO APR, - Data Out, Console - Blink Console Memory Lights
 DATAO PTR, - Operating Data Out, Console - Diddle switches

These interfaces are described in the 1973 third addition of the
orange assembly language handbook in section 2-80 (bottom of page 102,
top of page 103) and in the Febuary 1978, 1st addition of the Hardware
Reference Manual (Volume I, Central Processing Unit) at the bottom of
page 5-3.

I have the second and third additions the orange assemble language
handbooks and two later versions of SYSREF, describing KL extended
mode programming.  The 1st addition of SYSREF has the famous Spic and
Span cleaning instructions guide at the beginning of Appendix F.  It
also has an unfortunately black and white picture of the beautiful
KI-10 console.

With this as background, I don't feel that outputting the lights
should directly change the switch register.  That would mean that any
time you had to put something in the lights, you would clobber
information that might be used by a program.

At WPI, for example, we used the console switches and lights for
different things.  Each student operator was assigned a switch or bit
in the switch register.  When you came in on your shift, you would
walk over and flick your console switch on.  This might have made
billing easier (I can't remember now), but it did enable this
following really fun output (assign three switches were set):

     .R OPRS

     FOO, BAR and BAZ are operators

     .

This would tell you who was around at WACCC (Worcester Area College
Computation Center) that you could nag, plead with or grovel to.
However, I think that the lights were used by a seperate program (or
was it the monitor?) to indicate some other sort of system status.  I
can't remember what that was.

I often wished for the same kind of easy functionality on the KL-10.
So, I think that you should keep these in seperate registers.  As long
as you are implementing lights and switches, it might make more sense
to follow the KI-10 model.

Anyway, perhaps this might be of some use or fun.  Or not...

                  --T


7-May-2004 11:44:18-PDT,1135;000000000000
Mail-From: MRC created at  7-May-2004 11:37:10
Date: Fri, 7 May 2004 11:37:10 -0700 (PDT)
From: Mark Crispin <[email protected]>
Subject: Re: lights and switches
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]>

DATAO PTR, on the KI didn't set the console switches; it set the console
address (bits 14-35) and address condition (bits 0-6) switches.  I believe
that bits 7-13 of the value passed to DATAO PTR, were just tossed.

I'm pretty sure that DATAO PTR, did nothing on the KA, but the processor
reference manual isn't clear on that point; it implies that it may affect
the more limited address break on the KA but I doubt that was the case.

Unfortunately, the reference to Spic and Span got changed to "an ordinary
cleaner" in later versions of Appendix F.  However, the rest of that
paragraph is still there.

The KI could also return the status of 6 sense switches in bits 12-17 from
CONI APR,

-- Mark --
-------
7-May-2004 11:53:10-PDT,3536;000000000000
Return-Path: <[email protected]>
Received: from service0.etnus.com (tmpsys.etnus.com [68.162.234.181]) by lingling.panda.com with TCP/SMTP; Fri, 7 May 2004 11:45:29 -0700 (PDT)
Received: from RCN.Com (ralfie.etnus.com [192.168.68.75])
       by service0.etnus.com (Postfix) with ESMTP
       id B357EFC05F; Fri,  7 May 2004 14:45:23 -0400 (EDT)
Sender: [email protected]
Message-ID: <[email protected]>
Date: Fri, 07 May 2004 14:45:26 -0400
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: lights and switches
References: <[email protected]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Mark Crispin wrote:
>
> [email protected] wrote:
> >
> > Currently, I have the lights and the switches be separate registers,
> > as they were on the PDP-6, KA10, and KI10.  I wonder if they should
> > be the same register, so that outputting the lights also sets the
> > switches?

Since that's not how the hardware worked, it wouldn't constitute a
faithful model.


> However, I don't remember this also being the case on the winning
> KI-10 console.  There, the switches are push buttons which toggled
> flip flops.  You would push a button and the light underneath the
> button would come on (or go off).  At any rate, a user I/O program
> could also set these flip flops, ...

On the KI, LIGHTS is documented to affect the 36 memory indicators, not
the illumination for the data switches.


>... if the appropriate switch was set (MI
> program disable).  ...

The sense is that when the MI PROG DIS switch is on, it *disables* the
LIGHTS UUO, so the console operator is not harassed by user programs.

The intent was that on the KA, SHIFT CNTR MAINT, FM ENB, REPT BYT and
MI PROG DIS all had their upper halves depressed.  The rationale is
obvious for FM ENB and plausible for MI PROG DIS; I haven't thought
about the benefits for SHIFT CNTR MAINT and REPT BYT.  Whether there
was an attempt at similar consistency for the analogous switches on
the left end of the upper KI panel, I don't know.


>...  The output device that you used was PTR, the paper
> tape READER.  The assignments are as follows:
..
>   DATAO APR, - Data Out, Console - Blink Console Memory Lights

On the KA, that sets the relocation and protection registers;
on the KI, that sets the address break.


>   DATAO PTR, - Operating Data Out, Console - Diddle switches

Fascinating.


> These interfaces are described in the 1973 third addition of the
> orange assembly language handbook in section 2-80 (bottom of page 102,
> top of page 103) and in the Febuary 1978, 1st addition of the Hardware
> Reference Manual (Volume I, Central Processing Unit) at the bottom of
> page 5-3.
>
> I have the second and third additions the orange assemble language
> handbooks and two later versions of SYSREF, describing KL extended
> mode programming.  The 1st addition of SYSREF has the famous Spic and
> Span cleaning instructions guide at the beginning of Appendix F.  It
> also has an unfortunately black and white picture of the beautiful
> KI-10 console.

DECsystem-10/DECSYSTEM-20 Processor Reference Manual AA-H391A-TK,
AA-H391A-T1 (Jun-82) is online at:

       http://pdp10.nocrew.org/docs/ad-h391a-t1.pdf
                               /AHM
--
Alan Howard Martin                      [email protected]
7-May-2004 12:35:46-PDT,1320;000000000000
Return-Path: <[email protected]>
Received: from service0.etnus.com (tmpsys.etnus.com [68.162.234.181]) by lingling.panda.com with TCP/SMTP; Fri, 7 May 2004 12:28:01 -0700 (PDT)
Received: from RCN.Com (ralfie.etnus.com [192.168.68.75])
       by service0.etnus.com (Postfix) with ESMTP
       id 5087BFC058; Fri,  7 May 2004 15:27:59 -0400 (EDT)
Sender: [email protected]
Message-ID: <[email protected]>
Date: Fri, 07 May 2004 15:27:56 -0400
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: lights and switches
References: <[email protected]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Mark Crispin wrote:
>
> DATAO PTR, on the KI didn't set the console switches; it set the console
> address (bits 14-35) and address condition (bits 0-6) switches.  ...

(I agree DATAO PTR set the address break; my misteak paging back and
forth in the manual this afternoon).


>...  I believe
> that bits 7-13 of the value passed to DATAO PTR, were just tossed.

No documented use for them in at least one illustration.
                               /AHM
--
Alan Howard Martin                      [email protected]
7-May-2004 12:59:59-PDT,1804;000000000000
Return-Path: <[email protected]>
Received: from Ikkoku-Kan.Panda.COM (panda.com [206.124.149.114]) by lingling.panda.com with TCP/SMTP; Fri, 7 May 2004 12:52:54 -0700 (PDT)
Received: from Ikkoku-Kan.Panda.COM (Ikkoku-Kan.Panda.COM [192.107.14.50]) by Ikkoku-Kan.Panda.COM id MAA08981; Fri, 7 May 2004 12:52:47 -0700 (PDT)
Date: Fri, 7 May 2004 12:48:16 -0700 (PDT)
From: Mark Crispin <[email protected]>
Sender: Mark Crispin <[email protected]>
Subject: Re: lights and switches
To: "Alan H. Martin" <[email protected]>
cc: [email protected]
In-Reply-To: <[email protected]>
Message-ID: <[email protected]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII

On Fri, 07 May 2004 14:45:26 -0400, Alan H. Martin wrote:
> > > Currently, I have the lights and the switches be separate registers,
> > > as they were on the PDP-6, KA10, and KI10.  I wonder if they should
> > > be the same register, so that outputting the lights also sets the
> > > switches?
> Since that's not how the hardware worked, it wouldn't constitute a
> faithful model.

There is no such thing as "how the hardware worked" for lights and switches on
the KL.  So that argument is fallacious.

However, I think that Tom's arguments are compelling and I will keep them
separate.

> >   DATAO APR, - Data Out, Console - Blink Console Memory Lights
> On the KA, that sets the relocation and protection registers;
> on the KI, that sets the address break.

The correct KA/KI instruction was DATAO PI,

That instruction is unused on the KL.  The KS technically did not have a
DATAO, but that particular bit pattern is also unused on the KS.  The XKL
doesn't have DATAO either, and uses that bit pattern for something else.

7-May-2004 13:49:10-PDT,1829;000000000000
Return-Path: <[email protected]>
Received: from service0.etnus.com (tmpsys.etnus.com [68.162.234.181]) by lingling.panda.com with TCP/SMTP; Fri, 7 May 2004 13:41:21 -0700 (PDT)
Received: from RCN.Com (ralfie.etnus.com [192.168.68.75])
       by service0.etnus.com (Postfix) with ESMTP
       id 578F6FC002; Fri,  7 May 2004 16:41:20 -0400 (EDT)
Sender: [email protected]
Message-ID: <[email protected]>
Date: Fri, 07 May 2004 16:41:16 -0400
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: lights and switches
References: <[email protected]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Mark Crispin wrote:
>
> On Fri, 07 May 2004 14:45:26 -0400, Alan H. Martin wrote:
> > > > Currently, I have the lights and the switches be separate registers,
> > > > as they were on the PDP-6, KA10, and KI10.  I wonder if they should
> > > > be the same register, so that outputting the lights also sets the
> > > > switches?
> > Since that's not how the hardware worked, it wouldn't constitute a
> > faithful model.
>
> There is no such thing as "how the hardware worked" for lights and switches on
> the KL.  So that argument is fallacious.

Fine, FShardware$architecture$$

(Note rationales of ``no *exact* prior art'' are the first step down the
slippery slope of incompatibility between members of a product line).


BTW, where was there a switches'n'lights game that had one bit shifting
back and forth like a Cylon's eyeball, with the player trapping the bit
by using the switches to set bounds?
                               /AHM
--
Alan Howard Martin                      [email protected]
7-May-2004 16:21:49-PDT,5817;000000000000
Return-Path: <[email protected]>
Received: from mta5.srv.hcvlny.cv.net ([167.206.5.78]) by lingling.panda.com with TCP/SMTP; Fri, 7 May 2004 16:14:40 -0700 (PDT)
Received: from optonline.net (mstr3.srv.hcvlny.cv.net [167.206.5.14])
by mta5.srv.hcvlny.cv.net
(iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar  3 2004))
with ESMTP id <[email protected]> for
[email protected]; Fri, 07 May 2004 19:14:31 -0400 (EDT)
Received: from [167.206.5.79] (Forwarded-For: [24.47.51.196])
by mstr3.srv.hcvlny.cv.net (mshttpd); Fri, 07 May 2004 19:13:07 -0400
Date: Fri, 07 May 2004 19:13:07 -0400
From: [email protected]
Subject: Re: lights and switches
To: "Alan H. Martin" <[email protected]>
Cc: [email protected]
Message-id: <[email protected]>
MIME-version: 1.0
X-Mailer: iPlanet Messenger Express 5.2 HotFix 1.25 (built Mar  3 2004)
Content-type: text/plain; charset=us-ascii
Content-language: en
Content-transfer-encoding: 7BIT
Content-disposition: inline
X-Accept-Language: en
Priority: normal

> > > > Currently, I have the lights and the switches be separate
> > > > registers as they were on the PDP-6, KA10, and KI10.  I wonder
> > > > if they should be the same register, so that outputting the
> > > > lights also sets the switches?

> > > Since that's not how the hardware worked, it wouldn't constitute
> > > a faithful model.

> > There is no such thing as "how the hardware worked" for lights and
> > switches on the KL.  So that argument is fallacious.

> (Note rationales of ``no *exact* prior art'' are the first step down
> the slippery slope of incompatibility between members of a product
> line).

At the risk of sounding presidential, it seems to me that it would
depend on what the meaning of 'slippery' is.  I think it is probably
safe to say that, for the PDP-6, KA-10 and KI-10 instantiations of the
PDP-10 architecture, it was unusual for the instruction set to change.
MIT and BBN may have had a few special instructions, but I don't
remember hearing about much else.  At least from the user programming
perspective, I can't recall any KA-10 being different from any other.

However, I do remember things being quite different with the KL-10.
There, you loaded microcode which implemented an instantiation of the
instruction set.  All instantiations were clearly not equal.  Every
once in a LONG while at Columbia, we would get the opportunity to beta
test new versions of the microcode.  That kind of stuff made us
extremely nervous, so we usually declined the offer, except during the
summer when we had an entire machine that we could take out of service
(CU20C).

Various flavors of string instructions, floating point and other
randomness would come in and out of the KL ISA.  In fact, if I'm
remembering clearly, I believe that the model B KL-10 hardware would
support extended addressing, but you could only have it in the ISA if
you ran a particular version microcode.  The microcode had to
implement some additional bits someplace and something else.  I think
that if you had the EA microcode, some instructions were not
available.

The fact that the instruction set could easily change was repeatedly
and repeatedly touted as an advantage to us by our smiling Digital
representatives.  In fact, I seem to recall somebody telling me that
it was theoretically possible that we could implement our own
microcode to turn one of our KL's into VAX!  It didn't seem like a
good idea, so ...  We never bothered exploring the more winning
proposition of turning a VAX into a PDP-10.

So, clearly each instantiation of the PDP-10 ISA was not 100%
compatible with the other.  There were KI-10 programs that would not
run on a KA or a PDP-6, etc., etc.  This was the reason for subtle
routins that tried to determine what machines they were running on to
either exploit instructions or to not execute contextually bogus code.
Later, I think that you could get the microcode version with a special
instruction.

It might make sense at some point to have KLH-10 report out a
different microcode version.  Then new programs could use that to
decide which (esoteric) features to use.  Or Not...  From that
perspective, I don't think that MRC is sliding anywhere.  If he
defines an additional device or register, so what?  It's been
happening since the 1970's.  If the hardware definition doesn't
conflict with an existing device, so what?  If it doesn't conflict
with existing usage of a device, so what?  I can't see how changing
KLH-10 to implement new registers is different from changing microcode
versions on the KL-10, other than the underlying micro-engine is far
faster and far more capable.

I can see that I misread DATAO PTR, Opps.  That's what I get for
spending more time chuckling over the 'how to wash your computer'
directions then carefully looking at the instruction definitions...
However, when I remember looking the KI-10 console, I remember
thinking that it was (would be) very cool to have the inverse of an
RSW.  It seemed that it would be winning to have a program be able to
have a read and write the switch register.

The lights were, programmatically, write only.  I don't think that you
could read back what you wrote in there.  The switch register was read
only, you couldn't write back what you read in there.  I think that it
should be read/write.  For the times that you want it to be read only,
I guess you'd want a 'SW program disable' switch that could only be
modified by the ISA.

PS: We never washed, cleaned or did anything else to our hardware.  In
   fact, any time building services came in with a dust mop, we
   usually had head crashes soon afterwards.  :-(


17-May-2004 08:54:20-PDT,673;000000000000
Mail-From: MRC created at 17-May-2004 08:46:51
Date: Mon, 17 May 2004 08:46:51 -0700 (PDT)
From: Mark Crispin <[email protected]>
Subject: 21 years ago today...
To: [email protected]
Pithy-Thought: TOPS-20 was a great improvement over its successors
Message-ID: <[email protected]>

21 years ago today, at 2PM Eastern Time, Ken Olsen and Bill Johnson canceled
Project Jupiter, and set in motion the set of circumstances that ultimately
led to the demise of Digital Equipment Corporation.

It's been a long hard road since then.  DEC (and its successor Digital) are
now no more than a memory.  But we're still around.
-------
17-May-2004 10:35:56-PDT,1657;000000000000
Return-Path: <[email protected]>
Received: from rwcrmhc11.comcast.net ([204.127.198.35]) by lingling.panda.com with TCP/SMTP; Mon, 17 May 2004 10:28:09 -0700 (PDT)
Received: from [10.0.1.2] (h000393e155ff.ne.client2.attbi.com[24.63.6.9])
         by comcast.net (rwcrmhc11) with ESMTP
         id <20040517172808013000hc79e>
         (Authid: pwex);
         Mon, 17 May 2004 17:28:09 +0000
Mime-Version: 1.0
X-Sender:  (Unverified)
Message-Id: <p06020400bccea618b3d0@[10.0.1.2]>
In-Reply-To: <[email protected]>
References: <[email protected]>
Date: Mon, 17 May 2004 13:28:06 -0400
To: Mark Crispin <[email protected]>, [email protected]
From: Paul Wexelblat <[email protected]>
Subject: Just Suppose... RE: 21 years ago...
Content-Type: text/plain; charset="us-ascii" ; format="flowed"

Suppose they had not cancelled Jupiter, where do you think DEC,
Mainframes, us, and computers would have been today???

Blue sky time...


At 8:46 AM -0700 5/17/04, Mark Crispin wrote:
>21 years ago today, at 2PM Eastern Time, Ken Olsen and Bill Johnson canceled
>Project Jupiter, and set in motion the set of circumstances that ultimately
>led to the demise of Digital Equipment Corporation.
>
>It's been a long hard road since then.  DEC (and its successor Digital) are
>now no more than a memory.  But we're still around.
>-------
>
>
>  E3-I: This message has been scanned for viruses and dangerous
>content by UML's antivirus scanning services.


--
P.M. Wexelblat PhD
Dept. of Computer Science
University of Massachusetts Lowell
One University Ave
Lowell, MA 01854
17-May-2004 11:44:47-PDT,2698;000000000000
Return-Path: <[email protected]>
Received: from sesame.cc.columbia.edu ([128.59.59.56]) by lingling.panda.com with TCP/SMTP; Mon, 17 May 2004 11:37:35 -0700 (PDT)
Received: from sesame.cc.columbia.edu (localhost [127.0.0.1])
       by sesame.cc.columbia.edu (8.12.11/8.12.10) with ESMTP id i4HIbRJu001849;
       Mon, 17 May 2004 14:37:27 -0400 (EDT)
Received: (from fdc@localhost)
       by sesame.cc.columbia.edu (8.12.11/8.12.8/Submit) id i4HIbRtV001848;
       Mon, 17 May 2004 14:37:27 -0400 (EDT)
Date: Mon, 17 May 2004 14:37:27 EDT
From: Frank da Cruz <[email protected]>
To: Paul Wexelblat <[email protected]>
Cc: Mark Crispin <[email protected]>, [email protected]
Subject: Re: Just Suppose... RE: 21 years ago...
In-Reply-To: <p06020400bccea618b3d0@[10.0.1.2]>
Message-ID: <CMM.0.91.0.1084819047.fdc@sesame>

> Suppose they had not cancelled Jupiter, where do you think DEC,
> Mainframes, us, and computers would have been today???
>
Well sure, we might have hung on to these guys a while a longer,
but it was only a matter of time before Gresham's Law would prevail
(basically, "The bad drives out the good").  Big PDP-10s cost a lot
of money, and -- at least in universities -- centralized computing
was increasingly unpopular.  Everbody wanted control.  Now they
have it, I hope they're happy :-)

Also, as easy as TOPS-20 was to use, and despite the fact that we had
some 6000 users at Columbia, including many deans, administrators, and
office workers, something has happened since then to make these very
same people -- and of course all who came after them -- incapable of
dealing with words.  Now they need pictures.

It was inevitable.  PDP-10s, and centralized timesharing in general, were
too good to last.  When I say "too good", I mean users could just do their
work and leave all the management and patching and upgrading and maintenance
to the pros.  Now users spend 80% of their time playing and chatting and
shopping and stealing music, 10% on system management and maintenance, and
10% on real work.  Then when their PC is destroyed by a virus, it's 100% of
their time for several days, and all their work (if they did any) is lost.
The time spent on reinstalling the OS, all the applications, patches,
customizations, etc, declines over some amount of time until the next
disaster strikes, so "productivity" is a sawtooth curve.  Multiply this
over every person who has a PC to see the broad effect.

Some of you might already have seen my rant on modern times:

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

DEC-10/20 folks will see where it's coming from, at least Sections 3-4 :-)

- Frank

P.S. This mail comes to you from MM.
17-May-2004 14:29:10-PDT,1491;000000000000
Return-Path: <[email protected]>
Received: from sj-iport-1.cisco.com ([171.71.176.70]) by lingling.panda.com with TCP/SMTP; Mon, 17 May 2004 14:20:43 -0700 (PDT)
Received: from cypher.cisco.com (cypher.cisco.com [171.69.11.143])
       by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i4HLKfSu014485;
       Mon, 17 May 2004 14:20:41 -0700 (PDT)
Received: (from billw@localhost)
       by cypher.cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) id OAA03425;
       Mon, 17 May 2004 14:20:41 -0700 (PDT)
Sender: Bill Westfield <[email protected]>
Date: Mon, 17 May 2004 14:20:40 PDT
From: William "Chops" Westfield <[email protected]>
To: Paul Wexelblat <[email protected]>
Cc: Mark Crispin <[email protected]>, [email protected]
Subject: Re: Just Suppose... RE: 21 years ago...
In-Reply-To: Your message of Mon, 17 May 2004 13:28:06 -0400
Message-ID: <CMM.0.90.4.1084828840.billw@cypher>

>    Suppose they had not cancelled Jupiter, where do you think DEC,
>    Mainframes, us, and computers would have been today???

Gone sooner.  Jupiter would have come out in the timeframe where Moore's law
as well on its way to reality, and it wasn't good enough for the amount of
resources it was consuming.  DEC needed Jupiter to be on-par with the
Systems Concept Machines (only earlier; I'm not entirely sure that was
possible.)  Smaller and cheaper AND faster.

And a successful mainframe wouldn't have helped DEC understand the
microcomputer scene any better...

BillW


17-May-2004 14:43:39-PDT,1310;000000000000
Mail-From: MRC created at 17-May-2004 14:36:41
Date: Mon, 17 May 2004 14:36:41 -0700 (PDT)
From: Mark Crispin <[email protected]>
Subject: Re: Just Suppose... RE: 21 years ago...
To: [email protected]
In-Reply-To: <CMM.0.90.4.1084828840.billw@cypher>
Pithy-Thought: TOPS-20 was a great improvement over its successors
Message-ID: <[email protected]>

> Gone sooner.  Jupiter would have come out in the timeframe where Moore's law
> as well on its way to reality, and it wasn't good enough for the amount of
> resources it was consuming.  DEC needed Jupiter to be on-par with the
> Systems Concept Machines (only earlier; I'm not entirely sure that was
> possible.)  Smaller and cheaper AND faster.

Jupiter certainly was a failed project.

However, I disagree that a successful Jupiter would have caused
DEC to fail sooner.  Mainframes have not vanished entirely, in
spite of Moore's Law; there are still plenty of S/360 descendants
and Unisys boxes in the world.

> And a successful mainframe wouldn't have helped DEC understand the
> microcomputer scene any better...

Not clear.  Mainframes force the issue of micros.  Digital seemed
to think that VAX made them immune from the micro revolution; you
just get a smaller (or bigger) VAX.
-------
17-May-2004 15:08:43-PDT,5062;000000000000
Return-Path: <[email protected]>
Received: from turkey.mail.pas.earthlink.net ([207.217.120.126]) by lingling.panda.com with TCP/SMTP; Mon, 17 May 2004 15:01:42 -0700 (PDT)
Received: from cpe-24-221-177-162.ca.sprintbbd.net ([24.221.177.162] helo=reststop.com)
       by turkey.mail.pas.earthlink.net with esmtp (Exim 3.33 #1)
       id 1BPqAw-00043t-00; Mon, 17 May 2004 15:01:34 -0700
Date: Mon, 17 May 2004 15:01:29 -0700
Subject: Re: Just Suppose... RE: 21 years ago... other OSs?
Content-Type: text/plain; charset=US-ASCII; format=flowed
Mime-Version: 1.0 (Apple Message framework v553)
Cc: Paul Wexelblat <[email protected]>,
Mark Crispin <[email protected]>,
[email protected]
To: Frank da Cruz <[email protected]>
From: Carl Baltrunas <[email protected]>
In-Reply-To: <CMM.0.91.0.1084819047.fdc@sesame>
Message-Id: <[email protected]>
Content-Transfer-Encoding: 7bit
X-Mailer: Apple Mail (2.553)


On Monday, May 17, 2004, at 11:37 AM, Frank da Cruz wrote:

>> Suppose they had not cancelled Jupiter, where do you think DEC,
>> Mainframes, us, and computers would have been today???
>>
> Well sure, we might have hung on to these guys a while a longer,
> but it was only a matter of time before Gresham's Law would prevail
> (basically, "The bad drives out the good").  Big PDP-10s cost a lot
> of money, and -- at least in universities -- centralized computing
> was increasingly unpopular.  Everbody wanted control.  Now they
> have it, I hope they're happy :-)

I think it may have been one of those "Be careful of what you ask for,
you might get it" things as far as control.  People don't realize what
it means to have that control, and what responsibility it bears.

>  ... Now users spend 80% of their time playing and chatting and
> shopping and stealing music, 10% on system management and maintenance,
> and
> 10% on real work.  Then when their PC is destroyed by a virus, it's
> 100% of
> their time for several days, and all their work (if they did any) is
> lost.
> The time spent on reinstalling the OS, all the applications, patches,
> customizations, etc, declines over some amount of time until the next
> disaster strikes, so "productivity" is a sawtooth curve.  Multiply this
> over every person who has a PC to see the broad effect.

I wonder if some day, everyone will wake up and realize how much their
lives have been taken over by having to spend that 10% or 100% of their
life doing system maintenance.  I'm waiting to see if there will ever
be a class-action suit against Microsoft for the insecure system they
have put into people's hands and all the time lost fighting virus and
other attacks as a product liability issue.  It's probably moot, as
there must be some legal language in their boilerplate license that
says users are using this at their own risk.  I don't know, as I've
never bought a single Microsoft product, although I've come into
possession of a few over the years.

>
> Some of you might already have seen my rant on modern times:
>
>   http://www.columbia.edu/kermit/safe.html

Good rant... but for those of use here, it's probably preaching to the
choir.  Most of us are already aware of the points you made, and sadly
many have to live with the Microsoft/Intel debacle to interact with
others who have bought into it lock, stock and barrel.  (Sorry about
the cliches).

I know that some here, have been burned by Apple, but I still prefer
Apple and *NIX based systems to anything else still around.  I would
have liked Amiga to have gotten a bigger market share so as to have
some real competition against SGI, but that's just a dream today.
Unfortunately, many job prospects require knowledge of Microsoft/Intel
based systems at a hight or low level.  After 30+ years in this
business, 15-20 of which were working on DEC hardware, I am now
preferring to let others deal with the system administration issues.
It's nostalgic to think of what things might be like if DEC were still
a big player in todays computer market.  Having used TOPS-10, ITS,
Tenex, TOPS-20 (aka Twenex) and TYMCOM-X/XX myself there weren't too
many other variants of the systems I didn't use.  The hybrid system at
SAIL, I never had an account there, but did watch over peoples'
shoulders sever times.  CMU's system also hacked TOPS-10 a bit but was
mostly TOPS-10.  Online Systems and Compuserve also went their own ways
and I had exposure to their changes as friends went to work there.
What other variations were out there, anyone have a complete list?  It
would be interesting to see a timeline a la the UNIX tree, for OSs that
ran on DEC hardware.
>
> DEC-10/20 folks will see where it's coming from, at least Sections 3-4
> :-)
>
> - Frank
>
> P.S. This mail comes to you from MM.

This comes from Mail on my Mac laptop.  Also (mostly) immune to virus
attacks unless Virtual PC is installed, especially not that Microsoft
owns that product.

-Carl

17-May-2004 15:19:09-PDT,1853;000000000000
Return-Path: <[email protected]>
Received: from sj-iport-1.cisco.com ([171.71.176.70]) by lingling.panda.com with TCP/SMTP; Mon, 17 May 2004 15:10:51 -0700 (PDT)
Received: from cypher.cisco.com (cypher.cisco.com [171.69.11.143])
       by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i4HMAnC1007705;
       Mon, 17 May 2004 15:10:50 -0700 (PDT)
Received: (from billw@localhost)
       by cypher.cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) id PAA09707;
       Mon, 17 May 2004 15:10:49 -0700 (PDT)
Sender: Bill Westfield <[email protected]>
Date: Mon, 17 May 2004 15:10:49 PDT
From: William "Chops" Westfield <[email protected]>
To: Mark Crispin <[email protected]>
Cc: [email protected]
Subject: Re: Just Suppose... RE: 21 years ago...
In-Reply-To: Your message of Mon, 17 May 2004 14:36:41 -0700 (PDT)
Message-ID: <CMM.0.90.4.1084831849.billw@cypher>

   > And a successful mainframe wouldn't have helped DEC understand the
   > microcomputer scene any better...

   Not clear.  Mainframes force the issue of micros.  Digital seemed
   to think that VAX made them immune from the micro revolution; you
   just get a smaller (or bigger) VAX.

Are you assuming that if Jupiter had continued (and even been successful),
there would have been no Vax?  The Vax was a much a big pdp-11 as a smaller
mainframe, and I don't think It would have gone away.  DEC was beginning to
suffer from too many architectures with or without the 36bit line...

It is amusing, in retrospect, how many companies failed to integrate
mainframes and PCs in any meaningful way.  And how often things like the
WWW were ALMOST invented so many times before (Plato and SUN to name
two.)  DEC might have done better if the Jupiter bungle hadn't
alientated so many universities (if it did.  The university "psyche" is
hard to probe.)

BillW

17-May-2004 15:26:52-PDT,3056;000000000000
Return-Path: <[email protected]>
Received: from mv.opost.com ([199.125.75.195]) by lingling.panda.com with TCP/SMTP; Mon, 17 May 2004 15:14:41 -0700 (PDT)
Received: from road.fpl (road.fpl [172.22.41.6])
       by mv.opost.com (8.12.8/8.12.8) with ESMTP id i4HMEXc6011594
       for <[email protected]>; Mon, 17 May 2004 18:14:33 -0400
Received: from road.fpl (localhost [127.0.0.1])
       by road.fpl (8.12.10/8.12.10) with ESMTP id i4HMEWSV002175
       for <[email protected]>; Mon, 17 May 2004 18:14:32 -0400
Received: (from dlm@localhost)
       by road.fpl (8.12.10/8.12.10/Submit) id i4HMEW6x002173
       for [email protected]; Mon, 17 May 2004 18:14:32 -0400
Date: Mon, 17 May 2004 18:14:32 -0400
Message-Id: <[email protected]>
From: Dan Murphy <[email protected]>
To: [email protected]
Subject: Re: Just Suppose... RE: 21 years ago...
Reply-To: Dan Murphy <[email protected]>
X-OpostMailScanner-Information: Please contact the ISP for more information
X-OpostMailScanner: Found to be clean


   I actually think that the cancellation a year or two earlier of
   "Minnow" was a more pivotal moment.  The Jupiter cancellation may
   seem bigger in our memories because the whole line was cancelled
   with it, but the cancellation of Minnow showed that DEC had become
   incapable of thinking outside the boxes that it had already built.
   Specifically, I heard these reasons stated out loud while we were
   working on Minnow:

   1. 10/20's are "mainframes", so no one could possibly want a
   smaller (and cheaper) one.

   2. A 10/20 could be of no possible use without a big, expensive
   magtape drive connected to it.

   And it was people in the 10/20 product line making these
   arguments; not people in VAXland who would happily kill any and
   all 36-bit machines anyhow.

   You can blame Ken Olsen and Bill Johnson for the cancellation, but
   the people in the 10/20 line deserve at least as much of the blame
   for all the ways they screwed up the business and the engineering.

   Ken Olsen even came by and pronounced the Minnow prototype a nifty
   bit of engineering, but still shot it in the head.  Of course, it
   would have competed right in the center of the VAX price band, and
   Ken had already put out his "Backhoe" memo...

   More broadly, DEC was doomed from the day Ken declared "One
   Company, One Message, ..." (one egg, one basket, one coffin, one
   tombstone, ...)  The 36-bit cancellation was just one action that
   flowed from that disastrous mindset.



   dlm


=====================

   Mark Crispin <[email protected]> on Mon, 17 May 2004 14:36:41 -0700 (PDT) writes:

> > And a successful mainframe wouldn't have helped DEC understand the
> > microcomputer scene any better...

> Not clear.  Mainframes force the issue of micros.  Digital seemed
> to think that VAX made them immune from the micro revolution; you
> just get a smaller (or bigger) VAX.

17-May-2004 15:36:58-PDT,1717;000000000000
Return-Path: <[email protected]>
Received: from sj-iport-1.cisco.com ([171.71.176.70]) by lingling.panda.com with TCP/SMTP; Mon, 17 May 2004 15:29:09 -0700 (PDT)
Received: from cypher.cisco.com (cypher.cisco.com [171.69.11.143])
       by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i4HMT7C1001296;
       Mon, 17 May 2004 15:29:08 -0700 (PDT)
Received: (from billw@localhost)
       by cypher.cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) id PAA20607;
       Mon, 17 May 2004 15:29:07 -0700 (PDT)
Sender: Bill Westfield <[email protected]>
Date: Mon, 17 May 2004 15:29:07 PDT
From: William "Chops" Westfield <[email protected]>
To: Carl Baltrunas <[email protected]>
Subject: Re: Just Suppose... RE: 21 years ago... other OSs?
In-Reply-To: Your message of Mon, 17 May 2004 15:01:29 -0700
Cc: [email protected]
Message-ID: <CMM.0.90.4.1084832947.billw@cypher>

>    I wonder if some day, everyone will wake up and realize how much their
>    lives have been taken over by having to spend that 10% or 100% of their
>    life doing system maintenance.

Bah.  10% doing systems maintenance vs 10% getting the people who did
systems maintenance to do what I wanted them too.  No big deal.  I'd be
more worried about the 50% extra time spent making presentations look good
without out adding any actual content.  Compare a 1982 DECUS with DEC and
user presentations done using B&W typed overhead transparencies vs one of
today's "modern" presentations with computer, high-res digital color
projector, and animated powerpoint slides.  Is todays presentation
"better"?  Probably.  Enough better to justify the extra work that goes
into making (and presenting) it?  Probably not.

BillW





17-May-2004 15:43:55-PDT,1852;000000000000
Mail-From: MRC created at 17-May-2004 15:30:03
Date: Mon, 17 May 2004 15:30:03 -0700 (PDT)
From: Mark Crispin <[email protected]>
Subject: Re: Just Suppose... RE: 21 years ago...
To: [email protected]
cc: [email protected]
In-Reply-To: <CMM.0.90.4.1084831849.billw@cypher>
Pithy-Thought: TOPS-20 was a great improvement over its successors
Message-ID: <[email protected]>

> Are you assuming that if Jupiter had continued (and even been successful),
> there would have been no Vax?

No, not at all.

Rather, I am contending that the fantasy of "all the world is (or
should be) a VAX" never would have taken hold at Digital.

Digital never took PCs seriously, thinking that instead of a PC
people should just get a bitty VAX.  If they still had a
mainframe product line, they would have been forced to deal with
the reality of PCs.

> DEC was beginning to
> suffer from too many architectures with or without the 36bit line...

Too many architectures?  Only if you define "too many" as being
"more than one".

By 1983, the 12-bit and 18-bit product lines were dead.  The
writing was clearly on the wall for 16-bit.

The cancellation of 36-bits was a move to be a one-architecture
company; and more importantly to an operating system that they
had much tighter control over.

> DEC might have done better if the Jupiter bungle hadn't
> alientated so many universities (if it did.  The university "psyche" is
> hard to probe.)

It wasn't just universities that they alienated.  A number of
corporations also got burned by the Jupiter fiasco.  One fellow
at DECUS got a page from his office telling him to return
immediately to clean out his desk; he made it quite clear that it
would be a cold day in hell before he ever had anything to do
with Digital product again.
-------
17-May-2004 15:51:32-PDT,1962;000000000000
Return-Path: <[email protected]>
Received: from epsilon3.corestore.org ([216.220.114.27]) by lingling.panda.com with TCP/SMTP; Mon, 17 May 2004 15:34:09 -0700 (PDT)
Return-Path: <[email protected] ([68.198.25.144])>
Received: from ool-44c61990.dyn.optonline.net ([68.198.25.144]) by epsilon3.corestore.org id 919 ; Mon, 17 May 2004 19:05:48 -0400
From: Michael Ross <[email protected]>
To: [email protected]
Subject: Re: Just Suppose... RE: 21 years ago...
Date: Mon, 17 May 2004 18:31:24 -0400
Message-ID: <[email protected] ([68.198.25.144])>
References: <CMM.0.90.4.1084828840.billw@cypher> <[email protected] ([206.124.149.115])>
In-Reply-To: <[email protected] ([206.124.149.115])>
X-Mailer: Forte Agent 1.93/32.576 English (American)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable

On Mon, 17 May 2004 14:36:41 -0700 (PDT), you wrote:

>Mainframes have not vanished entirely, in
>spite of Moore's Law; there are still plenty of S/360 descendants
>and Unisys boxes in the world.

Not the best example to choose, IMHO. Mainframes have a problem with
Moore's law, yes, but it's rather in the opposite sense to that which
you imply: CMOS mainframe CPU performance has reached a level where
the biggest problem in that market is software costs (since most
software vendors price their products according to the performance of
the machine they're being run on).

IBM have had to introduce deliberately crippled systems, with degraded
performance, simply to address the issue of software costs.

Lemmings, the lot of them...

Lack of performance hasn't been a significant issue for some time -
just buy more processors and lash 'em together in a sysplex...

Mike
http://www.corestore.org

'As I walk along these shores
I am the history within'
17-May-2004 16:58:26-PDT,1684;000000000000
Return-Path: <[email protected]>
Received: from sj-iport-2.cisco.com ([171.71.176.71]) by lingling.panda.com with TCP/SMTP; Mon, 17 May 2004 16:50:01 -0700 (PDT)
Received: from sj-core-1.cisco.com (171.71.177.237)
 by sj-iport-2.cisco.com with ESMTP; 17 May 2004 15:55:30 +0000
Received: from cypher.cisco.com (cypher.cisco.com [171.69.11.143])
       by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i4HNnxC1029203;
       Mon, 17 May 2004 16:49:59 -0700 (PDT)
Received: (from billw@localhost)
       by cypher.cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) id QAA14844;
       Mon, 17 May 2004 16:49:59 -0700 (PDT)
Sender: Bill Westfield <[email protected]>
Date: Mon, 17 May 2004 16:49:59 PDT
From: William "Chops" Westfield <[email protected]>
To: Mark Crispin <[email protected]>
Cc: [email protected]
Subject: Re: Just Suppose... RE: 21 years ago...
In-Reply-To: Your message of Mon, 17 May 2004 15:30:03 -0700 (PDT)
Message-ID: <CMM.0.90.4.1084837799.billw@cypher>

>    Too many architectures?  Only if you define "too many" as being
>    "more than one".

How about "more architectures than they were willing or able to manage"?
But you're right; it was less a matter of having too many in an absolute
sense than thinking that they only needed one.  (OTOH, arguably the WORLD
now how fewer successful architectures for general purpose computing than
DEC had in 1982...  Where "successful" is something like "more than 5% of
sales on a per-count basis.")


> It wasn't just universities that they alienated.

Of course not.  But the universities had the best chance of doing something
meaningful in the mainframe/pc integration area.

BillW

22-May-2004 15:09:18-PDT,12922;000000000000
Return-Path: <[email protected]>
Received: from mta8.srv.hcvlny.cv.net ([167.206.5.75]) by lingling.panda.com with TCP/SMTP; Sat, 22 May 2004 15:01:46 -0700 (PDT)
Received: from optonline.net (ool-182f33c4.dyn.optonline.net [24.47.51.196])
by mta8.srv.hcvlny.cv.net
(iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar  3 2004))
with ESMTP id <[email protected]> for
[email protected]; Sat, 22 May 2004 18:01:43 -0400 (EDT)
Date: Sat, 22 May 2004 18:01:03 -0400
From: Thomas DeBellis <[email protected]>
Subject: Fun with FTP
To: Tops-20 Wizards <[email protected]>
Message-id: <[email protected]>
MIME-version: 1.0
X-Mailer: Mozilla 4.5 [en]C-CCK-MCD BA45DSL  (WinNT; U)
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7BIT
X-Accept-Language: en

I was recently using the Tops-20 FTP client to track down some
problems that I'm having with getting some data from a service bureau.
It's REALLY great having something besides old versions of SCO Unix
for regression testing!  It turns out that they were running
Windows/ME with a very old and apparently non-compliant FTP server.
They've since finally bitten the bullet and upgraded some of these
systems to Windows 2000 and say that they will look at Linux in the
future (I strongly resisted the urge to suggest to them that they use
Tops-20, instead).  Tops-20 FTP works with Windows 2000.

While I was doing this, I ran into a problem with entering and
printing foreign directory specifications.  The Tops-20 FTP client was
only parsing for a field (.CMFLD) on the CONNECT comand and the break
mask was set to break on a space.  This made it impossible to enter
such remote directory strings as "My Losing Directory".  Another minor
problem was that FTP doesn't implement the PWD command, either.

You can use QUOTE to send the command, but this gets tedious very
fast.  What really gets tedious is that if you type PWD to the FTP
command line by mistake, it tries to connect to host "PWD" which
doesn't exist.  That causes FTP to wedge while it attempts to do a DNS
resolution.  Not good when you're bragging to the kidddies...

So, I've hacked together an FTP which fixes these things along with
some other cutenesses.  I've implemented PWD and changed the CONNECT
command function descriptor blocks to allow a quoted string in
addition to the field.  I might revisit the CONNECT parsing logic
again.  When the connection is closed, FTP makes the (reasonable)
assumption that you want to do a local CONNECT.

Once you ARE connected to a foreign host, however, I didn't see any
way to change the local connected directory.  I know that you can
control-C and use the Exec to do this, but it seems that if it does it
when you're not connected, it might as well do it when you are.  Other
FTP clients have commands like "lcd" (which are more necessary on
operating systems that don't implement the idea of a job wide
connected directory).  Maybe I could have a "/LOCAL" switch on CONNECT
and have LCD be an invisible abbreviation to an alternate entry point
in the parse code?

As far as the cutenesses go, I don't allow a top level parse for a
remote system once an open connection exists.  Thus, you can still do
things like @FTP FOO.BAR.EDU and have the right thing happen.  If you
close the connection, then you can simply type the name of the next
host that you want to go to at top level (although some of the
defaults then seem to get screwed up).

I've taken off a number of the suppressed standard helps (CM%SDH)
because I like to have lots of blather.  In particular, I didn't
notice that all the SET commands can also be parsed as top level
commands.  In other words, instead of typing something like "SET
VERBOSITY VERBOSE" you can simply type "VERBOSITY VERBOSE" and the
right thing will happen.  I thought that was pretty cute, but never
noticed it because it isn't listed as a keyword at top level.

I changed the linkage definitions to make it easier to build FTP in
the future.  As it stands now, like many other programs, FTP needs to
be run once to do some post linkage changes (called a 'postlude') to
its .EXE file.  The initial .EXE has no start address, but that's no
problem because the batch file starts it at the appropriate place.

Unfortunately, it issues the START command to the EXEC with a symbolic
address.  This gronks because the PANDA EXEC will only parse a numeric
address.  I was doing an EXAMINE on the symbol of the once only
routine and then using the result in the start, but that got old REAL
fast.

Since the address of the routine changed, I couldn't just get it out
of the coimmand history.  I didn't feel PCL'ish either, so...  I set
an entry vector.  Now you can simply start FTP at the end of the link
and have it do the right thing.  I'm not sure if this is the right
thing, but at least it works for now.  I think it might be a nice idea
to change the EXEC START command parse logic to accept and process a
symbolic address.

It should be noted that this version of FTP is now technically NOT
compatible with the PANDA Tops-20 FTPSER which doesn't implement
"PWD".  I've implemented it there, also, along with some other
commands in order to get the Windows Explorer and GNU Ange-FTP mode to
work (I'm still not done with that).  If anybody wants these, just ask
me offline (don't all come running at once!).  Once I finally
straighten out making Ange-FTP work (or give up and port Samba), I'll
post the FTPSER changes.

Finally, I noticed that a number of local errors generated by FTP
don't appear to be preceded with a "?" (i.e., doesn't look like an
ESOUT% is being done).  That means that FTP can't (easily) be used in
a batch stream.  Heavens!  Since I'm starting to run nightly batch
frobs to copy stuff around, I'm thinking about changing this so that I
can have appropriate error reporting and stuff from Batcon.

The remote errors are a more interesting case.  I'd like to also have
an ESOUT% when the remote server can't perform an action.  I guess I
could look for a 550 error and type the information with an ESOUT%.  I
don't remember whether this might mean modifying the UUO handler a bit
to handle a formatting type.

The real issue would be tracking down all the error response codes in
the RFC and then looking for them and doing the ESOUT%.  As I recall,
this was another reason that I wrote Viking; automatically recovering
from signalled FTP errors in a nightly batch stream.

File 1) STAR:FTP.MAC[4,24]      created: 1315 21-May-104
File 2) PS:FTP.MAC[4,52]        created: 0519 20-Jul-86

1)1     ;[TOMMYT]STAR:<FTP>FTP.MAC.297, 21-May-2004 02:44:35, Edit by SLOGIN
1)      ;[T16] Bring client up to date with newer servers, misc. cuteness
1)      ; 0) Implement PWD command
1)      ; 1) Don't allow an implied open if already open; require a close, first
1)      ; 2) Use standard help for top level commands
1)      ; 3) Use standard help for abbreviated SET commands
1)      ; 4) Set up a default entry so we don't have to futz around when
1)      ;    building an FTP.  We can't start a postlude with an EXEC that
1)      ;    doesn't handle a symbolic start address.  We set a default start
1)      ;    up and FTP smashes that when it finishes doing its once only thing.
1)      ; 5) Fix the connect command to parse a directory with spaces
1)      ;<FTP>FTP.MAC.296, 20-Jul-86 02:19:06, Edit by WHP4
****
2)1     ;<FTP>FTP.MAC.296, 20-Jul-86 02:19:06, Edit by WHP4
**************
1)2     VEDIT==303              ;[T16]  ; Edit version
1)      VWHO==6                 ;[T16]  ; Who last edited (4 = Stanford)
1)              PTITLE(FTP, -- Pup and Internet FTP user program)
****
2)2     VEDIT==302                      ; Edit version
2)      VWHO==0                         ; Who last edited (4 = Stanford)
2)              PTITLE(FTP, -- Pup and Internet FTP user program)
**************
1)7             T PWD                   ;;[T16] Print working directory
1)              TA Q
****
2)7             TA Q
**************
1)9               TYPE <Stanford/TT TOPS-20 FTP %1S, type HELP if you need it.%/> ;;[T16]
1)              ENDIF.
****
2)9               TYPE <Stanford TOPS-20 FTP %1S, type HELP if you need it.%/>
2)              ENDIF.
**************
1)9             MOVEI B,[FLDDB. .CMKEY,,CMDDSP,,,[                      ;;[T16]
1)                       FLDDB. .CMKEY,,SETDSP,<a SET command>,,,]]     ;;[T16]
1)              TXNN F,F%COPN           ;[T16] Is there a connection open?
1)               MOVEI B,[FLDDB. .CMKEY,,CMDDSP,,,[                     ;;[T16]
1)                        FLDDB. .CMKEY,,SETDSP,<a SET command>,,[      ;;[T16]
1)                        FLDBK. .CMFLD,CM%SDH,,<type a network host name or number>,,HSTBRK]]]
1)              CALL .COMND
****
2)9             MOVEI B,[FLDDB. .CMKEY,,CMDDSP,<
2)        Type HELP for a brief example of how to use FTP.
2)        Type HELP <command> for a detailed explanation of a particular command.
2)        Now type an FTP command,>,,[
2)                       FLDDB. .CMKEY,CM%SDH,SETDSP,,,[
2)                       FLDBK. .CMFLD,CM%SDH,,<type a network host name or number>,,HSTBRK]]]
2)              CALL .COMND
**************
1)54    ;[T16] Begin Code Addition
1)      SUBTTL PWD command.
1)      H.PWD: ASCIZ/The PWD command causes the foreign machine to display the current
1)      working directory.  Depending on the operating system, this may be a
1)      default directory, a connected directory or a string that is a prefix
1)      to a file specification.
1)
1)      Note: The PANDA 5.32(41)-7 FTP Server (FTPSER) does NOT implement
1)            code to properly handle the PWD command!  Modifications to do
1)            this exist in version 5.32(44)-7, currently available on Tommy
1)            Timesharing.
1)      /                               ;[T16] We are sooo helpful!
1)      C.PWD:  NOISE <to print foreign working directory>
1)              CALL CONFRM             ;[T16] Tie off the line
1)              IFXE. F,F%COPN          ;[T16] Is there any point to this?
1)                TYPE <No connection is open%/>
1)                RET                   ;[T16] No foreign anything, so
1)              ENDIF.                  ;[T16] no point asking about it.
1)              CALL @.PWD(V)           ;[T16] Call protocol dependent routine
1)              RET                     ;[T16] Finally done, get lost
1)      ;[T16] End Code Addition
1)55    SUBTTL CONNECT command.
****
2)54    SUBTTL CONNECT command.
**************
1)55            MOVEI B,[FLDDB. .CMCFM,,,<to clear the remote directory,>,,[ ;;[T16]
1)                       FLDDB. .CMQST,,,<for remote directory with spaces, use a>,,[ ;;[T16]
1)                       FLDBK. .CMFLD,,,^_
1)                        <for remote directory with NO spaces, simply type the name>,,REMBRK]]]
1)              CALL .COMND
****
2)54            MOVEI B,[FLDDB. .CMCFM,CM%SDH,,,,[
2)                       FLDBK. .CMFLD,CM%SDH,,<remote directory>,,REMBRK]]
2)              CALL .COMND
**************
1)106           EXTERN FTPINI           ;[T16] Once only routine for first
1)              END <1,,FTPINI>         ;[T16] start up to clean up some stuff
****
2)105           END
**************

File 1) STAR:FTPDEF.MAC[4,24]   created: 0412 21-May-104
File 2) PS:FTPDEF.MAC[4,52]     created: 0329 15-Sep-88

1)1     ;[TOMMYT]STAR:<FTP>FTPDEF.MAC.114, 21-May-2004 04:10:40, Edit by SLOGIN
1)      ;[T16] Add PWD
1)      ;<FTP>FTPDEF.MAC.113, 15-Sep-88 00:29:56, Edit by MRC
****
2)1     ;<FTP>FTPDEF.MAC.113, 15-Sep-88 00:29:56, Edit by MRC
**************
1)4     .PWD==23                ;;[T16] ; Print foreign working directory
1)              VECSIZ==:.PWD+1 ;;[T16] ; How many entries there are in the vector
1)      DEFINE CHKVEC (LAB) <
****
2)4             VECSIZ==:.RMDIR+1       ; How many entries there are in the vector
2)      DEFINE CHKVEC (LAB) <
**************

File 1) STAR:FTPLUD.MAC[4,24]   created: 0323 21-May-104
File 2) PS:FTPLUD.MAC[4,52]     created: 1908 30-Mar-84

1)1     ;[TOMMYT]STAR:<FTP>FTPLUD.MAC.24, 21-May-2004 03:16:09, Edit by SLOGIN
1)      ;[T16] Set up a default entry so we don't have to futz around
1)      ;      starting a postlude with an EXEC that doesn't handle a
1)      ;      symbolic start addressing
1)              SEARCH FTPDEF
****
2)1             SEARCH FTPDEF
**************
1)2             INTERN FTPINI           ;[T16] Let other people know about it
1)      FTPINI: RESET%                  ; Init the world
****
2)2     FTPINI: RESET%                  ; Init the world
**************

File 1) STAR:TCPFTP.MAC[4,24]   created: 0448 21-May-104
File 2) PS:TCPFTP.MAC[4,52]     created: 1620 28-Dec-101

1)1     ;[TOMMYT]STAR:<FTP>TCPFTP.MAC.317, 21-May-2004 04:05:59, Edit by SLOGIN
1)      ;[T16] Offsets for the PWD command
1)      ;<FTP>TCPFTP.MAC.316, 28-Dec-2001 13:20:37, Edit by MRC
****
2)1     ;<FTP>TCPFTP.MAC.316, 28-Dec-2001 13:20:37, Edit by MRC
**************
1)1             TCPPWD          ;[T16]  ; .PWD - Print Working Directory
1)      CHKVEC TCPVEC                   ; Make sure vector is right
****
2)1     CHKVEC TCPVEC                   ; Make sure vector is right
**************
1)24    ; .PWD - Prints Foreign Working Directory
1)      TCPPWD: FTPM <PWD>              ;[T16] Request server working directory
1)              CALL TCPRSQ             ;[T16] Read reply being quiet about errors
1)               NOP                    ;[T16] Error, just fall through
1)                NOP                   ;[T16] Retry needed, just fall through
1)               TYPE <%3S%/>           ;[T16]  Else type server response without angles
1)      TCPPW0: CAIN B,"-"              ;[T16] Continued?
1)               JRST TCPPW0            ;[T16]  Yes, get rest
1)              RET                     ;[T16] Finally done
1)25    ; TCPSTU - see if TCPSCN and TCPPRP can be used for this operating system
****
2)24    ; TCPSTU - see if TCPSCN and TCPPRP can be used for this operating system
**************

22-May-2004 20:23:20-PDT,566;000000000000
Mail-From: MRC created at 22-May-2004 20:15:59
Date: Sat, 22 May 2004 20:15:59 -0700 (PDT)
From: Mark Crispin <[email protected]>
Subject: Re: Fun with FTP
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]>

Thank you Tom for your suggestions.  I have adopted all of them, although
I made a few changes.  Available via ANONYMOUS FTP from PS:<FTP> at
lingling.panda.com
-------
23-May-2004 14:19:59-PDT,4698;000000000000
Return-Path: <[email protected]>
Received: from mta2.srv.hcvlny.cv.net ([167.206.5.68]) by lingling.panda.com with TCP/SMTP; Sun, 23 May 2004 14:12:07 -0700 (PDT)
Received: from optonline.net (ool-182f33c4.dyn.optonline.net [24.47.51.196])
by mta2.srv.hcvlny.cv.net
(iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar  3 2004))
with ESMTP id <[email protected]>; Sun,
23 May 2004 17:12:03 -0400 (EDT)
Date: Sun, 23 May 2004 17:11:43 -0400
From: Thomas DeBellis <[email protected]>
Subject: Re: Fun with FTP
To: [email protected]
Cc: Tops-20 Wizards <[email protected]>
Message-id: <[email protected]>
MIME-version: 1.0
X-Mailer: Mozilla 4.5 [en]C-CCK-MCD BA45DSL  (WinNT; U)
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7BIT
X-Accept-Language: en
References: <[email protected]>

MRC,

Thanks for taking my changes.  Anyway, they do make FTP more
convenient, don't they?  I noticed that you punted (CM%SDH) the
supplied help text for CONNECT command.  That was probably a good
thing, because I think that the semantics of the command itself still
seem unclear.  But I don't immediately see what the right thing is to
do.  As it stands now, the command appears to do the following:

When NOT connected:

1) Parse a carriage return and stomp CONNAM.
2) Parse a directory string and store that in CONNAM.  Always ask for
   a password and store whatever is typed (including nothing) in
   CONPSW.
3) Cleverly use CONNAM and CONPSW in various places once connected.
   (I haven't really nosed around much for #3)

Once Connected:

1) Same parse structure
2) Always, issue winning remote CWD command, sometimes automagically
3) On a carriage return, issue ONLY a CWD (wih no arguments)

I was able to test the results on various machines:

1) Windows 2000: SUCCEED, returns to "/"

2) SCO Unix: 500 'CWD ': command not understood
3) Unknown Columbia FTP: 500 'CWD ': command not understood
4) Unknown ftp.gnu.org:  500 'CWD ': command not understood
5) Better Telnet, MacOS: 501 Directory not present or syntax error
6) Tops-20, FTPSER: 501 No such directory - CWD

As can be seen, nearly all systems that I tested failed, with the
exception of Windows.  I don't know what #2 and #3 were.  They
responded to SYST with a '215 UNIX Type: L8', which I didn't
recognize.

I didn't see how any of the supplied FTP documentation (.MSS), etc.
really clarified this point: it's silent on no string being input.
However, RFC959 indicates that the syntax for CWD is the following
"CWD <SP> <pathname> <CRLF>".  The relevant BNF for <pathname> is the
following:

   <pathname> ::= <string>
   <string> ::= <char> | <char><string>
   <char> ::= any of the 128 ASCII characters except <CR> and <LF>

It's been nearly 20 years since my last compiler class, but this BNF
snippit is fairly straight forward.  A pathname is a string.  A string
is one of more characters except carriage return and linfeed.  I
wonder if the above means PRINTING characters.  If not, then strings
with embedded ^@ (NUL) and other randomness might be fun to try.

So, it would seem that Windows is out of specification for accepting a
CWD command with no arguments and that the Tops-20 FTP client is out
of specification for accepting it.  But!  Neither the SCO UNIX,
Windows nor Lindows FTP clients parse for a zero length directory
path.  Perhaps would mean that they are trying to adhere to RFC959?
In any event, this leaves us with the decision of what to do about the
Tops-20 FTP client.  I think that there are two choices:

1) Disallow the parsing of a zero length string when connected.
   Allow the parsing of a zero length string in TAKE files when not
   connected.

2) Leave the client alone.

The question then is, what to do with FTPSER.  It certainly seems like
a bad idea to have it gronk on commands being sent to it by a Tops-20
client!  I think that the Windows 2000 approach is very suggestive.
It puts you some place.  That place is the root of the FTP file
system.  Today, if I simply type "CONNECT" to the Exec, I wind up in
my login directory.

I think that FTPSER should be changed to connect user into their login
directory when a CWD command issued with no pathname.  Since I'm
hacking FTPSER now, already, I know that this is basically a trivial
change and would be delighted to do it.  Since this isn't quite
conforming to RFC959, I suppose we could growl at the user a bit, but
still do the connect.

                             Comments?

                                        --T

23-May-2004 17:34:35-PDT,22383;000000000000
Return-Path: <[email protected]>
Received: from mta6.srv.hcvlny.cv.net ([167.206.5.72]) by lingling.panda.com with TCP/SMTP; Sun, 23 May 2004 17:27:20 -0700 (PDT)
Received: from optonline.net (ool-182f33c4.dyn.optonline.net [24.47.51.196])
by mta6.srv.hcvlny.cv.net
(iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar  3 2004))
with ESMTP id <[email protected]>; Sun,
23 May 2004 20:24:59 -0400 (EDT)
Date: Sun, 23 May 2004 20:24:20 -0400
From: Thomas DeBellis <[email protected]>
Subject: Re: Fun with FTP
To: [email protected]
Cc: Tops-20 Wizards <[email protected]>
Message-id: <[email protected]>
MIME-version: 1.0
X-Mailer: Mozilla 4.5 [en]C-CCK-MCD BA45DSL  (WinNT; U)
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7BIT
X-Accept-Language: en
References: <[email protected]> <[email protected]>

Actually, the changes to the Tops-20 FTP server were so trivial that I
just did them.  Here are the DIFs for an FTPSER that implements SYST,
PWD, CDUP, SIZE, MDTM and CWD with a zero length pathname getting to
the login directory.

It will be noticed that in the CDUP command that I actually grovel the
directory string.  This was before I know about stuff like <..> in
Tops-20.  As I'm not sure whether the 'standard' Tops-20 monitor
implements this, I left the code the way it is.

File 1) STAR:FTPSER.MAC[4,24]   created: 2001 23-May-104
File 2) PS:FTPSER.MAC[4,52]     created: 1717 03-Dec-85

1)      ;;[TOMMYT]STAR:<FTP>FTPSER.MAC.64, 11-Jul-2003 12:09:45, Edit by SLOGIN
1)      ;
1)      ;;[T17] On a CWD with a 0 length pathname, go to login directory
1)      ;
1)      ;;T3   Support for SIZE and MDTM.  Note that these command do NOT
1)      ;       appear in RFC959 or any other RFC except for 2389, which only
1)      ;       discusses feature negotiation, not implementation.  This
1)      ;       implementation was done by investigating the returns fr m
1)      ;       various Unix and Windows server implementations along with
1)      ;       expected values for clients such as the ange-ftp package
1)      ;
1)      ;;T2    Put in some commands to enable the Tops-20 FTP server to provide
1)      ;       service to some newer graphical and character based semi-
1)      ;       automatic FTP clients (i.e., Microsoft Internet Explorer and
1)      ;       gnuEmacs) which need some more recent commands to function
1)      ;       properly.
1)      ;
1)      ;       'PWD'   is an informational command that prints the currently
1)      ;               connected or 'working' directory.
1)      ;       'XPWD'  is simply a synonym for 'PWD', per RFC 1123.
1)      ;       'SYST'  is an informational command that prints the current
1)      ;               system type and some other relevant information.
1)      ;       'CDUP'  connects to this directory's superior.
1)      ;
1)      ;<SUBSYS.CMU>FTPSRT.MAC.40, 18-Nov-85 03:09:52, Edit by VAF
****
2)1     ;<SUBSYS.CMU>FTPSRT.MAC.40, 18-Nov-85 03:09:52, Edit by VAF
**************
1)2     VWHO==7         ;[T17] Last edited by SLOGIN
1)      VMAJOR==5       ; Major Version #
1)      VMINOR==^D26    ; Make "Z" to be higher than "T" in standard version...
1)      VEDIT==45       ;[T17] Edit Number
1)              LOC     <.JBVER==137>
****
2)2     VWHO==7         ; Last edited by VAF
2)      VMAJOR==5       ; Major Version #
2)      VMINOR==^D26    ; Make "Z" to be higher than "T" in standard version...
2)      VEDIT==40       ; Edit Number
2)              LOC     <.JBVER==137>
**************
1)25    CRLFM:  BYTE (7) C.CR, C.LF , C.NUL
1)      PREPLY: POINT 7,REPLYM
****
2)25    CRLFM:  BYTE (7)C.CR,C.LF,C.NUL
2)      PREPLY: POINT 7,REPLYM
**************
1)28    CC (PWD,C.LGN)          ;;T2 Standard name for 'P'rint 'W'orking 'D'irectory
1)      CC (XPWD,C.LGN)         ;;T2 Experimental synonym for same
1)      CC (SYST,0)             ;;T2 Provide system information, even if not logged in
1)      CC (CDUP,C.LGN)         ;;T2 Connect to directory's superior
1)      CC (SIZE,C.LGN)         ;;T3 Size of a file in bytes
1)      CC (MDTM,C.LGN)         ;;T3 Last modification time of file in GMT
1)      ; FOLLOWING ARE NOT PART OF FORMAL SYNTAX BUT ARE ACCEPTED
****
2)28    ; FOLLOWING ARE NOT PART OF FORMAL SYNTAX BUT ARE ACCEPTED
**************
1)63    ZSYST:  CALL BEGREP             ;T2 Proclaim to all of the world that
1)              ASCIZ /215 TOPS20 /     ;T2 we are a WINNING Tops-20 system!
1)              MOVE T2,A               ;T2 A was side-effected with updated REPLYP
1)              SETZ T1,                ;T2 Initialize system version text index
1)                                      ;T2 Now get monitor data into our reply
1)      ZSYSGV: HRRI A,.SYSVE           ;T2 Want system version text
1)              HRL A,T1                ;T2 Current index into said text
1)              GETAB%                  ;T2 Load the current quintet into AC1
1)               ERJMPS ZSYSEL          ;T2  Failed--so we're done: send the reply
1)                JUMPE A,ZSYSEL        ;T2   PRESUME a zero word means no more data
1)              MOVE D,A                ;T2 Load returned word into double shifter
1)              MOVX B,^D5              ;T2 Five characters per quintet
1)                                      ;T2 Maybe LSHC is faster than an ILDB?
1)      ZSYSCB: LSHC C,^D7              ;T2 So load up an ASCII byte from the quintet
1)              TXNN C,177              ;T2 Did we shift in a NULL?
1)               JRST ZSYSCD            ;T2  We did, PRESUME that the copy is done
1)              IDPB C,T2               ;T2 Deposit the byte into the reply buffer
1)               SOJG B,ZSYSCB          ;T2  Go copy some more bytes
1)      ZSYSCD:   AOJA T1,ZSYSGV        ;T2   Step to the next quintet of version text
1)                                      ;T2 Here when we got all the text
1)      ZSYSEL: MOVEM T2,REPLYP         ;T2 Update pointer for written text
1)              JSP B,RPCRLP            ;T2 Tie off the line with a CRLF
1)              0                       ;T2 and ship to user, no extra data
1)      ZSITE:  CALL GETARG             ;CS129 Have any argument?
****
2)63    ZSITE:  CALL GETARG             ;CS129 Have any argument?
**************
1)64    214-  USER, PASS, ACCT, HELP, QUIT, SYST
1)      214-  SITE, TYPE A, MODE S, STRU F and NOOP.
1)      214-After logging in, the following are also allowed:
1)      214-  TYPE I, TYPE L 1 to 36, STRU P, CDUP, PWD,
1)      214-  RETR, STOR, APPE, RNFR, RNTO, SMNT, MDTM, CWD,
1)      214-  DELE, LIST, NLST, STAT, PASV, SIZE and PORT.
1)      214 End of help text./ ;;T2 & T3
1)      HMSLI:  ASCIZ /214-The following commands are allowed:
1)      214-  PASS, ACCT, HELP, QUIT, NOOP, SYST
1)      214-  SITE, TYPE I, TYPE L 1 to 36, STRU P, CDUP
1)      214-  PWD, RETR, STOR, APPE, RNFR, RNTO, SMNT, CWD,
1)      214-  DELE, LIST, NLST, STAT, RSTA, RLST, PASV
1)      214-  SIZE, MDTM and PORT.
1)      214 End of help text./ ;;T2 & T3
1)65            SUBTTL  Password when logged in may be for CWD
****
2)64    214-  USER, PASS, ACCT, HELP, QUIT,
2)      214-  SITE, TYPE A, MODE S, STRU F, and NOOP.
2)      214-After logging in, the following are also allowed:
2)      214-  TYPE I, TYPE L 1 to 36, STRU P,
2)      214-  RETR, STOR, APPE, RNFR, RNTO, SMNT, CWD,
2)      214-  DELE, LIST, NLST, STAT, PASV, and PORT.
2)      214 End of help text./
2)      HMSLI:  ASCIZ /214-The following commands are allowed:
2)      214-  PASS, ACCT, HELP, QUIT, NOOP,
2)      214-  SITE, TYPE I, TYPE L 1 to 36, STRU P,
2)      214-  RETR, STOR, APPE, RNFR, RNTO, SMNT, CWD,
2)      214-  DELE, LIST, NLST, STAT, RSTA, RLST, PASV,
2)      214-  and PORT.
2)      214 End of help text./
2)65            SUBTTL  Password when logged in may be for CWD
**************
1)67            SUBTTL  Post-Login Command Execution Routines - PWD
1)      ;T2 Note, the screwy ;;" stuff is to make the gnuEmacs font lock
1)      ;T2 color formatter not get confused.  It has no effect on generated
1)      ;T2 code.
1)      ZXPWD:  REMARK                  ;T2 Experimental synonym verb
1)      ZPWD:   CALL BEGREP             ;T2 Begin a new reply
1)              ASCIZ /257 "/   ;;"     ;T2 Use EXACT syntax as displayed by Unix
1)              GJINF%                  ;T2 Find out where we are connected
1)              MOVE A,REPLYP           ;T2 Reload the reply buffer pointer
1)              DIRST%                  ;T2 Now drop in the text
1)               ERJMPS ZPWD1           ;T2  Uh oh: file system is probably trashed!
1)              MOVEM A,REPLYP          ;T2 Update pointer for written text
1)      ZPWD1:  JSP B,RPCRLP            ;T2 Jumped here to preserve pointer
1)              ASCIZ /" is current directory./ ;;" ;T2 Same text format as Unix
1)              SUBTTL  Post-Login Command Execution Routines - CDUP
1)      ;T2 Note, once you are in a top-level directory on TOPS-20, there
1)      ;T2 is really no place to go.  There is a ROOT-DIRECTORY, but one
1)      ;T2 normally never accesses this directly.  You can step directories
1)      ;T2 via RCDIR%.  I find this more convenient than Unix based file
1)      ;T2 systems where you can't easily directly specify a subset of
1)      ;T2 directories.  However, we can only simulate Unix semantics
1)      ;T2 so far.  So, unless you are a WHEEL, CDUP stops in the last
1)      ;T2 top level directory it saw.
1)      ZCDUP:  GJINF%                  ;T2 Find out where we are connected
1)              HRROI A,CDUSTR          ;T2 Point to a location to build the
1)              DIRST%                  ;T2 directory string and then translate it
1)               ERJMP XCWD1            ;T2  Uh oh, file system is probably trashed!
1)              MOVX A,<POINT 7,CDUSTR> ;T2 Load a pointer to current directory
1)              SETZ C,                 ;T2 Have not seen any subdirectories
1)                                      ;T2 Now go try to parse out the superior
1)      CDUPLS: ILDB B,A                ;T2 Pick up the current byte
1)              CAIN B,"."              ;T2 Subdirectory indicator??
1)               MOVE C,A               ;T2  Yes!  Save the last location seen!
1)                JUMPN B,CDUPLS        ;T2   Continue looking for superior
1)                                      ;T2 Done scanning, now get the superior
1)              JUMPE C,CDUPTP          ;T2 No dot, so handle a top-level directory
1)              DMOVE A,[EXP 76,0]      ;T2 Load a close-pointy and a NULL
1)              DPB A,C                 ;T2 Overwrite the subdirectory punctuation
1)              IDPB B,C                ;T2 and neatly tie off the string
1)      CDUPOK: MOVE B,[POINT 7,CDUSTR] ;T2 Load a pointer to our new string
1)              JRST CDUPEP             ;T2 Join CWD at CDUP entry point
1)                                      ;T2 Top level! Try going into ROOT-DIRECTORY
1)      CDUPTP: MOVX A,.FHSLF           ;T2 But FIRST!  Is this a good idea?
1)              RPCAP%                  ;T2 Base the policy on our capabilities
1)               ERJMP XCWD1            ;T2  Just pretend a bad directory
1)              TXNN B,<SC%WHL>         ;T2 Okay, are we a systems dude?
1)               JRST CDUPOK            ;T2  No, a regular user has no business there
1)                                      ;T2 FTP into ROOT-DIRECTORY could get scary!
1)              DMOVE A,[EXP <POINT 7,T20RDN>,<POINT 7,CDUSTR>] ;T2
1)              MOVX C,<T20RDL>         ;T2 Load up the parameters for the
1)      CDUPTC: ILDB D,A                ;T2 byte hussle: load the byte, write
1)              IDPB D,B                ;T2 the byte; we all know the drill
1)               SOJG C,CDUPTC          ;T2  Wiz around for more bytes, weeee!!
1)              JRST CDUPOK             ;T2 Hand the mess to CWD and hope...
1)      T20RDL==:^D17                   ;T2 Tops-20 Root directory length and name
1)      T20RDN: ASCIZ /<ROOT-DIRECTORY>/
1)              0                       ;T2 Just because I cain't count...
1)              SUBTTL  Post-Login Command Execution Routines - SIZE
1)      ;T3 The SIZE command is not currently part of any official RFC that I
1)      ;T3 was able to determine.  It is used by the ange-ftp package in
1)      ;T3 order to not have to parse directory listing strings from foreign
1)      ;T3 systems.  This apparently makes coding of the package easier, but
1)      ;T3 obviously makes for more network traffic.  This used to be a big
1)      ;T3 deal...
1)      ;T3
1)      ;T3 SIZE returns the size of the file in bytes.  Note that this may
1)      ;T3 or MAY NOT be correctly interpreted by the client.  As most
1)      ;T3 'modern' FTP clients can no longer imagine anything but eight bit
1)      ;T3 bytes, it is doubtful that they would understand that a 200 byte
1)      ;T3 file with 7 bit bytes is smaller than a 41 byte file with 36 bit
1)      ;T3 (i.e., full word) bytes.  So it goes...
1)      ;T3
1)      ;T3 Responses are modeled from responses from actual implementations
1)      ;T3 To do: are these error numeric codes really correct and appropriate?
1)      JFNT$L==<<<EJFNTX+1-JFNTXS>*5>-2> ;T3 Maximum characters minus two NULLs
1)      ZSIZE:  MOVX A,<POINT 7,JFNTXS> ;T3 Copy to JFN text area
1)              MOVE B,SBP              ;T3 Source byte pointer to argument
1)              MOVX D,JFNT$L           ;T3 Don't allow buffer overflows!
1)                                      ;T3 We do NOT use SOUT% to transfer data!
1)      ZSIZCB: ILDB C,B                ;T3 Pick up an argument byte from client
1)              IDPB C,A                ;T3 Deposit into file string we're building
1)               JUMPE C,ZSIZCD         ;T3  Did we hit the end of the string?
1)                SOJN D,ZSIZCB         ;T3   No, go copy bytes until buffer is full
1)                                      ;T3 Note that we try to carefully check for
1)      ZSIZCD: JUMPE C,ZSIZGF          ;T3 a bogus file name.  So, terminated string?
1)              SETZ C,                 ;T3 No, so tack on a final NULL
1)              IDPB C,A                ;T3 Deposit into file string we're building
1)                                      ;T3 Note, this depends on REAL GTJFN!
1)      ZSIZGF: CALL JBKINI             ;T3 Set up for long form file size request
1)                                      ;T3 Returns A/addr JBLOCK, B/SBP
1)              MOVX C,<GJ%OLD+.GJDEF>  ;T3 Want newest generation of EXISTING file
1)              MOVEM C,.GJGEN(A)       ;T3 store in long form request block
1)              %GTJFN                  ;T3 Note TCPSIM potential %GTJFN name clash!
1)                ERJMP [ JSP B,DELXX   ;T3 On failure, assume file doesn't exist
1)                        ASCIZS (450,550,< SIZE: No such>)] ;T3 Bum code from ZDELE
1)              HRRZM A,LCLJFN          ;T3 Got a JFN: store it, stripping flags
1)              LDB C,B                 ;T3 Oh, did we finish parsing the file??
1)              JUMPN C,[ JSP B,DELXX   ;T3  No, suspicious left over characters...
1)                        ASCIZS (550,501,< SIZE: Ambiguous file name syntax in>)]
1)                                      ;T3 Check for a bogus device, ie., PLPT
1)              DVCHR%                  ;T3 Now what kind of device is this?
1)                ERJMP [ JSP B,DELXX   ;T3 On failure, assume device bogosity
1)                        ASCIZS (450,550,< SIZE: Invalid device for>)]
1)              LOAD D,DV$TYP           ;T3 Get device type field
1)              CAXN D,.DVNUL           ;T3 Special case NULL
1)               JRST [ SETZ T1,        ;T3  You always get EOF, so ZERO bytes
1)                      JRST ZSIZOK ]   ;T3  Ship response to user
1)              CAXE D,.DVDTA           ;T3 The Great Pumpkin had DECtape...
1)               CAXN D,.DVDSK          ;T3  Otherwise is this a disk?
1)                JRST ZSIZGZ           ;T3   Device has lengths, go get the size
1)                 JSP B,DELXX          ;T3    No. Error.  Bum some code from ZDEL
1)                 ASCIZS (506,504,< SIZE: This device does not have named files,>)
1)                                      ;T3 Err, did ANSI tapes have named files?
1)      ZSIZGZ: HRRZ A,LCLJFN           ;T3 Load the JFN, ensuring no flags tag along
1)              MOVX B,<1,,.FBSIZ>      ;T3 Get the byte count, overlook byte size...
1)              MOVEI C,T1              ;T3 It eventually gets to an AC anyway
1)              GTFDB%                  ;T3 Finally try to pull it from the FDB
1)                ERJMP [ JSP B,DELXX   ;T3 Assume GFDBX3, list access required
1)                        ASCIZS (451,550,< SIZE: You do not have access rights to>)]
1)                                      ;T3 At this point, we have something useful
1)      ZSIZOK: SETO A,                 ;T3 But first, punt the JFN since
1)              EXCH A,LCLJFN           ;T3 it is no longer necessary
1)              RLJFN%                  ;T3 No need to close since never opened
1)               ERJMP [ JSP B,DELXX    ;T3 Report a failure although we have data..
1)                       ASCIZS (450,550,< SIZE: Unable to release JFN for>)] ;T3
1)                                      ;T3 Finally try to report the size
1)      ZSIZRP: CALL BEGREP             ;T3 Begin a new reply
1)              ASCIZ /213 /            ;T3 Use EXACT syntax as displayed by Unix
1)              SKIPN B,T1              ;T3 Load the byte count
1)               JRST ZSIZ0L            ;T3  Nothing there, bum the NOUT%
1)              MOVX C,<NO%MAG!FLD(^D10,NO%RDX)> ;T3 Unsigned base 10
1)              NOUT%                   ;T3 Try to report the size
1)               ERJMP ZSIZ0L           ;T3  On error, just say that it is zero
1)              MOVEM A,REPLYP          ;T3 Update the global variable
1)              JSP B,RPCRLP            ;T3 Tie off the line with a CRLF
1)              0                       ;T3 and ship to user, no extra data
1)      ZSIZ0L: JSP B,RPCRLP            ;T3 Less CPU than a NOUT%
1)              ASCIZ /0/               ;T3 Since we know the ASCII representation
1)              SUBTTL  Post-Login Command Execution Routines - MDTM
1)      ;T3 The MDTM command is not currently part of any official RFC that I
1)      ;T3 was able to determine.  It is used by the ange-ftp package in
1)      ;T3 order to not have to parse directory listing strings from foreign
1)      ;T3 systems.  This apparently makes coding of the package easier, but
1)      ;T3 obviously makes for more network traffic.  This used to be a big
1)      ;T3 deal...
1)      ;T3
1)      ;T3 MDTM returns the last modification time of the file as an ASCII
1)      ;T3 string of the following form: YYYYMMDDhhmmss which YYYY is a Y2K
1)      ;T3 compatible year, MM is the month ("01" is January), DD is the day
1)      ;T3 in the month ("01" is the first), hh is the 24 hour of the day
1)      ;T3 (starts at "00" and ranges to "23"), mm is the 60 minute portion
1)      ;T3 of the hour (starts at "00" and ranges to "59") and ss is the 60
1)      ;T3 second portion of the minute (starts at "00" and ranges to "59")
1)      ;T3
1)      ;T3 Responses are modeled from responses from actual implementations
1)      ;T3 To do: are these error numeric codes really correct and appropriate?
1)      ZMDTM:  MOVX A,<POINT 7,JFNTXS> ;T3 Copy to JFN text area
1)              MOVE B,SBP              ;T3 Source byte pointer to argument
1)              MOVX D,JFNT$L           ;T3 Don't allow buffer overflows!
1)                                      ;T3 We do NOT use SOUT% to transfer data!
1)      ZMDTCB: ILDB C,B                ;T3 Pick up an argument byte from client
1)              IDPB C,A                ;T3 Deposit into file string we're building
1)               JUMPE C,ZMDTCD         ;T3  Did we hit the end of the string?
1)                SOJN D,ZMDTCB         ;T3   No, go copy bytes until buffer is full
1)                                      ;T3 Note that we try to carefully check for
1)      ZMDTCD: JUMPE C,ZMDTGF          ;T3 a bogus file name.  So, terminated string?
1)              SETZ C,                 ;T3 No, so tack on a final NULL
1)              IDPB C,A                ;T3 Deposit into file string we're building
1)                                      ;T3 Note, this depends on REAL GTJFN!
1)      ZMDTGF: CALL JBKINI             ;T3 Set up for long form file time request
1)                                      ;T3 Returns A/addr JBLOCK, B/SBP
1)              MOVX C,<GJ%OLD+.GJDEF>  ;T3 Want newest generation of EXISTING file
1)              MOVEM C,.GJGEN(A)       ;T3 store in long form request block
1)              %GTJFN                  ;T3 Note TCPSIM potential %GTJFN name clash!
1)                ERJMP [ JSP B,DELXX   ;T3 On failure, assume file doesn't exist
1)                        ASCIZS (450,550,< MDTM: No such>)] ;T3 Bum code from ZDELE
1)              HRRZM A,LCLJFN          ;T3 Got a JFN: store it, stripping flags
1)              LDB C,B                 ;T3 Oh, did we finish parsing the file??
1)              JUMPN C,[ JSP B,DELXX   ;T3  No, suspicious left over characters...
1)                        ASCIZS (550,501,< MDTM: Ambiguous file name syntax in>)]
1)                                      ;T3 Check for a bogus device, ie., PLPT
1)              DVCHR%                  ;T3 Now what kind of device is this?
1)                ERJMP [ JSP B,DELXX   ;T3 On failure, assume device bogosity
1)                        ASCIZS (450,550,< MDTM: Invalid device for>)]
1)              LOAD D,DV$TYP           ;T3 Get device type field
1)              CAXN D,.DVNUL           ;T3 Special case NULL
1)               JRST [ SETO T1,        ;T3  Safest to say it's right now
1)                      JRST ZMDTOK ]   ;T3  Ship response to user
1)              CAXE D,.DVDTA           ;T3 The Great Pumpkin had DECtape...
1)               CAXN D,.DVDSK          ;T3  Otherwise is this a disk?
1)                JRST ZMDTGZ           ;T3   Device has lengths, go get the time
1)                 JSP B,DELXX          ;T3    No. Error.  Bum some code from ZDEL
1)                 ASCIZS (506,504,< MDTM: This device does not have named files,>)
1)                                      ;T3 Err, did ANSI tapes have named files?
1)      ZMDTGZ: HRRZ A,LCLJFN           ;T3 Load the JFN, ensuring no flags tag along
1)              MOVX B,<1,,.FBWRT>      ;T3 Get the last write time
1)              MOVEI C,T1              ;T3 It eventually gets to an AC anyway
1)              GTFDB%                  ;T3 Finally try to pull it from the FDB
1)                ERJMP [ JSP B,DELXX   ;T3 Assume GFDBX3, list access required
1)                        ASCIZS (451,550,< MDTM: You do not have access rights to>)]
1)                                      ;T3 At this point, we have something useful
1)      ZMDTOK: SETO A,                 ;T3 But first, punt the JFN since
1)              EXCH A,LCLJFN           ;T3 it is no longer necessary
1)              RLJFN%                  ;T3 No need to close since never opened
1)               ERJMP [ JSP B,DELXX    ;T3 Report a failure although we have data..
1)                       ASCIZS (450,550,< MDTM: Unable to release JFN for>)] ;T3
1)                                      ;T3 Here to convert the time
1)      ZMDTCT: SKIPN B,T1              ;T3 Load the time we got from the FDB
1)               SETO B,                ;T3 Zero will BREAK foolish Unixes
1)              MOVX D,<IC%DSA!IC%UTZ!FLD(0,IC%TMZ)> ;T3 GMT, no daylight savings
1)              ODCNV%                  ;T3 Hope for the best and convert...
1)                ERJMP [ JSP B,DELXX   ;T3 DATEX6, TIMEX1, ZONEX1
1)                        ASCIZS (451,550,< MDTM: unable to convert time>)]
1)              DMOVE T1,B              ;T3 Save <year,,month>,<month day,,weekday>
1)              HRR T2,D                ;T3 Overwrite weekday with time since midnight
1)                                      ;T3 Finally try to report the size
1)      ZMDTRP: CALL BEGREP             ;T3 Begin a new reply
1)              ASCIZ /213 /            ;T3 Use EXACT syntax as displayed by Unix
1)              HLRZ B,T1               ;T3 Load the year
1)              MOVX C,<NO%MAG!NO%LFL!NO%ZRO!FLD(^D4,NO%COL)!FLD(^D10,NO%RDX)>
1)              NOUT%                   ;T3 Try to report the year
1)               ERJMP ZMDTFE           ;T3  On error, complain to client
1)              HRRZ B,T1               ;T3 Load the month
1)              ADDI B,^D1              ;T3 Months start from 1 not zero!
1)              MOVX C,<NO%MAG!NO%LFL!NO%ZRO!FLD(^D2,NO%COL)!FLD(^D10,NO%RDX)>
1)              NOUT%                   ;T3 Try to report the month
1)               ERJMP ZMDTFE           ;T3  On error, complain to client
1)              HLRZ B,T2               ;T3 Load the day of the month
1)              ADDI B,^D1              ;T3 Day of month starts from 1 not zero!
1)              NOUT%                   ;T3 Try to report the day of the month
1)               ERJMP ZMDTFE           ;T3  On error, complain to client
1)              HRRZ T1,T2              ;T3 Load seconds since midnight
1)              IDIVI T1,<^D60*^D60>    ;T3 Strip off the hours
1)              MOVE B,T1               ;T3 And load it into AC2
1)              NOUT%                   ;T3 Try to report the hour
1)               ERJMP ZMDTFE           ;T3  On error, complain to client
1)              MOVE T1,T2              ;T3 Load up remainder of minutes and seconds
1)              IDIVI T1,<^D60>         ;T3 Strip off the minutes
1)              MOVE B,T1               ;T3 And load it into AC2
1)              NOUT%                   ;T3 Try to report the minutes
1)               ERJMP ZMDTFE           ;T3  On error, complain to client
1)              MOVE B,T2               ;T3 Load the seconds
1)              NOUT%                   ;T3 Try to report the seconds
1)               ERJMP ZMDTFE           ;T3  On error, complain to client
1)              MOVEM A,REPLYP          ;T3 Update the global variable
1)              JSP B,RPCRLP            ;T3 Tie off the line with a CRLF
1)              0                       ;T3 and ship to user, no extra data
1)      ZMDTFE: JSP B,DELXX             ;T3 Here when one of our NOUT%s fails
1)              ASCIZS (451,550,< MDTM: unable to format time>) ;T3
1)              SUBTTL  Post-Login Command Execution Routines - ALLOcate
****
2)66            SUBTTL  Post-Login Command Execution Routines - ALLOcate
**************
1)69            MOVE C,B                ;[T17] Save a copy of the pointer
1)              ILDB A,C                ;[T17] Pick up the first character
1)              JUMPN A,CDUPEP          ;[T17] Process the pathname
1)              SKIPN USERNM            ;[T17] Do we have a user number?
1)               JRST XCWD1             ;[T17]  No, DIRST% will fail
1)              MOVE A,B                ;[T17] Over write blank path with ours
1)              HRROI B,[ASCIZ /PS:</]  ;[T17] Start of string
1)              SETZ C,                 ;[T17] Stop on a NUL
1)              SOUT%                   ;[T17] Transfer it the slow way, sigh ..
1)               ERJMP XCWD1            ;[T17]  ??
1)              MOVE B,USERNM           ;[T17] Load our (checked) user number
1)              DIRST%                  ;[T17] Write out the user name
1)               ERJMP XCWD1            ;[T17]  ???
1)              MOVEI B,">"             ;[T17] Right pointy gronks MOVX!
1)              IDPB B,A                ;[T17] Finish directory punctuation
1)              SETZ B,                 ;[T17] Create NUL
1)              IDPB B,A                ;[T17] Terminate the string
1)              MOVE B,SBP              ;[T17] Restore pointer to argument
1)      CDUPEP: REMARK 'CDUP' 'E'ntry 'P'oint ;;T2
1)              CALL DIRCHK             ; See if valid directory name
****
2)68            CALL DIRCHK             ; See if valid directory name
**************
1)140   CDUSTR: BLOCK 20           ;T2  ;s Space to buld up a superior name
1)      USERST: BLOCK 20                ;s Name string of directory from CWD
****
2)139   USERST: BLOCK 20                ;s Name string of directory from CWD
**************
24-May-2004 03:43:32-PDT,4578;000000000000
Return-Path: <[email protected]>
Received: from grebe.mail.pas.earthlink.net ([207.217.120.46]) by lingling.panda.com with TCP/SMTP; Mon, 24 May 2004 03:36:24 -0700 (PDT)
Received: from cpe-24-221-177-162.ca.sprintbbd.net ([24.221.177.162] helo=reststop.com)
       by grebe.mail.pas.earthlink.net with esmtp (Exim 3.33 #1)
       id 1BSCoi-0005Z5-00; Mon, 24 May 2004 03:36:24 -0700
Date: Mon, 24 May 2004 03:36:21 -0700
Subject: Re: Fun with FTP
Content-Type: text/plain; charset=US-ASCII; format=flowed
Mime-Version: 1.0 (Apple Message framework v553)
Cc: [email protected],
Tops-20 Wizards <[email protected]>
To: Thomas DeBellis <[email protected]>
From: Carl Baltrunas <[email protected]>
In-Reply-To: <[email protected]>
Message-Id: <[email protected]>
Content-Transfer-Encoding: quoted-printable
X-Mailer: Apple Mail (2.553)

Hi Tom,

Nice to see someone taking an interest in FTPSER.  It has been so long
since I looked at this issue ('97?), but I noticed that all of the GUI=20=

tools that
permit uploading and downloading to web sites (website construction
tools, such as GoLive, and even newer PC or Mac ftp clients) via ftp
were unable to connect and display the login directory, let alone=20
connect
to the appropriate subdirectory on the TOPS-20 server.  (I had, and
still have when it's up, a web server running under XKL's system)

I ended up making all the web pages by hand, or building a mirror on
a unix server and ftp'ing all the files from there.  I also haven't=20
tried
any GUI tools under Linux yet, but I'd suppose they may have the same
issues.

If these added commands were all that was missing, then it will be
nice to try it out again sometime soon.  Keep us posted on any other
changes you make.  I'll see if I can dig up the email I sent back then
to an FTP client programmer specifying what failed and asking if
they would make the modifications to connect properly to FTPSER.

Does anyone know if the XKL distribution works under KLH's emulator?
   ... or whether anyone has bothered since Mark has provided the
       panda distribution, and XKL may not be providing copies of their
       modifications.
I have yet to bother setting up a system with Ken's emulator since I
just happen to have a TOAD-1 lying dormant in my garage.  I'll have
to double check whether your diff/filcom listing matches the FTPSER
on the XKL.

Alas, that's another project for later in the summer or fall.

-Carl


On Sunday, May 23, 2004, at 05:24 PM, Thomas DeBellis wrote:
> Actually, the changes to the Tops-20 FTP server were so trivial that I
> just did them.  Here are the DIFs for an FTPSER that implements SYST,
> PWD, CDUP, SIZE, MDTM and CWD with a zero length pathname getting to
> the login directory.
>
> It will be noticed that in the CDUP command that I actually grovel the
> directory string.  This was before I know about stuff like <..> in
> Tops-20.  As I'm not sure whether the 'standard' Tops-20 monitor
> implements this, I left the code the way it is.
> =0C
> File 1)       STAR:FTPSER.MAC[4,24]   created: 2001 23-May-104
> File 2)       PS:FTPSER.MAC[4,52]     created: 1717 03-Dec-85
>
> 1)    ;;[TOMMYT]STAR:<FTP>FTPSER.MAC.64, 11-Jul-2003 12:09:45, Edit by=20=

> SLOGIN
> 1)    ;
> 1)    ;;[T17] On a CWD with a 0 length pathname, go to login directory
> 1)    ;
> 1)    ;;T3   Support for SIZE and MDTM.  Note that these command do =
NOT
> 1)    ;       appear in RFC959 or any other RFC except for 2389, which =
only
> 1)    ;       discusses feature negotiation, not implementation.  This
> 1)    ;       implementation was done by investigating the returns fr =
m
> 1)    ;       various Unix and Windows server implementations along =
with
> 1)    ;       expected values for clients such as the ange-ftp package
> 1)    ;
> 1)    ;;T2    Put in some commands to enable the Tops-20 FTP server to=20=

> provide
> 1)    ;       service to some newer graphical and character based =
semi-
> 1)    ;       automatic FTP clients (i.e., Microsoft Internet Explorer =
and
> 1)    ;       gnuEmacs) which need some more recent commands to =
function
> 1)    ;       properly.
> 1)    ;
> 1)    ;       'PWD'   is an informational command that prints the =
currently
> 1)    ;               connected or 'working' directory.
> 1)    ;       'XPWD'  is simply a synonym for 'PWD', per RFC 1123.
> 1)    ;       'SYST'  is an informational command that prints the =
current
> 1)    ;               system type and some other relevant information.
> 1)    ;       'CDUP'  connects to this directory's superior.
> 1)    ;
> 1)    ;<SUBSYS.CMU>FTPSRT.MAC.40, 18-Nov-85 03:09:52, Edit by VAF

24-May-2004 08:34:23-PDT,1167;000000000000
Mail-From: MRC created at 24-May-2004 08:27:16
Date: Mon, 24 May 2004 08:27:16 -0700 (PDT)
From: Mark Crispin <[email protected]>
Subject: Re: Fun with FTP
To: [email protected]
In-Reply-To: <[email protected]>
Pithy-Thought: TOPS-20 was a great improvement over its successors
Message-ID: <[email protected]>

> Does anyone know if the XKL distribution works under KLH's emulator?
> > ... or whether anyone has bothered since Mark has provided the
>       panda distribution, and XKL may not be providing copies of their
>       modifications.

For the most part, klh10 is KL10-compatible; user and most exec
mode software runs without modification.  It has 23-bit virtual
addressing and 30-bit physical addressing.

The XKL-1 has 30-bit addressing, which means (among other things)
that the pager is completely different.  It isn't conceptually
all that hard to go to 27 bits, but those last 3 bits are a pain.
The I/O instructions are also completely different.

So there is no way that an XKL-1 monitor will run under klh10 or
vice-versa.

User code should be compatible.
-------
26-May-2004 21:03:14-PDT,3921;000000000000
Return-Path: <[email protected]>
Received: from mta9.srv.hcvlny.cv.net ([167.206.5.42]) by lingling.panda.com with TCP/SMTP; Wed, 26 May 2004 20:55:03 -0700 (PDT)
Received: from optonline.net (mstr3.srv.hcvlny.cv.net [167.206.5.14])
by mta9.srv.hcvlny.cv.net
(iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar  3 2004))
with ESMTP id <[email protected]>; Wed,
26 May 2004 23:54:54 -0400 (EDT)
Received: from [167.206.5.139] (Forwarded-For: [208.63.226.242])
by mstr3.srv.hcvlny.cv.net (mshttpd); Wed, 26 May 2004 23:53:11 -0400
Date: Wed, 26 May 2004 23:53:11 -0400
From: [email protected]
Subject: Re: Fun with FTP
To: Mark Crispin <[email protected]>
Cc: [email protected]
Message-id: <[email protected]>
MIME-version: 1.0
X-Mailer: iPlanet Messenger Express 5.2 HotFix 1.25 (built Mar  3 2004)
Content-type: text/plain; charset=us-ascii
Content-language: en
Content-transfer-encoding: 7BIT
Content-disposition: inline
X-Accept-Language: en
Priority: normal

> So there is no way that an XKL-1 monitor will run under klh10 or
> vice-versa.

It is obvious that a lot of the device driver code couldn't work
because of the different hardware interfaces being used.  So that
would rule out anything like PAGEM, PHYSIO, PHYH2 and the like.
Probably APRSRV, too.

On the other hand, in theory, other modules that didn't depend on such
low level access should be freely interchangable.  I'd suppose that
you might be able swap things like COMND, DATIME, ENQ and maybe FORK
without too many sparks flying out.  I don't remember if the Toad has
a different way of doing an executive XCT to get user arguments, but
assuming the macros are the same, maybe you could get away with it.

> User code should be compatible.

Yes, but at least for the extremely trivial user mode code that I did,
XKL Tops-20 and KL Tops-20 don't appear to be exactly bug for bug
compatible.  While I had access to the XKL Toad, I knocked together a
little program to learn about pipes.  This was a number of years ago
and I didn't know that Tops-20 had finally gotten that functionality.
When I found out, I was pretty thrilled about learning more about it.

It didn't appear to really be documented anywhere and so Ralph wound
up giving me a copy of the PIPE source code so I could learn how to
program pipes without bugging anybody.  Alas, it closely follows the
Unix paradigm of having pipes be UNIdirectional!  I have always
believed that you should have the option of having a pipe be
BIdirectional.  That can make certain kinds of programming be a LOT
easier.  I had just assumed that Tops-20 would be more winning in that
respect and ...  Disappointment ...

Anyway, I made sure that I understood everything by writing a program
that created some pipes and then sent some IPCF messages to another
program in the same job to use a pair pipe JFNs .  I used IPCF instead
of forking an inferior because it made certain aspects of debugging
easier and I wanted to remember about IPCF, also.  After I finished
polishing it up, the program worked fine.

Once my copy of KLH10 was set up, this was one of the first programs
that I tried and ...  It croaked horribly!  When I had a look at
things, it turned out that the pipes implementation was completely
different.  Once I fixed my code, I found that the IPCF code also
broke completely.  A closer investigation showed that it should have
never worked at all on XKL.  I tried to fix it on PANDA 7.1, but never
got very far.  It was doing lots of odd things that I couldn't make
sense of.

Unfortunately, my access to the XKL was terminated shortly thereafter
(along with many other guest accounts) and I was never able to pursue
the matter any further by doing an A-B executable comparison.  Maybe
if I get some time, I might ask Ralph about it.


26-May-2004 21:43:29-PDT,4015;000000000000
Return-Path: <[email protected]>
Received: from mta6.srv.hcvlny.cv.net ([167.206.5.72]) by lingling.panda.com with TCP/SMTP; Wed, 26 May 2004 21:36:17 -0700 (PDT)
Received: from optonline.net (mstr3.srv.hcvlny.cv.net [167.206.5.14])
by mta6.srv.hcvlny.cv.net
(iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar  3 2004))
with ESMTP id <[email protected]> for
[email protected]; Thu, 27 May 2004 00:36:17 -0400 (EDT)
Received: from [167.206.5.71] (Forwarded-For: [208.63.226.242])
by mstr3.srv.hcvlny.cv.net (mshttpd); Thu, 27 May 2004 00:34:34 -0400
Date: Thu, 27 May 2004 00:34:34 -0400
From: [email protected]
Subject: Re: Fun with FTP
To: [email protected]
Message-id: <[email protected]>
MIME-version: 1.0
X-Mailer: iPlanet Messenger Express 5.2 HotFix 1.25 (built Mar  3 2004)
Content-type: text/plain; charset=us-ascii
Content-language: en
Content-transfer-encoding: 7BIT
Content-disposition: inline
X-Accept-Language: en
Priority: normal

A kind soul pointed out that the code that I wrote for PWD can hang in
certain cases.  In particular, if the server issues a continuation
(which Tops-20 FTPSER doesn't do for PWD), then FTP will wedge.  The
problem is that when the contents of B is "-", FTP gets stuck in an
infinite loop.  In TCPFTP, I wrote:

TCPPWD: FTPM <PWD>              ;[T16] Request server working directory
       CALL TCPRSQ             ;[T16] Read reply being quiet about errors
        NOP                    ;[T16] Error, just fall through
         NOP                   ;[T16] Retry needed, just fall through
        TYPE <%3S%/>           ;[T16]  Else type server response without angles
TCPPW0: CAIN B,"-"              ;[T16] Continued?
        JRST TCPPW0            ;[T16]  Yes, get rest
       RET                     ;[T16] Finally done

Which should be:

TCPPWD: FTPM <PWD>              ;[T16] Request server working directory
TCPPW0: CALL TCPRSQ             ;[T16] Read reply being quiet about errors
        NOP                    ;[T16] Error, just fall through
         NOP                   ;[T16] Retry needed, just fall through
        TYPE <%3S%/>           ;[T16]  Else type server response without angles
       CAIN B,"-"              ;[T16] Continued?
        JRST TCPPW0            ;[T16]  Yes, get rest
       RET                     ;[T16] Finally done

What's changed is that the label TCPPW0 needs to be at TCPPWD+1,
otherwise you just jump to the CAIN again. and again. and again.  How
many knucklehead points do I earn for this?  :-)  Anyway, the problem
also appears to be in MRC's cleaned up version of my code.  It looks
like:

TCPPWD: FTPM <PWD>              ; Request server working directory
       CALL TCPRSQ             ; Read reply being quiet about errors
        NOP                    ; Error
        NOP                    ; Retry needed
       TYPE <%3S%/>            ; Type server response
       DO.
         CAIN B,"-"            ; Continued
          LOOP.
       ENDDO.
       RET

Should be:

TCPPWD: FTPM <PWD>              ; Request server working directory
       DO.
       CALL TCPRSQ             ; Read reply being quiet about errors
        NOP                    ; Error
        NOP                    ; Retry needed
       TYPE <%3S%/>            ; Type server response
         CAIN B,"-"            ; Continued
          LOOP.
       ENDDO.
       RET

Notice that the DO has moved up a few lines.  At least I think this is
right.  I always get all that DO./DID./DONE./DONT./LOOP. stuff wrong.
I'm hopeless enough so that I don't normally use it unless I'm working
with somebody else, in which case I try to conform to their coding
style.  I always have to check the .EXE file to be sure that I got
everything right.  Pitiful ...

Goodness, actual public code review!  Could we have the beginnings of
a user community here again??


26-May-2004 23:07:02-PDT,813;000000000000
Mail-From: MRC created at 26-May-2004 22:59:47
Date: Wed, 26 May 2004 22:59:47 -0700 (PDT)
From: Mark Crispin <[email protected]>
Subject: Re: Fun with FTP
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]>

The pipe code in Panda TOPS-20 was the Stanford code from March 1985.  I
am not surprised that XKL did more work on it.

Yes, I was rather disappointed myself that Kirk made them unidirectional,
but apparently all he cared about was duplicating the UNIX functionality
as opposed to surpassing it.  I never did much with TOPS-20 pipes myself
as a result of that design decision.

-- Mark --
-------
27-May-2004 18:55:06-PDT,5434;000000000000
Return-Path: <[email protected]>
Received: from mta8.srv.hcvlny.cv.net ([167.206.5.75]) by lingling.panda.com with TCP/SMTP; Thu, 27 May 2004 18:47:20 -0700 (PDT)
Received: from optonline.net (ool-182f33c4.dyn.optonline.net [24.47.51.196])
by mta8.srv.hcvlny.cv.net
(iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar  3 2004))
with ESMTP id <[email protected]> for
[email protected]; Thu, 27 May 2004 21:47:14 -0400 (EDT)
Date: Thu, 27 May 2004 21:46:55 -0400
From: Thomas DeBellis <[email protected]>
Subject: Re: Fun with FTP
To: Phil Budne <[email protected]>
Cc: Tops-20 Wizards <[email protected]>
Message-id: <[email protected]>
MIME-version: 1.0
X-Mailer: Mozilla 4.5 [en]C-CCK-MCD BA45DSL  (WinNT; U)
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7BIT
X-Accept-Language: en
References: <[email protected]>

> > 1)              HRROI B,[ASCIZ /PS:</]  ;[T17] Start of string
>
> I seem to recall changes at some point so that the 'primary'
> disk didn't need to be called PS:
>
> The proper way to create your home dir may have been to put some
> constant into the LH with your usernumber in the RH and do some system
> call (DIRST%?).... I'm sure MRC will know...
>
> Probably doesn't matter unless you're running CFS (CI clustering)...

Phil,

That was an interesting question.  I had a look at things.  Using PS:
as the login directory structure prefix IS the correct sequence.  The
monitor defines PS: on boot up to point to the login structure, which
can be different than the boot structure, BS:.  This is true even on
non-CFS systems.

I remember that you could transmogify a login user number into a
directory number (on PS:) by dinking bit three.  the number.  I don't
know if this is valid for a non-PS: login structure nor where or if
bit three is defined.  I don't even know why I remember this!

Anyway, connecting the user to their directory on the login structure
is always possible, otherwise I don't think that they would have been
able to log in.  It appears that you can't dismount or otherwise
remove a structure while it is being used as a login structure.
Therefore:

 1) The default for PWD <NUL> for user FOO is always PS:<FOO>
 2) Other routines in FTPSER, such as DIRCHK which is PS: as the
    directory prefix appear to do the right thing.

                                --T

The rest of this letter contains some research that I did to answer
the questions on the boot and login structure, which may be of
interest.

Columbia did run CFS, but I believe we only ran 6.0.  I don't think we
ever made it to 7.anything.  I also don't remember a time when we
weren't a beta site and I remember that putting up a new monitor was
an extremely big deal for us, due to the extensive amount of local
customization that we had (now all lost, it seems).

However, when DEC approached us about the 7.0 beta, we declined
because we had almost all of our systems programmer staff devoted to
developing replacement applications in C for our first Unix system.
The hardware was a VAX 8600 which quickly became an 8700 which was
then replaced by a Sun 4.  I haven't heard of there being any more
DEC, err, Compaq hardware at the university, except for some PC's.

6.0 did NOT support a CFS login.  We had a rather interesting ID
system that (nearly) simultaneously created ID's on all three of our
student machines (the fourth was for staff and paying customers).
Having seperate login structures was a pain because users would write
their files into PS, and when a particular machine went down ...  I
think that we may have hacked LOGIN% or CRJOB% to do an automatic
connect to the CFS structure when a student signed on.

I don't know a lot about 7.0 series per say, but since I was poking
around at the CI stuff, I thought that I was 'sort of' near the right
place and had a look.  I wasn't even near the right place, but anyway,
here is what I found that happens, which is probably NOT in correct
order:

Some time after boot , a number of routines in DSKALC are called by
MEXEC to decide what the login structure is.  SETSPD eventually runs
and has parsed for ENABLE/DISABLE LOGIN-STRUCTURE to decide whether to
allow non-BS (!) logins and sets the appropriate bit with TMON.

FNDLGS in DSKALC is called to find the login structure, which need not
be the boot structure.  It looks like a seperate login structure is
possible even in a non-CI system as the decision is not CFS dependent.
CHECKD is used to enable logins on a structure--I don't think it cares
where the structure is.

FNDLGS then uses a CRLNM% to define PS:.  (I wonder what happens if
you do a ^Edefine and change PS: after timesharing is running?  Maybe
that could get ugly ...)  Probably having more than one login
structure means that the first one found gets picked.  Or gronkage.
Multiple disk packs per different login structures might be
interesting.  Or not allowed.  Or gronkage.

In MEXEC, in the Job 0 initialization, after the swappable monitor is
loaded, SLNINI is called.  SLNINI has a table of defined system
logical names.  The SYNMTB table is in STG.  When six spaces precede
the colon of a logical, SLNINI inserts the name of the Primary
;Structure into that location.  That is how BS: gets defined to point
to TOPS20:.

27-May-2004 23:09:30-PDT,1796;000000000000
Return-Path: <[email protected]>
Received: from Ikkoku-Kan.Panda.COM (panda.com [206.124.149.114]) by lingling.panda.com with TCP/SMTP; Thu, 27 May 2004 23:00:41 -0700 (PDT)
Received: from Ikkoku-Kan.Panda.COM (Ikkoku-Kan.Panda.COM [192.107.14.50]) by Ikkoku-Kan.Panda.COM id XAA26700; Thu, 27 May 2004 23:00:38 -0700 (PDT)
Date: Thu, 27 May 2004 22:48:13 -0700 (PDT)
From: Mark Crispin <[email protected]>
Sender: Mark Crispin <[email protected]>
Subject: Re: Fun with FTP
To: Thomas DeBellis <[email protected]>
cc: Tops-20 Wizards <[email protected]>
In-Reply-To: <[email protected]>
Message-ID: <[email protected]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII

On Thu, 27 May 2004 21:46:55 -0400, Thomas DeBellis wrote:
> > The proper way to create your home dir may have been to put some
> > constant into the LH with your usernumber in the RH and do some system
> > call (DIRST%?)....

The right way to get the login directory string, given a user number is:
       ; enter with user number in AC2
       SETZB 1,3
       RCDIR%
        JSHLT
       MOVE 2,3                ; RCDIR% returns directory number in AC3
       HRROI 1,DIRBUF
       DIRST%
        JSHLT

> Using PS:
> as the login directory structure prefix IS the correct sequence.  The
> monitor defines PS: on boot up to point to the login structure, which
> can be different than the boot structure, BS:.  This is true even on
> non-CFS systems.

Nevertheless, modern software is *not* supposed to have PS: wired in.  You're
supposed to use RCDIR%.

> I remember that you could transmogify a login user number into a
> directory number (on PS:) by dinking bit three.

Ugh.  Please don't do this.  That's even more fragile than wiring-in PS:...

-- Mark --

29-May-2004 13:19:47-PDT,4260;000000000000
Return-Path: <[email protected]>
Received: from mta10.srv.hcvlny.cv.net ([167.206.5.85]) by lingling.panda.com with TCP/SMTP; Sat, 29 May 2004 13:06:38 -0700 (PDT)
Received: from optonline.net (mstr3.srv.hcvlny.cv.net [167.206.5.14])
by mta10.srv.hcvlny.cv.net
(iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar  3 2004))
with ESMTP id <[email protected]>; Sat,
29 May 2004 16:06:27 -0400 (EDT)
Received: from [167.206.5.139] (Forwarded-For: [209.139.22.66])
by mstr3.srv.hcvlny.cv.net (mshttpd); Sat, 29 May 2004 16:04:49 -0400
Date: Sat, 29 May 2004 16:04:49 -0400
From: [email protected]
Subject: Re: Fun with FTP
To: Mark Crispin <[email protected]>
Cc: Tops-20 Wizards <[email protected]>
Message-id: <[email protected]>
MIME-version: 1.0
X-Mailer: iPlanet Messenger Express 5.2 HotFix 1.25 (built Mar  3 2004)
Content-type: text/plain; charset=us-ascii
Content-language: en
Content-transfer-encoding: 7BIT
Content-disposition: inline
X-Accept-Language: en
Priority: normal

> Nevertheless, modern software is *not* supposed to have PS: wired
> in.  You're supposed to use RCDIR%.

Did you have any more details on that?  Do you mean structure labels
or (logical) device names?  I ask because my impression was that it
really looks like PS: is supposed to exist in one form or another.  If
I can't depend on PS: being there, then I'm probably going have to
rewrite some code in FTPSER: ZCWD, DIRCHK and anything that is using
T20.DV (I don't think anything is at this point).


I could see how software that depended on the structure label of 'PS'
might get into trouble.  I guess problems could happen in at least one
of two ways.  The first case would be that a system need not have any
pack labeled 'PS' mounted at all.  There, software that went looking
for a structure labeled 'PS' would be in for a very rude surprise.
The second case would be when a structure labeled 'PS' wasn't really
the system structure.  Programs could then wind up thinking they were
in the right place and ...  Things could get ugly.

I guess MOUNTR, DUMPER and CHECKD would be the main candidates for
programs that actually directly look at structure labels.

My feeling is that systems with no structures labeled 'PS' at all
would probably have become increasingly common in the 7.1 CFS world.
This would have been a blessing for those installations with more than
one 20.  At Columbia, already with 6.1 CFS, having multiple system
structures labeled 'PS' running around and dealing with the aliases
was causing us some major headaches.

All our system structures disks were externally labeled as PSA, PSB,
PSC and PSD according to system, but they all showed up as PS when
mounted, which caused some of our operations people no end of
confusion (no BOFH jokes, please).  I believe that I rewrote the
parsing logic in MOUNTR at one point to more cleanly handle errors in
MOUNTR.CMD because we were doing so much of that stuff.

Had we proceeded with 7.1, as the MOUNTR maven and general Galaxy
geek, I would undoubtedly have heavily lobbbied for internal labels on
system (PS) structures to correspond with external labels.  It
probably would have also saved us some futzing with the backups,
cometo think of it.


But I don't see how doing changing the labels would have broken any
software.  It looks like the monitor is going to guarantee that the
system logical name PS: is going be defined, one way or the other.
SLNINI is going to be invoked by JBI0 at boot time.  It will create a
number of system logical names, among them BS: and PS:, both of which
are going to point to the boot structure.

Afterwards, RUNDD is going to invoke SETSPD (shortly after RUNDEQ)
which will tell the the monitor whether to use non-BS structure
logins.  Long after SETSPD has done its thing and after any CHECKD
futzing, FLDLGS is going to get invoked which will redefine PS: to
point to the login structure.

It looks like the only bad thing that could happen would be if
somebody went and either redefined the system logical name PS: or,
worse, clobbered it entirely.  I guess you'd want to have the ACJ
prevent that.


13-Jun-2004 03:24:12-PDT,10233;000000000000
Return-Path: <[email protected]>
Received: from mta3.srv.hcvlny.cv.net ([167.206.5.69]) by lingling.panda.com with TCP/SMTP; Sun, 13 Jun 2004 03:13:43 -0700 (PDT)
Received: from optonline.net (ool-182f33c4.dyn.optonline.net [24.47.51.196])
by mta3.srv.hcvlny.cv.net
(iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar  3 2004))
with ESMTP id <[email protected]> for
[email protected]; Sun, 13 Jun 2004 06:13:31 -0400 (EDT)
Date: Sun, 13 Jun 2004 06:13:11 -0400
From: Thomas DeBellis <[email protected]>
Subject: Whither FTPSER?
To: Tops-20 Wizards <[email protected]>
Cc: Carl Baltrunas <[email protected]>
Message-id: <[email protected]>
MIME-version: 1.0
X-Mailer: Mozilla 4.5 [en]C-CCK-MCD BA45DSL  (WinNT; U)
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7BIT
X-Accept-Language: en
References: <[email protected]>

> Keep us posted on any other changes you make.

I'll certainly do this, once I have some more significant progress to
report.  Thus far, it has been slow going for a number of reasons, one
fundamental problem being that a single RFC describing what is
expected of an FTP implementation no longer seems to exist.  RFC959 is
the last complete one, with a number of others describing additional
new features and behavior.  Unfortunately, this doesn't imply that all
FTP clients use these consistently (or at all).  There is ambiguity in
some cases and lack of clarification in others.

Worse, in the case of the FTP command set itself, I was unable to
discover definitions for some of the newer keywords and cooresponding
required actions.  That meant investigating the behavior of existing
client implementations.  For GNU ange-ftp mode, I was able to look at
the source code and deduce what was required by looking at server
responses.  For the case of Windows' Internet Explorer (IE), I had to
spy on the actual command stream with ^E peek and snoop packets with
Ethereal.

> Does anyone know if the XKL distribution works under KLH's emulator?
> or whether anyone has bothered since Mark has provided the PANDA
> distribution, and XKL may not be providing copies of their
> modifications.

While I had access to a Toad, I noticed that its particular FTP server
had a number of commands that the PANDA version did not.  I don't
remember what these were and in any case, I never looked at the XKL
source code (I don't even remember if it was available to me).  But,
the fact that XKL FTPSER did some things that PANDA FTPSER didn't was
one of the original inducements for my starting to tinker with its
implementation.

> If these added commands were all that was missing, then it will be
> nice to try it out again sometime soon.

Thus far, I've been able to cons up some code for a number of trivial
commands that were lacking: SYST, PWD, CDUP, SIZE, MDTM and define a
default flavor for CWD.  The current state of my work is that the
PANDA Tops-20 FTP server now seems to be compatible with most
character mode FTP clients that have Unix ancestry.  It is lacking
FEAT and OPTS (RFC2389).  I've haven't checked to see whether PASV has
been broken or not.

I will probably implement FEAT and OPTS next.  FEAT is trivial: I'd
just respond with 'SIZE' and 'MDTM'.  Once I determine whether and
how to report MLST, I would add that to the feature list.  OPTS may
be trivial as the only defined behavior is UFT8, which the Tops-20
file name space doesn't explicitly support.  At this point, I'd reject
the command and hope that the client would do the right thing.

Currently, the fact that OPTS doesn't exist doesn't seem to break IE
in any obvious way, but I havn't done extensive testing.  I'm guessing
that I might be able to fake a subset of UTF8 at some point in the
future, but I haven't really turned my attention to this, yet.
However, RFC2640 explicitly requires OPTS UFT8, so I should probably
try (or pretend) to do something reasonable.

> I noticed that all of the GUI tools that permit uploading and
> downloading to web sites (website construction tools, such as
> GoLive, and even newer PC or Mac ftp clients) via ftp were unable to
> connect and display the login directory, let alone connect to the
> appropriate subdirectory on the TOPS-20 server.

IE and other graphical clients seem to expect a remote server that is
based on the Unix name space and they use several commands without
ever bothering to negotiate for them.  In particular, IE uses OPTS
without ever bothering to see if it exists by issuing a FEAT.  While
RFC2389 never explicitly forbids this, the behavior seems to defeat
the stated purpose of the RFC to begin with.

IE also uses SITE with a parameter ('HELP').  This is a problem for
two reasons.  First, FTPSER is currently coded to reject ANY parameter
at all for SITE (however the default reponse could be trivially
returned for HELP).  I couldn't say what IE expects from SITE and how
it uses it.  RFC959 doesn't elaborate on SITE much, but it smells
something like FEAT, viz:

   SCO Unix:

   214-The following SITE commands are recognized (* =>'s unimplemented).
   0    UMASK   CHMOD   GROUP   NEWER   INDEX   LANG    CDPATH
   0    IDLE    HELP    GPASS   MINFO   EXEC    ALIAS

   Tops-20:

   214 Use SMNT <structure-name> to use unregulated structures.


However the REAL problem that I'm having is that EVERYTHING seems to
be assuming a Unix-like name space these days.  IE and ange-ftp
specifically send file paths in the form of "/PS:<SLOGIN>/" which
GTJFN% doesn't grok.  To date, no RFC that I've come across specifies
file path interoperability.  RFC959 is pretty explicit about data
interoperability, but explicitly does NOT define a pathname
convention.  The user is expected to know how to retrieve and create
files based on target operating systems.

Were pathsnames considered for the original RFC?  My inclination
is to suspect that they weren't because of the radically differing
natures of how files were specified.  There were a great deal more
differing systems with significant user populations.  I personally
used MVS, CMS, ITS, Unix and TOPS-20, which differed greatly.  So, for
the past few months, I've found that I've been annoyed that the world
seems to expect a Unix default and have resisted trying to come up
with some way to transmorgify a winning Tops-20 file specification
into a Unix flavor.

On the other hand, while nosing around GNU ange-ftp, I noticed there
is the idea of a 'canonical' file specification which is explicitly a
Unix path name.  For each supported foreign operating system, ange-ftp
is responsible for munging the responses into a canonical form that
the rest of GNU Emacs can use.  That is suggestive.  There is also
code in the Tops-20 FTP client to explicitly deal with transfering
files with a Unix system and clipping the generation numbers.  So, I'm
starting to wonder if transmorgification isn't absolutely cretinous.

At least for the very few simple file specifications that I've
imagined, I think that I might be able to come up with some reasonable
'canonical' responses.  In other words, I don't see that turning
PS:<FOO.BAR>BAZ.TXT.1 into /ps/foo/bar/baz.txt and vice versa is
theoretically impossible.  I just don't know if this mapping is
complete in all cases and invertible.  On the other hand, I also don't
clearly see how FTPSER would know when to do this.  It seems that a
MLST feature response in FEAT may be the way to go, but I don't have
enough information on how to report it.  The client would then have
to issue an OPTS.

Another approach is to use a hack to flag transmorgification.  Tops-20
file specifications can not contain unquoted (^V) forward slashes (/).
I could scan each file specification and on the appearance of an
unquoted forward slash, I would put the FTP server into auto-magic
mode.  However, there are some implications to be considered here, the
very first being whether legitimate Tops-20 file specifications might
be rejected.  I also don't see how I could consistently get the server
back out of auto-magic mode (or even whether I should).

I can't make up my mind whether it is winning to have the Tops-20 FTP
server heuristically configure itself to newer FTP clients or whether
it is losing to have FTPSER try to pick up the ball for non-compliant
clients.  I am being pushed in the direction of auto-magic mode for
two reasons.

The first is that it hasn't been much fun for me to puzzle out the
hairy ange-ftp lisp code.  Despite some help from other people, my
lisp was never Olympic, so doing the work is a chore, particularly
since I don't really know the GNU lisp debugger (and don't feel like
learning it).  Now, PDP10 assembler and DDT, that's different!

Secondly, and perhaps more importantly, I don't believe that any major
graphical client is going to change (or get it right) any time soon.
I don't think that the Tops-20 community is currently large enough for
the IE development owners to devote any resources to that aspect of
inter-operability.  Whether or not we have a ton of extremely useful
historcal perspectives just doesn't seem to be relevant.  Quantity of
users is now more important than implementation conformance quality.

Assuming I can get most of these issues resolved, I've begun to wonder
if, at some point, it might not be a bad idea for some of us to create
a consolidated RFC for FTP that would define the current command set,
along with describing the syntax and semantics of canonical file
system name space.  It's required a bit of sleuthing to find and sift
through the various RFC's that elaborate and define required new and
extended FTP features and behavior (or don't!).  Also, I'm worried
about some of the more winning features of FTP, such as support for
paged ('holey') files getting left by the wayside.

Unfortunately, this is only a hobby, so I devote time to it between
consulting tasks.  Sometimes I have a lot of time on my hands (i.e.,
no active work) and sometimes I don't.

                                --T

13-Jun-2004 10:06:37-PDT,2141;000000000000
Return-Path: <[email protected]>
Received: from Ikkoku-Kan.Panda.COM (panda.com [206.124.149.114]) by lingling.panda.com with TCP/SMTP; Sun, 13 Jun 2004 09:57:05 -0700 (PDT)
Received: from Ikkoku-Kan.Panda.COM (Ikkoku-Kan.Panda.COM [192.107.14.50]) by Ikkoku-Kan.Panda.COM id JAA09266; Sun, 13 Jun 2004 09:57:01 -0700 (PDT)
Date: Sun, 13 Jun 2004 09:44:14 -0700 (PDT)
From: Mark Crispin <[email protected]>
Sender: Mark Crispin <[email protected]>
Subject: re: Whither FTPSER?
To: Thomas DeBellis <[email protected]>
cc: Tops-20 Wizards <[email protected]>,
       Carl Baltrunas <[email protected]>
In-Reply-To: <[email protected]>
Message-ID: <[email protected]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII

My comments:

FTP is, in general, a disaster; and in particular TOPS-20 FTP is a major
disaster.  Tom's comments about the sad state of the protocol and of
implementations are completely valid; I could add to his list but it would
just depress us all more more.

As far as I know, XKL considers its software to be its property.  We can ask
them, but it isn't clear to me that FTP is worth squandering any good will or
"favor credits" we may have with XKL.  If Tom is willing to work on FTP, we
may well end up with something that is better than what XKL has, and thus have
something to offer in trade (rather than us being leeches).

The XKL monitor will definitely NOT run under klh10 since the Toad is an
entirely different processor with completely different I/O and pager.
However, user code software such as FTPSER should run without modification in
either environment.

If we start talking about TOPS-20 UTF-8 support in any meaningful way, I very
much want to be part of that loop, as I have definite ideas of how we should
do Unicode.

I think that the idea of path mapping between TOPS-20 and UNIX style paths is
much more important than UTF-8.  The use of unquoted slashes to flag UNIX
style is probably the way to go.  Don't forget that the list commands also
have to do this.

-- Mark --

15-Jun-2004 08:42:41-PDT,3389;000000000000
Return-Path: <[email protected]>
Received: from sesame.cc.columbia.edu ([128.59.59.56]) by lingling.panda.com with TCP/SMTP; Tue, 15 Jun 2004 08:32:40 -0700 (PDT)
Received: from sesame.cc.columbia.edu (localhost [127.0.0.1])
       by sesame.cc.columbia.edu (8.12.11/8.12.11) with ESMTP id i5FFWVpb007903;
       Tue, 15 Jun 2004 11:32:31 -0400 (EDT)
Received: (from fdc@localhost)
       by sesame.cc.columbia.edu (8.12.11/8.12.8/Submit) id i5FFWV9g007902;
       Tue, 15 Jun 2004 11:32:31 -0400 (EDT)
Date: Tue, 15 Jun 2004 11:32:31 EDT
From: Frank da Cruz <[email protected]>
To: Thomas DeBellis <[email protected]>
Cc: Tops-20 Wizards <[email protected]>,
       Carl Baltrunas <[email protected]>
Subject: Re: Whither FTPSER?
In-Reply-To: <[email protected]>
Message-ID: <CMM.0.91.0.1087313551.fdc@sesame>

> Worse, in the case of the FTP command set itself, I was unable to
> discover definitions for some of the newer keywords and cooresponding
> required actions.  That meant investigating the behavior of existing
> client implementations.
>
I wrote an FTP implementation for Kermit recently:

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

It includes some of the new FTP commands and features:

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

some of which (as you'll see if you read the above) are quite poorly
thought out, but the FTP WG is not about to change them.  It seems the
emphasis now is on supporting GUI drag-and-drop FTP clients, rather than
command-driven automatable ones.

Experimentation shows that sending commands like FEAT and OPTS to servers
that don't understand them sometimes causes trouble, so additional client
commands are needed to disable new protocol commands.

> However the REAL problem that I'm having is that EVERYTHING seems to
> be assuming a Unix-like name space these days.
>
That's actually a GOOD idea.  We have now reached a stage where
Unixlike paths are an implicit, and in some cases explicit, standard
format on the wire, thus eliminating the n x n problem.  Each client
and server should be prepared to convert between its own pathname format
and the common Unix one.

I've done the same thing in Kermit protocol across Unix, VMS, Windows,
AOS/VS, VOS, and some other OS's and the mapping is mostly quite natural.
Obviously there are wrinkles involving structure or disk names, but in
a perfect world, a standard mapping would be worked out for each file system.

> IE and ange-ftp
> specifically send file paths in the form of "/PS:<SLOGIN>/" which
> GTJFN% doesn't grok.  To date, no RFC that I've come across specifies
> file path interoperability.  RFC959 is pretty explicit about data
> interoperability, but explicitly does NOT define a pathname
> convention.
>
One of the newer IDs specifies this; it's called the Trivial Virtual
File System (TVFS).  But I don't think its use is negotiated -- you just
use it and hope for the best.

 http://www.ietf.org/internet-drafts/draft-ietf-ftpext-mlst-16.txt

(there might be a newer version...)

The FTP WG is not terribly interested in straightening out this mess.
MLSD *finally* gives a reasonable way of dealing with file agglomerations,
but has some fatal flaws.  You can see some correspondence I had with them
in Sep-Oct 2002 over this in their archive:

 http://w3.hethmon.com/ftpext/

- Frank
15-Jun-2004 09:16:20-PDT,10732;000000000000
Return-Path: <[email protected]>
Received: from mta4.srv.hcvlny.cv.net ([167.206.5.70]) by lingling.panda.com with TCP/SMTP; Tue, 15 Jun 2004 09:07:23 -0700 (PDT)
Received: from optonline.net (mstr3.srv.hcvlny.cv.net [167.206.5.14])
by mta4.srv.hcvlny.cv.net
(iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar  3 2004))
with ESMTP id <[email protected]> for
[email protected]; Tue, 15 Jun 2004 12:07:25 -0400 (EDT)
Received: from [167.206.5.76] (Forwarded-For: [24.47.51.196])
by mstr3.srv.hcvlny.cv.net (mshttpd); Tue, 15 Jun 2004 12:07:17 -0400
Date: Tue, 15 Jun 2004 12:07:17 -0400
From: [email protected]
Subject: Re: Whither FTPSER?
To: Frank da Cruz <[email protected]>
Cc: Tops-20 Wizards <[email protected]>,
Carl Baltrunas <[email protected]>
Message-id: <[email protected]>
MIME-version: 1.0
X-Mailer: iPlanet Messenger Express 5.2 HotFix 1.25 (built Mar  3 2004)
Content-type: text/plain; charset=us-ascii
Content-language: en
Content-transfer-encoding: 7BIT
Content-disposition: inline
X-Accept-Language: en
Priority: normal

Frank,

Thanks for the input.  I'll try to have a look at all that stuff a
little later.  Yes, the FTP WG isn't ... Well, let's not get into
that ...  Maybe at some point a number of us might get
together and generate more noise.  It might help.  Or not ...

For the moment, I think that hacking FTP is interesting.  Having
ange-ftp and Internet Explorer NOT work is growing more annoying.  I
would love to do (and believe that I can do) everything specified
below, but I can't say much about any sort of schedule.

As I understand it, the FTP protocol itself is suffering from a number
of problems.  This is what I believe them to be, in no particular
order:

0) Modern implementations are largely an undocumented superset of
   RFC959.  Chasing down all the keywords, their syntax and semantic
   actions was not what I expected.  I thought that there would be
   one SINGLE RFC that superseded RFC959.  That was decidedly NOT
   the case.

1) Many implementations do not conform to published specifications,
   FEAT and OPTS being two notable examples.

2) NVT-ASCII appears be no longer the only format for a control
   stream token.  I know that EBCDIC could be specified for the data
   stream, but I don't know about the control stream.  It is unclear
   where UTF8 fits, exactly (see #4)

3) UTF8 is now required, but does not appear to be fully specified.
   Winning UTF9 should be an option.

4) Lack of canonical file name specifications.  Now that I'm deep
   into looking at the issue, I can see why it wasn't done.  There is
   a bit more than a bit of work to do.

5) Extensive use of SITE command, even though these keywords are not
   uniform nor are their actions consistently documented (or at all).
   This can make interchange between a client from a different
   manufacturer than a server quite an adventure.
^L
FTPSER has its own woes.  It is suffering from a gradually worsening
case of multi-cruft.  At one point, I actually did know, was
acquainted with or knew of a number of people who were hacking the
code and while they were all fairly talented individuals, they never
seemed to have enough time to do what they needed to do.  It seems
that there were so many cooks.

Worse, I don't recall FTPSER ever having any real owner or champion,
either at DEC or externally, such as was and is the case with MM and
friends.  In any case, to date, I have identified a number of
concerns, problems, misfeatures or unfeatures (a command that is
claimed to be implemented that doesn't really do anything):

0) I think it's time to flush all the Tenex code.  If not cruft, then
   it is close to it at this point.  It's a good place for bugs.

1) There is at least one command that doesn't conform to
   specification: LIST.  It returns MLST as a default.  Everybody
   else does a full vdirectory type listing.

2) There are a number of site specific commands that are at top level
   which should be sub-commands of SITE (BOMB, CRASH).

3) SITE is also broken (no HELP) and lists SMNT, which is a required
   top-level command, as per RFC959.

4) ABOR completely punts the file and does not allow for a REST.

5) REST doesn't do anything.

6) STOU isn't implemented.

7) REIN is invisibly implemented with no action.  It should at least
   flatten the current address space with a new copy of FTPSER.  If
   we can't get the job back to a not logged in state, then the new
   copy of FTPSER should only allow a login to the current user.

8) There are a number of undocumented commands that may have
   potential security issues (CRASH, BOMB).

9) ALLO should do more than just be acknowledged and ignored.  It
   should either report that space may not or could not be reserved
   or actually reserve the space.  It might do one of the following
   (I yearn for c):

   a) At the very least, the requested amount should be subtracted
      from the free space on the structure.  If this is negative,
      then the command should FAIL.
   b) The directory current disk usage should be subtracted from the
      permanent quota and the requested amount be subtracted from
      this.  If negative, then FAIL as per a)
   c) A file in the connected directory with a unique name should be
      created with the total amount of requested disk space.

       i) On receipt of a STOU (which is currently NOT implemented),
          the created name should be kept.
      ii) On receipt of a STOR, the created file should be renamed.
     iii) If the new name is not in the current directory, then the
          created file should be punted and an error message given.
      iv) APPE should cause the file allocation to be transfered to
          the requested file.  A page should be deleted from the
          created file and then added to the requested file.  The
          created file should then be tossed.
^L
While on a train trip, I came up with a preliminary set of
specifications for Tops-20 FTP server canonical mode.  I haven't fully
resolved all issues with file path transmogyfication, but here is what
I do have:

Name Space:

1) Root Directory is simulated, populated with directory entries
  that can NOT modified in any way by anyone, except by addition (see
   below).  These entries are:

  a) User's currently MOUNTed directory structures:
       i) Connecting to structure then yields list of top-level
          directories, but no files (ie, DSKBTTBL). On TOMMYT:
          admiral, fdc, missyface, mrc, operator, rossman, saber and
          slogin would be listed.
      ii) In no case is a connect to <ROOT-DIRECTORY> ever allowed.
     iii) Connecting to a top level directory then produces a normal
          list of files, viz: /tops20/slogin/filepath/
      iv) '.' and '..' are simulated as expected.
  b) Additional structures may be added to root with SMNT, but only
     if they are domestic and unregulated.  In no case will operator
     intervention ever be requested.
  c) Mounted DECtapes:
       i) Top-level directory contains list of files.
      ii) Pathnames are of the form /dta0/foo.bar
     iii) '.' and '..' are simulated as expected.  '.'
      iv) Additional details on KLH10 and Tops-20 DECtape support to be
          posted, later. (I wrote this up, but want to think about it)
  d) NUL:
       i) NUL: is special, it is both a directory and a file.
      ii) Write to or read from /null as file is allowed
     iii) Connect to /null is allowed, directory entries being:
           '.' (/null), '..'  (/) and /null.
      iv) Writing to or reading from /null/null works.
       v) Connecting to /null/null (or /null/null/null, etc) puts you
          back in /null.

2) Initial root directory MLST might be: 'nul tops20/'.  SMNT SNARK
  would then produce: 'nul snark/ tops20/'.
3) /dev does NOT exist, so no 'raw' devices such as MTA0:, TTY0:,
  PTY0:, PLPT0:, DCN:, SRV:, TCP: or PIPE:
4) DECnet files are not supported, viz: CU20A::PS:<SLOGIN>FOO.BAR.1

Command Set:

1) Re-Implement SITE with the following keywords:

  a) DIRSTYLE for different directory listing styles.  See KB102974
       i) DIRSTYLE ON  - Winning TOPS20 filepaths (default)
      ii) DIRSTYLE OFF - CANONICAL (Unix) style filepaths
     iii) Detected forward slash '/' implies canonical; turns
          DIRSTYLE off.
      iv) No arguments implies toggle
  b) CKM for annotated listings.  See KB102974.
       i) CKM ON  - Display contents of the file ^V~FTPSVC^V~.CKM, if it
          exists in target directory, as part of response to a CWD
      ii) CKM OFF - Ignore ~FTPSVC~.CKM. (default)
     iii) No arguments implies toggle.
      iv) CDUP performs as CWD.  Or not?
     iii) No arguments implies toggle.
      iv) CDUP performs as CWD.  Or not?
  c) VERBOSE for extra processing messages.
       i) VERBOSE ON  - Normal responses plus blather
      ii) VERBOSE OFF - Normal responses and no blather (default)
  d) DEBUG - merge DDT into address space and start it.  Return from
     DDT completes command.  Only enabled WHEEL allowed to use DEBUG.
  e) BOMB  - Graceful fatal system error and close. Needs WHEEL.
  f) CRASH - Unhandled fatal system error (JRST 4,.). Needs WHEEL.
  g) CAPS  - Enable user's capabilities
       i) CAPS ON  - Enable capabilities
      ii) CAPS OFF - Disable capapbilities (default)
     iii) FYI: current implementation ALWAYS has capabilities on!!!
  h) HELP  - List of site specific commands:
     DIRSTYLE, CKM, VERBOSE, DEBUG, BOMB, CRASH, CAPS HELP

2) STAT modified to display DEBUG, VERBOSE, DIRSTYLE CAPS and CKM status

3) LIST is broken; it returns only a list of names.  It should return
  a list with file information in ALL cases. viz:

  DIRSTYLE ON: (TOPS20)
       TOPS20:<SLOGIN>NAG.TXT.1;P777700;A,6,26-May-2004;00:15:15,14-Jun-2004;
       17:29:54,11-Jun-2004 09:14:50

  DIRSTYLE OFF: (CANONICAL)  [tentative]
       -rwxrwx---   1 slogin   wheel      15360 Jun 24 17:29 nag.txt

4) Implement FEAT: (RFC2389).  Feature list is SIZE, MDTM and OPTS

5) Implement OPTS: (RFC2389).  Keywords are:

  UTF8 - 8 bit byte Unicode encoding
  UTF9 - Winning Tops-20 9 bit byte (half half word) encoding

  Initial implementation of OPTS will recognize both, but issue a failure

6) STOU (store unique file name) does not exist.  Maybe implement?












15-Jun-2004 09:35:50-PDT,4204;000000000000
Return-Path: <[email protected]>
Received: from sesame.cc.columbia.edu ([128.59.59.56]) by lingling.panda.com with TCP/SMTP; Tue, 15 Jun 2004 09:27:47 -0700 (PDT)
Received: from sesame.cc.columbia.edu (localhost [127.0.0.1])
       by sesame.cc.columbia.edu (8.12.11/8.12.11) with ESMTP id i5FGRmvR014188;
       Tue, 15 Jun 2004 12:27:48 -0400 (EDT)
Received: (from fdc@localhost)
       by sesame.cc.columbia.edu (8.12.11/8.12.8/Submit) id i5FGRlG6014187;
       Tue, 15 Jun 2004 12:27:47 -0400 (EDT)
Date: Tue, 15 Jun 2004 12:27:47 EDT
From: Frank da Cruz <[email protected]>
To: [email protected]
Subject: Re: Whither FTPSER?
In-Reply-To: <[email protected]>
Cc: Tops-20 Wizards <[email protected]>,
       Carl Baltrunas <[email protected]>
Message-ID: <CMM.0.91.0.1087316867.fdc@sesame>

>  0) Modern implementations are largely an undocumented superset of
>     RFC959.  Chasing down all the keywords, their syntax and semantic
>     actions was not what I expected.  I thought that there would be
>     one SINGLE RFC that superseded RFC959.  That was decidedly NOT
>     the case.
>
It's rarely the case.  Try to piece together the Telnet protocol definition!

>  1) Many implementations do not conform to published specifications,
>     FEAT and OPTS being two notable examples.
>
Right.  And then when you get into the security features, it's even worse
than that.

>  2) NVT-ASCII appears be no longer the only format for a control
>     stream token.  I know that EBCDIC could be specified for the data
>     stream, but I don't know about the control stream.  It is unclear
>     where UTF8 fits, exactly (see #4)
>
>  3) UTF8 is now required, but does not appear to be fully specified.
>     Winning UTF9 should be an option.
>
UTF-8 is a Can O' Worms.  Actually it's not UTF-8 so much as it is Unicode
itself (speaking as a Unicode Consortium member and sometime contributor).
Briefly put: there is more than one way to spell the same word in Unicode,
e.g. Salvador with Latin-1 a-acute versus a + combining acute, so you
have to do canonical decomposition and recomposition, which involves
database lookups, sorting, etc.  And that doesn't even begin to address
problems like spelling IBM, with a Cyrillic B instead of an ASCII one.
However, it IS a sign of progress that file NAMES are now supposed always be
in UTF-8.

>  4) Lack of canonical file name specifications.  Now that I'm deep
>     into looking at the issue, I can see why it wasn't done.  There is
>     a bit more than a bit of work to do.
>
>  5) Extensive use of SITE command, even though these keywords are not
>     uniform nor are their actions consistently documented (or at all).
>     This can make interchange between a client from a different
>     manufacturer than a server quite an adventure.
>
The most disgusting thing about current FTP implementations is how DIR is
implemented by sending a LIST command and the "parsing" the result, yuk!
That's why MLSD is ALMOST such a great leap forward.  Unfortunately few
servers implement it yet, so I haven't bothered to make an MLSD-driven
DIR command (it's on my list).

>  1) There is at least one command that doesn't conform to
>     specification: LIST.  It returns MLST as a default.  Everybody
>     else does a full vdirectory type listing.
>
I had to put a special client command into C-Kermit's FTP client to get
the VDIR listing from FTPSER :-)

> 4) Implement FEAT: (RFC2389).  Feature list is SIZE, MDTM and OPTS
>
> 5) Implement OPTS: (RFC2389).  Keywords are:
>
>    UTF8 - 8 bit byte Unicode encoding
>    UTF9 - Winning Tops-20 9 bit byte (half half word) encoding
>
>    Initial implementation of OPTS will recognize both, but issue a failure
>
> 6) STOU (store unique file name) does not exist.  Maybe implement?
>
The problem with this command is that there is no mechanism for the server
to tell the client what name was used, so it's basically useless.  What I
do is have the client check if the name exists, and if so, construct another
and check that, etc, until it finds a free name.

 7) MLSD <-- implement this one too.

- Frank
15-Jun-2004 12:59:46-PDT,3343;000000000000
Return-Path: <[email protected]>
Received: from mxout6.cac.washington.edu ([140.142.33.20]) by lingling.panda.com with TCP/SMTP; Tue, 15 Jun 2004 12:50:12 -0700 (PDT)
Received: from smtp.washington.edu (smtp.washington.edu [140.142.33.9])
       by mxout6.cac.washington.edu (8.12.11+UW04.02/8.12.11+UW04.03) with ESMTP id i5FJo62Q015011;
       Tue, 15 Jun 2004 12:50:11 -0700
Received: from Tomobiki-Cho.CAC.Washington.EDU (tomobiki-cho.cac.washington.edu [128.95.135.58])
       (authenticated bits=0)
       by smtp.washington.edu (8.12.11+UW04.02/8.12.11+UW04.03) with ESMTP id i5FJo5S5014739
       (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT);
       Tue, 15 Jun 2004 12:50:05 -0700
Date: Tue, 15 Jun 2004 12:50:07 -0700 (Pacific Daylight Time)
From: Mark Crispin <[email protected]>
To: [email protected]
cc: Tops-20 Wizards <[email protected]>
Subject: Re: Whither FTPSER?
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

On Tue, 15 Jun 2004 [email protected] wrote:
> Yes, the FTP WG isn't ... Well, let's not get into
> that ...  Maybe at some point a number of us might get
> together and generate more noise.  It might help.  Or not ...

The dysfunction of the FTP WG is perhaps the oldest and longest-lasting of
all, having gone on for at least 30 years that I am aware of.  I've heard
stories about how one meeting in the 1970s had people pounding tables.  I
also heard a bizarre story about the fate of the document author of that
time, which I won't repeat since I don't know if it is true.

> For the moment, I think that hacking FTP is interesting.

Good.  I encourage you to do so.

> 0) Modern implementations are largely an undocumented superset of
>    RFC959.

Be thankful that there is such a thing as RFC 959 which is largely a
subset of modern FTP.  That was not always the case.

> 3) UTF8 is now required, but does not appear to be fully specified.
>    Winning UTF9 should be an option.

I disagree.  UTF-9 should most certainly be used as a TOPS-20 internal
format, but over the wire UTF-8 makes more sense except in some specific
TOPS-20 <=> TOPS-20 interchange such as paged transfers.

> FTPSER has its own woes.  It is suffering from a gradually worsening
> case of multi-cruft.

Indeed.  I started a rewrite of FTPSER years ago, but that effort was
sabotaged.  By the time those factors ceased to be an issue, I was already
heavily involved on IMAP and the effort came to an end.

> 0) I think it's time to flush all the Tenex code.

Agreed.  Also agreed on your other proposed fixes and changes.  I'd like
to see the whole damn thing cleaned up (including but not limited to that
TCPSIM crap).

I think that you have volunteered yourself to be the owner of FTPSER.
With that in mind, I propose that I receive new releases of FTPSER from
you (as opposed to patches for me to install).

-- Mark --

http://staff.washington.edu/mrc
Science does not emerge from voting, party politics, or public debate.
Si vis pacem, para bellum.
15-Jun-2004 15:59:32-PDT,4932;000000000000
Return-Path: <[email protected]>
Received: from mta10.srv.hcvlny.cv.net ([167.206.5.85]) by lingling.panda.com with TCP/SMTP; Tue, 15 Jun 2004 15:47:39 -0700 (PDT)
Received: from optonline.net (mstr3.srv.hcvlny.cv.net [167.206.5.14])
by mta10.srv.hcvlny.cv.net
(iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar  3 2004))
with ESMTP id <[email protected]> for
[email protected]; Tue, 15 Jun 2004 18:47:30 -0400 (EDT)
Received: from [167.206.5.73] (Forwarded-For: [216.179.91.114])
by mstr3.srv.hcvlny.cv.net (mshttpd); Tue, 15 Jun 2004 18:47:26 -0400
Date: Tue, 15 Jun 2004 18:47:26 -0400
From: [email protected]
Subject: Re: Whither FTPSER?
To: Frank da Cruz <[email protected]>
Cc: Tops-20 Wizards <[email protected]
Message-id: <[email protected]>
MIME-version: 1.0
X-Mailer: iPlanet Messenger Express 5.2 HotFix 1.25 (built Mar  3 2004)
Content-type: text/plain; charset=us-ascii
Content-language: en
Content-transfer-encoding: 7BIT
Content-disposition: inline
X-Accept-Language: en
Priority: normal

> UTF-8 is a Can O' Worms.  Actually it's not UTF-8 so much as it is
> Unicode itself (speaking as a Unicode Consortium member and sometime
> contributor).

Actually, I have read a single book about Unicode in 1995 and have
since forgotten almost everything about it and UTF-8.  The only thing
that I do recall is that I (mistakenly) believed that I then knew
something about it.  However, I seem to remember seeing some stuff
posted on the Kermit web site about this.  I'll have another look.  If
not, thank you for volunteering to mentor me in UTF-8!  :-)

> Briefly put: there is more than one way to spell the same word in
> Unicode, e.g. Salvador with Latin-1 a-acute versus a + combining
> acute, so you have to do canonical decomposition and recomposition,
> which involves database lookups, sorting, etc.  And that doesn't
> even begin to address problems like spelling IBM, with a Cyrillic B
> instead of an ASCII one.  However, it IS a sign of progress that
> file NAMES are now supposed always be in UTF-8.

Yes, I believe that you've posted something about this.  Somewhere?
My guess is that I wouldn't have much trouble converting the existing
Tops-20 file names into UTF-8.  However, trying to convert UTF-8 file
names into Tops-20 file specifications, which only support 7 bit
bytes, is making me a little nervous at the moment.

> DIR is implemented by sending a LIST command and the "parsing" the
> result, yuk!

I haven't had the stomach to look at ange-ftp in a few months, but as
nearly as I can recollect, this is, in fact, EXACTLY what it does for
known Unix hosts.  However, for other hosts, I believe that it issues
an NLST and then grovels over the returned list of files, issuing a
SIZE and MDTM for each one.  This is how I learned that these two
features existed...

> >  1) There is at least one command that doesn't conform to
> >     specification: LIST.  It returns NLST as a default.  Everybody
> >     else does a full vdirectory type listing.

> I had to put a special client command into C-Kermit's FTP client to
> get the VDIR listing from FTPSER :-)

That is really swell of you to volunteer to test the C-Kermit FTP
client with the new FTPSER!  :-)

> > 6) STOU (store unique file name) does not exist.  Maybe implement?
> >
> The problem with this command is that there is no mechanism for
> the server to tell the client what name was used, so it's basically
> useless.  What I do is have the client check if the name exists, and
> if so, construct another and check that, etc, until it finds a free
> name.

Yech, that is pretty awful.  Only you would have the patience to do
something like that!  However for STOU, RFC959 says in part: "The 250
Transfer Started response must include the name generated".  I was
thinking that I would respond with something like:

250 "JOB#-UNIQUE#.DATE-TIME#.GENERATION#" Transfer Started

                               as in:

250 "JOB6-UNIQUE.15-JUNE-2004-170303.8" Transfer Started

The uniqueness is something off the top of my head.  I obviously can't
use the fork number because FTPSER is always the top fork in the job.
I'm certain somebody will have a better idea.  Anyway, I thought that
this would be similar to what is returned for PWD:

ftp> pwd
257 "TOPS20:<SLOGIN>" is current directory.

>  7) MLSD <-- implement this one too.

I'll make sure that gets on the list and do please feel free to nag me
about it if you don't see it.  I'm always in favor of anything that
allows me to brag about winning Tops-20 features to the (many) Unix
and Windows people around here.  But, I wasn't aware of MLSD.  As you
probably know all too well, it's difficult to be aware of this stuff.
Do you have any examples of MLSD output that you can send my way or
should I just assume canonical?


15-Jun-2004 16:18:49-PDT,2756;000000000000
Return-Path: <[email protected]>
Received: from mta7.srv.hcvlny.cv.net ([167.206.5.74]) by lingling.panda.com with TCP/SMTP; Tue, 15 Jun 2004 16:08:18 -0700 (PDT)
Received: from optonline.net (mstr3.srv.hcvlny.cv.net [167.206.5.14])
by mta7.srv.hcvlny.cv.net
(iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar  3 2004))
with ESMTP id <[email protected]>; Tue,
15 Jun 2004 19:08:14 -0400 (EDT)
Received: from [167.206.5.73] (Forwarded-For: [216.179.91.114])
by mstr3.srv.hcvlny.cv.net (mshttpd); Tue, 15 Jun 2004 19:08:07 -0400
Date: Tue, 15 Jun 2004 19:08:07 -0400
From: [email protected]
Subject: Re: Whither FTPSER?
To: Mark Crispin <[email protected]>
Cc: Tops-20 Wizards <[email protected]>
Message-id: <[email protected]>
MIME-version: 1.0
X-Mailer: iPlanet Messenger Express 5.2 HotFix 1.25 (built Mar  3 2004)
Content-type: text/plain; charset=us-ascii
Content-language: en
Content-transfer-encoding: 7BIT
Content-disposition: inline
X-Accept-Language: en
Priority: normal

> I also heard a bizarre story about the fate of the document author
> of that time, which I won't repeat since I don't know if it is true.

Regretfully, not knowing if something scandalous is truly true has
never been much of an impediment to me gossiping about it in the past.
I envy your will power.  :-(

> I disagree.  UTF-9 should most certainly be used as a TOPS-20
> internal format, but over the wire UTF-8 makes more sense except in
> some specific TOPS-20 <=> TOPS-20 interchange such as paged
> transfers.

I think that it is fairly clear to me that I don't really understand
either UTF-8 or UTF-9.  When I do get to looking at this, I will make
sure you are in the loop and will probably ask Frank for his thoughts.
In the case of UTF-9, I was merely assuming that something that is
more specific to 36 bit machines is, by its very nature, more winning
and hence is to be held in higher regard.

> I'd like to see the whole damn thing cleaned up (including but not
> limited to that TCPSIM crap).

Oh yeah, you noticed TCPSIM?  Once I get some major functionality on
the air, I am probably going to punt that entire source file along
with a lot of other things.

> I think that you have volunteered yourself to be the owner of
> FTPSER.  With that in mind, I propose that I receive new releases of
> FTPSER from you (as opposed to patches for me to install).

Assuming I do something worthwhile, I'll be happy to volunteer.  On
the other hand, don't discount the possibility that I will screw
things up worse.  :-)  With that in mind, I will probably be looking
around for some victims, err, volunteers to test some of this stuff.


15-Jun-2004 19:09:19-PDT,2218;000000000000
Return-Path: <[email protected]>
Received: from mxout6.cac.washington.edu ([140.142.33.20]) by lingling.panda.com with TCP/SMTP; Tue, 15 Jun 2004 19:00:43 -0700 (PDT)
Received: from smtp.washington.edu (smtp.washington.edu [140.142.32.139])
       by mxout6.cac.washington.edu (8.12.11+UW04.02/8.12.11+UW04.03) with ESMTP id i5G20gFe005944;
       Tue, 15 Jun 2004 19:00:43 -0700
Received: from Tomobiki-Cho.CAC.Washington.EDU (tomobiki-cho.cac.washington.edu [128.95.135.58])
       (authenticated bits=0)
       by smtp.washington.edu (8.12.11+UW04.02/8.12.11+UW04.03) with ESMTP id i5G20PWV031423
       (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT);
       Tue, 15 Jun 2004 19:00:42 -0700
Date: Tue, 15 Jun 2004 19:00:21 -0700 (Pacific Daylight Time)
From: Mark Crispin <[email protected]>
To: [email protected]
cc: Frank da Cruz <[email protected]>,
       Tops-20 Wizards <[email protected]>
Subject: Re: Whither FTPSER?
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

On Tue, 15 Jun 2004 [email protected] wrote:
> My guess is that I wouldn't have much trouble converting the existing
> Tops-20 file names into UTF-8.

The transformation of ASCII into UTF-8 is the identity function.  It's the
reverse transformation that is the problem.

> However, trying to convert UTF-8 file
> names into Tops-20 file specifications, which only support 7 bit
> bytes, is making me a little nervous at the moment.

There have been several attempts at this.  However, the important thing is
that you do *NOT*, repeat, *NOT* follow the mistake of IMAP in using
"modified UTF-7", but rather use punycode which has become the standard
encoding of Unicode into ASCII.

I also will be glad to help you with Unicode issues.  For now, stick to
ASCII.

-- Mark --

http://staff.washington.edu/mrc
Science does not emerge from voting, party politics, or public debate.
Si vis pacem, para bellum.
15-Jun-2004 19:17:06-PDT,2388;000000000000
Return-Path: <[email protected]>
Received: from mxout4.cac.washington.edu ([140.142.33.19]) by lingling.panda.com with TCP/SMTP; Tue, 15 Jun 2004 19:04:20 -0700 (PDT)
Received: from smtp.washington.edu (smtp.washington.edu [140.142.33.9])
       by mxout4.cac.washington.edu (8.12.11+UW04.02/8.12.11+UW04.03) with ESMTP id i5G24A7w023522;
       Tue, 15 Jun 2004 19:04:10 -0700
Received: from Tomobiki-Cho.CAC.Washington.EDU (tomobiki-cho.cac.washington.edu [128.95.135.58])
       (authenticated bits=0)
       by smtp.washington.edu (8.12.11+UW04.02/8.12.11+UW04.03) with ESMTP id i5G24AAC021466
       (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT);
       Tue, 15 Jun 2004 19:04:10 -0700
Date: Tue, 15 Jun 2004 19:04:08 -0700 (Pacific Daylight Time)
From: Mark Crispin <[email protected]>
To: [email protected]
cc: Tops-20 Wizards <[email protected]>
Subject: Re: Whither FTPSER?
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

On Tue, 15 Jun 2004 [email protected] wrote:
> I think that it is fairly clear to me that I don't really understand
> either UTF-8 or UTF-9.  When I do get to looking at this, I will make
> sure you are in the loop and will probably ask Frank for his thoughts.
> In the case of UTF-9, I was merely assuming that something that is
> more specific to 36 bit machines is, by its very nature, more winning
> and hence is to be held in higher regard.

UTF-9 would be useful as a text file format (9-bit files) and possibly
also for filenames.  However, UTF-9 filenames will require substantial
changes to the filesystem and is not going to happen soon.

> Oh yeah, you noticed TCPSIM?

Yes.  For decades.  Death to TCPSIM.

> Assuming I do something worthwhile, I'll be happy to volunteer.

You've been volunteered.

> On
> the other hand, don't discount the possibility that I will screw
> things up worse.  :-)

Don't worry, I'll be happy to yell at you if you break it. :-)

-- Mark --

http://staff.washington.edu/mrc
Science does not emerge from voting, party politics, or public debate.
Si vis pacem, para bellum.
16-Jun-2004 03:55:59-PDT,2310;000000000000
Return-Path: <[email protected]>
Received: from YALLA.kz.kz ([82.182.137.68]) by lingling.panda.com with TCP/SMTP; Wed, 16 Jun 2004 03:44:10 -0700 (PDT)
Received: from kz.kz (DHCP-100 [192.168.0.100])
       by YALLA.kz.kz (8.9.2/) with ESMTP id MAA57310;
       Wed, 16 Jun 2004 12:35:34 +0200 (CEST)
       (envelope-from [email protected])
Message-ID: <[email protected]>
Date: Wed, 16 Jun 2004 12:46:11 +0200
From: Klaus Zeuge <[email protected]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7b) Gecko/20040421
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Mark Crispin <[email protected]>
CC: [email protected], Frank da Cruz <[email protected]>,
       Tops-20 Wizards <[email protected]>
Subject: Re: Whither FTPSER?
References: <[email protected]> <[email protected]>
In-Reply-To: <[email protected]>
Content-Type: text/plain; charset=ISO-8859-15; format=flowed
Content-Transfer-Encoding: quoted-printable

Mark Crispin wrote:
> On Tue, 15 Jun 2004 [email protected] wrote:
>=20
>> My guess is that I wouldn't have much trouble converting the existing
>> Tops-20 file names into UTF-8.
>=20
>=20
> The transformation of ASCII into UTF-8 is the identity function.  It's =

> the reverse transformation that is the problem.


Is this true in all circumstances? I remember using ASCII { for =E4, ASCI=
I ]=20
for =C5 and so on in filenames and text on the TOPS-20 and Tops-10 machin=
es=20
I used in the 19890's and 1990's in Sweden. This technique of using the=20
same character code for different characters is of course according to=20
ISO-646-SE and ISO-646-SE2. (ASCII is the special case ISO-646.) It's jus=
t=20
like when switching between ISO-8859-1 (Latin1) and ISO-8859-15 (Latin9) =

and their friends.

The problem with character codings was much worse in the era of seven bit=
=20
characters. This is not a new problem. UTF-8, Unicode and so on are just =

"new" solution.

When stepping into the conversion swamp using UTF-8, wouldn't it be a a=20
good thing to get it right? Not just when handling a reduced alphabet of =

just A-Z, but also when handling =C9, =C5, =F1 and so on?

       Regards,
       Klaus Zeuge



16-Jun-2004 06:31:47-PDT,4648;000000000000
Return-Path: <[email protected]>
Received: from sesame.cc.columbia.edu ([128.59.59.56]) by lingling.panda.com with TCP/SMTP; Wed, 16 Jun 2004 06:20:12 -0700 (PDT)
Received: from sesame.cc.columbia.edu (localhost [127.0.0.1])
       by sesame.cc.columbia.edu (8.12.11/8.12.11) with ESMTP id i5GDK9V3026231;
       Wed, 16 Jun 2004 09:20:09 -0400 (EDT)
Received: (from fdc@localhost)
       by sesame.cc.columbia.edu (8.12.11/8.12.8/Submit) id i5GDK8cI026222;
       Wed, 16 Jun 2004 09:20:08 -0400 (EDT)
Date: Wed, 16 Jun 2004 9:20:08 EDT
From: Frank da Cruz <[email protected]>
To: Klaus Zeuge <[email protected]>
Cc: Mark Crispin <[email protected]>, [email protected],
       Tops-20 Wizards <[email protected]>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-15; format=flowed
Subject: Re: Whither FTPSER?
In-Reply-To: <[email protected]>
Message-ID: <CMM.0.91.0.1087392008.fdc@sesame>
Content-Transfer-Encoding: quoted-printable
X-MIME-Autoconverted: from 8bit to quoted-printable by sesame.cc.columbia.edu id i5GDK9V3026231

Klaus Zeuge <[email protected]> wrote:
>=20
> ... I remember using ASCII { for =E4, ASCII ]=20
> for =C5 and so on in filenames and text on the TOPS-20 and Tops-10 mach=
ines=20
> I used in the 19890's and 1990's in Sweden. This technique of using the=
=20
> same character code for different characters is of course according to=20
> ISO-646-SE and ISO-646-SE2. (ASCII is the special case ISO-646.) It's j=
ust=20
> like when switching between ISO-8859-1 (Latin1) and ISO-8859-15 (Latin9=
)=20
> and their friends.
>=20
ISO-646 national versions were a sensible, if awkward, solution for the
DEC-20, because of its use of 7-bit bytes for text files.  One of the
beauties of PDP-10 architecture is the variable byte size, but writers of
software almost always hardwired 7-bit bytes, and even the Monitor prefer=
red
them ("HRROI A, ASCIZ /Some string/" to set up a JSYS).

In theory it would be possible to convert TOPS-20 and all its utilities t=
o
an 8-bit, 9-bit, 16-bit, 24-bit, or even 32-bit character set, but it wou=
ld
require modifying all the applications to pay attention to bytesize.  It
could also clash with various file formats, e.g. EDIT line numbers.

That's why ISO 646 was so successful -- you could use it behind the back =
of
the computer.  No applications needed to be changed.  You simply put your
terminal in "Swedish mode" or whatever, and then used {}\[]... for accent=
ed
letters (which tended to make your source look funny, but people were qui=
te
accustomed to that).

> The problem with character codings was much worse in the era of seven b=
it=20
> characters. This is not a new problem. UTF-8, Unicode and so on are jus=
t=20
> "new" solution.
>=20
I wrote a little paper about this ten years ago:

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

> When stepping into the conversion swamp using UTF-8, wouldn't it be a a=
=20
> good thing to get it right? Not just when handling a reduced alphabet o=
f=20
> just A-Z, but also when handling =C9, =C5, =F1 and so on?
>=20
Unicode handles *everything* -- Tibetan, Sanskrit, Hebrew, Arabic, Chines=
e,
Japanese, Korean, Armenian, Russian, Georgian, Greek, Coptic, Amharic, et=
c,
as well as accented East and West European Latin letters (not to mention
Vietnamese, in which a Latin letter can have several accents).  Text
processing, which was so simple with single-byte character sets like ASCI=
I,
ISO 646, and ISO 8859, becomes enormously complicated with Unicode, where
every application must carry around multiple databases to look up the
properties of each character, the collation rules, etc.

But if TOPS-20 applications actually paid attention to file bytesizes, it
would be one of the easiest OS's to convert to Unicode -- just start usin=
g
32-bit bytes for text (or 16-bit bytes if you wanted to save space and
didn't mind putting up with surrogates).  To make TOPS-20 use 8-bit
characters (like ISO 8859-15) would be just as difficult as making it use
any other size characters.

UTF-8, by the way, is for use on the wire, but does not make a lot of sen=
se
as a native storage format for text, except for its identity with ASCII i=
n
the 0-127 range, but that's just a trick needed for 8-bit-byte systems li=
ke
Unix.  In TOPS-20, the same thing is accomplished by changing the bytesiz=
e.

The terminal driver would need some attention.  It would need to convert
between UTF-32 internally and UTF-8 on the wire, and it would need to all=
ow
UTF-8 characters to pass through without triggering control functions.

- Frank
16-Jun-2004 10:01:12-PDT,6150;000000000000
Return-Path: <[email protected]>
Received: from Ikkoku-Kan.Panda.COM (panda.com [206.124.149.114]) by lingling.panda.com with TCP/SMTP; Wed, 16 Jun 2004 09:49:22 -0700 (PDT)
Received: from Ikkoku-Kan.Panda.COM (Ikkoku-Kan.Panda.COM [192.107.14.50]) by Ikkoku-Kan.Panda.COM id JAA11862; Wed, 16 Jun 2004 09:41:40 -0700 (PDT)
Date: Wed, 16 Jun 2004 09:00:48 -0700 (PDT)
From: Mark Crispin <[email protected]>
Sender: Mark Crispin <[email protected]>
Subject: Re: Whither FTPSER?
To: TOPS-20 Hackers and Yackers <[email protected]>
In-Reply-To: <CMM.0.91.0.1087392008.fdc@sesame>
Message-ID: <[email protected]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII

On Wed, 16 Jun 2004 9:20:08 EDT, Frank da Cruz wrote:
> Klaus Zeuge <[email protected]> wrote:
> > ... I remember using ASCII

Klaus did not use ASCII.  He used ISO 646.  ISO 646 is not ASCII, although
ASCII is one of the ISO 646 versions.

ISO 646 has all the problems of ISO 8859, in that the same codepoints are used
in different regions for the same purpose, making untagged text unsuitable in
a networked environment that crosses regions.

In addition, ISO 646 has an even more severe problem; ASCII is not a proper
subset of the national versions.  This means that you lose such characters as
"@".

The deficiencies of ISO 646 in an Internet environment were recognized early
on, and nobody ever seriously advocated its use for the Internet.  The reason
why people in Europe might remember using it on the DEC-20 is that there
weren't very many Internet DEC-20s in Europe.  I think that I can count the
European Internet DEC-20s on one hand, and IIRC none of these systems used ISO
646 in network applications.

ISO 8859, on the other hand, had ASCII as a subset, and many of the 8859
variants covered larger regions than a single country.  Furthermore, we
institute character set tagging in protocols (e.g. MIME in email) to make some
measure of interoperability possible when codepoints overlap.

Nevertheless, file names and URLs in ISO 8859 (not to mention KOI-8R, Shift-
JIS, EUC-??, etc.) have never worked well in an Internet context due to the
lack of such tagging.

That is why we concluded 7 years ago (see RFC 2130) that a transition to
Unicode was the only sensible approach.

> ISO-646 national versions were a sensible, if awkward, solution for the
> DEC-20, because of its use of 7-bit bytes for text files.

But only in a closed environment when you don't interact with systems outside
of your own ISO 646 national environment.

> In theory it would be possible to convert TOPS-20 and all its utilities to
> an 8-bit, 9-bit, 16-bit, 24-bit, or even 32-bit character set, but it would
> require modifying all the applications to pay attention to bytesize.

A simpler task is to fix TOPS-20 so that file byte sizes are considered as
well as the open mode.  Right now, only the open mode is used, and file data
is considered to be raw 36-bit words.  For compatibility with the past, 36-bit
files could do the existing behavior.

In other words, if you read an 8-bit file with an 7-bit open mode, the high
bit should be truncated from each byte instead of returning
       b0-6 of byte 1
       b7 of byte 1 and b0-5 of byte 2
       b6-7 of byte 2 and b0-4 of byte 3
       b5-7 of byte 3 and b0-3 of byte 4
       b4-7 of byte 4 and 3 bits of randomness.

This has been on my queue of things to do for 25 years.  Unicode finally gives
me a reason to do it.

> It
> could also clash with various file formats, e.g. EDIT line numbers.

EDIT line numbers are perhaps the last thing that I (or anyone else) should
care about in this day and age!  Get with the program, use EMACS or at least
TECO!  :-)

> > When stepping into the conversion swamp using UTF-8, wouldn't it be a a
> > good thing to get it right? Not just when handling a reduced alphabet of
> > just A-Z

It's necessary to walk before we run, and there are some well-work transition
paths.  The first step is to make sure that we can talk to other systems.  The
second step is to make sure that we look like we handle Unicode to other
systems, e.g. by use of punycode encoded filenames which internally are ASCII
but look to the world like Unicode.  Finally, we do internal support.

If we take on too much at the onset, the likely result is that nothing gets
done.  IMAP faced the same issue.

> But if TOPS-20 applications actually paid attention to file bytesizes,

More importantly, the TOPS-20 monitor.  IO.MAC is far below its promise.

> it
> would be one of the easiest OS's to convert to Unicode -- just start using
> 32-bit bytes for text (or 16-bit bytes if you wanted to save space and
> didn't mind putting up with surrogates).

The cost of variable-width characters is something that you have to pay anyway
because of composed characters.  There is no good reason not to use UTF-9.
But if you want to disregard composed characters and have a fixed-width
character size, then it is possible to have a UCS-18 which uses planes 0, 1,
2, and 16.  Those are the only planes which are going to be used for a long
time.

UTF-9 or UCS-18 make much more sense than UCS-4 (which actually is 31 bits,
not 32).  UCS-4 Planes higher than 16 have been formally abandoned.  The
result is not a power of 2 (it's 20 and a half bits) since there are 17
planes.

> UTF-8, by the way, is for use on the wire, but does not make a lot of sense
> as a native storage format for text, except for its identity with ASCII in
> the 0-127 range, but that's just a trick needed for 8-bit-byte systems like
> Unix.  In TOPS-20, the same thing is accomplished by changing the bytesize.

The problem with UTF-8 is that it makes files 50% longer than UTF-16 for
certain scripts (most notably CJK).  UTF-9 does not have that problem.

UTF-9 is as good, or better, than UTF-16 for the BMP.  If you care about non-
BMP characters (and for the most part, we never will), then UCS-18 is just as
sensible and will cover all characters we're likely to see for a long time in
18-bits.

16-Jun-2004 12:16:24-PDT,2387;000000000000
Return-Path: <[email protected]>
Received: from aun.it.uu.se ([130.238.12.36]) by lingling.panda.com with TCP/SMTP; Wed, 16 Jun 2004 12:04:54 -0700 (PDT)
Received: from Nomen.it.uu.se (h133n2fls301o851.telia.com [81.224.225.133])
       (authenticated bits=0)
       by aun.it.uu.se (8.12.11/8.12.10) with ESMTP id i5GJ4ZHD022765
       (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
       Wed, 16 Jun 2004 21:04:36 +0200 (MEST)
Received: by Nomen.it.uu.se (Postfix, from userid 1020)
       id E38E01743D2; Wed, 16 Jun 2004 21:04:27 +0200 (CEST)
To: TOPS-20 Hackers and Yackers <[email protected]>
Subject: Re: Whither FTPSER?
References: <[email protected]>
From: Bjorn Victor <[email protected]>
Date: Wed, 16 Jun 2004 21:04:27 +0200
In-Reply-To: <[email protected]> (Mark
Crispin's message of "Wed, 16 Jun 2004 09:00:48 -0700 (PDT)")
Message-ID: <[email protected]>
User-Agent: Gnus/5.110002 (No Gnus v0.2) XEmacs/21.4 (Security Through
Obscurity, 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 i5GJ4ZHD022765

On Wed, 16 Jun 2004 09:00:48 -0700 (PDT) Mark Crispin <[email protected]=
COM> wrote:

> The deficiencies of ISO 646 in an Internet environment were recognized =
early
> on, and nobody ever seriously advocated its use for the Internet.  The =
reason
> why people in Europe might remember using it on the DEC-20 is that ther=
e
> weren't very many Internet DEC-20s in Europe.  I think that I can count=
the
> European Internet DEC-20s on one hand, and IIRC none of these systems u=
sed ISO
> 646 in network applications.

You may have larger hands than me ;-), but I believe there were more
than a handful only in Sweden (2 in Uppsala, 3-5 or so in Stockholm
(not counting Peter's), 2-3 in Link=F6ping).  The reasons for using ISO
646 were terminals and 7-bit issues, I think.  (When did ISO 8859 have
its breakthrough, really?  I don't remember, but around '90?)

Many people around here could read and write ][\ (etc) as =C5=C4=D6 (etc)
fluently; terminals could present them either way.  In that sense we
certainly used ISO 646 in network applications (e.g. mail, ftp, news).

-- Bj=F6rn
16-Jun-2004 13:00:44-PDT,1157;000000000000
Return-Path: <[email protected]>
Received: from Ikkoku-Kan.Panda.COM (panda.com [206.124.149.114]) by lingling.panda.com with TCP/SMTP; Wed, 16 Jun 2004 12:50:08 -0700 (PDT)
Received: from Ikkoku-Kan.Panda.COM (Ikkoku-Kan.Panda.COM [192.107.14.50]) by Ikkoku-Kan.Panda.COM id MAA11959; Wed, 16 Jun 2004 12:50:02 -0700 (PDT)
Date: Wed, 16 Jun 2004 12:48:26 -0700 (PDT)
From: Mark Crispin <[email protected]>
Sender: Mark Crispin <[email protected]>
Subject: Re: Whither FTPSER?
To: Bjorn Victor <[email protected]>
cc: TOPS-20 Hackers and Yackers <[email protected]>
In-Reply-To: <[email protected]>
Message-ID: <[email protected]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII

On Wed, 16 Jun 2004 21:04:27 +0200, Bjorn Victor wrote:
> You may have larger hands than me ;-), but I believe there were more
> than a handful only in Sweden

But were they on the Internet?

IIRC, ISO 8859-1 was pretty much standard in European email by 1988, although
it wasn't until 1990 that the alarming number of "just send 8-bit" systems
triggered the MIME work.


16-Jun-2004 16:29:43-PDT,1903;000000000000
Return-Path: <[email protected]>
Received: from aun.it.uu.se ([130.238.12.36]) by lingling.panda.com with TCP/SMTP; Wed, 16 Jun 2004 16:17:26 -0700 (PDT)
Received: from Nomen.it.uu.se (h133n2fls301o851.telia.com [81.224.225.133])
       (authenticated bits=0)
       by aun.it.uu.se (8.12.11/8.12.10) with ESMTP id i5GNHKRM006639
       (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
       Thu, 17 Jun 2004 01:17:21 +0200 (MEST)
Received: by Nomen.it.uu.se (Postfix, from userid 1020)
       id 735CB1743D2; Thu, 17 Jun 2004 01:17:10 +0200 (CEST)
To: Mark Crispin <[email protected]>
Cc: Bjorn Victor <[email protected]>,
       TOPS-20 Hackers and Yackers <[email protected]>
Subject: Re: Whither FTPSER?
References: <[email protected]>
From: Bjorn Victor <[email protected]>
Date: Thu, 17 Jun 2004 01:17:10 +0200
In-Reply-To: <[email protected]> (Mark
Crispin's message of "Wed, 16 Jun 2004 12:48:26 -0700 (PDT)")
Message-ID: <[email protected]>
User-Agent: Gnus/5.110002 (No Gnus v0.2) XEmacs/21.4 (Security Through
Obscurity, 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 i5GNHKRM006639

On Wed, 16 Jun 2004 12:48:26 -0700 (PDT) Mark Crispin <[email protected]=
COM> wrote:

> On Wed, 16 Jun 2004 21:04:27 +0200, Bjorn Victor wrote:
>> You may have larger hands than me ;-), but I believe there were more
>> than a handful only in Sweden
>
> But were they on the Internet?

Oh yes, the Nordic network got onto the Internet about a week *after*
the Morris worm, as I recall... and the DEC-20s started shutting down
about two years later, I think.  (But my memory may not be what it
was.  Could check it.)

-- Bj=F6rn
17-Jun-2004 09:29:16-PDT,2598;000000000000
Return-Path: <[email protected]>
Received: from sunshine.math.utah.edu ([128.110.198.2]) by lingling.panda.com with TCP/SMTP; Thu, 17 Jun 2004 09:18:13 -0700 (PDT)
Received: from psi.math.utah.edu (IDENT:[email protected] [155.101.96.19])
       by sunshine.math.utah.edu (8.12.11/8.12.10) with ESMTP id i5HGIDKt022874;
       Thu, 17 Jun 2004 10:18:13 -0600 (MDT)
Received: from psi.math.utah.edu (IDENT:MCUutwQZw06mK36qUl3GgrzXz4wETZZz@localhost [127.0.0.1])
       by psi.math.utah.edu (8.12.11/8.12.10) with ESMTP id i5HGIDOA017263;
       Thu, 17 Jun 2004 10:18:13 -0600 (MDT)
Received: (from beebe@localhost)
       by psi.math.utah.edu (8.12.11/8.12.10/Submit) id i5HGICZf017262;
       Thu, 17 Jun 2004 10:18:12 -0600 (MDT)
Date: Thu, 17 Jun 2004 10:18:12 -0600 (MDT)
From: "Nelson H. F. Beebe" <[email protected]>
To: Tops-20 Wizards <[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: Status of http://twenex.org/?
Message-ID: <[email protected]>

I've reached a point in the development of some software that makes
heavy use of floating-point arithmetic where I would very much like to
test it on platforms that do NOT have IEEE 754 arithmetic.  All of the
many Unix systems to which I currently have access do, but TOPS-20 has
36-bit, 72-bit, and 144-bit arithmetic.

A telnet session to twenex.org, followed by

       @new new

reports

       You are welcome to look around.  If you'd like an account,
       please go to our webpage, http://twenex.org and select 'MKACCT'

However, attempts to reach that URL with various Web browsers fail
with "Unable to connect to remote host.".

Has the service been dropped, or is it just that the Web server there
has hung or crashed, and no one has noticed?

-------------------------------------------------------------------------------
- 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  -
-------------------------------------------------------------------------------
18-Jun-2004 12:42:06-PDT,2849;000000000000
Return-Path: <[email protected]>
Received: from mta2.srv.hcvlny.cv.net ([167.206.5.68]) by lingling.panda.com with TCP/SMTP; Fri, 18 Jun 2004 12:30:47 -0700 (PDT)
Received: from optonline.net (mstr3.srv.hcvlny.cv.net [167.206.5.14])
by mta2.srv.hcvlny.cv.net
(iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar  3 2004))
with ESMTP id <[email protected]> for
[email protected]; Fri, 18 Jun 2004 15:30:03 -0400 (EDT)
Received: from [167.206.5.79] (Forwarded-For: [24.47.51.196])
by mstr3.srv.hcvlny.cv.net (mshttpd); Fri, 18 Jun 2004 15:29:55 -0400
Date: Fri, 18 Jun 2004 15:29:55 -0400
From: [email protected]
Subject: FTPSER
To: [email protected]
Message-id: <[email protected]>
MIME-version: 1.0
X-Mailer: iPlanet Messenger Express 5.2 HotFix 1.25 (built Mar  3 2004)
Content-type: text/plain; charset=us-ascii
Content-language: en
Content-transfer-encoding: 7BIT
Content-disposition: inline
X-Accept-Language: en
Priority: normal

I've been hacking FTPSER while I've been mulling over my file
specification transformation scheme.  Hacking code has occasionally
made things clearer for me in the past.  Or not...  In any event, here
is what I've done thus far:

1) Top-level commands DEBUG, CRASH, BOMB removed (moved to SITE)
2) SITE changed to parse sub-commands (it had refused anything)
3) Implemented FEAT: feature list is MDTM, SIZE.  OPTS is NOT there.
4) SITE command changed to have the following commands:
  a) HELP (default), lists the below
  b) BOMB, CRASH various flavors of gracelessly ending a session
  c) DDT (does the obvious thing if you are logged in and an enabled
     wheel).  Fixed so the server client process does not hang.
  d) CKM, enables directory annotation.  That is, it displays the
     contents of the file  ~FTPSVC~.CKM.0 when connecting into a
     directory.  Each line in the file is prepended with a '250-'.
     Other than that, I don't check for gubbish.  It's preliminary ...
  e) CAPAS, used to turn the user's capabilities (right halfword) on
     and off.  They are now OFF by default.
  f) NOOP, used to test parser.

This is up on my system, but I haven't done extensive testing, yet.
If anybody wants to try this and doesn't have any serious objection to
having their data corrupted, lost or misplaced, please feel free to
ask me. :-)

Meanwhile, Frank pointed me at some stuff for FTP called TVFS, or
Trivial Virtual File System.  It's very close to what I've been
thinking about, so I'm going to look at it over some more and make
some sort of an effort to see if I conform to it.

The NLST/LIST/STAT code in FTPSER seems a little too convoluted for
me.  I am probably going to just flush it all and do a rewrite.

                                --T

18-Jun-2004 15:12:31-PDT,1520;000000000000
Return-Path: <[email protected]>
Received: from Ikkoku-Kan.Panda.COM (panda.com [206.124.149.114]) by lingling.panda.com with TCP/SMTP; Fri, 18 Jun 2004 15:01:36 -0700 (PDT)
Received: from localhost (mrc@localhost) by Ikkoku-Kan.Panda.COM id PAA13576; Fri, 18 Jun 2004 15:01:34 -0700 (PDT)
Date: Fri, 18 Jun 2004 15:01:33 -0700 (PDT)
From: Mark Crispin <[email protected]>
Sender: [email protected]
To: [email protected]
cc: [email protected]
Subject: Re: FTPSER
In-Reply-To: <[email protected]>
Message-ID: <[email protected]>
References: <[email protected]>
Organization: Pandamonium Reigns
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed

On Fri, 18 Jun 2004 [email protected] wrote:
> 1) Top-level commands DEBUG, CRASH, BOMB removed (moved to SITE)

I don't think that CRASH and BOMB should exist at all, especially not
without the SC%WHL test that DEBUG has.

>   c) DDT (does the obvious thing if you are logged in and an enabled
>      wheel).  Fixed so the server client process does not hang.

How does this differ from DEBUG?

> The NLST/LIST/STAT code in FTPSER seems a little too convoluted for
> me.  I am probably going to just flush it all and do a rewrite.

Sounds good.

-- 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.
18-Jun-2004 16:54:56-PDT,1881;000000000000
Return-Path: <[email protected]>
Received: from YALLA.kz.kz ([82.182.137.68]) by lingling.panda.com with TCP/SMTP; Fri, 18 Jun 2004 16:43:26 -0700 (PDT)
Received: from kz.kz (DHCP-100 [192.168.0.100])
       by YALLA.kz.kz (8.9.2/) with ESMTP id BAA96147
       for <[email protected]>; Sat, 19 Jun 2004 01:34:41 +0200 (CEST)
       (envelope-from [email protected])
Message-ID: <[email protected]>
Date: Sat, 19 Jun 2004 01:45:36 +0200
From: Klaus Zeuge <[email protected]>
Reply-To: TOPS-20 Hackers and Yackers <[email protected]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7b) Gecko/20040421
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: TOPS-20 Hackers and Yackers <[email protected]>
Subject: Re: Whither FTPSER?
References: <[email protected]> <[email protected]>
In-Reply-To: <[email protected]>
Content-Type: text/plain; charset=ISO-8859-15; format=flowed
Content-Transfer-Encoding: quoted-printable

Bjorn Victor wrote:

> You may have larger hands than me ;-), but I believe there were more
> than a handful only in Sweden (2 in Uppsala, 3-5 or so in Stockholm
> (not counting Peter's), 2-3 in Link=F6ping).



In Link=F6ping, Sweden, one DEC-20 (Lisbet) had TCP/IP and DECnet.
Three others (Linux, Linnea, eLinor) didn't have TCP/IP, but they
had DECnet. After logging in on Lisbet, you could continue from
TCP/IP-land to DECnet-land and vice versa.

Later, an Ultrix box (Elrond) had a public service for connecting
TELNET with CTERM and FTP to the DECnet-counterpart. This box did
not require you to log in.

There also was email gatewaying between the TCP/IP and DECnet
worlds.

In Uppsala, Sweden, the two DEC-20's both had TCP/IP and DECnet.

In Stockholm, there were quite a few DEC-20 and DEC-10, still not
counting Peters machines.

       Klaus


18-Jun-2004 20:14:46-PDT,2616;000000000000
Return-Path: <[email protected]>
Received: from mta1.srv.hcvlny.cv.net ([167.206.5.67]) by lingling.panda.com with TCP/SMTP; Fri, 18 Jun 2004 20:02:53 -0700 (PDT)
Received: from optonline.net (mstr3.srv.hcvlny.cv.net [167.206.5.14])
by mta1.srv.hcvlny.cv.net
(iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar  3 2004))
with ESMTP id <[email protected]>; Fri,
18 Jun 2004 23:02:56 -0400 (EDT)
Received: from [167.206.5.80] (Forwarded-For: [24.47.51.196])
by mstr3.srv.hcvlny.cv.net (mshttpd); Fri, 18 Jun 2004 23:02:40 -0400
Date: Fri, 18 Jun 2004 23:02:40 -0400
From: [email protected]
Subject: Re: FTPSER
To: Mark Crispin <[email protected]>
Cc: [email protected]
Message-id: <[email protected]>
MIME-version: 1.0
X-Mailer: iPlanet Messenger Express 5.2 HotFix 1.25 (built Mar  3 2004)
Content-type: text/plain; charset=us-ascii
Content-language: en
Content-transfer-encoding: 7BIT
Content-disposition: inline
X-Accept-Language: en
Priority: normal

> > 1) Top-level commands DEBUG, CRASH, BOMB removed (moved to SITE)

> I don't think that CRASH and BOMB should exist at all, especially
> not without the SC%WHL test that DEBUG has.

It would appear that they were there for testing purposes.  But, I was
wondering why they would still be sticking around in a 'production'
program.  History??  Well, I'm probably going to punt them...

However, I believe that some sort of similar (yet superior)
functionality might be appropriate.  Galaxy based programs have a nice
crash feature.  If something that uses GLXLIB gronks, then they write
a crash file with the stack and registers saved so that you can poke
around later.  Something like what the MONITR/FILDDT combo can do.

I think that I should put in a SITE DUMP command.  It would need
enabled wheel to work.  DUMP OFF would mean crashes would just cause
FTPSER to exit (current behavior).  DUMP ON would mean that you'd get
a crash dump file ala GLXLIB.  DUMP SNAP would mean that you would
save the currently running image and continue running.  DUMP NOW would
mean that you'd do a crash dump and exit.

> >   c) DDT (does the obvious thing if you are logged in and an enabled
> >      wheel).  Fixed so the server client process does not hang.

> How does this differ from DEBUG?

It doesn't.  Since it is a SITE specific command, I wanted the name of
the winning site specific debugging tool.  I believe that I am going
to reserve the DEBUG name for debugging protocol negotiations (I don't
know exactly what that means, yet).


29-Jun-2004 14:18:57-PDT,4569;000000000000
Return-Path: <[email protected]>
Received: from sunshine.math.utah.edu ([128.110.198.2]) by lingling.panda.com with TCP/SMTP; Tue, 29 Jun 2004 14:05:43 -0700 (PDT)
Received: from psi.math.utah.edu (IDENT:[email protected] [155.101.96.19])
       by sunshine.math.utah.edu (8.12.11/8.12.10) with ESMTP id i5TL5fkv009448;
       Tue, 29 Jun 2004 15:05:41 -0600 (MDT)
Received: from psi.math.utah.edu (IDENT:wEDCccHSaWF/XEp+z+VzjJ1JvN0BrkCt@localhost [127.0.0.1])
       by psi.math.utah.edu (8.12.11/8.12.10) with ESMTP id i5TL5fPO012928;
       Tue, 29 Jun 2004 15:05:41 -0600 (MDT)
Received: (from beebe@localhost)
       by psi.math.utah.edu (8.12.11/8.12.10/Submit) id i5TL5fGT012926;
       Tue, 29 Jun 2004 15:05:41 -0600 (MDT)
Date: Tue, 29 Jun 2004 15:05:41 -0600 (MDT)
From: "Nelson H. F. Beebe" <[email protected]>
To: Tops-20 Wizards <[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: [TOPS-20] Emacs' birthday: seeking some history
Message-ID: <[email protected]>

Folks, I'm reposting this query just sent to to emacs developers to
the private list for TOPS-20 folks, many of whom were/are, like me,
devotees of emacs.

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

Date: Tue, 29 Jun 2004 15:02:09 -0600 (MDT)
From: "Nelson H. F. Beebe" <[email protected]>
To: [email protected]
Cc: [email protected]
Subject: Emacs' birthday: seeking some history

According to the article

       Richard M. Stallman
       EMACS: The Extensible, Customizable, Self-Documenting Display Editor
       in David R. Barstow and Howard E. Shrobe and Erik Sandewall,
       Interactive Programming Environments
       McGraw-Hill 1984

emacs was born in 1974.

That means that this year, it turns/turned 30.  But when?

rms's article did not provide an exact date for emacs' birth, but 30
is a nice round number, and emacs is important enough, that it/she/he
deserves recognition, and, I hope, a celebratory birthday T-shirt, at
the very least.

I'll bet that we could commission Duane Bibby to create a suitable
design; besides his great work in the TeX community, he also
illustrated Lugaru Software's book for the Epsilon editor.  Epsilon
was modeled on emacs, but ran on PC DOS, and had its own extension
language, EEL (Epsilon Extension Language), which was C-like, rather
than Lisp- or TECO-like.

A Web search turned up the PDP-10 archives at

       http://pdp-10.trailing-edge.com/

but the oldest date that I could spot in the listing at

       http://pdp-10.trailing-edge.com/mit_emacs_170_teco_1220/index.html

is for

---    1     2077  7 777742 Dec 15 19:13:54 1978 info:efork.info.1

The PDP-10 emacs kernel was in Midas (assembly language): a search of
*.mid files turned up

       <CPML-MARK>TNXDFS.MID.2    14-Apr-77 01:29:59    TECO'd by CPML-MARK

but teco.mid's earlist internal date is 27-Sep-83, where it says:

       ;<EMACS162>TECO.MID.118019, 27-Sep-83 23:10:54, Edit by LOUGHEED
       ; How about we start an edit history for changes at Stanford?
       ...
       ; The "standard Stanford EMACS" was version 165 for the last decade.  This was
       ; Bill Westfield's version, which used TEXTI% for input.  It diverged from the
       ; other Stanford stream after edit 118030; only comments after that are
       ; retained here.

So, someone excised a whopping big chunk of our history in that edit,
sigh...

I have my own archive of my *.emacs files (in TECO); their internal
dates run from 23-Aug-80 to 20-Jan-88 (our DEC-20/60 was retired on
Halloween, 1990).  I started on the DEC-20 in late September 1978, but
didn't start using emacs until sometime in the following year.

Can anyone shed further light on this history, or at least find
evidence of timestamps back in 1974?

-------------------------------------------------------------------------------
- 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  -
-------------------------------------------------------------------------------
29-Jun-2004 15:32:34-PDT,3843;000000000000
Return-Path: <[email protected]>
Received: from Ikkoku-Kan.Panda.COM (panda.com [206.124.149.114]) by lingling.panda.com with TCP/SMTP; Tue, 29 Jun 2004 15:24:03 -0700 (PDT)
Received: from localhost (mrc@localhost) by Ikkoku-Kan.Panda.COM id PAA21008; Tue, 29 Jun 2004 15:24:00 -0700 (PDT)
Date: Tue, 29 Jun 2004 15:23:59 -0700 (PDT)
From: Mark Crispin <[email protected]>
Sender: [email protected]
To: "Nelson H. F. Beebe" <[email protected]>
cc: Tops-20 Wizards <[email protected]>
Subject: Re: [TOPS-20] Emacs' birthday: seeking some history
In-Reply-To: <[email protected]>
Message-ID: <[email protected]>
References: <[email protected]>
Organization: Pandamonium Reigns
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed

On Tue, 29 Jun 2004, Nelson H. F. Beebe wrote:
> According to the article
>       Richard M. Stallman
>       EMACS: The Extensible, Customizable, Self-Documenting Display Editor
>       in David R. Barstow and Howard E. Shrobe and Erik Sandewall,
>       Interactive Programming Environments
>       McGraw-Hill 1984
> emacs was born in 1974.

If Stallman is accurately quoted, he is referring to the predecessors of
EMACS.

EMACS did not exist prior to the end of 1976.

Prior to EMACS, there were two popular TECO macro packages in use at the
MIT AI Lab: TECMAC and TMACS.  For those of the Hegelian bent, TMACS was
the antithesis to TECMAC, and EMACS was the synthesis.  Although
discussions about this synthesis began in the summer of 1976 (IIRC Guy
Steele instigated it), EMACS didn't show up until around December of 1976.

ITS TECO was always a display editor, similar to the TOPS-20 "TV" TECO
program.  In effect, TV came around full circle, from an early ITS TECO
converted to TOPS-10 and stripped of display features, to Tenex TECO, and
then to TV.

ITS TECO was further extended by the addition of "real-time editing mode"
which was entered with the ^R command.  Stallman once told me that he
added it to ITS TECO as a result of a visit to the Stanford AI Lab and
seeing its E editor in action.  I don't have any reason to disbelieve it
other than Stallman's natural tendency to trumpet his own contributions
at the expense of others.

^R mode was rather primitive, with only the most basic editing commands:
^A, ^B, ^D, ^E, ^F, ^K, ^L, ^N, ^O, ^P, ^V and of course self-insert of
text and whitespace characters.  Since it was possible to bind TECO macros
to characters in ^R mode, macro packages rapidly developed to extend the
environment.

TECMAC was more oriented towards creating more keys to do things, e.g.
making ^S be incremental search.  A popular additional extension was to
make the META key be "word" for any command in which CONTROL was
"character" (e.g. if CONTROL F moved forward a character then META F would
move forward a word), and CONTROL+META would act on a sentence.

TMACS was more oriented towards giving you named functions that you called
via the "M" TECO macro, e.g. "MM Blurdybloop" would do the "Blurdybloop"
function.  I used TECMAC so I don't remember much about TMACS.

Anyway, EMACS was definite the fusion of these two.

IIRC much of the early work was done by Guy Steele and David Moon, but
Stallman quickly took it over.

You can thank me for the idea that ^X^R, ^X^W, etc. prompt you for a
filename instead of throwing you in a minibuffer with an MM macro call to
do the action with the cursor placed at where you would type the file
name.  I nagged Stallman at some length to do 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.
29-Jun-2004 16:25:39-PDT,2036;000000000000
Return-Path: <[email protected]>
Received: from mv.opost.com ([199.125.75.195]) by lingling.panda.com with TCP/SMTP; Tue, 29 Jun 2004 16:17:37 -0700 (PDT)
Received: from road.fpl (road.fpl [172.22.41.6])
       by mv.opost.com (8.12.8/8.12.8) with ESMTP id i5TNHNO8027391
       for <[email protected]>; Tue, 29 Jun 2004 19:17:23 -0400
Received: from road.fpl (localhost [127.0.0.1])
       by road.fpl (8.12.10/8.12.10) with ESMTP id i5TNHMSV005144
       for <[email protected]>; Tue, 29 Jun 2004 19:17:22 -0400
Received: (from dlm@localhost)
       by road.fpl (8.12.10/8.12.10/Submit) id i5TNHMke005142
       for [email protected]; Tue, 29 Jun 2004 19:17:22 -0400
Date: Tue, 29 Jun 2004 19:17:22 -0400
Message-Id: <[email protected]>
From: Dan Murphy <[email protected]>
To: [email protected]
Subject: Birthdays [was: Emacs' birthday]
Reply-To: Dan Murphy <[email protected]>
X-OpostMailScanner-Information: Please contact the ISP for more information
X-OpostMailScanner: Found to be clean


   While we are noting birthdays, I could note that the birthday of
   TECO is sometime in late 1962 - early 1963.  Alas, I seem to have
   lost my file of TECO memorabilia from the early days which would
   provide more specific dates.

   A good birthday for TENEX would be June 15, 1970 as recorded in
   the contemporaneous memo on http://tenex.opost.com/


   -d


=====================

   Mark Crispin <[email protected]> on Tue, 29 Jun 2004 15:23:59 -0700 (PDT) writes:

> On Tue, 29 Jun 2004, Nelson H. F. Beebe wrote:
> > According to the article
> >     Richard M. Stallman
> >     EMACS: The Extensible, Customizable, Self-Documenting Display Editor
> >     in David R. Barstow and Howard E. Shrobe and Erik Sandewall,
> >     Interactive Programming Environments
> >     McGraw-Hill 1984
> > emacs was born in 1974.

> If Stallman is accurately quoted, he is referring to the predecessors of
> EMACS.

> EMACS did not exist prior to the end of 1976.
1-Jul-2004 22:27:45-PDT,2396;000000000000
Return-Path: <[email protected]>
Received: from mta10.srv.hcvlny.cv.net ([167.206.5.85]) by lingling.panda.com with TCP/SMTP; Thu, 1 Jul 2004 22:16:50 -0700 (PDT)
Received: from optonline.net (mstr3.srv.hcvlny.cv.net [167.206.5.14])
by mta10.srv.hcvlny.cv.net
(iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar  3 2004))
with ESMTP id <[email protected]> for
[email protected]; Fri, 02 Jul 2004 01:16:29 -0400 (EDT)
Received: from [167.206.5.73] (Forwarded-For: [24.184.174.68])
by mstr3.srv.hcvlny.cv.net (mshttpd); Fri, 02 Jul 2004 01:16:22 -0400
Date: Fri, 02 Jul 2004 01:16:22 -0400
From: [email protected]
Subject: The correct way to load a 30 bit address of a local symbol
To: Tops-20 Wizards <[email protected]>
Message-id: <[email protected]>
MIME-version: 1.0
X-Mailer: iPlanet Messenger Express 5.2 HotFix 1.25 (built Mar  3 2004)
Content-type: text/plain; charset=us-ascii
Content-language: en
Content-transfer-encoding: 7BIT
Content-disposition: inline
X-Accept-Language: en
Priority: normal

I've been spending some time hacking up a version of FTPSRV that I am
largely rewriting from scratch.  I am using extended addressing and
PSECT's.  I recently ran into some interesting behavior.

I was looking to load a 30 bit address into an accumulator to do some
page arithmatic.  When the address is external and resolved by LINK,
then I get the section number.  Otherwise, I do not.  Consider the
following definitions:

File 1:

IFNDEF HLPORG,<HLPORG==2,,1000> ;data on page 2001
       INTERN HLPBEG           ; Allow file 2 to reference this
       .PSECT HELP,HLPORG
HLPBEG:                         ; Beginning of help area


File 2:

IFNDEF CODORG,<CODORG==1,,002000> ; code begins on page 1002
       EXTERN HLPBEG               ; INTERNed in File 1:
       .PSECT CODE,CODORG      ; pure code.  pure Heaven.
CODEBG:                         ; Beginning of read only code

The following code loads T1 with 2000 and T2 with 2,1000.  I would
have expected 1,2000 in T1.  It looks like T2 got the right thing.

      MOVE T1,[CODEBG]     ; Address of beginning  of code
       MOVE T2,[HLPBEG]            ; Address of beginning and end of help text


So the external address that is filled in by Link appears to work.
What about the addresses that are local to File 2?


1-Jul-2004 23:46:11-PDT,1140;000000000000
Return-Path: <[email protected]>
Received: from Ikkoku-Kan.Panda.COM (panda.com [206.124.149.114]) by lingling.panda.com with TCP/SMTP; Thu, 1 Jul 2004 23:38:02 -0700 (PDT)
Received: from Ikkoku-Kan.Panda.COM (Ikkoku-Kan.Panda.COM [192.107.14.50]) by Ikkoku-Kan.Panda.COM id XAA22588; Thu, 1 Jul 2004 23:37:59 -0700 (PDT)
Date: Thu, 1 Jul 2004 23:30:46 -0700 (PDT)
From: Mark Crispin <[email protected]>
Sender: Mark Crispin <[email protected]>
Subject: re: The correct way to load a 30 bit address of a local symbol
To: [email protected]
cc: Tops-20 Wizards <[email protected]>
In-Reply-To: <[email protected]>
Message-ID: <[email protected]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII

It's not external addresses; it's in-section addresses.  Consider the
following:

CODORG==1,,2000
DATORG==2,,4000

       .PSECT DATA,DATORG
BAR:    1

       .PSECT CODE,CODORG
FOO:    SKIPA 1,.+1
        FOO
       SKIPA 2,.+1
        BAR

FOO+1 contains 2000, whereas FOO+3 contains 2,,4000.

To load an in-section address as a GFIW, you need to use XMOVEI.

2-Jul-2004 00:00:49-PDT,2183;000000000000
Return-Path: <[email protected]>
Received: from cyteen.hactrn.net ([66.92.66.68]) by lingling.panda.com with TCP/SMTP; Thu, 1 Jul 2004 23:53:09 -0700 (PDT)
Received: from thrintun.hactrn.net (thrintun.hactrn.net [IPv6:2002:425c:4242:0:250:daff:fe82:1c39])
       (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
       (Client CN "thrintun.hactrn.net", Issuer "Grunchweather Associates" (verified OK))
       by cyteen.hactrn.net (Postfix) with ESMTP id 36A1048A;
       Fri,  2 Jul 2004 02:53:06 -0400 (EDT)
Received: from thrintun.hactrn.net (localhost [IPv6:::1])
       by thrintun.hactrn.net (Postfix) with ESMTP
       id 67B5D42B2; Fri,  2 Jul 2004 02:53:05 -0400 (EDT)
Date: Fri, 02 Jul 2004 02:53:05 -0400
From: Rob Austein <[email protected]>
To: [email protected]
Cc: Tops-20 Wizards <[email protected]>
Subject: Re: The correct way to load a 30 bit address of a local symbol
In-Reply-To: <[email protected]>
References: <[email protected]>
User-Agent: Wanderlust/2.10.1 (Watching The Wheels) Emacs/21.3 Mule/5.0 (SAKAKI)
MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen")
Content-Type: text/plain; charset=US-ASCII
Message-Id: <[email protected]>

I seem to recall that the trick is to force the address expression to
"go polish", ie, be flagged by the assembler as needing fixup by LINK.

The person I was in 1988 apparently understood this weirdness well
enough to write the following code fragment.  If you figure out what
it means, please tell me so we'll both know....


;XX:<CHIVES.BETA.SOURCE>GTDOM.MAC.159,  2-Sep-88 00:23:53, Edit by SRA
; Replace all uses of CALLX with a new macro, CALLXX, which does random
; arithmetic to force LINK to do the right thing via polish fixup.

; CALLXX is like CALLX but hairier because we want to generate .REL
; files that can be linked with any version of the monitor.
;
; NB: CALLXX depends on LINK evaluating the expression <0/0> as zero.
DEFINE CALLXX(FOO) <            ;; Polish to add section number to local addrs
       MOVE CX,[FOO!<<1-<<FOO&<-1,,0>>/<FOO&<-1,,0>>>>*<MSEC1,,0>>]
       CALL (CX)               ;; Index instead of indirect
>;DEFINE CALLXX
2-Jul-2004 09:48:47-PDT,3252;000000000000
Return-Path: <[email protected]>
Received: from toed.xkl.com ([192.94.202.46]) by lingling.panda.com with TCP/SMTP; Fri, 2 Jul 2004 09:39:23 -0700 (PDT)
Date: Fri, 2 Jul 2004 09:36:39 -0700
From: Ralph Gorin <[email protected]>
Subject: Re: The correct way to load a 30 bit address of a local symbol
To: [email protected]
cc: [email protected]
In-Reply-To: <[email protected]>
Reply-to: [email protected]
Message-ID: <[email protected]>

This is a well-known issue (one hesitates to call it a bug) in MACRO.

macro prefers to provide only 18-bit addresses.  it does so whenever
it can.  macro provides 30 bit addresses only when you force it to use
a polish fixup.

there are three common situations in which it will supply a polish
expression to link:

       1. External reference
       2. Cross-PSECT references
       3. Arithmetic references to externals

In the example given, the literal [HLPBEG] became 30 bits because
HLPBEG is external OR because HLPBEG is in a different PSECT.  (Note
that in the example, both are true, but either would be sufficient.)

In the example given, the literal [CODBEG] became 18 bits because
CODBEG is both local and in the same psect as the reference.  In the
"usual" case, e.g., JRST CODBEG, 18 bits would be sufficient for the
reference; this is what Macro provides.  If the author knows that the
symbol is both local and in the same PSECT as the reference, s/he can
write XMOVEI AC,CODBEG for the correct effect.

Finally, you can write [CODBEG+ZERO] where ZERO is external and
has a value that you might guess.   The arithmetic expression
forces Macro to ask for a polish fixup and the fixup will be
for an entire word.

Ralph

----------

Date: Fri, 02 Jul 2004 01:16:22 -0400
From: [email protected]
Subject: The correct way to load a 30 bit address of a local symbol
To: Tops-20 Wizards <[email protected]>

I've been spending some time hacking up a version of FTPSRV that I am
largely rewriting from scratch.  I am using extended addressing and
PSECT's.  I recently ran into some interesting behavior.

I was looking to load a 30 bit address into an accumulator to do some
page arithmatic.  When the address is external and resolved by LINK,
then I get the section number.  Otherwise, I do not.  Consider the
following definitions:

File 1:

IFNDEF HLPORG,<HLPORG==2,,1000> ;data on page 2001
       INTERN HLPBEG           ; Allow file 2 to reference this
       .PSECT HELP,HLPORG
HLPBEG:                         ; Beginning of help area


File 2:

IFNDEF CODORG,<CODORG==1,,002000> ; code begins on page 1002
       EXTERN HLPBEG               ; INTERNed in File 1:
       .PSECT CODE,CODORG      ; pure code.  pure Heaven.
CODEBG:                         ; Beginning of read only code

The following code loads T1 with 2000 and T2 with 2,1000.  I would
have expected 1,2000 in T1.  It looks like T2 got the right thing.

      MOVE T1,[CODEBG]     ; Address of beginning  of code
       MOVE T2,[HLPBEG]            ; Address of beginning and end of help text


So the external address that is filled in by Link appears to work.
What about the addresses that are local to File 2?


-------
4-Jul-2004 10:15:10-PDT,3741;000000000000
Return-Path: <[email protected]>
Received: from mta1.srv.hcvlny.cv.net ([167.206.5.67]) by lingling.panda.com with TCP/SMTP; Sun, 4 Jul 2004 10:04:35 -0700 (PDT)
Received: from optonline.net (mstr3.srv.hcvlny.cv.net [167.206.5.14])
by mta1.srv.hcvlny.cv.net
(iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar  3 2004))
with ESMTP id <[email protected]>; Sun,
04 Jul 2004 13:04:37 -0400 (EDT)
Received: from [167.206.5.79] (Forwarded-For: [24.184.174.68])
by mstr3.srv.hcvlny.cv.net (mshttpd); Sun, 04 Jul 2004 13:04:10 -0400
Date: Sun, 04 Jul 2004 13:04:10 -0400
From: [email protected]
Subject: Re: The correct way to load a 30 bit address of a local symbol
To: Ralph Gorin <[email protected]>, Mark Crispin <[email protected]>
Cc: Tops-20 Wizards <[email protected]>
Message-id: <[email protected]>
MIME-version: 1.0
X-Mailer: iPlanet Messenger Express 5.2 HotFix 1.25 (built Mar  3 2004)
Content-type: text/plain; charset=us-ascii
Content-language: en
Content-transfer-encoding: 7BIT
Content-disposition: inline
X-Accept-Language: en
Priority: normal

Thanks for all the tips!  A number of points:

> MRC,
>
> To load an in-section address as a GFIW, you need to use XMOVEI.

There were a number of reasons that I wanted to load 30 bit addresses
with:

   DMOVE T1,[EXP FOO, BAR]
   DMOVE T3,[EXP GOO,BAZ]

   Instead of with:

   XMOVEI T1,FOO
   XMOVEI T2,BAR
   XMOVEI T3,GOO
   XMOVEI T4,BAZ

1) Two DMOVE's take 2 more words but (I believe) are faster than
   XMOVEI.  I am in a bit banger 12 step program, but I really
   haven't made much progress... :-)

2) I don't have to worry about what is external or not and write code
   appropriately.  MACRO and LINK can just handle it for me (like
   they do with 18 bit addresses).

3) Unless you are using indexing or indirection, XMOVEI doesn't work
   right for an address that is outside of the section in which it is
   executing.  For XMOVEI T1,FOO##, you get the wrong section and LINK
   says: "%LNKFTH Fullword value ACCT$ being truncated to halfword."

> Gorin,
>
> This is a well-known issue (one hesitates to call it a bug) in MACRO.

Well known??  Oh dear ...  I guess I had overlooked this; was it
documented anywhere?  My inclination was to call it more of a
'secret-feature' as it wasn't immediately obvious what MACRO's
strategy was.

For example, in order to allow to implement Unix (TVFS) semantics, I
needed FTPSER to be able to connect to a 'directory' file.  To do
this, I scanned for all sub-directories in the connected directory to
build a keyword table on the fly.  I did this by GTJFN% for all files
of type .DIRECTORY that had FB%DIR set in the FDB.  Once I had my
keyword table built (on the stack), I poked the address of it into an
COMND% FDB.  The following broke:

CWDHLP: ASCIZ /a subdirectory, / ;Prefix the directory file list
CWDKEY: <<FLD(.CMKEY,CM%FNC)>!CM%HPP!UPARSE>>
       0                       ; We'll fill this in at parse time
       POINT 7,CWDHLP          ; Pointer to help

       The following worked:

CWDHLP: ASCIZ /a subdirectory, / ;Prefix the directory file list
CWDKEY: <<FLD(.CMKEY,CM%FNC)>!CM%HPP!<<0,,-1>&UPARSE>>
       0                       ; We'll fill this in at parse time
       POINT 7,CWDHLP          ; Pointer to help

Although both CWDKEY and UPARSE are in the same section (1), CWDHLP is in
PSECT DATA while UPARSE (Unix parsing) is in .PSECT CODE.  As both of
these are declared in a single module, I expected 18 bit addresses.
Instead, .CMFNP got build with CM%SDH (bit 17) set, so my keyword
table never listed.

Because XMOVEI didn't complain about loading CWDKEY, I never suspected
anything was wrong ...


4-Jul-2004 11:39:59-PDT,1655;000000000000
Return-Path: <[email protected]>
Received: from Ikkoku-Kan.Panda.COM (panda.com [206.124.149.114]) by lingling.panda.com with TCP/SMTP; Sun, 4 Jul 2004 11:32:26 -0700 (PDT)
Received: from Ikkoku-Kan.Panda.COM (Ikkoku-Kan.Panda.COM [192.107.14.50]) by Ikkoku-Kan.Panda.COM id LAA24127; Sun, 4 Jul 2004 11:32:13 -0700 (PDT)
Date: Sun, 4 Jul 2004 11:13:06 -0700 (PDT)
From: Mark Crispin <[email protected]>
Sender: Mark Crispin <[email protected]>
Subject: Re: The correct way to load a 30 bit address of a local symbol
To: [email protected]
cc: Ralph Gorin <[email protected]>,
       Tops-20 Wizards <[email protected]>
In-Reply-To: <[email protected]>
Message-ID: <[email protected]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII

On Sun, 04 Jul 2004 13:04:10 -0400, [email protected] wrote:
> CWDKEY:       <<FLD(.CMKEY,CM%FNC)>!CM%HPP!UPARSE>>

That'll teach you to add/or in an unbounded field at B35.  Those "unnecessary"
masks are there in MONSYM for a reason.  The correct thing is:

CWDKEY: <FLD .CMKEY,CM%FNC>!CM%HPP!<FLD CM%LST,UPARSE>

I disapprove of the practice of assembling non-zero values into a DATA PSECT.
Better to do:
       .PSECT DATA
CWDKEY: BLOCK 3

       .PSECT CODE

       MOVX T1,<<FLD .CMKEY,CM%FNC>!CM%HPP!<FLD CM%LST,UPARSE>>
       MOVEM T1,CWDKEY+.CMFNP
       HRROI T1,[ASCIZ/a subdirectory, /]
       MOVEM T1,CWDKEY+.CMHLP

Or, better yet:
       .PSECT DATA

       MOVE T1,[CWDKYI,,CWDKEY]
       BLT T1,CWDKEY+CWDKYL-1
        . . .
CWDKYI: FLDDB. .CMKEY,,0,<a subdirectory, >,,UPARSE
CMDKYL==.-CWDKYX

       .PSECT CODE
CWDKEY: BLOCK CMDKYL

4-Jul-2004 11:47:26-PDT,473;000000000000
Mail-From: MRC created at  4-Jul-2004 11:39:09
Date: Sun, 4 Jul 2004 11:39:09 -0700 (PDT)
From: Mark Crispin <[email protected]>
Subject: time for an XCOMD%?
To: [email protected]
Pithy-Thought: TOPS-20 was a great improvement over its successors
Message-ID: <[email protected]>

Hmm.  So it turns out that a COMND% chain must be all in the same section.
I wonder if that means that it's time to add an XCOMD% JSYS?  :-)
-------
8-Jul-2004 08:59:35-PDT,2004;000000000000
Return-Path: <[email protected]>
Received: from mta4.srv.hcvlny.cv.net ([167.206.5.70]) by lingling.panda.com with TCP/SMTP; Thu, 8 Jul 2004 08:49:45 -0700 (PDT)
Received: from optonline.net (mstr3.srv.hcvlny.cv.net [167.206.5.14])
by mta4.srv.hcvlny.cv.net
(iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar  3 2004))
with ESMTP id <[email protected]>; Thu,
08 Jul 2004 11:49:41 -0400 (EDT)
Received: from [167.206.5.73] (Forwarded-For: [216.179.91.114])
by mstr3.srv.hcvlny.cv.net (mshttpd); Thu, 08 Jul 2004 11:49:09 -0400
Date: Thu, 08 Jul 2004 11:49:09 -0400
From: [email protected]
Subject: Re: time for an XCOMD%?
To: Mark Crispin <[email protected]>
Cc: [email protected]
Message-id: <[email protected]>
MIME-version: 1.0
X-Mailer: iPlanet Messenger Express 5.2 HotFix 1.25 (built Mar  3 2004)
Content-type: text/plain; charset=us-ascii
Content-language: en
Content-transfer-encoding: 7BIT
Content-disposition: inline
X-Accept-Language: en
Priority: normal

Funny you should mention that.  I was noodling over it a
few months ago when I needed to remember some stuff
regarding binary sorting.

TEXTI% would need some minor tweaking.
TBLUK%, TBADD% and TBDEL% would need interface
changes and the format of the table would need to change.
TBLUK% uses a binary search, so excluding page faults,
the performance might not be terrible.

The prospect of a multiple section keyword table is humbling.
Applications include on line dictionaries and ?

It sounds like it might be fun and not that much work.  Maybe
I'll take a closer look once I get tired of The Great FTPSER
Rewrite.
----- Original Message -----
From: Mark Crispin <[email protected]>
Date: Sunday, July 4, 2004 2:39 pm
Subject: time for an XCOMD%?

> Hmm.  So it turns out that a COMND% chain must be all in the same
> section.I wonder if that means that it's time to add an XCOMD%
> JSYS?  :-)
> -------
>

9-Jul-2004 22:17:05-PDT,22584;000000000000
Return-Path: <[email protected]>
Received: from mta10.srv.hcvlny.cv.net ([167.206.5.85]) by lingling.panda.com with TCP/SMTP; Fri, 9 Jul 2004 22:04:48 -0700 (PDT)
Received: from optonline.net (mstr3.srv.hcvlny.cv.net [167.206.5.14])
by mta10.srv.hcvlny.cv.net
(iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar  3 2004))
with ESMTP id <[email protected]> for
[email protected]; Sat, 10 Jul 2004 01:04:08 -0400 (EDT)
Received: from [167.206.5.73] (Forwarded-For: [24.184.174.68])
by mstr3.srv.hcvlny.cv.net (mshttpd); Sat, 10 Jul 2004 01:04:01 -0400
Date: Sat, 10 Jul 2004 01:04:01 -0400
From: [email protected]
Subject: EFTPSR
To: [email protected]
Message-id: <[email protected]>
MIME-version: 1.0
X-Mailer: iPlanet Messenger Express 5.2 HotFix 1.25 (built Mar  3 2004)
Content-type: text/plain; charset=us-ascii
Content-language: en
Content-transfer-encoding: 7BIT
Content-disposition: inline
X-Accept-Language: en
Priority: normal

I've done bit of work rewriting FTPSER which (for lack of creativity)
I now call EFTPSR.  I guess I am about 1/3 done with everything that I
hope to accomplish, so I thought that I would drop some email about
it.

All of the RFC959 parsing logic is finished and the initial part of
the TVFS (Unix) has been coded.  I'll probably have working (non-
paged) transfer logic up in about another month and believe I'll have
TVFS shortly afterwards.  The following commands are implemented:

   ACCT  ALLO  CDUP  CWD   DELE  HELP  MDTM  MODE  NOOP
   PASS  PORT  PWD   QUIT  REIN  RNFR  RNTO  SITE  SIZE
   SMNT  STRU  SYST  TYPE  USER

The following commands remain to be implemented.  Note that these all
involve data transfer.

   ABOR  APPE  FEAT  LIST  MRCP  MSAM  MSND  MSOM
   NLST  PASV  REST  RETR  RLST  RSTA  STAT  STOR

Highlights:

0) More complete implementation of RFC959, plus additional
   enhanced commands.

1) Completely rewritten command interface using COMND%.  Extensive
   built in help and documentation.

   When not running as a top level fork, EFTPSR will allow command
   recognition and reparsing.  Otherwise, a reparse is reported as an
   error (normal case for server operation)

2) Multiple section program to allow for extensive future growth
   (i.e., Unicode) and high performace.

3) Multiple fork design, with all data transfer being done by a
   inferior fork under the rabbinical supervision of the main COMND%
   fork on the control channel.

4) Tenex specific code removed.  The program will now only execute on
   a model B CPU or higher.

5) Extensive work done to handle testing, performace and simulation
   (greater implementation of NUL: semantics).  Overall attempts at
   De-cruftification.

General To Do:

A) Transfer logic must be written.  This will be done in a completely
   seperate fork to allow for asynchronous transfer, better
   monitoring and full implementation of the ABOR command.

B) TVFS file space simulation remains to be completed.

C) ANONYMOUS must be implemented.

D) NOT-LOGGED-IN restrictions.  The server currently makes no attempt
   whatsoever to restrict actions based on whether somebody is logged
   in or not.  It depends on Tops-20 to prevent access.

   I wanted to see what you could actually do if you are not logged
   in.  You can do more than I thought, so I will need to restrict
   the command set and actions here.

E) Bullet proofing.

The rest of this letter contains details of the implementation.

Modules:

1) EFTPSU - Universal symbols and linkages
2) EFTPSZ - .PSECT and reverse polish definitions
3) EFTPSH - (extensive) Help text and documentation (section 2)
4) EFTPSS - SITE local commands (section 1)
5) EFTPSV - TVFS support (Unix file simulation) (section 1)
6) EFTPSR - Main program parsing and control logic (section 1)
7) EFTPST - Transfer functions (seperate fork) [unwritten]
8) Symbols and Patch area are in section 37 with XDDT

Command Changes and Enhancements:

ALLO
====

Essentially unimplemented in FTPSER.  The ALLO command now determines
the current free space on the structure, working quota and permanent
quota of the current working directory.  If the requested allocation
exceeds any of these quanities, then the server notifies the client.
Quota checks are disregared for an enabled WHEEL or OPERATOR

Otherwise, it acknowledges the request under the hope that the later
storage command will succeed.  This probably is NOT a good assumption
for a structure that is at near capacity because the algorithm does
NOT take index page and other file system overhead into consideration.

If the user connects to another directory and/or another filesystem,
then the response of this command will probably be, at best,
misinformed.

When connected to the NUL: device, the ALLO command sets the size of
the file being transfered from NUL: for future transfers.  The default
size for a NUL: transfer, unless otherwise specified, is zero.

To Do:

Generate a random file name and REALLY allocate the storage.  Set the
file with the ;T parameter to make sure it is tossed if is not used.
Should also record directory that the allocate happened in and then
toss the file if we are someplace else?  Parse the odd R second
parameter and maybe do something with it.  Use the TYPE L parameter to
determine how many pages.  Maybe the ALLO could restrict the size of
the transfer to NUL:?


CDUP
====

Modified to handle the idea of connecting to NUL:.  A CDUP on NUL:
always puts you back into NUL:


CWD
===

The following are now valid arguments for CWD:

1) CWD <CR> {blank line} connects to the user's login directory.

2) CWD user-name <CR> will parse for a user name and, on success,
  will connect to that user's login directory.

3) CWD directory <CR> functions as expected.

4) CWD NUL: <CR> will force any future file specification with a
  non-explicit device to default to NUL:

5) CWD file-name <CR> will parse for a file name in the current
  connected directory and see if that is a directory.  If the file
  name IS a directory, then EFTPSR will take the current connected
  directory and append the file name to the directory string.  A
  connection attempt will be made to that particular subdirectory.

  I.E., suppose directory file BAR.DIRECTORY.1 exists in directory
  <FOO>.  If you are connected to <FOO>, then CWD BAR puts you in
  <FOO.BAR>.  Note that NO attempt is made to try to make CWD
  <FOO>BAR.DIRECTORY.0 work as CWD <FOO.BAR>.  The code is ONLY for
  the connected directory!

  Actually, this isn't quite true.  CWD doesn't parse for an
  arbitrary file specification.  A GNJFN% is done on all
  *.DIRECTORY.* files in the current directory.  Those candidates
  that have FB%DIR set have their file names added to a TBLUK% table
  that is dynamically built on the stack.  Directory name keywords
  are then recognized as valid places to connect.


6) TVFS dot "." and ".." directory file idioms are supported for
  Tops-20, even when TVFS has not been explicitly turned on.
  If they are encountered, however, then TVFS mode is enabled.

  "CWD ." re-connects to the current directory.  As automatic
  directory accessing is turned off by default, it may be
  necessary to reconnect to a directory after enabling it.

  "CWD .." connects to the directory's superior. It has exactly
  same semantic logic as CDUP.

  When connected to NUL:, "CWD ." and "CWD .." put you back in NUL:

Note that there is a possibility of conflict between a user name FOO
and a subdirectory file named FOO.  EFTPSR resolves this by always
picking the subdirectory file over the user name, if it exists.

If a failure occurs, then CWD tries to determine if a password would
cure the problem.  If so, it will ask for a PASS from the FTP client.
The code here models the differed USER methodology.

Although EFTPSR may be waiting for a password to do a connect, it
allows other commands to be given before a PASS.  If one of these is
either another CWD or a CDUP which succeeds, then a following PASS
will be rejected.

To do:

Maybe it would be groovy to allow the directory specification to be
wildcarded.  That would allow for abbreviations ala Unix and DOS (cd
foo*bar gets you to foo.thomas.bar).  Under Tops-20, connecting to a
directory can give you access to that directory's group lists.  This
is currently not done by default.  Is automagic the correct thing?


DELE
====

TVFS dot "." and ".." directory file idioms are supported for Tops-20,
even when TVFS has not been explicitly turned on.  If they are
encountered, however, then TVFS mode is enabled.  Both "DELE ." and
"DELE .." fail because it is illegal to delete a directory FILE under
Tops-20.

Unless specified, only the latest generation is deleted.  Deleted
files are not expunged until logout time.  I currently do not allow
wildcards.  As a consequence, "." nor ".."  can NOT be used as a
synonym for 'all files in a directory'.

You can delete NUL: and anything on it as much as you want.  NUL:
doesn't go away, however.

To do:

Do a SITE UNDELETE command.  Figure out why the old code in FTPSER
appears to have used .GJLEG to remove the lowest existing file
generation?

What about wildcards?


HELP
====

With no arguments, lists the contents of the main TBLUK% table so that
an accurate and up to date listing of keywords is always displayed.
Extensive written documentation for each command.

To do:

Implement self documenting code.  :-)


MDTM
====

The MDTM command is not currently part of any official RFC that I was
able to determine.  It is used by the gnuEmacs ange-ftp package in
order to not have to parse directory listing strings from foreign
systems.  This apparently makes coding of the package easier, but
obviously makes for more network traffic.  This used to be a big
deal...

MDTM returns the last modification time of the file as an ASCII string
of the following form: YYYYMMDDhhmmss, in which YYYY is a Y2K
compatible year, MM is the month ("01" is January), DD is the day in
the month ("01" is the first), hh is the 24 hour of the day (starts at
"00" and ranges to "23"), mm is the 60 minute portion of the hour
(starts at "00" and ranges to "59") and ss is the 60 second portion of
the minute (starts at "00" and ranges to "59")

Note that the returned time is listed in GMT, not local!

TVFS dot "." and ".." directory file idioms are supported for Tops-20,
even when TVFS has not been explicitly turned on.  If they are
encountered, however, then TVFS mode is enabled.

"MDTM ." returns the last login time of the connected directory.
"MDTM .." returns the boot time of the system when issued while
 connected to a top-level directory, otherwise it functions as
 "MDTM ." for the superior directory.

Note that when the server is running in Trivial Virtual File System
(TVFS) mode, there is the possibility that the returned time may not
be entirely correct.  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:    1-JAN-1970 00:00:00-GMT    19-JAN-2038 02:14:07-GMT

Because of this, the server will clip any date which falls outside
of this range when in TVS mode.

When connected to NUL:, "MDTM ." returns the current time of day.
"MDTM .." returns the time that EFTPSR was started (and thus
created its local instantiation of the NUL: device).

Responses are modeled from responses from actual implementations.

To do:

Most directories can not be logged-in to.  Thus the result for "MDTM
" is almost entirely useless.  It would be nice if we could get the
last modification time on the directory (like the last CRDIR% done on
it), but Tops-20 doesn't seem to update this and you can't always
count on being able to get a JFN on a directory file.  What else would
be good?  What is a good time to return on a structure?  Can't seem to
get the mount time, although MOUNTR could know this.


PASS
====

Internal interface cleaned up and generalised  so that any command can
request a password (such as for accessing a directory).


PWD
===

When 'connected' to NUL:,all transfers which do not specify a device
default to NUL:.  I simply print NUL: as the connected directory.  The
code, as implemented here, nearly exactly reproduces what a Unix
machine would type if it had a winning Tops-20 file system.


QUIT
====

To do:

More useful logout message.  "221 QUIT command received. Goodbye." is
nice but ... "221 BCNU" was cute ...


REIN
====

Unimplemented in FTPSER.  Reinitialize (REIN) terminates the USER
user, flushing all I/O and information, except to allow any transfer
in progress to be completed.  All parameters are reset to the default
settings and the control connection is left open.  This is identical
to the state in which a user finds himself immediately after the
control connection is opened.  A USER command may be expected to
follow.

Be aware that RFC959 states that if there is a transfer in progress
that REIN MUST BE DIFFERED.  The code, as currently implemented,
simply jumps to the top level of the server.  If there is an
outstanding transfer, then a flag is set to cause us to reinitialize
after the transfer is done.  The RFC does not indicate whether other
commands are allowed in the control, so I allow them.

Finally, appears to be no immediately convenient way to set the status
of a job to be NOT LOGGED IN without breaking the NVT connection (the
REATT UUO under Tops-10 suggests itself).  Therefore, if a USER
command follows, I only allow the user to log back in as themselves.

To do:

Calculate the number of minutes to wait if in a transfer.  SITE
command to do a 'hard' reset (stomp everything, followed by a GET%)
Log out and keep the terminal with a new version of EFTPSR with
creative use of CRJOB%, DTACH%, SCTTY% and perhaps ATACH%.


RNFR  (Rename From)
====

Unless specified, only the latest generation is renamed.  I currently
do not allow wildcards.

TVFS dot "." and ".." directory file idioms are supported for Tops-20,
even when TVFS has not been explicitly turned on.  If they are
encountered, however, then TVFS mode is enabled.  Note that both "RNFR
" and "RNFR .." fail because it is illegal to rename a directory FILE
under Tops-20.

The server will complain if it gets a RNTO (rename to) without having
seen a RNFR (rename from) beforehand.  However, the server is NOT
completely compliant with RFC959 because it does not INSIST on getting
a RNTO as the next command immediately following the RNFR.

The reasons for this are to allow multiple attempts at a RNTO,
intervening commands (such as a PWD, CWD) and debugging.

To do:

Since the from-file specification is stored in absolute form, it
should always be possible to open it again, provided that the file
hasn't gone away.  However, an intervening CWD may or may not cause a
failure.  If the access rights change while changing directories, then
the user may lose access to the original file.

This could be fixed by keeping the RNFR file assigned to a JFN.  Then
an intervening CWD would not break the RNAMF%.  Verify that hanging on
to the JFN would actually work and not break stuff and isn't a bad
idea.

Maybe "RNFR ." and "RNFR .." should work for the entire contents of
the directory?  What about subdirectories?

What about wildcards, anyway?


RNTO (Rename To)
====

Unless specified, only the latest generation is renamed.  I currently
do not allow wildcards.  Tops-20 does not allow a rename across
structures.  I am not sure if TVFS will require me to simulate this (I
hope not).

TVFS dot "." and ".." directory file idioms are supported for Tops-20,
even when TVFS has not been explicitly turned on.  For "RNTO .", the
from-file is renamed into the current working directory.  For "RNTO
.", the from-file is renamed into the current working directory's
superior.  In both cases, the file is given the next highest
generation number.

The server will complain if it gets a RNTO (rename to) without having
seen a RNFR (rename from) beforehand.  However, the server is NOT
completely compliant with RFC959 because it does not INSIST on getting
a RNTO as the next command immediately following the RNFR.

This allows a RNFR, CWD and then a "RNTO ." to get the file into the
current dirctory

You can rename NUL: as many times as you want.  It keeps coming back.

To do:

Should RNTO <CR> mean the same thing as "RNTO ." (i.e., default to the
next highest generation in the current directory_?

What about wildcards?


SIZE
====

The SIZE command is not currently part of any official RFC that I was
able to determine.  It is used by the gnuEmacs ange-ftp package in
order to not have to parse directory listing strings from foreign
systems.  This apparently makes coding of the package easier, but
obviously makes for more network traffic.  This used to be a big
deal...

SIZE returns the size of the file in bytes.  Note that this may or MAY
NOT be correctly interpreted by the client.  As most 'modern' FTP
clients can no longer imagine anything but eight bit bytes, it is
doubtful that they would understand that a 200 byte file with 7 bit
bytes is smaller than a 41 byte file with 36 bit (i.e., full word)
bytes.

TVFS dot "." and ".." directory file idioms are supported for Tops-20,
even when TVFS has not been explicitly turned on.  If they are
encountered, however, then TVFS mode is enabled.

   "SIZE ." the current directory disk usage in PAGES
   "SIZE .." the superior directory disk usage in PAGES.

   When connected to a top level level directory, SIZE .. returns
   the amount of pages in use on the structure.

The size of the NUL: device is the amount set by the last ALLO
command.   It is the same for /nul/. and /nul/..

Note that Tops-20 stores numbers in a 36 bit word.  This is 4 bits
longer than many implementations of the C libary.  When running in TVS
mode, I clip any numbers that are larger than 2,147,483,647 to
2,147,483,647.

Responses are modeled from responses from actual implementations.

To do:

Should I convert the file size to total bits, divide by 8 and report
that?


SMNT
====

When mounting a structure that is already mounted, SMNT will succeed,
but will notify the user.  NUL: is special cased to always work.

Note that I do NOT mount structures by default and, when I do, I
do not try to access a directory on them by default.

To do:

SITE command to set up automatic mounting and accessing?  SITE command
to dismount a structure?

SITE
====

Many, many, many, many SITE local commands, a few of which are
actually implemented:

         DDT - invoke debugger, don't forget "DDT /Overlay /Use 37"
CAPABILITIES - Turn capabilities on or off
                 ON - turn them on
                OFF - shut them off
             STATUS - List current and possible capabilities
               <CR> - toggle current setting
    TRANSFER - Commands to effect current transfer
              PAUSE - Pause the data transfer (FFORK%)
             RESUME - Continues the data transfer (RFORK%)
              ABORT - eliminates (KFORK's) the data transfer
             STATUS - Fork status and position (also ^T)
               <CR> - same as STATUS
   ANONYMOUS - Allows anonymous access.  This is in a SYSTEM:EFTPSR.INI
                        which is parsed at program start up.
         [password] - ANONYMOUS login password
                OFF - turn it off
             STATUS - Whether currently allowed (and, if so, being used)
               <CR> - same as STATUS
        TIMER - shutoff time out (or set the time out)
               AUTO - synonym for ON
                 ON - turn it on
                OFF - turn it off
           [number] - timer interval
             STATUS - Status and time of last tick and last action
               <CR> - same as STATUS
         HELP - SITE keyword to describe (one of these)
         PUNT - Get rid of HELP and SYMBOL .PSECT's.  Used prior to CRASH.
         FROM - Display the parsed from-file name from RNFR.  Maybe
                try to open it, also.
    DISMOUNT - dismount a structure mounted with SMNT
    UNDELETE - Undelete a file deleted with DELE
     EXPUNGE - Really get rid of something.
               <CR> - Current connected directory
              <DIR> - A particular directory
             <FILE> - A particular file (which must already be deleted)
               NUL: - "What, me, worry?"
        CRASH - produce a crash file
         SEND - SEND a TTY message to a user
       STATUS - Display job number, terminal, user, connect time, CPU
                used, commands processed, data transfered (both
                ways), memory in use.
       PROMPT - Turn on command prompting, sets TTY
                 ON - turn it on
                OFF - turn it off
               <CR> - toggle current state
         NOOP - do nothing.
          CKM - Turn on directory annotation
                 ON - turn it on
                OFF - turn it off
               <CR> - toggle current state
       ACCESS - Access a directory
               AUTO - access a directory on connect
                 ON - turn it on
                OFF - turn it off
               <CR> - toggle current state
          DIRECTORY - parses for a directory and accesses it (may need PASS)
         TVFS - Turn on Trivial Virtual File System
               AUTO - figure it out [default]
                 ON - turn it on
                OFF - turn it off
               LOCK - never allow it on
               <CR> - toggle current state
          DIRECTORY - parses for a directory and returns a directory
               FILE - parses for a file and returns a directory and
                       (inverse from Tops20 to TVFS)


10-Jul-2004 19:38:28-PDT,950;000000000000
Return-Path: <[email protected]>
Received: from Ikkoku-Kan.Panda.COM (panda.com [206.124.149.114]) by lingling.panda.com with TCP/SMTP; Sat, 10 Jul 2004 19:29:28 -0700 (PDT)
Received: from Ikkoku-Kan.Panda.COM (Ikkoku-Kan.Panda.COM [192.107.14.50]) by Ikkoku-Kan.Panda.COM id TAA28911; Sat, 10 Jul 2004 19:29:25 -0700 (PDT)
Date: Sat, 10 Jul 2004 19:27:22 -0700 (PDT)
From: Mark Crispin <[email protected]>
Sender: Mark Crispin <[email protected]>
Subject: re: EFTPSR
To: [email protected]
cc: [email protected]
In-Reply-To: <[email protected]>
Message-ID: <[email protected]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII

Comment about not-logged-in EFTPSR:

Suggest that EFTPSR be split in two: one module for not-logged-in and one for
logged in, and switch at login time.

That way the dangerous not-logged-in code can be minimized.

11-Jul-2004 14:26:45-PDT,2813;000000000000
Return-Path: <[email protected]>
Received: from mta8.srv.hcvlny.cv.net ([167.206.5.75]) by lingling.panda.com with TCP/SMTP; Sun, 11 Jul 2004 14:16:05 -0700 (PDT)
Received: from optonline.net (mstr3.srv.hcvlny.cv.net [167.206.5.14])
by mta8.srv.hcvlny.cv.net
(iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar  3 2004))
with ESMTP id <[email protected]>; Sun,
11 Jul 2004 17:16:02 -0400 (EDT)
Received: from [167.206.5.71] (Forwarded-For: [24.184.174.68])
by mstr3.srv.hcvlny.cv.net (mshttpd); Sun, 11 Jul 2004 17:15:32 -0400
Date: Sun, 11 Jul 2004 17:15:32 -0400
From: [email protected]
Subject: Re: re: EFTPSR
To: Mark Crispin <[email protected]>
Cc: [email protected]
Message-id: <[email protected]>
MIME-version: 1.0
X-Mailer: iPlanet Messenger Express 5.2 HotFix 1.25 (built Mar  3 2004)
Content-type: text/plain; charset=us-ascii
Content-language: en
Content-transfer-encoding: 7BIT
Content-disposition: inline
X-Accept-Language: en
Priority: normal

I agree.  Funny you should say that:

The memory foot print of the old FTPSER is laid out something very
much like a Tops-10 program.  When you are NOT logged in, it
essentially punts the 'high segment' so that you can't do much of
anything besides sign on.  Once you are logged in however, it turns
the 'high segment' back on with SPACS% (not with a GETSEG UUO :-) so
you can then do your thing.

I was planning on doing something similar (but possibly more cleanly
and perhaps more elegantly) with .PSECTs.  I was toying with the idea
of putting the login code in section 0 and shutting off access from
there with an SMAP% until sucessful sign on.

I'm guessing that it is faster to turn a section on and off with SMAP%
than to sit in a loop with SPACS% over a bunch of pages.  I was
thinking that having the login stuff in section 0 might make it harder
for it to accidently clobber (or exploit) stuff in the other sections.

It's something that I am leaving until after I get most of the code
done because I have some vague feeling that it would be best to leave
PSECT tweaking until then.

If it gets to be too gross, I might just punt and have a small
seperate program that does the LOGIN% thing and then pulls in the
reset of the world.  I'm shying away from that for right now because
I'm worried about it being another thing for me to lose track of.

----- Original Message -----
From: Mark Crispin <[email protected]>
Date: Saturday, July 10, 2004 10:27 pm
Subject: re: EFTPSR

> Comment about not-logged-in EFTPSR:
>
> Suggest that EFTPSR be split in two: one module for not-logged-in
> and one for logged in, and switch at login time.
>
> That way the dangerous not-logged-in code can be minimized.


11-Jul-2004 14:34:12-PDT,4947;000000000000
Return-Path: <[email protected]>
Received: from mta8.srv.hcvlny.cv.net ([167.206.5.75]) by lingling.panda.com with TCP/SMTP; Sun, 11 Jul 2004 14:18:51 -0700 (PDT)
Received: from optonline.net (mstr3.srv.hcvlny.cv.net [167.206.5.14])
by mta8.srv.hcvlny.cv.net
(iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar  3 2004))
with ESMTP id <[email protected]> for
[email protected]; Sun, 11 Jul 2004 17:18:45 -0400 (EDT)
Received: from [167.206.5.71] (Forwarded-For: [24.184.174.68])
by mstr3.srv.hcvlny.cv.net (mshttpd); Sun, 11 Jul 2004 17:18:15 -0400
Date: Sun, 11 Jul 2004 17:18:15 -0400
From: [email protected]
Subject: Resuscitating Tops-20 DECtape support
To: [email protected]
Message-id: <[email protected]>
MIME-version: 1.0
X-Mailer: iPlanet Messenger Express 5.2 HotFix 1.25 (built Mar  3 2004)
Content-type: text/plain; charset=us-ascii
Content-language: en
Content-transfer-encoding: 7BIT
Content-disposition: inline
X-Accept-Language: en
Priority: normal

While I've been working on EFTPSR, I got to thinking about other ways
of transfering files on and off of a 20.  Back when I used to commute
between college (WPI) and Marlboro, I kept a couple of DECtapes in my
bag.  I would write my work to them on our KA-10 and then mount them
on 1031 (The Great Pumpkin) to read them.

Tops-20 did have DECtape support.  I used it nearly every day.  I
don't remember, but I'm pretty sure that GTJFN% would do escape
recognition.  Aside from the fact that it was cool, I was thinking
that a DECtape-like device might still be useful in the new
millennium.

Since Tops-20 never had a direct access floppy drive (although you
could use FE0: to get to the RX01 on the front end), the following
suggests itself:

1) Physical implementation media for DECtape is now a floppy.  The is
   a good device to use because it is portable.  Since the DECtape
   driver is used to slow access, this physical instantiation may be
   quite appropriate--we might not have to worry about time outs.

2) The floppy must be pre-formated by a seperate program before
   mount.  This creates a file that large enough to contain the
   complete contents of a DECtape (576 128 word blocks?).  The file
   is called 'DECTAPE.DAT' and it has the 'S' bit set.

3) The DECtape driver is ported from Tenex.  The ITS and Tops-10
   DECtape drivers are used as reference.  PDP-8 and other TU55
   management code may also be useful.

4) A new KLH10 module is coded to handle DECtapes.  It is the shell
   of the magtape simulator with lots of stuff ripped out.  DECtape
   simulation logic (and perhaps some code) is lifted from SIMH which
   handles DECtape for the PDP-15.

5) The floppy drive is identified to KLH10 and it forks a process
   containing the DECtape handler.  The process checks for media in
   the floppy drive.  If it detects that the media has changed, it
   looks for 'DECTAPE.DAT' with the 'S' bit set.

6) If these conditions hold, then the handler lights the ready bit.  I
   the R bit is set on DECTAPE.DAT, then the read only bit is also
   set.   Tops-20 can then do its thing, the results being propagated
   to the physical media.

7) When the user is done, the command is given to flap (unload) the
   DECtape media.  KLH10 then flushes all the buffers and (possibly)
   informs the host operating system to dismount the drive.

8) Media errors which can not be recovered are kicked up to the host
   operating system.  The media recover logic for DECtape was HIGHLY
   robust.  If enough space exists on the floppy, we might actually
   want to use two seperate redundant files or some other flavor of
   redundancy, error checking, recovery.

9) MOUNTR,ORION,QUASAR possibly modified to handle tape mount
   requests.

Once KLH10 has dismounted the floppy, a seperate program is run (maybe
called SLURP?).  Slurp has the following switchs:

-l: Set the floppy volume id to the same name as the DECtape label.

-d: List the directory on the 'DECtape'

-x: Extract all the files from DECTAPE.DAT.  For each file on tape, a
   seperate file is made on the floppy containing all the blocks for
   that file.  Any file on the floppy with a name over 6 characters
   will NOT insert.

-u: Unextract.  The inverse of -x.  A file called DECTAPE.NEW is
   created and every file on the tape is inserted into it, building a
   new directory file.  The label of the tape is the same as the
   volume id label of the floppy.  Once done, DECTAPE.DAT is deleted
   and DECTAPE.NEW is appropriately renamed.

-r: Retrieve a particular file from DECTAPE.DAT.

-w: Write a particular file to DECtape.DAT.  File name is limited to
   six characters.

-b: set the byte size of the target file.

-c: Source byte conversion (7 bit, 8 bit, 36)

12-Jul-2004 09:45:09-PDT,2208;000000000000
Return-Path: <[email protected]>
Received: from mta9.srv.hcvlny.cv.net ([167.206.5.42]) by lingling.panda.com with TCP/SMTP; Mon, 12 Jul 2004 09:35:50 -0700 (PDT)
Received: from optonline.net (mstr3.srv.hcvlny.cv.net [167.206.5.14])
by mta9.srv.hcvlny.cv.net
(iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar  3 2004))
with ESMTP id <[email protected]> for
[email protected]; Mon, 12 Jul 2004 12:34:31 -0400 (EDT)
Received: from [167.206.5.71] (Forwarded-For: [24.184.174.68])
by mstr3.srv.hcvlny.cv.net (mshttpd); Mon, 12 Jul 2004 12:34:00 -0400
Date: Mon, 12 Jul 2004 12:34:00 -0400
From: [email protected]
Subject: What can't live without section zero?
To: [email protected]
Message-id: <[email protected]>
MIME-version: 1.0
X-Mailer: iPlanet Messenger Express 5.2 HotFix 1.25 (built Mar  3 2004)
Content-type: text/plain; charset=us-ascii
Content-language: en
Content-transfer-encoding: 7BIT
Content-disposition: inline
X-Accept-Language: en
Priority: normal

With respect to the LOGIN% issues that I mentioned earlier, I was
writing some code to write-protect some pages that I don't want
modifed under any circumstances.

While checking the page map, I noticed that although I don't have
anything in section zero, it still exists (with no pages).  So, I
wrote a little code to toss it and keep things tidy, viz:

       SETO T1,                        ; Punting a section
       DMOVE T2,[EXP <.FHSLF,,0>,<0,,1>]
       SMAP%                           ; This process, section 0, one section
        ERCAL FATAL

This gronked with an ARGX23, Invalid section number.  Looking in the
early part of .SMAP in JSYSA shows the following:

       HRRZS T2                ;GET SECTION # ONLY
       SKIPG T2                ;NON-ZERO SECTION?
       ITERR (ARGX23)          ;NO. ILLEGAL THEN

I spent another five minutes poking around in PAGEM and didn't
immediately stumble across anything that croaks if section 0 isn't
around.  Isn't section 0 a valid section?  Why can't I get rid it?  I
was tempted to JFCL the ITERR and try it, but before I do, I was just
wondering ...



12-Jul-2004 11:44:09-PDT,1078;000000000000
Return-Path: <[email protected]>
Received: from Ikkoku-Kan.Panda.COM (panda.com [206.124.149.114]) by lingling.panda.com with TCP/SMTP; Mon, 12 Jul 2004 11:35:48 -0700 (PDT)
Received: from Ikkoku-Kan.Panda.COM (Ikkoku-Kan.Panda.COM [192.107.14.50]) by Ikkoku-Kan.Panda.COM id LAA00192; Mon, 12 Jul 2004 11:35:46 -0700 (PDT)
Date: Mon, 12 Jul 2004 11:18:01 -0700 (PDT)
From: Mark Crispin <[email protected]>
Sender: Mark Crispin <[email protected]>
Subject: re: What can't live without section zero?
To: [email protected]
cc: [email protected]
In-Reply-To: <[email protected]>
Message-ID: <[email protected]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII

Of course, section 0 ACs are accessible.

My guess is that nobody ever tried to make a TOPS-20 process not have a
section 0.

AFAIK, the only way to avoid anything touching section 0 would be to map that
section to a protected file, since otherwise TOPS-20 will create the page the
first time it is touched.

12-Jul-2004 17:11:38-PDT,1372;000000000000
Return-Path: <[email protected]>
Received: from jalapeno.cc.columbia.edu ([128.59.59.238]) by lingling.panda.com with TCP/SMTP; Mon, 12 Jul 2004 17:01:26 -0700 (PDT)
Received: from [192.168.0.101] (pcp09163523pcs.verona01.nj.comcast.net [69.141.118.203])
       (user=rossman mech=PLAIN bits=0)
       by jalapeno.cc.columbia.edu (8.12.11/8.12.11) with ESMTP id i6D01N9r008955
       (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT);
       Mon, 12 Jul 2004 20:01:23 -0400 (EDT)
In-Reply-To: <[email protected]>
References: <[email protected]>
Mime-Version: 1.0 (Apple Message framework v618)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <[email protected]>
Content-Transfer-Encoding: 7bit
Cc: Ken Rossman <[email protected]>, [email protected]
From: Ken Rossman <[email protected]>
Subject: Re: What can't live without section zero?
Date: Mon, 12 Jul 2004 20:01:18 -0400
To: [email protected]
X-Mailer: Apple Mail (2.618)
X-No-Spam-Score: Local
X-Scanned-By: MIMEDefang 2.40

Maybe I'm remembering this wrong, but

 a) don't you always have the regular ACs available to you, and
 b) aren't they really a part of section 0?

Hence, section 0 must always exist???

Or, am I missing something, and/or remembering things wrong?

Ken

12-Jul-2004 18:38:35-PDT,1204;000000000000
Return-Path: <[email protected]>
Received: from toed.xkl.com ([192.94.202.46]) by lingling.panda.com with TCP/SMTP; Mon, 12 Jul 2004 18:30:00 -0700 (PDT)
Date: Mon, 12 Jul 2004 18:27:19 -0700
From: Ralph Gorin <[email protected]>
Subject: re: What can't live without section zero?
To: [email protected]
Reply-to: [email protected]
Message-ID: <[email protected]>

Ken (and all),

The ACs have addresses in section 0 (and in section 1) but they're not
part of page 0 in either section.  When the process isn't running, the
ACs are remembered in the PSB, not in the process' memory image.
(Imagine sharing page 0 between two processes: where would you store
the process ACs?)

There was a protracted struggle to free TOPS-20 processes from
reliance on the TOPS-10 job data area, locations 20-137.  PDVs
supplied much of the answer.  I rather imagine TOPS-20 will work fine
for processes that have no section 0.  (Well, I may be thinking of
TOPS-20 as XKL has modified it.)

Due to limitations in the KL10, parts of TOPS-20 were required to be
mapped in section 0.  XKL did away with those limitations; none
of our TOPS-20 is in section 0.

Ralph
-------
13-Jul-2004 08:23:29-PDT,3607;000000000000
Return-Path: <[email protected]>
Received: from mta7.srv.hcvlny.cv.net ([167.206.5.74]) by lingling.panda.com with TCP/SMTP; Tue, 13 Jul 2004 08:14:24 -0700 (PDT)
Received: from optonline.net (mstr3.srv.hcvlny.cv.net [167.206.5.14])
by mta7.srv.hcvlny.cv.net
(iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar  3 2004))
with ESMTP id <[email protected]> for
[email protected]; Tue, 13 Jul 2004 11:14:24 -0400 (EDT)
Received: from [167.206.5.79] (Forwarded-For: [24.184.174.68])
by mstr3.srv.hcvlny.cv.net (mshttpd); Tue, 13 Jul 2004 11:13:43 -0400
Date: Tue, 13 Jul 2004 11:13:43 -0400
From: [email protected]
Subject: Re: What can't live without section zero?
To: Ken Rossman <[email protected]>
Cc: [email protected]
Message-id: <[email protected]>
MIME-version: 1.0
X-Mailer: iPlanet Messenger Express 5.2 HotFix 1.25 (built Mar  3 2004)
Content-type: text/plain; charset=us-ascii
Content-language: en
Content-transfer-encoding: 7BIT
Content-disposition: inline
X-Accept-Language: en
Priority: normal

Keng,

You can get to the registers as registers (i.e., SETZ 1,) in any
section.  If you use section local addressing, you can also get to the
registers in any section.  For example, consider the following code
executing in section 30:

       SETZB 1,2               ; zeros both AC1 and AC2

                 But  But! BUT!!!!

       XHLLI 3,0               ; Load the current section
       SETZB 1,2(3)            ; zero AC1 and location 30000002

Note that the second case doesn't get AC2.  I couldn't comment about
the monitor address space usage, but I don't see anything that would
drop dead if section zero didn't exist in the USER's virtual address
space.  However, I haven't checked extensively.

I wonder if certain legacy functions might get upset?  For example, if
you did a @GET MACRO /USE:30, punted section zero and then started it,
one speculates that one of a number of things might happen (note that,
in any case, MACRO itself would probably break).  On receipt of the
first UUO, Tops-20 might:

1) Pull PA1050 into section 30 and allow MACRO to die.
2) Ignore a UUO request from a non-zero section.
3) Issue an error for a non-zero section UUO request.
4) Attempt to PA1050 into section 0 and:
    a) Notice section zero isn't there and:
        i) Create it, load PA1050 and proceed as in #1
       ii) Refuse to create it and proceed as in #3
    b) Not notice section zero isn't there, attempt to load PA1050
       and crash ignominiously.

Case 4b is obviously the 'interesting' one.  MRC's suggestion of
mapping section zero to a protected file is interesting.  One wonders
if something like 4b would be encountered, because of trying to pull
PA1050 in on top of something that doesn't want to go away.

Some of the PA1050 monitor support code got tinkered with back when
there was being work done on putting PA1050 into an extended section,
but I don't know much about it and it's been awhile since I poked
around in that part of the monitor.  I know that a number of fixes
were done, but I don't remember what those were.

                                --T
----- Original Message -----
From: Ken Rossman <[email protected]>
Date: Monday, July 12, 2004 8:01 pm
Subject: Re: What can't live without section zero?

> Maybe I'm remembering this wrong, but
>
>  a) don't you always have the regular ACs available to you, and
>  b) aren't they really a part of section 0?
>
> Hence, section 0 must always exist???
>
> Or, am I missing something, and/or remembering things wrong?
>
> Ken


13-Jul-2004 19:27:44-PDT,2295;000000000000
Return-Path: <[email protected]>
Received: from mta10.srv.hcvlny.cv.net ([167.206.5.85]) by lingling.panda.com with TCP/SMTP; Tue, 13 Jul 2004 19:18:50 -0700 (PDT)
Received: from optonline.net (mstr3.srv.hcvlny.cv.net [167.206.5.14])
by mta10.srv.hcvlny.cv.net
(iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar  3 2004))
with ESMTP id <[email protected]> for
[email protected]; Tue, 13 Jul 2004 22:17:29 -0400 (EDT)
Received: from [167.206.5.80] (Forwarded-For: [24.184.174.68])
by mstr3.srv.hcvlny.cv.net (mshttpd); Tue, 13 Jul 2004 22:17:22 -0400
Date: Tue, 13 Jul 2004 22:17:22 -0400
From: [email protected]
Subject: FTPSER starts with OPERATOR capability
To: [email protected]
Message-id: <[email protected]>
MIME-version: 1.0
X-Mailer: iPlanet Messenger Express 5.2 HotFix 1.25 (built Mar  3 2004)
Content-type: text/plain; charset=us-ascii
Content-language: en
Content-transfer-encoding: 7BIT
Content-disposition: inline
X-Accept-Language: en
Priority: normal

I finished some code to build up a capability list.  I wanted to do
this to only enable a specific capability while debugging.  In
particular, I only allow DDT to be invoked on the top level fork when
SC%WHL is enabled.  I was testing this out and found some things that
I thought were interesting.

When FTPSER starts up, it has no capabilities enabled at all.  But, it
is allowed to enable ALL of the following capabilities: SC%CTC,
SC%GTB, SC%LOG, SC%SCT, SC%OPR and SC%IPC.  I tested and you are, in fact, allowed to enable OPERATOR.

A brief investigation of the NETSRV.MAC source code shows that it is
setting F%PRV which sets CJ%CAP on a CRJOB%.  I wonder what a
NOT-LOGGED-IN FTPSER job would need with OPERATOR capability?

Although I don't know everything that you can do when you're not
logged in, I have verified that you CAN delete a file.  One supposes
that you might be able to do more with OPERATOR enabled.

At any rate, LOGIN% still requires a correct password even if OPERATOR
is on.  The capabilities are set to the login directory afterwards.

I guess I better really make sure that I do everything I can to make
sure that FTPSER *HIGHLY RESTRICTS* what can be done before sign on.


13-Jul-2004 20:32:46-PDT,927;000000000000
Return-Path: <[email protected]>
Received: from Ikkoku-Kan.Panda.COM (panda.com [206.124.149.114]) by lingling.panda.com with TCP/SMTP; Tue, 13 Jul 2004 20:24:37 -0700 (PDT)
Received: from Ikkoku-Kan.Panda.COM (Ikkoku-Kan.Panda.COM [192.107.14.50]) by Ikkoku-Kan.Panda.COM id UAA01061; Tue, 13 Jul 2004 20:24:34 -0700 (PDT)
Date: Tue, 13 Jul 2004 20:18:20 -0700 (PDT)
From: Mark Crispin <[email protected]>
Sender: Mark Crispin <[email protected]>
Subject: re: FTPSER starts with OPERATOR capability
To: [email protected]
cc: [email protected]
In-Reply-To: <[email protected]>
Message-ID: <[email protected]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII

I forget the reason, but traditionally not logged in jobs are able to enable
wheel and/or operator.

I did some tests and I didn't see any obvious need though.

16-Jul-2004 15:05:47-PDT,5374;000000000000
Return-Path: <[email protected]>
Received: from mta8.srv.hcvlny.cv.net ([167.206.5.75]) by lingling.panda.com with TCP/SMTP; Fri, 16 Jul 2004 14:53:41 -0700 (PDT)
Received: from optonline.net (mstr3.srv.hcvlny.cv.net [167.206.5.14])
by mta8.srv.hcvlny.cv.net
(iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar  3 2004))
with ESMTP id <[email protected]> for
[email protected]; Fri, 16 Jul 2004 17:53:33 -0400 (EDT)
Received: from [167.206.5.71] (Forwarded-For: [24.184.174.68])
by mstr3.srv.hcvlny.cv.net (mshttpd); Fri, 16 Jul 2004 17:53:03 -0400
Date: Fri, 16 Jul 2004 17:53:03 -0400
From: [email protected]
Subject: What happens to section 37 on CR%MAP?
To: [email protected]
Message-id: <[email protected]>
MIME-version: 1.0
X-Mailer: iPlanet Messenger Express 5.2 HotFix 1.25 (built Mar  3 2004)
Content-type: text/plain; charset=us-ascii
Content-language: en
Content-transfer-encoding: 7BIT
Content-disposition: inline
X-Accept-Language: en
Priority: normal

I've just noticed some behavior that I don't understand with an
inferior fork running in a non-zero section.  Basically, I'm setting
up the transfer fork with the same page map as the control fork and
making sure that shared routines are truely reentrant.  Consider the
following:

       MOVX T1,.FHINF          ; Kill all inferiors
       KFORK%                  ; and any file handles
        ERJMP .+1              ;  Not killing ourselves, so should always work
       MOVX T1,CR%MAP!CR%CAP   ; With our capabilities and map
       CFORK%                  ; Create it

I had assumed that the inferior fork would get the same sections that
the superior has.  This isn't happening.  Section 37 (which has my
symbols and patch area) is not mapped.  So, when I put DDT in there,
create the fork and then set a breakpoint, the inferior croaks because
there is no place for the JSR to go to:

!g star:<ftp>eftpsr
!ree
220 TOMMYT TOPS20 FTP Server V6.1(1100) on Friday, July 16, 2004 5:35:32PM-EDT
FTPSER>site capabilities enable whl
200 CTC GTB LOG SCT WHL.
FTPSER>site ddt
200-Starting debug.
$0B>>DEBUG#/   MOVE T1,SITLIT#+432   $p
200 End of DDT.
FTPSER>;DDT has now been mapped into the address space
FTPSER>site transfer abort
200 Transfer fork reset and initialized
FTPSER>;The inferior fork has now been created with the 'same' address space.
FTPSER>quit
221 QUIT command received. Goodbye.
!information (about) fork
=> EFTPSR (2): HALT at 1,,24552, 0:00:00.2
      Fork 3: HALT at 1,,26062, 0:00:00.0
!information (about) memory

90. pages, Entry vector loc 1,,20000 len 3

 Section 0     R, W, E,  Private
 Section 1     R, W, E,  Private
1001     EFTPSR.EXE.597  1   R, CW, E
1010-1030        EFTPSR.EXE.597  2-22   R, E
1100-1102        Private   R, W, E
1103     Private   R, CW, E
 Section 2     R, W, E,  Private
2001-2025        EFTPSR.EXE.597  23-47   R, E
 Section 37    R, W, E,  Private
37001-37007      EFTPSR.EXE.597  50-56   R, CW, E
37700-37701      TOPS20:<SUBSYS>XDDT.EXE.1  1-2   R, CW, E
37703-37732      TOPS20:<SUBSYS>XDDT.EXE.1  3-32   R, CW, E
37735-37736      Private   R, W, E
37740-37753      TOPS20:<SUBSYS>XDDT.EXE.1  35-50   R, E

So far, so good.  The sections are normal.  Section 0 exists because I
can't get rid of it.  Section 1 contains code, literals, stack space
and static storage.  Section 2 contains the server's extensive help
text and documentation.  DDT is in section 37 along with the symbol
table.  However:

!fork (is) 3
% Fork is not a direct inferior
!information (about) memory

555. pages

 Section 0     R, W, E,  Private
0-777    Fork 2  0-777   R, W, E
 Section 1     R, W, E,  special mapping
1001     EFTPSR.EXE.597  1   R, CW, E
1010-1030        EFTPSR.EXE.597  2-22   R, E
1100-1102        Fork 2  1100-1102   R, W, E
1103     Fork 2  1103   R, CW, E
 Section 2     R, W, E,  special mapping
2001-2025        EFTPSR.EXE.597  23-47   R, E
 Section 3      special mapping
 Section 4      special mapping
 Section 5      special mapping
 Section 6      special mapping
 Section 7      special mapping
 Section 10     special mapping
 Section 11     special mapping
 Section 12     special mapping
 Section 13     special mapping
 Section 14     special mapping
 Section 15     special mapping
 Section 16     special mapping
 Section 17     special mapping
 Section 20     special mapping
 Section 21     special mapping
 Section 22     special mapping
 Section 23     special mapping
 Section 24     special mapping
 Section 25     special mapping
 Section 26     special mapping
 Section 27     special mapping
 Section 30     special mapping
 Section 31     special mapping
 Section 32     special mapping
 Section 33     special mapping
 Section 34     special mapping
 Section 35     special mapping
 Section 36     special mapping
!

555. pages?  Pages from section 0?  There isn't supposed to be
anything in there.  Special mapping?  What's that?  I'm not using
those sections.  Where is section 37??  Anyway, this isn't the end of
the world, I'll just not use CR%MAP for now and do things by hand with
SMAP%/PMAP%, etc.  I wonder if all sections except 3777 (?) get mapped
on a Toad?


16-Jul-2004 16:14:06-PDT,2483;000000000000
Return-Path: <[email protected]>
Received: from mta3.srv.hcvlny.cv.net ([167.206.5.69]) by lingling.panda.com with TCP/SMTP; Fri, 16 Jul 2004 16:03:48 -0700 (PDT)
Received: from optonline.net (mstr3.srv.hcvlny.cv.net [167.206.5.14])
by mta3.srv.hcvlny.cv.net
(iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar  3 2004))
with ESMTP id <[email protected]> for
[email protected]; Fri, 16 Jul 2004 19:03:31 -0400 (EDT)
Received: from [167.206.5.71] (Forwarded-For: [24.184.174.68])
by mstr3.srv.hcvlny.cv.net (mshttpd); Fri, 16 Jul 2004 19:03:07 -0400
Date: Fri, 16 Jul 2004 19:03:07 -0400
From: [email protected]
Subject: Re: What can't live without section zero?
To: [email protected]
Message-id: <[email protected]>
MIME-version: 1.0
X-Mailer: iPlanet Messenger Express 5.2 HotFix 1.25 (built Mar  3 2004)
Content-type: text/plain; charset=us-ascii
Content-language: en
Content-transfer-encoding: 7BIT
Content-disposition: inline
X-Accept-Language: en
Priority: normal

While I was SMAP%ing to get around the CR%MAP behavior, the hacker in
me tried to create a case where section zero would not exist.  That
is, I created a fork with no page map and then only mapped a single
section into it, viz:


       MOVX T1,CR%CAP          ; Just our capabilities, no map
       CFORK%                  ; "You're a fork"
        ERJMP DIE
       MOVEM T1,TFORK          ; Save the handle

       HRLZI T1,.FHSLF         ; This fork
       HLR T1,[ZERO!CODORG]    ; Code segment
       HRLZ T2,TFORK           ; Going into the inferior
       HRR T2,T1               ; Same section
       MOVX T3,<SM%RWX!SM%IND!1> ; Track all changes in this section
       SMAP%

After the CFORK%, the inferior fork has no page map and no sections:
zero everything.  After the SMAP%?  CODORG is in section one, which is
created just fine in the inferior.  Contrary to intuition, section
zero shows up, also.  Why??  I sure didn't put it there ...

!g star:<ftp>eftpsr
!reenter
220 TOMMYT TOPS20 FTP Server V6.1(1103) on Friday, July 16, 2004 7:00:34PM-EDT
FTPSER>quit
221 QUIT command received. Goodbye.
!i for
=> EFTPSR (2): HALT at 1,,24552, 0:00:00.0
      Fork 3: HALT at 1,,26103, 0:00:00.0
!fork 3
% Fork is not a direct inferior
!information (about) memory

22. pages

 Section 0     R, W, E,  Private
 Section 1     R, W, E,  special mapping
1001     EFTPSR.EXE.603  1   R, CW, E
1010-1030        EFTPSR.EXE.603  2-22   R, E
1100-1102        Fork 2  1100-1102   R, W, E
1103     Fork 2  1103   R, CW, E
!


16-Jul-2004 18:38:19-PDT,1734;000000000000
Return-Path: <[email protected]>
Received: from toed.xkl.com ([192.94.202.46]) by lingling.panda.com with TCP/SMTP; Fri, 16 Jul 2004 18:27:18 -0700 (PDT)
Date: Fri, 16 Jul 2004 18:24:18 -0700
From: Ralph Gorin <[email protected]>
Subject: Re: What happens to section 37 on CR%MAP?
To: [email protected]
cc: [email protected]
In-Reply-To: <[email protected]>
Reply-to: [email protected]
Message-ID: <[email protected]>

OK, I took the bait.

On the toad, DDT "normally" runs in section 7776.  (7777 is illegal.)
I added DDT to the following section 1 program, added a breakpoint
after the CFORK and ran it.

       MOVX T1,.FHINF          ; Kill all inferiors
       KFORK%                  ; and any file handles
        ERJMP .+1              ;  Not killing ourselves, so should always work
       MOVX T1,CR%MAP!CR%CAP   ; With our capabilities and map
       CFORK%                  ; Create it

The result was 512 section 0 pages in the new fork mapped to the
corresponding pages of the original fork, two pages in section 1
of the new fork mapped to the corresponding pages of the original
fork, and sections 2 through 777 "special mapping".

I'm terribly embarassed that I didn't provide sections 1000 through 7775
as special mapping also.  Evidently I was too hasty in implementing
those top three address bits.   And of course, it should have mapped
section 7776 of the new fork to the original.

I think section 0 is handled as a special case for compatibility with
the bad old days.  Lacking the concept of section mapping, the individual
pages of section 0 were mapped (notwithstanding the non-existent target
pages).

Ralph
-------
17-Jul-2004 05:17:55-PDT,1844;000000000000
Mail-From: MRC created at 17-Jul-2004 05:07:31
Date: Sat, 17 Jul 2004 05:07:31 -0700 (PDT)
From: Mark Crispin <[email protected]>
Subject: Re: What happens to section 37 on CR%MAP?
To: [email protected], [email protected]
In-Reply-To: <[email protected]>
Pithy-Thought: TOPS-20 was a great improvement over its successors
Message-ID: <[email protected]>

Hi Ralph -

I did something unimaginable; I looked at the source.  :-)

CR%MAP is implemented by routine CFK4 in FORK.MAC, and it very
clearly behaves the way described:

Map pages 0 to 777.
If processor has extended addressing, map MXSECN-1 sections
starting at section 1.
If superior is execute only, make inferior execute only too.

There is a comment right after the test for extended addressing:

;SECTION 0 COULD BE HANDLED WITH AN INDIRECT SECTION POINTER AS WELL
; MAYBE FUTURE ...

My surmise is that this was done this way because of 2020 and
model A compatibility.

As for not mapping the last section, that is very plainly done
with the instruction:
       MOVEI 4,MXSECN-1        ;ALL SECTIONS

On a KL[H]10, MXSECN is 37 octal or 31. decimal.  Therefore, it
maps 30. sections starting at section 1.

The very next instriction reads:
       CALL MSETST             ;MAP SECTIONS 1 THRU MXSECN
which suggests that this may be a bug instead of a deliberate
feature.  It appears that, rather than a conscious effort to
exclude the DDT section, someone thought that since they were
starting with 1 they had to subtract 1 from the count.  Classic
fencepost error; the programmer thought there would be a
fencepost error, so committed a fencepost error in order to
compensate for the fencepost error!

Anyway, I think that the MOVEI 4,MXSECN-1 at CFK41-3 should be
changed to MOVEI 4,MXSECN

-- Mark --
-------
23-Jul-2004 18:02:19-PDT,1933;000000000000
Return-Path: <[email protected]>
Received: from mta9.srv.hcvlny.cv.net ([167.206.5.42]) by lingling.panda.com with TCP/SMTP; Fri, 23 Jul 2004 17:52:55 -0700 (PDT)
Received: from optonline.net (mstr3.srv.hcvlny.cv.net [167.206.5.14])
by mta9.srv.hcvlny.cv.net
(iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar  3 2004))
with ESMTP id <[email protected]> for
[email protected]; Fri, 23 Jul 2004 20:52:54 -0400 (EDT)
Received: from [167.206.5.139] (Forwarded-For: [24.184.174.68])
by mstr3.srv.hcvlny.cv.net (mshttpd); Fri, 23 Jul 2004 20:52:10 -0400
Date: Fri, 23 Jul 2004 20:52:10 -0400
From: [email protected]
Subject: RETR partially implemented, first transfer on new FTPSER!!
To: [email protected]
Message-id: <[email protected]>
MIME-version: 1.0
X-Mailer: iPlanet Messenger Express 5.2 HotFix 1.25 (built Mar  3 2004)
Content-type: text/plain; charset=iso-8859-1
Content-language: en
Content-transfer-encoding: quoted-printable
Content-disposition: inline
X-Accept-Language: en
Priority: normal

R=3A=5CTops-20=3Eftp tommyt
Connected to TommyT=2E
=A0=26=238805=3B220 TOMMYT TOPS20 FTP Server V6=2E1(1205) on Friday=2C Ju=
ly 23=2C 2004 8=3A49=3A51PM-EDT
User (TommyT=3A(none))=3A slogin
331 User name SLOGIN ok=2E Password=2C please=2E
Password=3A
230 User SLOGIN logged in at Friday=2C July 23=2C 2004 8=3A49=3A55PM-EDT=2C=
job 13=2E
ftp=3E ascii
200 Type A ok=2E
ftp=3E get hello=2Etxt
200 Port 4889 (19=2E25) at host 192=2E168=2E1=2E7 accepted=2E
150 Retrieving TOPS20=3A=3CSLOGIN=3EHELLO=2ETXT=2E1=2C ASCII (7-=3E7)=2C =
Telnet=2C Stream=2C File
226 Inferior fork transfered TOPS20=3A=3CSLOGIN=3EHELLO=2ETXT=2E1
ftp=3A 15 bytes received in 0=2E00Seconds 15000=2E00Kbytes/sec=2E
ftp=3E bye
221 QUIT command received=2E Goodbye=2E

R=3A=5CTops-20=3Etype hello=2Etxt
Hello=2C World=2E

R=3A=5CTops-20=3E

27-Jul-2004 05:59:06-PDT,4717;000000000000
Return-Path: <[email protected]>
Received: from mta10.srv.hcvlny.cv.net ([167.206.5.85]) by lingling.panda.com with TCP/SMTP; Tue, 27 Jul 2004 05:48:42 -0700 (PDT)
Received: from optonline.net (mstr3.srv.hcvlny.cv.net [167.206.5.14])
by mta10.srv.hcvlny.cv.net
(iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar  3 2004))
with ESMTP id <[email protected]> for
[email protected]; Tue, 27 Jul 2004 08:47:42 -0400 (EDT)
Received: from [167.206.5.71] (Forwarded-For: [24.184.174.68])
by mstr3.srv.hcvlny.cv.net (mshttpd); Tue, 27 Jul 2004 08:46:56 -0400
Date: Tue, 27 Jul 2004 08:46:56 -0400
From: [email protected]
Subject: MLFL, MAIL, MSND, MSOM, MSAM, MRSQ, MRCP
To: [email protected]
Message-id: <[email protected]>
MIME-version: 1.0
X-Mailer: iPlanet Messenger Express 5.2 HotFix 1.25 (built Mar  3 2004)
Content-type: text/plain; charset=us-ascii
Content-language: en
Content-transfer-encoding: 7BIT
Content-disposition: inline
X-Accept-Language: en
Priority: normal

I was reviewing the FTPSER command table for keywords that I have yet
to implement, and I noticed a couple that I didn't recognize.  These
were: MSND, MSOM, MSAM and MRCP.  All of these are in the command
table, but I hadn't seen them in RFC959.  Each implementation of these
was "502 The FOO command is not yet implemented."

I thought they might be for new commands, the suffices being
reminiscent of some delivery options in MM that I had previously
encountered.  After a little poking around, I came across an earlier
RFC (765) from 1980 that RFC 959 obsoletes.  These keywords, along
with MLFL, MAIL, and MRSQ are all for sending mail.  Sending mail??
What was SMTP for?  Does anybody have any historical background on
this?

I very briefly surfed through the command set of a very few FTP
servers.  Some of them recognize these keywords, but none implement
them, either.  At this point, I think I am probably going to flush
them.  Anybody have any major objections?



MAIL FILE (MLFL)

  The intent of this command is to enable a user at the user
  site to mail data (in form of a file) to another user at the
  server site.  It should be noted that the files to be mailed
  are transmitted via the data connection in ASCII or EBCDIC
  type.  (It is the user's responsibility to ensure that the
  type is correct.)  These files should be inserted into the
  destination user's mailbox by the server in accordance with
  serving Host mail conventions.  The mail may be marked as
  sent from the particular user HOST and the user specified by
  the 'USER' command.  The argument field may contain a Host
  system ident, or it may be empty.  If the argument field is
  empty or blank (one or more spaces), then the mail is
  destined for a printer or other designated place for general
  delivery site mail.

MAIL (MAIL)

  This command allows a user to send mail that is NOT in a
  file over the TELNET connection.  The argument field may
  contain system ident, or it may be empty.  The ident is
  defined as above for the MLFL command.  After the 'MAIL'
  command is received, the server is to treat the following
  lines as text of the mail sent by the user.  The mail text
  is to be terminated by a line containing only a single
  period, that is, the character sequence "CRLF.CRLF".  It is
  suggested that a modest volume of mail service should be
  free; i.e., it may be entered before a USER command.

MAIL SEND TO TERMINAL (MSND)

  This command is like the MAIL command, except that the data
  is displayed on the addressed user's terminal, if such
  access is currently allowed, otherwise an error is returned.

MAIL SEND TO TERMINAL OR MAILBOX (MSOM)

  This command is like the MAIL command, except that the data
  is displayed on the addressed user's terminal, if such
  access is currently allowed, otherwise the data is placed in
  the user's mailbox.

MAIL SEND TO TERMINAL AND MAILBOX (MSAM)

  This command is like the MAIL command, except that the data
  is displayed on the addressed user's terminal, if such
  access is currently allowed, and, in any case, the data is
  placed in the user's mailbox.

MAIL RECIPIENT SCHEME QUESTION (MRSQ)

  This FTP command is used to select a scheme for the
  transmission of mail to several users at the same host.  The
  schemes are to list the recipients first, or to send the
  mail first.

MAIL RECIPIENT (MRCP)

  This command is used to identify the individual recipients
  of the mail in the transmission of mail for multiple users
  at one host.


28-Jul-2004 20:57:12-PDT,1923;000000000000
Return-Path: <[email protected]>
Received: from goose.mail.pas.earthlink.net ([207.217.120.18]) by lingling.panda.com with TCP/SMTP; Wed, 28 Jul 2004 20:48:03 -0700 (PDT)
Received: from cpe-24-221-177-162.ca.sprintbbd.net ([24.221.177.162] helo=reststop.com)
       by goose.mail.pas.earthlink.net with esmtp (Exim 3.33 #1)
       id 1Bq1ti-0006sD-00
       for [email protected]; Wed, 28 Jul 2004 20:48:03 -0700
Date: Wed, 28 Jul 2004 20:48:11 -0700
Mime-Version: 1.0 (Apple Message framework v553)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Subject: Listings and scanning?
From: Carl Baltrunas <[email protected]>
To: Tops-20 Wizards <[email protected]>
Content-Transfer-Encoding: 7bit
Message-Id: <[email protected]>
X-Mailer: Apple Mail (2.553)

Hi everyone,

I was digging through my attic and storage locker for some exhibits to
show at a presentation tomorrow and came across a number of old
listings.  Of interest to this group would be the ITS Microcode from
1976.  I also have a couple of GT-40 program listings, including one I
was working on when I left the last place I worked that had a GT-40.

Anyone interested in scanning the listings in, let me know, and I'll
see what I can make available.  I have a few boxes of listings that I
didn't go through in storage, and if someone is interested, I will try
to make a list of what I have.  Obviously, my own programs, I'm not
concerned with, just the things that would be of interest to other 10 &
20 people.

I also have some punch cards and paper tapes with programs on them, if
anyone still has a working reader.  I know a couple of the more
meaningless programs are from circa 1972, on one of the PDP-11 OSs
which name escapes me... it's command structure was regular BASIC
commands.  I must be getting old, since I don't recall the name of the
OS.

-Carl

29-Jul-2004 05:26:32-PDT,2544;000000000000
Return-Path: <[email protected]>
Received: from igw2.watson.ibm.com ([129.34.20.6]) by lingling.panda.com with TCP/SMTP; Thu, 29 Jul 2004 05:17:26 -0700 (PDT)
Received: from sp1n293en1.watson.ibm.com (sp1n293en1.watson.ibm.com [129.34.20.41])
       by igw2.watson.ibm.com (8.11.7-20030924/8.11.4) with ESMTP id i6TCG3F42308;
       Thu, 29 Jul 2004 08:16:03 -0400
Received: from OCELOT (localhost [127.0.0.1])
       by sp1n293en1.watson.ibm.com (8.11.7-20030924/8.11.7/8.11.7-01-14-2004) with SMTP id i6TCHNn65728;
       Thu, 29 Jul 2004 08:17:23 -0400
Message-ID: <[email protected]>
From: "David F. Bacon" <[email protected]>
To: "Carl Baltrunas" <[email protected]>,
  "Tops-20 Wizards" <[email protected]>
References: <[email protected]>
Subject: Re: Listings and scanning?
Date: Thu, 29 Jul 2004 08:17:24 -0400
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.1409
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409

That would have been RSTS.

32767 END
----- Original Message -----
From: "Carl Baltrunas" <[email protected]>
To: "Tops-20 Wizards" <[email protected]>
Sent: Wednesday, July 28, 2004 11:48 PM
Subject: Listings and scanning?


> Hi everyone,
>
> I was digging through my attic and storage locker for some exhibits to
> show at a presentation tomorrow and came across a number of old
> listings.  Of interest to this group would be the ITS Microcode from
> 1976.  I also have a couple of GT-40 program listings, including one I
> was working on when I left the last place I worked that had a GT-40.
>
> Anyone interested in scanning the listings in, let me know, and I'll
> see what I can make available.  I have a few boxes of listings that I
> didn't go through in storage, and if someone is interested, I will try
> to make a list of what I have.  Obviously, my own programs, I'm not
> concerned with, just the things that would be of interest to other 10 &
> 20 people.
>
> I also have some punch cards and paper tapes with programs on them, if
> anyone still has a working reader.  I know a couple of the more
> meaningless programs are from circa 1972, on one of the PDP-11 OSs
> which name escapes me... it's command structure was regular BASIC
> commands.  I must be getting old, since I don't recall the name of the
> OS.
>
> -Carl
>
29-Jul-2004 07:48:24-PDT,1265;000000000000
Return-Path: <[email protected]>
Received: from sccrmhc12.comcast.net ([204.127.202.56]) by lingling.panda.com with TCP/SMTP; Thu, 29 Jul 2004 07:37:07 -0700 (PDT)
Received: from [10.0.1.2] (h000393e155ff.ne.client2.attbi.com[24.218.204.6])
         by comcast.net (sccrmhc12) with ESMTP
         id <2004072914370701200jra5qe>
         (Authid: pwex);
         Thu, 29 Jul 2004 14:37:07 +0000
Mime-Version: 1.0
X-Sender:  (Unverified)
Message-Id: <p06110401bd2ebafdfe9a@[10.0.1.2]>
In-Reply-To: <[email protected]>
References: <[email protected]>
<[email protected]>
Date: Thu, 29 Jul 2004 10:37:05 -0400
To: "Tops-20 Wizards" <[email protected]>
From: Paul Wexelblat <[email protected]>
Subject: Re: Listings and scanning?
Content-Type: text/plain; charset="us-ascii" ; format="flowed"

Gee, if anyone wants to do scanning, I've got a copy of my
DECsystem-10 System Engineer course upstairs in the attic somewhere
if anyone wants to do that too. (I went from the Monitor Group to Ed
Services for a while - wrote a Data Comm course too.)


--
--
        ...wex

(PMW on the Monitor listings - SCNSER guy after RCC)
2-Aug-2004 20:29:36-PDT,1947;000000000000
Return-Path: <[email protected]>
Received: from mxout4.cac.washington.edu ([140.142.33.19]) by lingling.panda.com with TCP/SMTP; Mon, 2 Aug 2004 20:19:22 -0700 (PDT)
Received: from smtp.washington.edu (smtp.washington.edu [140.142.32.139])
       by mxout4.cac.washington.edu (8.13.0+UW04.06/8.13.0+UW04.06) with ESMTP id i733JNOw019943;
       Mon, 2 Aug 2004 20:19:23 -0700
Received: from Shimo-Tomobiki.Panda.COM (pool.dsl.179.081.cvinternet.net [209.161.179.81])
       (authenticated bits=0)
       by smtp.washington.edu (8.13.0+UW04.06/8.13.0+UW04.06) with ESMTP id i733JEMo012535
       (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT);
       Mon, 2 Aug 2004 20:19:22 -0700
Date: Mon, 2 Aug 2004 20:19:10 -0700 (Pacific Daylight Time)
From: Mark Crispin <[email protected]>
To: [email protected]
cc: [email protected]
Subject: Re: MLFL, MAIL, MSND, MSOM, MSAM, MRSQ, MRCP
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

On Tue, 27 Jul 2004 [email protected] wrote:
> These keywords, along
> with MLFL, MAIL, and MRSQ are all for sending mail.  Sending mail??
> What was SMTP for?  Does anybody have any historical background on
> this?

In the old days (pre-1983) of NCP instead of TCP, mail was sent using the
FTP protocol.  SMTP was spawned off as a separate protocol, but was never
widely used in NCP.

> At this point, I think I am probably going to flush
> them.  Anybody have any major objections?

Yes, flush them.  TCP based FTP servers should not do mail.

-- Mark --

http://staff.washington.edu/mrc
Science does not emerge from voting, party politics, or public debate.
Si vis pacem, para bellum.
3-Aug-2004 15:33:05-PDT,3786;000000000000
Return-Path: <[email protected]>
Received: from mta9.srv.hcvlny.cv.net ([167.206.5.42]) by lingling.panda.com with TCP/SMTP; Tue, 3 Aug 2004 15:21:06 -0700 (PDT)
Received: from optonline.net (mstr3.srv.hcvlny.cv.net [167.206.5.14])
by mta9.srv.hcvlny.cv.net
(iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar  3 2004))
with ESMTP id <[email protected]> for
[email protected]; Tue, 03 Aug 2004 18:20:59 -0400 (EDT)
Received: from [167.206.5.46] (Forwarded-For: [216.179.91.114])
by mstr3.srv.hcvlny.cv.net (mshttpd); Tue, 03 Aug 2004 18:20:11 -0400
Date: Tue, 03 Aug 2004 18:20:11 -0400
From: [email protected]
Subject: MDTM and SIZE for TVFS
To: [email protected]
Message-id: <[email protected]>
MIME-version: 1.0
X-Mailer: iPlanet Messenger Express 5.2 HotFix 1.25 (built Mar  3 2004)
Content-type: text/plain; charset=us-ascii
Content-language: en
Content-transfer-encoding: 7BIT
Content-disposition: inline
X-Accept-Language: en
Priority: normal

I'm not sure if this message got dropped by my mailer, but I never
got a copy of it via the mailing list on Lingling, so I'm sending it
again.  My PROFUSE apologies to anybody who gets it twice.

I've been working on implementing Trivial Virtual File System (TVFS)
support for EFTPSR.  While I have by no means completed a general case
TVFS parser, I have done a few trivial cases, such as "."  and ".."
The SIZE command came along nicely:

0) For the trivial case of a local existing file, I report the size
   in local bytes (i.e., I make no attempt whatsoever to convert the
   total size into eight bit bytes).

1) SIZE will parse for a directory specification.  If one is
   recognized, the SIZE will return the number of PAGES in use in
   the directory.

   The remote client is expected to NOT care about the difference
   in units between files bytes and directory pages.   The remote
   user is expected to understand that these figures are
   analogous to the blocks reported by Unix for directory files.

2) If SIZE 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).  I.e., PS:<FOO>BAR.DIRECTORY becomes
   PS:<FOO.BAR> and I do a GTDAL% on that.

3) If the requested directory in question is ROOT-DIRECTORY, then
   SIZE will report the total pages in use on the referenced
   structure.  This allows SIZE .. to work when in "/TOPS20/FOO"

I guess when I am in "/", I could do a GDSKC% for all the mounted
structures.  However, MDTM ...  It wants to return the last
modification time of a file.  I can pull .FBWRT from the directory
just fine and use that (after fixing any Unix epoch issues).

For NUL:, I report the current time of day for "." and the time that
EFTPSR started for "..".  These seemed as good numbers as any.

But for directories?  .? ..?  Structures?  I can't seem to find
something reasonable.  When I do a CRDIR% on an existing directory,
the associated directory file's .FBWRT is not updated.  That's not a
particularly good idea, either, as I may not be able to get a handle
on a superior directory file.

For now, I report the last login time for "." , which won't work for a
files only directory.  For "..", I report the boot time of the system.
It's something, I guess, but I find it unsatisfying.  Anybody have any
better ideas?  Mount times?  I believe that MOUNTR would (or could be
made to) know this, but I don't believe that any command was ever made
in OPR to return it.  I didn't immediately notice anything in GETJI%,
GETAB% or TMON% that would be applicable.






3-Aug-2004 16:25:15-PDT,2927;000000000000
Return-Path: <[email protected]>
Received: from mta2.srv.hcvlny.cv.net ([167.206.5.68]) by lingling.panda.com with TCP/SMTP; Tue, 3 Aug 2004 16:15:25 -0700 (PDT)
Received: from optonline.net (mstr3.srv.hcvlny.cv.net [167.206.5.14])
by mta2.srv.hcvlny.cv.net
(iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar  3 2004))
with ESMTP id <[email protected]> for
[email protected]; Tue, 03 Aug 2004 19:15:22 -0400 (EDT)
Received: from [167.206.5.139] (Forwarded-For: [216.179.91.114])
by mstr3.srv.hcvlny.cv.net (mshttpd); Tue, 03 Aug 2004 19:14:30 -0400
Date: Tue, 03 Aug 2004 19:14:30 -0400
From: [email protected]
Subject: Re: MLFL, MAIL, MSND, MSOM, MSAM, MRSQ, MRCP
To: Mark Crispin <[email protected]>
Cc: [email protected]
Message-id: <[email protected]>
MIME-version: 1.0
X-Mailer: iPlanet Messenger Express 5.2 HotFix 1.25 (built Mar  3 2004)
Content-type: text/plain; charset=us-ascii
Content-language: en
Content-transfer-encoding: 7BIT
Content-disposition: inline
X-Accept-Language: en
Priority: normal

> In the old days (pre-1983) of NCP instead of TCP, mail was sent
> using the  FTP protocol.  SMTP was spawned off as a separate
> protocol, but was never widely used in NCP.

Are you aware of ANY machines that might still need/want to use these
commands?  For example, the SCO UNIX Release 3.2v5.0.5 FTP server
still seems to know about these, although it DOES say that they are
not implemented.  Ditto for Debian 6.4/OpenBSD/Linux-ftpd-0.17.
Windows 2000 doesn't seem to have any recollection of them.

If it helped talking to some random machine (maybe ITS?) or otherwise
gave Tops-20 some more bragging rights, perhaps they might be
worthwhile to revisit at some point.  Since the mail ids were all
local and are parsed one at a time, at first glance, it didn't look
like it would be a big deal to the code.  Also, I am a BIG fan of
regression testing ...

> > At this point, I think I am probably going to flush
> > them.  Anybody have any major objections?
>
> Yes, flush them.  TCP based FTP servers should not do mail.

What about non-TCP based FTP servers?  The server control fork does
not use any TCP based calls at all.  I don't believe that there would
be any (or much) work involved getting it to run on DECnet, Chaos, Pup
or anything else (IP6??).

Should I consider keeping any of this stuff for these other protocols?
I don't believe that I need to because I believe that, at least under
Tops-20, there are SMTP MTAs for each protocol.

Finally, although SMTP is clearly the more modern way to deliver
email, there was one thing about using FTP to do this that I did like
and that we might want to think about.  In order to send mail with
FTP, you have to have a valid id and password.  Absent ANONYMOUS
usage, this would seem to make SPAM harder to do.


3-Aug-2004 17:48:26-PDT,1255;000000000000
Return-Path: <[email protected]>
Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by lingling.panda.com with TCP/SMTP; Tue, 3 Aug 2004 17:37:32 -0700 (PDT)
Received: from rtp-core-1.cisco.com (64.102.124.12)
 by rtp-iport-1.cisco.com with ESMTP; 03 Aug 2004 20:44:55 -0400
X-BrightmailFiltered: true
Received: from cisco.com (cypher.cisco.com [171.69.11.142])
       by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i740ZxSw028462;
       Tue, 3 Aug 2004 20:37:29 -0400 (EDT)
Received: (from billw@localhost)
       by cisco.com (8.8.8-Cisco List Logging/8.8.8) id RAA11363;
       Tue, 3 Aug 2004 17:07:22 -0700 (PDT)
Sender: Bill Westfield <[email protected]>
Date: Tue, 3 Aug 2004 17:07:22 PDT
From: William "Chops" Westfield <[email protected]>
To: [email protected]
Cc: Mark Crispin <[email protected]>, [email protected]
Subject: Re: MLFL, MAIL, MSND, MSOM, MSAM, MRSQ, MRCP
In-Reply-To: Your message of Tue, 03 Aug 2004 19:14:30 -0400
Message-ID: <CMM.0.90.4.1091578042.billw@cypher>

Weren't there a couple of system that still used FTP for the "send" command
("send [email protected] DinnerP")?  I think there were "issues" getting such
commands through the (generally queue-based) SMTP servers in a timely manner.

BillW
4-Aug-2004 22:01:33-PDT,1792;000000000000
Mail-From: MRC created at  4-Aug-2004 21:50:45
Date: Wed, 4 Aug 2004 21:50:45 -0700 (PDT)
From: Mark Crispin <[email protected]>
Subject: Re: MLFL, MAIL, MSND, MSOM, MSAM, MRSQ, MRCP
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]>

> Are you aware of ANY machines that might still need/want to use these
> commands?

Nothing since 1982, or at least when the last NCP reclama was
pulled.

FTP should not be in the business of mailing or sending.

> If it helped talking to some random machine (maybe ITS?) or otherwise
> gave Tops-20 some more bragging rights, perhaps they might be
> worthwhile to revisit at some point.

Nope.  ITS used proper SMTP.

> > Yes, flush them.  TCP based FTP servers should not do mail.
> What about non-TCP based FTP servers?

NCP has been dead since the last ARPAnet NCP reclama was pulled
in 1983.  Death to mail commands in the FTP protocol.  Please.

Even DECnet ended up having SMTP.

Pup had its own FTP and Mail protocol which was completely different.

> Finally, although SMTP is clearly the more modern way to deliver
> email, there was one thing about using FTP to do this that I did like
> and that we might want to think about.  In order to send mail with
> FTP, you have to have a valid id and password.  Absent ANONYMOUS
> usage, this would seem to make SPAM harder to do.

SMTP has SASL now.

There is no benefit to mail or send in FTP, and there are many
demerits.  As the mailsystem maintainer, I ask you not to
reimplement something that I and many other people worked hard to
kill over 20 years ago.
-------
5-Aug-2004 09:05:43-PDT,2892;000000000000
Return-Path: <[email protected]>
Received: from mta6.srv.hcvlny.cv.net ([167.206.5.72]) by lingling.panda.com with TCP/SMTP; Thu, 5 Aug 2004 08:54:25 -0700 (PDT)
Received: from optonline.net (mstr3.srv.hcvlny.cv.net [167.206.5.14])
by mta6.srv.hcvlny.cv.net
(iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar  3 2004))
with ESMTP id <[email protected]>; Thu,
05 Aug 2004 11:54:17 -0400 (EDT)
Received: from [167.206.5.80] (Forwarded-For: [216.179.91.114])
by mstr3.srv.hcvlny.cv.net (mshttpd); Thu, 05 Aug 2004 11:53:13 -0400
Date: Thu, 05 Aug 2004 11:53:13 -0400
From: [email protected]
Subject: Re: MLFL, MAIL, MSND, MSOM, MSAM, MRSQ, MRCP
To: Mark Crispin <[email protected]>
Cc: [email protected]
Message-id: <[email protected]>
MIME-version: 1.0
X-Mailer: iPlanet Messenger Express 5.2 HotFix 1.25 (built Mar  3 2004)
Content-type: text/plain; charset=us-ascii
Content-language: en
Content-transfer-encoding: 7BIT
Content-disposition: inline
X-Accept-Language: en
Priority: normal

> Nothing since 1982, or at least when the last NCP reclama was
> pulled.

What's a reclama?  Is that another word for an IMP?

> NCP has been dead since the last ARPAnet NCP reclama was pulled in
> 1983.  Death to mail commands in the FTP protocol.  Please.

Death to RFC765!  Death to FTP mail commands!  Death to TCPSIM!!!
You're not waffling on me, are you?  :-)  Oh well, I'm sure all of
this was wonderful at some point to somebody ...  Err, wasn't it?

> Even DECnet ended up having SMTP.

Yup, if I remember correctly, Kenga did some of the early (original)
work on MMAILR back in the bad old days before CU20B and friends were
on the ARPAnet.  Our (single) VAX didn't speak SMTP at the time, it
did some other different VAX mail thingie.  Naturally.

> Pup had its own FTP and Mail protocol which was completely different.

Pup popped into my mind because of the following.  After I (or if I
ever) get done (enough) with EFTPSR, I will probably want to take a
another look at the FTP client.  I don't know if I actually need to do
this, but it would give me a reason to have FTP fork up EFTPSR and
then talk to it via pipes.  A hackerly activity, surely to be lauded.

> SMTP has SASL now.

Ah, RFC2554?  Another RFC I hadn't known anything about.  Any day
dreams about putting AUTH into MAISER?

> As the mailsystem maintainer, I ask you not to reimplement something
> that I and many other people worked hard to kill over 20 years ago.

Not a problem, I only had hooks for the commands and help text
written.  It has been 'officially' flushed, never to return.  I just
wanted to be deeply sure before I got rid of something that somebody
might have wanted.  I wonder why it was still sticking around in
FTPSER?  Or maybe I shouldn't wonder at all ...



5-Aug-2004 09:44:39-PDT,1952;000000000000
Return-Path: <[email protected]>
Received: from sesame.cc.columbia.edu ([128.59.59.56]) by lingling.panda.com with TCP/SMTP; Thu, 5 Aug 2004 09:34:34 -0700 (PDT)
Received: from sesame.cc.columbia.edu (localhost [127.0.0.1])
       by sesame.cc.columbia.edu (8.13.0/8.12.11) with ESMTP id i75GYJnM016428;
       Thu, 5 Aug 2004 12:34:19 -0400 (EDT)
Received: (from fdc@localhost)
       by sesame.cc.columbia.edu (8.13.0/8.12.8/Submit) id i75GYIIU016427;
       Thu, 5 Aug 2004 12:34:18 -0400 (EDT)
Date: Thu, 5 Aug 2004 12:34:18 EDT
From: Frank da Cruz <[email protected]>
To: [email protected]
Cc: Mark Crispin <[email protected]>, [email protected]
Subject: Re: MLFL, MAIL, MSND, MSOM, MSAM, MRSQ, MRCP
In-Reply-To: <[email protected]>
Message-ID: <CMM.0.91.0.1091723658.fdc@sesame>

> > Even DECnet ended up having SMTP.
>
> Yup, if I remember correctly, Kenga did some of the early (original)
> work on MMAILR back in the bad old days before CU20B and friends were
> on the ARPAnet.  Our (single) VAX didn't speak SMTP at the time, it
> did some other different VAX mail thingie.  Naturally.
>
As I recall DECnet mail pre-SMTP was essentially:

 copy /append <message> node::<user's-mailbox>

so if "node" wasn't up, the send failed.  There was no queuing. Not a
great security model either.  I'm pretty sure we wrote a replacement that
at least did the queuing.

For mainframes our CU20B mailer actually constructed a "deck of cards"
complete with JCL and "punched" it over our DN20-based HASP station to the
mainframe's "reader".  Incoming mail from that side showed up as 132-column
print jobs.  From 1982 to 1988, CU20B served as an ARPANET-CCNET-BITNET
gateway and routed a lot of traffic.  (CCNET was our own DECnet network of
Columbia, CMU, NYU, a bunch of universities in Ohio, and some others.)

There's probably something about all this in Quarterman's book, The Matrix.

- Frank
5-Aug-2004 10:44:22-PDT,2666;000000000000
Return-Path: <[email protected]>
Received: from zravo.cc.columbia.edu ([128.59.59.176]) by lingling.panda.com with TCP/SMTP; Thu, 5 Aug 2004 10:34:12 -0700 (PDT)
Received: from zravo.cc.columbia.edu (localhost [127.0.0.1])
       by zravo.cc.columbia.edu (8.13.0/8.12.11) with ESMTP id i75HYCxj011095;
       Thu, 5 Aug 2004 13:34:12 -0400 (EDT)
Received: (from www@localhost)
       by zravo.cc.columbia.edu (8.13.0/8.12.3/Submit) id i75HYCep011094;
       Thu, 5 Aug 2004 13:34:12 -0400 (EDT)
Received: from internet1.pearsontc.com (internet1.pearsontc.com [198.4.159.6])
       by cubmail.cc.columbia.edu (IMP) with HTTP
       for <[email protected]>; Thu,  5 Aug 2004 13:34:12 -0400
Message-ID: <[email protected]>
Date: Thu,  5 Aug 2004 13:34:12 -0400
From: [email protected]
To: Frank da Cruz <[email protected]>, [email protected]
Subject: Re: MLFL, MAIL, MSND, MSOM, MSAM, MRSQ, MRCP
References: <CMM.0.91.0.1091723658.fdc@sesame>
In-Reply-To: <CMM.0.91.0.1091723658.fdc@sesame>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
User-Agent: Internet Messaging Program (IMP) 3.2.5
X-Originating-IP: 198.4.159.6

Quoting Frank da Cruz <[email protected]>:
> > > Even DECnet ended up having SMTP.
> >
> > Yup, if I remember correctly, Kenga did some of the early
> > (original) work on MMAILR back in the bad old days before
> > CU20B and friends were on the ARPAnet.

MMAILR was written well enough that it made it surprisingly easy
(and fun) to retrofit DECnet support into it.  I vaguely remember
doing that stuff...

> > Our (single) VAX didn't speak SMTP at the time, it did some
> > other different VAX mail thingie.  Naturally.
>
> As I recall DECnet mail pre-SMTP was essentially:
>
>   copy /append <message> node::<user's-mailbox>
>
> so if "node" wasn't up, the send failed.  There was no queuing.

Yep, good old VAX/VMS MAIL.  A stunningly forward-looking piece
of software if ever I saw one...

> For mainframes our CU20B mailer actually constructed a "deck of
> cards" complete with JCL and "punched" it over our DN20-based
> HASP station to the mainframe's "reader".

(with real megnetic core memory, no less :-)

> Incoming mail from that side showed up as 132-column print jobs.
> From 1982 to 1988, CU20B served as an ARPANET-CCNET-BITNET
> gateway and routed a lot of traffic.  (CCNET was our own DECnet
> network of Columbia, CMU, NYU, a bunch of universities in Ohio,
> and some others.)

Boy, what a lot of bending over backwards to get what really
amounts to a very simple job done.  :-) :-)

Ken(ga)
5-Aug-2004 13:52:08-PDT,1358;000000000000
Return-Path: <[email protected]>
Received: from sj-iport-3.cisco.com ([171.71.176.72]) by lingling.panda.com with TCP/SMTP; Thu, 5 Aug 2004 13:41:11 -0700 (PDT)
Received: from sj-core-5.cisco.com (171.71.177.238)
 by sj-iport-3.cisco.com with ESMTP; 05 Aug 2004 13:43:49 +0000
X-BrightmailFiltered: true
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 i75Kf1VD016126;
       Thu, 5 Aug 2004 13:41:01 -0700 (PDT)
Received: (from billw@localhost)
       by cisco.com (8.8.8-Cisco List Logging/8.8.8) id NAA04358;
       Thu, 5 Aug 2004 13:41:01 -0700 (PDT)
Sender: Bill Westfield <[email protected]>
Date: Thu, 5 Aug 2004 13:41:01 PDT
From: William "Chops" Westfield <[email protected]>
To: [email protected]
Cc: Mark Crispin <[email protected]>, [email protected]
Subject: Re: MLFL, MAIL, MSND, MSOM, MSAM, MRSQ, MRCP
In-Reply-To: Your message of Thu, 05 Aug 2004 11:53:13 -0400
Message-ID: <CMM.0.90.4.1091738461.billw@cypher>

   Death to RFC765!  Death to FTP mail commands!  Death to TCPSIM!!!
   You're not waffling on me, are you?  :-)  Oh well, I'm sure all of
   this was wonderful at some point to somebody ...  Err, wasn't it?

Yes, the ARPANet prior to TCP was still wonderful.  You have to compare it
to the alternatives available at the time...

BillW

7-Aug-2004 21:23:02-PDT,3296;000000000000
Return-Path: <[email protected]>
Received: from mta6.srv.hcvlny.cv.net ([167.206.5.72]) by lingling.panda.com with TCP/SMTP; Sat, 7 Aug 2004 21:12:03 -0700 (PDT)
Received: from optonline.net (mstr3.srv.hcvlny.cv.net [167.206.5.14])
by mta6.srv.hcvlny.cv.net
(iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar  3 2004))
with ESMTP id <[email protected]> for
[email protected]; Sun, 08 Aug 2004 00:11:57 -0400 (EDT)
Received: from [167.206.5.139] (Forwarded-For: [216.179.91.114])
by mstr3.srv.hcvlny.cv.net (mshttpd); Sun, 08 Aug 2004 00:10:50 -0400
Date: Sun, 08 Aug 2004 00:10:50 -0400
From: [email protected]
Subject: One word global byte pointer P&S 39 and 40
To: [email protected]
Message-id: <[email protected]>
MIME-version: 1.0
X-Mailer: iPlanet Messenger Express 5.2 HotFix 1.25 (built Mar  3 2004)
Content-type: text/plain; charset=us-ascii
Content-language: en
Content-transfer-encoding: 7BIT
Content-disposition: inline
X-Accept-Language: en
Priority: normal

I've been rewriting some of my FTP server byte translation routines
for speed.  In particular, for the (7 bit) ASCII to (8 bit)
translation for representation type 'A', I am doing the work using the
MOVSLJ EXTEND instruction.

Because SOUTR% wants a one word (global for my use) pointer and MOVSLJ
converts single word pointers to double words, I have to do some
pointer conversion.  I do this with a look up table.

While I was doing this, I noticed what I think may be a documentation
bug in the 1982 Processor Reference Manual.  In the Section User
Operations on Page 2-85, note the following:

        P&S     P    S
        ===    ==   ==
         37    36    6    ;  6 Bit Byte Pointers
         38    30    6
         39    24    6    <=====
         40    28    6    <=====
         41    12    6
         42     6    6
         43     0    6
         49    36    7    ;  7 Bit Byte Pointers
         50    29    7
         51    22    7
         52    15    7
         53     8    7
         54     1    7
         44    36    8    ;  8 Bit Byte Pointers
         45    28    8
         46    20    8
         47    12    8
         48     4    8
         55    36    9    ;  9 Bit Byte Pointers
         56    27    9
         57    18    9
         58     9    9
         59     0    9
         60    36   18    ; 18 Bit Byte Pointers
         61    18   18
         62     0   18

P&S is the one word global pointer magic number, P is the two word
byte pointer byte position and S is the two word byte pointer size of
the byte.  I don't use 6 bit pointers anywhere, but it seems that
entries 39 and 40 are swapped.  Shouldn't P&S entry 39 be position 28
and P&S entry 40 be 24?  I haven't looked at it any, but it seems
logical.

I am using global pointers in order to have very large buffers.  My
input and output buffers are variable sized, up to a section.  At 512
pages, I can translate an ASCII file to NVT ASCII with a single PMAP,
MOVSLJ and SOUTR% sequence.  Thus far, I am seeing nearly a four-fold
increase in FTP transfer speed.  Nice, but I probably would have been
throttled for using that much memory 20 years ago.


8-Aug-2004 00:47:49-PDT,1535;000000000000
Return-Path: <[email protected]>
Received: from nic.cafax.se ([192.71.228.17]) by lingling.panda.com with TCP/SMTP; Sun, 8 Aug 2004 00:36:34 -0700 (PDT)
Received: from nic.cafax.se (localhost [127.0.0.1])
       by nic.cafax.se (8.12.11/8.12.11) with ESMTP id i787aV6W023830
       for <[email protected]>; Sun, 8 Aug 2004 09:36:31 +0200 (MEST)
Received: (from bygg@localhost)
       by nic.cafax.se (8.12.11/8.12.11/Submit) id i787aVuf016105
       for [email protected]; Sun, 8 Aug 2004 09:36:31 +0200 (MEST)
Date: Sun, 8 Aug 2004 9:36:31 WET DST
From: Johnny Eriksson <[email protected]>
To: [email protected]
Subject: Re: One word global byte pointer P&S 39 and 40
In-Reply-To: Your message of Sun, 08 Aug 2004 00:10:50 -0400
Message-ID: <[email protected]>

[email protected] wrote:

>          P&S     P    S
>          ===    ==   ==
>           37    36    6    ;  6 Bit Byte Pointers
>           38    30    6
>           39    24    6    <=====
>           40    28    6    <=====
>
> [...]
>
> P&S is the one word global pointer magic number, P is the two word
> byte pointer byte position and S is the two word byte pointer size of
> the byte.  I don't use 6 bit pointers anywhere, but it seems that
> entries 39 and 40 are swapped.  Shouldn't P&S entry 39 be position 28
> and P&S entry 40 be 24?  I haven't looked at it any, but it seems
> logical.

Not quite, but the P value for 40 should be 18, not 28.  The XKL
processor manual has this corrected.

--Johnny
23-Aug-2004 18:40:46-PDT,3968;000000000000
Return-Path: <[email protected]>
Received: from mta9.srv.hcvlny.cv.net ([167.206.5.42]) by lingling.panda.com with TCP/SMTP; Mon, 23 Aug 2004 18:29:08 -0700 (PDT)
Received: from optonline.net (mstr3.srv.hcvlny.cv.net [167.206.5.14])
by mta9.srv.hcvlny.cv.net
(iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar  3 2004))
with ESMTP id <[email protected]> for
[email protected]; Mon, 23 Aug 2004 21:28:36 -0400 (EDT)
Received: from [167.206.5.135] (Forwarded-For: [24.184.174.68])
by mstr3.srv.hcvlny.cv.net (mshttpd); Mon, 23 Aug 2004 21:28:36 -0400
Date: Mon, 23 Aug 2004 21:28:36 -0400
From: [email protected]
Subject: KL-10/KLH-10 NI & Toad Ethernet Interface Speeds
To: [email protected]
Message-id: <[email protected]>
MIME-version: 1.0
X-Mailer: iPlanet Messenger Express 5.2 HotFix 1.25 (built Mar  3 2004)
Content-type: text/plain; charset=us-ascii
Content-language: en
Content-transfer-encoding: 7BIT
Content-disposition: inline
X-Accept-Language: en
Priority: normal

I have been doing some speed tests for my FTPSER rewrite.  I have a
couple of questions concerning interface (and media) speeds for the
the KL-10 NI, the KLH NI and (if anybody knows) the Toad.  Does
anybody remember what the maximum speed of the NI media was?  I seem
to remember it being about 3 megabits per second.  If that were the
case, then I believe that the maximum throughput that I could expect
to achieve would around 384 KB/s.

Here is roughly where things stand: I have written special case code
for ASCII (7) and logical 8, 16, 24 and 32 bit upload (RETR).  I have
to finish up the general byte packing code for the cases of the other
bit widths (like 36).  I've run some tests and--thus far--the results
seem to be encouraging.  Here are some figures for uploads with a 458
page file, all numbers are in kilobytes per second (KB/s):

        Type      A       L8     L16     L24     L32
       ======  ======  ======  ======  ======  ======
 Old   FTPSER   60.61   58.44   56.26   56.68   61.23
 New   EFTPSR  232.68  255.13  180.41  198.92  255.13

It looks like the slowest speed up that I am getting is over a factor
of three.  L16, L24 and L32 use a shift and deposit loop, which is
what the old FTPSER 5Z appears to be doing.  The ASCII transfer is
done using a MOVSLJ to do the conversion and L8 and L32 are doing a
straight SOUTR% as no munging is necessary.  I had suspected that the
ASCII and L8 and L32 cases might perform better, but I didn't know how
much better.  I had thought that L16 and L24 would be on a par with
FTPSER, so I don't fully understand why EFTPSR is so much faster.

I'm not sure what to attribute the speed up to, in all cases.  I was
hoping that buffer memory might have something to do with it.  As much
as I am able puzzle out the TCPSIM/FTPSER code, it looks like it is
using about 5 pages for network data buffers.  The buffer memory in
EFTPSR is dynamically configurable at run time (with a SITE command)
for up to a section (512 pages) each for input and output.

By default, I am currently running with 512 pages for input and 512
pages for output.  Isn't memory great?  I would have been shot for
being such a hog back in the day...  However, the performance
improvement clearly isn't all just due to the larger buffers; I can
cut the buffer memory back to a single (1) page and my best case (L 8)
output speed only drops by 25% ...

So, if my memory is correct about the NI speeds, it would appear that
I am doing about two thirds of the media maximum.  As a comparison, I
am doing 13,446.15 KB/s for an image (L 8) transfer between a Windows
and a Linux box on the same (100BaseT) backbone.  Finally, I briefly
perused through some of the monitor code and it looks like further
speed ups might be possible there, also (some byte loops might be able
to be replaced with MOVSLJ).


25-Aug-2004 10:49:29-PDT,3092;000000000000
Return-Path: <[email protected]>
Received: from Ikkoku-Kan.Panda.COM (panda.com [206.124.149.114]) by lingling.panda.com with TCP/SMTP; Wed, 25 Aug 2004 10:38:23 -0700 (PDT)
Received: from localhost (mrc@localhost) by Ikkoku-Kan.Panda.COM id KAA28600; Wed, 25 Aug 2004 10:38:20 -0700 (PDT)
Date: Wed, 25 Aug 2004 10:38:19 -0700 (PDT)
From: Mark Crispin <[email protected]>
Sender: [email protected]
To: [email protected]
cc: [email protected]
Subject: Re: KL-10/KLH-10 NI & Toad Ethernet Interface Speeds
In-Reply-To: <[email protected]>
Message-ID: <[email protected]>
References: <[email protected]>
Organization: Pandamonium Reigns
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed

On Mon, 23 Aug 2004 [email protected] wrote:
> It looks like the slowest speed up that I am getting is over a factor
> of three.  L16, L24 and L32 use a shift and deposit loop, which is
                      ^^^^^^^ ???
> what the old FTPSER 5Z appears to be doing.  The ASCII transfer is
> done using a MOVSLJ to do the conversion and L8 and L32 are doing a
> straight SOUTR% as no munging is necessary.

Don't you mean that "A does MOVSLJ, L16 and L24 do a shift/deposit loop,
and L8 and L32 do SOUTR%"?

It's been years since I looked at FTP, so these questions may not make
sense:

Why can't L16 also do a SOUTR%?  I doubt that the monitor handles 16-bit
pointers for the TCP: device, but you can just use an 8-bit pointer and
make sure that the overall byte count ends up is even (if not, add a null
byte at the end).

What is the point of a special implementation of L24?  L16 also seems
pointless except that is trivial.  The only sizes that seem useful to me
are L8, L32, and L36; and of these L8 is the most important.

Note that for a TOPS-20 FTP server, TYPE A means 7-bit and TYPE I means
36-bit (9 octets for a doubleword).

Of course, it's very important to get 36-bit transfers as fast as
possible.  You may have to play with various byte-blt algorithms until you
find the one that's fastest.  Here's a pretty simple-minded one to
convert 8 36-bit words into 9 32-bit words:
       MOVSI 10,FOO
       BLT 10,FOO+7
       LSHC 7,-D32             ; 10/ bytes 33-36
       LSH 7,^D32
       LSHC 6,-^D28            ;  7/ bytes 29-32
       LSH 6,^D28
       LSHC 5,-^D24            ;  6/ bytes 25-28
       LSH 5,^D24
       LSHC 4,-^D20            ;  5/ bytes 21-24
       LSH 4,^D20
       LSHC 3,-^D16            ;  4/ bytes 17-20
       LSH 3,^D16
       LSHC 2,-^D12            ;  3/ bytes 13-16
       LSH 2,^D12
       LSHC 1,-^D8             ;  2/ bytes 9-12
       LSH 1,^D8
       LSHC 0,-^D4             ;  1/ bytes 5-8
       LSH 0,^D4
       MOVEI 11,BAR
       BLT 11,BAR+^D8

> I had thought that L16 and L24 would be on a par with
> FTPSER, so I don't fully understand why EFTPSR is so much faster.

FTPSER was pretty crufty.  I'm not surprised that you could do a better
job.

-- 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.
25-Aug-2004 14:01:07-PDT,5069;000000000000
Return-Path: <[email protected]>
Received: from mta4.srv.hcvlny.cv.net ([167.206.5.70]) by lingling.panda.com with TCP/SMTP; Wed, 25 Aug 2004 13:48:01 -0700 (PDT)
Received: from optonline.net (mstr3.srv.hcvlny.cv.net [167.206.5.14])
by mta4.srv.hcvlny.cv.net
(iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar  3 2004))
with ESMTP id <[email protected]>; Wed,
25 Aug 2004 16:47:58 -0400 (EDT)
Received: from [167.206.5.45] (Forwarded-For: [216.179.91.114])
by mstr3.srv.hcvlny.cv.net (mshttpd); Wed, 25 Aug 2004 16:47:58 -0400
Date: Wed, 25 Aug 2004 16:47:58 -0400
From: [email protected]
Subject: Re: KL-10/KLH-10 NI & Toad Ethernet Interface Speeds
To: Mark Crispin <[email protected]>
Cc: [email protected]
Message-id: <[email protected]>
MIME-version: 1.0
X-Mailer: iPlanet Messenger Express 5.2 HotFix 1.25 (built Mar  3 2004)
Content-type: text/plain; charset=us-ascii
Content-language: en
Content-transfer-encoding: 7BIT
Content-disposition: inline
X-Accept-Language: en
Priority: normal

MRC,

To correct, clarify and elaborate: for any data transfer, I always
open the TCP: device in 8 bit byte mode.  The SOUTR% for the TCP: data
stream is always given a one word global 8 bit byte pointer, as the
data buffers reside in differet sections.  Other routines are
responsible for doing any appropriate bit conversions.

For a Type A retrieval (the typical client command being ASCII), the
conversion from 7 bit ASCII to 8 bit NVT ASCII is done with a MOVSLJ
with the different byte sizes (width) being specified for the input
and output byte pointers.  Type A is only allowed for 7 bit files and
36 bit files (i.e., text output from PA1050).  I parse for, but do not
implement, Type E (EBCDIC).

Type I and Type L are implemented as follows.  For a store, whatever
is specified for type L is used.  For a store with Type I, the RFC
appears to specify that 8 bit bytes are used for transfer and that the
client and server are to agree on what the byte size is, although how
this is to be done is not directly articulated in the protocol itself.

I have implemented the following heuristic.  When the server is
running TVFS (Unix file names), then the default is 8 bit bytes.  When
the server is NOT running TVFS and the file structure is PAGED, then
36 bit bytes are selected.  Otherwise, 8 bit is assumed.  This allows
the server to properly be side-effected based on the behavior of the
default Windows character mode FTP client, Windows Explorer, gnuEmacs
ange-ftp mode, most Unix FTP clients and the Tops-20 FTP client (which
sets PAGED structure when connecting to a Tops-20 host).

For retrievals, the decision is based as follows: For a Type I, the
byte size of the local file determines the packing.  For Type L, the
specified byte size overrides the local file size.  For the various
byte sizes, they are packed into the output 8 bit byte stream as
follows:

 8 Bit) No translation necessary, 4 bytes per 36 bit word.  Common
        files include most anything from Unix and Windows files:
        JPEG's, Word, Excel and the like.  A direct SOUTR% suffices.
16 Bit) No translation necessary, 2 bytes per 36 bit word.  Common
        files include data from PDP-11's, 8086, 80286.  Common files
        would be CD data which is sampled at 44,100 16 bit bytes.
        A direct SOUTR% suffices (with the input byte count left
        shifted 1 bit).
24 Bit) Shift and deposit, 1 byte per 36 bit word.  This can not be
        directly SOUTR%'ed because the one word global byte pointer
        format does not allow for 24 bit bytes.  Doing a SOUTR% with
        an 8 bit pointer inserts a zero in the output stream at every
        fourth byte.
32 Bit) No translation necessary, 1 byte per 36 bit word.  Common
        files would include data from VMS, MVS, 80386, Interdata.
        There is a stereo digital audio format that uses this stream
        (it's essentially a doubled 16 bit stream).  A direct SOUTR%
        suffices (with the input byte count left shifted 2 bits).

I know that I would use L16 as I have written software that processes
audio.  I also have routines that manage 32 bit numbers (360 floating
point).  I have some other software that implement floating point in
packed decimal using 24 bits, but this is arcane.  I don't recall
whether I ever heard anything about a 24 bit machine or not.  I think
I did.

Other than 36 bits, I believe that the other sizes would be of less
interest to the Internet community at large (or not, what about 9
bits?).  I am currently modeling the packing algorithm as a truncated
matrix transform.  Efficiency is paramount for 36 bits.  However, I'm
sure that I will never be able to touch Type A nor Type L8, L16 or L32
for speed.  Bummer...

Finally, I know that there are one or two NI's left in operation and a
few Toads about.  Anybody care to speak up about the media speeds??
Rich?  Ralph?

                                --T

25-Aug-2004 15:16:33-PDT,2292;000000000000
Return-Path: <[email protected]>
Received: from falcon.mail.pas.earthlink.net ([207.217.120.74]) by lingling.panda.com with TCP/SMTP; Wed, 25 Aug 2004 15:06:01 -0700 (PDT)
Received: from cpe-24-221-177-162.ca.sprintbbd.net ([24.221.177.162] helo=reststop.com)
       by falcon.mail.pas.earthlink.net with esmtp (Exim 3.33 #1)
       id 1C05u4-0002Ft-00; Wed, 25 Aug 2004 15:06:00 -0700
Date: Wed, 25 Aug 2004 15:05:59 -0700
Subject: Re: KL-10/KLH-10 NI & Toad Ethernet Interface Speeds
Content-Type: text/plain; charset=US-ASCII; format=flowed
Mime-Version: 1.0 (Apple Message framework v553)
Cc: Mark Crispin <[email protected]>,
[email protected]
To: [email protected]
From: Carl Baltrunas <[email protected]>
In-Reply-To: <[email protected]>
Message-Id: <[email protected]>
Content-Transfer-Encoding: 7bit
X-Mailer: Apple Mail (2.553)


On Wednesday, August 25, 2004, at 01:47 PM, [email protected] wrote:
>
> I know that I would use L16 as I have written software that processes
> audio.  I also have routines that manage 32 bit numbers (360 floating
> point).  I have some other software that implement floating point in
> packed decimal using 24 bits, but this is arcane.  I don't recall
> whether I ever heard anything about a 24 bit machine or not.  I think
> I did.
>
The SDS/XDS (Xerox) 930 and 940 model computers were 24 bit systems.
We had 21 or so of these at Tymshare, connected to Tymnet.  Before FTP,
we had a file transfer program called TELECOPY which had versions for
The 940s, the PDP-10s (TYMCOM-X/XX), and the 360/370s managed as
part of Tymshare's timesharing services.

I never worked with the early Interdata systems which pre-dated the
32-bit
Tymnet engines, but it's quite possible they were 24 bit also as they
were
used for inter system communication on the XDS-940s in the early days
of Tymnet.

The DEC PDP-12 had an odd word size as well, but I don't recall what it
was.
I just remember the audio department at Gallaudet College having to do
word-size munging to move data between the PDP-12s and the PDP-10s.

Somewhere around here I may have a programming card for the 940.
If I run across it, I'l make it available on my web site.

-Carl

26-Aug-2004 08:23:37-PDT,1062;000000000000
Return-Path: <[email protected]>
Received: from sesame.cc.columbia.edu ([128.59.59.56]) by lingling.panda.com with TCP/SMTP; Thu, 26 Aug 2004 08:12:17 -0700 (PDT)
Received: from sesame.cc.columbia.edu (localhost [127.0.0.1])
       by sesame.cc.columbia.edu (8.13.0/8.12.11) with ESMTP id i7QFCHZq006857;
       Thu, 26 Aug 2004 11:12:17 -0400 (EDT)
Received: (from fdc@localhost)
       by sesame.cc.columbia.edu (8.13.0/8.12.8/Submit) id i7QFCGTM006856;
       Thu, 26 Aug 2004 11:12:16 -0400 (EDT)
Date: Thu, 26 Aug 2004 11:12:16 EDT
From: Frank da Cruz <[email protected]>
To: Carl Baltrunas <[email protected]>
Cc: [email protected], Mark Crispin <[email protected]>,
       [email protected]
Subject: Re: KL-10/KLH-10 NI & Toad Ethernet Interface Speeds
In-Reply-To: <[email protected]>
Message-ID: <CMM.0.91.0.1093533136.fdc@sesame>

> The DEC PDP-12 had an odd word size as well, but I don't recall what it
> was.
>
12 bits of course :-)  See (e.g.):

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

- Frank
14-Sep-2004 09:18:01-PDT,4493;000000000000
Return-Path: <[email protected]>
Received: from mta7.srv.hcvlny.cv.net ([167.206.5.74]) by lingling.panda.com with TCP/SMTP; Tue, 14 Sep 2004 09:08:39 -0700 (PDT)
Received: from optonline.net (mstr3.srv.hcvlny.cv.net [167.206.5.14])
by mta7.srv.hcvlny.cv.net
(iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar  3 2004))
with ESMTP id <[email protected]> for
[email protected]; Tue, 14 Sep 2004 12:08:25 -0400 (EDT)
Received: from [167.206.5.46] (Forwarded-For: [24.184.174.68])
by mstr3.srv.hcvlny.cv.net (mshttpd); Tue, 14 Sep 2004 12:08:25 -0400
Date: Tue, 14 Sep 2004 12:08:25 -0400
From: [email protected]
Subject: How's your TOD?
To: [email protected]
Message-id: <[email protected]>
MIME-version: 1.0
X-Mailer: iPlanet Messenger Express 5.2 HotFix 1.25 (built Mar  3 2004)
Content-type: text/plain; charset=us-ascii
Content-language: en
Content-transfer-encoding: 7BIT
Content-disposition: inline
X-Accept-Language: en
Priority: normal

I don't usually check (nor care about) my time of day (TOD) clock.
However, around late May of this year, I noticed that my TOD clock was
running a number of minutes slow.  Since I didn't remember the last
time or if I had ever reset it since boot time, I knocked together a
short batch job to synch the TOD clock.  It runs every three days
unless there is a problem, in which case it keeps trying every hour to
do its thing.

Since late May, the batch job has run 35 times and the average time
difference is just about -7.03 seconds (i.e., slow) every 72 hours.
That figure gets WORSE as I put more load on the machine.  I don't
remember what the drift was for the KL (or the KA) clocks, but I do
know that we did indeed reset ours every so often.  However, I don't
recall whether this was because we really needed to or it was just
because we were being perfectionists.  In any event, as I am not using
the 20 as a time source, I don't think that I should care much about
it.  Er, right?

At least for the system code which cares about the time of day that I
am aware of, futzing with the TOD clock doesn't appear to directly
break anything.  In Galaxy, for the I%SLP routine in GLXINT, on a
return from a sleep, the time of day is gotten and compared against
the first entry in an ordered list, so that works.  In Tops-20 itself,
for the TIMSCM and TIMSCD scheduler tests in TIMER, TODCLK is checked
against an ordered list.  The right thing appears to happen for DISMS%
in SCHED, also.  However, for (errorneous) programs that purely
depended on what they specified without checking, there could
obviously be a problem.

Has anybody noticed this or know more anything about it?  Is it any
sort of a big deal?  Here is the batch job and other information,
below:

! Don't allow wrap so our silly message isn't silly AND ugly !
@Terminal Width 0
! [TOMMYT]PS:<OPERATOR>TIMCHK.CTL.1, 22-May-2004 20:37:49, by SLOGIN   !
! Over time, the hardware clock on the KLH10 microengine appears to be !
! inaccurate (or it is seeded with an incorrect value from the         !
! operating system that is hosting the microengine).  As an example,   !
! once Tommy Timesharing had been up over 450 hours, the system date   !
! had drifted by 2 minutes and 33 seconds.  This drift appears to be   !
! worse under conditions of high load such as that produced by         !
! multiple concurrent compilations or assemblies.  The purpose of this !
! batch job is to synchronize the clock with known servers on a        !
! periodic basis.  TIMCHK takes a list of servers and protocols to use !
! from a configuration file named TIMCHK.SERVERS in SYSTEM:            !
@Enable
@DayTime
@Original ERun UNS:TIMCHK.EXE
*Y
@DayTime
@Submit PS:<OPERATOR>TIMCHK.CTL.0 /After:+72:00 /Assistance:Yes -
@ /Batch-Log:Append /Connected-Directory:PS:<OPERATOR> -
@ /LogDisposition:Keep /LogName:PS:<OPERATOR>TIMCHK.LOG.0 /Notify:No -
@ /Output:NoLog /Restartable:YES /Unique:No /User:OPERATOR
@Goto END
%ERR::
@Submit PS:<OPERATOR>TIMCHK.CTL.0 /After:+1:00 /Assistance:Yes -
@ /Batch-Log:Append /Connected-Directory:PS:<OPERATOR> -
@ /LogDisposition:Keep /LogName:PS:<OPERATOR>TIMCHK.LOG.0 /Notify:No -
@ /Output:NoLog /Restartable:YES /Unique:No /User:OPERATOR
END::
@Echo That's all folks!

SYSTEM:TIMCHK.SERVERS

TCP time.nist.gov
TCP ns.arc.nasa.gov
TCP tick.usno.navy.mil
UDP TIME.U.WASHINGTON.EDU
EOF


14-Sep-2004 21:37:03-PDT,2298;000000000000
Return-Path: <[email protected]>
Received: from soulshock.mail.pas.earthlink.net ([207.217.120.130]) by Lingling.Panda.COM with TCP/SMTP; Tue, 14 Sep 2004 21:28:44 -0700 (PDT)
Received: from pop-a065c28.pas.sa.earthlink.net (pop11.sprintmail.com [207.217.120.198])
       by soulshock.mail.pas.earthlink.net (8.11.6+Sun/8.11.6) with ESMTP id i8F2eJJ01518
       for <[email protected]>; Tue, 14 Sep 2004 19:40:19 -0700 (PDT)
Received: from cpe-24-221-177-162.ca.sprintbbd.net ([24.221.177.162] helo=reststop.com)
       by pop-a065c28.pas.sa.earthlink.net with esmtp (Exim 3.33 #1)
       id 1C7Pep-0001fx-00
       for [email protected]; Tue, 14 Sep 2004 19:36:34 -0700
Date: Tue, 14 Sep 2004 19:36:29 -0700
Subject: Re: How's your TOD?
Content-Type: text/plain; charset=US-ASCII; format=flowed
Mime-Version: 1.0 (Apple Message framework v553)
From: Carl Baltrunas <[email protected]>
To: Tops-20 Wizards <[email protected]>
Content-Transfer-Encoding: 7bit
In-Reply-To: <[email protected]>
Message-Id: <[email protected]>
X-Mailer: Apple Mail (2.553)

Just of interest is this on real hardware or on the simulator?

On the Foonly F3s we noticed that time was always lost when we
performed tape operations that took longer than a clock tick, since we
disabled interrupts on some tape functions.  But, on real KI, KL, and
KS hardware, the only drift we saw was fairly static and we only reset
it to WWV on any regular basis just to be accurate.  I don't recall
whether we set it by hand (most likely) or from a network time source
(Tymnet) or just at boot time (elsewhere) as time accounting wasn't
that critical for billing customers that a little drift was just
ignored.

-Carl

On Tuesday, September 14, 2004, at 09:08 AM, [email protected] wrote:

> I don't usually check (nor care about) my time of day (TOD) clock.
> However, around late May of this year, I noticed that my TOD clock was
> running a number of minutes slow.  Since I didn't remember the last
> time or if I had ever reset it since boot time, I knocked together a
> short batch job to synch the TOD clock.  It runs every three days
> unless there is a problem, in which case it keeps trying every hour to
> do its thing.

14-Sep-2004 21:55:40-PDT,1321;000000000000
Mail-From: MRC created at 14-Sep-2004 21:48:39
Date: Tue, 14 Sep 2004 21:48:39 -0700 (PDT)
From: Mark Crispin <[email protected]>
Subject: Re: How's your TOD?
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 usually check (nor care about) my time of day (TOD) clock.
>  However, around late May of this year, I noticed that my TOD clock was
>  running a number of minutes slow.

A klh10-based system (such as yours) synchronizes its time with
the host operating system.  If your host system's clock is off,
the klh10's clock will also be off by the same amount.

This is a "hardware time"; it doesn't depend upon TOPS-20 to keep
it accurate.

You can run a synchronize procedure on the TOPS-20 end such as
what you are doing, but all that will do is change the offset
between clock time and hardware time (which comes from the host
system).  If you keep the host system's clock synchronized, then
you don't have to worry about synchronizing at the TOPS-20 end.

Lingling's host system synchronizes its clock with network time
every hour; consequently Lingling's clock is kept accurate.
-------
19-Sep-2004 12:41:49-PDT,2425;000000000000
Return-Path: <[email protected]>
Received: from mta7.srv.hcvlny.cv.net ([167.206.5.74]) by lingling.panda.com with TCP/SMTP; Sun, 19 Sep 2004 12:33:13 -0700 (PDT)
Received: from optonline.net (mstr3.srv.hcvlny.cv.net [167.206.5.14])
by mta7.srv.hcvlny.cv.net
(iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar  3 2004))
with ESMTP id <[email protected]>; Sun,
19 Sep 2004 15:33:13 -0400 (EDT)
Received: from [167.206.5.139] (Forwarded-For: [24.184.174.68])
by mstr3.srv.hcvlny.cv.net (mshttpd); Sun, 19 Sep 2004 15:33:12 -0400
Date: Sun, 19 Sep 2004 15:33:12 -0400
From: [email protected]
Subject: Re: How's your TOD?
To: Mark Crispin <[email protected]>
Cc: [email protected]
Message-id: <[email protected]>
MIME-version: 1.0
X-Mailer: iPlanet Messenger Express 5.2 HotFix 1.25 (built Mar  3 2004)
Content-type: text/plain; charset=us-ascii
Content-language: en
Content-transfer-encoding: 7BIT
Content-disposition: inline
X-Accept-Language: en
Priority: normal

I checked my host clock and it was more than two MINUTES out.
Wouldn't this have resulted in worse times?  After your letter,
I downloaded, installed and am now running ntpd.  After 72 hours,
the TOD was 4948 milliseconds slow--this is typical.  I haven't
checked recently, but loading machine (like with a program that
does JRST .) significantly affects the TOD clock; the drift got
worse.

----- Original Message -----
From: Mark Crispin <[email protected]>
Date: Wednesday, September 15, 2004 0:48 am
Subject: Re: How's your TOD?

> >  I don't usually check (nor care about) my time of day (TOD) clock.
> >  However, around late May of this year, I noticed that my TOD
> >  clock was running a number of minutes slow.
>
> A klh10-based system (such as yours) synchronizes its time with
> the host operating system.  If your host system's clock is off,
> the klh10's clock will also be off by the same amount.
>
> This is a "hardware time"; it doesn't depend upon TOPS-20 to keep
> it accurate.
>
> You can run a synchronize procedure on the TOPS-20 end such as
> what you are doing, but all that will do is change the offset
> between clock time and hardware time (which comes from the host
> system).  If you keep the host system's clock synchronized, then
> you don't have to worry about synchronizing at the TOPS-20 end.


19-Sep-2004 13:55:43-PDT,1383;000000000000
Mail-From: MRC created at 19-Sep-2004 13:48:34
Date: Sun, 19 Sep 2004 13:48:34 -0700 (PDT)
From: Mark Crispin <[email protected]>
Subject: Re: How's your TOD?
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 checked my host clock and it was more than two MINUTES out.
> Wouldn't this have resulted in worse times?  After your letter,
> I downloaded, installed and am now running ntpd.  After 72 hours,
> the TOD was 4948 milliseconds slow--this is typical.  I haven't
> checked recently, but loading machine (like with a program that
> does JRST .) significantly affects the TOD clock; the drift got
> worse.

On my system, Lingling (the TOPS-20 end) keeps accurate time, and
Meimei (the Linux end) resynchronizes its clock via NTP every
hour.  I was unable to get any drift with a "JRST ." loop.

The TOPS-20 GTAD% clock is set by RDTIME (in UPDTCK in
APRSRV.MAC), which in the KLH10 microcode ends up in os_rtmget()
which gets the UNIX clock via gettimeofday().

Consequently, if the UNIX end time is kept accurate, the TOPS-20
end should be accurate too.  If I remember correct, you're using
a Wal-Mart Linux PC; perhaps it doesn't keep accurate time.
-------
20-Sep-2004 12:37:46-PDT,1394;000000000000
Mail-From: MRC created at 20-Sep-2004 12:31:02
Date: Mon, 20 Sep 2004 12:31:02 -0700 (PDT)
From: Mark Crispin <[email protected]>
Subject: bug in CR%MAP option for CFORK%
To: [email protected]
Pithy-Thought: TOPS-20 was a great improvement over its successors
Message-ID: <[email protected]>

This question was discussed a couple of months ago.  I can now confirm that
it is a bug.

In the last Digital-released version of TOPS-20, there is a bug with the
CR%MAP option of CFORK% in that the highest section (37) is not mapped.

The problem is with the MOVEI 4,MXSECN-1 instruction at CFK41-3 in FORK.MAC.
This should be MOVEI 4,MXSECN or MOVEI T4,MXSECN.

On xkleten.paulallen.com (the only XKL processor I have access to), it looks
like CKF41-3 is MOVEI 4,MXSECN but MXSECN is improperly set to 777 instead of
7777.  As a result, only sections 1-777 are mapped.  I also noticed that DDT
was still mapped into section 37, so it's possible that this machine has an
older version of XKL software; I no longer have access to XKL's system so I
don't know if it is fixed there.

Section 0 is treated specially by CR%MAP.  Rather than mapping the section,
the inferior process gets a private section 0 and its pages are mapped to
the superior's page 0 pages.  I decided to leave this alone to maintain
compatibility with the KS.
-------
21-Sep-2004 11:42:26-PDT,8423;000000000000
Return-Path: <[email protected]>
Received: from mta1.srv.hcvlny.cv.net ([167.206.5.67]) by lingling.panda.com with TCP/SMTP; Tue, 21 Sep 2004 11:36:13 -0700 (PDT)
Received: from optonline.net (mstr3.srv.hcvlny.cv.net [167.206.5.14])
by mta1.srv.hcvlny.cv.net
(iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar  3 2004))
with ESMTP id <[email protected]>; Tue,
21 Sep 2004 14:34:28 -0400 (EDT)
Received: from [167.206.5.45] (Forwarded-For: [66.114.69.214])
by mstr3.srv.hcvlny.cv.net (mshttpd); Tue, 21 Sep 2004 14:34:28 -0400
Date: Tue, 21 Sep 2004 14:34:28 -0400
From: [email protected]
Subject: Re: bug in CR%MAP option for CFORK%
To: Mark Crispin <[email protected]>
Cc: [email protected]
Message-id: <[email protected]>
MIME-version: 1.0
X-Mailer: iPlanet Messenger Express 5.2 HotFix 1.25 (built Mar  3 2004)
Content-type: text/plain; charset=us-ascii
Content-language: en
Content-transfer-encoding: 7BIT
Content-disposition: inline
X-Accept-Language: en
Priority: normal

> This question was discussed a couple of months ago.  I can now
> confirm that it is a bug.

MRC,

Based on your previous response to my original email, I did some more
checking into the 'anomaly', a number of months ago.  However, I
eventually decided not to post anything further because I felt that my
investigation was incomplete and I was uncomfortable about
speculating.  Anyway, here is the research that I did do and what I
found out.  In brief:

 1) The suggested code change does work (see below)
 2) Based on the (miniscule) amount of data that I have, I couldn't
    rule out the chance that the change wouldn't break something.  We
    would probably want to do some sort of regression testing before
    committing to it.  There used to be a tool for this.
 3) One might make the case that CR%MAP usage in an extended mode
    program should probably be avoided altogether.
    a) On a KL-10B or a KLH10 processor in model B mode, a great deal
       more CPU time is used in the CFORK% JSYS.
    b) On an XKL processor, the CFORK% JSYS CPU usage is far worse.
 4) Similar arguments MAY apply for system memory usage.  In any
    event, extended mode memory information gathering is complicated
    by CR%MAP usage.
 5) The CFK4 (is it really CKF41 on the XKL?) code could probably be
    rewritten for both processor and memory efficiency.
 6) The whole idea of monitor extended mode run time checking may
    need to be reviewed.

Here are the details:

I went into MDDT and changed CFK4+25 (a.k.a CFK41-3) from MOVEI
4,MXSECN-1 (36) to MOVEI 4,MXSECN (37).  Then I did a CFORK% with
CR%MAP set and verified that the 'correct' behavior happened.  By
this, I mean that my system didn't crash and that section 37 was
mapped.  Both were true (phew!).  Then I changed it back and did some
serious thinking as to what the 'right' thing to do was.  I came up
with fourth major issues.

First, for my own code, I decided that the correct approach would be
to create and manage the sections myself.  This was because doing it
that way resulted in more meaningful typeout and (possibly) less use
of system resources.  When you use CR%MAP on a model B KL or KLH
machine, you get 37 sections mapped and every single page in section 0
mapped, whether you are using anything 'down there' or not.  When you
do this on an XKL, you get lots more sections (more on this, below).

For me, this resulted in output that was difficult to interprete.  I
got a bunch of special mapped sections that I wasn't using and 512
pages mapped from section 0, which I don't use.  That totalled up to
591 pages.  When I did the mapping myself, the total in the inferior
data transfer fork went to 86 pages and was a LOT easier to read.

Second, I didn't know if any code in the system depended on the last
section NOT being mapped.  Instead of being a bug, there was the
distinct possibility that this might have been some sort of an arcane
misfeature that somebody depended on.  I readily concede that it is
hard to see how this could possibly be the case, but without checking,
one mustn't assume.

Third, there was the issue of resource usage.  Although processor
utilization is less of a concern these days, I still try to conserve
cycles, if for nothing else than as a matter of taste.  On a model B
KL or KLH10, you sit in a loop and do some amount of bit banging to
make these sections mapping.  On an XKL processor, you do a LOT more
bit banging: over 2 decimal orders of magnitude.

Then there is the actual system table utilization.  It seemed to me
that having all of these section entries being filled might cause more
real memory to be used.  I'm not up to date on the section
implementation, so this may or may not be true.  In other words, a
page map with entries changed from 0 to indirect pointers may take
exactly the same amount of real storage.  But taste caused me to
reject that possibility.

Fourth, it seemed to me that the code was really doing the wrong
thing.  For section zero, it sets up special mapping for each page.
After doing this, it checks for an extended machine and then sets up
special mappings for every possible section if so.  There is also the
following comment: "SECTION 0 COULD BE HANDLED WITH AN INDIRECT
SECTION POINTER AS WELL MAYBE FUTURE ..."  This suggests saving some
processor cycles by rearranging the code, viz:

       CALL CKXADR             ;EXTENDED ADDRESSING SUPPORTED?
       IFNSK.                  ;No: KS, KL-A, KLH10-KS mode, etc.
         MOVE 1,FORKX
         LOAD T3,FKUP%,(T1)
         HRLZ T1,T3            ;SOURCE IS THIS FORK
         LOAD T3,FKUPT
         HRLZ T2,T3            ;DESTINATION IS NEW FORK
         MOVSI 3,(PTRW)
         MOVEI 4,PGSIZ
         CALL MSETPT           ;DO FOR ALL PAGES
          JRST [ ADJSP P,-3    ;FIX UP STACK POINTER
               JRST CFFAT]     ;HANDLE FATAL ERROR
       ELSE.                   ; Otherwise an extended machine!!!
         MOVE 1,FORKX
         LOAD T1,FKPS%,(T1)    ;GET SPT INDEX FOR PSB OF THIS FORK
         HRLZ T1,T1            ; into left half, source section 0
         LOAD T2,FKPSB         ;GET SPT INDEX FOR PSB OF NEW FORK
         HRLZ T2,T2            ; into left half, destination section 0
         TXO 3,SM%IND          ;MAP VIA INDIRECT POINTERS
         MOVEI 4,MXSECN+1      ;all sections, including section 0
         CALL MSETST           ;MAP SECTIONS ZERO THRU MXSECN
          JFCL                 ;CAN'T HAPPEN
       ENDIF.

Assuming that CKXADR does the right thing, then this code should work
on any machine.  However, since I'm trying to focus on FTPSER, I
haven't been able to test it, so it is speculative.  But this may hide
what may be a deeper issue.  It is instructive to look at the
following comments and implenentation of CKXADR in APRSRV:

; UPD ID= 383, SNARK:<6.MONITOR>APRSRV.MAC.50,   5-Feb-82 13:40:05 by HALL
;TCO 6.1000 - Support the 2080
;       Remove checks on EXADFL from SECALE, XBLTA, BLTMU1, BLTUM1, BLTUU
;       Make CKXADR always return success

       .
       .
       .

CKXADR::RETSKP                  ;YES

It would seem that the monitor now requires extended addressing.  I
don't know how long this has been the case: in the version 4.0 Tops-20
Monitor sources that I have, CKXADR actually does something: it skips
on EXADFL.  So it looks like support for the KS10 and Model A CPUs was
dropped.

I actually remember this being stated at one of the few meetings in
NYC that I went to after the 2080 was cancelled.  I don't remember the
name of the VP from DEC who announced this, but I do vividly recall
that she was really shouted at by a person in the audience that had a
Model A CPU who was pretty ballistic.  Come to think of it, nobody was
happy that day.

Depending on what is being shared and what CAN be shared between the
KS/KL-A monitor sources and version 7, it may be appropriate to revist
the decision to keep such conditional executable code.  I'm not saying
to pitch all of it.  At WPI, AEJ and friends managed to shoe-horn most
of 6.02 Tops-10 into a 5.0 monitor and had the whole thing running on
a KA-10.  What happy hackers ...  Anyway, it's something to consider.


21-Sep-2004 17:40:40-PDT,2166;000000000000
Mail-From: MRC created at 21-Sep-2004 17:34:10
Date: Tue, 21 Sep 2004 17:34:10 -0700 (PDT)
From: Mark Crispin <[email protected]>
Subject: Re: bug in CR%MAP option for CFORK%
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]>

Hi Tom -

I doubt very much that the change will break anything.  This is,
after all, a newly-created fork.  For something to break, it
would have to depend upon section 37 not existing and giving a
page fail trap.

I didn't notice all that much CPU time being used by CR%MAP, even
on an XKL processor which is mapping many more pages and is much
slower than most KLH10 systems.

As for memory, the current crufty way only results in the
creation of one additional page to hold those section 0 page
mappings.  Everything else is indirect pointers in
already-existing section tables.  [Note that the XKL monitor
currently has a bug in that it stops at section 777 rather than
section 7776.]

As you pointed out, on a KL (KL10, SC, KLH10) processor, CR%MAP
can theoretically be done with 31 section indirect pointers.  It
gets better on an XKL processor; just 8 supersection indirect
pointers are needed.

The question is, whether the continued special treatment of
section 0 is justified or not.  I think that the whole reason why
is to avoid the risk of breaking a program which, somehow,
depends upon section 0 pages being individually mapped instead of
the entire section being mapped.

I'm not sure if a user program can somehow tell that a page 0
page is page-mapped as opposed to being section mapped.  You
could try changing it and seeing if anything is broken.  But, I
fear, if something does get broken the breakage will be
non-obvious and obscure.

Of course, a 7 series monitor will only run on an extended
processor.  That isn't the point for leaving the section 0
mapping unchanged; the point is whether or not a user program
from ancient days would notice a difference.

-- Mark --
-------
24-Sep-2004 10:28:46-PDT,6015;000000000000
Return-Path: <[email protected]>
Received: from mta8.srv.hcvlny.cv.net ([167.206.5.75]) by lingling.panda.com with TCP/SMTP; Fri, 24 Sep 2004 10:22:17 -0700 (PDT)
Received: from optonline.net (mstr3.srv.hcvlny.cv.net [167.206.5.14])
by mta8.srv.hcvlny.cv.net
(iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar  3 2004))
with ESMTP id <[email protected]>; Fri,
24 Sep 2004 13:21:41 -0400 (EDT)
Received: from [167.206.5.73] (Forwarded-For: [66.114.69.214])
by mstr3.srv.hcvlny.cv.net (mshttpd); Fri, 24 Sep 2004 13:21:41 -0400
Date: Fri, 24 Sep 2004 13:21:41 -0400
From: [email protected]
Subject: Re: bug in CR%MAP option for CFORK%
To: Mark Crispin <[email protected]>
Cc: [email protected]
Message-id: <[email protected]>
MIME-version: 1.0
X-Mailer: iPlanet Messenger Express 5.2 HotFix 1.25 (built Mar  3 2004)
Content-type: text/plain; charset=us-ascii
Content-language: en
Content-transfer-encoding: 7BIT
Content-disposition: inline
X-Accept-Language: en
Priority: normal

> I doubt very much that the change will break anything.  This is,
> after all, a newly-created fork.  For something to break, it would
> have to depend upon section 37 not existing and giving a page fail
> trap.

As I believe I may have implied, it's hard to see how this particular
change could possibly break anything.  My own problem with making any
predictions is understanding why section 0 always seems to have to
exist, cannot be deleted with SMAP% and what implications this has--if
any--with other sections.  In short, why does section 0 really have to
be there and does this imply anything about the other sections?

> I'm not sure if a user program can somehow tell that a page 0 page
> is page-mapped as opposed to being section mapped.  You could try
> changing it and seeing if anything is broken.  But, I fear, if
> something does get broken the breakage will be non-obvious and
> obscure.

I think that there would be two general cases: user mode and monitor
mode.  As I recall, excluding MONRD% and SNOOP%, a number of JSYi will
give you information about pages.  At least, these would be RPACS%,
XRMAP%, RMAP% and (perhaps) RSMAP%.  To make a moby speculation, I
think that PA%RD, PA%WT, PA%EX, PA%PEX, PA%CPY and PA%PRV are going to
be consistent whether or not you are indirecting through a section or
a page.

Of these, only RPACS% gives information about indirect pointers.  How
are PA%IND, P1%RD, P1%WT, P1%EX, P1%PEX and P1%CPY effected by an
PMAP% being substituted by SMAP%?  I think that the next chapter in
the CR%MAP saga would be to determine this.  Other than for
informational purposes (such as what the EXEC does), what decisions do
programs base indirect pointers on?  Determining if a page is shared
or mapped from a file?

> The question is, whether the continued special treatment of section
> 0 is justified or not.  I think that the whole reason why is to
> avoid the risk of breaking a program which, somehow, depends upon
> section 0 pages being individually mapped instead of the entire
> section being mapped.

If the indirect pointer information that is returned from RPACS% is
consistent between SMAP% and PMAP%, then a user mode program would
have no defined monitor interface to determine the difference.  In
that case, the change could have no effect.

That leaves the monitor.  If the monitor depends on the existance of
section zero in a fork or (possibly funny) mapping of the pages
therein, then lossage would occur.  I know that some parts of the
monitor use (or used to use) pages from a fork whose sole purpose for
existance is to have someplace from which to 'steal' pages.  It
depends on the internal implementation with which I am completely
unfamiliar: my monitor internal documentation is only from the 3A
course.

> I didn't notice all that much CPU time being used by CR%MAP, even on
> an XKL processor which is mapping many more pages and is much slower
> than most KLH10 systems.
>
> [Note that the XKL monitor currently has a bug in that it
>  stops at section 777 rather than section 7776.]

PDP-10 CPU cycles are certainly a lot cheaper than they used to be and
it may not make sense to try to bum the code.  These days, I think in
orders of magnitude.  Changing the code for machines with KL10B (23
bit) address spaces would result in 32 section mapping operations as
opposed to 31 section mapping operations plus 512 page mapping
operations.

Assuming that the magnitude of a single page map change operation is
roughly equivalent to that of a single section map change operation,
this is probably a worthwhile avenue of inquiry to pursue under
certain circumstances (see below).

In the case of a 'fixed' XKL implementation, CR%MAP is two (octal)
orders of magnitude worse.  You may very well have not noticed any
significant delay for the current bug which only roughly doubles the
amount of mappage.  In this case, bumming the 512 page mappings in
section 0 may not be noticeable.  Then again ...

Actually, the situation on the XKL suggests a different approach
altogether.  Perhaps an SSMAP% (super-section MAP) or XBLTing section
maps.  Or section indirect map on reference?  Or something?

So when would we care about this?  We would have cared about it at
Columbia, particularly at the end of the semester when the kiddies
were compiling their hearts out.  Emacs could be continued as could
some of the DEC compilers, but other compilers?  That's a lot of fork
creation for lots of people on largely overloaded timesharing systems
..  :-) That's not the case anymore, but one can hope for the future.

Another case would be for ported Unix code.  I know that the gnu C
compiler (and perhaps other languages) were (are?) being ported to
Tops-20.  Anything that depends on lots of pipage or threads and
hence, cheap fork creation, might not give inspiring performation.


24-Sep-2004 14:00:10-PDT,3903;000000000000
Return-Path: <[email protected]>
Received: from mxout2.cac.washington.edu ([140.142.33.4]) by lingling.panda.com with TCP/SMTP; Fri, 24 Sep 2004 13:54:03 -0700 (PDT)
Received: from smtp.washington.edu (smtp.washington.edu [140.142.33.9])
       by mxout2.cac.washington.edu (8.13.1+UW04.08/8.13.1+UW04.08) with ESMTP id i8OKs2tT008523;
       Fri, 24 Sep 2004 13:54:02 -0700
Received: from Tomobiki-Cho.CAC.Washington.EDU (tomobiki-cho.cac.washington.edu [128.95.135.58])
       (authenticated bits=0)
       by smtp.washington.edu (8.13.1+UW04.08/8.13.1+UW04.08) with ESMTP id i8OKs1k6021608
       (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT);
       Fri, 24 Sep 2004 13:54:02 -0700
Date: Fri, 24 Sep 2004 13:54:03 -0700 (Pacific Daylight Time)
From: Mark Crispin <[email protected]>
To: [email protected]
cc: [email protected]
Subject: Re: bug in CR%MAP option for CFORK%
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

On Fri, 24 Sep 2004 [email protected] wrote:
> My own problem with making any
> predictions is understanding why section 0 always seems to have to
> exist, cannot be deleted with SMAP% and what implications this has--if
> any--with other sections.  In short, why does section 0 really have to
> be there and does this imply anything about the other sections?

If I had to take a wild guess, perhaps something depends upon being able
to access ACs through section 0.

> Other than for
> informational purposes (such as what the EXEC does), what decisions do
> programs base indirect pointers on?  Determining if a page is shared
> or mapped from a file?

Your guess is as good as mine.  Who knows what the various Lisp systems
might do, or perhaps some other program from Tenex days?

These would all be section 0 only programs.

> If the indirect pointer information that is returned from RPACS% is
> consistent between SMAP% and PMAP%, then a user mode program would
> have no defined monitor interface to determine the difference.  In
> that case, the change could have no effect.

Hmm.

Here's something to check.  After doing CR%MAP, suppose the inferior uses
PMAP% to unmap some pages, then touches those pages.

Does the behavior change between a section 0 program and a section 1
program?

In the case of section 0, I would expect that the pages in question get
created as private pages in the inferior.

In the case of section 1, perhaps the PMAP% and subsequent touch would
affect the superior as well, since the section pointer is shared between
the two and the inferior does not have a private section pointer.  Or
maybe doing the PMAP% will give the inferior its own section pointer.

> In the case of a 'fixed' XKL implementation, CR%MAP is two (octal)
> orders of magnitude worse.

I don't think so.  You're apparently thinking that the XKL has to do 512
page maps plus 4094 section maps.  IIRC, an XKL has an eight-entry
supersection table, each entry pointing to a page of section pointers (as
opposed to the 32-entry section table on the KL/KLH10).

So, the XKL should be able to share supersections (visible only to the
pager, not to user code), so it would either be:
       512 page maps
       511 section maps
       7 supersection maps
or (if we're convinced that the page maps aren't needed) just 8
supersection maps.  The XKL monitor on xkleten.paulallen.com just maps up
to section 777 (thus 512 page maps and 511 section maps).

Ralph would be the expert.  There is a question also about section 7777
which must always trap (according to the architecture book).

-- Mark --
20-Dec-2004 08:30:45-PST,440;000000000000
Mail-From: MRC created at 20-Dec-2004 08:21:52
Date: Mon, 20 Dec 2004 08:21:52 -0800 (PST)
From: Mark Crispin <[email protected]>
Subject: Happy DEC-20 Day!
To: [email protected]
Pithy-Thought: TOPS-20 was a great improvement over its successors
Message-ID: <[email protected]>

Be sure to give your DEC-20 a hug and tell it that you still love it, on this
40th year of 36 bit computing!
-------