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 Subject: record TOPS-20 list traffic and 40th anniversary To: TOPS-20@Lingling.Panda.COM Pithy-Thought: TOPS-20 was a great improvement over its successors Message-ID: <13895230038.12.MRC@lingling.panda.com> 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: tops-20@lingling.panda.com 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: 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: In-Reply-To: <13895230038.12.MRC@lingling.panda.com> References: <13895230038.12.MRC@lingling.panda.com> Date: Fri, 2 Jan 2004 13:28:17 -0500 To: Mark Crispin , TOPS-20@lingling.panda.com From: Paul Wexelblat 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: Sender: tops-20-request@Panda.COM Reminder: To post to the list, send mail to tops-20@Panda.COM Reminder: To [un]subscribe, send mail to tops-20-request@Panda.COM Date: Wed, 13 Nov 1996 11:14:15 -0800 From: Rich Alderson Subject: Accounts on toad.xkl.com To: tops-20@Panda.COM 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: > tops-20@lingling.panda.com >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: 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: <615@66-65-143-33.nyc.rr.com ([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 To: TOPS-20@lingling.panda.com Subject: Re: Happy DEC-20 day! Date: Mon, 05 Jan 2004 22:29:27 -0500 Message-ID: <615.23.53.44.05.01.2004@66-65-143-33.nyc.rr.com ([66.65.143.33])> References: <43568.16.45.49.20.12.2003@lingling.panda.com ([206.124.149.115])> In-Reply-To: <43568.16.45.49.20.12.2003@lingling.panda.com ([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: 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 TOPS-20@Lingling.Panda.COM; Mon, 12 Jan 2004 13:23:38 -0800 (PST) Date: Mon, 12 Jan 2004 13:23:38 PST From: Mark Lottor To: TOPS-20@Lingling.Panda.COM Subject: chives/jeeves Message-ID: Hi, if you have this, please contact him. thanks, Mark --------------- Date: Mon, 12 Jan 2004 22:11:33 +0100 (CET) From: Roy Arends To: Mark Lottor 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: 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 ; Mon, 12 Jan 2004 16:48:51 -0500 (EST) Date: Mon, 12 Jan 2004 16:48:51 -0500 From: Rob Austein To: TOPS-20@Lingling.Panda.COM Subject: Re: chives/jeeves In-Reply-To: References: 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: <20040112214851.CA44D18E6@thrintun.hactrn.net> 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 > > 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: 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 ; Mon, 12 Jan 2004 17:04:03 -0500 (EST) Date: Mon, 12 Jan 2004 17:04:03 -0500 From: Rob Austein To: TOPS-20@Lingling.Panda.COM Subject: Re: chives/jeeves In-Reply-To: References: 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: <20040112220403.E187B18E8@thrintun.hactrn.net> 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: 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:smj@ol.freeshell.org [192.94.73.20]) by sdf.lonestar.org (8.12.10/8.12.10) with ESMTP id i0CMGkNw002710 for ; 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 tops-20@lingling.panda.com; Mon, 12 Jan 2004 22:16:46 GMT From: Stephen Jones Message-Id: <200401122216.i0CMGkY0002708@sdf.lonestar.org> Subject: Seattle based get together? In-Reply-To: <20040112214851.CA44D18E6@thrintun.hactrn.net> To: tops-20@lingling.panda.com 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 .. SMJ@TWENEX.ORG 12-Jan-2004 16:12:46-PST,1500;000000000000 Return-Path: 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 Sender: mrc@shiva1.cac.washington.edu To: Stephen Jones cc: tops-20@Lingling.Panda.COM Subject: Re: Seattle based get together? In-Reply-To: <200401122216.i0CMGkY0002708@sdf.lonestar.org> Message-ID: References: <200401122216.i0CMGkY0002708@sdf.lonestar.org> 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: 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 <0HS700848WA8SP@mta3.srv.hcvlny.cv.net> for Tops-20@lingling.panda.com; Wed, 28 Jan 2004 15:44:33 -0500 (EST) Date: Wed, 28 Jan 2004 15:44:25 -0500 From: Thomas DeBellis Subject: SORT To: Tops-20 Wizards Message-id: <40181F29.6DE0C289@optonline.net> MIME-version: 1.0 X-Mailer: Mozilla 4.5 [en]C-CCK-MCD BA45DSL (WinNT; U) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-Accept-Language: en 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: 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:LtmzI+k5g9nRmolePVtid9BCo8NGejsU@psi.math.utah.edu [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" To: Tops-20 Wizards Cc: beebe@math.utah.edu, Thomas DeBellis 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: Thomas DeBellis 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: beebe@math.utah.edu - - 155 S 1400 E RM 233 beebe@acm.org beebe@computer.org - - 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: 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 <0HT100EGO931RS@mta7.srv.hcvlny.cv.net> for Tops-20@lingling.panda.com; Fri, 13 Feb 2004 12:11:26 -0500 (EST) Date: Fri, 13 Feb 2004 12:11:16 -0500 From: Thomas DeBellis Subject: 9 track and DECtape data recovery To: Tops-20 Wizards Message-id: <402D0533.851D2407@optonline.net> MIME-version: 1.0 X-Mailer: Mozilla 4.5 [en]C-CCK-MCD BA45DSL (WinNT; U) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-Accept-Language: en 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: 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 <0HT100L4W9S3SZ@mta6.srv.hcvlny.cv.net> for Tops-20@lingling.panda.com; Fri, 13 Feb 2004 12:26:28 -0500 (EST) Date: Fri, 13 Feb 2004 12:26:17 -0500 From: Thomas DeBellis Subject: Multi-homed systems To: Tops-20 Wizards Message-id: <402D08B9.4BC4CA04@optonline.net> MIME-version: 1.0 X-Mailer: Mozilla 4.5 [en]C-CCK-MCD BA45DSL (WinNT; U) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-Accept-Language: en I 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: 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 Sender: Mark Crispin Subject: re: Multi-homed systems To: Thomas DeBellis cc: Tops-20 Wizards In-Reply-To: <402D08B9.4BC4CA04@optonline.net> Message-ID: 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: 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 <0HT100G7RC18HJ@mta1.srv.hcvlny.cv.net> for Tops-20@lingling.panda.com; Fri, 13 Feb 2004 13:15:10 -0500 (EST) Date: Fri, 13 Feb 2004 13:14:59 -0500 From: Thomas DeBellis Subject: SC%MNT Shutdown To: Tops-20 Wizards Message-id: <402D1423.4F2B4F29@optonline.net> MIME-version: 1.0 X-Mailer: Mozilla 4.5 [en]C-CCK-MCD BA45DSL (WinNT; U) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-Accept-Language: en 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: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: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: 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 ; Fri, 13 Feb 2004 13:17:56 -0500 (EST) Date: Fri, 13 Feb 2004 13:17:56 -0500 From: Rob Austein To: Tops-20 Wizards Subject: Re: Multi-homed systems In-Reply-To: <402D08B9.4BC4CA04@optonline.net> References: <402D08B9.4BC4CA04@optonline.net> 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: <20040213181756.BB7E218E3@thrintun.hactrn.net> 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: 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 Tops-20@lingling.panda.com; Fri, 13 Feb 2004 14:16:02 -0500 (EST) Date: Fri, 13 Feb 2004 14:16:02 -0500 (EST) From: Phil Budne Message-Id: <200402131916.i1DJG25N022576@ultimate.com> To: Tops-20@lingling.panda.com 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: 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: jtw@mercury.lcs.mit.edu Message-Id: In-Reply-To: <20040213181756.BB7E218E3@thrintun.hactrn.net> References: <402D08B9.4BC4CA04@optonline.net> <20040213181756.BB7E218E3@thrintun.hactrn.net> Date: Fri, 13 Feb 2004 13:34:18 -0600 To: Rob Austein , Tops-20 Wizards From: John Wroclawski 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: 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 ; Fri, 13 Feb 2004 14:48:38 -0500 (EST) Date: Fri, 13 Feb 2004 14:48:38 -0500 From: Rob Austein To: Tops-20@lingling.panda.com Subject: Re: Multi-homed systems In-Reply-To: <200402131916.i1DJG25N022576@ultimate.com> References: <200402131916.i1DJG25N022576@ultimate.com> 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: <20040213194838.97B1418E6@thrintun.hactrn.net> 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: 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 <0HT100CEOGL6R4@mta10.srv.hcvlny.cv.net> for Tops-20@lingling.panda.com; Fri, 13 Feb 2004 14:53:32 -0500 (EST) Date: Fri, 13 Feb 2004 14:53:26 -0500 From: Thomas DeBellis Subject: Re: SC%MNT Shutdown To: "Alan H. Martin" Cc: Tops-20 Wizards Message-id: <402D2B36.5EF013AA@optonline.net> MIME-version: 1.0 X-Mailer: Mozilla 4.5 [en]C-CCK-MCD BA45DSL (WinNT; U) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-Accept-Language: en References: <402D1423.4F2B4F29@optonline.net> <402D28C7.176CAC@RCN.Com> 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 AMartin.MA.UltraNet@RCN.Com 13-Feb-2004 13:18:31-PST,1299;000000000000 Return-Path: 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 Tops-20@lingling.panda.com; Fri, 13 Feb 2004 16:11:41 -0500 Date: Fri, 13 Feb 2004 16:11:41 -0500 From: John Wilson Message-Id: <200402132111.i1DLBfp11650@dbit.com> To: Tops-20@lingling.panda.com Subject: Re: Multi-homed systems From: John Wroclawski >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: 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 Date: Fri, 13 Feb 2004 14:51:29 PST From: William "Chops" Westfield To: Thomas DeBellis Cc: Tops-20 Wizards Subject: Re: Multi-homed systems In-Reply-To: Your message of Fri, 13 Feb 2004 12:26:17 -0500 Message-ID: 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: 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 <20040213225415.THCG8426.out003.verizon.net@bellatlantic.net>; Fri, 13 Feb 2004 16:54:15 -0600 Message-ID: <402D5596.2030409@bellatlantic.net> Date: Fri, 13 Feb 2004 17:54:14 -0500 From: bob Reply-To: sfmc68@verizon.net 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 CC: Tops-20 Wizards Subject: Re: Multi-homed systems References: <402D08B9.4BC4CA04@optonline.net> In-Reply-To: <402D08B9.4BC4CA04@optonline.net> 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 Subject: Re: Multi-homed systems To: TOPS-20@Lingling.Panda.COM In-Reply-To: Pithy-Thought: TOPS-20 was a great improvement over its successors Message-ID: <13906470256.10.MRC@lingling.panda.com> > From: William "Chops" Westfield > > 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: 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 Date: Fri, 13 Feb 2004 15:24:44 PST From: William "Chops" Westfield To: John Wroclawski Cc: Rob Austein , Tops-20 Wizards Subject: Re: Multi-homed systems In-Reply-To: Your message of Fri, 13 Feb 2004 13:34:18 -0600 Message-ID: > 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: 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 <0HT500LL479QO8@mta2.srv.hcvlny.cv.net>; Sun, 15 Feb 2004 15:22:40 -0500 (EST) Date: Sun, 15 Feb 2004 15:22:37 -0500 From: Thomas DeBellis Subject: Re: Multi-homed systems To: Mark Crispin Cc: TOPS-20@lingling.panda.com Message-id: <402FD50D.6D7B67B0@optonline.net> MIME-version: 1.0 X-Mailer: Mozilla 4.5 [en]C-CCK-MCD BA45DSL (WinNT; U) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-Accept-Language: en References: <13906470256.10.MRC@lingling.panda.com> 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: 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 To: TOPS-20@lingling.panda.com From: Ken Rossman In-Reply-To: <402FD50D.6D7B67B0@optonline.net> Message-Id: <0981D73A-5FF9-11D8-BC3D-000393A3AAF8@columbia.edu> 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: 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 Date: Sun, 15 Feb 2004 14:37:02 PST From: William "Chops" Westfield To: Thomas DeBellis Cc: Mark Crispin , TOPS-20@lingling.panda.com Subject: Re: Multi-homed systems In-Reply-To: Your message of Sun, 15 Feb 2004 15:22:37 -0500 Message-ID: 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: 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 Date: Sun, 15 Feb 2004 14:52:23 PST From: William "Chops" Westfield To: Ken Rossman Cc: TOPS-20@lingling.panda.com, Ken Rossman Subject: Re: Multi-homed systems In-Reply-To: Your message of Sun, 15 Feb 2004 15:53:41 -0500 -0500 Message-ID: >> 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: 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 <0HU600GH75LDDT@mta10.srv.hcvlny.cv.net> for Tops-20@lingling.panda.com; Sat, 06 Mar 2004 14:17:39 -0500 (EST) Date: Sat, 06 Mar 2004 14:17:35 -0500 From: Thomas DeBellis Subject: FR.NOS or Your system clock really isn't slowing down, is it? To: Tops-20 Wizards Message-id: <404A23CF.2FC32DF5@optonline.net> MIME-version: 1.0 X-Mailer: Mozilla 4.5 [en]C-CCK-MCD BA45DSL (WinNT; U) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-Accept-Language: en 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: 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 Sender: Mark Crispin Subject: re: FR.NOS or Your system clock really isn't slowing down, is it? To: Thomas DeBellis cc: Tops-20 Wizards In-Reply-To: <404A23CF.2FC32DF5@optonline.net> Message-ID: 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: 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 <20040316151729.QIXH18295.out012.verizon.net@bellatlantic.net> for ; Tue, 16 Mar 2004 09:17:29 -0600 Message-ID: <40571A88.3040908@bellatlantic.net> Date: Tue, 16 Mar 2004 10:17:28 -0500 From: bob Reply-To: sfmc68@verizon.net 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 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: 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 Sender: Mark Crispin Subject: re: really dumb question To: sfmc68@verizon.net cc: Tops-20 Wizards In-Reply-To: <40571A88.3040908@bellatlantic.net> Message-ID: 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 Subject: another TOPS-20 system heading for an UP2LNG... To: TOPS-20@Lingling.Panda.COM Pithy-Thought: TOPS-20 was a great improvement over its successors Message-ID: <13914846902.10.MRC@lingling.panda.com> 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: 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 <0HUU00K9TWBFDH@mta10.srv.hcvlny.cv.net> for Tops-20@lingling.panda.com; Fri, 19 Mar 2004 22:57:15 -0500 (EST) Date: Fri, 19 Mar 2004 22:57:10 -0500 From: Thomas DeBellis Subject: TECO, Symbols and TEXTI% To: Tops-20 Wizards Message-id: <405BC116.589173A4@optonline.net> MIME-version: 1.0 X-Mailer: Mozilla 4.5 [en]C-CCK-MCD BA45DSL (WinNT; U) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-Accept-Language: en 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: 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 Sender: Mark Crispin Subject: re: TECO, Symbols and TEXTI% To: Thomas DeBellis cc: Tops-20 Wizards In-Reply-To: <405BC116.589173A4@optonline.net> Message-ID: 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 directory which shows how the build is done. 20-Mar-2004 12:56:44-PST,2954;000000000000 Return-Path: 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 <0HUW00AWW75SZ4@mta2.srv.hcvlny.cv.net>; 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: slogin@optonline.net Subject: Re: re: TECO, Symbols and TEXTI% To: Mark Crispin Cc: Tops-20 Wizards Message-id: <971c5b973b70.973b70971c5b@optonline.net> 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: 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: 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 Sender: Mark Crispin Subject: Re: re: TECO, Symbols and TEXTI% To: TOPS-20 Hackers and Yackers In-Reply-To: <971c5b973b70.973b70971c5b@optonline.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII On Sat, 20 Mar 2004 15:48:39 -0500, slogin@optonline.net wrote: > I looked around at every DDT in PS: and none of them handle > ;y. It's IDDT, right? IDDT is in PS:, which is part of SYS: 27-Mar-2004 17:25:16-PST,1576;000000000000 Return-Path: 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 <20040328011657.YNAA5247.out014.verizon.net@bellatlantic.net> for ; Sat, 27 Mar 2004 19:16:57 -0600 Message-ID: <40662789.9080106@bellatlantic.net> Date: Sat, 27 Mar 2004 20:16:57 -0500 From: bob Reply-To: sfmc68@verizon.net 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 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 Subject: what happens when TOPS-20 on a KLH-10 system hits UP2LNG To: TOPS-20@Lingling.Panda.COM Pithy-Thought: TOPS-20 was a great improvement over its successors Message-ID: <13920347599.10.MRC@Lingling.Panda.COM> 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 Subject: more on failed UP2LNG To: TOPS-20@Lingling.Panda.COM Pithy-Thought: TOPS-20 was a great improvement over its successors Message-ID: <13920353619.10.MRC@Lingling.Panda.COM> 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: 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: amartin@etnus.com Message-ID: <407330EB.BFFC7C4B@RCN.Com> Date: Tue, 06 Apr 2004 18:36:27 -0400 From: "Alan H. Martin" 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 Cc: TOPS-20@Lingling.Panda.COM Subject: Re: what happens when TOPS-20 on a KLH-10 system hits UP2LNG References: <13920347599.10.MRC@Lingling.Panda.COM> 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 AMartin.MA.UltraNet@RCN.Com 6-Apr-2004 15:52:28-PDT,1953;000000000000 Return-Path: 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 <20040406223840.WKCD11989.out004.verizon.net@bellatlantic.net> for ; Tue, 6 Apr 2004 17:38:40 -0500 Message-ID: <4073316F.1060902@bellatlantic.net> Date: Tue, 06 Apr 2004 18:38:39 -0400 From: bob Reply-To: sfmc68@verizon.net 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@Lingling.Panda.COM Subject: Re: what happens when TOPS-20 on a KLH-10 system hits UP2LNG References: <13920347599.10.MRC@Lingling.Panda.COM> In-Reply-To: <13920347599.10.MRC@Lingling.Panda.COM> 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: 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 ; 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 To: TOPS-20@Lingling.Panda.COM Content-Transfer-Encoding: 7bit In-Reply-To: Message-Id: 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: 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: TOPS-20@Lingling.Panda.COM (Tops-20 Wizards) To: Ken Rossman From: Carl Baltrunas In-Reply-To: Message-Id: <3729A582-8C2E-11D8-92CA-000A959E889E@reststop.com> 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: 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: <849@ool-44c61990.dyn.optonline.net ([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 To: Carl Baltrunas Cc: Ken Rossman , TOPS-20@Lingling.Panda.COM (Tops-20 Wizards) Subject: Re: RSX20F Date: Mon, 12 Apr 2004 00:11:02 -0400 Message-ID: <849.00.43.40.12.04.2004@ool-44c61990.dyn.optonline.net ([68.198.25.144])> References: <66009.23.53.13.11.04.2004@lingling.panda.com ([206.124.149.115])> In-Reply-To: <66009.23.53.13.11.04.2004@lingling.panda.com ([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. 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: 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 Sender: Mark Crispin Subject: Re: RSX20F To: Tops-20 Wizards In-Reply-To: <3729A582-8C2E-11D8-92CA-000A959E889E@reststop.com> Message-ID: 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: 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 ; 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 To: Tops-20 Wizards Content-Transfer-Encoding: 7bit In-Reply-To: Message-Id: 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: 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 <0HWT000Q924UDH@mta9.srv.hcvlny.cv.net>; Mon, 26 Apr 2004 21:14:54 -0400 (EDT) Date: Mon, 26 Apr 2004 21:09:27 -0400 From: Thomas DeBellis Subject: Re: Multi-homed systems To: Mark Crispin Cc: TOPS-20@lingling.panda.com Message-id: <408DB2C7.F740C1D4@optonline.net> MIME-version: 1.0 X-Mailer: Mozilla 4.5 [en]C-CCK-MCD BA45DSL (WinNT; U) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-Accept-Language: en References: <13906470256.10.MRC@lingling.panda.com> 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 > > > > 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: 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 <0HX500A2UETF2E@mta7.srv.hcvlny.cv.net> for Tops-20@lingling.panda.com; Mon, 03 May 2004 13:20:04 -0400 (EDT) Date: Mon, 03 May 2004 13:19:24 -0400 From: Thomas DeBellis Subject: Fun with the mail system AFTER feature To: Tops-20 Wizards Message-id: <40967F1C.B5D6AC58@optonline.net> MIME-version: 1.0 X-Mailer: Mozilla 4.5 [en]C-CCK-MCD BA45DSL (WinNT; U) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-Accept-Language: en 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., 1234567890@vtext.com). 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 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 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.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: 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 Sender: Mark Crispin Subject: re: Fun with the mail system AFTER feature To: Thomas DeBellis cc: Tops-20 Wizards In-Reply-To: <40967F1C.B5D6AC58@optonline.net> Message-ID: 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 bug-mm@simtel20.arpa). 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: 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 <0HX60007CZP00H@mta9.srv.hcvlny.cv.net> for Tops-20@lingling.panda.com; Tue, 04 May 2004 09:48:38 -0400 (EDT) Date: Tue, 04 May 2004 09:48:44 -0400 From: Thomas DeBellis Subject: SOML, SAML and friends To: Tops-20 Wizards Message-id: <40979F3C.5873A425@optonline.net> MIME-version: 1.0 X-Mailer: Mozilla 4.5 [en]C-CCK-MCD BA45DSL (WinNT; U) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-Accept-Language: en I 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: 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 ; 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 Tops-20@lingling.panda.com; Tue, 4 May 2004 10:23:29 -0400 (EDT) Received: from 198.4.159.5 ( [198.4.159.5]) as user rossman@avocado.cc.columbia.edu by cubmail.cc.columbia.edu with HTTP; Tue, 4 May 2004 10:23:29 -0400 Message-ID: <1083680609.4097a76180f09@cubmail.cc.columbia.edu> Date: Tue, 4 May 2004 10:23:29 -0400 From: rossman@columbia.edu To: Tops-20 Wizards Subject: Re: SOML, SAML and friends References: <40979F3C.5873A425@optonline.net> In-Reply-To: <40979F3C.5873A425@optonline.net> 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 : > 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: 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 Message-Id: <200405041629.i44GTjxX019337@ultimate.com> To: Tops-20@lingling.panda.com, rossman@columbia.edu 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: jpn@panda.UUCP Mod.sources: Volume 5, Issue 13 Submitted by: Greg 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 satz@mojave.stanford.edu Shasta!satz 4-May-2004 10:55:59-PDT,1531;000000000000 Return-Path: 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 ; Tue, 4 May 2004 13:47:58 -0400 (EDT) Date: Tue, 04 May 2004 13:47:58 -0400 From: Rob Austein To: Tops-20@lingling.panda.com Subject: Re: SOML, SAML and friends In-Reply-To: <200405041629.i44GTjxX019337@ultimate.com> References: <200405041629.i44GTjxX019337@ultimate.com> 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: <20040504174758.9028842B2@thrintun.hactrn.net> 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 Subject: lights and switches To: TOPS-20@Lingling.Panda.COM Pithy-Thought: TOPS-20 was a great improvement over its successors Message-ID: <13928058051.9.MRC@Lingling.Panda.COM> 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, 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, 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 Subject: bug in PA1050 handling of LIGHTS and SWITCH UUOs To: TOPS-20@Lingling.Panda.COM Pithy-Thought: TOPS-20 was a great improvement over its successors Message-ID: <13928246289.13.MRC@Lingling.Panda.COM> 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 Subject: more on SWITCH UUO in PA1050 To: TOPS-20@Lingling.Panda.COM Pithy-Thought: TOPS-20 was a great improvement over its successors Message-ID: <13928249496.10.MRC@Lingling.Panda.COM> 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: 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 <0HXC00CATSR64P@mta2.srv.hcvlny.cv.net>; 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: slogin@optonline.net Subject: Re: lights and switches To: Mark Crispin Cc: TOPS-20@Lingling.Panda.COM Message-id: <9c42ad9c48c4.9c48c49c42ad@optonline.net> 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 Subject: Re: lights and switches To: slogin@optonline.net cc: TOPS-20@Lingling.Panda.COM In-Reply-To: <9c42ad9c48c4.9c48c49c42ad@optonline.net> Pithy-Thought: TOPS-20 was a great improvement over its successors Message-ID: <13928438382.9.MRC@lingling.panda.com> 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: 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: amartin@etnus.com Message-ID: <409BD946.886D7A3F@RCN.Com> Date: Fri, 07 May 2004 14:45:26 -0400 From: "Alan H. Martin" 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: TOPS-20@Lingling.Panda.COM Subject: Re: lights and switches References: <9c42ad9c48c4.9c48c49c42ad@optonline.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Mark Crispin wrote: > > slogin@optonline.net 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 AMartin.MA.UltraNet@RCN.Com 7-May-2004 12:35:46-PDT,1320;000000000000 Return-Path: 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: amartin@etnus.com Message-ID: <409BE33C.660AF1B1@RCN.Com> Date: Fri, 07 May 2004 15:27:56 -0400 From: "Alan H. Martin" 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: TOPS-20@lingling.panda.com Subject: Re: lights and switches References: <13928438382.9.MRC@lingling.panda.com> 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 AMartin.MA.UltraNet@RCN.Com 7-May-2004 12:59:59-PDT,1804;000000000000 Return-Path: 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 Sender: Mark Crispin Subject: Re: lights and switches To: "Alan H. Martin" cc: TOPS-20@Lingling.Panda.COM In-Reply-To: <409BD946.886D7A3F@RCN.Com> Message-ID: 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: 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: amartin@etnus.com Message-ID: <409BF46C.DA316536@RCN.Com> Date: Fri, 07 May 2004 16:41:16 -0400 From: "Alan H. Martin" 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: TOPS-20@Lingling.Panda.COM Subject: Re: lights and switches References: 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 AMartin.MA.UltraNet@RCN.Com 7-May-2004 16:21:49-PDT,5817;000000000000 Return-Path: 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 <0HXD006PJ9W7WK@mta5.srv.hcvlny.cv.net> for TOPS-20@Lingling.Panda.COM; 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: slogin@optonline.net Subject: Re: lights and switches To: "Alan H. Martin" Cc: TOPS-20@Lingling.Panda.COM Message-id: <83278982d3dd.82d3dd832789@optonline.net> 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 Subject: 21 years ago today... To: TOPS-20@Lingling.Panda.COM Pithy-Thought: TOPS-20 was a great improvement over its successors Message-ID: <13931028816.9.MRC@lingling.panda.com> 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: 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: In-Reply-To: <13931028816.9.MRC@lingling.panda.com> References: <13931028816.9.MRC@lingling.panda.com> Date: Mon, 17 May 2004 13:28:06 -0400 To: Mark Crispin , TOPS-20@lingling.panda.com From: Paul Wexelblat 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: 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 To: Paul Wexelblat Cc: Mark Crispin , TOPS-20@lingling.panda.com Subject: Re: Just Suppose... RE: 21 years ago... In-Reply-To: Message-ID: > 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: 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 Date: Mon, 17 May 2004 14:20:40 PDT From: William "Chops" Westfield To: Paul Wexelblat Cc: Mark Crispin , TOPS-20@lingling.panda.com Subject: Re: Just Suppose... RE: 21 years ago... In-Reply-To: Your message of Mon, 17 May 2004 13:28:06 -0400 Message-ID: > 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 Subject: Re: Just Suppose... RE: 21 years ago... To: TOPS-20@Lingling.Panda.COM In-Reply-To: Pithy-Thought: TOPS-20 was a great improvement over its successors Message-ID: <13931092501.10.MRC@lingling.panda.com> > 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: 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 , Mark Crispin , TOPS-20@lingling.panda.com To: Frank da Cruz From: Carl Baltrunas In-Reply-To: Message-Id: 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: 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 Date: Mon, 17 May 2004 15:10:49 PDT From: William "Chops" Westfield To: Mark Crispin Cc: TOPS-20@lingling.panda.com 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: > 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: 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 ; 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 ; 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 TOPS-20@lingling.panda.com; Mon, 17 May 2004 18:14:32 -0400 Date: Mon, 17 May 2004 18:14:32 -0400 Message-Id: <200405172214.i4HMEW6x002173@road.fpl> From: Dan Murphy To: TOPS-20@lingling.panda.com Subject: Re: Just Suppose... RE: 21 years ago... Reply-To: Dan Murphy 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 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: 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 Date: Mon, 17 May 2004 15:29:07 PDT From: William "Chops" Westfield To: Carl Baltrunas 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: TOPS-20@lingling.panda.com Message-ID: > 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 Subject: Re: Just Suppose... RE: 21 years ago... To: billw@cisco.com cc: TOPS-20@Lingling.Panda.COM In-Reply-To: Pithy-Thought: TOPS-20 was a great improvement over its successors Message-ID: <13931102217.10.MRC@lingling.panda.com> > 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: 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: <919@ool-44c61990.dyn.optonline.net ([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 To: TOPS-20@lingling.panda.com Subject: Re: Just Suppose... RE: 21 years ago... Date: Mon, 17 May 2004 18:31:24 -0400 Message-ID: <919.19.05.48.17.05.2004@ool-44c61990.dyn.optonline.net ([68.198.25.144])> References: <76099.18.25.05.17.05.2004@lingling.panda.com ([206.124.149.115])> In-Reply-To: <76099.18.25.05.17.05.2004@lingling.panda.com ([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: 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 Date: Mon, 17 May 2004 16:49:59 PDT From: William "Chops" Westfield To: Mark Crispin Cc: TOPS-20@lingling.panda.com 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: > 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: 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 <0HY400893YIU4D@mta8.srv.hcvlny.cv.net> for Tops-20@lingling.panda.com; Sat, 22 May 2004 18:01:43 -0400 (EDT) Date: Sat, 22 May 2004 18:01:03 -0400 From: Thomas DeBellis Subject: Fun with FTP To: Tops-20 Wizards Message-id: <40AFCD9F.E17C9021@optonline.net> MIME-version: 1.0 X-Mailer: Mozilla 4.5 [en]C-CCK-MCD BA45DSL (WinNT; U) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-Accept-Language: en I 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.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.MAC.296, 20-Jul-86 02:19:06, Edit by WHP4 **** 2)1 ;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 ;;[T16] 1) ENDIF. **** 2)9 TYPE 2) ENDIF. ************** 1)9 MOVEI B,[FLDDB. .CMKEY,,CMDDSP,,,[ ;;[T16] 1) FLDDB. .CMKEY,,SETDSP,,,,]] ;;[T16] 1) TXNN F,F%COPN ;[T16] Is there a connection open? 1) MOVEI B,[FLDDB. .CMKEY,,CMDDSP,,,[ ;;[T16] 1) FLDDB. .CMKEY,,SETDSP,,,[ ;;[T16] 1) FLDBK. .CMFLD,CM%SDH,,,,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 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,,,,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 1) CALL CONFRM ;[T16] Tie off the line 1) IFXE. F,F%COPN ;[T16] Is there any point to this? 1) TYPE 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,,,,,[ ;;[T16] 1) FLDDB. .CMQST,,,,,[ ;;[T16] 1) FLDBK. .CMFLD,,,^_ 1) ,,REMBRK]]] 1) CALL .COMND **** 2)54 MOVEI B,[FLDDB. .CMCFM,CM%SDH,,,,[ 2) FLDBK. .CMFLD,CM%SDH,,,,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:FTPDEF.MAC.114, 21-May-2004 04:10:40, Edit by SLOGIN 1) ;[T16] Add PWD 1) ;FTPDEF.MAC.113, 15-Sep-88 00:29:56, Edit by MRC **** 2)1 ;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: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:TCPFTP.MAC.317, 21-May-2004 04:05:59, Edit by SLOGIN 1) ;[T16] Offsets for the PWD command 1) ;TCPFTP.MAC.316, 28-Dec-2001 13:20:37, Edit by MRC **** 2)1 ;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 ;[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 Subject: Re: Fun with FTP To: slogin@optonline.net cc: Tops-20@Lingling.Panda.COM In-Reply-To: <40AFCD9F.E17C9021@optonline.net> Pithy-Thought: TOPS-20 was a great improvement over its successors Message-ID: <13932464990.9.MRC@lingling.panda.com> Thank you Tom for your suggestions. I have adopted all of them, although I made a few changes. Available via ANONYMOUS FTP from PS: at lingling.panda.com ------- 23-May-2004 14:19:59-PDT,4698;000000000000 Return-Path: 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 <0HY600I4VQW2OG@mta2.srv.hcvlny.cv.net>; Sun, 23 May 2004 17:12:03 -0400 (EDT) Date: Sun, 23 May 2004 17:11:43 -0400 From: Thomas DeBellis Subject: Re: Fun with FTP To: MRC@lingling.panda.com Cc: Tops-20 Wizards Message-id: <40B1138F.B0479DD3@optonline.net> MIME-version: 1.0 X-Mailer: Mozilla 4.5 [en]C-CCK-MCD BA45DSL (WinNT; U) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-Accept-Language: en References: <40AFCD9F.E17C9021@optonline.net> 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 ". The relevant BNF for is the following: ::= ::= | ::= any of the 128 ASCII characters except and 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: 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 <0HY6007U5ZTLI9@mta6.srv.hcvlny.cv.net>; Sun, 23 May 2004 20:24:59 -0400 (EDT) Date: Sun, 23 May 2004 20:24:20 -0400 From: Thomas DeBellis Subject: Re: Fun with FTP To: MRC@lingling.panda.com Cc: Tops-20 Wizards Message-id: <40B140B4.71ED4C18@optonline.net> MIME-version: 1.0 X-Mailer: Mozilla 4.5 [en]C-CCK-MCD BA45DSL (WinNT; U) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-Accept-Language: en References: <40AFCD9F.E17C9021@optonline.net> <40B1138F.B0479DD3@optonline.net> 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: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) ;FTPSRT.MAC.40, 18-Nov-85 03:09:52, Edit by VAF **** 2)1 ;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, ;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, ;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 ,] ;T2 1) MOVX C, ;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 // 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==<<*5>-2> ;T3 Maximum characters minus two NULLs 1) ZSIZE: MOVX A, ;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, ;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, ;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, ;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, ;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, ;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 , 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, 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, 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] 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: 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: MRC@lingling.panda.com, Tops-20 Wizards To: Thomas DeBellis From: Carl Baltrunas In-Reply-To: <40B140B4.71ED4C18@optonline.net> Message-Id: <328E2C35-AD6E-11D8-82D3-000A959E889E@reststop.com> 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: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) ;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 Subject: Re: Fun with FTP To: tops-20@Lingling.Panda.COM In-Reply-To: <328E2C35-AD6E-11D8-82D3-000A959E889E@reststop.com> Pithy-Thought: TOPS-20 was a great improvement over its successors Message-ID: <13932860259.9.MRC@lingling.panda.com> > 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: 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 <0HYC00EU8TJIJD@mta9.srv.hcvlny.cv.net>; 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: slogin@optonline.net Subject: Re: Fun with FTP To: Mark Crispin Cc: tops-20@lingling.panda.com Message-id: <1379c3b137e130.137e1301379c3b@optonline.net> 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: 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 <0HYC00MMUVGH2Z@mta6.srv.hcvlny.cv.net> for tops-20@lingling.panda.com; 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: slogin@optonline.net Subject: Re: Fun with FTP To: tops-20@lingling.panda.com Message-id: <11573de11599c7.11599c711573de@optonline.net> 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 ;[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 ;[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 ; 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 ; 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 Subject: Re: Fun with FTP To: slogin@optonline.net cc: tops-20@Lingling.Panda.COM In-Reply-To: <1379c3b137e130.137e1301379c3b@optonline.net> Pithy-Thought: TOPS-20 was a great improvement over its successors Message-ID: <13933543385.9.MRC@lingling.panda.com> 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: 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 <0HYE008T1IAPDL@mta8.srv.hcvlny.cv.net> for Tops-20@lingling.panda.com; Thu, 27 May 2004 21:47:14 -0400 (EDT) Date: Thu, 27 May 2004 21:46:55 -0400 From: Thomas DeBellis Subject: Re: Fun with FTP To: Phil Budne Cc: Tops-20 Wizards Message-id: <40B69A0F.A4DF47B4@optonline.net> MIME-version: 1.0 X-Mailer: Mozilla 4.5 [en]C-CCK-MCD BA45DSL (WinNT; U) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-Accept-Language: en References: <200405240148.i4O1mR3p009679@ultimate.com> > > 1) HRROI B,[ASCIZ /PS: > 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 for user FOO is always PS: 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: 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 Sender: Mark Crispin Subject: Re: Fun with FTP To: Thomas DeBellis cc: Tops-20 Wizards In-Reply-To: <40B69A0F.A4DF47B4@optonline.net> Message-ID: 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: 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 <0HYH00GGRRURQV@mta10.srv.hcvlny.cv.net>; 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: slogin@optonline.net Subject: Re: Fun with FTP To: Mark Crispin Cc: Tops-20 Wizards Message-id: <124317f1243c58.1243c58124317f@optonline.net> 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: 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 <0HZ8008P4SEFHZ@mta3.srv.hcvlny.cv.net> for Tops-20@lingling.panda.com; Sun, 13 Jun 2004 06:13:31 -0400 (EDT) Date: Sun, 13 Jun 2004 06:13:11 -0400 From: Thomas DeBellis Subject: Whither FTPSER? To: Tops-20 Wizards Cc: Carl Baltrunas Message-id: <40CC28B7.CC94A0B0@optonline.net> MIME-version: 1.0 X-Mailer: Mozilla 4.5 [en]C-CCK-MCD BA45DSL (WinNT; U) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-Accept-Language: en References: <328E2C35-AD6E-11D8-82D3-000A959E889E@reststop.com> > 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 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:/" 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: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: 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 Sender: Mark Crispin Subject: re: Whither FTPSER? To: Thomas DeBellis cc: Tops-20 Wizards , Carl Baltrunas In-Reply-To: <40CC28B7.CC94A0B0@optonline.net> Message-ID: 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: 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 To: Thomas DeBellis Cc: Tops-20 Wizards , Carl Baltrunas Subject: Re: Whither FTPSER? In-Reply-To: <40CC28B7.CC94A0B0@optonline.net> Message-ID: > 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:/" 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: 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 <0HZC009UJY4DVK@mta4.srv.hcvlny.cv.net> for Tops-20@lingling.panda.com; 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: slogin@optonline.net Subject: Re: Whither FTPSER? To: Frank da Cruz Cc: Tops-20 Wizards , Carl Baltrunas Message-id: <6902e626f8.626f86902e@optonline.net> 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 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: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: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: 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 To: slogin@optonline.net Subject: Re: Whither FTPSER? In-Reply-To: <6902e626f8.626f86902e@optonline.net> Cc: Tops-20 Wizards , Carl Baltrunas Message-ID: > 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: 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 To: slogin@optonline.net cc: Tops-20 Wizards Subject: Re: Whither FTPSER? In-Reply-To: <6902e626f8.626f86902e@optonline.net> Message-ID: References: <6902e626f8.626f86902e@optonline.net> Organization: Networks & Distributed Computing Sender: mrc@ndcms.cac.washington.edu MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed On Tue, 15 Jun 2004 slogin@optonline.net 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: 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 <0HZD0024NGN63T@mta10.srv.hcvlny.cv.net> for Tops-20@lingling.panda.com; 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: slogin@optonline.net Subject: Re: Whither FTPSER? To: Frank da Cruz Cc: Tops-20 Wizards 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:" 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: 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 <0HZD003NPHLQIP@mta7.srv.hcvlny.cv.net>; 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: slogin@optonline.net Subject: Re: Whither FTPSER? To: Mark Crispin Cc: Tops-20 Wizards Message-id: <195ba319b165.19b165195ba3@optonline.net> 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: 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 To: slogin@optonline.net cc: Frank da Cruz , Tops-20 Wizards Subject: Re: Whither FTPSER? In-Reply-To: <19a14319a4de.19a4de19a143@optonline.net> Message-ID: References: <19a14319a4de.19a4de19a143@optonline.net> Organization: Networks & Distributed Computing Sender: mrc@panda.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed On Tue, 15 Jun 2004 slogin@optonline.net 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: 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 To: slogin@optonline.net cc: Tops-20 Wizards Subject: Re: Whither FTPSER? In-Reply-To: <195ba319b165.19b165195ba3@optonline.net> Message-ID: References: <195ba319b165.19b165195ba3@optonline.net> Organization: Networks & Distributed Computing Sender: mrc@panda.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed On Tue, 15 Jun 2004 slogin@optonline.net 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: 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 kz@kz.kz) Message-ID: <40D024F3.7000707@kz.kz> Date: Wed, 16 Jun 2004 12:46:11 +0200 From: Klaus Zeuge 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 CC: slogin@optonline.net, Frank da Cruz , Tops-20 Wizards Subject: Re: Whither FTPSER? References: <19a14319a4de.19a4de19a143@optonline.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: quoted-printable Mark Crispin wrote: > On Tue, 15 Jun 2004 slogin@optonline.net 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: 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 To: Klaus Zeuge Cc: Mark Crispin , slogin@optonline.net, Tops-20 Wizards MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-15; format=flowed Subject: Re: Whither FTPSER? In-Reply-To: <40D024F3.7000707@kz.kz> Message-ID: Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by sesame.cc.columbia.edu id i5GDK9V3026231 Klaus Zeuge 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: 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 Sender: Mark Crispin Subject: Re: Whither FTPSER? To: TOPS-20 Hackers and Yackers In-Reply-To: Message-ID: 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 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: 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 Subject: Re: Whither FTPSER? References: From: Bjorn Victor Date: Wed, 16 Jun 2004 21:04:27 +0200 In-Reply-To: (Mark Crispin's message of "Wed, 16 Jun 2004 09:00:48 -0700 (PDT)") Message-ID: <7nfz8v9ves.fsf@Nomen.it.uu.se> 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 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: 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 Sender: Mark Crispin Subject: Re: Whither FTPSER? To: Bjorn Victor cc: TOPS-20 Hackers and Yackers In-Reply-To: <7nfz8v9ves.fsf@Nomen.it.uu.se> Message-ID: 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: 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 Cc: Bjorn Victor , TOPS-20 Hackers and Yackers Subject: Re: Whither FTPSER? References: From: Bjorn Victor Date: Thu, 17 Jun 2004 01:17:10 +0200 In-Reply-To: (Mark Crispin's message of "Wed, 16 Jun 2004 12:48:26 -0700 (PDT)") Message-ID: <7nacz3ks95.fsf@Nomen.it.uu.se> 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 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: 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:+6fzEOyMUtWNaJtKKOatMufkd9Wdhrv3@psi.math.utah.edu [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" To: Tops-20 Wizards Cc: beebe@math.utah.edu 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: 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: beebe@math.utah.edu - - 155 S 1400 E RM 233 beebe@acm.org beebe@computer.org - - 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: 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 <0HZI00MY8RI3HV@mta2.srv.hcvlny.cv.net> for TOPS-20@Lingling.Panda.COM; 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: slogin@optonline.net Subject: FTPSER To: TOPS-20@Lingling.Panda.COM Message-id: <2f3f162f349f.2f349f2f3f16@optonline.net> 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: 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 Sender: mrc@Ikkoku-Kan.Panda.COM To: slogin@optonline.net cc: TOPS-20@Lingling.Panda.COM Subject: Re: FTPSER In-Reply-To: <2f3f162f349f.2f349f2f3f16@optonline.net> Message-ID: References: <2f3f162f349f.2f349f2f3f16@optonline.net> Organization: Pandamonium Reigns MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed On Fri, 18 Jun 2004 slogin@optonline.net 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: 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 ; Sat, 19 Jun 2004 01:34:41 +0200 (CEST) (envelope-from kz@kz.kz) Message-ID: <40D37EA0.3010306@kz.kz> Date: Sat, 19 Jun 2004 01:45:36 +0200 From: Klaus Zeuge Reply-To: TOPS-20 Hackers and Yackers 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 Subject: Re: Whither FTPSER? References: <7nfz8v9ves.fsf@Nomen.it.uu.se> In-Reply-To: <7nfz8v9ves.fsf@Nomen.it.uu.se> 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: 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 <0HZJ001T6CGWTB@mta1.srv.hcvlny.cv.net>; 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: slogin@optonline.net Subject: Re: FTPSER To: Mark Crispin Cc: TOPS-20@Lingling.Panda.COM Message-id: <2e304f2dd2ca.2dd2ca2e304f@optonline.net> 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: 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:oJpbf17iE0q9V3NQd13X0xoke+iKZ2mF@psi.math.utah.edu [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" To: Tops-20 Wizards Cc: beebe@math.utah.edu 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: 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" To: emacs-pretesters@gnu.org Cc: beebe@math.utah.edu 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 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: ;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: beebe@math.utah.edu - - 155 S 1400 E RM 233 beebe@acm.org beebe@computer.org - - 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: 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 Sender: mrc@Ikkoku-Kan.Panda.COM To: "Nelson H. F. Beebe" cc: Tops-20 Wizards Subject: Re: [TOPS-20] Emacs' birthday: seeking some history In-Reply-To: Message-ID: References: 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: 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 ; 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 ; 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 Tops-20@Lingling.Panda.COM; Tue, 29 Jun 2004 19:17:22 -0400 Date: Tue, 29 Jun 2004 19:17:22 -0400 Message-Id: <200406292317.i5TNHMke005142@road.fpl> From: Dan Murphy To: Tops-20@Lingling.Panda.COM Subject: Birthdays [was: Emacs' birthday] Reply-To: Dan Murphy 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 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: 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 <0I07006T0LBGCM@mta10.srv.hcvlny.cv.net> for Tops-20@lingling.panda.com; 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: slogin@optonline.net Subject: The correct way to load a 30 bit address of a local symbol To: Tops-20 Wizards Message-id: 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, ;data on page 2001 INTERN HLPBEG ; Allow file 2 to reference this .PSECT HELP,HLPORG HLPBEG: ; Beginning of help area File 2: IFNDEF CODORG, ; 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: 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 Sender: Mark Crispin Subject: re: The correct way to load a 30 bit address of a local symbol To: slogin@optonline.net cc: Tops-20 Wizards In-Reply-To: Message-ID: 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: 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 To: slogin@optonline.net Cc: Tops-20 Wizards Subject: Re: The correct way to load a 30 bit address of a local symbol In-Reply-To: References: 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: <20040702065305.67B5D42B2@thrintun.hactrn.net> 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: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-<>/>>>*>] CALL (CX) ;; Index instead of indirect >;DEFINE CALLXX 2-Jul-2004 09:48:47-PDT,3252;000000000000 Return-Path: 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 Subject: Re: The correct way to load a 30 bit address of a local symbol To: slogin@optonline.net cc: Tops-20@lingling.panda.com In-Reply-To: Reply-to: gorin@xkl.com Message-ID: <13943096506.14.GORIN@toed.xkl.com> 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: slogin@optonline.net Subject: The correct way to load a 30 bit address of a local symbol To: Tops-20 Wizards 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, ;data on page 2001 INTERN HLPBEG ; Allow file 2 to reference this .PSECT HELP,HLPORG HLPBEG: ; Beginning of help area File 2: IFNDEF CODORG, ; 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: 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 <0I0C0036S7FPHC@mta1.srv.hcvlny.cv.net>; 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: slogin@optonline.net Subject: Re: The correct way to load a 30 bit address of a local symbol To: Ralph Gorin , Mark Crispin Cc: Tops-20 Wizards Message-id: <18f49818f71c.18f71c18f498@optonline.net> 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: <!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: <!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: 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 Sender: Mark Crispin Subject: Re: The correct way to load a 30 bit address of a local symbol To: slogin@optonline.net cc: Ralph Gorin , Tops-20 Wizards In-Reply-To: <18f49818f71c.18f71c18f498@optonline.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII On Sun, 04 Jul 2004 13:04:10 -0400, slogin@optonline.net wrote: > CWDKEY: <!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: !CM%HPP! 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,<!CM%HPP!> 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,,,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 Subject: time for an XCOMD%? To: tops-20@Lingling.Panda.COM Pithy-Thought: TOPS-20 was a great improvement over its successors Message-ID: <13943643096.9.MRC@lingling.panda.com> 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: 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 <0I0J003TVIMT27@mta4.srv.hcvlny.cv.net>; 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: slogin@optonline.net Subject: Re: time for an XCOMD%? To: Mark Crispin Cc: tops-20@lingling.panda.com Message-id: <3c077d3bdb03.3bdb033c077d@optonline.net> 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 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: 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 <0I0M0034EE2W7Z@mta10.srv.hcvlny.cv.net> for Tops-20@lingling.panda.com; 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: slogin@optonline.net Subject: EFTPSR To: Tops-20@lingling.panda.com Message-id: <4594e34563e4.4563e44594e3@optonline.net> 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 {blank line} connects to the user's login directory. 2) CWD user-name will parse for a user name and, on success, will connect to that user's login directory. 3) CWD directory functions as expected. 4) CWD NUL: will force any future file specification with a non-explicit device to default to NUL: 5) CWD file-name 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 . If you are connected to , then CWD BAR puts you in . Note that NO attempt is made to try to make CWD BAR.DIRECTORY.0 work as CWD . 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 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 - 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) - 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) - 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 - 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. - Current connected directory - A particular directory - 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 - toggle current state NOOP - do nothing. CKM - Turn on directory annotation ON - turn it on OFF - turn it off - toggle current state ACCESS - Access a directory AUTO - access a directory on connect ON - turn it on OFF - turn it off - 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 - 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: 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 Sender: Mark Crispin Subject: re: EFTPSR To: slogin@optonline.net cc: Tops-20@lingling.panda.com In-Reply-To: <4594e34563e4.4563e44594e3@optonline.net> Message-ID: 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: 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 <0I0P00MOEHQQND@mta8.srv.hcvlny.cv.net>; 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: slogin@optonline.net Subject: Re: re: EFTPSR To: Mark Crispin Cc: Tops-20@lingling.panda.com Message-id: <11a22711ec0e.11ec0e11a227@optonline.net> 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 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: 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 <0I0P00010HV81E@mta8.srv.hcvlny.cv.net> for Tops-20@lingling.panda.com; 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: slogin@optonline.net Subject: Resuscitating Tops-20 DECtape support To: Tops-20@lingling.panda.com Message-id: <496f6849694f.49694f496f68@optonline.net> 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: 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 <0I0Q00MFPZDJG3@mta9.srv.hcvlny.cv.net> for Tops-20@lingling.panda.com; 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: slogin@optonline.net Subject: What can't live without section zero? To: Tops-20@lingling.panda.com Message-id: <517b08511d78.511d78517b08@optonline.net> 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: 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 Sender: Mark Crispin Subject: re: What can't live without section zero? To: slogin@optonline.net cc: Tops-20@lingling.panda.com In-Reply-To: <517b08511d78.511d78517b08@optonline.net> Message-ID: 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: 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: <517b08511d78.511d78517b08@optonline.net> References: <517b08511d78.511d78517b08@optonline.net> Mime-Version: 1.0 (Apple Message framework v618) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: Ken Rossman , Tops-20@lingling.panda.com From: Ken Rossman Subject: Re: What can't live without section zero? Date: Mon, 12 Jul 2004 20:01:18 -0400 To: slogin@optonline.net 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: 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 Subject: re: What can't live without section zero? To: TOPS-20@lingling.panda.com Reply-to: gorin@xkl.com Message-ID: <13945814551.14.GORIN@toed.xkl.com> 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: 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 <0I0S00JCXQC0I5@mta7.srv.hcvlny.cv.net> for Tops-20@lingling.panda.com; 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: slogin@optonline.net Subject: Re: What can't live without section zero? To: Ken Rossman Cc: Tops-20@lingling.panda.com Message-id: <5c0bb95c2c6d.5c2c6d5c0bb9@optonline.net> 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 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: 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 <0I0T00FWYL15TE@mta10.srv.hcvlny.cv.net> for TOPS-20@lingling.panda.com; 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: slogin@optonline.net Subject: FTPSER starts with OPERATOR capability To: TOPS-20@lingling.panda.com Message-id: <5f93335fa83b.5fa83b5f9333@optonline.net> 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: 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 Sender: Mark Crispin Subject: re: FTPSER starts with OPERATOR capability To: slogin@optonline.net cc: TOPS-20@lingling.panda.com In-Reply-To: <5f93335fa83b.5fa83b5f9333@optonline.net> Message-ID: 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: 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 <0I0Y00KZTST8G9@mta8.srv.hcvlny.cv.net> for TOPS-20@lingling.panda.com; 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: slogin@optonline.net Subject: What happens to section 37 on CR%MAP? To: TOPS-20@lingling.panda.com Message-id: <79d22379e773.79e77379d223@optonline.net> 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: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:XDDT.EXE.1 1-2 R, CW, E 37703-37732 TOPS20:XDDT.EXE.1 3-32 R, CW, E 37735-37736 Private R, W, E 37740-37753 TOPS20: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: 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 <0I0Y004TWW1VW1@mta3.srv.hcvlny.cv.net> for Tops-20@lingling.panda.com; 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: slogin@optonline.net Subject: Re: What can't live without section zero? To: Tops-20@lingling.panda.com Message-id: <42841f42380b.42380b42841f@optonline.net> 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, ; 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: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: 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 Subject: Re: What happens to section 37 on CR%MAP? To: slogin@optonline.net cc: TOPS-20@lingling.panda.com In-Reply-To: <79d22379e773.79e77379d223@optonline.net> Reply-to: gorin@xkl.com Message-ID: <13946862578.8.GORIN@toed.xkl.com> 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 Subject: Re: What happens to section 37 on CR%MAP? To: TOPS-20@Lingling.Panda.COM, gorin@toed.xkl.com In-Reply-To: <13946862578.8.GORIN@toed.xkl.com> Pithy-Thought: TOPS-20 was a great improvement over its successors Message-ID: <13946979671.9.MRC@lingling.panda.com> 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: 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 <0I1B00MOYZS6IE@mta9.srv.hcvlny.cv.net> for TOPS-20@lingling.panda.com; 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: slogin@optonline.net Subject: RETR partially implemented, first transfer on new FTPSER!! To: TOPS-20@lingling.panda.com Message-id: 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: 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 <0I1I00LJ6GVIE9@mta10.srv.hcvlny.cv.net> for TOPS-20@lingling.panda.com; 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: slogin@optonline.net Subject: MLFL, MAIL, MSND, MSOM, MSAM, MRSQ, MRCP To: TOPS-20@lingling.panda.com Message-id: 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: 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 Tops-20@lingling.panda.com; 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 To: Tops-20 Wizards Content-Transfer-Encoding: 7bit Message-Id: <1CF10236-E112-11D8-98BB-000A959E889E@reststop.com> 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: 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: <0ca701c47566$01df4560$7d220209@watson.ibm.com> From: "David F. Bacon" To: "Carl Baltrunas" , "Tops-20 Wizards" References: <1CF10236-E112-11D8-98BB-000A959E889E@reststop.com> 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" To: "Tops-20 Wizards" 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: 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: In-Reply-To: <0ca701c47566$01df4560$7d220209@watson.ibm.com> References: <1CF10236-E112-11D8-98BB-000A959E889E@reststop.com> <0ca701c47566$01df4560$7d220209@watson.ibm.com> Date: Thu, 29 Jul 2004 10:37:05 -0400 To: "Tops-20 Wizards" From: Paul Wexelblat 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: 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 To: slogin@optonline.net cc: TOPS-20@lingling.panda.com Subject: Re: MLFL, MAIL, MSND, MSOM, MSAM, MRSQ, MRCP In-Reply-To: Message-ID: References: Organization: Networks & Distributed Computing Sender: MRC@lingling.panda.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed On Tue, 27 Jul 2004 slogin@optonline.net 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: 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 <0I1W0092762YAJ@mta9.srv.hcvlny.cv.net> for TOPS-20@lingling.panda.com; 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: slogin@optonline.net Subject: MDTM and SIZE for TVFS To: TOPS-20@lingling.panda.com Message-id: <338a8c3375e3.3375e3338a8c@optonline.net> 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:BAR.DIRECTORY becomes PS: 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: 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 <0I1W00HB78LLP1@mta2.srv.hcvlny.cv.net> for Tops-20@LingLing.Panda.COM; 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: slogin@optonline.net Subject: Re: MLFL, MAIL, MSND, MSOM, MSAM, MRSQ, MRCP To: Mark Crispin Cc: Tops-20@LingLing.Panda.COM Message-id: <31765f3150fe.3150fe31765f@optonline.net> 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: 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 Date: Tue, 3 Aug 2004 17:07:22 PDT From: William "Chops" Westfield To: slogin@optonline.net Cc: Mark Crispin , Tops-20@LingLing.Panda.COM 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: Weren't there a couple of system that still used FTP for the "send" command ("send billw@cisco.com 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 Subject: Re: MLFL, MAIL, MSND, MSOM, MSAM, MRSQ, MRCP To: slogin@optonline.net cc: Tops-20@Lingling.Panda.COM In-Reply-To: <31765f3150fe.3150fe31765f@optonline.net> Pithy-Thought: TOPS-20 was a great improvement over its successors Message-ID: <13951880898.13.MRC@lingling.panda.com> > 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: 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 <0I1Z00J84DIHVH@mta6.srv.hcvlny.cv.net>; 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: slogin@optonline.net Subject: Re: MLFL, MAIL, MSND, MSOM, MSAM, MRSQ, MRCP To: Mark Crispin Cc: Tops-20@lingling.panda.com Message-id: <43e31d43d789.43d78943e31d@optonline.net> 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: 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 To: slogin@optonline.net Cc: Mark Crispin , Tops-20@lingling.panda.com Subject: Re: MLFL, MAIL, MSND, MSOM, MSAM, MRSQ, MRCP In-Reply-To: <43e31d43d789.43d78943e31d@optonline.net> Message-ID: > > 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 node:: 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: 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 ; Thu, 5 Aug 2004 13:34:12 -0400 Message-ID: <1091727252.41126f9428b57@cubmail.cc.columbia.edu> Date: Thu, 5 Aug 2004 13:34:12 -0400 From: rossman@columbia.edu To: Frank da Cruz , Tops-20@lingling.panda.com Subject: Re: MLFL, MAIL, MSND, MSOM, MSAM, MRSQ, MRCP References: In-Reply-To: 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 : > > > 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 node:: > > 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: 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 Date: Thu, 5 Aug 2004 13:41:01 PDT From: William "Chops" Westfield To: slogin@optonline.net Cc: Mark Crispin , Tops-20@lingling.panda.com 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: 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: 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 <0I2400LKP0ZWFV@mta6.srv.hcvlny.cv.net> for Tops-20@lingling.panda.com; 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: slogin@optonline.net Subject: One word global byte pointer P&S 39 and 40 To: Tops-20@lingling.panda.com Message-id: <5a69085a77e6.5a77e65a6908@optonline.net> 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: 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 ; 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 Tops-20@lingling.panda.com; Sun, 8 Aug 2004 09:36:31 +0200 (MEST) Date: Sun, 8 Aug 2004 9:36:31 WET DST From: Johnny Eriksson To: Tops-20@lingling.panda.com 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: slogin@optonline.net 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: 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 <0I2X00A5AG3ONX@mta9.srv.hcvlny.cv.net> for Tops-20@lingling.panda.com; 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: slogin@optonline.net Subject: KL-10/KLH-10 NI & Toad Ethernet Interface Speeds To: Tops-20@lingling.panda.com Message-id: <5ff1615fce5c.5fce5c5ff161@optonline.net> 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: 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 Sender: mrc@Ikkoku-Kan.Panda.COM To: slogin@optonline.net cc: Tops-20@lingling.panda.com Subject: Re: KL-10/KLH-10 NI & Toad Ethernet Interface Speeds In-Reply-To: <5ff1615fce5c.5fce5c5ff161@optonline.net> Message-ID: References: <5ff1615fce5c.5fce5c5ff161@optonline.net> Organization: Pandamonium Reigns MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed On Mon, 23 Aug 2004 slogin@optonline.net 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: 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 <0I3000L3DSFYMG@mta4.srv.hcvlny.cv.net>; 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: slogin@optonline.net Subject: Re: KL-10/KLH-10 NI & Toad Ethernet Interface Speeds To: Mark Crispin Cc: Tops-20@lingling.panda.com Message-id: <6f65cc6fc94a.6fc94a6f65cc@optonline.net> 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: 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 , Tops-20@Lingling.Panda.COM To: slogin@optonline.net From: Carl Baltrunas In-Reply-To: <6f65cc6fc94a.6fc94a6f65cc@optonline.net> Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.553) On Wednesday, August 25, 2004, at 01:47 PM, slogin@optonline.net 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: 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 To: Carl Baltrunas Cc: slogin@optonline.net, Mark Crispin , Tops-20@Lingling.Panda.COM Subject: Re: KL-10/KLH-10 NI & Toad Ethernet Interface Speeds In-Reply-To: Message-ID: > 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: 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 <0I4100FHZGU132@mta7.srv.hcvlny.cv.net> for Tops-20@lingling.panda.com; 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: slogin@optonline.net Subject: How's your TOD? To: Tops-20@lingling.panda.com Message-id: <2145d4214f79.214f792145d4@optonline.net> 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: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:TIMCHK.CTL.0 /After:+72:00 /Assistance:Yes - @ /Batch-Log:Append /Connected-Directory:PS: - @ /LogDisposition:Keep /LogName:PS:TIMCHK.LOG.0 /Notify:No - @ /Output:NoLog /Restartable:YES /Unique:No /User:OPERATOR @Goto END %ERR:: @Submit PS:TIMCHK.CTL.0 /After:+1:00 /Assistance:Yes - @ /Batch-Log:Append /Connected-Directory:PS: - @ /LogDisposition:Keep /LogName:PS: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: 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 ; 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 Tops-20@lingling.panda.com; 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 To: Tops-20 Wizards Content-Transfer-Encoding: 7bit In-Reply-To: <2145d4214f79.214f792145d4@optonline.net> Message-Id: <0C517AE6-06C0-11D9-92AB-000A959E889E@reststop.com> 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, slogin@optonline.net 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 Subject: Re: How's your TOD? To: slogin@optonline.net cc: Tops-20@Lingling.Panda.COM In-Reply-To: <2145d4214f79.214f792145d4@optonline.net> Pithy-Thought: TOPS-20 was a great improvement over its successors Message-ID: <13962628420.9.MRC@Lingling.Panda.COM> > 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: 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 <0I4A00DK8ZNCG6@mta7.srv.hcvlny.cv.net>; 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: slogin@optonline.net Subject: Re: How's your TOD? To: Mark Crispin Cc: Tops-20@Lingling.Panda.COM Message-id: <15f0971619f5.1619f515f097@optonline.net> 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 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 Subject: Re: How's your TOD? To: slogin@optonline.net cc: tops-20@Lingling.Panda.COM In-Reply-To: <15f0971619f5.1619f515f097@optonline.net> Pithy-Thought: TOPS-20 was a great improvement over its successors Message-ID: <13963851742.9.MRC@lingling.panda.com> > 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 Subject: bug in CR%MAP option for CFORK% To: TOPS-20@Lingling.Panda.COM Pithy-Thought: TOPS-20 was a great improvement over its successors Message-ID: <13964099771.9.MRC@lingling.panda.com> 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: 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 <0I4E00H6UM9GMI@mta1.srv.hcvlny.cv.net>; 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: slogin@optonline.net Subject: Re: bug in CR%MAP option for CFORK% To: Mark Crispin Cc: TOPS-20@lingling.panda.com Message-id: <2ded5e2dfed3.2dfed32ded5e@optonline.net> 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 Subject: Re: bug in CR%MAP option for CFORK% To: slogin@optonline.net cc: TOPS-20@Lingling.Panda.COM In-Reply-To: <2ded5e2dfed3.2dfed32ded5e@optonline.net> Pithy-Thought: TOPS-20 was a great improvement over its successors Message-ID: <13964417099.10.MRC@lingling.panda.com> 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: 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 <0I4K008YS2W50C@mta8.srv.hcvlny.cv.net>; 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: slogin@optonline.net Subject: Re: bug in CR%MAP option for CFORK% To: Mark Crispin Cc: TOPS-20@lingling.panda.com Message-id: 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: 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 To: slogin@optonline.net cc: TOPS-20@lingling.panda.com Subject: Re: bug in CR%MAP option for CFORK% In-Reply-To: Message-ID: References: Organization: Networks & Distributed Computing Sender: mrc@ndcms.cac.washington.edu MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed On Fri, 24 Sep 2004 slogin@optonline.net 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 Subject: Happy DEC-20 Day! To: TOPS-20@Lingling.Panda.COM Pithy-Thought: TOPS-20 was a great improvement over its successors Message-ID: <13987920440.9.MRC@lingling.panda.com> 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! -------