4-Jan-2007 17:16:56-PST,1637;000000000000 Return-Path: Received: from pangtzu.panda.com ([206.124.149.117]) by lingling.panda.com with TCP/SMTP; Thu, 4 Jan 2007 17:12:41 -0800 (PST) X-Return-Path: X-Received: from pangtzu.panda.com ([206.124.149.117]) by lingling.panda.com with TCP/SMTP; Thu, 4 Jan 2007 16:58:25 -0800 (PST) Date: Thu, 4 Jan 2007 16:58:21 -0800 (PST) From: Mark Crispin Sender: mrc@pangtzu.panda.com To: TOPS-20 Hackers and Yackers Subject: TOPS-20 list traffic: second highest year ever! Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed ReSent-Date: Thu, 4 Jan 2007 17:12:11 -0800 (PST) ReSent-From: TOPS-20 List Moderator ReSent-To: TOPS-20 Distribution: ; ReSent-Subject: TOPS-20 list traffic: second highest year ever! ReSent-Message-ID: The TOPS-20 list continued its remarkable activity in 2006, scoring a remarkable 437 disk pages of mail. That beats the previous #2 record year, 1983 (433 pages), and comes close to the all-time record year of 1982 with 442 pages. Sadly, the first two messages of 2007 were spam. Your humble & obedient moderator purged them from the queue upon his return from a week-long vacation in Japan. And he had thought, with nearly a year of no spam hitting the list, that we could go back to non-moderation... ;-( -- Mark -- http://panda.com/tops-20 TOPS-20: a great improvement over its successors 10-Feb-2007 21:11:19-PST,5508;000000000000 Return-Path: Received: from pangtzu.panda.com ([206.124.149.117]) by lingling.panda.com with TCP/SMTP; Sat, 10 Feb 2007 21:06:39 -0800 (PST) X-Return-Path: X-Received: from mta3.srv.hcvlny.cv.net ([167.206.4.198]) by lingling.panda.com with TCP/SMTP; Sat, 10 Feb 2007 17:38:11 -0800 (PST) X-Received: from optonline.net (mstr3a.srv.hcvlny.cv.net [10.240.4.140]) by mta3.srv.hcvlny.cv.net (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTP id <0JD900LBNZ7GEA70@mta3.srv.hcvlny.cv.net> for TOPS-20@Lingling.Panda.COM; Sat, 10 Feb 2007 20:38:05 -0500 (EST) X-Received: from [10.240.3.203] (Forwarded-For: 69.114.1.48, [10.240.3.203]) by mstr3.srv.hcvlny.cv.net (mshttpd); Sun, 11 Feb 2007 01:38:04 +0000 (GMT) Date: Sun, 11 Feb 2007 01:38:04 +0000 (GMT) From: slogin@optonline.net Subject: Floating Away, Doubly So To: TOPS-20@Lingling.Panda.COM Message-id: MIME-version: 1.0 X-Mailer: Sun Java(tm) System Messenger Express 6.2-6.01 (built Apr 3 2006) Content-type: text/plain; charset=us-ascii Content-language: en Content-transfer-encoding: 7BIT Content-disposition: inline X-Accept-Language: en Priority: normal ReSent-Date: Sat, 10 Feb 2007 21:06:30 -0800 (PST) ReSent-From: TOPS-20 List Moderator ReSent-To: TOPS-20 Distribution: ; ReSent-Subject: Floating Away, Doubly So ReSent-Message-ID: I wanted to have the FTP server type out some statistics and was looking for an easy way to do this. Right now, I have some numbers in double integer format. I doubt I need that much precision, but it was easy enough and I didn't have to check for overflow. Besides... who knows? However, I needed to give some estimates, so that suggested using double floating point (again, the precision isn't really an issue) and then using DFOUT% with the appropriate bits set to limit the decimal digits typed. However, I seem to have misremembered some things about double floating point and Tops-20. Around 1979, I was taking WPI's Numerical Methods class (we called it 'Nums'). Professor Perry (a very, very nice man) wanted the assignment programs written in something high level, I think it was Algol (or Pascal or Fortran). I didn't much care for the TA, a graduate student who we all thought wasn't up to our hackerly level. So, I did the assignments in assembler. They ran faster in less memory and had more precision. I was given due hackerly admiration, but completely missed the point of Nums in the first place. As I tried to remember what I had done back then, I recalled that I had had to do some tinkering to get Tops-20 to output my results. At that point (version 3A?), I believe DFIN% and DFOUT% wanted KA-10 format software double precision. G. Leavitt and I stayed up late one night, writing some routines to convert between KL machine format and KA software format. What fun! Nearly 30 years later, I thought that I was going to have to do the same fun thing, but now as I look at MFLIN and MFLOUT, I see that D. Murphy seems to have put in some support in Q3 '79 to change DFLOUT and DFIN to use the KL format, viz: ;<4.MONITOR>MFLIN.MAC.5, 26-Sep-79 23:12:24, EDIT BY MURPHY ;ELIMINATE USE OF FUNNY FORMAT EXTENDED RANGE DOUBLE PRECISION ;FLOATING POINT NUMBERS - USE DOUBLE PRECISION MACHINE INSTRUCTIONS ;FOR ARITHMETIC I guess this editing must have been done on 2102 because that night we were using 2116, which still must have been running something three'ish. But I don't remember ever using DFOUT% ever again. Did anybody? Does it do KL or KA type double floating point? From MFLOUT, it looks like it's doing KL floating point. Second, I can not remember how to float a double precision integer! I thought there was something like a DFLTR, but there isn't. There is a GFLTR, but I don't remember using it (it may not have existed in '79) and it doesn't do what I want, anyway. There's FLTR, but ... Anybody care to jog my quirky memory? For the time being, I simply do integer divides and then appropriately manage the remainder to produce digits that are part of a decimal fraction. It's easy enough (and probably faster than using floating point, anyway). As a coda to Nums: I don't remember that the TA even understood assembler; he certainly wasn't very happy about trying to grade it, which was, of course, no small part of the reason that I was doing it that way to begin with ... When he complained about it, I flounced into Perry's office where he very kindly suggested that I do the assignments both in assembler and Algol and then compare the two, giving the Algol (or Pascal or Fortran?) to the TA. I think I must have amused him; what a patient man. With respect to the FTP server, I've put in some additional post transfer reporting to analyze some traffic questions. I've also changed the server to be able to execute from any section and I've caught a few bugs that way. I've completed (re)fixing the small buffer storage problem for 36 bit retrievals. I've (re)begun work on the 36 bit STOR buffering (the conversion code has been finished for quite some time). The initial design for the paged file structure transfer is complete. This isn't a heck of a lot of work to do, but with a new job and a new baby ... Sigh ... 22-Feb-2007 11:09:18-PST,2198;000000000000 Return-Path: Received: from pangtzu.panda.com ([206.124.149.117]) by lingling.panda.com with TCP/SMTP; Thu, 22 Feb 2007 11:05:10 -0800 (PST) X-Return-Path: X-Received: from pangtzu.panda.com ([206.124.149.117]) by lingling.panda.com with TCP/SMTP; Thu, 22 Feb 2007 10:10:18 -0800 (PST) Date: Thu, 22 Feb 2007 10:10:13 -0800 (PST) From: Mark Crispin Sender: mrc@pangtzu.panda.com To: TOPS-20 Hackers and Yackers Subject: TOPS-20 mailing list SMTP server now doing HELO validation Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=us-ascii ReSent-Date: Thu, 22 Feb 2007 11:05:02 -0800 (PST) ReSent-From: TOPS-20 List Moderator ReSent-To: TOPS-20 Distribution: ; ReSent-Subject: TOPS-20 mailing list SMTP server now doing HELO validation ReSent-Message-ID: In the past few weeks, there has been an upsurge in spam aimed at the TOPS-20 list. It's all from systems in Red China, and is for Japanese language pornography. None of it has actually gotten through because I've been moderating the incoming traffic and deleting it. However, I really want to get out of the business of censoring TOPS-20 list traffic, while still keeping the TOPS-20 list on an actual TOPS-20 system. Since this particular spammer is using forged HELO addresses (it's falsely claiming to be from a Japanese cell phone), I've turned on HELO validation in the TOPS-20 SMTP server on Lingling.Panda.COM. What this means is that the name presented in a HELO/EHLO command must match the client IP address with a forward DNS lookup (it's too easy for spammers to spoof reverse lookups). If anyone has trouble posting to the TOPS-20 list (and in particular, starts receiving "you are a charlatan" bounces), please let me know. You can use my UW address, mrc@cac.washington.edu, if you can't get through to Lingling. -- Mark -- http://panda.com/tops-20 TOPS-20: a great improvement over its successors 23-Feb-2007 10:12:43-PST,8179;000000000000 Return-Path: Received: from pangtzu.panda.com ([206.124.149.117]) by lingling.panda.com with TCP/SMTP; Fri, 23 Feb 2007 10:08:52 -0800 (PST) X-Return-Path: X-Received: from mta1.srv.hcvlny.cv.net ([167.206.4.196]) by lingling.panda.com with TCP/SMTP; Fri, 23 Feb 2007 07:34:51 -0800 (PST) X-Received: from optonline.net (mstr3a.srv.hcvlny.cv.net [10.240.4.140]) by mta1.srv.hcvlny.cv.net (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTP id <0JDX00IDU9XWU160@mta1.srv.hcvlny.cv.net> for TOPS-20@Lingling.Panda.COM; Fri, 23 Feb 2007 10:34:45 -0500 (EST) X-Received: from [10.240.3.199] (Forwarded-For: 69.114.1.48, [10.240.3.199]) by mstr3.srv.hcvlny.cv.net (mshttpd); Fri, 23 Feb 2007 15:34:44 +0000 (GMT) Date: Fri, 23 Feb 2007 15:34:44 +0000 (GMT) From: slogin@optonline.net Subject: Cancelled tape mount requests inconsistently detected in batch streams In-reply-to: To: TOPS-20 Wizards Message-id: MIME-version: 1.0 X-Mailer: Sun Java(tm) System Messenger Express 6.2-6.01 (built Apr 3 2006) Content-type: text/plain; charset=us-ascii Content-language: en Content-transfer-encoding: 7BIT Content-disposition: inline X-Accept-Language: en Priority: normal References: ReSent-Date: Fri, 23 Feb 2007 10:01:20 -0800 (PST) ReSent-From: TOPS-20 List Moderator ReSent-To: TOPS-20 Distribution: ; ReSent-Subject: Cancelled tape mount requests inconsistently detected in batch streams ReSent-Message-ID: Problem: ======== Galaxy errors which happen in batch jobs are not always detected correctly. This will happen both in a Toad and a PANDA EXEC. Workaround: =========== Use the EXEC REWIND command on the requested logical name before starting actual processing and look for an error there. If the REWIND fails (because the logical name is undefined), then the mount failed. Background: =========== After more than four years and two months in operation, it occurred to me that depending on $200 hardware that wasn't being consistently backed up probably wasn't such a great idea. I've accumulated a great deal of j random cuspy detritus ... So, I implemented a batch job to do a quarterly backup. Once every 2,191 hours and thirty minutes, it starts. It sends me a text page and then requests a tape mount for a new tape. I sign on to the KLH10 host and mount a tape as a file on another system's RAID. Then I name the tape volume as an abbreviation of the tape file name, identify the volume to the mount request and away we go. Note the purpose of doing it this way is five fold: 1) It doesn't work if you just assign the tape drive and try to use it. You have to have done a devmount in KLH10 first and it probably isn't a good idea to always keep a file 'mounted' all the time, either. 2) I don't remember how to Use PLEASE or if it would work. (I think it could be made to) 3) Doing it this way gets the tape name logged in the ORION log file. This can reviewed later to match up the batch job with the associated tape file name--a definite plus after a few months of forgetting what went where on the RAID. 4) This is the way the batch and mount (AVR) sub-systems are designed to be used. 5) This is the way we did it at Columbia and for some strange reason, I actually remembered that, so there was no learning curve. But, constructing the batch job itself involved me cancelling a number of mount requests and these (along with the tape label refusals) were not always properly detected. I finally got curious ... Analysis: ========= BATCON defines a job error as any line that begins with a question mark. In other words, the sequence ? will cause BATCON to start skipping control file input, searching for an %ERR label. While the canceled or refused tape is properly detected by the EXEC, the error message itself is not always prefixed with ?. Sometimes, although not always, you will get ^G^G^G^G^G ^G?, instead. It is these intervening bells that are causing BATCON not to recognize the error--in this case the reported canceled or refused tape mount. Essentially, the EXEC is not following the ESOUT% 'standard'. The decision as to whether to ring the bell or not during IPCF message reception is driven by the setting of AUTOF. This variable is used for automatic mail and alerts. The timer routine (INTPSI) sets it to flag that it's time to have a look at things. If you quickly cancel the tape mount right after making it and there is no intervening timer interrupt, then the EXEC won't type the bells and the error will be properly detected by BATCON. Note that explicitly turning off automatic mail watching in the batch job (I.E., typing, "SET NO AUTOMATIC") will NOT work because INTPSI will still set AUTOF. However, if you wait awhile, then the bells happen because AUTOF has been set. Cure: ===== There are a number of ways to fix this. One notices that the bell is going to be rung a lot (9 times) if a mount request is canceled after a PSI check period. That's probably going to be annoying on an LA36 and downright dreadful on an ASR33, but these days ... One approach might be to change the code with interprets Galaxy responses (QUASAR) at INTANS to ring the bell AFTER it types out the error messages. Some reworking might also be appropriate to limit the number of feeps. However, this got to be a little more complicated than what I would have liked when the following thought occured to me. No matter what the setting of mail watch is, checking for new mail is explicitly NOT done by MWATCH when running in a batch stream. This is probably a good idea as having an unexpected message come out into the the middle of a batch stream runs the risk of it being mis-interpreted by BATCON. But more obvious is the fact that there is no real reason to ring the bell in a batch stream in the first place. BATCON is always listening, so there is no need to fweep to get its attention. The following change therefor suggests itself. In EXECMT.EXE at INTA2:, change the following code from: INTA2: SKIPE AUTOF ;RING BELLS IF CALLED FROM INTERRUPT TYPE <^G^G^G> To: INTA2: SKIPN BATCHF ;[T43] Are we in a batch stream? SKIPN AUTOF ;[T43] RING BELLS IF CALLED FROM INTERRUPT TRNA ;[T43] No noise if either batch or not TYPE <^G^G^G> ;[T43] from an interrupt Note: In this e-mail, the Bells or Control-G's in TYPE have been changed to ^uparrow-G, so don't just cut and paste this--it needs to be re-feepified. Finally, I had also considered making a change to BATCON to have it not count characters after a that don't change the horizontal position, perhaps by doing an RFPOS% when it sees a "?". The would probably produce definitive results and fix other programs which don't follow the ESOUT% 'standard'. I'll have to think about that some more before I do anything (if anything). One assumes that programs that don't follow the ESOUT% 'standard' are broken and should be fixed. On the other hand, if the sources to these programs are not available, then fixing them may be probablematic, at best. For now, I think that the EXEC should definately be changed in this regard. Besides, not having all those ^G's in the log file definately makes it easier to read! 24-Feb-2007 21:36:57-PST,12552;000000000000 Return-Path: Received: from pangtzu.panda.com ([206.124.149.117]) by lingling.panda.com with TCP/SMTP; Sat, 24 Feb 2007 21:32:52 -0800 (PST) X-Return-Path: X-Received: from mta5.srv.hcvlny.cv.net ([167.206.4.200]) by lingling.panda.com with TCP/SMTP; Sat, 24 Feb 2007 21:21:04 -0800 (PST) X-Received: from optonline.net (mstr3a.srv.hcvlny.cv.net [10.240.4.140]) by mta5.srv.hcvlny.cv.net (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTP id <0JE000H5L6UWE1G0@mta5.srv.hcvlny.cv.net> for TOPS-20@Lingling.Panda.COM; Sun, 25 Feb 2007 00:20:58 -0500 (EST) X-Received: from [10.240.3.208] (Forwarded-For: 64.72.85.122, [10.240.3.208]) by mstr3.srv.hcvlny.cv.net (mshttpd); Sun, 25 Feb 2007 05:20:56 +0000 (GMT) Date: Sun, 25 Feb 2007 05:20:56 +0000 (GMT) From: slogin@optonline.net Subject: FIND issues with non-ASCII files In-reply-to: To: TOPS-20 Wizards Message-id: MIME-version: 1.0 X-Mailer: Sun Java(tm) System Messenger Express 6.2-6.01 (built Apr 3 2006) Content-type: text/plain; charset=us-ascii Content-language: en Content-transfer-encoding: 7BIT Content-disposition: inline X-Accept-Language: en Priority: normal References: ReSent-Date: Sat, 24 Feb 2007 21:32:44 -0800 (PST) ReSent-From: TOPS-20 List Moderator ReSent-To: TOPS-20 Distribution: ; ReSent-Subject: FIND issues with non-ASCII files ReSent-Message-ID: Symptom: ======== FIND can crash on files with incorrect byte counts, among other things. Example: ======== !VDIRECTORY (VERBOSE, OF FILES) TOMMYT:CAVE.DAT.1 TOMMYT: CAVE.DAT.1;P776060 3 34359738367(36) 27-Aug-2006 23:44:55 SLOGIN Total of 3 pages in 1 file !FIND FIND %2(50) FIND>STRING FOO FIND>FILES (TO SEARCH) TOMMYT:CAVE.DAT.1 FIND>INF Files to search specified are: 1. TOMMYT:CAVE.DAT.0 Strings to search for are: 1. FOO Listing format is complete listing. Filenames will not be typed for each file as searched. FIND>LIST ?Illegal instruction EXTEND P1,DSLITS+377 at SCAN ?Undefined operation code Analysis: ========= FIND is using the file byte count without checking it. For files with non-ASCII (7 bit) byte sizes, it calculates what the count of characters would be by multiplying the byte count by the byte size and then dividing by 7. Doing that arithmatic with the above number (positive infinity), causes overflow with the result being a number that causes MOVST to generate an error. The "?Undefined operation code" message is misleading. Further, if the file has holes in it, FIND will get a read error trying to sequencially process the pages. Cure: ===== Calculate what the maximum possible byte count could be and if the reported byte count isn't in this range, use the maximum. Skip files with holes in them--searching the Quasar queue file may not be immediately fruitful... While we're at it, have a look at the FDB and don't bother trying to open files that we won't be able to use. Saves us some OPENF%s with the same amount of GTFDB%s File 1) DSK:FIND.MAC[4,110] created: 2328 24-Feb-07 File 2) DSK:FIND.BAK[4,110] created: 0910 24-Feb-82 1)1 ;[TOMMYT]STAR:FIND.MAC.2, 23-Feb-2007 17:01:30, Edit by SLOGIN 1) ;[T44] Make FIND not gronk on files with random byte counts 1) TITLE FIND SUBSTRING SEARCH PROGRAM **** 2)1 TITLE FIND SUBSTRING SEARCH PROGRAM ************** 1)1 .REQUIRE ZSUBS ;[T44] Pull in the subroutines 1) .DIRECT FLBLST ;AND NICE LISTING **** 2)1 .DIRECT FLBLST ;AND NICE LISTING ************** 1)1 VEDIT==51 ;[T44] EDIT LEVEL 1) VWHO==2 ;[T44] Customer edited 1) ;FIND is a substring search program. The canonical use is to search **** 2)1 VEDIT==50 ;EDIT LEVEL 2) VWHO==0 ;WHO LAST EDITED 2) ;FIND is a substring search program. The canonical use is to search ************** 1)6 DEFINE MESSAGE (STRING),<[ASCIZ \STRING\]> ;[T44] Text for errors 1)7 SUBTTL ENTRY VECTOR AND INITIALIZATION **** 2)7 SUBTTL ENTRY VECTOR AND INITIALIZATION ************** 1)21 IDIVX T1,SEGBY ;[T44] NUMBER OF BYTES 1) MOVE P1,T2 ;GET REMAINDER IF NOW NON-BIG **** 2)21 IDIVI T1,SEGBY ;NUMBER OF BYTES 2) MOVE P1,T2 ;GET REMAINDER IF NOW NON-BIG ************** 1)25 DMOVE T2,[EXP <.FBLEN,,.FBHDR>,FILFDB] ;[T44] 1) GTFDB% ;[T44] Pull out the ENTIRE FDB 1) IFJE. R ;[T44] Couldn't?? 1) MOVEI T1,MESSAGE 1) JRST NXTERN ;[T44] Handle the rest of the error 1) ENDIF. ;[T44] End case of failed index read 1) MOVE T3,FILFDB+.FBCTL ;[T44] Load up the control words 1) TXNN T3,FB%NXF ;[T44] Will an OPENF% fail? 1) IFSKP. ;[T44] Yes, don't bother 1) MOVEI T1,MESSAGE 1) JRST NXTERN ;[T44] Handle the rest of the error 1) ENDIF. ;[T44] End case non-existant file 1) TXNN T3,FB%DIR ;[T44] Is this a directory? 1) IFSKP. ;[T44] Don't want to open one of those 1) MOVEI T1,MESSAGE 1) JRST NXTERN ;[T44] Hit the error handler 1) ENDIF. ;[T44] End case of directory file 1) TXNN T3,FB%OFF ;[T44] Is the file offline? 1) IFSKP. ;[T44] Nothing in there to search 1) MOVEI T1,MESSAGE 1) JRST NXTERN ;[T44] Hit the error handler 1) ENDIF. ;[T44] End case of offline file 1) MOVX T2,OF%RD ;OPENING JUST FOR READ 1) OPENF ;TRY THE OPEN 1) IFJE. R ;[T44] Couldn't?? 1) MOVEI T1,MESSAGE 1) JRST NXTERN ;[T44] How about doing thawed at some point? 1) ENDIF. ;[T44] End case of failed OPENF% 1) FFFFP% ;[T44] Find the first free page from zero 1) IFJE. R ;[T44] Couldn't?? 1) MOVEI T1,MESSAGE 1) JRST NXTERR ;[T44] Try the next file 1) ENDIF. ;[T44] End case of failed index read 1) HRRZ T4,T1 ;[T44] Save the first free page 1) DMOVE P1,FILFDB+.FBBYV ;[T44] Load file byte size, counts 1) HRRZ T3,P1 ;[T44] Pick up the number of pages 1) CAMN T3,T4 ;[T44] A contiguous file?? 1) IFSKP. ;[T44] No! 1) MOVEI T1,MESSAGE 1) JRST NXTERR ;[T44] Try the next file 1) ENDIF. ;[T44] End case of non-contiguous file 1) IMULX T3,<^D512*^D5> ;[T44] Calculate maximum possible characters 1) ;... 1)26 ;... 1) HRRZM P1,TFSIZE ;SAVE THE TOTAL FILE SIZE IN PAGES **** 2)25 MOVX T2,OF%RD ;OPENING JUST FOR READ 2) OPENF ;TRY THE OPEN 2) ERJMP [AOS FSKIP ;COUNT UP NUMBER SKIPPED 2) TXNN F,FL%GEF ;GIVE ALL FILES MODE? 2) JRST NXTFI0 ; NO, BE SILENT. 2) HRRZ T1,FILJFN ;GET JFN BACK 2) MOVE T2,[1,,.FBCTL] ;WANT TO READ JUST .FBCTL 2) MOVEI T3,T3 ;INTO T3 IS FINE 2) GTFDB ;READ FDB 2) ERJMP LOSE 2) TXNN T3,FB%OFF ;OFF-LINE? 2) WARN ;NO, GIVE THIS MESSAGE 2) TXNE T3,FB%OFF ;OFF-LINE? 2) WARN ;SAY SORRY 2) TYPJFN FILJFN,FULL ;GIVE THE NAME 2) TYPE < 2) > ;CRLF THE LINE 2) JRST NXTFI0] ;AND TRY ANOTHER 2) ;... 2)26 ;... 2) MOVE T2,[2,,.FBBYV] ;WORDS TO READ FROM FDB 2) MOVEI T3,P1 ;WHERE TO READ THEM 2) GTFDB ;READ THEM 2) ERJMP LOSE 2) HRRZM P1,TFSIZE ;SAVE THE TOTAL FILE SIZE IN PAGES ************** 1)26 CAILE P2,0 ;[T44] Negative or other funkyness? 1) CAMLE P2,T3 ;[T44] Greater than maximum possible? 1) MOVE P2,T3 ;[T44] Yes, clip down to maximum 1) MOVEM P2,FBYTCT ;SAVING BYTE COUNT FOR FILE **** 2)26 MOVEM P2,FBYTCT ;SAVING BYTE COUNT FOR FILE ************** 1)26 IFJE. R ;[T44] Couldn't?? 1) MOVEI T1,MESSAGE 1) JRST NXTERR ;[T44] Try the next file 1) ENDIF. ;[T44] End case of failed file read 1) RETSKP ;RETURN WITH NEXT FILE 1)27 SUBTTL Handle various error message from stepping loop 1) NXTERN: CALL NXTMSG ;[T44] Display a message, if any 1) JRST NXTWON ;[T44] Count and loop 1) 1) NXTERR: CALL NXTMSG ;[T44] Display a message, if any 1) HRRZ T1,FILJFN ;[T44] Load up this poor file ... 1) TXO T1,CO%NRJ ;[T44] Don't kill our wildcard!!! 1) CLOSF% ;[T44] Close the file 1) ERJMPR .+1 ;[T44] And ignore the error 1) NXTWON: AOS FSKIP ;[T44] Tally the file anyway 1) JRST NXTFI0 ;[T44] Try the next file 1) NXTMSG: TXNN F,FL%GEF ;[T44] Is the user interested? 1) IFSKP. ;[T44] Yes, give an error message 1) HRLI T1,(WARN.) ;[T44] Construct the UUO call 1) XCT T1 ;[T44] And invoke it 1) TYPJFN FILJFN,FULL ;[T44] Type the file we won't search 1) TYPE < 1) > ;[T44] Tie off the line 1) ENDIF. ;[T44] End case of error message 1) RET ;[T44] Handle the rest of the error 1)28 SUBTTL MORE ROUTINE TO MAP NEXT FILE SEGMENT **** 2)26 ERJMP [LERROR ] 2) RETSKP ;RETURN WITH NEXT FILE 2)27 SUBTTL MORE ROUTINE TO MAP NEXT FILE SEGMENT ************** 1)31 FILFDB: BLOCK .FBLEN ;[T44] Space for the entire FDB 1)32 ;XTBL IS THE TRANSLATION TABLE FOR THE MOVST INSTRUCTION. **** 2)31 ;XTBL IS THE TRANSLATION TABLE FOR THE MOVST INSTRUCTION. ************** Caveats: ======== 1) As written, FIND will not assemble without errors because an IDIVI is using a symbol (SEGBY) whose value is larger than 18 bits. 2) As written, the FIND.CTL file will not properly link FIND. It doesn't load the ZSUBS routine package. This has been fixed with a .REQUIRE directive. 25-Feb-2007 08:37:50-PST,1664;000000000000 Return-Path: Received: from pangtzu.panda.com ([206.124.149.117]) by lingling.panda.com with TCP/SMTP; Sun, 25 Feb 2007 08:33:51 -0800 (PST) X-Return-Path: X-Received: from mta3.srv.hcvlny.cv.net ([167.206.4.198]) by lingling.panda.com with TCP/SMTP; Sun, 25 Feb 2007 08:04:52 -0800 (PST) X-Received: from amd2 (ool-18b9d8b2.dyn.optonline.net [24.185.216.178]) by mta3.srv.hcvlny.cv.net (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTP id <0JE100F4Y0NX2M20@mta3.srv.hcvlny.cv.net> for TOPS-20@lingling.panda.com; Sun, 25 Feb 2007 11:04:45 -0500 (EST) Date: Sun, 25 Feb 2007 11:04:45 -0500 From: Rick Ace Subject: Re: FIND issues with non-ASCII files To: "TOPS-20@lingling.panda.com" Message-id: Organization: Planet Claire MIME-version: 1.0 Content-type: text/plain; format=flowed; delsp=yes; charset=iso-8859-15 Content-transfer-encoding: 7BIT User-Agent: Opera M2/7.54u1 (Win32, build 3918) ReSent-Date: Sun, 25 Feb 2007 08:33:36 -0800 (PST) ReSent-From: TOPS-20 List Moderator ReSent-To: TOPS-20 Distribution: ; ReSent-Subject: Re: FIND issues with non-ASCII files ReSent-Message-ID: As an alternative to FIND, yall might try my TOPS-20 implementation of grep. Wildcarded filespecs are happily accepted but aside from that not a lot of bells and whistles (feel free to add same of course :-). It did come in mighty handy back when I was hacking MACRO-20. http://www.panix.com/~rick/GREP.MAC rick 25-Feb-2007 08:50:10-PST,2116;000000000000 Return-Path: Received: from pangtzu.panda.com ([206.124.149.117]) by lingling.panda.com with TCP/SMTP; Sun, 25 Feb 2007 08:46:36 -0800 (PST) X-Return-Path: X-Received: from pangtzu.panda.com ([206.124.149.117]) by lingling.panda.com with TCP/SMTP; Sun, 25 Feb 2007 08:44:46 -0800 (PST) Date: Sun, 25 Feb 2007 08:44:41 -0800 (PST) From: Mark Crispin Sender: mrc@pangtzu.panda.com To: Rick Ace cc: "TOPS-20@lingling.panda.com" Subject: Re: FIND issues with non-ASCII files In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=us-ascii ReSent-Date: Sun, 25 Feb 2007 08:46:29 -0800 (PST) ReSent-From: TOPS-20 List Moderator ReSent-To: TOPS-20 Distribution: ; ReSent-Subject: Re: FIND issues with non-ASCII files ReSent-Message-ID: On Sun, 25 Feb 2007, Rick Ace wrote: > As an alternative to FIND, yall might try my TOPS-20 > implementation of grep. It's not really a grep because it doesn't process regular expressions. ;-) One way that you can make it a lot faster is to change the search to a Boyer-Moore type search. Instead of checking the first character of the potential string byte-by-byte, check the *last* character. Furthermore, set up a vector of "value used in search string" indexed by all possible string search values (in the case of 7-bit ASCII, this is 128). So, if the last character of the string is not a character in the string at all, then you know that the string can not possibly start earlier, and you can skip over all those bytes. If it in the string, then do the byte-by-byte check. This algorithm is incredibly simple to implement, and it screams compared to the byte-by-byte search. -- Mark -- http://panda.com/tops-20 TOPS-20: a great improvement over its successors 26-Feb-2007 17:11:23-PST,13861;000000000000 Return-Path: Received: from pangtzu.panda.com ([206.124.149.117]) by lingling.panda.com with TCP/SMTP; Mon, 26 Feb 2007 17:07:16 -0800 (PST) X-Return-Path: X-Received: from mail.math.utah.edu ([155.101.98.135]) by lingling.panda.com with TCP/SMTP; Mon, 26 Feb 2007 13:38:21 -0800 (PST) X-Received: from psi.math.utah.edu (psi.math.utah.edu [155.101.96.19]) by mail.math.utah.edu (8.13.6/8.13.6) with ESMTP id l1QLcE8m018836; Mon, 26 Feb 2007 14:38:14 -0700 (MST) X-Received: from psi.math.utah.edu (localhost [127.0.0.1]) by psi.math.utah.edu (8.13.6/8.13.6) with ESMTP id l1QLcEXH028657; Mon, 26 Feb 2007 14:38:14 -0700 (MST) X-Received: (from beebe@localhost) by psi.math.utah.edu (8.13.6/8.13.6/Submit) id l1QLcEfJ028656; Mon, 26 Feb 2007 14:38:14 -0700 (MST) Date: Mon, 26 Feb 2007 14:38:14 -0700 (MST) From: "Nelson H. F. Beebe" To: "TOPS-20@lingling.panda.com" 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: Re: FIND issues with non-ASCII files Message-ID: X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0 (mail.math.utah.edu [155.101.98.135]); Mon, 26 Feb 2007 14:38:14 -0700 (MST) ReSent-Date: Mon, 26 Feb 2007 17:07:08 -0800 (PST) ReSent-From: TOPS-20 List Moderator ReSent-To: TOPS-20 Distribution: ; ReSent-Subject: Re: FIND issues with non-ASCII files ReSent-Message-ID: On the subject of improving the TOPS-20 string-search utility, find, Mark Crispin suggests looking at the Boyer-Moore search. The reference is @String{j-CACM = "Communications of the ACM"} @Article{Boyer:1977:FSS, author = "Robert S. Boyer and J. Strother Moore", title = "A Fast String Searching Algorithm", journal = j-CACM, volume = "20", number = "10", pages = "762--772", month = oct, year = "1977", CODEN = "CACMA2", ISSN = "0001-0782", bibdate = "Mon Jan 22 06:27:49 MST 2001", bibsource = "Compendex database; ftp://ftp.ira.uka.de/pub/bibliography/Misc/protein.pattern.bib; http://dblp.uni-trier.de/db/journals/cacm/cacm20.html#BoyerM77", note = "See also \cite{Knuth:1977:FPM} and \cite{Sunday:1990:VFS}.", abstract = "An algorithm is presented that searches for the location, ``i,'' of the first occurrence of a character string, ``pat,'' in another string, ``string.'' During the search operation, the characters of pat are matched starting with the last character of pat. The information gained by starting the match at the end of the pattern often allows the algorithm to proceed in large jumps through the text being searched. Thus the algorithm has the unusual property that, in most cases, not all of the first i characters of string are inspected. The number of characters actually inspected (on the average) decreases as a function of the length of pat. For a random English pattern of length 5, the algorithm will typically inspect i/4 characters of string before finding a match at i. Furthermore, the algorithm has been implemented so that (on the average) fewer than i plus patlen machine instructions are executed. These conclusions are supported with empirical evidence and a theoretical analysis of the average behavior of the algorithm. The worst case behavior of the algorithm is linear in i plus patlen, assuming the availability of array space for tables linear in patlen plus the size of the alphabet.", acknowledgement = ack-nhfb, classcodes = "C4240 (Programming and algorithm theory); C6130 (Data handling techniques)", classification = "723; 901", comment = "The Boyer-Moore string matching algorithm is, in the worst case, linear in the length of the text + length of the pattern. The average case behavior is sublinear. Practical efficient implementations of this algorithm exist. By starting the comparisons at the right of the pattern instead of the left of the pattern, large jumps can be made in the text.", corpsource = "Stanford Res. Inst., Stanford, CA, USA", journalabr = "Commun ACM", keywords = "algorithm; Boyer-Moore; character string; computer operating systems; computer programming; fast; information science --- Information Retrieval; list processing; pattern matching; string matching; string searching; text; text editing", oldlabel = "BoyerM77", treatment = "T Theoretical or Mathematical", XMLdata = "ftp://ftp.informatik.uni-trier.de/pub/users/Ley/bib/records.tar.gz#journals/cacm/BoyerM77", } Related work appeared about the same time: @String{j-SIAM-J-COMPUT = "SIAM Journal of Computing"} @Article{Knuth:1977:FPM, author = "Donald E. Knuth and J. H. Morris and V. R. Pratt", title = "Fast pattern matching in strings", journal = j-SIAM-J-COMPUT, volume = "6", number = "2", pages = "323--350", month = jun, year = "1977", CODEN = "SMJCAT", ISSN = "0097-5397", bibdate = "Tue Feb 6 05:29:37 1996", note = "See also \cite{Boyer:1977:FSS} and \cite{Sunday:1990:VFS}.", acknowledgement = ack-nhfb, } There have been variants and improvements since: @TechReport{Karp:1981:ERP, author = "R. M. Karp and M. O. Rabin", title = "Efficient Randomized Pattern-Matching Algorithms", type = "Technical report", number = "TR-31-81", institution = "Harvard University", address = "Cambridge, MA, USA", pages = "??", month = "??", year = "1981", bibdate = "Thu Apr 29 17:39:54 1999", note = "An incremental hash function is described for application to the string search problem. See \cite{Baeza-Yates:1992:NAT}.", acknowledgement = ack-nhfb, } @String{j-INFO-PROC-LETT = "Information Processing Letters"} @Article{Gonnet:1990:AKS, author = "Gaston H. Gonnet and Ricardo A. Baeza-Yates", title = "Analysis of the {Karp-Rabin} string matching algorithm", journal = j-INFO-PROC-LETT, volume = "34", number = "5", pages = "271--274", month = may, year = "1990", CODEN = "IFPLAT", ISSN = "0020-0190", bibdate = "Tue Apr 14 12:06:34 1998", bibsource = "Compendex database", abstract = "We present an average case analysis of the Karp-Rabin string matching algorithm. This algorithm is a probabilistic algorithm that adapts hashing techniques to string searching. We also propose an efficient implementation of this algorithm.", acknowledgement = ack-nhfb, keywords = "Algorithms; Computer Programming; Hashing; Karp-Rabin Algorithm; Probability; String Matching; String Searching", } @String{j-IBM-JRD = "IBM Journal of Research and Development"} @Article{Karp:1987:ERP, author = "Richard M. Karp and Michael O. Rabin", title = "Efficient Randomized Pattern-Matching Algorithms", journal = j-IBM-JRD, volume = "31", number = "2", pages = "249--260", month = mar, year = "1987", CODEN = "IBMJAE", ISSN = "0018-8646", MRclass = "68Q20", MRnumber = "89g:68021", bibdate = "Mon Feb 12 09:58:53 MST 2001", bibsource = "Compendex database", abstract = "We present randomized algorithms to solve the following string-matching problem and some of its generalizations: Given a string X of length n (the pattern) and a string Y (the text), find the first occurrence of X as a consecutive block within Y. The algorithms represent strings of length n by much shorter strings called fingerprints, and achieve their efficiency by manipulating fingerprints instead of longer strings. The algorithms require a constant number of storage locations, and essentially run in real time. They are conceptually simple and easy to implement. The method readily generalizes to higher-dimensional pattern-matching problems.", acknowledgement = ack-nhfb, ZMnumber = "653.68054", } @Article{Sunday:1990:VFS, author = "Daniel M. Sunday", title = "A Very Fast Substring Search Algorithm", journal = j-CACM, volume = "33", number = "8", pages = "132--142", month = aug, year = "1990", CODEN = "CACMA2", ISSN = "0001-0782", bibdate = "Thu May 30 09:41:10 MDT 1996", bibsource = "http://www.acm.org/pubs/toc/", note = "See also \cite{Boyer:1977:FSS,Knuth:1977:FPM,Baeza-Yates:1992:NAT}.", URL = "http://www.acm.org/pubs/toc/Abstracts/0001-0782/79184.html", abstract = "This article describes a substring search algorithm that is faster than the Boyer-Moore algorithm. This algorithm does not depend on scanning the pattern string in any particular order. Three variations of the algorithm are given that use three different pattern scan orders. These include: (1) a ``Quick Search'' algorithm; (2) a ``Maximal Shift'' and (3) an ``Optimal Mismatch'' algorithm.", acknowledgement = ack-nhfb, keywords = "algorithms; theory", subject = "{\bf F.2.2}: Theory of Computation, ANALYSIS OF ALGORITHMS AND PROBLEM COMPLEXITY, Nonnumerical Algorithms and Problems, Pattern matching.", } @Article{Baeza-Yates:1992:NVF, author = "Ricardo Baeza-Yates and Fred T. Krogh and Bernard Ziegler and Peter R. Sibbald and Daniel M. Sunday", title = "Technical Correspondence: Notes on a Very Fast Substring Search Algorithm", journal = j-CACM, volume = "35", number = "4", pages = "132--137", month = apr, year = "1992", CODEN = "CACMA2", ISSN = "0001-0782", bibdate = "Tue Jan 28 14:52:45 1997", acknowledgement = ack-nhfb, } You can find C code implementations of these search algorithms in Sedgewick's excellent books: @String{pub-AW = "Ad{\-d}i{\-s}on-Wes{\-l}ey"} @String{pub-AW:adr = "Reading, MA, USA"} @Book{Sedgewick:AC90, author = "Robert Sedgewick", title = "Algorithms in {C}", publisher = pub-AW, address = pub-AW:adr, pages = "xii + 657", year = "1990", ISBN = "0-201-51425-7", ISBN-13 = "978-0-201-51425-4", LCCN = "QA76.73.C15 S43 1990", bibdate = "Wed Dec 15 10:41:38 1993", } @Book{Sedgewick:1998:ACP, author = "Robert Sedgewick", title = "Algorithms in {C}: Parts 1--4: Fundamentals, data structures, sorting, searching", publisher = pub-AW, address = pub-AW:adr, pages = "xvii + 702", year = "1998", ISBN = "0-201-31452-5", ISBN-13 = "978-0-201-31452-6", LCCN = "QA76.73.C15 S43 1998", bibdate = "Tue Aug 25 17:20:35 1998", price = "US\$33.50", acknowledgement = ack-nhfb, } Pascal, Modula-3, and C++ editions are available as well: see http://www.math.utah.edu/pub/tex/bib/master.html The most useful thing, I believe, would be to backport the latest GNU grep and find utilities to TOPS-20: ftp://ftp.gnu.org/gnu/grep/ ftp://alpha.gnu.org/gnu/findutils/ Most of the overhead in simple string searches is I/O, so if fgetc() can be made fast by page-mapping (perhaps it already is?), then these utilities, and every other Unix utility ported to TOPS-20, can be made fast as well. ------------------------------------------------------------------------------- - 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/ - ------------------------------------------------------------------------------- 19-Mar-2007 10:47:32-PDT,3156;000000000000 Return-Path: Received: from pangtzu.panda.com ([206.124.149.117]) by lingling.panda.com with TCP/SMTP; Mon, 19 Mar 2007 10:42:48 -0700 (PDT) X-Return-Path: X-Received: from mxout3.cac.washington.edu ([140.142.32.166]) by lingling.panda.com with TCP/SMTP; Mon, 19 Mar 2007 10:41:00 -0700 (PDT) X-Received: from smtp.washington.edu (smtp.washington.edu [140.142.33.9] (may be forged)) by mxout3.cac.washington.edu (8.13.7+UW06.06/8.13.7+UW07.03) with ESMTP id l2JHerFn032543 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Mon, 19 Mar 2007 10:40:53 -0700 X-Auth-Received: from pangtzu.panda.com (pangtzu.panda.com [206.124.149.117]) (authenticated authid=mrc) by smtp.washington.edu (8.13.7+UW06.06/8.13.7+UW07.03) with ESMTP id l2JHelu7004209 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Mon, 19 Mar 2007 10:40:52 -0700 Date: Mon, 19 Mar 2007 10:40:46 -0700 (PDT) From: Mark Crispin Sender: mrc@pangtzu.panda.com To: TOPS-20 Hackers and Yackers Subject: Re: PDP-10 floating point with un-normalized operands (fwd) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=us-ascii X-PMX-Version: 5.3.0.289146, Antispam-Engine: 2.5.0.283055, Antispam-Data: 2007.3.19.102433 X-Uwash-Spam: Gauge=IIIIIII, Probability=7%, Report='__CP_URI_IN_BODY 0, __CT 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0' ReSent-Date: Mon, 19 Mar 2007 10:42:39 -0700 (PDT) ReSent-From: TOPS-20 List Moderator ReSent-To: TOPS-20 Distribution: ; ReSent-Subject: Re: PDP-10 floating point with un-normalized operands (fwd) ReSent-Message-ID: You folks may want to weigh in on this topic. [If you respond to him, or post to the alt.sys.pdp10 newsgroup, please make sure that the TOPS-20 mailing list email address doesn't appear. As matters stand, I'm already having to filter phishing scams aimed at the list. I'd rather not increase my workload...thanks!] -- 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. ---------- Forwarded message ---------- Date: 19 Mar 2007 09:13:46 -0700 From: Dave Conroy Newsgroups: alt.sys.pdp10 Subject: Re: PDP-10 floating point with un-normalized operands I have been thinking about this a little more, and I want to revise my question. Would software (discounting disgnostics) really care if floating point divide, when presented with non-normalized operands that passed the a-2*b>=0 check from the reference manual and therefore should get a no- divide, got the correct result instead (the only time it would no- divide would be if the divisor is 0.0, which is the normal behavior if all non-0.0 operands are in normalized form). dgc 19-Mar-2007 11:32:00-PDT,2313;000000000000 Return-Path: Received: from pangtzu.panda.com ([206.124.149.117]) by lingling.panda.com with TCP/SMTP; Mon, 19 Mar 2007 11:27:55 -0700 (PDT) X-Return-Path: X-Received: from outgoing02.lava.net ([64.65.64.125]) by lingling.panda.com with TCP/SMTP; Mon, 19 Mar 2007 11:00:57 -0700 (PDT) X-Received: from [192.168.0.102] (kahealani.net [64.65.108.250]) by outgoing02.lava.net (Postfix) with ESMTP id C00C4B9810; Mon, 19 Mar 2007 08:00:50 -1000 (HST) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <6ABC6789-DEF6-4734-87B8-71599462B839@kahealani.com> Cc: TOPS-20 Hackers and Yackers Content-Transfer-Encoding: 7bit From: Angela Kahealani Subject: Encryption Date: Mon, 19 Mar 2007 08:00:49 -1000 To: Mark Crispin X-Mailer: Apple Mail (2.752.2) ReSent-Date: Mon, 19 Mar 2007 11:27:47 -0700 (PDT) ReSent-From: TOPS-20 List Moderator ReSent-To: TOPS-20 Distribution: ; ReSent-Subject: Encryption ReSent-Message-ID: Aloha TOPS-20 Hackers Since most of our modern computing world was developed on PDP-10s in the first place, I figure this would be the first place to introduce in the computing world some information which has only recently come to my attention, though I understand that it has already been broached into some portions of the computing and communications communities. http://www.calculateprimes.com/ http://www.jmccanneyscience.com/ James M. McCanney is a name you won't forget, because this guy has figured out how to teach 3rd graders to calculate primes. You may remember that most of our "modern" (now obsolete) encryption technology is based on prime numbers. "setec astronomy" anyone? (Ref: "Sneakers") Aloha, Angela Kahealani -- All Information and Transactions are Non Negotiable and Private Between the Parties. All Rights Reserve and CopyRight 2007, Angela Kahealani http://www.kahealani.com/ 29-Mar-2007 22:21:58-PDT,6852;000000000000 Return-Path: Received: from pangtzu.panda.com ([206.124.149.117]) by lingling.panda.com with TCP/SMTP; Thu, 29 Mar 2007 22:17:19 -0700 (PDT) X-Return-Path: X-Received: from mta2.srv.hcvlny.cv.net ([167.206.4.197]) by lingling.panda.com with TCP/SMTP; Thu, 29 Mar 2007 20:21:17 -0700 (PDT) X-Received: from optonline.net (mstr3a.srv.hcvlny.cv.net [10.240.4.140]) by mta2.srv.hcvlny.cv.net (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTP id <0JFP000D65AUIBJ0@mta2.srv.hcvlny.cv.net> for TOPS-20@Lingling.Panda.COM; Thu, 29 Mar 2007 23:20:55 -0400 (EDT) X-Received: from [10.240.3.201] (Forwarded-For: 69.114.1.48, [10.240.3.201]) by mstr3.srv.hcvlny.cv.net (mshttpd); Fri, 30 Mar 2007 03:20:54 +0000 (GMT) Date: Fri, 30 Mar 2007 03:20:54 +0000 (GMT) From: slogin@optonline.net Subject: LAT (Finally!) In-reply-to: To: TOPS-20@Lingling.Panda.COM Message-id: MIME-version: 1.0 X-Mailer: Sun Java(tm) System Messenger Express 6.2-6.01 (built Apr 3 2006) Content-type: text/plain; charset=us-ascii Content-language: en Content-transfer-encoding: 7BIT Content-disposition: inline X-Accept-Language: en Priority: normal References: ReSent-Date: Thu, 29 Mar 2007 22:17:11 -0700 (PDT) ReSent-From: TOPS-20 List Moderator ReSent-To: TOPS-20 Distribution: ; ReSent-Subject: LAT (Finally!) ReSent-Message-ID: I finally got LAT to work! The problem appears to have been, in part, PATHWORKS itself. While taking care of a daylight savings time issue on my host machine (having put MRC's Tops-20 patch in well over a year ago), I mistakenly upgraded every package on the machine. Hint: apt-get upgrade and dist-upgrade are real different ... So I wondered whether the Linux LAT package (llogin) might start working. I had a look at its control file and discovered that I had misconfigured the server to run LAT on both ethernet boards on the machine, even though I had eventually exclusively assigned one of them to Tops-20. So, I fixed all of that and got the following on the host. $ llogin -d TOMMYT Available TOMMYT, PANDA TOPS-20 Monitor 7.1(21737)-5 TTUX Available Linux 2.4.19 That's promising, but llogin now silently fails (as opposed to actively croaking) and I haven't had the inclination to actually have a look. Since I reconfigured everything, I decided to have another look at PATHWORKS, anyway. Well, I installed it and it came right up, viz: !information (ABOUT) job-status Host TOMMYT, Job 18, TTY122 LAT_00045A9B761B(LAT) User SLOGIN, STAR: !systat 18 18* 122 SYSTAT SLOGIN LAT_00045A9B761B(LAT) !OPR OPR>enter (command subset) lcp LCP>show characteristics 21:40:01 [LCP] -- Host Characteristics -- LAT Access State: ON Host Name: TOMMYT Host id: Tops-20 LAT Service Host number: 1 Retransmit Limit: 60 Retransmit Timer: 1000 Multicast Timer: 30 Groups: 0 Current Maximum ------- ------- Allocated circuits 4 32 Active circuits 2 20 Sessions 2 5 Service Name Rating Identification -------------------- ------ ------------------------ TOMMYT 1 TOMMYT, PANDA TOPS-20 Monitor 7.1(21737)-5 LCP>show sessions 21:40:06 [LCP] -- Active LAT Sessions -- Job Line Program Server Name Port Name User --- ---- ------- ---------------- ---------------- -------------------- 14 121 EMACS LAT_00134633A0D6 SLOGIN 18 122 OPR LAT_00045A9B761B SLOGIN LCP>exit Why did it start working? Well, I run two completely redundant backbones in my house, one DSL and the other cable. By redundant, I mean the DSL and cable modems are on different sides of the house on different breakers and everything else is seperate: routers, switches and wiring. Nearly every machine in the house has dual NICs. However, the machine I tried PATHWORKs on happened to be one of the few that I have that DON'T have dual NICs... So here is how I got it to work: first, I don't load DECnet; just LAT (I don't know if this actually makes any difference). Second, before I load anything, I disable the interface that is not on the Tops-20 backbone. When the installation asks for a network interface to bind to, there is only one. After the installation is done, I enable the second interface and everything works. Now, as to performance ... It's nothing to write home about, but I think this might be because of the supplied terminal emulator: PowerTerm. It's not fast on my machine. It has built in Kermit, so I tested that with Tops-20 Kermit and the speed wasn't that good: about 6 Kbps (yup, less than 9600 baud). However, as that Kermit transfer speed might have been indicative of an older Kermit implementation (that doesn't do large packets), I did some other tests. Regular Kermit-95 did over 66 Kbps on the same file. I also created two PowerTerm terminal sessions: one via LAT and one via TCP/IP and typed out a large file. Neither listing was particularly fast and the CPU usage on my laptop (where I was running PowerTerm) went to 100%. PuTTY (my normal TELNET client) absolutely blew both out of the water and didn't pin the CPU. Unfortunately, I don't have any other LAT capable terminal emulator to compare with. Kermit-95 claims to have LAT support, but it hasn't worked for me, thus far. It would certainly be nice to try to have PuTTY have a LAT mode, but I don't know whether PATHWORKS has a published LAT programming interface (I don't believe that it does). I stated earlier that llogin silently fails. That isn't exactly true. If I do a 'llogin tommyt', llogin silently exits and Tops-20 gives a LATNSC BUFINF: 29-Mar-2007 22:24:48 ***BUGINF LATNSC*** LAT Host node stopped circuit, Data: 2, 6511703,0 I haven't investigated LATNSC further in part because I don't have any real diagnostic tools (other than Ethereal). Galaxy provides some information (see above), but I haven't found any other tool that handles LAT. The SYSDPY that I have doesn't know know about LAT. Now, what good is LAT? Well, it's helped me catch some bugs in my FTP server. The server assumes a TCP/IP (I.E., NVT) control connection and when I started running it in interactive mode under LAT, I noticed that some code that I had written to handle FTP bounce attacks didn't work. So that was useful. But anyway, fun fun fun. 29-Mar-2007 22:29:22-PDT,1471;000000000000 Return-Path: Received: from pangtzu.panda.com ([206.124.149.117]) by lingling.panda.com with TCP/SMTP; Thu, 29 Mar 2007 22:25:22 -0700 (PDT) X-Return-Path: X-Received: from pangtzu.panda.com ([206.124.149.117]) by lingling.panda.com with TCP/SMTP; Thu, 29 Mar 2007 22:24:48 -0700 (PDT) Date: Thu, 29 Mar 2007 22:24:42 -0700 (PDT) From: Mark Crispin Sender: mrc@pangtzu.panda.com To: slogin@optonline.net cc: TOPS-20@Lingling.Panda.COM Subject: Re: LAT (Finally!) In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=us-ascii; format=flowed ReSent-Date: Thu, 29 Mar 2007 22:25:13 -0700 (PDT) ReSent-From: TOPS-20 List Moderator ReSent-To: TOPS-20 Distribution: ; ReSent-Subject: Re: LAT (Finally!) ReSent-Message-ID: Congratulations on getting LAT working. I'm surprised, after all the bragging about how wonderful that LAT allegedly was, that TCP TELNET does so much better. But then again, I had little to do with DECnet in general, and nothing to do with LAT. -- Mark -- http://panda.com/tops-20 TOPS-20: a great improvement over its successors 30-Mar-2007 10:28:17-PDT,2562;000000000000 Return-Path: Received: from pangtzu.panda.com ([206.124.149.117]) by lingling.panda.com with TCP/SMTP; Fri, 30 Mar 2007 10:23:58 -0700 (PDT) X-Return-Path: X-Received: from smtpout.mac.com ([17.250.248.178]) by lingling.panda.com with TCP/SMTP; Fri, 30 Mar 2007 04:18:29 -0700 (PDT) X-Received: from mac.com (smtpin05-en2 [10.13.10.150]) by smtpout.mac.com (Xserve/smtpout08/MantshX 4.0) with ESMTP id l2UBINZ7016572; Fri, 30 Mar 2007 04:18:23 -0700 (PDT) X-Received: from [192.168.1.52] (c-24-147-40-233.hsd1.nh.comcast.net [24.147.40.233]) (authenticated bits=0) by mac.com (Xserve/smtpin05/MantshX 4.0) with ESMTP id l2UBIJTb026412; Fri, 30 Mar 2007 04:18:21 -0700 (PDT) Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Fri, 30 Mar 2007 07:18:29 -0400 To: slogin@optonline.net, TOPS-20@Lingling.Panda.COM From: John Francini Subject: Re: LAT (Finally!) Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Brightmail-Tracker: AAAAAA== X-Brightmail-scanned: yes ReSent-Date: Fri, 30 Mar 2007 10:23:29 -0700 (PDT) ReSent-From: TOPS-20 List Moderator ReSent-To: TOPS-20 Distribution: ; ReSent-Subject: Re: LAT (Finally!) ReSent-Message-ID: Okay, this is more than a little bit interesting to me, as I'm interested in getting a TOPS-10 box up and running at home. Unfortunately, it would seem that unless I either (a) did some serious Monitor hacking to include one of the third-party TCP stacks, or (b) found some way to get DECnet and LAT running on the "microengine" (i.e., box that KLH runs on), I'd just have a not-terribly-useful software bauble. What I *think* I'm seeing is that you: (a) run KLH on a Linux box (b) are running Linux LAT (and possibly DECnet) (c) found a PATHWORKS kit to put on some other PC (probably running some flavor of Windows). So, for those of us whose 36-bit heritage is blue instead of orange, could you please give me a run down what your configurations are? Thanks, John -- John Francini, francini@mac.com "The journey is more important than the destination -- that's part of life. If you only live for getting to the end, you're almost always disappointed." -- Donald Knuth 30-Mar-2007 10:31:48-PDT,7547;000000000000 Return-Path: Received: from pangtzu.panda.com ([206.124.149.117]) by lingling.panda.com with TCP/SMTP; Fri, 30 Mar 2007 10:24:15 -0700 (PDT) X-Return-Path: X-Received: from mta1.srv.hcvlny.cv.net ([167.206.4.196]) by lingling.panda.com with TCP/SMTP; Fri, 30 Mar 2007 08:43:45 -0700 (PDT) X-Received: from optonline.net (mstr3a.srv.hcvlny.cv.net [10.240.4.140]) by mta1.srv.hcvlny.cv.net (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTP id <0JFQ00MGZ3OMNS10@mta1.srv.hcvlny.cv.net> for TOPS-20@Lingling.Panda.COM; Fri, 30 Mar 2007 11:43:39 -0400 (EDT) X-Received: from [10.240.3.200] (Forwarded-For: 69.114.1.48, [10.240.3.200]) by mstr3.srv.hcvlny.cv.net (mshttpd); Fri, 30 Mar 2007 15:43:34 +0000 (GMT) Date: Fri, 30 Mar 2007 15:43:34 +0000 (GMT) From: slogin@optonline.net Subject: Re: LAT (Finally!) In-reply-to: To: John Francini Cc: TOPS-20@Lingling.Panda.COM Message-id: MIME-version: 1.0 X-Mailer: Sun Java(tm) System Messenger Express 6.2-6.01 (built Apr 3 2006) Content-type: text/plain; charset=us-ascii Content-language: en Content-transfer-encoding: 7BIT Content-disposition: inline X-Accept-Language: en Priority: normal References: ReSent-Date: Fri, 30 Mar 2007 10:24:06 -0700 (PDT) ReSent-From: TOPS-20 List Moderator ReSent-To: TOPS-20 Distribution: ; ReSent-Subject: Re: LAT (Finally!) ReSent-Message-ID: John, Here is what I have for you. Yes, I have a copy of PATHWORKS. As can be seen from my previous posts, I have been nosing around LAT for years. Typically what I've done is look for LAT stuff on eBay. I won a copy of KEA! there a few years ago, but this is a Windows 3.1 only LAT solution which appears to require KEATerm which I don't have. I have Windows 3.1 (somewhere) and a box to run it on (my current OS/2 machine), but I haven't got KEAterm yet or anything else that will talk to KEA! I've never bid on any LAT terminal concentrators as I didn't want to risk having something that wouldn't work with Tops-20. Maybe I will now. I also have a terminal around here (someplace...) I eventually won a copy of PATHWORKS 32. The CD-ROM has an Alpha directory, but I don't know what the target operating system is. It has i386 code for Windows 95, 2000 and XP. I have tested the Windows 2000 code and it works (now). I have a Windows 95 machine (an ancient AST Bravo laptop), but I haven't done any testing with this. I don't know if the Windows XP code works, as my XP machine is dual NIC'ed. I'm going to be building a single NIC XP machine in the near future, so maybe I'll test it, then. The CD-ROM comes with PowerTerm 525, a LAT compatible terminal client, but (as I've written earlier), the performance is slow, perhaps surprisingly, so. It comes with Xcursion, but I haven't looked at it (I use Hummingbird). There is also a doc directory, but I've never looked in there (WHAT?! RTFM??) Yes, I'm running KLH10 under Wallmart Lindows (the world famous $200 DECSYSTEM-20). The base distribution is Debian. I am not running DECnet. MRC has wrestled with DECnet a good deal but hasn't gotten it to work yet, so I've steered away from it. PATHWORKS will let you install a LAT only solution (without DECnet) and this is what I've done. There is an open source LAT solution for Linux called 'latd'. Mine used to work for llogin'ing in to my Linux box from itself, but this is now broken. I haven't had time to look at it. I couldn't tell you anything definitive about either DECnet or LAT under Tops-10. My direct programming experience with Tops-10 ends with a 5.06 series monitor (KA based) in 1980. Indirectly, I had to make sure that my Tops-20 Galaxy SPR's were compatible with Tops-10, but that's about it. I remember that Tops-10 ran its own networking, something called ANF10(?), but I never used it, even in Marlboro. I don't remember what else (if anything) that it talked to. I don't remember Tops-10 having a DECnet solution. Hey Frank, did we ever have any Tops-10 machines on CCnet? Did Stevens? Keng? I don't remember anything about Tops-10 having a LAT solution. BUT!! The Tops-20 LATSRV module has conditionals for Tops-10 under which it is called 'LATSER', so you might actually be able to get something to work out of the box--but I don't know if this was ever productised. You might not have to do so much monitor hacking. ... Or not ... Remember that LAT is different from DECnet. I believe it is possible to build Tops-20 without DECnet and still have LAT (the Panda distribution has some fixes to allow an NI system without DECnet). I don't think that the Toad monitor has DECnet in it any more. At least, when I went to test some old code there that I had written, the DCN: and SRV: devices were not present--they still exist in the PANDA monitor. If you have different NIC's, you can run Tops-20 and Linux just fine. At one point, my Linux LAT solution worked into my Linux box. It's broken now. Somebody (I don't know who/where) claims that latd will work under Mac OSX, but I have yet to try. I don't know if anybody has tested a Tops-20 to Tops-20 DECnet solution, yet. MRC was going to do this at one point, but I don't think he's gotten around to it. At least for now, I don't know anybody who has gotten DECnet to work under Tops-20. I don't think the Tops-20 DECnet is broken. I think it wants to do something funky with the NI (like program the MAC address) and KLH10 doesn't do this. I think if you program the DECnet node to be the same as the low byte (bytes) of your Ethernet adaptor you might get someplace. I've tried this (and so has MRC, I think), but I've never had success. I only got this working a few days ago, so I don't have much more to offer, but do let me know if I can be of more assistance. Regards, --T > ----- Original Message ----- > From: John Francini > Date: Friday, March 30, 2007 7:18 am > Subject: Re: LAT (Finally!) > To: slogin@optonline.net, TOPS-20@Lingling.Panda.COM > > Okay, this is more than a little bit interesting to me, as I'm > interested in getting a TOPS-10 box up and running at home. > Unfortunately, it would seem that unless I either > > (a) did some serious Monitor hacking to include one of the > third-party TCP stacks, or > > (b) found some way to get DECnet and LAT running on the > "microengine" (i.e., box that KLH runs on), I'd just have > a not-terribly-useful software bauble. > > What I *think* I'm seeing is that you: > > (a) run KLH on a Linux box > (b) are running Linux LAT (and possibly DECnet) > (c) found a PATHWORKS kit to put on some other PC (probably > running some flavor of Windows). > > So, for those of us whose 36-bit heritage is blue instead of orange, > could you please give me a run down what your configurations are? > > Thanks, > > John > -- > John Francini, francini@mac.com > > "The journey is more important than the destination -- that's > part of life. If you only live for getting to the end, you're > almost always disappointed." -- Donald Knuth > 30-Mar-2007 10:35:22-PDT,2751;000000000000 Return-Path: Received: from pangtzu.panda.com ([206.124.149.117]) by lingling.panda.com with TCP/SMTP; Fri, 30 Mar 2007 10:25:41 -0700 (PDT) X-Return-Path: X-Received: from sesame.cc.columbia.edu ([128.59.59.56]) by lingling.panda.com with TCP/SMTP; Fri, 30 Mar 2007 07:31:19 -0700 (PDT) X-Received: from sesame.cc.columbia.edu (localhost [127.0.0.1]) by sesame.cc.columbia.edu (8.13.7/8.13.6) with ESMTP id l2UEVCKS008715; Fri, 30 Mar 2007 10:31:12 -0400 (EDT) X-Received: (from fdc@localhost) by sesame.cc.columbia.edu (8.13.7/8.12.8/Submit) id l2UEVCQZ008714; Fri, 30 Mar 2007 10:31:12 -0400 (EDT) Date: Fri, 30 Mar 2007 10:31:12 EDT From: Frank da Cruz To: slogin@optonline.net Cc: TOPS-20 List Moderator , TOPS-20@Lingling.Panda.COM Subject: Re: LAT (Finally!) In-Reply-To: Message-ID: ReSent-Date: Fri, 30 Mar 2007 10:25:33 -0700 (PDT) ReSent-From: TOPS-20 List Moderator ReSent-To: TOPS-20 Distribution: ; ReSent-Subject: Re: LAT (Finally!) ReSent-Message-ID: > It's nothing to write home about, but I think this might be because of > the supplied terminal emulator: PowerTerm. It's not fast on my > machine. It has built in Kermit, so I tested that with Tops-20 Kermit > and the speed wasn't that good: about 6 Kbps (yup, less than 9600 > baud). However, as that Kermit transfer speed might have been > indicative of an older Kermit implementation (that doesn't do large > packets), I did some other tests. Regular Kermit-95 did over 66 Kbps > on the same file. > The general rule is, the more hyperbolic the name of the software, the crummier it is, and vice versa :-) > I also created two PowerTerm terminal sessions: one via LAT and one > via TCP/IP and typed out a large file. Neither listing was > particularly fast and the CPU usage on my laptop (where I was running > PowerTerm) went to 100%. PuTTY (my normal TELNET client) absolutely > blew both out of the water and didn't pin the CPU. > > Unfortunately, I don't have any other LAT capable terminal emulator to > compare with. Kermit-95 claims to have LAT support, but it hasn't > worked for me, thus far. > You need to have PATHWORKS, SuperLAT, or TES32 installed, most or all of which are long defunct. The instructions are in the K95 manual (Help -> Kermit 95 Manual -> Index to Reference Materials -> Digital Equipment Corp Networking Methods). I've never had access to this stuff myself, but as far as I know it works as described. - Frank 30-Mar-2007 10:39:17-PDT,6148;000000000000 Return-Path: Received: from pangtzu.panda.com ([206.124.149.117]) by lingling.panda.com with TCP/SMTP; Fri, 30 Mar 2007 10:26:00 -0700 (PDT) X-Return-Path: X-Received: from mta4.srv.hcvlny.cv.net ([167.206.4.199]) by lingling.panda.com with TCP/SMTP; Fri, 30 Mar 2007 07:48:06 -0700 (PDT) X-Received: from optonline.net (mstr3a.srv.hcvlny.cv.net [10.240.4.140]) by mta4.srv.hcvlny.cv.net (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTP id <0JFQ0071P13P8BS0@mta4.srv.hcvlny.cv.net>; Fri, 30 Mar 2007 10:48:00 -0400 (EDT) X-Received: from [10.240.3.200] (Forwarded-For: 69.114.1.48, [10.240.3.200]) by mstr3.srv.hcvlny.cv.net (mshttpd); Fri, 30 Mar 2007 14:47:49 +0000 (GMT) Date: Fri, 30 Mar 2007 14:47:49 +0000 (GMT) From: slogin@optonline.net Subject: Re: LAT (Finally!) In-reply-to: To: Mark Crispin Cc: TOPS-20@Lingling.Panda.COM Message-id: MIME-version: 1.0 X-Mailer: Sun Java(tm) System Messenger Express 6.2-6.01 (built Apr 3 2006) Content-type: text/plain; charset=us-ascii Content-language: en Content-transfer-encoding: 7BIT Content-disposition: inline X-Accept-Language: en Priority: normal References: ReSent-Date: Fri, 30 Mar 2007 10:25:50 -0700 (PDT) ReSent-From: TOPS-20 List Moderator ReSent-To: TOPS-20 Distribution: ; ReSent-Subject: Re: LAT (Finally!) ReSent-Message-ID: I don't have enough data yet to say anything definitive about LAT performance itself. Without having a different LAT terminal client or an updated PowerTerm, I'm not sure how I could. What I can state--having observed it and timed it--is that its end-to-end performance via PowerTerm is quite visibly slower than PuTTY. But the only LAT client I have is PowerTerm and its TCP/IP TELNET performance is about on par with its LAT performance: surprisingly poor. I have a Mac OSX laptop that I may be able to install latd/latcp/ llogin on, which would give me a different client to test against. But even then, it would then be a Linux llogin versus a Linux telnet; two completely different beasts. So it might be that PuTTY wins big. That's my current inclination given that its performance also a good deal faster than the Kermit-95 client. Kermit-95 has connection keywords for DECnet LAT and superlat, but thus far, none of these have worked for me. Maybe that could get looked at (ohhh Frank??) But yes, what I'm seeing could also mean that the 20's TCP/IP stack blows the LAT service out of the water. My inclination is to believe this since the TCP/IP source had a great deal of different people working on it. On the other hand, it's quite clear that DEC did put some resources into LAT and I don't think these can be discounted. DEC made a point of saying how very efficient LAT was, but we never had any mechanism to test this. We couldn't instrument the code paths (see below), but suspected that this claim couldn't be true. It seemed that the NI potentially had to service a huge number of interrupts with Tops-20 cracking the packets and doing all the processing. That didn't happen with DH11's--the front end could handle all of that hackery, essentially delivering the finished goods to the 20 via BIGBUF. If I recollect correctly, at Columbia we thought LAT itself was kind of neat, but we had a number of reservations about it, the very first being that it was proprietary and essentially unpublished. Even then, we had a diverse number of systems and we needed solutions that would allow us to connect to everything from everywhere. We had a PACX terminal concentrator that almost did this and would have if we could have gotten some civilised performance out of our COMTENs. We also had IBMSPL (which was the bane of my existence) to talk nicely with our IBM systems. LAT was a step in the complete opposite direction. It only talked to DEC systems and, at least at the computer center, we were quite reluctant to be put into the position where we were locked into a vendor specific solution again. DEC managed to sell us an 8650 (eventually upgraded to 8700), but we never ran VMS on it. I don't know if Ultrix had LAT, but I'm pretty sure it had DECnet which we did use to talk to other VMS machine, but mostly other 20's. At the time, we couldn't get source to LAT which meant that we couldn't fix it. By 'fixing' it, I don't mean performance: I mean crashing. The new code had new bugs that only seemed to come out when you really stressed the machine which, given our 10,000 user population and resulting system loads, was trivial to do. Telephones would glow white hot when our systems crashed and it was maddening not to be able to put our (very talented) systems staff on the problem. Because we were a source site, we had been able to do this for a long time (as witness to our many posts on Tops-20-Wizards). LAT was also non-routable and it was obvious, even then, that some form of non-level two solution would have to be implemented given the size and topology of our campus. Once we had NI based Internet, we would have never touched any of that stuff unless we had no other alternative. We didn't. > ----- Original Message ----- > From: Mark Crispin > Date: Friday, March 30, 2007 1:35 am > Subject: Re: LAT (Finally!) > To: slogin@optonline.net > Cc: TOPS-20@Lingling.Panda.COM > > Congratulations on getting LAT working. I'm surprised, after all > the bragging about how wonderful that LAT allegedly was, that TCP > TELNET does so much better. > > But then again, I had little to do with DECnet in general, and > nothing to do with LAT. > > -- Mark -- > > http://panda.com/tops-20 > TOPS-20: a great improvement over its successors 30-Mar-2007 20:36:28-PDT,3054;000000000000 Return-Path: Received: from pangtzu.panda.com ([206.124.149.117]) by lingling.panda.com with TCP/SMTP; Fri, 30 Mar 2007 20:32:12 -0700 (PDT) X-Return-Path: X-Received: from mail3.panix.com ([166.84.1.74]) by lingling.panda.com with TCP/SMTP; Fri, 30 Mar 2007 11:20:46 -0700 (PDT) X-Received: from panix5.panix.com (panix5.panix.com [166.84.1.5]) by mail3.panix.com (Postfix) with ESMTP id C706E13A886 for ; Fri, 30 Mar 2007 14:20:35 -0400 (EDT) X-Received: (from alderson@localhost) by panix5.panix.com (8.11.6p3/8.8.8/PanixN1.1) id l2UIKZx03518; Fri, 30 Mar 2007 14:20:35 -0400 (EDT) Date: Fri, 30 Mar 2007 14:20:35 -0400 (EDT) Message-Id: <200703301820.l2UIKZx03518@panix5.panix.com> From: Rich Alderson To: TOPS-20@Lingling.Panda.COM In-reply-to: (slogin@optonline.net) Subject: Re: LAT (Finally!) References: ReSent-Date: Fri, 30 Mar 2007 20:32:03 -0700 (PDT) ReSent-From: TOPS-20 List Moderator ReSent-To: TOPS-20 Distribution: ; ReSent-Subject: Re: LAT (Finally!) ReSent-Message-ID: On 30 Mar 2007, Tom DeBellis wrote to John Francini and the list, inter alia, > I remember that Tops-10 ran its own networking, something called ANF10(?), > but I never used it, even in Marlboro. I don't remember what else (if > anything) that it talked to. I don't remember Tops-10 having a DECnet > solution. Hey Frank, did we ever have any Tops-10 machines on CCnet? Did > Stevens? Keng? Stevens, as it happens, was always and only a Tops-10 shop until they moved to VMS. Leslie and Betsy wouldn't have had it any other way. There was indeed an end-node version of DECnet for Tops-10, which I've been urged from time to time to put on the PDPplanet 2065; management fiat prevents. (Barb Huizenga spits on the floor when DECnet is mentioned, and champions ANF-10 as the better solution that was lost. But that's to be expected.) > Remember that LAT is different from DECnet. I believe it is possible to > build Tops-20 without DECnet and still have LAT (the Panda distribution has > some fixes to allow an NI system without DECnet). I don't think that the > Toad monitor has DECnet in it any more. At least, when I went to test some > old code there that I had written, the DCN: and SRV: devices were not > present--they still exist in the PANDA monitor. The XKL monitor for the Toad-1 never had DECnet in it. Consider who the players are, and that will make sense. We considered putting DECnet into the XKL port of Tops-10 for a customer, but when they cancelled the order we cancelled the product. Rich 30-Mar-2007 20:40:06-PDT,4214;000000000000 Return-Path: Received: from pangtzu.panda.com ([206.124.149.117]) by lingling.panda.com with TCP/SMTP; Fri, 30 Mar 2007 20:33:13 -0700 (PDT) X-Return-Path: X-Received: from sj-iport-3.cisco.com ([171.71.176.72]) by lingling.panda.com with TCP/SMTP; Fri, 30 Mar 2007 18:19:12 -0700 (PDT) X-Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-3.cisco.com with ESMTP; 30 Mar 2007 18:19:07 -0700 X-Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l2V1J6qw015954; Fri, 30 Mar 2007 18:19:06 -0700 X-Received: from cisco.com (pita.cisco.com [171.71.177.199]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l2V1J5MF019591; Sat, 31 Mar 2007 01:19:05 GMT X-Received: (from billw@localhost) by cisco.com (8.8.8-Cisco List Logging/8.8.8) id SAA20376; Fri, 30 Mar 2007 18:18:58 -0700 (PDT) Sender: Bill Westfield Date: Fri, 30 Mar 2007 18:18:58 PDT From: William "Chops" Westfield To: slogin@optonline.net Cc: TOPS-20 List Moderator , Mark Crispin , TOPS-20@Lingling.Panda.COM Subject: Re: LAT (Finally!) In-Reply-To: Your message of Fri, 30 Mar 2007 14:47:49 +0000 (GMT) Message-ID: DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1838; t=1175303946; x=1176167946; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=billw@cisco.com; z=From:=20William=20=22Chops=22=20Westfield=20 |Subject:=20Re=3A=20LAT=20(Finally!) |Sender:=20Bill=20Westfield=20; bh=GB0uFxvO/+VNSAzBGYMxo0Puh6wI99A/7rfdf/atZcg=; b=WEU/eBWd06rxidi9qUkhs66vT8sN/lJt99qQsuvJu5pxXEli5gNvBmrUEdgHbm1uOy1gri+w YmPG8y8lUQ2pojYuDv5So6PPs7NKwhXuhqGDAhBZtP94QhOP1X1rjDXuq8QTguaAVh4r7mVCjJ UXK3hBuLNzECazK6gkD01IZ2o=; Authentication-Results: sj-dkim-1; header.From=billw@cisco.com; dkim=pass (s ig from cisco.com/sjdkim1004 verified; ); ReSent-Date: Fri, 30 Mar 2007 20:32:20 -0700 (PDT) ReSent-From: TOPS-20 List Moderator ReSent-To: TOPS-20 Distribution: ; ReSent-Subject: Re: LAT (Finally!) ReSent-Message-ID: DEC made a point of saying how very efficient LAT was, but we never had any mechanism to test this. We couldn't instrument the code paths (see below), but suspected that this claim couldn't be true. I did cisco's LAT terminal server support (based on code from a company named Meridian was was first selling a homegrown implementation and then later became DEC's licensing agent for DEC. We also licensed the LAT spec from DEC directly to start with (and made something of a big marketing stink about being the only terminal server vendor to have actually licensed code. Sigh.)) The "efficiency" claimed for LAT was probably mostly due to the fact that lat would multiplex a terminal-server's worth of lines' data into single LAT packets. The termial-server to host link would send ONE packet each 80 milliseconds (perhaps configurable, it's been a while) containing all the data collected from all the lines on the TS for that host. Likewise, packets from the host would contain data for multiple async ports (although these were not restricted to timeslots.) The idea was to vastly decrease the interrupt load on the host. With 16 users doing "repeat forward arrow" (3 characters repeated three times a second or so), the host would get about 10 packet interrupts per second instead of the 144 async interrupt per second from a dumb serial port (or a stupid TCP/IP implementation.) Of course, this also meant a latency of up to 80ms on data to the host, and potentially a limit on the data rate to the host, so it looked a lot like something aimed at users on 9600bps TERMINALS. It's not surprising that file transfers using a kermit-like protocol are slow, and it's not surprising that overall throughput is low compared with todays expectations of 115200bps or faster. BillW 30-Mar-2007 20:43:48-PDT,4570;000000000000 Return-Path: Received: from pangtzu.panda.com ([206.124.149.117]) by lingling.panda.com with TCP/SMTP; Fri, 30 Mar 2007 20:33:34 -0700 (PDT) X-Return-Path: X-Received: from mta3.srv.hcvlny.cv.net ([167.206.4.198]) by lingling.panda.com with TCP/SMTP; Fri, 30 Mar 2007 19:33:19 -0700 (PDT) X-Received: from optonline.net (mstr3a.srv.hcvlny.cv.net [10.240.4.140]) by mta3.srv.hcvlny.cv.net (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTP id <0JFQ00EDFXR3QNM0@mta3.srv.hcvlny.cv.net> for TOPS-20@Lingling.Panda.COM; Fri, 30 Mar 2007 22:33:05 -0400 (EDT) X-Received: from [10.240.3.207] (Forwarded-For: 69.114.1.48, [10.240.3.207]) by mstr3.srv.hcvlny.cv.net (mshttpd); Sat, 31 Mar 2007 02:33:03 +0000 (GMT) Date: Sat, 31 Mar 2007 02:33:03 +0000 (GMT) From: slogin@optonline.net Subject: Re: LAT (Finally!) In-reply-to: To: Frank da Cruz Cc: TOPS-20@Lingling.Panda.COM Message-id: MIME-version: 1.0 X-Mailer: Sun Java(tm) System Messenger Express 6.2-6.01 (built Apr 3 2006) Content-type: text/plain; charset=us-ascii Content-language: en Content-transfer-encoding: 7BIT Content-disposition: inline X-Accept-Language: en Priority: normal References: ReSent-Date: Fri, 30 Mar 2007 20:33:24 -0700 (PDT) ReSent-From: TOPS-20 List Moderator ReSent-To: TOPS-20 Distribution: ; ReSent-Subject: Re: LAT (Finally!) ReSent-Message-ID: Frank, Thanks for the tip. You know, one of these days I've really got to start reading documentation instead of just jumping in ... But, then again ... Yes, Kermit 95 still works with PATHWORKS. I had been trying to connect with SUPERLAT, but that didn't work. Connecting with DECnet didn't work, either. You have to do: 1) SET NETWORK TYPE PATHWORKS LAT ; Choose PATHWORKS networking 2) SET HOST TOMMYT ; Make a connection to node TOMMYT 3) CONNECT ; Enter the terminal window The performance of Kermit is noticably faster than PowerTerm (so go give the appropriate hacker a pat on the head for me). Here are some statistics for LAT and TCP/IP Kermit 95 (2.1.3). I transfered the same file (The SWSKIT Handbook, HANDBOOK.MEM) both up and down from the 20. For a download from the 20 using LAT, Kermit selected large packet sizes (4000 bytes) and delivered 2,947 CPS, doing a 303,696 byte file in 1:43. Doing tha same download via TCP/IP got me over three times the performance: 9,167 CPS (did the file in 33 seconds). Same packet size. Uploads were a difference story. For some reason that I've never been able to track down, my system has never been able to do a good TCP/IP upload. I've even hung PuTTY when trying to paste data into a terminal window. It's the same thing with FTP: downloads are zippy fast, but when I try to write a file that is larger than about 1K, the fork hangs. This doesn't happen when I try to upload (using the extended mode FTP server which can run in interactive mode) to Twenex.ORG or a Toad, so I've always assumed it's something in my machine, but I've never been able to track it down. Anyway, uploading the same file via TCP/IP negotiated an 80 byte packet size and took 18:41 or ran at 270 CPS, less than one tenth the download speed. Using LAT was faster: it negotiated a 72 byte packet size and took 5:22 or ran at 943 CPS. It got 26 errors (which I thought was surprising). In summary, I think for downloads, I am closer to comparing Apples to Apples and am seeing a much faster transfer rate with TCP/IP (congratulations, MRC). I have yet to figure out my issues with TCP/IP upload, so I don't think that LAT being faster in that case is definitive. LAT upload is about half the speed of a download which is faster than I would have expected given the number of cautions about using LAT to do uploads to a VMS host (or maybe I should have expected Tops-20 to be better, anyway). Finally, a quick question: I noticed that, when receiving a file from the 20, Kermit-95 can not give an estimated time remaining figure. That's because Tops-20 Kermit doesn't do the "A" attribute, right? It didn't look like it did. Well? How about it? :-) --T 30-Mar-2007 21:18:13-PDT,2288;000000000000 Return-Path: Received: from pangtzu.panda.com ([206.124.149.117]) by lingling.panda.com with TCP/SMTP; Fri, 30 Mar 2007 21:14:28 -0700 (PDT) X-Return-Path: X-Received: from pangtzu.panda.com ([206.124.149.117]) by lingling.panda.com with TCP/SMTP; Fri, 30 Mar 2007 21:05:13 -0700 (PDT) Date: Fri, 30 Mar 2007 21:05:07 -0700 (PDT) From: Mark Crispin Sender: mrc@pangtzu.panda.com To: Rich Alderson cc: TOPS-20@Lingling.Panda.COM Subject: Re: LAT (Finally!) In-Reply-To: <200703301820.l2UIKZx03518@panix5.panix.com> Message-ID: References: <200703301820.l2UIKZx03518@panix5.panix.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=us-ascii; format=flowed ReSent-Date: Fri, 30 Mar 2007 21:14:19 -0700 (PDT) ReSent-From: TOPS-20 List Moderator ReSent-To: TOPS-20 Distribution: ; ReSent-Subject: Re: LAT (Finally!) ReSent-Message-ID: On Fri, 30 Mar 2007, Rich Alderson wrote: > Stevens, as it happens, was always and only a Tops-10 shop until they > moved to VMS. Leslie and Betsy wouldn't have had it any other way. Who was Betsy? She must have been after my time. My knowledge of computing at Stevens mostly ends after 1977. When I left they still had a KA with all of 128KB. They did eventually get a KL. In the early 80s, I saw in the alumni rag that they joined the personal computer revolution by requiring that every student buy an Atari 800, then the next year it was one of the Digital PCs (I forget if it was the CP/M Rainbow or the PDP-11 based "Professional") thus missing the mainstream twice. I think that they got their VAX by then. A perfect trifecta of missing the mainstream. By 1988, I succeeded in becoming a "lost alumnus" ;-) so I don't know when they finally gave up on TOPS-10 and VMS. -- Mark -- http://panda.com/tops-20 TOPS-20: a great improvement over its successors 30-Mar-2007 22:51:28-PDT,5415;000000000000 Return-Path: Received: from pangtzu.panda.com ([206.124.149.117]) by lingling.panda.com with TCP/SMTP; Fri, 30 Mar 2007 22:46:49 -0700 (PDT) X-Return-Path: X-Received: from fall-curlleaf.atl.sa.earthlink.net ([207.69.195.105]) by lingling.panda.com with TCP/SMTP; Fri, 30 Mar 2007 22:34:42 -0700 (PDT) X-Received: from pop-tawny.atl.sa.earthlink.net ([207.69.195.67]) by fall-curlleaf.atl.sa.earthlink.net with esmtp (Exim 4.34) id 1HXWEW-0007Y9-2l for TOPS-20@lingling.panda.com; Sat, 31 Mar 2007 01:34:36 -0400 X-Received: from cpe-24-221-177-162.ca.sprintbbd.net ([24.221.177.162] helo=[204.238.239.104]) by pop-tawny.atl.sa.earthlink.net with esmtp (Exim 3.36 #1) id 1HXWAs-00015Y-00 for TOPS-20@Lingling.Panda.COM; Sat, 31 Mar 2007 01:30:51 -0400 Mime-Version: 1.0 (Apple Message framework v624) In-Reply-To: References: Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <46eb5ce5d6e44776e7ebfb4474b5b7e5@reststop.com> Content-Transfer-Encoding: 7bit X-Image-Url: http://www.goldenstategiftbaskets.com/minibasket.jpg From: Carl Baltrunas Subject: Re: LAT (Finally!) Date: Fri, 30 Mar 2007 22:30:48 -0700 To: TOPS-20 Hackers and Yackers X-Mailer: Apple Mail (2.624) ReSent-Date: Fri, 30 Mar 2007 22:46:40 -0700 (PDT) ReSent-From: TOPS-20 List Moderator ReSent-To: TOPS-20 Distribution: ; ReSent-Subject: Re: LAT (Finally!) ReSent-Message-ID: On Mar 30, 2007, at 8:43 AM, slogin@optonline.net wrote: > I couldn't tell you anything definitive about either DECnet or LAT > under Tops-10. My direct programming experience with Tops-10 ends > with a 5.06 series monitor (KA based) in 1980. Indirectly, I had to > make sure that my Tops-20 Galaxy SPR's were compatible with Tops-10, > but that's about it. Yikes! I thought that only Stanford and Tymshare were still running KA-10s in 1980. (Of course the Tymshare KA-10s had a BBN pager and an IMP interface, and were running Tenex, up on the ARPA-NET as Office-nn). Ok, maybe MIT was also, but ITS isn't part of this discussion. > > I remember that Tops-10 ran its own networking, something called > ANF10(?), but I never used it, even in Marlboro. I don't remember > what else (if anything) that it talked to. I don't remember Tops-10 > having a DECnet solution. Hey Frank, did we ever have any Tops-10 > machines on CCnet? Did Stevens? Keng? ANF-10 worked well between TOPS-10 hosts, and I think worked just on the DC76. When they upgraded to the DN87 as the front-end concentrator, they added DECnet capability. I worked on a PDP-11/34 in the business office at Gallaudet College that used DECnet to make a connection to the KL-10 we had in the computer center. At that time, I believe we were running TOPS-10 v 6.03a, but possibly something as early as 6.01 (1977-1980). At the same time, we had a couple of ANF-10 connections to Catholic University and to NIH. When I left Gallaudet in 1980, 7.01 tapes were sitting on my desk, but we hadn't upgraded the systems to use it yet. At one time, I was able to dial out from Gallaudet with a Vadic 1200 baud modem into a similar modem at Catholic University and was even able to maintain a connection telling both modes to sync at 1800 baud, but not any higher. We then had an operational ANF-10 connection which we could connect to any host in the network from any terminal. Really nice. I don't recall if ANF-10 worked on the DC10, but am sure it worked on the DC76. Likewise, I do not know if DECnet worked on the DC76, but it most certainly did on the DN87. > I don't remember anything about Tops-10 having a LAT solution. BUT!! > The Tops-20 LATSRV module has conditionals for Tops-10 under which it > is called 'LATSER', so you might actually be able to get something to > work out of the box--but I don't know if this was ever productised. > You might not have to do so much monitor hacking. ... Or not ... > We never used LAT at CUA or at Gallaudet while I was there. At Tymshare, we looked at LAT as one possible way to interconnect some LSI-11s as special Tymnet node interfaces, but I don't think it ever went out of the lab. Instead one of the x.25 protocol experts came up with a way to make a Tymnet connection directly off of the LSI-11, and used the -11 as a regular terminal concentrator/node which could connect at 9600 baud directly to a KS-10 or a Foonly F3 running Tymcom-X/XX, and quite possibly talk to Tenex/Augment(a.k.a. August)/Tops-20 on a KS-10 or Foonly F4. Since I worked on Tymcom-X/XX I know how the interface worked, but seldom had any need to work on the Tops-20 side, except to access the ARPA-NET every so often so I could login to accounts at MIT to test how specific instructions worked on the KA, KI, KL, KS, and F3 so we could tell them apart by executing a set of instructions. (We didn't have the appropriate GETTAB tables in our OS, so we determined the processor by testing.) Hope that little ANF-10 history helps. -Carl 31-Mar-2007 00:49:44-PDT,1957;000000000000 Return-Path: Received: from pangtzu.panda.com ([206.124.149.117]) by lingling.panda.com with TCP/SMTP; Sat, 31 Mar 2007 00:45:42 -0700 (PDT) X-Return-Path: X-Received: from pangtzu.panda.com ([206.124.149.117]) by lingling.panda.com with TCP/SMTP; Sat, 31 Mar 2007 00:45:13 -0700 (PDT) Date: Sat, 31 Mar 2007 00:45:08 -0700 (PDT) From: Mark Crispin Sender: mrc@pangtzu.panda.com To: Carl Baltrunas cc: TOPS-20 Hackers and Yackers Subject: Re: LAT (Finally!) In-Reply-To: <46eb5ce5d6e44776e7ebfb4474b5b7e5@reststop.com> Message-ID: References: <46eb5ce5d6e44776e7ebfb4474b5b7e5@reststop.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=us-ascii ReSent-Date: Sat, 31 Mar 2007 00:45:33 -0700 (PDT) ReSent-From: TOPS-20 List Moderator ReSent-To: TOPS-20 Distribution: ; ReSent-Subject: Re: LAT (Finally!) ReSent-Message-ID: On Fri, 30 Mar 2007, Carl Baltrunas wrote: > Yikes! I thought that only Stanford and Tymshare were still running > KA-10s in 1980. (Of course the Tymshare KA-10s had a BBN pager and an > IMP interface, and were running Tenex, up on the ARPA-NET as Office-nn). > Ok, maybe MIT was also, but ITS isn't part of this discussion. I can think of other KAs that were still around at that time. SRI-AI was a KA running Tenex; the SRI KL system was SRI-KL. HARV-10 was TOPS-10, and I'm pretty sure it didn't die until the TCP/IP transition in 1983. -- Mark -- http://panda.com/tops-20 TOPS-20: a great improvement over its successors 31-Mar-2007 11:27:26-PDT,2600;000000000000 Return-Path: Received: from pangtzu.panda.com ([206.124.149.117]) by lingling.panda.com with TCP/SMTP; Sat, 31 Mar 2007 11:23:19 -0700 (PDT) X-Return-Path: X-Received: from cyteen.hactrn.net ([66.92.66.68]) by lingling.panda.com with TCP/SMTP; Sat, 31 Mar 2007 07:43:19 -0700 (PDT) X-Received: from thrintun.hactrn.net (thrintun.hactrn.net [IPv6:2002:425c:4242:0:219:d1ff:fe12:5d30]) (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 6BB0C28429 for ; Sat, 31 Mar 2007 14:43:12 +0000 (UTC) X-Received: from thrintun.hactrn.net (localhost [IPv6:::1]) by thrintun.hactrn.net (Postfix) with ESMTP id 26EF02283F for ; Sat, 31 Mar 2007 10:43:12 -0400 (EDT) Date: Sat, 31 Mar 2007 10:43:12 -0400 From: Rob Austein To: TOPS-20 Hackers and Yackers Subject: Re: LAT (Finally!) In-Reply-To: References: <46eb5ce5d6e44776e7ebfb4474b5b7e5@reststop.com> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20070331144312.26EF02283F@thrintun.hactrn.net> ReSent-Date: Sat, 31 Mar 2007 11:22:58 -0700 (PDT) ReSent-From: TOPS-20 List Moderator ReSent-To: TOPS-20 Distribution: ; ReSent-Subject: Re: LAT (Finally!) ReSent-Message-ID: At Sat, 31 Mar 2007 00:45:08 -0700 (PDT), Mark Crispin wrote: > > I can think of other KAs that were still around at that time. SRI-AI was > a KA running Tenex; the SRI KL system was SRI-KL. HARV-10 was TOPS-10, > and I'm pretty sure it didn't die until the TCP/IP transition in 1983. The ITS machines MIT-AI, MIT-ML, and MIT-DM were all KAs. AI and DM were shut down in 1983; I don't recall exactly when ML went, but it was later, probably 1984. AI's and ML's names were eventually resurrected as KS-10s (but not DM -- too many pieces of ITS code behaved differently if the machine's name for itself was named "DM"). 31-Mar-2007 11:31:11-PDT,3711;000000000000 Return-Path: Received: from pangtzu.panda.com ([206.124.149.117]) by lingling.panda.com with TCP/SMTP; Sat, 31 Mar 2007 11:23:56 -0700 (PDT) X-Return-Path: X-Received: from sesame.cc.columbia.edu ([128.59.59.56]) by lingling.panda.com with TCP/SMTP; Sat, 31 Mar 2007 07:51:44 -0700 (PDT) X-Received: from sesame.cc.columbia.edu (localhost [127.0.0.1]) by sesame.cc.columbia.edu (8.13.7/8.13.6) with ESMTP id l2VEpboZ018824; Sat, 31 Mar 2007 10:51:37 -0400 (EDT) X-Received: (from fdc@localhost) by sesame.cc.columbia.edu (8.13.7/8.12.8/Submit) id l2VEpbYk018822; Sat, 31 Mar 2007 10:51:37 -0400 (EDT) Date: Sat, 31 Mar 2007 10:51:37 EDT From: Frank da Cruz To: slogin@optonline.net Cc: TOPS-20@Lingling.Panda.COM Subject: Re: LAT (Finally!) In-Reply-To: Message-ID: ReSent-Date: Sat, 31 Mar 2007 11:23:44 -0700 (PDT) ReSent-From: TOPS-20 List Moderator ReSent-To: TOPS-20 Distribution: ; ReSent-Subject: Re: LAT (Finally!) ReSent-Message-ID: > Uploads were a difference story. For some reason that I've never been > able to track down, my system has never been able to do a good TCP/IP > upload. I've even hung PuTTY when trying to paste data into a > terminal window. It's the same thing with FTP: downloads are zippy > fast, but when I try to write a file that is larger than about 1K, the > fork hangs. This doesn't happen when I try to upload (using the > extended mode FTP server which can run in interactive mode) to > Twenex.ORG or a Toad, so I've always assumed it's something in my > machine, but I've never been able to track it down. > I'm just guessing, but it seems to me that every DEC timesharing system was designed on the assumption that a lot of data would be going out and very little coming in -- the terminal/host model. And thus there were big buffer pools in the outbound direction and much smaller ones for inbound. Of course this might have been appropriate for actual terminals (at least until -- you remember this -- the Concept-100 appeared with its RSX20F-killing "transmit screen" function). Anyway, who knows, this might even have carried over into the TCP/IP stack and/or CTERM and LAT implementations. > Anyway, uploading the same file via TCP/IP negotiated an 80 byte > packet size and took 18:41 or ran at 270 CPS, less than one tenth the > download speed. Using LAT was faster: it negotiated a 72 byte packet > size and took 5:22 or ran at 943 CPS. It got 26 errors (which I > thought was surprising). > You mean with Kermit? You can, of course, control the packet size. Tell the file receiver to SET RECEIVE PACKET-LENGTH 4000 or whatever, as noted here: http://www.columbia.edu/kermit/ftp/d/k20mit.txt and in the Kermit-20 manual. > Finally, a quick question: I noticed that, when receiving a file from > the 20, Kermit-95 can not give an estimated time remaining figure. > That's because Tops-20 Kermit doesn't do the "A" attribute, right? It > didn't look like it did. Well? How about it? :-) > Yeah, how about it? :-) To answer your other question, I am almost certain that we had DECnet (CTERM) access to the PDP-10s at both Stevens and CMU over CCNET, but it would take a lot of excavation to be certain. I'm sure I was logging in to CMU10A or whatever it was called from our 20s at the time, over DECnet, but that doesn't prove the -10 itself was on DECnet because they might have had some kind of contraption in between. - Frank 31-Mar-2007 11:35:02-PDT,1696;000000000000 Return-Path: Received: from pangtzu.panda.com ([206.124.149.117]) by lingling.panda.com with TCP/SMTP; Sat, 31 Mar 2007 11:24:14 -0700 (PDT) X-Return-Path: X-Received: from dbit.dbit.com ([208.238.226.25] -- may be forged) by lingling.panda.com with TCP/SMTP; Sat, 31 Mar 2007 09:23:46 -0700 (PDT) X-Received: from dbit.dbit.com (IDENT:501@localhost [127.0.0.1]) by dbit.dbit.com (8.13.8/8.13.8) with ESMTP id l2VGNhdK026066 for ; Sat, 31 Mar 2007 12:23:43 -0400 X-Received: (from wilson@localhost) by dbit.dbit.com (8.13.8/8.13.8/Submit) id l2VGNhC4026065 for TOPS-20@LINGLING.PANDA.COM; Sat, 31 Mar 2007 12:23:43 -0400 Date: Sat, 31 Mar 2007 12:23:43 -0400 From: John Wilson Message-Id: <200703311623.l2VGNhC4026065@dbit.dbit.com> To: TOPS-20@LINGLING.PANDA.COM Subject: Re: LAT (Finally!) ReSent-Date: Sat, 31 Mar 2007 11:24:05 -0700 (PDT) ReSent-From: TOPS-20 List Moderator ReSent-To: TOPS-20 Distribution: ; ReSent-Subject: Re: LAT (Finally!) ReSent-Message-ID: From: Mark Crispin >I can think of other KAs that were still around at that time. SRI-AI was >a KA running Tenex; the SRI KL system was SRI-KL. HARV-10 was TOPS-10, >and I'm pretty sure it didn't die until the TCP/IP transition in 1983. Might be remembering wrong, but wasn't the QUT (Australia) machine that was shut down around 1991-1992 a KA10? Also I thought there was one in Pennsylvania (I forget which school) until almost that late. Could be wrong on both. John Wilson D Bit 31-Mar-2007 11:38:55-PDT,3598;000000000000 Return-Path: Received: from pangtzu.panda.com ([206.124.149.117]) by lingling.panda.com with TCP/SMTP; Sat, 31 Mar 2007 11:24:49 -0700 (PDT) X-Return-Path: X-Received: from mail.math.utah.edu ([155.101.98.135]) by lingling.panda.com with TCP/SMTP; Sat, 31 Mar 2007 11:19:28 -0700 (PDT) X-Received: from psi.math.utah.edu (psi.math.utah.edu [155.101.96.19]) by mail.math.utah.edu (8.13.6/8.13.6) with ESMTP id l2VIJLdv027397; Sat, 31 Mar 2007 12:19:21 -0600 (MDT) X-Received: from psi.math.utah.edu (localhost [127.0.0.1]) by psi.math.utah.edu (8.13.6/8.13.6) with ESMTP id l2VIJLC0015994; Sat, 31 Mar 2007 12:19:21 -0600 (MDT) X-Received: (from beebe@localhost) by psi.math.utah.edu (8.13.6/8.13.6/Submit) id l2VIJLBN015992; Sat, 31 Mar 2007 12:19:21 -0600 (MDT) Date: Sat, 31 Mar 2007 12:19:21 -0600 (MDT) From: "Nelson H. F. Beebe" To: TOPS-20@Lingling.Panda.COM 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: [tops20] inbound FTP performance issue Message-ID: X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0 (mail.math.utah.edu [155.101.98.135]); Sat, 31 Mar 2007 12:19:21 -0600 (MDT) ReSent-Date: Sat, 31 Mar 2007 11:24:41 -0700 (PDT) ReSent-From: TOPS-20 List Moderator ReSent-To: TOPS-20 Distribution: ; ReSent-Subject: [tops20] inbound FTP performance issue ReSent-Message-ID: I'm working again on getting a large C library working on TOPS-20, and have put using FTP from a Sun Solaris 10 SPARC system to move source code files to it. I get erratic performance that may have some simple fix, but I don't see it. Specifically, a "put foo.c" can complete in 10 seconds, or take 20 minutes, largely independent of the size of the file. There is no significant CPU or network load on either machine. On the Unix end, I use the native Solaris /bin/ftp, and on the TOPS-20 end, the FTP that comes with PANDA. A typical session with lousy performance looks like this: % ftp xxx Connected to xxx 220 xxx FTP Server Process 5Z(40)-7 at Sat 31-Mar-2007 11:05-MST ftp> user xxx 331 User name ok. Password, please. Password: 230 User xxx logged in at Sat 31-Mar-2007 11:05-MST, job 8. ftp> ascii ftp> put xxx.c 200 Port xxx at host xxx accepted. 150 ASCII Store of XXX.C.1;P777752;A started. 226 Transfer completed. 7680 (8) bytes transferred. local: xxx.c remote: xxx.c 7680 bytes sent in 3.5e+02 seconds (0.02 Kbytes/s) A kermit connection transferred the same file at a rate 10x that reported by FTP. Ideas, anyone? [apart from switching to kermit, which I certainly can do.] ------------------------------------------------------------------------------- - 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/ - ------------------------------------------------------------------------------- 31-Mar-2007 11:51:26-PDT,1819;000000000000 Return-Path: Received: from pangtzu.panda.com ([206.124.149.117]) by lingling.panda.com with TCP/SMTP; Sat, 31 Mar 2007 11:47:42 -0700 (PDT) X-Return-Path: X-Received: from pangtzu.panda.com ([206.124.149.117]) by lingling.panda.com with TCP/SMTP; Sat, 31 Mar 2007 11:31:38 -0700 (PDT) Date: Sat, 31 Mar 2007 11:31:33 -0700 (PDT) From: Mark Crispin Sender: mrc@pangtzu.panda.com To: Rob Austein cc: TOPS-20 Hackers and Yackers Subject: Re: LAT (Finally!) In-Reply-To: <20070331144312.26EF02283F@thrintun.hactrn.net> Message-ID: References: <46eb5ce5d6e44776e7ebfb4474b5b7e5@reststop.com> <20070331144312.26EF02283F@thrintun.hactrn.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=us-ascii ReSent-Date: Sat, 31 Mar 2007 11:47:35 -0700 (PDT) ReSent-From: TOPS-20 List Moderator ReSent-To: TOPS-20 Distribution: ; ReSent-Subject: Re: LAT (Finally!) ReSent-Message-ID: On Sat, 31 Mar 2007, Rob Austein wrote: > The ITS machines MIT-AI, MIT-ML, and MIT-DM were all KAs. AI and DM > were shut down in 1983; I don't recall exactly when ML went, but it > was later, probably 1984. Probably when their NCP reclama ran out. [How many old farts here remember what "NCP reclama" was?!?] -- Mark -- http://panda.com/tops-20 TOPS-20: a great improvement over its successors 1-Apr-2007 12:47:52-PDT,2211;000000000000 Return-Path: Received: from pangtzu.panda.com ([206.124.149.117]) by lingling.panda.com with TCP/SMTP; Sun, 1 Apr 2007 12:43:15 -0700 (PDT) X-Return-Path: X-Received: from mail2.panix.com ([166.84.1.73]) by lingling.panda.com with TCP/SMTP; Sun, 1 Apr 2007 12:32:11 -0700 (PDT) X-Received: from panix5.panix.com (panix5.panix.com [166.84.1.5]) by mail2.panix.com (Postfix) with ESMTP id 7A7ACCA9B3 for ; Sun, 1 Apr 2007 15:32:02 -0400 (EDT) X-Received: (from alderson@localhost) by panix5.panix.com (8.11.6p3/8.8.8/PanixN1.1) id l31JW2Z08622; Sun, 1 Apr 2007 15:32:02 -0400 (EDT) Date: Sun, 1 Apr 2007 15:32:02 -0400 (EDT) Message-Id: <200704011932.l31JW2Z08622@panix5.panix.com> From: Rich Alderson To: TOPS-20@Lingling.Panda.COM In-reply-to: (message from Mark Crispin on Fri, 30 Mar 2007 21:05:07 -0700 (PDT)) Subject: Re: LAT (Finally!) References: <200703301820.l2UIKZx03518@panix5.panix.com> ReSent-Date: Sun, 1 Apr 2007 12:43:06 -0700 (PDT) ReSent-From: TOPS-20 List Moderator ReSent-To: TOPS-20 Distribution: ; ReSent-Subject: Re: LAT (Finally!) ReSent-Message-ID: > Date: Fri, 30 Mar 2007 21:05:07 -0700 (PDT) > From: Mark Crispin > On Fri, 30 Mar 2007, Rich Alderson wrote: >> Stevens, as it happens, was always and only a Tops-10 shop until they >> moved to VMS. Leslie and Betsy wouldn't have had it any other way. > Who was Betsy? She must have been after my time. Sorry, brain fart. Betsy Ramsey is associated in my mind with Leslie Maltz, but that's a DECUS association. I believe that Betsy was at one of the DC universities, on further reflection. Rich 1-Apr-2007 16:49:25-PDT,2897;000000000000 Return-Path: Received: from pangtzu.panda.com ([206.124.149.117]) by lingling.panda.com with TCP/SMTP; Sun, 1 Apr 2007 16:45:20 -0700 (PDT) X-Return-Path: X-Received: from pangtzu.panda.com ([206.124.149.117]) by lingling.panda.com with TCP/SMTP; Sun, 1 Apr 2007 13:02:15 -0700 (PDT) Date: Sun, 1 Apr 2007 13:02:08 -0700 (PDT) From: Mark Crispin Sender: mrc@pangtzu.panda.com To: Rich Alderson cc: TOPS-20@Lingling.Panda.COM Subject: Re: LAT (Finally!) In-Reply-To: <200704011932.l31JW2Z08622@panix5.panix.com> Message-ID: References: <200703301820.l2UIKZx03518@panix5.panix.com> <200704011932.l31JW2Z08622@panix5.panix.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=us-ascii ReSent-Date: Sun, 1 Apr 2007 16:45:13 -0700 (PDT) ReSent-From: TOPS-20 List Moderator ReSent-To: TOPS-20 Distribution: ; ReSent-Subject: Re: LAT (Finally!) ReSent-Message-ID: On Sun, 1 Apr 2007, Rich Alderson wrote: > Sorry, brain fart. Betsy Ramsey is associated in my mind with Leslie Maltz, > but that's a DECUS association. I believe that Betsy was at one of the DC > universities, on further reflection. Aha. The only two Betsys in the PDP-10 world that I remember were Betsy Ramsey and Betsy Unangst, neither of whom were at Stevens. Betsy Ramsey was at Wesleyan, then at the American Mathematic Society for a long time, and the last that I heard she was at Catholic Univerity of America. She's on the TOPS-20 list, so I hope that she'll give us an update on what she's been up to! Betsy Unangst was one of the founders of CUFFS Planning & Models, Ltd., a small software house in New York (http://www.cuffs88.com) whose product was CUFFS, the Combs-Unangst Financial Forecasting System. I worked there in the mid-1970s; at the time their biggest customer was CompuServe. Back then, CUFFS was written in Fortran, but was too large to run on TOPS-10 (or CompuServe's funky fork of TOPS-10) without overlaying. I forget why, but they couldn't use DEC's overlay system or GETSEG, so I had to write a custom overlay system in assembly for them. It was great to get on TOPS-20 and not have to deal with that any more! I haven't heard from Betsy Unangst in 30 years, although Dave Combs (the other founder) and I exchange email about once a decade. -- Mark -- http://panda.com/tops-20 TOPS-20: a great improvement over its successors 1-Apr-2007 16:53:00-PDT,2324;000000000000 Return-Path: Received: from pangtzu.panda.com ([206.124.149.117]) by lingling.panda.com with TCP/SMTP; Sun, 1 Apr 2007 16:45:30 -0700 (PDT) X-Return-Path: X-Received: from cyteen.hactrn.net ([66.92.66.68]) by lingling.panda.com with TCP/SMTP; Sun, 1 Apr 2007 14:21:51 -0700 (PDT) X-Received: from thrintun.hactrn.net (thrintun.hactrn.net [IPv6:2002:425c:4242:0:219:d1ff:fe12:5d30]) (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 9A66928429 for ; Sun, 1 Apr 2007 21:21:44 +0000 (UTC) X-Received: from thrintun.hactrn.net (localhost [IPv6:::1]) by thrintun.hactrn.net (Postfix) with ESMTP id 59F252283F for ; Sun, 1 Apr 2007 17:21:44 -0400 (EDT) Date: Sun, 01 Apr 2007 17:21:44 -0400 From: Rob Austein To: TOPS-20@Lingling.Panda.COM Subject: Re: LAT (Finally!) In-Reply-To: <200704011932.l31JW2Z08622@panix5.panix.com> References: <200703301820.l2UIKZx03518@panix5.panix.com> <200704011932.l31JW2Z08622@panix5.panix.com> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20070401212144.59F252283F@thrintun.hactrn.net> ReSent-Date: Sun, 1 Apr 2007 16:45:23 -0700 (PDT) ReSent-From: TOPS-20 List Moderator ReSent-To: TOPS-20 Distribution: ; ReSent-Subject: Re: LAT (Finally!) ReSent-Message-ID: At Sun, 1 Apr 2007 15:32:02 -0400 (EDT), Rich Alderson wrote: > > Sorry, brain fart. Betsy Ramsey is associated in my mind with Leslie Maltz, > but that's a DECUS association. I believe that Betsy was at one of the DC > universities, on further reflection. Catholic University. Betsy's an almost-classmate of mine from Wesleyan, where we both once worked for Doug Bigelow. 1-Apr-2007 16:56:41-PDT,2151;000000000000 Return-Path: Received: from pangtzu.panda.com ([206.124.149.117]) by lingling.panda.com with TCP/SMTP; Sun, 1 Apr 2007 16:45:43 -0700 (PDT) X-Return-Path: X-Received: from pop-knobcone.atl.sa.earthlink.net ([207.69.195.64]) by lingling.panda.com with TCP/SMTP; Sun, 1 Apr 2007 16:17:15 -0700 (PDT) X-Received: from cpe-24-221-177-162.ca.sprintbbd.net ([24.221.177.162] helo=[204.238.239.104]) by pop-knobcone.atl.sa.earthlink.net with esmtp (Exim 3.36 #1) id 1HY9IC-00067w-00; Sun, 01 Apr 2007 19:17:00 -0400 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v624) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <362c12930e81b66c5ed38d3ec8be9b37@reststop.com> Content-Transfer-Encoding: 7bit Cc: TOPS-20@Lingling.Panda.COM X-Image-Url: http://www.goldenstategiftbaskets.com/minibasket.jpg From: Carl Baltrunas Subject: Re: [tops20] inbound FTP performance issue Date: Sun, 1 Apr 2007 16:16:58 -0700 To: "Nelson H. F. Beebe" X-Mailer: Apple Mail (2.624) ReSent-Date: Sun, 1 Apr 2007 16:45:36 -0700 (PDT) ReSent-From: TOPS-20 List Moderator ReSent-To: TOPS-20 Distribution: ; ReSent-Subject: Re: [tops20] inbound FTP performance issue ReSent-Message-ID: On Mar 31, 2007, at 11:19 AM, Nelson H. F. Beebe wrote: > I'm working again on getting a large C library working on TOPS-20, and > have put using FTP from a Sun Solaris 10 SPARC system to move source > code files to it. > > I get erratic performance that may have some simple fix, but I don't > see it. Specifically, a "put foo.c" can complete in 10 seconds, or > take 20 minutes, largely independent of the size of the file. There > is no significant CPU or network load on either machine. Have you tried logging into the Tops-20 system and pulling the data? I'd be interested in knowing if that shows any significant difference. -Carl 1-Apr-2007 21:39:45-PDT,4393;000000000000 Return-Path: Received: from pangtzu.panda.com ([206.124.149.117]) by lingling.panda.com with TCP/SMTP; Sun, 1 Apr 2007 21:35:45 -0700 (PDT) X-Return-Path: X-Received: from mta3.srv.hcvlny.cv.net ([167.206.4.198]) by lingling.panda.com with TCP/SMTP; Sun, 1 Apr 2007 18:49:34 -0700 (PDT) X-Received: from optonline.net (mstr3a.srv.hcvlny.cv.net [10.240.4.140]) by mta3.srv.hcvlny.cv.net (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTP id <0JFU0010QL2FTOL0@mta3.srv.hcvlny.cv.net> for TOPS-20@Lingling.Panda.COM; Sun, 01 Apr 2007 21:49:28 -0400 (EDT) X-Received: from [10.240.3.207] (Forwarded-For: 64.72.85.122, [10.240.3.207]) by mstr3.srv.hcvlny.cv.net (mshttpd); Mon, 02 Apr 2007 01:49:27 +0000 (GMT) Date: Mon, 02 Apr 2007 01:49:27 +0000 (GMT) From: slogin@optonline.net Subject: Re: [tops20] inbound FTP performance issue In-reply-to: To: "Nelson H. F. Beebe" Cc: TOPS-20@Lingling.Panda.COM, beebe@math.utah.edu Message-id: MIME-version: 1.0 X-Mailer: Sun Java(tm) System Messenger Express 6.2-6.01 (built Apr 3 2006) Content-type: text/plain; charset=us-ascii Content-language: en Content-transfer-encoding: 7BIT Content-disposition: inline X-Accept-Language: en Priority: normal References: ReSent-Date: Sun, 1 Apr 2007 21:35:36 -0700 (PDT) ReSent-From: TOPS-20 List Moderator ReSent-To: TOPS-20 Distribution: ; ReSent-Subject: Re: [tops20] inbound FTP performance issue ReSent-Message-ID: Nelson, I believe you may be seeing behavior that I have documented on previous occasions. It would appear that, on certain hosts systems, TCP/IP upload somehow gets 'clogged', except for very slow character typing. For large uploads, sometimes you just wait. The behavior is independent on whether you are signed on to the 20 'pulling' or on a remote client 'pushing'. I think the Kermit statistics that I posted yesterday are a perfect example: Kermit has to negotiate a small packet size and I get both packet error and time out errors when doing TCP/IP uploads. LAT uploads are a lot faster: over three times as fast, in fact. This performance is independent of FTP server; I get it with either the BBN server which uses the BBN JSYS interface or with the new extended mode Tops-20 server which uses the JFN based interface. Files of a small size (under a K) seem to just blink over, sometimes even larger files will go. After a certain file size, however, the transfer just wedges. Usually you will see the transfer fork waiting in TCPTST and that the TCB has been aborted. For smaller files, it usually restarts, for larger ones, it just hangs (well, I've never waited much more than 5 minutes). The behavior happens whether I am on a local LAN or not, so I don't know if segment sizes are in play, here. I don't think this is a KLH10 issue, per se. Otherwise, I would see it on TWENEX.ORG and I don't. I've tested my FTP server there a number of times and I've never had any problem uploading. Ditto Toads. Anybody else? Mark? Lingling's fine, I'm sure ... The only thing I've been able to come up with is that I am perhaps running a version of KLH on a machine that it wasn't compiled on. I'm running Debian, but I don't know what KLH this is. I've been meaning to recompile it here, but ... --T ----- Original Message ----- From: "Nelson H. F. Beebe" Date: Saturday, March 31, 2007 2:59 pm Subject: [tops20] inbound FTP performance issue To: TOPS-20@Lingling.Panda.COM Cc: beebe@math.utah.edu > I'm working again on getting a large C library working on TOPS- 20, > and have put using FTP from a Sun Solaris 10 SPARC system to move > source code files to it. > > I get erratic performance that may have some simple fix, but I don't > see it. Specifically, a "put foo.c" can complete in 10 seconds, or > take 20 minutes, largely independent of the size of the file. There > is no significant CPU or network load on either machine. > > On the Unix end, I use the native Solaris /bin/ftp, and on the > TOPS-20 end, the FTP that comes with PANDA. 5-May-2007 20:38:14-PDT,3096;000000000000 Return-Path: Received: from pangtzu.panda.com ([206.124.149.117]) by lingling.panda.com with TCP/SMTP; Sat, 5 May 2007 20:31:26 -0700 (PDT) X-Return-Path: X-Received: from mta5.srv.hcvlny.cv.net ([167.206.4.200]) by lingling.panda.com with TCP/SMTP; Sat, 5 May 2007 19:37:39 -0700 (PDT) X-Received: from [192.168.1.7] (ool-45720130.dyn.optonline.net [69.114.1.48]) by mta5.srv.hcvlny.cv.net (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTP id <0JHL0097JLYB2BP0@mta5.srv.hcvlny.cv.net> for TOPS-20@Lingling.Panda.COM; Sat, 05 May 2007 22:37:24 -0400 (EDT) Date: Sat, 05 May 2007 22:37:22 -0400 From: Thomas DeBellis Subject: .DVNFT In-reply-to: <20070401212144.59F252283F@thrintun.hactrn.net> To: TOPS-20@Lingling.Panda.COM Message-id: <463D3F62.2030108@optonline.net> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en References: <200703301820.l2UIKZx03518@panix5.panix.com> <200704011932.l31JW2Z08622@panix5.panix.com> <20070401212144.59F252283F@thrintun.hactrn.net> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) ReSent-Date: Sat, 5 May 2007 20:31:18 -0700 (PDT) ReSent-From: TOPS-20 List Moderator ReSent-To: TOPS-20 Distribution: ; ReSent-Subject: .DVNFT ReSent-Message-ID: In the process of testing some more graphical FTP clients with the new FTP server, I found another problem. The SmartFTP graphical FTP client wants to have the output of the LIST command to be 'classified', so it gives what it thinks is 'ls' the "-F" switch. By classifying, it wants a suffix appended to certain entries in a listing. For example a directory "foo" would get displayed as "foo/". Sockets are suffixed with a "=", so I check for a number of different network-like devices when doing a listing: .DVTCP, .DVNET, .DVDCN, .DVSRV and .DVNFT. Unfortunately, like .DVTCP, .DVNFT doesn't exist in the standard MONSYM (I don't think .DVNFT is in the PANDA MONSYM, either). STDEV% shows that device "NFT" is device type 24. So, instead of the following devices: .DVATS==:24 ;APPLICATIONS TERMINAL SERVICE .DVADS==:25 ;AYDIN DISPLAY We should have the following in MONSYM: .DVNFT==:24 ;NFT (FTS) .DVTCP==:25 ;TCP/IP4 I don't remember seeing any "APPLICATIONS TERMINAL SERVICE" nor "AYDIN DISPLAY". Was either of these the canonical display support that DEC was talking about at one point (at least, they asked us at Columbia whether we could use something flavored like ITS SUPDUP). Finally SmartFTP probably shouldn't be using "-F" as not all Unices implement it. 5-May-2007 21:01:18-PDT,2300;000000000000 Return-Path: Received: from pangtzu.panda.com ([206.124.149.117]) by lingling.panda.com with TCP/SMTP; Sat, 5 May 2007 20:55:06 -0700 (PDT) X-Return-Path: X-Received: from pangtzu.panda.com ([206.124.149.117]) by lingling.panda.com with TCP/SMTP; Sat, 5 May 2007 20:54:39 -0700 (PDT) Date: Sat, 5 May 2007 20:54:34 -0700 (PDT) From: Mark Crispin Sender: mrc@pangtzu.panda.com To: Thomas DeBellis cc: TOPS-20@Lingling.Panda.COM Subject: Re: .DVNFT In-Reply-To: <463D3F62.2030108@optonline.net> Message-ID: References: <200703301820.l2UIKZx03518@panix5.panix.com> <200704011932.l31JW2Z08622@panix5.panix.com> <20070401212144.59F252283F@thrintun.hactrn.net> <463D3F62.2030108@optonline.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=us-ascii ReSent-Date: Sat, 5 May 2007 20:54:57 -0700 (PDT) ReSent-From: TOPS-20 List Moderator ReSent-To: TOPS-20 Distribution: ; ReSent-Subject: Re: .DVNFT ReSent-Message-ID: On Sat, 5 May 2007, Thomas DeBellis wrote: > Unfortunately, like .DVTCP, .DVNFT doesn't exist > in the standard MONSYM (I don't think .DVNFT is in the PANDA MONSYM, > either). .DVTCP and .DVNFT have been defined in the Panda MONSYM since September 12, 2005. > .DVATS==:24 ;APPLICATIONS TERMINAL SERVICE > .DVADS==:25 ;AYDIN DISPLAY > I don't remember seeing any "APPLICATIONS TERMINAL SERVICE" nor "AYDIN > DISPLAY". ATSSRV was in the TOPS-20 v4 field tests. I don't know if it disappeared in release 4, or in release 5. It's gone now, and repeated efforts by myself over the past 20 or so years to find a copy of ATSSRV.MAC have failed. However, the fact that DEC recycled the device numbers indicates that these device drivers were abandoned. -- Mark -- http://panda.com/tops-20 TOPS-20: a great improvement over its successors 17-May-2007 06:50:07-PDT,1226;000000000000 Return-Path: Received: from pangtzu.panda.com ([206.124.149.117]) by lingling.panda.com with TCP/SMTP; Thu, 17 May 2007 06:43:26 -0700 (PDT) X-Return-Path: X-Received: from pangtzu.panda.com ([206.124.149.117]) by lingling.panda.com with TCP/SMTP; Thu, 17 May 2007 06:42:35 -0700 (PDT) Date: Thu, 17 May 2007 06:42:27 -0700 (PDT) From: Mark Crispin Sender: mrc@pangtzu.panda.com To: TOPS-20 Hackers and Yackers Subject: 24 years ago today... Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=us-ascii ReSent-Date: Thu, 17 May 2007 06:43:12 -0700 (PDT) ReSent-From: TOPS-20 List Moderator ReSent-To: TOPS-20 Distribution: ; ReSent-Subject: 24 years ago today... ReSent-Message-ID: Hard to believe that it's been so long. On May 17, 1983 at 2PM US east coast time, Ken Olsen and Bill Johnson cancelled Project Jupiter and killed the PDP-10. -- Mark -- http://panda.com/tops-20 TOPS-20: a great improvement over its successors 28-May-2007 20:03:51-PDT,1705;000000000000 Return-Path: Received: from pangtzu.panda.com ([206.124.149.117]) by lingling.panda.com with TCP/SMTP; Mon, 28 May 2007 19:56:50 -0700 (PDT) X-Return-Path: X-Received: from mta3.srv.hcvlny.cv.net ([167.206.4.198]) by lingling.panda.com with TCP/SMTP; Sat, 26 May 2007 14:16:26 -0700 (PDT) X-Received: from [192.168.1.7] (ool-45720130.dyn.optonline.net [69.114.1.48]) by mta3.srv.hcvlny.cv.net (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTP id <0JIO00G72337HCB0@mta3.srv.hcvlny.cv.net> for TOPS-20@Lingling.Panda.COM; Sat, 26 May 2007 17:16:19 -0400 (EDT) Date: Sat, 26 May 2007 17:16:18 -0400 From: Thomas DeBellis Subject: SC%MMN, SC%MPP, SC%SDV To: TOPS-20@Lingling.Panda.COM Message-id: <4658A3A2.8050405@optonline.net> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) ReSent-Date: Mon, 28 May 2007 19:56:41 -0700 (PDT) ReSent-From: TOPS-20 List Moderator ReSent-To: TOPS-20 Distribution: ; ReSent-Subject: SC%MMN, SC%MPP, SC%SDV ReSent-Message-ID: Consider the following entries in MONSYM.MAC: SC%MMN==:1B2 ;MAP MONITOR SC%MPP==:1B4 ;MAP PRIVILEGED PAGES SC%SDV==:1B5 ;SPECIAL DEVICES I didn't see these used anywhere in the monitor sources that I have when I looked with FIND. Are they actually used for anything or are they Tenex remnants (I don't have Tenex source)? 28-May-2007 20:31:40-PDT,1433;000000000000 Return-Path: Received: from pangtzu.panda.com ([206.124.149.117]) by lingling.panda.com with TCP/SMTP; Mon, 28 May 2007 20:25:07 -0700 (PDT) X-Return-Path: X-Received: from pangtzu.panda.com ([206.124.149.117]) by lingling.panda.com with TCP/SMTP; Mon, 28 May 2007 20:24:57 -0700 (PDT) Date: Mon, 28 May 2007 20:24:52 -0700 (PDT) From: Mark Crispin Sender: mrc@pangtzu.panda.com To: Thomas DeBellis cc: TOPS-20@Lingling.Panda.COM Subject: Re: SC%MMN, SC%MPP, SC%SDV In-Reply-To: <4658A3A2.8050405@optonline.net> Message-ID: References: <4658A3A2.8050405@optonline.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=us-ascii ReSent-Date: Mon, 28 May 2007 20:25:00 -0700 (PDT) ReSent-From: TOPS-20 List Moderator ReSent-To: TOPS-20 Distribution: ; ReSent-Subject: Re: SC%MMN, SC%MPP, SC%SDV ReSent-Message-ID: On Sat, 26 May 2007, Thomas DeBellis wrote: > SC%MMN==:1B2 ;MAP MONITOR > SC%MPP==:1B4 ;MAP PRIVILEGED PAGES > SC%SDV==:1B5 ;SPECIAL DEVICES As you guessed, these are remnants from Tenex; and AFAICT they were never implemented in Tenex. -- Mark -- http://panda.com/tops-20 TOPS-20: a great improvement over its successors 12-Jun-2007 09:05:57-PDT,2417;000000000000 Return-Path: Received: from pangtzu.panda.com ([206.124.149.117]) by lingling.panda.com with TCP/SMTP; Tue, 12 Jun 2007 08:59:44 -0700 (PDT) X-Return-Path: X-Received: from sj-iport-3.cisco.com ([171.71.176.72]) by lingling.panda.com with TCP/SMTP; Mon, 11 Jun 2007 23:59:27 -0700 (PDT) X-Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-3.cisco.com with ESMTP; 11 Jun 2007 23:59:18 -0700 X-IronPort-AV: i="4.16,410,1175497200"; d="scan'208"; a="492795239:sNHT35618378" X-Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l5C6xHwu004541 for ; Mon, 11 Jun 2007 23:59:17 -0700 X-Received: from cisco.com (pita.cisco.com [171.71.177.199]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l5C6xDaI003872 for ; Tue, 12 Jun 2007 06:59:17 GMT X-Received: (from billw@localhost) by cisco.com (8.8.8-Cisco List Logging/8.8.8) id XAA18305 for tops-20@lingling.panda.com; Mon, 11 Jun 2007 23:58:31 -0700 (PDT) Sender: Bill Westfield Date: Mon, 11 Jun 2007 23:58:31 PDT From: William "Chops" Westfield To: tops-20@lingling.panda.com Subject: Unix MM... Message-ID: DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=124; t=1181631557; x=1182495557; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=billw@cisco.com; z=From:=20William=20=22Chops=22=20Westfield=20 |Subject:=20Unix=20MM... |Sender:=20Bill=20Westfield=20; bh=OO3tOSUGzhWImWD5CmdbIJm3BmBtJLP9K8IUftPdEKk=; b=gZILGvOh7QLYTXu/mVTinK9Tisl3/NiycP7rUdFwtZL89wO0O7SEtx/cqZBkv3iBeKGs3Y+3 A/DSfDLhkUF36qEiAWbMg5Er4v3xfisy/E5Z54l8TLKvQy1j0Jc/Ev3v; Authentication-Results: sj-dkim-2; header.From=billw@cisco.com; dkim=pass (s ig from cisco.com/sjdkim2002 verified; ); ReSent-Date: Tue, 12 Jun 2007 08:59:33 -0700 (PDT) ReSent-From: TOPS-20 List Moderator ReSent-To: TOPS-20 Distribution: ; ReSent-Subject: Unix MM... ReSent-Message-ID: What the status and current location of the latest version of the C (Columbia, originally) MM for unix? Thanks Bill W 12-Jun-2007 17:39:18-PDT,1435;000000000000 Return-Path: Received: from pangtzu.panda.com ([206.124.149.117]) by lingling.panda.com with TCP/SMTP; Tue, 12 Jun 2007 17:33:23 -0700 (PDT) X-Return-Path: X-Received: from sesame.cc.columbia.edu ([128.59.59.56]) by lingling.panda.com with TCP/SMTP; Tue, 12 Jun 2007 09:18:27 -0700 (PDT) X-Received: from sesame.cc.columbia.edu (localhost [127.0.0.1]) by sesame.cc.columbia.edu (8.13.7/8.13.6) with ESMTP id l5CGIKsA015151; Tue, 12 Jun 2007 12:18:20 -0400 (EDT) X-Received: (from fdc@localhost) by sesame.cc.columbia.edu (8.13.7/8.12.8/Submit) id l5CGIGM7015150; Tue, 12 Jun 2007 12:18:16 -0400 (EDT) Date: Tue, 12 Jun 2007 12:18:16 EDT From: Frank da Cruz To: William "Chops" Westfield Cc: TOPS-20 List Moderator , tops-20@Lingling.Panda.COM Subject: Re: Unix MM... In-Reply-To: Message-ID: ReSent-Date: Tue, 12 Jun 2007 17:33:16 -0700 (PDT) ReSent-From: TOPS-20 List Moderator ReSent-To: TOPS-20 Distribution: ; ReSent-Subject: Re: Unix MM... ReSent-Message-ID: > What the status and current location of the latest version of the > C (Columbia, originally) MM for unix? > http://www.columbia.edu/~fdc/mm/ - Frank 12-Jun-2007 17:44:56-PDT,1719;000000000000 Return-Path: Received: from pangtzu.panda.com ([206.124.149.117]) by lingling.panda.com with TCP/SMTP; Tue, 12 Jun 2007 17:33:38 -0700 (PDT) X-Return-Path: X-Received: from mail2.panix.com ([166.84.1.73]) by lingling.panda.com with TCP/SMTP; Tue, 12 Jun 2007 10:53:09 -0700 (PDT) X-Received: from panix5.panix.com (panix5.panix.com [166.84.1.5]) by mail2.panix.com (Postfix) with ESMTP id EB53A3480D; Tue, 12 Jun 2007 13:53:02 -0400 (EDT) X-Received: (from alderson@localhost) by panix5.panix.com (8.11.6p3/8.8.8/PanixN1.1) id l5CHr2w19750; Tue, 12 Jun 2007 13:53:02 -0400 (EDT) Date: Tue, 12 Jun 2007 13:53:02 -0400 (EDT) Message-Id: <200706121753.l5CHr2w19750@panix5.panix.com> From: Rich Alderson To: billw@cisco.com CC: tops-20@lingling.panda.com In-reply-to: Subject: Re: Unix MM... References: ReSent-Date: Tue, 12 Jun 2007 17:33:27 -0700 (PDT) ReSent-From: TOPS-20 List Moderator ReSent-To: TOPS-20 Distribution: ; ReSent-Subject: Re: Unix MM... ReSent-Message-ID: > Date: Mon, 11 Jun 2007 23:58:31 PDT > From: William "Chops" Westfield > What the status and current location of the latest version of the > C (Columbia, originally) MM for unix? Hi, Bill, It looks as though the latest bits are at ftp://ftp.cc.columbia.edu/mm/ and it was last worked on in 2003 by FdC. I imagine that no one outside Columbia has touched it since. Rich 12-Jun-2007 17:50:44-PDT,4505;000000000000 Return-Path: Received: from pangtzu.panda.com ([206.124.149.117]) by lingling.panda.com with TCP/SMTP; Tue, 12 Jun 2007 17:33:49 -0700 (PDT) X-Return-Path: X-Received: from mail.math.utah.edu ([155.101.98.135]) by lingling.panda.com with TCP/SMTP; Tue, 12 Jun 2007 11:55:01 -0700 (PDT) X-Received: from sunblast.math.utah.edu (sunblast.math.utah.edu [155.101.96.165]) by mail.math.utah.edu (8.13.6/8.13.6) with ESMTP id l5CIspw5000594; Tue, 12 Jun 2007 12:54:51 -0600 (MDT) X-Received: from sunblast.math.utah.edu (localhost [127.0.0.1]) by sunblast.math.utah.edu (8.13.6/8.13.6) with ESMTP id l5CIspFf021503; Tue, 12 Jun 2007 12:54:51 -0600 (MDT) X-Received: (from beebe@localhost) by sunblast.math.utah.edu (8.13.6/8.13.6/Submit) id l5CIspY9021502; Tue, 12 Jun 2007 12:54:51 -0600 (MDT) Date: Tue, 12 Jun 2007 12:54:51 -0600 (MDT) From: "Nelson H. F. Beebe" To: William "Chops" Westfield Cc: beebe@math.utah.edu, TOPS-20 List Moderator , tops-20@lingling.panda.com X-US-Mail: "Department of Mathematics, 110 LCB, University of Utah, 155 S 1400 E RM 233, Salt Lake City, UT 84112-0090, USA" X-Telephone: +1 801 581 5254 X-FAX: +1 801 585 1640, +1 801 581 4148 X-URL: http://www.math.utah.edu/~beebe Subject: Re: Unix MM... In-Reply-To: Message-ID: X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0 (mail.math.utah.edu [155.101.98.135]); Tue, 12 Jun 2007 12:54:51 -0600 (MDT) ReSent-Date: Tue, 12 Jun 2007 17:33:42 -0700 (PDT) ReSent-From: TOPS-20 List Moderator ReSent-To: TOPS-20 Distribution: ; ReSent-Subject: Re: Unix MM... ReSent-Message-ID: William "Chops" Westfield asks >> What the status and current location of the latest version of the >> C (Columbia, originally) MM for unix? Frank da Cruz will no doubt respond too. At Utah, we've been using mm-ccmd-0.95-20060109 for the last 18 months; this is an autoconfigurized version of mm that builds on many Unix platforms (Sun Solaris IA-32 and SPARC, SGI IRIX MIPS, DEC OSF/1 Alpha, GNU/Linux (many architectures), ...). There are still three outstanding issues with it that I've not had time to resolve: (1) A "move" command in the 64-bit GNU/Linux versions (notably, IA-64 and AMD64) causes a core dump; I therefore avoid using mm on those platforms. (2) A paste of text containing Unicode characters into an mm session running in a terminal window causes a core dump. This can be avoided by first running an editor inside mm, then doing the paste into the editor window. (3) The code does not build successfully on new Mac OS X Intel-based system (it does on old Mac PowerPC systems). Although these are serious problems, my main host where I read mail is a Solaris SPARC system, and most of our users are in the same position, so I've not been inclined to spend the debugging time to resolve them. There is a fourth problem that is seen very rarely, and thus, is hard to debug: returning from the editor to mm may return an empty message buffer. This seems not to happen if the "edit" command is used to invoke the editor, but does sometimes happen if Ctl-e is used to get there instead. We've done a lot of hair pulling over this one in multiple debug sessions, but have not solved it, and it has been there for many years. We believe that it is caused by a timing race in the interrupt handler. You can find a copy of our latest mm here (identical filesystem locations): http://www.math.utah.edu/pub/mm/mm-ccmd-0.95.20051208.autoconf.tar.gz ftp://ftp.math.utah.edu/pub/mm/mm-ccmd-0.95.20051208.autoconf.tar.gz ------------------------------------------------------------------------------- - 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/ - ------------------------------------------------------------------------------- 12-Jun-2007 17:56:34-PDT,3888;000000000000 Return-Path: Received: from pangtzu.panda.com ([206.124.149.117]) by lingling.panda.com with TCP/SMTP; Tue, 12 Jun 2007 17:34:11 -0700 (PDT) X-Return-Path: X-Received: from mail.math.utah.edu ([155.101.98.135]) by lingling.panda.com with TCP/SMTP; Tue, 12 Jun 2007 17:07:57 -0700 (PDT) X-Received: from sunblast.math.utah.edu (sunblast.math.utah.edu [155.101.96.165]) by mail.math.utah.edu (8.13.6/8.13.6) with ESMTP id l5D07YpL029718; Tue, 12 Jun 2007 18:07:34 -0600 (MDT) X-Received: from sunblast.math.utah.edu (localhost [127.0.0.1]) by sunblast.math.utah.edu (8.13.6/8.13.6) with ESMTP id l5D07XMO004896; Tue, 12 Jun 2007 18:07:33 -0600 (MDT) X-Received: (from beebe@localhost) by sunblast.math.utah.edu (8.13.6/8.13.6/Submit) id l5D07X7A004894; Tue, 12 Jun 2007 18:07:33 -0600 (MDT) Date: Tue, 12 Jun 2007 18:07:33 -0600 (MDT) From: "Nelson H. F. Beebe" To: TOPS-20@Lingling.Panda.COM 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] Bliss require-file problem Message-ID: X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0 (mail.math.utah.edu [155.101.98.135]); Tue, 12 Jun 2007 18:07:34 -0600 (MDT) ReSent-Date: Tue, 12 Jun 2007 17:33:57 -0700 (PDT) ReSent-From: TOPS-20 List Moderator ReSent-To: TOPS-20 Distribution: ; ReSent-Subject: [tops-20] Bliss require-file problem ReSent-Message-ID: Some time ago, I attempted to write a small Bliss program on TOPS-20 with the Panda distribution on the KLH10, but could not find a suitable I/O library. Recently, a correspondent on another list reported a successful hello-world example in Bliss on TOPS-10, and pointed me to the file tutio.r36 available at http://pdp-10.trailing-edge.com/bb-j939f-bm/01/bliss/tutio.r36 I fetched that file, but still get compilation failure: @type hi.bli MODULE MAIN= BEGIN REQUIRE 'tutio'; TTY_PUT_QUO('Hello world from Bliss.'); END ELUDOM @compile hi.bli BLISS: HI.BLI 3 REQUIRE 'tutio'; LINE: 2 ......^ ?BLSFNF File not found ... Both hi.bli and tutio.r36 reside in my login directory. If I change the name 'tutio' to 'tutio.r36', and retry, I get this: @compile hi.bli BLISS: HI.BLI 4 %IF NOT %BLISS (BLISS36) %BLSUID Undeclared identifier; ID: BLISS % 6 %ERROR ('? To be used only with BLISS-36'); %BLSUID Undeclared identifier; ID: BLISS36 ... What logical name defines the file search path used by the Bliss compiler to find require-files? Is there a convention for default (omitted) extensions of require-files? Has anyone on this list had success with Bliss on TOPS-20 on current platforms? If so, what is the magic incantation? ------------------------------------------------------------------------------- - 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/ - ------------------------------------------------------------------------------- 12-Jun-2007 18:02:18-PDT,3888;000000000000 Return-Path: Received: from pangtzu.panda.com ([206.124.149.117]) by lingling.panda.com with TCP/SMTP; Tue, 12 Jun 2007 17:34:54 -0700 (PDT) X-Return-Path: X-Received: from mail.math.utah.edu ([155.101.98.135]) by lingling.panda.com with TCP/SMTP; Tue, 12 Jun 2007 17:07:57 -0700 (PDT) X-Received: from sunblast.math.utah.edu (sunblast.math.utah.edu [155.101.96.165]) by mail.math.utah.edu (8.13.6/8.13.6) with ESMTP id l5D07YpL029718; Tue, 12 Jun 2007 18:07:34 -0600 (MDT) X-Received: from sunblast.math.utah.edu (localhost [127.0.0.1]) by sunblast.math.utah.edu (8.13.6/8.13.6) with ESMTP id l5D07XMO004896; Tue, 12 Jun 2007 18:07:33 -0600 (MDT) X-Received: (from beebe@localhost) by sunblast.math.utah.edu (8.13.6/8.13.6/Submit) id l5D07X7A004894; Tue, 12 Jun 2007 18:07:33 -0600 (MDT) Date: Tue, 12 Jun 2007 18:07:33 -0600 (MDT) From: "Nelson H. F. Beebe" To: TOPS-20@Lingling.Panda.COM 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] Bliss require-file problem Message-ID: X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0 (mail.math.utah.edu [155.101.98.135]); Tue, 12 Jun 2007 18:07:34 -0600 (MDT) ReSent-Date: Tue, 12 Jun 2007 17:34:43 -0700 (PDT) ReSent-From: TOPS-20 List Moderator ReSent-To: TOPS-20 Distribution: ; ReSent-Subject: [tops-20] Bliss require-file problem ReSent-Message-ID: Some time ago, I attempted to write a small Bliss program on TOPS-20 with the Panda distribution on the KLH10, but could not find a suitable I/O library. Recently, a correspondent on another list reported a successful hello-world example in Bliss on TOPS-10, and pointed me to the file tutio.r36 available at http://pdp-10.trailing-edge.com/bb-j939f-bm/01/bliss/tutio.r36 I fetched that file, but still get compilation failure: @type hi.bli MODULE MAIN= BEGIN REQUIRE 'tutio'; TTY_PUT_QUO('Hello world from Bliss.'); END ELUDOM @compile hi.bli BLISS: HI.BLI 3 REQUIRE 'tutio'; LINE: 2 ......^ ?BLSFNF File not found ... Both hi.bli and tutio.r36 reside in my login directory. If I change the name 'tutio' to 'tutio.r36', and retry, I get this: @compile hi.bli BLISS: HI.BLI 4 %IF NOT %BLISS (BLISS36) %BLSUID Undeclared identifier; ID: BLISS % 6 %ERROR ('? To be used only with BLISS-36'); %BLSUID Undeclared identifier; ID: BLISS36 ... What logical name defines the file search path used by the Bliss compiler to find require-files? Is there a convention for default (omitted) extensions of require-files? Has anyone on this list had success with Bliss on TOPS-20 on current platforms? If so, what is the magic incantation? ------------------------------------------------------------------------------- - 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-Jun-2007 20:20:33-PDT,3905;000000000000 Return-Path: Received: from pangtzu.panda.com ([206.124.149.117]) by lingling.panda.com with TCP/SMTP; Wed, 13 Jun 2007 20:14:04 -0700 (PDT) X-Return-Path: X-Received: from pangtzu.panda.com ([206.124.149.117]) by lingling.panda.com with TCP/SMTP; Wed, 13 Jun 2007 20:13:19 -0700 (PDT) X-Return-Path: X-Received: from sesame.cc.columbia.edu ([128.59.59.56]) by lingling.panda.com with TCP/SMTP; Wed, 13 Jun 2007 08:05:36 -0700 (PDT) X-Received: from sesame.cc.columbia.edu (localhost [127.0.0.1]) by sesame.cc.columbia.edu (8.13.7/8.13.6) with ESMTP id l5DF5Uh1025593; Wed, 13 Jun 2007 11:05:30 -0400 (EDT) X-Received: (from fdc@localhost) by sesame.cc.columbia.edu (8.13.7/8.12.8/Submit) id l5DF5PYb025591; Wed, 13 Jun 2007 11:05:25 -0400 (EDT) Date: Wed, 13 Jun 2007 11:05:25 EDT From: Frank da Cruz To: "Nelson H. F. Beebe" Cc: TOPS-20 List Moderator Subject: Re: Unix MM... In-Reply-To: Message-ID: X-ReSent-Date: Wed, 13 Jun 2007 20:13:12 -0700 (PDT) X-ReSent-From: Mark Crispin X-ReSent-To: TOPS-20 Hackers and Yackers X-ReSent-Subject: Re: Unix MM... X-ReSent-Message-ID: ReSent-Date: Wed, 13 Jun 2007 20:13:55 -0700 (PDT) ReSent-From: TOPS-20 List Moderator ReSent-To: TOPS-20 Distribution: ; ReSent-Subject: Re: Unix MM... ReSent-Message-ID: > William "Chops" Westfield asks > > >> What the status and current location of the latest version of the > >> C (Columbia, originally) MM for unix? > > Frank da Cruz will no doubt respond too. > Yup. As noted, the latest (Dec 2005) Columbia version is here: http://www.columbia.edu/~fdc/mm/ > At Utah, we've been using mm-ccmd-0.95-20060109 for the last 18 > months; this is an autoconfigurized version of mm that builds on many > Unix platforms (Sun Solaris IA-32 and SPARC, SGI IRIX MIPS, DEC OSF/1 > Alpha, GNU/Linux (many architectures), ...). > This one is just a wee bit behind my version. The Columbia and Utah versions diverged rather dramatically around the turn of the millenium; I did a lot of work on bugs and features not knowing that Nelson also doing a lot of work on portability and modernization. Finally in December 2005 I did my best to reconcile the two versions, and the result is evidently the one at Nelson's place: http://www.math.utah.edu/pub/mm/mm-ccmd-0.95.20051208.autoconf.tar.gz ftp://ftp.math.utah.edu/pub/mm/mm-ccmd-0.95.20051208.autoconf.tar.gz However, for some reason it seems we got out of sync again; I did a few minor things since then: fixed some bugs, some code cleanups, copyright notice updates, I restored the mail-file locking mechanism that Nelson took out (this is conditionally compiled) because we need it here. Some filenames were distinct only in casing, e.g. foo.h and foo.H, which doesn't work on case-insensitive file systems; I changed the names where needed, e.g. to foo.hh. I added a command QDELETE (QD) that is the same as DELETE -- people who read a lot of spam through "more" or "less" will understand :-) The differences between Nelson's and my versions are here: ftp://kermit.columbia.edu/kermit/mm/test/mm.diff ftp://kermit.columbia.edu/kermit/mm/test/ccmd.diff ftp://kermit.columbia.edu/kermit/mm/test/notes-fdc.txt (edit history) or by http: http://kermit.columbia.edu/ftp/mm/test/mm.diff http://kermit.columbia.edu/ftp/mm/test/ccmd.diff http://kermit.columbia.edu/ftp/mm/test/notes-fdc.txt (edit history) - Frank 16-Jun-2007 12:46:15-PDT,3595;000000000000 Return-Path: Received: from pangtzu.panda.com ([206.124.149.117]) by lingling.panda.com with TCP/SMTP; Sat, 16 Jun 2007 12:39:49 -0700 (PDT) X-Return-Path: X-Received: from smtp02.lnh.mail.rcn.net ([207.172.157.102]) by lingling.panda.com with TCP/SMTP; Sat, 16 Jun 2007 12:17:42 -0700 (PDT) X-Received: from mr08.lnh.mail.rcn.net ([207.172.157.28]) by smtp02.lnh.mail.rcn.net with ESMTP; 16 Jun 2007 15:17:32 -0400 X-Received: from smtp01.lnh.mail.rcn.net (smtp01.lnh.mail.rcn.net [207.172.4.11]) by mr08.lnh.mail.rcn.net (MOS 3.8.3-GA) with ESMTP id IUF92950; Sat, 16 Jun 2007 15:17:27 -0400 (EDT) X-Received: from c-76-19-132-186.hsd1.ma.comcast.net (HELO [127.0.0.1]) ([76.19.132.186]) by smtp01.lnh.mail.rcn.net with ESMTP; 16 Jun 2007 15:17:24 -0400 Message-ID: <4674373D.5000705@RCN.Com> Date: Sat, 16 Jun 2007 15:17:17 -0400 From: "Alan H. Martin" User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: "Nelson H. F. Beebe" CC: TOPS-20@Lingling.Panda.COM Subject: Re: [tops-20] Bliss require-file problem References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Junkmail-Whitelist: YES (by domain whitelist at mr08.lnh.mail.rcn.net) ReSent-Date: Sat, 16 Jun 2007 12:39:41 -0700 (PDT) ReSent-From: TOPS-20 List Moderator ReSent-To: TOPS-20 Distribution: ; ReSent-Subject: Re: [tops-20] Bliss require-file problem ReSent-Message-ID: Nelson H. F. Beebe wrote: > @type hi.bli > MODULE MAIN= > BEGIN > REQUIRE 'tutio'; ... > @compile hi.bli > BLISS: HI.BLI > 3 REQUIRE 'tutio'; > LINE: 2 ......^ > ?BLSFNF File not found > > ... > > Both hi.bli and tutio.r36 reside in my login directory. > > If I change the name 'tutio' to 'tutio.r36', and retry, I get this: > > @compile hi.bli > BLISS: HI.BLI > 4 %IF NOT %BLISS (BLISS36) > > %BLSUID Undeclared identifier; ID: BLISS > > % 6 %ERROR ('? To be used only with BLISS-36'); > > %BLSUID Undeclared identifier; ID: BLISS36 I'm convinced that you invoked BLISS-10 with that COMPILE command (see below). > What logical name defines the file search path used by the Bliss > compiler to find require-files? I don't recall one, and I don't see one in the Jan-80 V2 _BLISS-36 User's Guide_. > Is there a convention for default (omitted) extensions of > require-files? For BLISS-36, the REQUIRE lookup sequence is: .R36, .REQ, .B36, .BLI > Has anyone on this list had success with Bliss on TOPS-20 on current > platforms? If so, what is the magic incantation? " CHAPTER 1 TOPS-20 OPERATING SYSTEM 1.1 COMPILING A BLISS PROGRAM ... @BLISS BLISS>ALPHA BLISS>/EXIT @EXECUTE ALPHA ... NOTE The TOPS-20 EXEC does not support BLISS-36 in LOAD-class commands. Therefore, the commands: @EXECUTE ALPHA.BLI @LOAD ALPHA.BLI will not compiler ALPHA as a BILSS-36 module. However, they will attempt to use BLISS-10 to compile ALPHA.BLI ... " Hope this helps, /AHM -- Alan Howard Martin AMartin.MA.UltraNet@RCN.Com 16-Jun-2007 12:57:19-PDT,1541;000000000000 Return-Path: Received: from pangtzu.panda.com ([206.124.149.117]) by lingling.panda.com with TCP/SMTP; Sat, 16 Jun 2007 12:51:31 -0700 (PDT) X-Return-Path: X-Received: from pangtzu.panda.com ([206.124.149.117]) by lingling.panda.com with TCP/SMTP; Sat, 16 Jun 2007 12:50:17 -0700 (PDT) Date: Sat, 16 Jun 2007 12:50:12 -0700 (PDT) From: Mark Crispin Sender: mrc@pangtzu.panda.com To: "Alan H. Martin" cc: "Nelson H. F. Beebe" , TOPS-20@Lingling.Panda.COM Subject: Re: [tops-20] Bliss require-file problem In-Reply-To: <4674373D.5000705@RCN.Com> Message-ID: References: <4674373D.5000705@RCN.Com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=us-ascii ReSent-Date: Sat, 16 Jun 2007 12:51:23 -0700 (PDT) ReSent-From: TOPS-20 List Moderator ReSent-To: TOPS-20 Distribution: ; ReSent-Subject: Re: [tops-20] Bliss require-file problem ReSent-Message-ID: For what it's worth, modern EXECs have the /36-BLISS (vs. /10-BLISS) compile switch. I haven't checked the source, but if I remember correctly an extension of .BLI implies BLISS-10, wherease an extension of .B36 implies BLISS-36. -- Mark -- http://panda.com/tops-20 TOPS-20: a great improvement over its successors 19-Jun-2007 19:54:26-PDT,3233;000000000000 Return-Path: Received: from pangtzu.panda.com ([206.124.149.117]) by lingling.panda.com with TCP/SMTP; Tue, 19 Jun 2007 19:47:50 -0700 (PDT) X-Return-Path: X-Received: from mail.ultimate.com ([199.201.145.150]) by lingling.panda.com with TCP/SMTP; Tue, 19 Jun 2007 14:32:08 -0700 (PDT) X-Received: from ultimate.com (localhost [127.0.0.1]) by mail.ultimate.com (8.13.8/8.13.8) with ESMTP id l5JLW1TI030907 for ; Tue, 19 Jun 2007 17:32:01 -0400 (EDT) (envelope-from phil@ultimate.com) X-Received: (from phil@localhost) by ultimate.com (8.13.8/8.13.8/Submit) id l5JLW1lU030906 for TOPS-20@Lingling.Panda.COM; Tue, 19 Jun 2007 17:32:01 -0400 (EDT) (envelope-from phil) Date: Tue, 19 Jun 2007 17:32:01 -0400 (EDT) From: Phil Budne Message-Id: <200706192132.l5JLW1lU030906@ultimate.com> To: TOPS-20@Lingling.Panda.COM Subject: Fwd: Anyone got a working DEC10 (or a running emulator?) ReSent-Date: Tue, 19 Jun 2007 19:47:42 -0700 (PDT) ReSent-From: TOPS-20 List Moderator ReSent-To: TOPS-20 Distribution: ; ReSent-Subject: Fwd: Anyone got a working DEC10 (or a running emulator?) ReSent-Message-ID: > Date: Tue, 19 Jun 2007 15:49:44 -0500 > From: "Graham Toal" > To: cctech@classiccmp.org > Subject: Anyone got a working DEC10 (or a running emulator?) > Reply-To: "General Discussion: On-Topic and Off-Topic Posts" > > List-Id: "General Discussion: On-Topic and Off-Topic Posts" > > List-Unsubscribe: , > > List-Archive: > List-Post: > List-Help: > List-Subscribe: , > > > A friend at Edinburgh recovered some binaries, a bit of source code, > and a fair bit > of documentation for the Imp language running on the Dec 10. > > We're holding a reunion and historical conference in Edinburgh in a couple > of weeks - it occurred to me it might be fun if I could show the folks back > home that the old code was running again... > > Does anyone have a working Dec10, whether a physical or a virtual one? > > Our recovered code is here: http://history.dcs.ed.ac.uk/archive/dec10/imp/ > > (also if you pop up a directory there's some more stuff, but not of as > immediate interest as getting the compiler to run again!) > > If you could download any of these binaries and give them a try I'ld > be very interested to see the results. I think this ran under tops10/tops20 > and the precise version of CPU shouldn't be critical I don't think. > > A trivial "hello world" imp program might be: > > %begin > print string("Hello world!") > newline > %end %of %program > > If anyone can get it running, I'll announce it and credit you at the > conference :-) > > > Graham > 24-Jun-2007 11:26:35-PDT,8268;000000000000 Return-Path: Received: from pangtzu.panda.com ([206.124.149.117]) by lingling.panda.com with TCP/SMTP; Sun, 24 Jun 2007 11:20:17 -0700 (PDT) X-Return-Path: X-Received: from omr6.networksolutionsemail.com ([205.178.146.56]) by lingling.panda.com with TCP/SMTP; Sun, 24 Jun 2007 10:03:09 -0700 (PDT) X-Received: from mail.networksolutionsemail.com (ns-omr6.mgt.netsol.com [10.49.6.69]) by omr6.networksolutionsemail.com (8.13.6/8.13.6) with SMTP id l5OH33X1020226 for ; Sun, 24 Jun 2007 13:03:03 -0400 X-Received: (qmail 2772 invoked by uid 78); 24 Jun 2007 17:03:03 -0000 X-Received: from unknown (HELO XPS140) (74.192.171.58) by ns-omr6.lb.hosting.dc2.netsol.com with SMTP; 24 Jun 2007 17:03:03 -0000 From: "Paul Raulerson" To: Subject: Conferencing software? Date: Sun, 24 Jun 2007 12:03:03 -0500 Message-ID: <000301c7b681$87727490$96575db0$@com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0004_01C7B657.9E9C6C90" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ace2gYb9o6ckJOm+QpyJ6h1zjf83yQ== Content-Language: en-us ReSent-Date: Sun, 24 Jun 2007 11:20:08 -0700 (PDT) ReSent-From: TOPS-20 List Moderator ReSent-To: TOPS-20 Distribution: ; ReSent-Subject: Conferencing software? ReSent-Message-ID: This is a multipart message in MIME format. ------=_NextPart_000_0004_01C7B657.9E9C6C90 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Does anyone know of any conferencing software on TOPS-20? Or if not, = anyone have any opinions they want to share and discuss?=20 =20 I=92m thinking of a hobby project something along these lines:=20 =20 Windows/Mac TOPS/20 Panda Processing to handle conference Front-end GUI =DF TCPIP =E0 Unpriv account =DF =E0 and users = and so forth Program login =20 Since both ends of the connection would be absolutely controlled, it = could have the best of both worlds, And be tailored to do just about what anyone wants it to do.=20 =20 The fun part is, I know how to do this under UNIX or Linux, and can do = the front-ends and such without any trouble, but doing the backend on = TOPS-20 =96 ah! Now that is a challenge!! Older compilers and a wheelbarrow full of ignorance! Sounds like an excellent project to take on. And a fun one = that can be shared too, if anyone is interested in a group project.=20 Does not necessarily have to be a conference system, could just as well = be a system to interface TOPS-20 to X10 appliance controllers =96 the = paradigm works just as well for multiple solutions. For example, I have a small mainframe here that, as a side job, records the local rainfall, = temperature, sunshine, and such and so forth. It is interfaced to the real world = through just such an arrangement as above, and runs some software I write to = analyze and predict the local climate. Not sure if that would work on TOPS-20 = (it uses some math libraries that may not be available) but the same idea.=20 =20 Any ideas, suggestions, or pointers are welcome.=20 =20 Yours, -Paul =20 =20 ------=_NextPart_000_0004_01C7B657.9E9C6C90 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Does anyone know of any conferencing software on = TOPS-20? Or if not, anyone have any opinions they want to share and discuss? =

 

I’m thinking of a hobby project something = along these lines:

 

Windows/Mac = =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0TOPS/20 Panda=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =A0=A0=A0=A0=A0=A0Processing to handle conference

Front-end GUI=A0 =DF=A0 TCPIP =E0=A0 =A0=A0Unpriv = account=A0=A0 =DF =E0 =A0=A0and users and so forth

Program = =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0login

 

Since both ends of the connection would be = absolutely controlled, it could have the best of both worlds,

And be tailored to do just about what anyone wants = it to do.

 

The fun part is, I know how to do this under UNIX = or Linux, and can do the front-ends and such without any trouble, but doing the = backend on TOPS-20 – ah! Now that is a challenge!! Older compilers and a = wheelbarrow full of ignorance! Sounds like an excellent project to take on. =A0And a = fun one that can be shared too, if anyone is interested in a group project. =

Does not necessarily have to be a conference = system, could just as well be a system to interface TOPS-20 to X10 appliance = controllers – the paradigm works just as well for multiple solutions. For example, I = have a small mainframe here that, as a side job, records the local rainfall, temperature, sunshine, and such and so forth. It is interfaced to the = real world through just such an arrangement as above, and runs some software = I write to analyze and predict the local climate. Not sure if that would work on TOPS-20 (it uses some math libraries that may not be available) but the = same idea.

 

Any ideas, suggestions, or pointers are welcome. =

 

Yours,

-Paul

 

 

------=_NextPart_000_0004_01C7B657.9E9C6C90-- 24-Jun-2007 11:32:20-PDT,4192;000000000000 Return-Path: Received: from pangtzu.panda.com ([206.124.149.117]) by lingling.panda.com with TCP/SMTP; Sun, 24 Jun 2007 11:20:36 -0700 (PDT) X-Return-Path: X-Received: from omr4.networksolutionsemail.com ([205.178.146.54]) by lingling.panda.com with TCP/SMTP; Sun, 24 Jun 2007 11:16:55 -0700 (PDT) X-Received: from mail.networksolutionsemail.com (ns-omr4.mgt.netsol.com [10.49.6.67]) by omr4.networksolutionsemail.com (8.13.6/8.13.6) with SMTP id l5OIGngO001968 for ; Sun, 24 Jun 2007 14:16:49 -0400 X-Received: (qmail 13359 invoked by uid 78); 24 Jun 2007 18:16:49 -0000 X-Received: from unknown (HELO XPS140) (74.192.171.58) by ns-omr4.lb.hosting.dc2.netsol.com with SMTP; 24 Jun 2007 18:16:49 -0000 From: "Paul Raulerson" To: References: In-Reply-To: Subject: Tapes? Date: Sun, 24 Jun 2007 13:16:49 -0500 Message-ID: <000001c7b68b$d57bacb0$80730610$@com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C7B661.ECA5A4B0" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ace2gYb9o6ckJOm+QpyJ6h1zjf83yQAChXAQ Content-Language: en-us ReSent-Date: Sun, 24 Jun 2007 11:20:27 -0700 (PDT) ReSent-From: TOPS-20 List Moderator ReSent-To: TOPS-20 Distribution: ; ReSent-Subject: Tapes? ReSent-Message-ID: This is a multipart message in MIME format. ------=_NextPart_000_0001_01C7B661.ECA5A4B0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Will the KL Emulator allow Tops to talk to a real tape drive? As in a SCSI 4mm or something? Or will it only talk to emulated tape files on DISK? -Paul ------=_NextPart_000_0001_01C7B661.ECA5A4B0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Will the KL Emulator = allow Tops to talk to a real tape drive? As in a SCSI 4mm or something?  Or = will it only talk to emulated tape files on DISK?

 

-Paul

 

------=_NextPart_000_0001_01C7B661.ECA5A4B0-- 24-Jun-2007 12:29:01-PDT,1722;000000000000 Return-Path: Received: from pangtzu.panda.com ([206.124.149.117]) by lingling.panda.com with TCP/SMTP; Sun, 24 Jun 2007 12:23:05 -0700 (PDT) X-Return-Path: X-Received: from pangtzu.panda.com ([206.124.149.117]) by lingling.panda.com with TCP/SMTP; Sun, 24 Jun 2007 11:46:15 -0700 (PDT) Date: Sun, 24 Jun 2007 11:46:10 -0700 (PDT) From: Mark Crispin Sender: mrc@pangtzu.panda.com To: Paul Raulerson cc: tops-20@lingling.panda.com Subject: Re: Tapes? In-Reply-To: <000001c7b68b$d57bacb0$80730610$@com> Message-ID: References: <000001c7b68b$d57bacb0$80730610$@com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=us-ascii ReSent-Date: Sun, 24 Jun 2007 12:22:55 -0700 (PDT) ReSent-From: TOPS-20 List Moderator ReSent-To: TOPS-20 Distribution: ; ReSent-Subject: Re: Tapes? ReSent-Message-ID: On Sun, 24 Jun 2007, Paul Raulerson wrote: > Will the KL Emulator allow Tops to talk to a real tape drive? As in a SCSI > 4mm or something? Or will it only talk to emulated tape files on DISK? It should be possible to talk to a physical tape drive; although few people use such things any more. TOPS-20, of course, assumes that all tapes are 9-track 1/2" reels. By the way, please reconfigure your Outlook so that it just sends plain text (and in particular doesn't sent HTML mail). For many people on this list, HTML mail is an annoyance. Thanks! -- Mark -- http://panda.com/tops-20 TOPS-20: a great improvement over its successors 25-Jun-2007 20:36:42-PDT,3597;000000000000 Return-Path: Received: from pangtzu.panda.com ([206.124.149.117]) by lingling.panda.com with TCP/SMTP; Mon, 25 Jun 2007 20:30:40 -0700 (PDT) X-Return-Path: X-Received: from mail.math.utah.edu ([155.101.98.135]) by lingling.panda.com with TCP/SMTP; Mon, 25 Jun 2007 18:26:49 -0700 (PDT) X-Received: from psi.math.utah.edu (psi.math.utah.edu [155.101.96.19]) by mail.math.utah.edu (8.13.6/8.13.6) with ESMTP id l5Q1QgfT007274; Mon, 25 Jun 2007 19:26:42 -0600 (MDT) X-Received: from psi.math.utah.edu (localhost [127.0.0.1]) by psi.math.utah.edu (8.13.6/8.13.6) with ESMTP id l5Q1Qgro029365; Mon, 25 Jun 2007 19:26:42 -0600 (MDT) X-Received: (from beebe@localhost) by psi.math.utah.edu (8.13.6/8.13.6/Submit) id l5Q1Qgx1029363; Mon, 25 Jun 2007 19:26:42 -0600 (MDT) Date: Mon, 25 Jun 2007 19:26:42 -0600 (MDT) From: "Nelson H. F. Beebe" To: TOPS-20@Lingling.Panda.COM 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: Re: [tops-20] Bliss require-file problem Message-ID: X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0 (mail.math.utah.edu [155.101.98.135]); Mon, 25 Jun 2007 19:26:42 -0600 (MDT) ReSent-Date: Mon, 25 Jun 2007 20:29:49 -0700 (PDT) ReSent-From: TOPS-20 List Moderator ReSent-To: TOPS-20 Distribution: ; ReSent-Subject: Re: [tops-20] Bliss require-file problem ReSent-Message-ID: Thanks to list readers for their comments to my posting of 12-Jun-2007 about running Bliss; I've been out-of-town for the past 10 days, so this reply is delayed. I finally got a slightly more complex example to work, based on sample code in the Wikipedia article on Bliss at http://en.wikipedia.org/wiki/BLISS_%28programming_language%29 Here is the source file @type hello.b36 MODULE TEST(MAIN = HELLO) = BEGIN FORWARD ROUTINE HELLO; ROUTINE HELLO = BEGIN REQUIRE 'TUTIO'; TTY_PUT_QUO('Hello world from Bliss.'); END; END ELUDOM and its compilation and execution: @bliss hello ; File: TOPS20:HELLO.B36.2 INFO#212 L1:0247 Null expression appears in value-required context ; Information: 1 ; Warnings: 0 ; Errors: 0 ; Size: 75 code + 2110 data words ; Run Time: 00:00.1 ; Elapsed Time: 00:00.0 ; Lines/CPU Min: 241935 ; Lexemes/CPU-Min:1194193 ; Memory Used: 10 pages ; Compilation Complete @exec hello.rel LINK: Loading [LNKXCT TEST execution] Hello world from Bliss. The tutio file that provides I/O support is named tutio.r36 on my system, and resides in the same directory as hello.b36. ------------------------------------------------------------------------------- - 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/ - ------------------------------------------------------------------------------- 27-Jun-2007 12:08:10-PDT,3496;000000000000 Return-Path: Received: from pangtzu.panda.com ([206.124.149.117]) by lingling.panda.com with TCP/SMTP; Wed, 27 Jun 2007 12:02:08 -0700 (PDT) X-Return-Path: X-Received: from mail.math.utah.edu ([155.101.98.135]) by lingling.panda.com with TCP/SMTP; Wed, 27 Jun 2007 11:18:04 -0700 (PDT) X-Received: from psi.math.utah.edu (psi.math.utah.edu [155.101.96.19]) by mail.math.utah.edu (8.13.6/8.13.6) with ESMTP id l5RIHvgP024123; Wed, 27 Jun 2007 12:17:57 -0600 (MDT) X-Received: from psi.math.utah.edu (localhost [127.0.0.1]) by psi.math.utah.edu (8.13.6/8.13.6) with ESMTP id l5RIHvDF016333; Wed, 27 Jun 2007 12:17:57 -0600 (MDT) X-Received: (from beebe@localhost) by psi.math.utah.edu (8.13.6/8.13.6/Submit) id l5RIHvgc016331; Wed, 27 Jun 2007 12:17:57 -0600 (MDT) Date: Wed, 27 Jun 2007 12:17:57 -0600 (MDT) From: "Nelson H. F. Beebe" To: TOPS-20@Lingling.Panda.COM 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] Bliss and floating-point arithmetic Message-ID: X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0 (mail.math.utah.edu [155.101.98.135]); Wed, 27 Jun 2007 12:17:57 -0600 (MDT) ReSent-Date: Wed, 27 Jun 2007 12:01:58 -0700 (PDT) ReSent-From: TOPS-20 List Moderator ReSent-To: TOPS-20 Distribution: ; ReSent-Subject: [tops-20] Bliss and floating-point arithmetic ReSent-Message-ID: I've just completed an interesting little project to implement in Bliss-36 the next step beyond printing "Hello, World": computation and reporting of the Fibonacci sequence, and the ratios between successive terms of the sequence, which converge to the famous Golden Ratio, (1 + sqrt(5))/2 = 1.618_033_988_749_894_848_204_586_834_365_638... I've added two programs to my Web page on the problem at http://www.math.utah.edu/~beebe/software/java/fibonacci/ Search for "Bliss", which lead to the code, its output, and later, to commentary on the language. Because floating-point is not a data type that Bliss knows much about, its use requires function calls for arithmetic operations, and awkward data access for double-precision data. The programs contain the messy details. The difficulty of programming this simple problem in Bliss shows why Brian Reid reported that it took him about a year to develop a suitable underlying library in Bliss that eventually made it possible to write the Scribe typesetting system. Scribe strongly influenced the design of LaTeX and BibTeX, and to a lesser extent, TeX itself. ------------------------------------------------------------------------------- - 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/ - ------------------------------------------------------------------------------- 19-Jul-2007 17:00:26-PDT,2065;000000000000 Return-Path: Received: from pangtzu.panda.com ([206.124.149.117]) by lingling.panda.com with TCP/SMTP; Thu, 19 Jul 2007 16:54:05 -0700 (PDT) X-Return-Path: X-Received: from mta5.srv.hcvlny.cv.net ([167.206.4.200]) by lingling.panda.com with TCP/SMTP; Wed, 18 Jul 2007 18:50:44 -0700 (PDT) X-Received: from [192.168.1.7] (ool-45720130.dyn.optonline.net [69.114.1.48]) by mta5.srv.hcvlny.cv.net (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTP id <0JLE008PML4E4WN0@mta5.srv.hcvlny.cv.net> for TOPS-20@Lingling.Panda.COM; Wed, 18 Jul 2007 21:50:38 -0400 (EDT) Date: Wed, 18 Jul 2007 21:50:37 -0400 From: Thomas DeBellis Subject: Extended Address Limit To: TOPS-20@Lingling.Panda.COM Message-id: <469EC36D.7040601@optonline.net> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) ReSent-Date: Thu, 19 Jul 2007 16:53:48 -0700 (PDT) ReSent-From: TOPS-20 List Moderator ReSent-To: TOPS-20 Distribution: ; ReSent-Subject: Extended Address Limit ReSent-Message-ID: Does anybody know if there is a way to derive what the virtual address limit of a particular machine would be? For some reason, I thought that the biggest address that XMOVEI would generate on a KL would be 37,,777777 and that the largest I would get on a Toad would be 7777,,777777. Having finally finished the 36 bit packing/unpacking/buffering code, I am starting on paged file structures and was looking to write some address checking code. For now, the work-around is to use MRC's winning GETCPU routine to discover the processor type and then look that up in a table. Once I am done with paged file structures, I will have a release candidate for the extended mode FTP server. 6-Aug-2007 22:15:12-PDT,1790;000000000000 Return-Path: Received: from pangtzu.panda.com ([206.124.149.117]) by lingling.panda.com with TCP/SMTP; Mon, 6 Aug 2007 22:06:45 -0700 (PDT) X-Return-Path: X-Received: from mta1.srv.hcvlny.cv.net ([167.206.4.196]) by lingling.panda.com with TCP/SMTP; Mon, 6 Aug 2007 21:09:58 -0700 (PDT) X-Received: from Whitestar (ool-4577982f.dyn.optonline.net [69.119.152.47]) by mta1.srv.hcvlny.cv.net (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with SMTP id <0JMD000Q0Y87YCB0@mta1.srv.hcvlny.cv.net> for TOPS-20@Lingling.Panda.COM; Tue, 07 Aug 2007 00:09:43 -0400 (EDT) Date: Tue, 07 Aug 2007 00:09:38 -0700 From: Mike Ross Subject: RSX-20F To: TOPS-20@Lingling.Panda.COM Message-id: MIME-version: 1.0 X-Mailer: Forte Agent 1.93/32.576 English (American) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT ReSent-Date: Mon, 6 Aug 2007 22:06:34 -0700 (PDT) ReSent-From: TOPS-20 List Moderator ReSent-To: TOPS-20 Distribution: ; ReSent-Subject: RSX-20F ReSent-Message-ID: Guys, Would any of you be willing to make (or give, if you have any spare) a pair of RX02 floppies with bootable RSX-20F on them for me? I'm at the stage with my KL hardware restoration where I now desperately (as in, I'll pay for overnight Fedex!) need them... I do have a whole bunch of KL front-end stuff, but it's all on DECtape... Whilst on the subject, if anyone has a (hiss, spit) VAX 11/780 console floppy I could use one of them too... Thanks! Mike -- http://www.corestore.org 'As I walk along these shores I am the history within' 6-Aug-2007 22:55:39-PDT,1635;000000000000 Return-Path: Received: from pangtzu.panda.com ([206.124.149.117]) by lingling.panda.com with TCP/SMTP; Mon, 6 Aug 2007 22:47:45 -0700 (PDT) X-Return-Path: X-Received: from pangtzu.panda.com ([206.124.149.117]) by lingling.panda.com with TCP/SMTP; Mon, 6 Aug 2007 22:47:26 -0700 (PDT) Date: Mon, 6 Aug 2007 22:47:21 -0700 (PDT) From: Mark Crispin Sender: mrc@pangtzu.panda.com To: Mike Ross cc: TOPS-20@Lingling.Panda.COM Subject: Re: RSX-20F In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=us-ascii ReSent-Date: Mon, 6 Aug 2007 22:47:37 -0700 (PDT) ReSent-From: TOPS-20 List Moderator ReSent-To: TOPS-20 Distribution: ; ReSent-Subject: Re: RSX-20F ReSent-Message-ID: On Tue, 7 Aug 2007, Mike Ross wrote: > Would any of you be willing to make (or give, if you have any spare) a > pair of RX02 floppies with bootable RSX-20F on them for me? I *may* have a copy of RSX-20F floppies. If I do, they've been in an unheated Pacific Northwest garage for the past 19 years, so it is unlikely they are still readable. I will look, but I think that your best bet would be to ask someone like Rich Alderson who actually is running KLs. -- Mark -- http://panda.com/tops-20 TOPS-20: a great improvement over its successors 6-Aug-2007 23:26:19-PDT,2120;000000000000 Return-Path: Received: from pangtzu.panda.com ([206.124.149.117]) by lingling.panda.com with TCP/SMTP; Mon, 6 Aug 2007 23:18:21 -0700 (PDT) X-Return-Path: X-Received: from pangtzu.panda.com ([206.124.149.117]) by lingling.panda.com with TCP/SMTP; Mon, 6 Aug 2007 23:17:59 -0700 (PDT) Date: Mon, 6 Aug 2007 23:17:54 -0700 (PDT) From: Mark Crispin Sender: mrc@pangtzu.panda.com To: Mike Ross cc: TOPS-20@Lingling.Panda.COM Subject: Re: RSX-20F In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=us-ascii; format=flowed ReSent-Date: Mon, 6 Aug 2007 23:18:12 -0700 (PDT) ReSent-From: TOPS-20 List Moderator ReSent-To: TOPS-20 Distribution: ; ReSent-Subject: Re: RSX-20F ReSent-Message-ID: On Mon, 6 Aug 2007, Mark Crispin wrote: > I *may* have a copy of RSX-20F floppies. If I do, they've been in an > unheated Pacific Northwest garage for the past 19 years, so it is unlikely > they are still readable. I looked where they might be and didn't find any floppies. I did find (besides spider webs, etc.) lots of stuff that I hadn't laid eyes on in 19 years. I decided that it'd be prudent to stop before I started dragging mildewed books and other skanky stuff into the house. IIRC, the floppies used in the KL were the 8" type, weren't they? It's possible that I tossed all those 19 years ago, as I had no use for them on my KS systems and it was highly unlikely that I'd deal with a KL again. On the other hand, I seem to have a ridiculous number of DECtapes (the original 3/4" ones) even though the last time I had any use for one was in 1977! -- Mark -- http://panda.com/tops-20 TOPS-20: a great improvement over its successors 7-Aug-2007 11:39:45-PDT,2753;000000000000 Return-Path: Received: from pangtzu.panda.com ([206.124.149.117]) by lingling.panda.com with TCP/SMTP; Tue, 7 Aug 2007 11:31:26 -0700 (PDT) X-Return-Path: X-Received: from mta3.srv.hcvlny.cv.net ([167.206.4.198]) by lingling.panda.com with TCP/SMTP; Tue, 7 Aug 2007 04:21:12 -0700 (PDT) X-Received: from Whitestar (ool-4577982f.dyn.optonline.net [69.119.152.47]) by mta3.srv.hcvlny.cv.net (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with SMTP id <0JME009P1GSPOYT0@mta3.srv.hcvlny.cv.net>; Tue, 07 Aug 2007 06:50:49 -0400 (EDT) Date: Tue, 07 Aug 2007 06:50:44 -0700 From: Mike Ross Subject: Re: RSX-20F In-reply-to: <458859.02.57.01.07.08.2007@lingling.panda.com> To: Mark Crispin Cc: TOPS-20@Lingling.Panda.COM Message-id: MIME-version: 1.0 X-Mailer: Forte Agent 1.93/32.576 English (American) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT References: <458859.02.57.01.07.08.2007@lingling.panda.com> ReSent-Date: Tue, 7 Aug 2007 11:31:15 -0700 (PDT) ReSent-From: TOPS-20 List Moderator ReSent-To: TOPS-20 Distribution: ; ReSent-Subject: Re: RSX-20F ReSent-Message-ID: On Mon, 6 Aug 2007 23:17:54 -0700 (PDT), you wrote: >On Mon, 6 Aug 2007, Mark Crispin wrote: >> I *may* have a copy of RSX-20F floppies. If I do, they've been in an >> unheated Pacific Northwest garage for the past 19 years, so it is unlikely >> they are still readable. > >I looked where they might be and didn't find any floppies. I did find >(besides spider webs, etc.) lots of stuff that I hadn't laid eyes on in 19 >years. I decided that it'd be prudent to stop before I started dragging >mildewed books and other skanky stuff into the house. > >IIRC, the floppies used in the KL were the 8" type, weren't they? Yep >It's >possible that I tossed all those 19 years ago, as I had no use for them on >my KS systems and it was highly unlikely that I'd deal with a KL again. > >On the other hand, I seem to have a ridiculous number of DECtapes (the >original 3/4" ones) even though the last time I had any use for one was in >1977! Snap! All DECtapes. Unbelievably I don't have ANY bootable pdp-11 RXO2 8" disks in the house, not even diags or RT-11. They must all be in my storage unit in England, which I won't have access to for months. Mike -- http://www.corestore.org 'As I walk along these shores I am the history within' 7-Aug-2007 18:45:16-PDT,1808;000000000000 Return-Path: Received: from pangtzu.panda.com ([206.124.149.117]) by lingling.panda.com with TCP/SMTP; Tue, 7 Aug 2007 18:37:03 -0700 (PDT) X-Return-Path: X-Received: from dbit.dbit.com ([208.238.226.25] -- may be forged) by lingling.panda.com with TCP/SMTP; Tue, 7 Aug 2007 12:30:01 -0700 (PDT) X-Received: from dbit.dbit.com (IDENT:501@localhost [127.0.0.1]) by dbit.dbit.com (8.13.8/8.13.8) with ESMTP id l77JTBT7028339 for ; Tue, 7 Aug 2007 15:29:11 -0400 X-Received: (from wilson@localhost) by dbit.dbit.com (8.13.8/8.13.8/Submit) id l77JTBOY028338 for TOPS-20@LINGLING.PANDA.COM; Tue, 7 Aug 2007 15:29:11 -0400 Date: Tue, 7 Aug 2007 15:29:11 -0400 From: John Wilson Message-Id: <200708071929.l77JTBOY028338@dbit.dbit.com> To: TOPS-20@LINGLING.PANDA.COM Subject: Re: RSX-20F ReSent-Date: Tue, 7 Aug 2007 18:36:44 -0700 (PDT) ReSent-From: TOPS-20 List Moderator ReSent-To: TOPS-20 Distribution: ; ReSent-Subject: Re: RSX-20F ReSent-Message-ID: I don't know if you got the email I sent you directly, so I'll say the important stuff to the list. I took images of the RSX-20F floppies (I believe it was V16.00) back when I got my 2065, and my PDP-11/34a has an RX02 on it which still had one working drive at last use (about a year ago). But I don't have scratch floppies (my junk collection is still in upstate NY where I used to live). If you can come up with three RX01 or RX02 floppies (formatted) and get them to me in Mass., I should be able to put RSX-20F on them and get them back out to you quickly (same day, unless it's tomorrow because I'll be out of town). John Wilson Monson, MA 29-Aug-2007 12:50:07-PDT,1783;000000000000 Return-Path: Received: from pangtzu.panda.com ([206.124.149.117]) by Lingling.Panda.COM with TCP/SMTP; Wed, 29 Aug 2007 12:43:17 -0700 (PDT) X-Return-Path: X-Received: from pangtzu.panda.com ([206.124.149.117]) by Lingling.Panda.COM with TCP/SMTP; Wed, 29 Aug 2007 12:40:27 -0700 (PDT) Date: Wed, 29 Aug 2007 12:40:22 -0700 (PDT) From: Mark Crispin Sender: mrc@pangtzu.panda.com To: TOPS-20 Hackers and Yackers Subject: spammers hammering TOPS-20 servers? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII ReSent-Date: Wed, 29 Aug 2007 12:42:27 -0700 (PDT) ReSent-From: TOPS-20 List Moderator ReSent-To: TOPS-20 Distribution: ; ReSent-Subject: spammers hammering TOPS-20 servers? ReSent-Message-ID: I've recently noticed that Lingling's SMTP server is getting hammered by multiple systems continuously connecting to it. This is on top of the periodic FTP server hammering that has always gone on. The IP addresses are not ones associated with anyone who'd be legitimately sending email to Lingling; most are obvious DHCP-assigned addresses. No mail is actually delivered (other than the occasional phish message sent to the TOPS-20 list that I kill in the moderation step). Strangely, Hsinghsing isn't getting any of the SMTP server hammering, although it gets the FTP stuff. I would expect a worm or virus to hit each system equally. I wonder what is going on. -- Mark -- http://panda.com/tops-20 TOPS-20: a great improvement over its successors 3-Sep-2007 11:08:24-PDT,5652;000000000000 Return-Path: Received: from pangtzu.panda.com ([206.124.149.117]) by Lingling.Panda.COM with TCP/SMTP; Mon, 3 Sep 2007 11:03:54 -0700 (PDT) X-Return-Path: X-Received: from mta3.srv.hcvlny.cv.net ([167.206.4.198]) by Lingling.Panda.COM with TCP/SMTP; Mon, 3 Sep 2007 09:06:46 -0700 (PDT) X-Received: from [192.168.1.7] (ool-45720130.dyn.optonline.net [69.114.1.48]) by mta3.srv.hcvlny.cv.net (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTP id <0JNS00L73VF2NG20@mta3.srv.hcvlny.cv.net>; Mon, 03 Sep 2007 12:06:40 -0400 (EDT) Date: Mon, 03 Sep 2007 12:06:37 -0400 From: Thomas DeBellis Subject: Re: spammers hammering TOPS-20 servers? In-reply-to: To: Mark Crispin Cc: TOPS-20 Hackers and Yackers Message-id: <46DC310D.1010509@optonline.net> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en References: User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) ReSent-Date: Mon, 3 Sep 2007 11:03:38 -0700 (PDT) ReSent-From: TOPS-20 List Moderator ReSent-To: TOPS-20 Distribution: ; ReSent-Subject: Re: spammers hammering TOPS-20 servers? ReSent-Message-ID: > I've recently noticed that Lingling's SMTP server is getting > hammered by multiple systems continuously connecting to it. This is > on top of the periodic FTP server hammering that has always gone on. > The IP addresses are not ones associated with anyone who'd be > legitimately sending email to Lingling; most are obvious > DHCP-assigned addresses. I don't handle external e-mail, but I can speak to FTP attacks. A limited logging feature exists in the (modified) BBN server. If you turn it on, you'll get file stores (STOR, APPE) and retrieves (RETR) logged in a file in PS: (but see below). Some recoding would be involved to get it to remember other activity. That wasn't enough granularity for me. I did my first logging fairly early in the development of the server for different reasons: at the time, I needed to see what was coming across the wire on the control connection. I had completely forgotten about DMON and my version doesn't do anything with TVT's (or PTY's or CTERM, etc.), anyway. [Incidently, is there something that DOES do DMON'ish things for non-physical lines?] I also wanted to have crash logging in case the server gronked; you need to do these kinds of things when you're the top fork and don't have a friendly EXEC around looking out for you. I got a lot of log files, much more than I expected. After I inspected them, I began to get annoyed. Most were script attacks which fell into two major categories. 1) Try to hack into factory default accounts with factory default passwords. This attack is launched for both Windows and Unix. It keeps iterating through ids. But the scripts that are being used don't work under Tops-20 because none of the ids in question exist. 2) Log in anonymously and try various exploits, the most common being trying to create a directory. Since I haven't implemented MKDIR, this always fails. There is now code to handle these two cases in the server. You can build up a list of ids that will automatically get you kicked off if you try to use them. You can also set a scary message, viz: SITE FORBID MESSAGE 421 - "Unlawful connection attempt, authorities will be notified" SITE FORBID USER admin SITE FORBID USER Administrator SITE FORBID USER daemon SITE FORBID USER backup SITE FORBID USER Guest SITE FORBID USER HelpAssist SITE FORBID USER IUSR_TOMMYT SITE FORBID USER IWAM_TOMMYT SITE FORBID USER nobody SITE FORBID USER OPERATOR SITE FORBID USER OINKY SITE FORBID USER root SITE FORBID USER ROOT-DIRECTORY SITE FORBID USER sshd SITE FORBID USER Tourist SITE FORBID USER TsInternetUser SITE FORBID USER Voyeur SITE FORBID UNABBREVIATE SITE FORBID ERROR 5 A user id does not have to actually exist in order for it to be forbidden. Also, the server is hardwired to not allow an OPERATOR login under any circumstances. Anyway, although I throw attackers off very quickly with a scary message, they keep coming back. And I keep getting FTP attacks and the number is rising. Since my last boot (July 5th), I have been attacked approximately 3,800 times. A lot of stuff is not coming from the United States. I really can not put into words what kind of gratification that I would get from slapping these idiots around, verbally, digitally or otherwise. It was REALLY nice in the 1980's to be able to find them out and let them have it. While Frank was usually able to make me tone down the flame they'd get, but I still had the feeling like I could do something. Not now ... A final word on logging: there is a small amount code in the BBN FTP server for some kind of IPCF logging. It gets a PID for the following name: [SYSTEM]FTSCTT which internally is called 'FTSCTL'. On successful LOGIN% completion, the signed-on banner string is sent to this PID. The IPCF logging code appears to be vestigial, but I was wondering if anybody knew anything more (or less) about it. For the time being, I wasn't planning on supporting the functionality. 3-Sep-2007 12:20:28-PDT,2871;000000000000 Return-Path: Received: from pangtzu.panda.com ([206.124.149.117]) by Lingling.Panda.COM with TCP/SMTP; Mon, 3 Sep 2007 12:16:32 -0700 (PDT) X-Return-Path: X-Received: from pangtzu.panda.com ([206.124.149.117]) by Lingling.Panda.COM with TCP/SMTP; Mon, 3 Sep 2007 11:47:30 -0700 (PDT) Date: Mon, 3 Sep 2007 11:47:24 -0700 (PDT) From: Mark Crispin Sender: mrc@pangtzu.panda.com To: Thomas DeBellis cc: TOPS-20 Hackers and Yackers Subject: Re: spammers hammering TOPS-20 servers? In-Reply-To: <46DC310D.1010509@optonline.net> Message-ID: References: <46DC310D.1010509@optonline.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed ReSent-Date: Mon, 3 Sep 2007 12:16:24 -0700 (PDT) ReSent-From: TOPS-20 List Moderator ReSent-To: TOPS-20 Distribution: ; ReSent-Subject: Re: spammers hammering TOPS-20 servers? ReSent-Message-ID: On Mon, 3 Sep 2007, Thomas DeBellis wrote: > Most were script attacks which fell into two major > categories. > 1) Try to hack into factory default accounts with factory default > passwords. This attack is launched for both Windows and Unix. It > keeps iterating through ids. But the scripts that are being used > don't work under Tops-20 because none of the ids in question exist. > 2) Log in anonymously and try various exploits, the most common being > trying to create a directory. Since I haven't implemented MKDIR, > this always fails. Yup, this is the sort of attack that we've seen on our UNIX systems for years. FTP is a secondary target; the primary target is SSH. Scary messages are of no use, since the attacks are script mounted and the attacker never sees them. As you also noticed, most of the attacks come from overseas. Furthermore, the attacking machines are themselves the compromised victims of an earlier attack; the gangs avoid dirtying their own IP space. You have to understand that these are not the naughty kids of years past. They are organized criminal gangs; the Russian Mafia is a *HUGE* player. Other than understanding enough about the attacks to be sure that the defenses hold, I don't consider logs to be particularly interesting. I have voluminous logs of SSH attacks. Their only use would be to track down the legitimate owner of the IP space and inform him about the compromised system. But that takes considerable time, and sometimes there is no legitimate owner. -- Mark -- http://panda.com/tops-20 TOPS-20: a great improvement over its successors 14-Nov-2007 22:36:31-PST,2350;000000000000 Return-Path: Received: from pangtzu.panda.com ([206.124.149.117]) by Lingling.Panda.COM with TCP/SMTP; Wed, 14 Nov 2007 22:32:08 -0800 (PST) X-Return-Path: X-Received: from mta1.srv.hcvlny.cv.net ([167.206.4.196]) by Lingling.Panda.COM with TCP/SMTP; Wed, 14 Nov 2007 20:04:14 -0800 (PST) X-Received: from [192.168.1.7] (ool-45720130.dyn.optonline.net [69.114.1.48]) by mta1.srv.hcvlny.cv.net (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTP id <0JRJ00IU64MWTHV0@mta1.srv.hcvlny.cv.net> for TOPS-20@Lingling.Panda.COM; Wed, 14 Nov 2007 23:04:08 -0500 (EST) Date: Wed, 14 Nov 2007 23:04:07 -0500 From: Thomas DeBellis Subject: Holey File Batman! To: TOPS-20 Wizards Message-id: <473BC537.7090403@optonline.net> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) ReSent-Date: Wed, 14 Nov 2007 22:32:00 -0800 (PST) ReSent-From: TOPS-20 List Moderator ReSent-To: TOPS-20 Distribution: ; ReSent-Subject: Holey File Batman! ReSent-Message-ID: ReSent-User-Agent: Alpine 0.99999 (OSX 813 2007-11-14) I'm working on FTP paged structure transfers and am looking for files with legitmate holes in them. Does anybody know of some? I couldn't think of any. I thought I remembered that the Quasar failsoft file did, but it still doesn't (see below). I have an extremely vague recollection that one of the reasons for paged file structures was to enable the efficient transfer of crash dump files. Since I've been up over 3100 hours, I have little inclination to go produce these ... Incredibly enough, I actually remembered some changes to Quasar that I made to save on disk space that results in a failsoft file with holes in it. I guess that was *another* one of my SPR's that never made it in (and Frank made me work so carefully on them!!) Anyway, I'll post those changes in another message, but for now, other than building files with holes in them myself, does anybody know what would create them? 14-Nov-2007 22:40:09-PST,9332;000000000000 Return-Path: Received: from pangtzu.panda.com ([206.124.149.117]) by Lingling.Panda.COM with TCP/SMTP; Wed, 14 Nov 2007 22:33:47 -0800 (PST) X-Return-Path: X-Received: from mail1.acecape.com ([66.114.74.12]) by Lingling.Panda.COM with TCP/SMTP; Wed, 14 Nov 2007 20:05:10 -0800 (PST) X-Received: from [192.168.2.7] (p69-214.acedsl.com [66.114.69.214]) by mail1.acecape.com (8.13.8/8.13.8) with ESMTP id lAF454sf030233 for ; Wed, 14 Nov 2007 23:05:04 -0500 Message-ID: <473BC56F.7010102@acedsl.com> Date: Wed, 14 Nov 2007 23:05:03 -0500 From: Thomas DeBellis User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tops-20 Wizards Subject: Re: PRIMARY-MASTER-QUEUE-FILE.QUASAR Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit ReSent-Date: Wed, 14 Nov 2007 22:33:40 -0800 (PST) ReSent-From: TOPS-20 List Moderator ReSent-To: TOPS-20 Distribution: ; ReSent-Subject: Re: PRIMARY-MASTER-QUEUE-FILE.QUASAR ReSent-Message-ID: ReSent-User-Agent: Alpine 0.99999 (OSX 813 2007-11-14) More than a few years ago (*sigh*), we at Columbia had a VERY hard time keeping our PS: structures from filling up. This was back before we had CFS; I guess we were still on version 5 (or maybe even 4.1). As Frank felt very uncomfortable about non-standard structures, we were limited to a three pack RP06 PS:. I don't remember that we had an RP07 at that point or whether they were even available. I think CMU had one system (Tops-A?) that had a six pack RP06 PS:, of which we were quite in awe. So we were always scrounging around for disk space. Our Quasar failsoft files were large. Huge. Sometimes they cleared a thousand pages. This was before archiving; we just did a lot of mounting, printing and batch jobs. The problem got even worse after I modified our systems to be able to spool to each other via a Tops-20 based DN200 emulator that I wrote. Even when we no print jobs, no mount requests and a few batch jobs, the size of the Quasar failsoft file never shrank. So I spent a few weeks puzzling it all out and knocked together some code to remove a page in the failsoft file whenever a queue request was released. It was amazingly straightforward; almost as if Quasar had been designed for it. As may be inferred below, in 1985 I wasn't 100% sure about why it hadn't been coded that way in the first place. At this point, I would be more inclined to believe that this was more an artifact of Quasar running under Tops-10 which doesn't (or didn't) support non-contiguous files. But does anybody have any clues? Just wondering ... Anyway, here is my original post to Tops-20, but THIS time, the changes are at the end. It should be noted that the code in Quasar is *NOT* reentrant and that it is storing data in code pages. That's something that is really frowned on these days, but I'm following the coding conventions for these modules. As to why this would be so, I can only guess. Maybe it made debugging easier. Perhaps since there is only a single instance of Quasar, one assumes that it probably wasn't that bad to dirty up some pages that would never be shared, anyway. On the other hand, if stack variables were being used, maybe the overall page file usage might have dropped. Who knows? For what it's worth, we ran this code at Columbia for at least 3 years and I don't recall EVER seeing a stop code associated with it. I have done a GREAT deal of testing on my machine with various batch jobs that submit and cancel jobs all over the place. Since (re)developing the code and testing it, I've been running the updated Quasar for two months. I have self-submitting batch jobs that do all kinds of things (a re-occuring backup, for example) and notify me about various other randomalia, but in no way do I have the kind of traffic that CU20A,B,C,D had. However, my failsoft file is only six pages long and it has holes in it! ------- Return-Path: Received: from columbia.arpa by SU-SCORE.ARPA with TCP; Tue 15 Jan 85 15:04:22-PST Received: from CU20B.ARPA by columbia.arpa; Tue, 15 Jan 85 18:05:15 est Date: Tue 15 Jan 85 18:03:49-EST From: Thomas De Bellis Subject: Re: PRIMARY-MASTER-QUEUE-FILE.QUASAR To: RBASCH@BBNF.ARPA Cc: ROODE@SRI-NIC.ARPA, TOPS-20@SU-SCORE.ARPA In-Reply-To: Message from "RBASCH@BBNF.ARPA" of Tue 15 Jan 85 10:29:00-EST That is not the whole story. When Quasar deallocates a page in the Q file (most often when some processor does a RELEASE), it does NOT do a PMAP% to get rid of the page in the file. It marks the page as not in use and considers it for usage before allocating another page in the Q file (most often when a CREATE is requested). As you can see, this is not exactly a bug as it makes Quasar somewhat more efficient be virtue of the fact that you cut the number of PMAP%'s (and associated allocations and DSKBTTBL writes) roughly in half. This is good. Here, however, we were very tight on disk space so I wrote some code that tosses the page in the Q file. I don't toss the index pages (for you folks who know the format of the Q file). This code took me 20 minutes to write and involved a one line change to QSRFSS (the failsoft module) and the addition of one routine to QSRT20 (the Tops-20 interface) to handle the associated PMAP%'s. It doesn't seem to have slowed Quasar down at all. Our Q files are about 40 pages long on the average. If anyone is interested in this, I will dust off my sources and post the changes. They are pretty trivial if you look at QSRFSS; that's why I refrained from saying anything at first. -- Tom De Bellis CUCCA Systems Group ------- File 1) G:QSRFSS.MAC[4,106] created: 2016 22-Sep-07 File 2) T:QSRFSS.MAC[4,54] created: 1751 08-Mar-88 1)1 ;[TOMMYT]STAR:QSRFSS.MAC.2, 13-Sep-2007 21:33:15, Edit by SLOGIN 1) ;[T47] When releasing Galaxy requests, release the associated failsoft disk pages 1) 1) TITLE QSRFSS -- Failsoft System for QUASAR **** 2)1 TITLE QSRFSS -- Failsoft System for QUASAR ************** 1)1 FSSMAN==:1 ;[T47] ;Maintenance edit number 1) FSSDEV==:21 ;Development edit number **** 2)1 FSSMAN==:0 ;Maintenance edit number 2) FSSDEV==:21 ;Development edit number ************** 1)12 F$RLRQ: MOVEM S1,RLRQ.A ;[T47] Save the DPA 1) PUSHJ P,CLRDPA ;[T47] Clear the index words 1) PUSHJ P,WRTIDX ;[T47] Write the index 1) MOVE S1,RLRQ.A ;[T47] Restore the DPA 1) PUSHJ P,I$RELD## ;[T47] Go release the disk space 1) $RETT ;[T47] All done 1) 1) RLRQ.A: BLOCK 1 ;[T47] DPA storage 1) 1)13 SUBTTL Index Handling Routines **** 2)12 F$RLRQ: PUSHJ P,CLRDPA ;CLEAR THE INDEX WORDS OUT 2) PJRST WRTIDX ;WRITE THE INDEX AND RETURN 2) 2)13 SUBTTL Index Handling Routines ************** File 1) G:QSRT20.MAC[4,106] created: 2017 22-Sep-07 File 2) T:QSRT20.MAC[4,54] created: 2118 29-Nov-89 1)1 ;[TOMMYT]STAR:QSRT20.MAC.2, 13-Sep-2007 21:41:13, Edit by SLOGIN 1) ;[T47] When releasing Galaxy requests, release the associated failsoft disk pages 1) 1) TITLE QSRT20 -- Operating System Interface for QUASAR-20 **** 2)1 TITLE QSRT20 -- Operating System Interface for QUASAR-20 ************** 1)1 T20MAN==:41 ;[T47] ;Maintenance edit number 1) T20DEV==:35 ;Development edit number **** 2)1 T20MAN==:37 ;Maintenance edit number 2) T20DEV==:35 ;Development edit number ************** 1)40 INTERN I$RELD ;[T47] RELEASE DPA IN THE MASTER 1) INTERN I$READ ;READ SOMETHING FROM THE MASTER **** 2)40 INTERN I$READ ;READ SOMETHING FROM THE MASTER ************** 1)42 SUBTTL I$RELD - Release disk space from failsoft file 1) 1) ;[T47] Begin code addition 1) 1) ; Routine to release the disk space in the failsoft file associated 1) ; with a request. Call with S1 containing a block to release. Under 1) ; Tops-20, this is simply the disk page. 1) 1) I$RELD: PUSHJ P,.SAVET ; Save T1-T4 1) MOVEM S1,RELD.A ; Save the DPA 1) MOVE T1,S1 ; Get block number 1) IDIVI T1,FSSBPS ; Divide by blocks/section 1) CAIN T2,FSSFIB ; Is it an index block? 1) $STOP(SRI,SHOULD NOT RELEASE INDEX) 1) SETO S1, ; Removing a page in the failsoft file 1) HRR S2,RELD.A ; Load the file page to remove 1) HRL S2,FILJFN ; Produce JFN,,FILE-PAGE 1) SETZ T1, ; No repeats!! One page at a time!! 1) PMAP ; Finally pitch the page 1) ERJMPR RELD.1 ; Failure means inconsistent failsoft 1) $RETT ; And return 1) 1) RELD.1: $STOP(CRP,CANT RELEASE DPA) ; Most likey asked to release a hole 1) $RETT ; in the file (already released page) 1) 1) RELD.A: BLOCK 1 ; Space for the DPA 1) 1) ;[T47] End code addition 1) 1)43 SUBTTL I$READ - Read something from master queue file **** 2)42 SUBTTL I$READ - Read something from master queue file ************** 14-Nov-2007 22:51:12-PST,2134;000000000000 Return-Path: Received: from pangtzu.panda.com ([206.124.149.117]) by Lingling.Panda.COM with TCP/SMTP; Wed, 14 Nov 2007 22:47:28 -0800 (PST) X-Return-Path: X-Received: from pangtzu.panda.com ([206.124.149.117]) by Lingling.Panda.COM with TCP/SMTP; Wed, 14 Nov 2007 22:46:56 -0800 (PST) Date: Wed, 14 Nov 2007 22:46:52 -0800 (PST) From: Mark Crispin Sender: mrc@pangtzu.panda.com To: Thomas DeBellis cc: TOPS-20 Wizards Subject: Re: Holey File Batman! In-Reply-To: <473BC537.7090403@optonline.net> Message-ID: References: <473BC537.7090403@optonline.net> User-Agent: Alpine 0.99999 (OSX 813 2007-11-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII ReSent-Date: Wed, 14 Nov 2007 22:47:20 -0800 (PST) ReSent-From: TOPS-20 List Moderator ReSent-To: TOPS-20 Distribution: ; ReSent-Subject: Re: Holey File Batman! ReSent-Message-ID: ReSent-User-Agent: Alpine 0.99999 (OSX 813 2007-11-14) If I recall correctly, the biggest user of holey files was the TVEDIT editor (not to be confused with DEC's TV which was a variant of TECO). TVEDIT was a Tenex editor by Pentti Kanerva, of the same family line as E on WAITS and vi on UNIX (as opposed to the TECO/TECMAC/EMACS family line). Like E on WAITS, it had an index to each text page of the file; unlike E the index was all the way at the end (I forget if Tenex had long files or not, so either it was page 511 or page 262143). I forget if TVEDIT adjusted the start of text pages to disk pages the way E on WAITS did. Anyway, TVEDIT was very popular among Tenex hackers, especially on the west coast. Much the same type of people preferred TVEDIT over PDP-10 EMACS that preferred vi over UNIX emacs. Possibly some Interlisp save files were also holey. -- Mark -- http://panda.com/tops-20 TOPS-20: a great improvement over its successors 21-Nov-2007 14:05:45-PST,1394;000000000000 Return-Path: Received: from pangtzu.panda.com ([206.124.149.117]) by Lingling.Panda.COM with TCP/SMTP; Wed, 21 Nov 2007 14:01:14 -0800 (PST) X-Return-Path: X-Received: from pangtzu.panda.com ([206.124.149.117]) by Lingling.Panda.COM with TCP/SMTP; Wed, 21 Nov 2007 13:42:56 -0800 (PST) Date: Wed, 21 Nov 2007 13:42:52 -0800 (PST) From: Mark Crispin Sender: mrc@pangtzu.panda.com To: TOPS-20 Hackers and Yackers Subject: klh10 compilation error Message-ID: User-Agent: Alpine 0.99999 (OSX 825 2007-11-21) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII ReSent-Date: Wed, 21 Nov 2007 14:01:08 -0800 (PST) ReSent-From: TOPS-20 List Moderator ReSent-To: TOPS-20 Distribution: ; ReSent-Subject: klh10 compilation error ReSent-Message-ID: ReSent-User-Agent: Alpine 0.99999 (OSX 825 2007-11-21) In line 270 of klh10-20.h/src/cenv.h, there is a line which reads: # define _FILE_OFFSET_BITS=64 /* Use 64-bit file ops */ That line should read: # define _FILE_OFFSET_BITS 64 /* Use 64-bit file ops */ -- Mark -- http://panda.com/tops-20 TOPS-20: a great improvement over its successors 21-Nov-2007 15:09:59-PST,1865;000000000000 Return-Path: Received: from pangtzu.panda.com ([206.124.149.117]) by Lingling.Panda.COM with TCP/SMTP; Wed, 21 Nov 2007 15:05:42 -0800 (PST) X-Return-Path: X-Received: from pangtzu.panda.com ([206.124.149.117]) by Lingling.Panda.COM with TCP/SMTP; Wed, 21 Nov 2007 15:05:17 -0800 (PST) Date: Wed, 21 Nov 2007 15:05:14 -0800 (PST) From: Mark Crispin Sender: mrc@pangtzu.panda.com To: TOPS-20 Hackers and Yackers Subject: TOPS-20 in a shirt pocket! Message-ID: User-Agent: Alpine 0.99999 (OSX 825 2007-11-21) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII ReSent-Date: Wed, 21 Nov 2007 15:05:36 -0800 (PST) ReSent-From: TOPS-20 List Moderator ReSent-To: TOPS-20 Distribution: ; ReSent-Subject: TOPS-20 in a shirt pocket! ReSent-Message-ID: ReSent-User-Agent: Alpine 0.99999 (OSX 825 2007-11-21) I was bored, and ported klh10 to the Nokia N800 Internet Tablet. It is now running Panda TOPS-20, about 1.4 times faster than a DECSYSTEM-2065 and about 86% the speed of an XKL Toad. By comparison, Lingling (which I built in 2001) is about 12 times faster. That's right; for less than $300 (the N800 plus a large enough SD card to hold the RP07 virtual disk) you can have a shirt pocket TOPS-20 that is faster than any DEC machine ever was. A binary tarball for the Nokia N800 is on http://panda.com/klh10-n800.tar.gz You'll also need the Panda distribution from http://panda.trailing-edge.com/panda-dist.tar.gz for a TOPS-20 virtual RP07 and sources. -- Mark -- http://panda.com/tops-20 TOPS-20: a great improvement over its successors 25-Nov-2007 23:51:46-PST,3675;000000000000 Return-Path: Received: from pangtzu.panda.com ([206.124.149.117]) by Lingling.Panda.COM with TCP/SMTP; Sun, 25 Nov 2007 23:47:00 -0800 (PST) X-Return-Path: X-Received: from smtpoutm.mac.com ([17.148.16.68]) by Lingling.Panda.COM with TCP/SMTP; Sun, 25 Nov 2007 22:46:27 -0800 (PST) X-Received: from mac.com (asmtp005-s [10.150.69.68]) by smtpoutm.mac.com (Xserve/smtpout005/MantshX 4.0) with ESMTP id lAQ6kM93017052; Sun, 25 Nov 2007 22:46:22 -0800 (PST) X-Received: from [192.168.1.52] (c-24-147-40-233.hsd1.nh.comcast.net [24.147.40.233]) (authenticated bits=0) by mac.com (Xserve/asmtp005/MantshX 4.0) with ESMTP id lAQ6kKGr026751; Sun, 25 Nov 2007 22:46:20 -0800 (PST) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <71A2055F-3D81-4473-9586-3BA62D7603DF@mac.com> Cc: TOPS-20 Hackers and Yackers Content-Transfer-Encoding: 7bit From: John Francini Subject: Re: klh10 compilation error Date: Mon, 26 Nov 2007 01:46:46 -0500 To: Mark Crispin X-Mailer: Apple Mail (2.752.2) ReSent-Date: Sun, 25 Nov 2007 23:46:54 -0800 (PST) ReSent-From: TOPS-20 List Moderator ReSent-To: TOPS-20 Distribution: ; ReSent-Subject: Re: klh10 compilation error ReSent-Message-ID: ReSent-User-Agent: Alpine 0.99999 (OSX 825 2007-11-21) Mark, I just built the Panda Distribution from trailing-edge on Mac OS X 10.4.10. After making your suggested change, I only had one compilation problem: gcc didn't like the fact that a line of code in kn10ops.c tried to request the address of a variable declared type "register": ../../src/kn10ops.c: In function 'qdivstep': ../../src/kn10ops.c:3266: error: address of register variable 'qw' requested ../../src/kn10ops.c:3266: error: address of register variable 'qw' requested ../../src/kn10ops.c:3266: error: address of register variable 'qw' requested However, I seem to be unable to get the network port to connect, even if I run either logged in as root or having dpni20 set-UIDed to root. Do you know if there's any 'trick' to get it to work? The errors from KLH10 (and, correspondingly, from the Monitor), look like this: Why reload? opr Run CHECKD? (Y OR N) n DDMP: Started [KNILDR: Loading microcode version 1(172) into Ethernet channel 0] [dpni20: Warning - cannot set high priority - Permission denied] [dpni20: Fatal error: Must be superuser!] 26-Nov-2007 00:39:17 Internet: Network Narfnet on, Output off 26-Nov-2007 00:39:12 ***BUGCHK KNIINF*** PHYKNI - NIA20 initialization timed out Job: 0, User: OPERATOR, Data: 400007000036 26-Nov-2007 00:39:17 ***BUGCHK IPDWNS*** Datagram was not sent Job: 0, User: OPERATOR, Data: 36, 2 SYSJOB 7A(88)-4 started at 26-Nov-2007 0039 26-Nov-2007 00:39:17 ***BUGCHK KNIRLF*** PHYKNI - NIA20 Reload Failed Job: 0, User: OPERATOR, Data: 10 Thanks, John Francini On 21 Nov 2007, at 16:42, Mark Crispin wrote: > In line 270 of klh10-20.h/src/cenv.h, there is a line which reads: > > # define _FILE_OFFSET_BITS=64 /* Use 64-bit file ops */ > > That line should read: > > # define _FILE_OFFSET_BITS 64 /* Use 64-bit file ops */ > > -- Mark -- > > http://panda.com/tops-20 > TOPS-20: a great improvement over its successors > 26-Nov-2007 00:17:44-PST,3654;000000000000 Return-Path: Received: from pangtzu.panda.com ([206.124.149.117]) by Lingling.Panda.COM with TCP/SMTP; Mon, 26 Nov 2007 00:13:11 -0800 (PST) X-Return-Path: X-Received: from pangtzu.panda.com ([206.124.149.117]) by Lingling.Panda.COM with TCP/SMTP; Mon, 26 Nov 2007 00:09:22 -0800 (PST) Date: Mon, 26 Nov 2007 00:09:14 -0800 (PST) From: Mark Crispin Sender: mrc@pangtzu.panda.com To: John Francini cc: TOPS-20 Hackers and Yackers Subject: Re: klh10 compilation error In-Reply-To: <71A2055F-3D81-4473-9586-3BA62D7603DF@mac.com> Message-ID: References: <71A2055F-3D81-4473-9586-3BA62D7603DF@mac.com> User-Agent: Alpine 0.99999 (OSX 825 2007-11-21) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed ReSent-Date: Mon, 26 Nov 2007 00:13:04 -0800 (PST) ReSent-From: TOPS-20 List Moderator ReSent-To: TOPS-20 Distribution: ; ReSent-Subject: Re: klh10 compilation error ReSent-Message-ID: ReSent-User-Agent: Alpine 0.99999 (OSX 825 2007-11-21) John - Hsinghsing.panda.com is a klh10 running under Mac OS X 10.4.11 on PPC, so it definitely works on that platform. You can safely ignore the compiler warnings. The following messages clearly indicate that dpni20 is not setuid-ed to root. You need to get that fixed before anything else goes on, since that is the underlying cause of the failure for the network to start. > [dpni20: Warning - cannot set high priority - Permission denied] > > [dpni20: Fatal error: Must be superuser!] I know that you said that you ran it setuid root, and as root, but these error messages disagree with you. Double-check, triple-check, etc. until you find what it is that made dpni20 not run as root. Check obvious environmental things, such as it being on a filesystem mounted nosuid. Here is what Hsinghsing's klh10 runtime system looks like from Mac OS X: total 977912 -rw------- 1 mrc mrc 498530304 Nov 26 00:00 RH20.RP07.1 -r--r--r-- 1 mrc mrc 23280 Mar 9 2002 boot.sav -r-xr-xr-x 1 mrc mrc 28 Feb 7 2002 dfkfb* -r--r--r-- 1 mrc mrc 31365 Jan 13 1994 dfkfb-all.savh -r--r--r-- 1 mrc mrc 347 Feb 7 2002 dfkfb.ini -r-sr-xr-x 1 root wheel 115388 Jun 15 2006 dpni20* -r-sr-xr-x 1 root wheel 93744 Jun 15 2006 dprpxx* -r-sr-xr-x 1 root wheel 201540 Jun 15 2006 dptm03* -r-xr-xr-x 1 mrc mrc 69560 May 5 2003 enaddr* -r-xr-xr-x 1 mrc mrc 35 Feb 3 2002 inst-klt20* -r--r--r-- 1 mrc mrc 629 Feb 3 2002 inst-klt20.ini -r-xr-xr-x 1 mrc mrc 35 Apr 30 2005 klt20* -rw-r--r-- 1 mrc mrc 495 May 4 2005 klt20.ini -r-sr-xr-x 1 root wheel 1056004 Jun 15 2006 kn10-kl* -r--r--r-- 1 mrc mrc 20460 Mar 9 2002 mtboot.sav -r-xr-xr-x 1 mrc mrc 71042 Dec 26 2001 read20* -rwxr-xr-x 1 mrc mrc 166176 Jun 15 2006 tapedd* -r-xr-xr-x 1 mrc mrc 42232 May 5 2003 udlconv* -rwxr-xr-x 1 mrc mrc 49684 Jun 15 2006 uexbconv* -rwxr-xr-x 1 mrc mrc 69104 Jun 15 2006 vdkfmt* -rwxr-xr-x 1 mrc mrc 49112 Jun 15 2006 wfconv* -rwxr-xr-x 1 mrc mrc 52044 Jun 15 2006 wxtest* -- Mark -- http://panda.com/tops-20 TOPS-20: a great improvement over its successors 27-Nov-2007 22:24:42-PST,4490;000000000000 Return-Path: Received: from pangtzu.panda.com ([206.124.149.117]) by Lingling.Panda.COM with TCP/SMTP; Tue, 27 Nov 2007 22:20:40 -0800 (PST) X-Return-Path: X-Received: from smtpoutm.mac.com ([17.148.16.69]) by Lingling.Panda.COM with TCP/SMTP; Tue, 27 Nov 2007 21:21:41 -0800 (PST) X-Received: from mac.com (asmtp006-s [10.150.69.69]) by smtpoutm.mac.com (Xserve/smtpout006/MantshX 4.0) with ESMTP id lAS5LbCO005781; Tue, 27 Nov 2007 21:21:37 -0800 (PST) X-Received: from [192.168.1.52] (c-24-147-40-233.hsd1.nh.comcast.net [24.147.40.233]) (authenticated bits=0) by mac.com (Xserve/asmtp006/MantshX 4.0) with ESMTP id lAS5LZN1018189; Tue, 27 Nov 2007 21:21:35 -0800 (PST) In-Reply-To: References: <71A2055F-3D81-4473-9586-3BA62D7603DF@mac.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <6794963A-1469-418B-9CE8-B694DDE5CF9F@mac.com> Cc: TOPS-20 Hackers and Yackers Content-Transfer-Encoding: 7bit From: John Francini Subject: Re: klh10 compilation error Date: Wed, 28 Nov 2007 00:22:08 -0500 To: Mark Crispin X-Mailer: Apple Mail (2.752.2) ReSent-Date: Tue, 27 Nov 2007 22:20:29 -0800 (PST) ReSent-From: TOPS-20 List Moderator ReSent-To: TOPS-20 Distribution: ; ReSent-Subject: Re: klh10 compilation error ReSent-Message-ID: ReSent-User-Agent: Alpine 0.99999 (OSX 833 2007-11-27) Ah. You set *ALL* the executables that are part of the KLH10 'microcode engine suite' to setuid root. Let me poke around and try that. I'll let you know how it goes. Thanks! john On 26 Nov 2007, at 3:09, Mark Crispin wrote: > John - > > Hsinghsing.panda.com is a klh10 running under Mac OS X 10.4.11 on > PPC, so it definitely works on that platform. > > You can safely ignore the compiler warnings. > > The following messages clearly indicate that dpni20 is not setuid- > ed to root. You need to get that fixed before anything else goes > on, since that is the underlying cause of the failure for the > network to start. > >> [dpni20: Warning - cannot set high priority - Permission denied] >> >> [dpni20: Fatal error: Must be superuser!] > > I know that you said that you ran it setuid root, and as root, but > these error messages disagree with you. Double-check, triple- > check, etc. until you find what it is that made dpni20 not run as > root. Check obvious environmental things, such as it being on a > filesystem mounted nosuid. > > Here is what Hsinghsing's klh10 runtime system looks like from Mac > OS X: > > total 977912 > -rw------- 1 mrc mrc 498530304 Nov 26 00:00 RH20.RP07.1 > -r--r--r-- 1 mrc mrc 23280 Mar 9 2002 boot.sav > -r-xr-xr-x 1 mrc mrc 28 Feb 7 2002 dfkfb* > -r--r--r-- 1 mrc mrc 31365 Jan 13 1994 dfkfb-all.savh > -r--r--r-- 1 mrc mrc 347 Feb 7 2002 dfkfb.ini > -r-sr-xr-x 1 root wheel 115388 Jun 15 2006 dpni20* > -r-sr-xr-x 1 root wheel 93744 Jun 15 2006 dprpxx* > -r-sr-xr-x 1 root wheel 201540 Jun 15 2006 dptm03* > -r-xr-xr-x 1 mrc mrc 69560 May 5 2003 enaddr* > -r-xr-xr-x 1 mrc mrc 35 Feb 3 2002 inst-klt20* > -r--r--r-- 1 mrc mrc 629 Feb 3 2002 inst-klt20.ini > -r-xr-xr-x 1 mrc mrc 35 Apr 30 2005 klt20* > -rw-r--r-- 1 mrc mrc 495 May 4 2005 klt20.ini > -r-sr-xr-x 1 root wheel 1056004 Jun 15 2006 kn10-kl* > -r--r--r-- 1 mrc mrc 20460 Mar 9 2002 mtboot.sav > -r-xr-xr-x 1 mrc mrc 71042 Dec 26 2001 read20* > -rwxr-xr-x 1 mrc mrc 166176 Jun 15 2006 tapedd* > -r-xr-xr-x 1 mrc mrc 42232 May 5 2003 udlconv* > -rwxr-xr-x 1 mrc mrc 49684 Jun 15 2006 uexbconv* > -rwxr-xr-x 1 mrc mrc 69104 Jun 15 2006 vdkfmt* > -rwxr-xr-x 1 mrc mrc 49112 Jun 15 2006 wfconv* > -rwxr-xr-x 1 mrc mrc 52044 Jun 15 2006 wxtest* > > -- Mark -- > > http://panda.com/tops-20 > TOPS-20: a great improvement over its successors > 27-Nov-2007 23:08:28-PST,1917;000000000000 Return-Path: Received: from pangtzu.panda.com ([206.124.149.117]) by Lingling.Panda.COM with TCP/SMTP; Tue, 27 Nov 2007 23:04:42 -0800 (PST) X-Return-Path: X-Received: from pangtzu.panda.com ([206.124.149.117]) by Lingling.Panda.COM with TCP/SMTP; Tue, 27 Nov 2007 22:53:41 -0800 (PST) Date: Tue, 27 Nov 2007 22:53:38 -0800 (PST) From: Mark Crispin Sender: mrc@pangtzu.panda.com To: John Francini cc: TOPS-20 Hackers and Yackers Subject: Re: klh10 compilation error In-Reply-To: <6794963A-1469-418B-9CE8-B694DDE5CF9F@mac.com> Message-ID: References: <71A2055F-3D81-4473-9586-3BA62D7603DF@mac.com> <6794963A-1469-418B-9CE8-B694DDE5CF9F@mac.com> User-Agent: Alpine 0.99999 (OSX 833 2007-11-27) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII ReSent-Date: Tue, 27 Nov 2007 23:04:37 -0800 (PST) ReSent-From: TOPS-20 List Moderator ReSent-To: TOPS-20 Distribution: ; ReSent-Subject: Re: klh10 compilation error ReSent-Message-ID: ReSent-User-Agent: Alpine 0.99999 (OSX 833 2007-11-27) On Wed, 28 Nov 2007, John Francini wrote: > Ah. You set *ALL* the executables that are part of the KLH10 > 'microcode engine suite' to setuid root. Let me poke around and try > that. dpni20 is the only thing that must be setuid root. However, if kn10-kl is also setuid root, then it can lock itself in memory which will make it run better. [For KS-ITS builds, that is dpimp and kn10-ks...] -- Mark -- http://panda.com/tops-20 TOPS-20: a great improvement over its successors 28-Nov-2007 10:48:47-PST,3146;000000000000 Return-Path: Received: from pangtzu.panda.com ([206.124.149.117]) by Lingling.Panda.COM with TCP/SMTP; Wed, 28 Nov 2007 10:44:58 -0800 (PST) X-Return-Path: X-Received: from chip8og54.obsmtp.com ([64.18.15.181]) by Lingling.Panda.COM with TCP/SMTP; Wed, 28 Nov 2007 09:37:04 -0800 (PST) X-Received: from source ([12.110.134.31]) by chip8ob54.postini.com ([64.18.7.12]) with SMTP; Wed, 28 Nov 2007 09:36:36 PST X-Received: from [10.127.250.241] ([10.127.250.241]) by M31.equallogic.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Wed, 28 Nov 2007 12:35:07 -0500 In-Reply-To: References: <71A2055F-3D81-4473-9586-3BA62D7603DF@mac.com> <6794963A-1469-418B-9CE8-B694DDE5CF9F@mac.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <6A887C3F-FE06-4DB4-9234-636476185913@mac.com> Cc: TOPS-20 Hackers and Yackers Content-Transfer-Encoding: 7bit From: John Francini Subject: Re: klh10 compilation error Date: Wed, 28 Nov 2007 12:35:03 -0500 To: Mark Crispin X-Mailer: Apple Mail (2.752.3) X-Return-Path: francini@mac.com X-OriginalArrivalTime: 28 Nov 2007 17:35:07.0418 (UTC) FILETIME=[04949FA0:01C831E5] ReSent-Date: Wed, 28 Nov 2007 10:44:51 -0800 (PST) ReSent-From: TOPS-20 List Moderator ReSent-To: TOPS-20 Distribution: ; ReSent-Subject: Re: klh10 compilation error ReSent-Message-ID: ReSent-User-Agent: Alpine 0.99999 (OSX 833 2007-11-27) Okay, that seemed to work all right. Now the only problem is that if I'm running it on the laptop, it issues a warning about the ethernet port (actually the wireless port) not being dedicated. And in fact I can't seem to get in or out of the -20 using Telnet. I tried assigning a second IP address to it in System Preferences (the IP address that I want to use for the -20), but that didn't help. (I suspect that this was not the Right Thing, as it means now that both the host OS and KLH are vying for the same packets.) Can the two share a port, or must the port be dedicated to one XOR the other? Thanks, John On 28 Nov 2007, at 1:53, Mark Crispin wrote: > On Wed, 28 Nov 2007, John Francini wrote: >> Ah. You set *ALL* the executables that are part of the KLH10 >> 'microcode engine suite' to setuid root. Let me poke around and try >> that. > > dpni20 is the only thing that must be setuid root. However, if > kn10-kl is also setuid root, then it can lock itself in memory > which will make it run better. > > [For KS-ITS builds, that is dpimp and kn10-ks...] > > -- Mark -- > > http://panda.com/tops-20 > TOPS-20: a great improvement over its successors > 28-Nov-2007 10:59:35-PST,3062;000000000000 Return-Path: Received: from pangtzu.panda.com ([206.124.149.117]) by Lingling.Panda.COM with TCP/SMTP; Wed, 28 Nov 2007 10:55:55 -0800 (PST) X-Return-Path: X-Received: from pangtzu.panda.com ([206.124.149.117]) by Lingling.Panda.COM with TCP/SMTP; Wed, 28 Nov 2007 10:54:27 -0800 (PST) Date: Wed, 28 Nov 2007 10:54:24 -0800 (PST) From: Mark Crispin Sender: mrc@pangtzu.panda.com To: John Francini cc: TOPS-20 Hackers and Yackers Subject: Re: klh10 compilation error In-Reply-To: <6A887C3F-FE06-4DB4-9234-636476185913@mac.com> Message-ID: References: <71A2055F-3D81-4473-9586-3BA62D7603DF@mac.com> <6794963A-1469-418B-9CE8-B694DDE5CF9F@mac.com> <6A887C3F-FE06-4DB4-9234-636476185913@mac.com> User-Agent: Alpine 0.99999 (OSX 833 2007-11-27) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed ReSent-Date: Wed, 28 Nov 2007 10:55:48 -0800 (PST) ReSent-From: TOPS-20 List Moderator ReSent-To: TOPS-20 Distribution: ; ReSent-Subject: Re: klh10 compilation error ReSent-Message-ID: ReSent-User-Agent: Alpine 0.99999 (OSX 833 2007-11-27) Please review the instructions in the panda-dist/README file. To answer your specific questions: klh10 and the host system's TCP can share an Ethernet interface, but not an IP address. The IP address for klh10 MUST be a different IP address from the host system. The host system MUST NOT use klh10's IP address in any way (including listing it in System Preferences in Mac OS X). The IP address for klh10 must be configured both in klh10 (in the klt20.ini file) and in TOPS-20 (in the SYSTEM:INTERNET.ADDRESS file). Note that there is considerable other configuration to do at the TOPS-20 end, as described in the README file. I have two 24/7 TOPS-20 machines. One which has a dedicated Ethernet interface for klh10 (hence has two Ethernet interfaces). The other, a Mac, shares the interface. The instruction that I provide are for shared interfaces. Due to the way that UNIX works with shared interfaces, it is not possible for the TOPS-20 system behind a shared interface to access the host UNIX system on the shared interface. Dedicated interfaces don't have that problem. Put another way: my TOPS-20 system with a dedicated interface (Lingling) can talk to its host Linux system (Meimei) because Meimei doesn't share its interface with Lingling. My TOPS-20 system with a shared interface (Hsinghsing) can not talk to its host Mac system (Pangtzu) because the interface is shared. -- Mark -- http://panda.com/tops-20 TOPS-20: a great improvement over its successors 28-Nov-2007 21:27:32-PST,3823;000000000000 Return-Path: Received: from pangtzu.panda.com ([206.124.149.117]) by Lingling.Panda.COM with TCP/SMTP; Wed, 28 Nov 2007 21:23:43 -0800 (PST) X-Return-Path: X-Received: from chip8og54.obsmtp.com ([64.18.15.181]) by Lingling.Panda.COM with TCP/SMTP; Wed, 28 Nov 2007 11:24:58 -0800 (PST) X-Received: from source ([12.110.134.31]) by chip8ob54.postini.com ([64.18.7.12]) with SMTP; Wed, 28 Nov 2007 11:24:50 PST X-Received: from [10.127.250.241] ([10.127.250.241]) by M31.equallogic.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Wed, 28 Nov 2007 14:22:06 -0500 In-Reply-To: References: <71A2055F-3D81-4473-9586-3BA62D7603DF@mac.com> <6794963A-1469-418B-9CE8-B694DDE5CF9F@mac.com> <6A887C3F-FE06-4DB4-9234-636476185913@mac.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <91930559-0AB6-409E-9D6E-3C2B07E30C6D@mac.com> Cc: TOPS-20 Hackers and Yackers Content-Transfer-Encoding: 7bit From: John Francini Subject: Re: klh10 compilation error Date: Wed, 28 Nov 2007 14:21:56 -0500 To: Mark Crispin X-Mailer: Apple Mail (2.752.3) X-Return-Path: francini@mac.com X-OriginalArrivalTime: 28 Nov 2007 19:22:06.0713 (UTC) FILETIME=[F6C74E90:01C831F3] ReSent-Date: Wed, 28 Nov 2007 21:23:33 -0800 (PST) ReSent-From: TOPS-20 List Moderator ReSent-To: TOPS-20 Distribution: ; ReSent-Subject: Re: klh10 compilation error ReSent-Message-ID: ReSent-User-Agent: Alpine 0.99999 (OSX 835 2007-11-28) Gotcha. I'll review everything tonight or tomorrow; I know I've got something messed up somewhere in the config. Thanks! John On 28 Nov 2007, at 13:54, Mark Crispin wrote: > Please review the instructions in the panda-dist/README file. > > To answer your specific questions: > > klh10 and the host system's TCP can share an Ethernet interface, > but not an IP address. > > The IP address for klh10 MUST be a different IP address from the > host system. The host system MUST NOT use klh10's IP address in > any way (including listing it in System Preferences in Mac OS X). > > The IP address for klh10 must be configured both in klh10 (in the > klt20.ini file) and in TOPS-20 (in the SYSTEM:INTERNET.ADDRESS > file). Note that there is considerable other configuration to do at > the TOPS-20 end, as described in the README file. > > I have two 24/7 TOPS-20 machines. One which has a dedicated > Ethernet interface for klh10 (hence has two Ethernet interfaces). > The other, a Mac, shares the interface. The instruction that I > provide are for shared interfaces. > > Due to the way that UNIX works with shared interfaces, it is not > possible for the TOPS-20 system behind a shared interface to access > the host UNIX system on the shared interface. Dedicated interfaces > don't have that problem. > > Put another way: my TOPS-20 system with a dedicated interface > (Lingling) can talk to its host Linux system (Meimei) because > Meimei doesn't share its interface with Lingling. My TOPS-20 > system with a shared interface (Hsinghsing) can not talk to its > host Mac system (Pangtzu) because the interface is shared. > > -- Mark -- > > http://panda.com/tops-20 > TOPS-20: a great improvement over its successors 7-Dec-2007 20:24:16-PST,2132;000000000000 Return-Path: Received: from pangtzu.panda.com ([206.124.149.117]) by Lingling.Panda.COM with TCP/SMTP; Fri, 7 Dec 2007 20:20:13 -0800 (PST) X-Return-Path: X-Received: from vsta.org ([208.70.148.177]) by Lingling.Panda.COM with TCP/SMTP; Sun, 2 Dec 2007 13:20:24 -0800 (PST) X-Received: from [192.168.1.2] (localhost [127.0.0.1]) by vsta.org (Postfix) with ESMTP id 856B3AD16D for ; Sun, 2 Dec 2007 15:19:51 -0600 (CST) From: Andy Valencia To: TOPS-20@lingling.panda.com Subject: Help with dual RP07 system structure Date: Sun, 2 Dec 2007 13:20:19 -0800 User-Agent: KMail/1.9.6 (enterprise 0.20070907.709405) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200712021320.19385.vandys@vsta.org> ReSent-Date: Fri, 7 Dec 2007 20:20:07 -0800 (PST) ReSent-From: TOPS-20 List Moderator ReSent-To: TOPS-20 Distribution: ; ReSent-Subject: Help with dual RP07 system structure ReSent-Message-ID: ReSent-User-Agent: Alpine 1.00 (OSX 856 2007-12-08) Hi, I've just been added to this mailing list, and since my query on alt.sys.pdp10 hasn't yielded any responses, I'll ask here. Apologies if this is a repeat for any of you. I'm currently running the Panda distribution (TOPS-20) and am trying to create a new structure holding a pair of RP07's in raw format. I've created the disk space, added them to klt20.ini, and TOPS-20 seems to see them (more or less) on bootup. But when I try to initialize them with CHECKD, it fails with: ? JSYS ERROR: Could not write HOME blocks Tracing the simulator's I/O process for the unit, this error does not correspond to any simulator I/O underneath. Do I need to initialize these (blank, zero'ed) disk images in some other way before attempting to define the structure in CHECKD? Thanks, Andy Valencia 9-Dec-2007 09:43:55-PST,6804;000000000000 Return-Path: Received: from pangtzu.panda.com ([206.124.149.117]) by Lingling.Panda.COM with TCP/SMTP; Sun, 9 Dec 2007 09:39:41 -0800 (PST) X-Return-Path: X-Received: from mta4.srv.hcvlny.cv.net ([167.206.4.199]) by Lingling.Panda.COM with TCP/SMTP; Sun, 9 Dec 2007 09:11:44 -0800 (PST) X-Received: from [192.168.1.7] (ool-45720130.dyn.optonline.net [69.114.1.48]) by mta4.srv.hcvlny.cv.net (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTP id <0JSS00HHIL3EWIN0@mta4.srv.hcvlny.cv.net> for TOPS-20@lingling.panda.com; Sun, 09 Dec 2007 12:11:39 -0500 (EST) Date: Sun, 09 Dec 2007 12:11:37 -0500 From: Thomas DeBellis Subject: DELNF% is very disrespectful to DF%NRJ In-reply-to: <200712021320.19385.vandys@vsta.org> To: Tops-20 Wizards Message-id: <475C21C9.4010207@optonline.net> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en References: <200712021320.19385.vandys@vsta.org> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) ReSent-Date: Sun, 9 Dec 2007 09:39:33 -0800 (PST) ReSent-From: TOPS-20 List Moderator ReSent-To: TOPS-20 Distribution: ; ReSent-Subject: DELNF% is very disrespectful to DF%NRJ ReSent-Message-ID: ReSent-User-Agent: Alpine 1.00 (OSX 856 2007-12-08) Symptom: ======== DELNF% does not respect the setting of DF%NRJ: whether or not the bit is set, the JFN is not released. The Tops-20 Monitor Calls Reference Manual says that this is supposed to work (see section 3.33) Workaround: =========== Either assume it doesn't work, always set DF%NRJ and do the RLJFN% yourself or use DELF% in a loop. Background: =========== Because 'modern' graphical FTP clients remain unenlighted about versioned file systems, I don't display generations when doing directory listings (LIST, NLST or STAT verbs). However, for DELE (delete) and RNTO/RNFR (rename), I did not write any special code for generations--exactly one file is processed per verb. The default was generation zero. This led to the situation of the deletion of a file in the graphical client apparently doing nothing. For files with a large number of generations, you could select the file and delete it all you wanted and it would still be there. Same deal with the rename. Renames were particularly heinous because of the above generation default (I.E., the highest). Once you're done doing all of the renames, the versions of the file were in the exact opposite order of the creation dates. Bad ... So now when the server is running in TVFS mode, I silently handle all generations of a file for the DELE, RNTO and RNFR verbs. Both operations are processed by the control fork for a file with a single generation and by the data fork for multiple generations. RNTO and RNFR are handled by a loop. When I got to fixing DELE, I noticed the DELNF% JSYS (having completely forgotten what the DELF% mnemonic was). Initial cursory tests seemed to indicate that DELNF% was a LOT faster than DELF%. As some portion of this could be attributed to the reduction in JSYS overhead, I decided to bum the RLJFN% and not set DF%NRJ. But ... Example: ======== !direct eftpsa.rel STAR: EFTPSA.REL.71,72,73,74,75,76,77,78,79,80,81,82,83,84,85,86,87,88,89 Total of 1958 pages in 27 files !get eftpsr !reenter 220 TOMMYT TOPS20 FTP Server V7.1(14557) on Sun Dec 9, 2007 9:59:53AM-EST EFTPSER>site transfer synchronous 200 Control fork will wait for data fork command completion EFTPSER>site tvfs on 200 TVFS Mode: ON (Unix filepaths), Unix filepath recognition: automatic EFTPSER>site ddt 200-Starting debug. $0B>>DEBUG#/ MOVE T1,SITLIT#+635 $w SDELE+15/ TLO T1,400000 .$b $p 200 End of DDT. EFTPSER>abor 226 ABOR command successful EFTPSER>dele eftpsa.rel 250-Deleting all generations of /STAR/FTP/EFTPSA.REL $1B>>SDELE#+15/ TLO T1,400000 jfcl $x 10000 SDELE#+16/ SETZ T2,0 $x T2/ 0 SDELE#+17/ DELNF% 1[ 5 1,,T2[ 0 ^C !information file 5 5 EFTPSA.REL.89 Not opened !continue $x SDELE#+21/ MOVE Q1,T2 ^C !iNFORMATION (ABOUT) filE-STATUS (OF JFN) 5 5 EFTPSA.REL.89 Not opened <==== !!!!!! Analysis: ========= DELNF% is implemented in JSYSF.MAC at .DELNF (oddly enough). A review shows that DF%NRJ is never checked and that, in any event, there is no code to ever punt the JFN. The following lines in the edit history show that .DELNF was being worked on at some point: ; *** Edit 7253 to JSYSF.MAC by LOMARTIRE on 5-Mar-86, for SPR #21029 ; Make .DELNF honor the FB%NDL bit One might speculate some kind of mis-teco'ing here may have sent the relevant code into oblivion. My inclination is to doubt that. Judging from what I'm seeing, I think it more likely that it never existed in the first place. Solution: ========= If this is a documentation error, then update section 3.33 by eliminating any reference to DF%NRJ. Otherwise, make DELNF% do what 3.33 says it's supposed to do. It seems easy enough to implement the functionality as DELNF%'s operation is fairly straightforward. After some initial routine checking, it gets a pointer to the file's descriptor block via GETFDB, which returns with the directory locked. Then it stays in a loop (DELNF2), poking the delete bit of candidate files (some are skipped for various reasons) via a SETONE FBDEL,(A). I believe that this may explain perhaps the major part of the increase in speed: the overhead of directory/file locking and unlocking is eliminated. Once the loop is finished doing its thing, all that remains to be done is to finish off the JFN as indicated. Perhaps at DELNFE+4, after the directory is unmapped (via ULKDIR), replace the call to UNLCKF with the following? UMOVE A,1 ; Pick up the user's flags IFXN. A,DF%NRJ ; Wants to hang on to this JFN? TQNE ; BUT!! Is this file open? ANSKP. ; Bad idea to release it MOVEI A,0(JFN) ; Otherwise, get the JFN CALL LUNLK0 ; Free the structure lock CALL RELJFN ; Release the JFN ELSE. ; Otherwise, keeping the JFN CALL UNLCKF ; so just unlock the file ENDIF. 9-Dec-2007 09:47:31-PST,8759;000000000000 Return-Path: Received: from pangtzu.panda.com ([206.124.149.117]) by Lingling.Panda.COM with TCP/SMTP; Sun, 9 Dec 2007 09:40:12 -0800 (PST) X-Return-Path: X-Received: from pangtzu.panda.com ([206.124.149.117]) by Lingling.Panda.COM with TCP/SMTP; Sun, 9 Dec 2007 09:38:26 -0800 (PST) X-Return-Path: X-Received: from mta3.srv.hcvlny.cv.net ([167.206.4.198]) by Lingling.Panda.COM with TCP/SMTP; Sun, 9 Dec 2007 06:42:54 -0800 (PST) X-Received: from [192.168.1.7] (ool-45720130.dyn.optonline.net [69.114.1.48]) by mta3.srv.hcvlny.cv.net (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTP id <0JSS004R1E7281C0@mta3.srv.hcvlny.cv.net> for mrc@Lingling.Panda.COM; Sun, 09 Dec 2007 09:42:39 -0500 (EST) Date: Sun, 09 Dec 2007 09:42:37 -0500 From: Thomas DeBellis Subject: Re: Help with dual RP07 system structure In-reply-to: <200712021320.19385.vandys@vsta.org> To: Andy Valencia Cc: Mark Crispin Message-id: <475BFEDD.1090300@optonline.net> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en References: <200712021320.19385.vandys@vsta.org> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-ReSent-Date: Sun, 9 Dec 2007 09:38:19 -0800 (PST) X-ReSent-From: Mark Crispin X-ReSent-To: TOPS-20 Hackers and Yackers X-ReSent-Subject: Re: Help with dual RP07 system structure X-ReSent-Message-ID: X-ReSent-User-Agent: Alpine 1.00 (OSX 856 2007-12-08) ReSent-Date: Sun, 9 Dec 2007 09:40:00 -0800 (PST) ReSent-From: TOPS-20 List Moderator ReSent-To: TOPS-20 Distribution: ; ReSent-Subject: Re: Help with dual RP07 system structure ReSent-Message-ID: ReSent-User-Agent: Alpine 1.00 (OSX 856 2007-12-08) Well, take heart: it CAN be done. I know this because I've been running a two pack RP07 PS: structure since the beginning of March of this year. I probably would have been doing it a LOT longer, but I didn't want to take my machine down to do the conversion as I was trying to set an uptime record (which I eventually did: 6-Dec-2005 01:47:13 to 7-Jan-2007 17:57:46, over 397 days). Since it works for me (and others), this suggests that your KLH micro- engine does not have a problem in and of itself. Other than re- compiling it and specifically targeting it for your particular host machine, I probably wouldn't waste time trying to debug the issue at this level. However, I do think that such time learning its internals will be well spent when you want to contribute to the Tops-20 EEE effort. That's Extended Extended Edition: a PDP-10 that will handle more than 37 (octal) sections, but less than 7777. I've been thinking about making that my next project after getting the new FTP server done (see below). Because I am concentrating on getting a brand new version of the Tops-20 FTP server ready, I won't be able to closely help you trouble shoot your issue. Other than reporting and hopefully fixing bugs that I run into while developing it, I'm restricting myself to doing nothing else. However here are a few things that might help. Below are the relevant lines from my own klt20.ini: ; Allocate different RH20 controllers for BS (Boot Structure) devdef rh0 540 rh20 devdef rh2 550 rh20 ; Two Pack RP07 PS: structure on an entirely different host disk devdef dsk0 rh0.0 rp type=rp07 path=/disks/C/tommyt-ps0 format=dbd9 devdef dsk1 rh2.0 rp type=rp07 path=/disks/C/tommyt-ps1 format=dbd9 You will notice that I have these two units on different massbus controllers (RH20's). I did this because it can get you some extra speed. But I don't think that I got much of anything because, as you can see, I have both packs on the same physical media. Here's what they look like on the host system: total 973025 drwxrwxrwx 2 root root 16384 Dec 31 1969 . drwxr-xr-x 3 root root 72 Jul 11 2003 .. -rw-rw-rw- 1 root root 498044160 Dec 9 08:10 tommyt-ps0 -rw-rw-rw- 1 root root 498265344 Dec 9 08:13 tommyt-ps1 You'll note that the files are owned by root. Are you running everything as root? That can make klh10 perform a little better (and must be done in order for certain things to work). Instead of getting into klh10's guts, have you have you checked to see how the disks are showing up to Tops-20? An error like that might be explained by the disks not being write-enabled. Run chans and have a look: $chans Options (any of C=CDB, K=KDB, U=UDB, T=tapes, D=disks, V=video): Block Addr Chan Ctrl Unit Device Type Cyl/File Sec/Rec DSN Status CDB 664007 0 RH20 UDB 664101 0 -1 0 TOMMYT RP07 442 1720 1 CDB 664247 1 RH20 KDB 664341 1 0 TM03 UDB 664371 1 0 0 MTA0 TU45 0 0 1 Offline CDB 664467 2 RH20 UDB 664561 2 -1 0 TOMMYT RP07 440 1424 2 CDB 665027 3 RH20 UDB 665121 3 -1 0 STAR RP07 603 2010 3 UDB 665261 3 -1 1 TOPS20 RP07 117 530 4 CDB 665427 5 NI See what MOUNTR thinks by running OPR and doing: $OPR OPR>show status disk-drive /all OPR> 08:30:43 -- Disk Drive Status -- DISK DRIVE INFORMATION DISK PACK INFORMATION Chan-Cont Disk Mount Mount Usage Type Drive Status Status Count Name Options ---- --------- -------- ------- ----- ------------ -------------------------- RP07 0, ,0 Avail Mounted 0 TOMMYT (1/2) RP07 2, ,0 Avail Mounted 0 TOMMYT (2/2) RP07 3, ,0 Avail Mounted 8 STAR (1/1) Excl RP07 3, ,1 Avail Mounted 3 TOPS20 (1/1) Excl OPR>show status structure /all OPR> 08:31:23 -- Structure Status -- Mount Mount File Alias Name State Count Count Status Access Accounting ------ ------ ------- ----- ----- -------- -------------------- --------------- TOMMYT TOMMYT Mounted 0 112 Avail Shared ## Primary Public Str. ## STAR STAR Mounted 8 2 Avail Exclusive Domestic Regulated TOPS20 TOPS20 Mounted 3 0 Avail Exclusive Domestic Regulated DOUBLE Avail Shared Domestic Unregulated Tops-20 has a LOT of utilities to deal with disks, hardware and the like; go nose around in PS: directory. I suggest closely reading MGR_GUIDE.MEM, OP_GUIDE.MEM and OPRCOM.MEM (perhaps in that order). Better still, go look at the source for CHECKD.MAC and breakpoint the failing JSYS and then look it up in JSYS_REFERENCE.MEM. Learn about it. Then look in the monitor sources. See why it would be doing what it's doing. Finally, be sure to NEVER cross post between alt.sys.pdp10 and Tops-20!!! We're engineers here and spam REALLY annoys us more than you might imagine (among other things because of the missed technical opportunities to address the issue). This particular list is moderated and is more concerned with the technical issues of running Tops-20. This frequently includes finding and (but more importantly) fixing bugs. If I do post about a problem here, I try not to do so without specifically identifying the relevant code, giving an analysys, suggesting an alternative and possibly fixing it. See my next post as perhaps an example of this. Although a number of us here also read alt.sys.pdp10, not all of us care to wade through all the opinions that are (sometimes vehemently) expressed there (even though I personally would have LOVED to see multi-processor Tops-20! :-) Put bluntly, the Tops-20 list is the place where you win fame, honor and recognition by solving problems, most laudably via programming. So let us all know what you come up with so the knowledge doesn't get lost. Some may say it's a little late in the game for you to get into all of this. Phooey! It's never too late to find bugs, fix them, develop new functionality, imagine new features and just plain look at things differently. Rejoice. PS: MRC, I wasn't sure if this should have been posted to Tops-20. Please forward it if you feel it is appropriate. 9-Dec-2007 10:19:38-PST,3187;000000000000 Return-Path: Received: from pangtzu.panda.com ([206.124.149.117]) by Lingling.Panda.COM with TCP/SMTP; Sun, 9 Dec 2007 10:15:59 -0800 (PST) X-Return-Path: X-Received: from pangtzu.panda.com ([206.124.149.117]) by Lingling.Panda.COM with TCP/SMTP; Sun, 9 Dec 2007 10:07:19 -0800 (PST) Date: Sun, 9 Dec 2007 10:07:15 -0800 (PST) From: Mark Crispin Sender: mrc@pangtzu.panda.com To: Thomas DeBellis cc: TOPS-20 Hackers and Yackers Subject: Re: Help with dual RP07 system structure In-Reply-To: <475BFEDD.1090300@optonline.net> Message-ID: References: <200712021320.19385.vandys@vsta.org> <475BFEDD.1090300@optonline.net> User-Agent: Alpine 1.00 (OSX 856 2007-12-08) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII ReSent-Date: Sun, 9 Dec 2007 10:15:54 -0800 (PST) ReSent-From: TOPS-20 List Moderator ReSent-To: TOPS-20 Distribution: ; ReSent-Subject: Re: Help with dual RP07 system structure ReSent-Message-ID: ReSent-User-Agent: Alpine 1.00 (OSX 856 2007-12-08) On Sun, 9 Dec 2007, Thomas DeBellis wrote: > Tops-20 EEE effort. That's > Extended Extended Edition: a PDP-10 that will handle more than 37 > (octal) sections, but less than 7777. I've been thinking about making > that my next project after getting the new FTP server done (see > below). I agree that this is a high priority project, and we should be able to do up to section 777 without having to do all the pager and I/O system redesign work that Ralph had to do in XKL. However, I think that there is a higher priority project related to networking capability, specifically: (1) We need a DHCP client + NAT, for the benefit of running on systems (especially laptops and mobile devices) where assigning a fixed IP address is not practical. My idea is that at the TOPS-20 end you configure it with an IP address of something like 192.168.1.1, and let KLH10 NAT it to whatever address it got from DHCP. Of course, that also means that KLH10 must get a separate IP address from the host machine via DHCP. This would make KLH10 completely plug and play on non-fixed IP address systems. (2) We need an SSH server. Rather than try to port SSH to TOPS-20, my idea is to implement SSH ports as FE TTY lines as far as TOPS-20 is concerned. This isn't as awful as it sounds, especially if we translate some of the SSH stuff to front end protocol. Another thing on my list is to add a disk type that is maximum sized for TOPS-20 to handle and is addressed by page rather than by sector. This isn't particularly difficult, but it requires me to get A Round Tuit. This would create a 4 million page disk (8GB), which is about 16 times the RP07 and 4 times the infamous SCORE 4xRP07. That ought to be enough for TOPS-20 folks for the conceivable future... ;-) -- Mark -- http://panda.com/tops-20 TOPS-20: a great improvement over its successors 9-Dec-2007 10:23:15-PST,3187;000000000000 Return-Path: Received: from pangtzu.panda.com ([206.124.149.117]) by Lingling.Panda.COM with TCP/SMTP; Sun, 9 Dec 2007 10:16:50 -0800 (PST) X-Return-Path: X-Received: from pangtzu.panda.com ([206.124.149.117]) by Lingling.Panda.COM with TCP/SMTP; Sun, 9 Dec 2007 10:07:19 -0800 (PST) Date: Sun, 9 Dec 2007 10:07:15 -0800 (PST) From: Mark Crispin Sender: mrc@pangtzu.panda.com To: Thomas DeBellis cc: TOPS-20 Hackers and Yackers Subject: Re: Help with dual RP07 system structure In-Reply-To: <475BFEDD.1090300@optonline.net> Message-ID: References: <200712021320.19385.vandys@vsta.org> <475BFEDD.1090300@optonline.net> User-Agent: Alpine 1.00 (OSX 856 2007-12-08) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII ReSent-Date: Sun, 9 Dec 2007 10:16:43 -0800 (PST) ReSent-From: TOPS-20 List Moderator ReSent-To: TOPS-20 Distribution: ; ReSent-Subject: Re: Help with dual RP07 system structure ReSent-Message-ID: ReSent-User-Agent: Alpine 1.00 (OSX 856 2007-12-08) On Sun, 9 Dec 2007, Thomas DeBellis wrote: > Tops-20 EEE effort. That's > Extended Extended Edition: a PDP-10 that will handle more than 37 > (octal) sections, but less than 7777. I've been thinking about making > that my next project after getting the new FTP server done (see > below). I agree that this is a high priority project, and we should be able to do up to section 777 without having to do all the pager and I/O system redesign work that Ralph had to do in XKL. However, I think that there is a higher priority project related to networking capability, specifically: (1) We need a DHCP client + NAT, for the benefit of running on systems (especially laptops and mobile devices) where assigning a fixed IP address is not practical. My idea is that at the TOPS-20 end you configure it with an IP address of something like 192.168.1.1, and let KLH10 NAT it to whatever address it got from DHCP. Of course, that also means that KLH10 must get a separate IP address from the host machine via DHCP. This would make KLH10 completely plug and play on non-fixed IP address systems. (2) We need an SSH server. Rather than try to port SSH to TOPS-20, my idea is to implement SSH ports as FE TTY lines as far as TOPS-20 is concerned. This isn't as awful as it sounds, especially if we translate some of the SSH stuff to front end protocol. Another thing on my list is to add a disk type that is maximum sized for TOPS-20 to handle and is addressed by page rather than by sector. This isn't particularly difficult, but it requires me to get A Round Tuit. This would create a 4 million page disk (8GB), which is about 16 times the RP07 and 4 times the infamous SCORE 4xRP07. That ought to be enough for TOPS-20 folks for the conceivable future... ;-) -- Mark -- http://panda.com/tops-20 TOPS-20: a great improvement over its successors 9-Dec-2007 10:26:47-PST,1818;000000000000 Return-Path: Received: from pangtzu.panda.com ([206.124.149.117]) by Lingling.Panda.COM with TCP/SMTP; Sun, 9 Dec 2007 10:17:07 -0800 (PST) X-Return-Path: X-Received: from pangtzu.panda.com ([206.124.149.117]) by Lingling.Panda.COM with TCP/SMTP; Sun, 9 Dec 2007 10:15:49 -0800 (PST) Date: Sun, 9 Dec 2007 10:15:45 -0800 (PST) From: Mark Crispin Sender: mrc@pangtzu.panda.com To: Thomas DeBellis cc: Tops-20 Wizards Subject: Re: DELNF% is very disrespectful to DF%NRJ In-Reply-To: <475C21C9.4010207@optonline.net> Message-ID: References: <200712021320.19385.vandys@vsta.org> <475C21C9.4010207@optonline.net> User-Agent: Alpine 1.00 (OSX 856 2007-12-08) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed ReSent-Date: Sun, 9 Dec 2007 10:17:02 -0800 (PST) ReSent-From: TOPS-20 List Moderator ReSent-To: TOPS-20 Distribution: ; ReSent-Subject: Re: DELNF% is very disrespectful to DF%NRJ ReSent-Message-ID: ReSent-User-Agent: Alpine 1.00 (OSX 856 2007-12-08) On Sun, 9 Dec 2007, Thomas DeBellis wrote: > DELNF% does not respect the setting of DF%NRJ: whether or not the > bit is set, the JFN is not released. The Tops-20 Monitor Calls > Reference Manual says that this is supposed to work (see section > 3.33) This is clearly a documentation bug. DELNF% has never released the JFN since Tenex days, and making it do so unless a bit was set would break compatibility with old programs. -- Mark -- http://panda.com/tops-20 TOPS-20: a great improvement over its successors 9-Dec-2007 21:43:20-PST,2897;000000000000 Return-Path: Received: from pangtzu.panda.com ([206.124.149.117]) by Lingling.Panda.COM with TCP/SMTP; Sun, 9 Dec 2007 21:39:17 -0800 (PST) X-Return-Path: X-Received: from mta2.srv.hcvlny.cv.net ([167.206.4.197]) by Lingling.Panda.COM with TCP/SMTP; Sun, 9 Dec 2007 19:41:22 -0800 (PST) X-Received: from [192.168.1.7] (ool-45720130.dyn.optonline.net [69.114.1.48]) by mta2.srv.hcvlny.cv.net (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTP id <0JST00CVDE8TPW40@mta2.srv.hcvlny.cv.net>; Sun, 09 Dec 2007 22:41:17 -0500 (EST) Date: Sun, 09 Dec 2007 22:41:16 -0500 From: Thomas DeBellis Subject: Re: DELNF% is very disrespectful to DF%NRJ In-reply-to: To: Mark Crispin Cc: Tops-20 Wizards Message-id: <475CB55C.4060301@optonline.net> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en References: <200712021320.19385.vandys@vsta.org> <475C21C9.4010207@optonline.net> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) ReSent-Date: Sun, 9 Dec 2007 21:39:11 -0800 (PST) ReSent-From: TOPS-20 List Moderator ReSent-To: TOPS-20 Distribution: ; ReSent-Subject: Re: DELNF% is very disrespectful to DF%NRJ ReSent-Message-ID: ReSent-User-Agent: Alpine 1.00 (OSX 856 2007-12-08) > This is clearly a documentation bug. DELNF% has never released the > JFN since Tenex days, and making it do so unless a bit was set would > break compatibility with old programs. A documentation bug, eh? That won't be any fun to fix (I.E., no coding), but I do agree. I searched around for every program that I could find that uses DELNF% and found a number (PA1050 being a notable example). All expect this behavior. This appears to have been mis-documented for a long time. I went downstairs and managed to pull out my April 1982 copy of the JSYS reference manual for Tops-20 version 4. Same deal. The online INFO documentation for version 3A also says the same thing: DELNF% was supposed to know about DF%NRJ. What's interesting is that the TENEX manual doesn't say anything about DF%NRJ for DELNF% (for DELF%, DF%NRJ is called B0). However, at that point (1973), DELNF% was defined to return the NEGATIVE number of files deleted in AC2, whereas Tops-20 says it gives a POSTIVE count. At DELNFE+2, Tops-20 is doing an XCTU [MOVNM Q1,2] of a negative number, so I guess I'll believe that. So, they clearly changed the JSYS. Maybe they only changed it half way... 9-Dec-2007 22:03:23-PST,2971;000000000000 Return-Path: Received: from pangtzu.panda.com ([206.124.149.117]) by Lingling.Panda.COM with TCP/SMTP; Sun, 9 Dec 2007 21:59:44 -0800 (PST) X-Return-Path: X-Received: from pangtzu.panda.com ([206.124.149.117]) by Lingling.Panda.COM with TCP/SMTP; Sun, 9 Dec 2007 21:59:14 -0800 (PST) Date: Sun, 9 Dec 2007 21:59:10 -0800 (PST) From: Mark Crispin Sender: mrc@pangtzu.panda.com To: Thomas DeBellis cc: Tops-20 Wizards Subject: Re: DELNF% is very disrespectful to DF%NRJ In-Reply-To: <475CB55C.4060301@optonline.net> Message-ID: References: <200712021320.19385.vandys@vsta.org> <475C21C9.4010207@optonline.net> <475CB55C.4060301@optonline.net> User-Agent: Alpine 1.00 (OSX 856 2007-12-08) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII ReSent-Date: Sun, 9 Dec 2007 21:59:38 -0800 (PST) ReSent-From: TOPS-20 List Moderator ReSent-To: TOPS-20 Distribution: ; ReSent-Subject: Re: DELNF% is very disrespectful to DF%NRJ ReSent-Message-ID: ReSent-User-Agent: Alpine 1.00 (OSX 856 2007-12-08) On Sun, 9 Dec 2007, Thomas DeBellis wrote: > What's interesting is that the TENEX manual doesn't say anything about > DF%NRJ for DELNF% (for DELF%, DF%NRJ is called B0). In Tenex, AC1 contains only the JFN in DELNF; there are no flags. > However, at that > point (1973), DELNF% was defined to return the NEGATIVE number of > files deleted in AC2, whereas Tops-20 says it gives a POSITIVE count. > At DELNFE+2, Tops-20 is doing an XCTU [MOVNM Q1,2] of a negative > number, so I guess I'll believe that. So, they clearly changed the > JSYS. Maybe they only changed it half way... Yup. Tenex does UMOVEM E,2 in DELNFE. Definitely a change made in TOPS-20. There are several of these strange incompatibilities between Tenex and TOPS-20 for no apparent reason. I had to consider carefully what I wanted to do with LITES and SWTCH when I made those work once again after three decades of being useless. In Tenex, SWTCH always succeeds and returned +1, just like the SWITCH UUO on TOPS-10; in TOPS-20, it requires WOPR/MAINT and had a +1 fail return and +2 success return. Similarly, although both Tenex and TOPS-20 require WOPR/MAINT for LITES Tenex has an ITRAP, and TOPS-20 has +1/+2 returns. To make things worse, TOPS-20 PA1050 expected the Tenex behavior. What made this particularly wierd is that TOPS-20 standardized on ITRAP and using ERJMP/ERCAL rather than TOPS-10 style +1/+2 returns. I eventually decided to keep the different monitor behavior, and fix PA1050. -- Mark -- http://panda.com/tops-20 TOPS-20: a great improvement over its successors 11-Dec-2007 22:40:11-PST,2787;000000000000 Return-Path: Received: from pangtzu.panda.com ([206.124.149.117]) by Lingling.Panda.COM with TCP/SMTP; Tue, 11 Dec 2007 22:36:15 -0800 (PST) X-Return-Path: X-Received: from mail2.panix.com ([166.84.1.73]) by Lingling.Panda.COM with TCP/SMTP; Mon, 10 Dec 2007 13:56:10 -0800 (PST) X-Received: from panix5.panix.com (panix5.panix.com [166.84.1.5]) by mail2.panix.com (Postfix) with ESMTP id 589F234816; Mon, 10 Dec 2007 16:56:05 -0500 (EST) X-Received: (from alderson@localhost) by panix5.panix.com (8.11.6p3/8.8.8/PanixN1.1) id lBALpLx03517; Mon, 10 Dec 2007 16:51:21 -0500 (EST) Date: Mon, 10 Dec 2007 16:51:21 -0500 (EST) Message-Id: <200712102151.lBALpLx03517@panix5.panix.com> From: Rich Alderson To: Mark Crispin CC: slogin@optonline.net, TOPS-20 Distribution: ;, TOPS-20@Lingling.Panda.COM In-reply-to: (message from Mark Crispin on Sun, 9 Dec 2007 10:07:15 -0800 (PST)) Subject: Re: Help with dual RP07 system structure References: <200712021320.19385.vandys@vsta.org> <475BFEDD.1090300@optonline.net> ReSent-Date: Tue, 11 Dec 2007 22:36:08 -0800 (PST) ReSent-From: TOPS-20 List Moderator ReSent-To: TOPS-20 Distribution: ; ReSent-Subject: Re: Help with dual RP07 system structure ReSent-Message-ID: ReSent-User-Agent: Alpine 1.00 (OSX 862 2007-12-11) > Date: Sun, 9 Dec 2007 10:07:15 -0800 (PST) > From: Mark Crispin > Another thing on my list is to add a disk type that is maximum sized for > TOPS-20 to handle and is addressed by page rather than by sector. This > isn't particularly difficult, but it requires me to get A Round Tuit. > This would create a 4 million page disk (8GB), which is about 16 times the > RP07 and 4 times the infamous SCORE 4xRP07. That ought to be enough for > TOPS-20 folks for the conceivable future... ;-) We need two variants, one addressing sectors as well as Mark's proposal. Those of us who use KLH10 to test software installations and the like for running hardware need something for another operating system than the one licensed for discussion on this list. We are finishing the prototype phase of a hardware replacement for 25-year-old disk drives that attaches to a Massbus; the hardware guy saw all the available bits in the RH11/RH20 registers and asked why we couldn't have a larger "disk". It would be nice to be able to move images between KLH10 and the MDE. Rich 11-Dec-2007 23:18:27-PST,2658;000000000000 Return-Path: Received: from pangtzu.panda.com ([206.124.149.117]) by Lingling.Panda.COM with TCP/SMTP; Tue, 11 Dec 2007 23:14:48 -0800 (PST) X-Return-Path: X-Received: from pangtzu.panda.com ([206.124.149.117]) by Lingling.Panda.COM with TCP/SMTP; Tue, 11 Dec 2007 23:14:34 -0800 (PST) Date: Tue, 11 Dec 2007 23:14:30 -0800 (PST) From: Mark Crispin Sender: mrc@pangtzu.panda.com To: TOPS-20 Hackers and Yackers Subject: Re: Help with dual RP07 system structure In-Reply-To: <200712102151.lBALpLx03517@panix5.panix.com> Message-ID: References: <200712021320.19385.vandys@vsta.org> <475BFEDD.1090300@optonline.net> <200712102151.lBALpLx03517@panix5.panix.com> User-Agent: Alpine 1.00 (OSX 862 2007-12-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed ReSent-Date: Tue, 11 Dec 2007 23:14:42 -0800 (PST) ReSent-From: TOPS-20 List Moderator ReSent-To: TOPS-20 Distribution: ; ReSent-Subject: Re: Help with dual RP07 system structure ReSent-Message-ID: ReSent-User-Agent: Alpine 1.00 (OSX 862 2007-12-11) On Mon, 10 Dec 2007, Rich Alderson wrote: >> This would create a 4 million page disk (8GB), which is about 16 times the >> RP07 and 4 times the infamous SCORE 4xRP07. That ought to be enough for >> TOPS-20 folks for the conceivable future... ;-) Note that this also entails an incompatible change to the filesystem; you get two bits by going to sector addressing and two other bits by moving DSKAB/DSKNB. The DSKAB/DSKNB move is what is incompatible. The Panda monitor just moves DSKNB to the other side of DSKAB which gains only 1 bit (hence the possibility of two-RP07 structures) while keeping compatibility with smaller DEC structures. > We need two variants, one addressing sectors as well as Mark's proposal. Those > of us who use KLH10 to test software installations and the like for running > hardware need something for another operating system than the one licensed for > discussion on this list. I guess that I don't see much benefit of doing that. If you're going to stay sector-addressed and not change the filesystem, you might as well stay with RP07s. The maximum number of sectors in DEC's world is 1,048,576 (Panda doubles that). An RP07 has 865,504 sectors. -- Mark -- http://panda.com/tops-20 TOPS-20: a great improvement over its successors 12-Dec-2007 11:10:24-PST,5778;000000000000 Return-Path: Received: from pangtzu.panda.com ([206.124.149.117]) by Lingling.Panda.COM with TCP/SMTP; Wed, 12 Dec 2007 11:05:45 -0800 (PST) X-Return-Path: X-Received: from mta5.srv.hcvlny.cv.net ([167.206.4.200]) by Lingling.Panda.COM with TCP/SMTP; Wed, 12 Dec 2007 06:42:55 -0800 (PST) X-Received: from [192.168.1.7] (ool-45720130.dyn.optonline.net [69.114.1.48]) by mta5.srv.hcvlny.cv.net (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTP id <0JSX002N9Y6YMFU0@mta5.srv.hcvlny.cv.net>; Wed, 12 Dec 2007 09:42:35 -0500 (EST) Date: Wed, 12 Dec 2007 09:42:33 -0500 From: Thomas DeBellis Subject: Re: Help with dual RP07 system structure In-reply-to: To: Mark Crispin Cc: TOPS-20 Hackers and Yackers Message-id: <475FF359.4070409@optonline.net> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en References: <200712021320.19385.vandys@vsta.org> <475BFEDD.1090300@optonline.net> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) ReSent-Date: Wed, 12 Dec 2007 11:05:35 -0800 (PST) ReSent-From: TOPS-20 List Moderator ReSent-To: TOPS-20 Distribution: ; ReSent-Subject: Re: Help with dual RP07 system structure ReSent-Message-ID: ReSent-User-Agent: Alpine 1.00 (OSX 862 2007-12-11) As I've said, I'm very interested in the Tops-20 EEE effort (and hope to contribute to it once I get my nose off of the EFTPSR grindstone). I like the idea of the ssh/front-end interface stuff, too. Here were some other things that I was considering: 1) CI re-implementation. That way that I can have one system behind a firewall (for development) and another on the general Internet. 2) HSC50 simulation. Once the CI is done, I could then have a bunch of HSC50's all over the place. 3) Tops-20 re-drumification. I want to put a different swapping device back on to Tops-20 and not swap on the BS device. The drum would simply be implemented in memory and would: A) Be faster (lots) B) Involve a great deal less wear and tear on the disk C) Permit faster transfers from disks due to less media conflict (I.E., seek and rotatial delay from different file and swap requests) C) Allow for more usuable space on structures 4) Tops-20 read-only devices. Used for CD-ROM distributions. 5) KLH10 port to Windows. This would broaden the user base which is something that I'm interested in doing. I have a lot more Windows boxes than I have Unix ones (yeah, I know) But the problem is that many of these projects involve hacking code that wouldn't be on the 20. Horrors. Or maybe I could bring up the gnu compiler with the PDP-10 targeting and use that for most of the preliminary work. And, as I've been working on the extended mode FTP server, I've come across a large number of bugs that I am itching to fix. I've actually got quite a list of them. However I never did say what my Top Priority is. Please have a look at your USENET posting, below. It tickled my funny bone so much that I ftp'ed it into my DOCUMENTATION directory. So my Top Priority is to get you off your "butt to and upgrade TOPS-20 IMAP server from IMAP2 to IMAP4rev1...)" That way I could have a couple more people use my 20 (that are used to using graphical mail clients such as LookOut and Netscape). Fewer and fewer people are using graphical mode mail clients (such as MM) these days. But I don't have nagging rights to this, yet. Once I get EFTPSR out the door, THEN I have nagging rights. You've been warned... :-) ________________________________________________________________ From: "Mark Crispin" Subject: Re: device init failed on FreeBSD Date: Sunday, February 11, 2007 5:45 PM On Sun, 11 Feb 2007, John wrote: >>> What language is LPTSPL written in? >> Heh, as the saying goes, "if you have to ask..." > I'm guessing that the answer is assembly. Correct. > That said, it wouldn't be much worse than any other answer, since I > currently only know C++, Java, and m68k assembly. :-) No, it's much better. PDP-10 assembly language is God's Own Programming Language, before which all other languages bow in abject submission. C??? Bah. C is mere RatFor for PDP-11 assembly language, itself a pale and lesser entity to the perfection achieved on the PDP-10. When God uses a high level language (for convenience), she uses LISP. Beware. There are many unbelievers in the world, who have labored mightily to suppress the truth and persecute the faithful. The fact that the true faith still is practiced is a testiment to its virtue. However, know ye that the faithful are many; and even if they enter the temples of the unbelievers so that they may feed their families, they still practice the true faith in secret. Some have even labored to insert articles of the true faith into the blasphemous dogmas of the unbelievers. Yea, even in the great pagan temple of Redmond, of that which is Tiny and Flaccid, there are adherants of the true faith. Thou art about to join a great cause. Rejoice. -- Mark -- (who really has to get off his butt and upgrade TOPS-20 IMAP server from IMAP2 to IMAP4rev1...) http://panda.com/tops-20 TOPS-20: A Great Improvement Over Its Successors 12-Dec-2007 17:27:56-PST,2458;000000000000 Return-Path: Received: from pangtzu.panda.com ([206.124.149.117]) by Lingling.Panda.COM with TCP/SMTP; Wed, 12 Dec 2007 17:23:44 -0800 (PST) X-Return-Path: X-Received: from mail2.panix.com ([166.84.1.73]) by Lingling.Panda.COM with TCP/SMTP; Wed, 12 Dec 2007 15:27:06 -0800 (PST) X-Received: from panix5.panix.com (panix5.panix.com [166.84.1.5]) by mail2.panix.com (Postfix) with ESMTP id CDF913482D for ; Wed, 12 Dec 2007 18:26:56 -0500 (EST) X-Received: (from alderson@localhost) by panix5.panix.com (8.11.6p3/8.8.8/PanixN1.1) id lBCNQuq08175; Wed, 12 Dec 2007 18:26:56 -0500 (EST) Date: Wed, 12 Dec 2007 18:26:56 -0500 (EST) Message-Id: <200712122326.lBCNQuq08175@panix5.panix.com> From: Rich Alderson To: TOPS-20@lingling.panda.com In-reply-to: <475C21C9.4010207@optonline.net> (message from Thomas DeBellis on Sun, 09 Dec 2007 12:11:37 -0500) Subject: Re: DELNF% is very disrespectful to DF%NRJ References: <200712021320.19385.vandys@vsta.org> <475C21C9.4010207@optonline.net> ReSent-Date: Wed, 12 Dec 2007 17:23:34 -0800 (PST) ReSent-From: TOPS-20 List Moderator ReSent-To: TOPS-20 Distribution: ; ReSent-Subject: Re: DELNF% is very disrespectful to DF%NRJ ReSent-Message-ID: ReSent-User-Agent: Alpine 1.00 (OSX 862 2007-12-11) > Date: Sun, 09 Dec 2007 12:11:37 -0500 > From: Thomas DeBellis > Because 'modern' graphical FTP clients remain unenlighted about versioned > file systems, I don't display generations when doing directory listings > (LIST, NLST or STAT verbs). However, for DELE (delete) and RNTO/RNFR > (rename), I did not write any special code for generations--exactly one file > is processed per verb. The default was generation zero. Does anyone else find this disturbing? The graphical FTP clients which I have used (the Windows client from FTP Software, until they ripped out Tops-20 support because we would not change the way paths were printed in Tops-20 to match VMS, and a couple of different ones on Macs) all happily displayed the generations and their associated date info, and I made great use of that fact. I'm afraid that I will find EFTPSR less useful than otherwise. Rich 12-Dec-2007 23:34:42-PST,2019;000000000000 Return-Path: Received: from pangtzu.panda.com ([206.124.149.117]) by Lingling.Panda.COM with TCP/SMTP; Wed, 12 Dec 2007 23:30:31 -0800 (PST) X-Return-Path: X-Received: from pangtzu.panda.com ([206.124.149.117]) by Lingling.Panda.COM with TCP/SMTP; Wed, 12 Dec 2007 22:38:33 -0800 (PST) Date: Wed, 12 Dec 2007 22:38:29 -0800 (PST) From: Mark Crispin Sender: mrc@pangtzu.panda.com To: TOPS-20 Hackers and Yackers Subject: Re: DELNF% is very disrespectful to DF%NRJ In-Reply-To: <200712122326.lBCNQuq08175@panix5.panix.com> Message-ID: References: <200712021320.19385.vandys@vsta.org> <475C21C9.4010207@optonline.net> <200712122326.lBCNQuq08175@panix5.panix.com> User-Agent: Alpine 1.00 (OSX 862 2007-12-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed ReSent-Date: Wed, 12 Dec 2007 23:30:22 -0800 (PST) ReSent-From: TOPS-20 List Moderator ReSent-To: TOPS-20 Distribution: ; ReSent-Subject: Re: DELNF% is very disrespectful to DF%NRJ ReSent-Message-ID: ReSent-User-Agent: Alpine 1.00 (OSX 862 2007-12-11) On Wed, 12 Dec 2007, Rich Alderson wrote: > Does anyone else find this disturbing? The graphical FTP clients which I have > used (the Windows client from FTP Software, until they ripped out Tops-20 > support because we would not change the way paths were printed in Tops-20 to > match VMS, and a couple of different ones on Macs) all happily displayed the > generations and their associated date info, and I made great use of that fact. > > I'm afraid that I will find EFTPSR less useful than otherwise. This seems to be a compelling argument to me too. I think that the generation numbers should always show up. -- Mark -- http://panda.com/tops-20 TOPS-20: a great improvement over its successors 12-Dec-2007 23:53:41-PST,1824;000000000000 Return-Path: Received: from pangtzu.panda.com ([206.124.149.117]) by Lingling.Panda.COM with TCP/SMTP; Wed, 12 Dec 2007 23:50:00 -0800 (PST) X-Return-Path: X-Received: from pangtzu.panda.com ([206.124.149.117]) by Lingling.Panda.COM with TCP/SMTP; Wed, 12 Dec 2007 23:45:43 -0800 (PST) Date: Wed, 12 Dec 2007 23:45:39 -0800 (PST) From: Mark Crispin Sender: mrc@pangtzu.panda.com To: Thomas DeBellis cc: TOPS-20 Hackers and Yackers Subject: Re: Help with dual RP07 system structure In-Reply-To: <475FF359.4070409@optonline.net> Message-ID: References: <200712021320.19385.vandys@vsta.org> <475BFEDD.1090300@optonline.net> <475FF359.4070409@optonline.net> User-Agent: Alpine 1.00 (OSX 862 2007-12-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed ReSent-Date: Wed, 12 Dec 2007 23:49:55 -0800 (PST) ReSent-From: TOPS-20 List Moderator ReSent-To: TOPS-20 Distribution: ; ReSent-Subject: Re: Help with dual RP07 system structure ReSent-Message-ID: ReSent-User-Agent: Alpine 1.00 (OSX 862 2007-12-11) On Wed, 12 Dec 2007, Thomas DeBellis wrote: > So my Top Priority is to get you off your "butt to and upgrade TOPS-20 > IMAP server from IMAP2 to IMAP4rev1...)" Sadly, if I were to do IMAP4rev1 on TOPS-20 it would probably be to port UW imapd to TOPS-20 rather than to extend MAPSER to do IMAP4rev1. The task of doing the latter is just too daunting. -- Mark -- http://panda.com/tops-20 TOPS-20: a great improvement over its successors 13-Dec-2007 00:23:27-PST,1824;000000000000 Return-Path: Received: from pangtzu.panda.com ([206.124.149.117]) by Lingling.Panda.COM with TCP/SMTP; Thu, 13 Dec 2007 00:19:26 -0800 (PST) X-Return-Path: X-Received: from pangtzu.panda.com ([206.124.149.117]) by Lingling.Panda.COM with TCP/SMTP; Wed, 12 Dec 2007 23:45:43 -0800 (PST) Date: Wed, 12 Dec 2007 23:45:39 -0800 (PST) From: Mark Crispin Sender: mrc@pangtzu.panda.com To: Thomas DeBellis cc: TOPS-20 Hackers and Yackers Subject: Re: Help with dual RP07 system structure In-Reply-To: <475FF359.4070409@optonline.net> Message-ID: References: <200712021320.19385.vandys@vsta.org> <475BFEDD.1090300@optonline.net> <475FF359.4070409@optonline.net> User-Agent: Alpine 1.00 (OSX 862 2007-12-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed ReSent-Date: Thu, 13 Dec 2007 00:19:20 -0800 (PST) ReSent-From: TOPS-20 List Moderator ReSent-To: TOPS-20 Distribution: ; ReSent-Subject: Re: Help with dual RP07 system structure ReSent-Message-ID: ReSent-User-Agent: Alpine 1.00 (OSX 862 2007-12-11) On Wed, 12 Dec 2007, Thomas DeBellis wrote: > So my Top Priority is to get you off your "butt to and upgrade TOPS-20 > IMAP server from IMAP2 to IMAP4rev1...)" Sadly, if I were to do IMAP4rev1 on TOPS-20 it would probably be to port UW imapd to TOPS-20 rather than to extend MAPSER to do IMAP4rev1. The task of doing the latter is just too daunting. -- Mark -- http://panda.com/tops-20 TOPS-20: a great improvement over its successors 13-Dec-2007 10:16:03-PST,4555;000000000000 Return-Path: Received: from pangtzu.panda.com ([206.124.149.117]) by Lingling.Panda.COM with TCP/SMTP; Thu, 13 Dec 2007 10:11:30 -0800 (PST) X-Return-Path: X-Received: from mta1.srv.hcvlny.cv.net ([167.206.4.196]) by Lingling.Panda.COM with TCP/SMTP; Thu, 13 Dec 2007 08:41:02 -0800 (PST) X-Received: from [192.168.1.7] (ool-45720130.dyn.optonline.net [69.114.1.48]) by mta1.srv.hcvlny.cv.net (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTP id <0JSZ00EJKYC072Y0@mta1.srv.hcvlny.cv.net> for TOPS-20@lingling.panda.com; Thu, 13 Dec 2007 11:40:49 -0500 (EST) Date: Thu, 13 Dec 2007 11:40:47 -0500 From: Thomas DeBellis Subject: Re: DELNF% is very disrespectful to DF%NRJ In-reply-to: <200712122326.lBCNQuq08175@panix5.panix.com> To: Rich Alderson Cc: TOPS-20@lingling.panda.com Message-id: <4761608F.8000504@optonline.net> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en References: <200712021320.19385.vandys@vsta.org> <475C21C9.4010207@optonline.net> <200712122326.lBCNQuq08175@panix5.panix.com> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) ReSent-Date: Thu, 13 Dec 2007 10:11:24 -0800 (PST) ReSent-From: TOPS-20 List Moderator ReSent-To: TOPS-20 Distribution: ; ReSent-Subject: Re: DELNF% is very disrespectful to DF%NRJ ReSent-Message-ID: ReSent-User-Agent: Alpine 1.00 (OSX 862 2007-12-11) > > Because 'modern' graphical FTP clients remain unenlighted about > > versioned file systems, I don't display generations when doing > > directory listings (LIST, NLST or STAT verbs). However, for DELE > > (delete) and RNTO/RNFR (rename), I did not write any special code > > for generations--exactly one file is processed per verb. The > > default was generation zero. > > Does anyone else find this disturbing? The graphical FTP clients > which I have used (the Windows client from FTP Software, until they > ripped out Tops-20 support because we would not change the way paths > were printed in Tops-20 to match VMS, and a couple of different ones > on Macs) all happily displayed the generations and their associated > date info, and I made great use of that fact. > > I'm afraid that I will find EFTPSR less useful than otherwise. > > Rich I'm not clear on what you are saying. May I ask you to please elaborate on what is disturbing you? Please note that I am talking about the operation of the server ONLY when it is TVFS mode; Tops-20 listings and formats remain the same for those clients enlightened enough to understand them. You can force Tops-20 mode and keep the TVFS (a.k.a Unix) stuff locked out. Here are a few of the things that kicked this project off: 1) The Windows Internet Destroyer that I have (6, I have no tried 5 and 4) does not understand generation numbers. If you do a listing, you get no file types to sort on, all files are zero bytes long and all dates are 1/1/1980 12:00 PM. Directory trees do not work. Transfering files breaks for a number of reasons (see below) 2) EFTP does not work at all. It gets that the disk structure is not a valid integer. 3) Hummingbird FTP does not work at all. The VMS support doesn't understand Tops-20 4) gnu-Angeftpo mode does not work, you get/slogin@tommyt:/TOMMYT/SLOGIN: ? Not found. 5) The MAC OSX Safari client did not connect at all Many of these clients (particularly Windows) insist on transfering all files in image mode (and will not do anything else), which breaks 7 bit files. I just verified this with the BBN server. Thus the original purpose of the project was to lie to these clients to get them to do something reasonable. Little of this applies with many console clients. If you're winning enough to still know how to use these, then you can shut TVFS mode off and keep it locked out by doing a QUOTE SITE TVFS LOCK. But some clients still won't work. All also give you highly annoying file types of 1, 2 and 3. If your graphical client can handle a Tops-20 listing, then you can put a SITE TVFS LOCK in your EFTPSR login command file and keep it off. 13-Dec-2007 10:19:38-PST,7199;000000000000 Return-Path: Received: from pangtzu.panda.com ([206.124.149.117]) by Lingling.Panda.COM with TCP/SMTP; Thu, 13 Dec 2007 10:12:05 -0800 (PST) X-Return-Path: X-Received: from mta2.srv.hcvlny.cv.net ([167.206.4.197]) by Lingling.Panda.COM with TCP/SMTP; Thu, 13 Dec 2007 09:23:46 -0800 (PST) X-Received: from [192.168.1.7] (ool-45720130.dyn.optonline.net [69.114.1.48]) by mta2.srv.hcvlny.cv.net (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTP id <0JT000G0L0BFTVQ0@mta2.srv.hcvlny.cv.net>; Thu, 13 Dec 2007 12:23:40 -0500 (EST) Date: Thu, 13 Dec 2007 12:23:39 -0500 From: Thomas DeBellis Subject: EFTPSR TVFS activity To: Tops-20 Wizards Cc: Rich Alderson , Mark Crispin Message-id: <47616A9B.5050803@optonline.net> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) ReSent-Date: Thu, 13 Dec 2007 10:11:59 -0800 (PST) ReSent-From: TOPS-20 List Moderator ReSent-To: TOPS-20 Distribution: ; ReSent-Subject: EFTPSR TVFS activity ReSent-Message-ID: ReSent-User-Agent: Alpine 1.00 (OSX 862 2007-12-11) Just to be more explicit about things, here are some examples. Note that I do support the Tops-20 FTP client, so I made (and will continue to make) pretty sure that EFTPSR works with it!! Also, I forgot to mention that the initial setting of TVFS mode is AUTOMATIC; that means if it fails on a Tops-20 file specification, it tries parsing it as Unix path and--if successful--automagically switches the FTP server into TVFS mode. This is the only way to keep a novice (I.E., a new user who might not know about having an EFTPSR.CMD file in their login directory) from getting confused by having the previously mentioned clients break. We want them to stick around! However, an installation CAN elect to force Tops-20 or TVFS mode as it sees fit as the default in the system EFTPSR.CMD file, which is taken before sign on. TVFS mode can also be switched on by default for ANONYMOUS users. You can also use the system EFTPSR command file to configure and lock lots of stuff such as, ANONYMOUS usage, buffer usage, transfer throttling, idle timeout (and log out), various hack attacks, logging and bounce attacks. Again, deleting and renaming multiple generations of files (which are not listed in TVFS mode) for unenlightened graphical clients is the ONLY way to keep a novice user from being confused. Otherwise you keep deleting and the file doesn't go away. Then I get bugged about delete not working. Tops-20 mode does not delete or rename multiple generations of ANYTHING. I don't allow wildcards under the assumption that the Tops-20 FTP client is smart enough to deal with this kind of stuff (it is). Finally, remember that I am going through an alpha AND beta test round before releasing EFTPSR. I'm certainly open to changing just about anything and (as mentioned about) have put a GREAT deal of real time configuration parameters into the server so that each one of you can have it operated just the way you like it to be. Fair? One future plan is to modify the server to take an EFTPSR.CMD file on each directory change, so that each directory change can modify server behavior (including listing formats). But some of that stuff won't be in the release candidate. I'm desperately trying to avoid feeping creaturitis so that I can get this out the door. And congratulations Rich, I've just volunteered you to be an alpha tester! :-) ________________________________________________________________ ; Server start up (note the large number of edits ...) 220 TOMMYT TOPS20 FTP Server V7.1(14557) on Thu Dec 13, 2007 11:52:37AM-EST ; Now in Tops-20 mode PWD 257 "STAR:" is current directory. LIST e*.mac.0 150 List started for STAR:E*.MAC.0 STAR:EFTPSA.MAC.860;P777700;A,82, 8-Dec-2007 21:00:03, 8-Dec-2007 21:00:03,11-Dec-2007 14:05:52 STAR:EFTPSC.MAC.2057;P777700;A,67, 2-Dec-2007 13:42:37, 2-Dec-2007 13:42:37, 9-Dec-2007 22:13:25 STAR:EFTPSH.MAC.1105;P777700;A,107, 8-Dec-2007 20:11:35, 8-Dec-2007 20:11:35, 9-Dec-2007 22:13:25 STAR:EFTPSR.MAC.3055;P777700;A,77, 8-Dec-2007 21:05:46, 8-Dec-2007 21:05:46, 9-Dec-2007 22:13:25 STAR:EFTPSS.MAC.2725;P777700;A,73, 8-Dec-2007 20:28:19, 8-Dec-2007 20:28:19, 9-Dec-2007 22:13:25 STAR:EFTPST.MAC.2651;P777700;A,74,13-Dec-2007 06:47:04,13-Dec-2007 06:47:04,16-Nov-1858 19:00:00 STAR:EFTPSU.MAC.872;P777700;A,25, 2-Dec-2007 15:00:04, 2-Dec-2007 15:00:04, 9-Dec-2007 22:13:26 STAR:EFTPSV.MAC.1461;P777700;A,62, 1-Dec-2007 16:03:50, 1-Dec-2007 16:03:50, 9-Dec-2007 22:13:26 STAR:EFTPSZ.MAC.81;P777700;A,4, 1-Sep-2007 00:05:04, 1-Sep-2007 00:05:04, 9-Dec-2007 22:13:26 226 Inferior fork listed STAR:E*.MAC.0 ; Force TVFS mode TVFS ON 200 TVFS Mode: ON (Unix filepaths), Unix filepath recognition: automatic PWD 257 "/STAR/FTP" is current directory. LIST e*.mac 150 List started for STAR:E*.MAC.0 -rwxrwx--- 860 SLOGIN SLOGIN 209003 Dec 8 21:00 EFTPSA.MAC -rwxrwx--- 2057 SLOGIN SLOGIN 170945 Dec 2 13:42 EFTPSC.MAC -rwxrwx--- 1105 SLOGIN SLOGIN 273546 Dec 8 20:11 EFTPSH.MAC -rwxrwx--- 3055 SLOGIN SLOGIN 196073 Dec 8 21:05 EFTPSR.MAC -rwxrwx--- 2725 SLOGIN SLOGIN 185481 Dec 8 20:28 EFTPSS.MAC -rwxrwx--- 2651 SLOGIN SLOGIN 187431 Dec 13 06:47 EFTPST.MAC -rwxrwx--- 872 SLOGIN SLOGIN 62599 Dec 2 15:00 EFTPSU.MAC -rwxrwx--- 1461 SLOGIN SLOGIN 158368 Dec 1 16:03 EFTPSV.MAC -rwxrwx--- 81 SLOGIN SLOGIN 8078 Sep 1 00:05 EFTPSZ.MAC 226 Transfer complete. ; Force TVFS mode off and keep it off TVFS LOCK 200 TVFS Mode: OFF (Tops-20 file names), Unix filepath recognition: locked out LIST E*.MAC.0 150 List started for STAR:E*.MAC.0 STAR:EFTPSA.MAC.860;P777700;A,82, 8-Dec-2007 21:00:03, 8-Dec-2007 21:00:03,11-Dec-2007 14:05:52 STAR:EFTPSC.MAC.2057;P777700;A,67, 2-Dec-2007 13:42:37, 2-Dec-2007 13:42:37, 9-Dec-2007 22:13:25 STAR:EFTPSH.MAC.1105;P777700;A,107, 8-Dec-2007 20:11:35, 8-Dec-2007 20:11:35, 9-Dec-2007 22:13:25 STAR:EFTPSR.MAC.3055;P777700;A,77, 8-Dec-2007 21:05:46, 8-Dec-2007 21:05:46, 9-Dec-2007 22:13:25 STAR:EFTPSS.MAC.2725;P777700;A,73, 8-Dec-2007 20:28:19, 8-Dec-2007 20:28:19, 9-Dec-2007 22:13:25 STAR:EFTPST.MAC.2651;P777700;A,74,13-Dec-2007 06:47:04,13-Dec-2007 06:47:04,16-Nov-1858 19:00:00 STAR:EFTPSU.MAC.872;P777700;A,25, 2-Dec-2007 15:00:04, 2-Dec-2007 15:00:04, 9-Dec-2007 22:13:26 STAR:EFTPSV.MAC.1461;P777700;A,62, 1-Dec-2007 16:03:50, 1-Dec-2007 16:03:50, 9-Dec-2007 22:13:26 STAR:EFTPSZ.MAC.81;P777700;A,4, 1-Sep-2007 00:05:04, 1-Sep-2007 00:05:04, 9-Dec-2007 22:13:26 226 Inferior fork listed STAR:E*.MAC.0 13-Dec-2007 17:55:57-PST,2770;000000000000 Return-Path: Received: from pangtzu.panda.com ([206.124.149.117]) by Lingling.Panda.COM with TCP/SMTP; Thu, 13 Dec 2007 17:51:52 -0800 (PST) X-Return-Path: X-Received: from mail3.panix.com ([166.84.1.74]) by Lingling.Panda.COM with TCP/SMTP; Thu, 13 Dec 2007 17:28:10 -0800 (PST) X-Received: from panix5.panix.com (panix5.panix.com [166.84.1.5]) by mail3.panix.com (Postfix) with ESMTP id 4FCC713A79B for ; Thu, 13 Dec 2007 20:28:05 -0500 (EST) X-Received: (from alderson@localhost) by panix5.panix.com (8.11.6p3/8.8.8/PanixN1.1) id lBE1S5c20463; Thu, 13 Dec 2007 20:28:05 -0500 (EST) Date: Thu, 13 Dec 2007 20:28:05 -0500 (EST) Message-Id: <200712140128.lBE1S5c20463@panix5.panix.com> From: Rich Alderson To: TOPS-20@lingling.panda.com In-reply-to: <4761608F.8000504@optonline.net> (message from Thomas DeBellis on Thu, 13 Dec 2007 11:40:47 -0500) Subject: Re: DELNF% is very disrespectful to DF%NRJ References: <200712021320.19385.vandys@vsta.org> <475C21C9.4010207@optonline.net> <200712122326.lBCNQuq08175@panix5.panix.com> <4761608F.8000504@optonline.net> ReSent-Date: Thu, 13 Dec 2007 17:51:42 -0800 (PST) ReSent-From: TOPS-20 List Moderator ReSent-To: TOPS-20 Distribution: ; ReSent-Subject: Re: DELNF% is very disrespectful to DF%NRJ ReSent-Message-ID: ReSent-User-Agent: Alpine 1.00 (OSX 867 2007-12-13) > Date: Thu, 13 Dec 2007 11:40:47 -0500 > From: Thomas DeBellis >>> Because 'modern' graphical FTP clients remain unenlighted about versioned >>> file systems, I don't display generations when doing directory listings >>> (LIST, NLST or STAT verbs). However, for DELE (delete) and RNTO/RNFR >>> (rename), I did not write any special code for generations--exactly one >>> file is processed per verb. The default was generation zero. >> Does anyone else find this disturbing? [...] > I'm not clear on what you are saying. May I ask you to please elaborate on > what is disturbing you? Please note that I am talking about the operation of > the server ONLY when it is TVFS mode; Tops-20 listings and formats remain the > same for those clients enlightened enough to understand them. You can force > Tops-20 mode and keep the TVFS (a.k.a Unix) stuff locked out. Here are a few > of the things that kicked this project off: It was not clear to me (at least) from your original description that ignoring file generations is not the usual behavior of EFTPSR. I apologize for jumping to conclusions. Rich 14-Dec-2007 18:25:13-PST,4748;000000000000 Return-Path: Received: from pangtzu.panda.com ([206.124.149.117]) by Lingling.Panda.COM with TCP/SMTP; Fri, 14 Dec 2007 18:21:14 -0800 (PST) X-Return-Path: X-Received: from mta4.srv.hcvlny.cv.net ([167.206.4.199]) by Lingling.Panda.COM with TCP/SMTP; Fri, 14 Dec 2007 18:11:46 -0800 (PST) X-Received: from [192.168.1.7] (ool-45720130.dyn.optonline.net [69.114.1.48]) by mta4.srv.hcvlny.cv.net (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTP id <0JT200EU7JFGLN71@mta4.srv.hcvlny.cv.net> for TOPS-20@lingling.panda.com; Fri, 14 Dec 2007 21:11:41 -0500 (EST) Date: Fri, 14 Dec 2007 21:11:39 -0500 From: Thomas DeBellis Subject: Re: DELNF% is very disrespectful to DF%NRJ In-reply-to: <200712140128.lBE1S5c20463@panix5.panix.com> To: Rich Alderson Cc: TOPS-20@lingling.panda.com Message-id: <476337DB.9050104@optonline.net> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en References: <200712021320.19385.vandys@vsta.org> <475C21C9.4010207@optonline.net> <200712122326.lBCNQuq08175@panix5.panix.com> <4761608F.8000504@optonline.net> <200712140128.lBE1S5c20463@panix5.panix.com> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) ReSent-Date: Fri, 14 Dec 2007 18:21:05 -0800 (PST) ReSent-From: TOPS-20 List Moderator ReSent-To: TOPS-20 Distribution: ; ReSent-Subject: Re: DELNF% is very disrespectful to DF%NRJ ReSent-Message-ID: ReSent-User-Agent: Alpine 1.00 (OSX 867 2007-12-13) > It was not clear to me (at least) from your original description > that ignoring file generations is not the usual behavior of EFTPSR. Oh, I wouldn't worry about it. I'm not clear. I'm foggy. Opaque. Something ... Right, Keng? The original design of the EFTPSR directory listing code was supposed to be general enough to handle something called the "Trivial Virtual File Store (TVFS)". Basically this meant taking the winning Tops-20 file specification format and lobotomizing it for some new verbs called MLST and MLSD (see RFC 3659 for more details). For example: size=4161;lang=en-US;modify=19970214165800;create=19961001124534;type=file;x.myfact=foo,bar; Nice and obvious, eh? But, almost nothing I had could grok this (I think Kermit-95 does, Frank?). And Windows Explorer and gnu ange-ftp mode (and everything else that I had) still didn't work. Annoying. I wanted to be able point the Explorer at the 20, double click on my .MP3's and seamlessly listen to tunes. This works, which now allows my 36 bit mainframe to take its rightful place as the center of my multi-media entertainment solution. So I went with a Unix listing format, which is all anybody appears to want to hear about, these days. I even have to parse some ls switches (so some graphical clients don't break) and then phoney up certain types of ls responses over the data connection (so various other GUI based FTPs don't croak without seeing the 'piped' ls output). Ugh ... But I (hope I) designed the listing interface with enough generality to basically allow me to print any sort of directory format that I want. This means that, should anybody decide that they absolutely can not possibly live without having the uncurably brain damaged crock-o-tronic bogus losing abomination ... Whoops ... I mean VMS listing specification, I can certainly spew that out. I also have initial hooks and code to support a Unix type /DEV listing. You can go into the top level directory and connect to /DEV and then 'list' all the devices on the machine. I simulate /DEV with lots of GETAB%s. For example, a TTY character 'file' has the user logged in as the terminal's owner. Accepting links and advice gets converted into the appropriate file protections. Like: crw-rw-rw- 9 SLOGIN TTY 12, 40 Julh 21 2007 /DEV/TTY40 In this case, protection bits means that the terminal is accepting system messages, user messages, links and advice. The link field (9) is the person logged in on the terminal, the owner (SLOGIN) being the person logged in. The group is the device prefix. The device number is the Tops-20 device number and the unit is the line number. The date is when the user logged in. Discusting, isn't it? I do other silly things for PTYs (controlling job, etc.) and other devices. But none of this will be the initial version. Feeping creaturitis and all that. Second system effected... Mumble. 15-Dec-2007 10:22:05-PST,4304;000000000000 Return-Path: Received: from pangtzu.panda.com ([206.124.149.117]) by Lingling.Panda.COM with TCP/SMTP; Sat, 15 Dec 2007 10:17:45 -0800 (PST) X-Return-Path: X-Received: from mail.math.utah.edu ([155.101.98.135]) by Lingling.Panda.COM with TCP/SMTP; Sat, 15 Dec 2007 07:20:29 -0800 (PST) X-Received: from psi.math.utah.edu (psi.math.utah.edu [155.101.96.19]) by mail.math.utah.edu (8.13.6/8.13.6) with ESMTP id lBFFKKPT008874; Sat, 15 Dec 2007 08:20:20 -0700 (MST) X-Received: from psi.math.utah.edu (localhost [127.0.0.1]) by psi.math.utah.edu (8.13.6/8.13.6) with ESMTP id lBFFKJuF005145; Sat, 15 Dec 2007 08:20:19 -0700 (MST) X-Received: (from beebe@localhost) by psi.math.utah.edu (8.13.6/8.13.6/Submit) id lBFFKJsI005143; Sat, 15 Dec 2007 08:20:19 -0700 (MST) Date: Sat, 15 Dec 2007 08:20:19 -0700 (MST) From: "Nelson H. F. Beebe" To: TOPS-20@Lingling.Panda.COM 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] a significant birthday: the transistor turns 60 Message-ID: X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0 (mail.math.utah.edu [155.101.98.135]); Sat, 15 Dec 2007 08:20:20 -0700 (MST) ReSent-Date: Sat, 15 Dec 2007 10:17:34 -0800 (PST) ReSent-From: TOPS-20 List Moderator ReSent-To: TOPS-20 Distribution: ; ReSent-Subject: [tops-20] a significant birthday: the transistor turns 60 ReSent-Message-ID: ReSent-User-Agent: Alpine 1.00 (OSX 873 2007-12-15) Sunday, 16 December 2007, is a significant birthday: the transistor was invented just 60 years ago, later winning the Nobel Prize in Physics in 1956 for its inventors William Shockley, John Bardeen, and Walter Brattain http://nobelprize.org/nobel_prizes/physics/laureates/1956/index.html Shockley went on to found the Shockley Semiconductor division of Beckman Instruments, but was so abrasive that a group of his engineers left to found Fairchild Semiconductor, from which a split later produced Intel Corporation. See, for example, these recent books Leslie Berlin The man behind the microchip: Robert Noyce and the invention of Silicon Valley Oxford 2005 ISBN 0-19-516343-5, 978-0-19-516343-8 LCCN TK7807.N69 B47 2005 Richard S. Tedlow Andy Grove: the life and times of an American Portfolio 2006 ISBN 1-59184-139-9, 978-1-59184-139-5 LCCN HD9696.S44 T588 2006 Bardeen won the Nobel Prize in Physics a second time, in 1972 for the BCS theory of superconductivity: John Bardeen, Leon N. Cooper, Robert Schrieffer http://nobelprize.org/nobel_prizes/physics/laureates/1972/index.html There are news stories about the transistor here: The transistor: The most important invention of the 20th century? http://cwflyris.computerworld.com/t/2471749/419952/91210/2/ Celebrating 60 years of transistors http://www.nytimes.com/cnet/CNET_2100-1006_3-6222770.html The transistor: 60 years old and still switching http://www.eetimes.com/showArticle.jhtml?articleID=204300928 The Bell Labs transistor Web site is here: http://www.porticus.org/bell/belllabs_transistor.html That site gives 24 December 1947 as the day of the first successful test of the transistor. ------------------------------------------------------------------------------- - 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/ - ------------------------------------------------------------------------------- 15-Dec-2007 10:25:48-PST,2823;000000000000 Return-Path: Received: from pangtzu.panda.com ([206.124.149.117]) by Lingling.Panda.COM with TCP/SMTP; Sat, 15 Dec 2007 10:17:58 -0800 (PST) X-Return-Path: X-Received: from pangtzu.panda.com ([206.124.149.117]) by Lingling.Panda.COM with TCP/SMTP; Sat, 15 Dec 2007 10:17:25 -0800 (PST) X-Return-Path: X-Received: from sesame.cc.columbia.edu ([128.59.59.56]) by Lingling.Panda.COM with TCP/SMTP; Sat, 15 Dec 2007 06:31:52 -0800 (PST) X-Received: from sesame.cc.columbia.edu (localhost [127.0.0.1]) by sesame.cc.columbia.edu (8.14.1/8.14.1) with ESMTP id lBFEVlFW022953; Sat, 15 Dec 2007 09:31:47 -0500 (EST) X-Received: (from fdc@localhost) by sesame.cc.columbia.edu (8.14.1/8.14.1/Submit) id lBFEVlKC022952; Sat, 15 Dec 2007 09:31:47 -0500 (EST) Date: Sat, 15 Dec 2007 9:31:47 EST From: Frank da Cruz To: Thomas DeBellis Cc: TOPS-20 List Moderator Subject: Re: DELNF% is very disrespectful to DF%NRJ In-Reply-To: <476337DB.9050104@optonline.net> Message-ID: X-ReSent-Date: Sat, 15 Dec 2007 10:17:20 -0800 (PST) X-ReSent-From: Mark Crispin X-ReSent-To: TOPS-20 Hackers and Yackers X-ReSent-Subject: Re: DELNF% is very disrespectful to DF%NRJ X-ReSent-Message-ID: X-ReSent-User-Agent: Alpine 1.00 (OSX 873 2007-12-15) ReSent-Date: Sat, 15 Dec 2007 10:17:50 -0800 (PST) ReSent-From: TOPS-20 List Moderator ReSent-To: TOPS-20 Distribution: ; ReSent-Subject: Re: DELNF% is very disrespectful to DF%NRJ ReSent-Message-ID: ReSent-User-Agent: Alpine 1.00 (OSX 873 2007-12-15) > The original design of the EFTPSR directory listing code was supposed > to be general enough to handle something called the "Trivial Virtual > File Store (TVFS)". Basically this meant taking the winning Tops-20 > file specification format and lobotomizing it for some new verbs > called MLST and MLSD (see RFC 3659 for more details). For example: > > size=4161;lang=en-US;modify=19970214165800;create=19961001124534; - > type=file;x.myfact=foo,bar; > > Nice and obvious, eh? But, almost nothing I had could grok this (I > think Kermit-95 does, Frank?). > And C-Kermit: http://www.columbia.edu/kermit/ckermit80.html#x3.11 Btw, I believe MLST/MLSD and TVFS are separate concepts. TVFS just presents a "standard intermediate" (and yes, lowest-common-denominator) file system for FTP, not so much because it's a good idea but because most FTP clients at the time assumed that all servers were Unix. - Frank 15-Dec-2007 21:19:43-PST,3517;000000000000 Return-Path: Received: from pangtzu.panda.com ([206.124.149.117]) by Lingling.Panda.COM with TCP/SMTP; Sat, 15 Dec 2007 21:15:18 -0800 (PST) X-Return-Path: X-Received: from mxout1.cac.washington.edu ([140.142.32.134]) by Lingling.Panda.COM with TCP/SMTP; Sat, 15 Dec 2007 21:12:18 -0800 (PST) X-Received: from smtp.washington.edu (smtp.washington.edu [140.142.32.141] (may be forged)) by mxout1.cac.washington.edu (8.13.7+UW06.06/8.13.7+UW07.09) with ESMTP id lBG5CDPs014427 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Sat, 15 Dec 2007 21:12:13 -0800 X-Auth-Received: from pangtzu.panda.com (pangtzu.panda.com [206.124.149.117]) (authenticated authid=mrc) by smtp.washington.edu (8.13.7+UW06.06/8.13.7+UW07.09) with ESMTP id lBG5CBmF021706 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Sat, 15 Dec 2007 21:12:12 -0800 Date: Sat, 15 Dec 2007 21:12:08 -0800 (PST) From: Mark Crispin Sender: mrc@pangtzu.panda.com To: TOPS-20 Hackers and Yackers Subject: Re: panda dist TOPS-20 question (fwd) Message-ID: User-Agent: Alpine 1.00 (OSX 873 2007-12-15) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-PMX-Version: 5.3.3.310218, Antispam-Engine: 2.5.2.313940, Antispam-Data: 2007.12.15.205833 X-Uwash-Spam: Gauge=IIIIIII, Probability=7%, Report='__CP_URI_IN_BODY 0, __CT 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0, __USER_AGENT 0' ReSent-Date: Sat, 15 Dec 2007 21:15:13 -0800 (PST) ReSent-From: TOPS-20 List Moderator ReSent-To: TOPS-20 Distribution: ; ReSent-Subject: Re: panda dist TOPS-20 question (fwd) ReSent-Message-ID: ReSent-User-Agent: Alpine 1.00 (OSX 873 2007-12-15) The information below is of interest to anyone who is running klh10 on a FreeBSD platform: -- 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. ---------- Forwarded message ---------- Date: Sat, 15 Dec 2007 21:33:08 -0500 From: Mark Abene To: Mark Crispin Subject: Re: panda dist TOPS-20 question Nothing this obvious, as the telnets are local. :) However, last night I discovered the problem, and a solution. Apparently on FreeBSD it is the default to have the SO_KEEPALIVE option set on all tcp packets. I verified with tcpdump that TOPS-20 doesn't respond to keepalive probe packets. It is also the default on FreeBSD to wait 130 minutes of idle time on a tcp connection before sending 8 of these probe packets every 75 seconds. If there's no ack response from the other end to any of them, the connection is reset. I verified this by setting the "net.inet.tcp.keepidle" kernel option to 1 minute instead of 130 minutes, and my idle session in TOPS-20 was in fact dropped after a minute. The solution is simple: just set "net.inet.tcp.always_keepalive" to 0. My session has been logged in since last night, idle time and all, without interruption. What a relief. This is bound to come up eventually in the emulation "scene", so I wanted to pass along all the details. Regards, Mark 20-Dec-2007 11:33:47-PST,1795;000000000000 Return-Path: Received: from pangtzu.panda.com ([206.124.149.117]) by Lingling.Panda.COM with TCP/SMTP; Thu, 20 Dec 2007 11:29:09 -0800 (PST) X-Return-Path: X-Received: from xkleten.paulallen.com ([216.220.195.10]) by Lingling.Panda.COM with TCP/SMTP; Thu, 20 Dec 2007 09:54:17 -0800 (PST) Date: Thu, 20 Dec 2007 09:52:22 -0800 From: Rich Alderson Subject: Happy DEC-20 Day! To: tops-20@lingling.panda.com Reply-To: RichA@vulcan.com Message-ID: <14274984593.12.ALDERSON@xkleten.paulallen.com> ReSent-Date: Thu, 20 Dec 2007 11:29:01 -0800 (PST) ReSent-From: TOPS-20 List Moderator ReSent-To: TOPS-20 Distribution: ; ReSent-Subject: Happy DEC-20 Day! ReSent-Message-ID: ReSent-User-Agent: Alpine 1.00 (OSX 873 2007-12-15) From the pages of an XKL Toad-1 System! TOPS-20 Command processor 7(5000)-3 !sy a Thu 20-Dec-2007 09:49:28 Up 2850:10:48 3+6 Jobs Load av 0.08 0.04 0.02 Job CJB Line Program State Time Limit User, Origin 7 DET EXEC RUN 0:04:28 ALDERSON 12* 26 SYSTAT RUN 0:00:06 ALDERSON (c-76-104-154-244.hsd1.wa.comcast.net) 13 25 EXEC TI 0:00:45 SETALA (phys-staff2.kolumbus.fi) 1 0 1 OPR TI 0:00:02 OPERATOR 2 0 2 NETSRV TI 0:55:29 OPERATOR 3 0 3 RESOLV RUN 3:07:22 OPERATOR, PS: 4 0 4 MMAILR RUN 4:46:55 OPERATOR 5 0 5 EXEC TI 0:00:58 OPERATOR 6 0 6 MAILST RUN 0:00:00 OPERATOR ! ------- 20-Dec-2007 21:32:45-PST,1982;000000000000 Return-Path: Received: from pangtzu.panda.com ([206.124.149.117]) by Lingling.Panda.COM with TCP/SMTP; Thu, 20 Dec 2007 21:28:29 -0800 (PST) X-Return-Path: X-Received: from mta2.srv.hcvlny.cv.net ([167.206.4.197]) by Lingling.Panda.COM with TCP/SMTP; Thu, 20 Dec 2007 18:27:43 -0800 (PST) X-Received: from [192.168.1.7] (ool-45720130.dyn.optonline.net [69.114.1.48]) by mta2.srv.hcvlny.cv.net (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTP id <0JTD00DV7O61EVR0@mta2.srv.hcvlny.cv.net> for tops-20@lingling.panda.com; Thu, 20 Dec 2007 21:27:38 -0500 (EST) Date: Thu, 20 Dec 2007 21:27:36 -0500 From: Thomas DeBellis Subject: Re: Happy DEC-20 Day! In-reply-to: <14274984593.12.ALDERSON@xkleten.paulallen.com> To: RichA@vulcan.com Cc: tops-20@lingling.panda.com Message-id: <476B2498.7010101@optonline.net> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en References: <14274984593.12.ALDERSON@xkleten.paulallen.com> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) ReSent-Date: Thu, 20 Dec 2007 21:28:19 -0800 (PST) ReSent-From: TOPS-20 List Moderator ReSent-To: TOPS-20 Distribution: ; ReSent-Subject: Re: Happy DEC-20 Day! ReSent-Message-ID: ReSent-User-Agent: Alpine 1.00 (OSX 882 2007-12-20) > Thu 20-Dec-2007 09:49:28 Up 2850:10:48 Hmmm... I think you'd better call Field Service, it looks like you are having some uptime issues. @timeT2.EXE.2 Tops-20 was booted on Thursday, July 5, 2007 7:52:09AM-EDT. It will crash with an UP2LNG BUGHLT on Wednesday, August 6, 2008 12:14:27AM-EDT. @iNFORMATION (ABOUT) monITOR-STATISTICS Up 4046:29:45!!!! I may be headed for a second BUGHLT over here ... :-) 21-Dec-2007 12:19:32-PST,2253;000000000000 Return-Path: Received: from pangtzu.panda.com ([206.124.149.117]) by Lingling.Panda.COM with TCP/SMTP; Fri, 21 Dec 2007 12:15:18 -0800 (PST) X-Return-Path: X-Received: from mail2.panix.com ([166.84.1.73]) by Lingling.Panda.COM with TCP/SMTP; Fri, 21 Dec 2007 10:33:26 -0800 (PST) X-Received: from panix5.panix.com (panix5.panix.com [166.84.1.5]) by mail2.panix.com (Postfix) with ESMTP id B25DA3480C for ; Fri, 21 Dec 2007 13:33:21 -0500 (EST) X-Received: (from alderson@localhost) by panix5.panix.com (8.11.6p3/8.8.8/PanixN1.1) id lBLIXLD12894; Fri, 21 Dec 2007 13:33:21 -0500 (EST) Date: Fri, 21 Dec 2007 13:33:21 -0500 (EST) Message-Id: <200712211833.lBLIXLD12894@panix5.panix.com> From: Rich Alderson To: tops-20@lingling.panda.com In-reply-to: <476B2498.7010101@optonline.net> (message from Thomas DeBellis on Thu, 20 Dec 2007 21:27:36 -0500) Subject: Re: Happy DEC-20 Day! References: <14274984593.12.ALDERSON@xkleten.paulallen.com> <476B2498.7010101@optonline.net> ReSent-Date: Fri, 21 Dec 2007 12:15:09 -0800 (PST) ReSent-From: TOPS-20 List Moderator ReSent-To: TOPS-20 Distribution: ; ReSent-Subject: Re: Happy DEC-20 Day! ReSent-Message-ID: ReSent-User-Agent: Alpine 1.00 (OSX 882 2007-12-20) > Date: Thu, 20 Dec 2007 21:27:36 -0500 > From: Thomas DeBellis > > Thu 20-Dec-2007 09:49:28 Up 2850:10:48 > Hmmm... I think you'd better call Field Service, > it looks like you are having some uptime issues. The system gets taken down for administrative reasons from time to time. "Nothing to see here, folks. Move along, move along." :-) > @timeT2.EXE.2 > Tops-20 was booted on Thursday, July 5, 2007 7:52:09AM-EDT. > It will crash with an UP2LNG BUGHLT on Wednesday, August 6, 2008 12:14:27AM-EDT. > @iNFORMATION (ABOUT) monITOR-STATISTICS > Up 4046:29:45!!!! > I may be headed for a second BUGHLT over here ... :-) Remind me--does that have the corrected UP2LNG code in place? Rich 22-Dec-2007 16:19:39-PST,3818;000000000000 Return-Path: Received: from pangtzu.panda.com ([206.124.149.117]) by Lingling.Panda.COM with TCP/SMTP; Sat, 22 Dec 2007 16:15:38 -0800 (PST) X-Return-Path: X-Received: from mta3.srv.hcvlny.cv.net ([167.206.4.198]) by Lingling.Panda.COM with TCP/SMTP; Sat, 22 Dec 2007 13:30:43 -0800 (PST) X-Received: from [192.168.1.7] (ool-45720130.dyn.optonline.net [69.114.1.48]) by mta3.srv.hcvlny.cv.net (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTP id <0JTG00BP8ZQUD0R0@mta3.srv.hcvlny.cv.net> for TOPS-20@lingling.panda.com; Sat, 22 Dec 2007 16:30:33 -0500 (EST) Date: Sat, 22 Dec 2007 16:30:28 -0500 From: Thomas DeBellis Subject: backwr In-reply-to: <200712211833.lBLIXLD12894@panix5.panix.com> To: Tops-20 Wizards Message-id: <476D81F4.4010308@optonline.net> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en References: <14274984593.12.ALDERSON@xkleten.paulallen.com> <476B2498.7010101@optonline.net> <200712211833.lBLIXLD12894@panix5.panix.com> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) ReSent-Date: Sat, 22 Dec 2007 16:15:28 -0800 (PST) ReSent-From: TOPS-20 List Moderator ReSent-To: TOPS-20 Distribution: ; ReSent-Subject: backwr ReSent-Message-ID: ReSent-User-Agent: Alpine 1.00 (OSX 882 2007-12-20) I needed a means to transfer a large (huge, actually) number of files of various sizes into my machine. The purpose of this is for regression testing and I wanted completely seperate data path into the machine besides FTP (which is what I am testing in the first place). Using the BBN server is out because of speed considerations: sometimes it's well over a (decimal) order of magnitude slower than the extended mode server. However, I am still doing seperate regession tests with that server (naturally). Kermit is also out. I just can't get the speed I need. So, a magnetic tape is the obvious solution, which is what I used. I looked around for a utility to write tape files, found backwr and after short while had a working tape file to load lots of stuff. Nice. Fast. Unfortunately, backwr really doesn't have any sort of documentation, not even a usage line. So I obviously looked at the code and got what I needed out of it. But I would like to know more. What I downloaded is: -rw-rw-rw- 1 Data Hero 116 Oct 1 2001 Makefile -rw-rw-rw- 1 Data Hero 3245 Oct 1 2001 backup.h -rw-rw-rw- 1 Data Hero 17063 Oct 1 2001 backwr.c -rw-rw-rw- 1 Data Hero 595 Oct 1 2001 sysdep.c -rw-rw-rw- 1 Data Hero 99 Oct 1 2001 sysdep.h No real documentation there ... Is there any to be had? A man page? Something I might stick in DOC:, per chance? Anybody care to do this? I would (see below), but that would mean spending a bit of time noodling over the source and anything that isn't directly on the path of getting the alpha candidate ready is out for me. Discipline is such a chore sometimes. Frank was always on us to write documentation and so an entire module in the new server is help text (108 pages). ALso, whenever I come across something that I don't/can't remember/understand in the machine, I sometimes write up a short explanation and stick it in PS:. Then I have a good grin remembering Frank nagging us all about it. At some point, I plan on getting some of my stuff back to MRC for review and possible inclusion in a future PANDA distribution. It's not all just hacking. 23-Dec-2007 22:55:04-PST,1434;000000000001 Return-Path: Received: from pangtzu.panda.com ([206.124.149.117]) by Lingling.Panda.COM with TCP/SMTP; Sun, 23 Dec 2007 22:50:31 -0800 (PST) X-Return-Path: X-Received: from pangtzu.panda.com ([206.124.149.117]) by Lingling.Panda.COM with TCP/SMTP; Sun, 23 Dec 2007 22:23:26 -0800 (PST) Date: Sun, 23 Dec 2007 22:23:23 -0800 (PST) From: Mark Crispin Sender: mrc@pangtzu.panda.com To: TOPS-20 Hackers and Yackers Subject: One TOPS-20 Per Child Message-ID: User-Agent: Alpine 1.00 (OSX 882 2007-12-20) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII ReSent-Date: Sun, 23 Dec 2007 22:50:24 -0800 (PST) ReSent-From: TOPS-20 List Moderator ReSent-To: TOPS-20 Distribution: ; ReSent-Subject: One TOPS-20 Per Child ReSent-Message-ID: ReSent-User-Agent: Alpine 1.00 (OSX 882 2007-12-20) Well...I tried running klh10 on my newly-acquired OLPC XO. It does run, however the Terminal activity makes it rather frustrating because both CTRL/Q and CTRL/O are specials. Also, it looks like I need to turn off the fancy clock handling as I get DTE timing errors. -- Mark -- http://panda.com/tops-20 TOPS-20: a great improvement over its successors 26-Dec-2007 11:11:27-PST,2795;000000000000 Return-Path: Received: from pangtzu.panda.com ([206.124.149.117]) by Lingling.Panda.COM with TCP/SMTP; Wed, 26 Dec 2007 11:07:17 -0800 (PST) X-Return-Path: X-Received: from mail1.acecape.com ([66.114.74.12]) by Lingling.Panda.COM with TCP/SMTP; Wed, 26 Dec 2007 08:55:49 -0800 (PST) X-Received: from [192.168.2.7] (p69-214.acedsl.com [66.114.69.214]) by mail1.acecape.com (8.13.8/8.13.8) with ESMTP id lBQGth2P028770 for ; Wed, 26 Dec 2007 11:55:44 -0500 Message-ID: <4772878F.2070900@acedsl.com> Date: Wed, 26 Dec 2007 11:55:43 -0500 From: Thomas DeBellis User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tops-20 Wizards Subject: HLRI-HLRZI / XHLRI-XLRZI? Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit ReSent-Date: Wed, 26 Dec 2007 11:07:10 -0800 (PST) ReSent-From: TOPS-20 List Moderator ReSent-To: TOPS-20 Distribution: ; ReSent-Subject: HLRI-HLRZI / XHLRI-XLRZI? ReSent-Message-ID: ReSent-User-Agent: Alpine 1.00 (OSX 882 2007-12-20) Many times when I want to operate on the section part of an address, I find myself getting somewhat miffed at (what I remember are) the (only?) two instructions that I have to do this. This is because both XMOVEI and XHLLI put the section number in the left half word, which is right where I don't want it to be. Here are two typical examples: 1) By definition, section numbers are less than 18 bits, which means that in many (actually, most) cases, I can use the immediate mode instructions to operate on them. That is, provided they are in the right half word... 2) Or how about your favorite JSYS? Take SMAP%, for example: it only wants section numbers in the right half word which is right where XHLLI doesn't put it. I understand all about HLRZ (or maybe LDB) and all that, but I'd still like to load the section number into the right half word and bum the inter-half word frobinicating. Bad habits from my WPI days--we rewrote a lot of our Tops-10 CUSPS to run in less core. I remember a substantial reduction in DIRECT, I think the high segment went from 10K to something like 5 (or 7?) Put bluntly, I need the CAR of the address word to return the same range of values that the CDR does. It seems that, given the operation of HLRI and HLRZI in section 0, they could be changed to perform similar operations as HLLI in non-zero sections. Is there anything that does this? Should there be/have been? 28-Dec-2007 20:46:19-PST,3553;000000000000 Return-Path: Received: from pangtzu.panda.com ([206.124.149.117]) by Lingling.Panda.COM with TCP/SMTP; Fri, 28 Dec 2007 20:41:43 -0800 (PST) X-Return-Path: X-Received: from mail1.acecape.com ([66.114.74.12]) by Lingling.Panda.COM with TCP/SMTP; Fri, 28 Dec 2007 12:20:44 -0800 (PST) X-Received: from [192.168.2.7] (p69-214.acedsl.com [66.114.69.214]) by mail1.acecape.com (8.13.8/8.13.8) with ESMTP id lBSKKd7E026660 for ; Fri, 28 Dec 2007 15:20:39 -0500 Message-ID: <47755A96.9030206@acedsl.com> Date: Fri, 28 Dec 2007 15:20:38 -0500 From: Thomas DeBellis User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tops-20 Wizards Subject: Section 0 word pointers from a non-zero section? Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit ReSent-Date: Fri, 28 Dec 2007 20:41:36 -0800 (PST) ReSent-From: TOPS-20 List Moderator ReSent-To: TOPS-20 Distribution: ; ReSent-Subject: Section 0 word pointers from a non-zero section? ReSent-Message-ID: ReSent-User-Agent: Alpine 1.00 (OSX 882 2007-12-20) Can anybody give me a quick example of a global word pointer that I can use in a non-zero section in an index register? I don't want to use indirection. As background, I have some text files of varying sizes that I need to sort in a particular way based on pecular criteria. My I/O scheme is pretty simplistic: the program runs in the highest section that I can get (in my case, 37) and I start mapping the text file in at the base of section zero at page 1. The sort table is a list of double words. The first word is a one word global 7 bit pointer and the next word is the length of the string that I've isolated. It is built on the next page after the last page of the mapped file and grows upwards. Since the first file that I am working with is 737 pages, this all works fine because the sort table is in a non-zero section. One word global pointers work fine to reference section zero (which is why it's such a great place to store text). The index pointers to the sort table also work fine as long as the address is outside of section zero. For a file that doesn't completely exhaust section 0, the sort table itself will start in section zero and the word addresses that I construct will then look like section local (37) pointers and I get the wrong thing. I don't think I've understood how to construct or use an index word pointer for section zero. In other words, at the end of the program below, T2 has the contents of BAR while T3 has the contents of FOO. I want T2 to have the contents of FOO. What kind of pointer do I have to put in T1 for the de-indexing to work the way I want (put FOO in T2)? TITLE ADRTST SEARCH MONSYM,MACSYM STDAC. .PSECT ZERO,0001000 FOO: 1234567 .ENDPS .PSECT CODE,1001000 BAR: 7654321 ADRTST: RESET% MOVEI T1,FOO ; Load section offset of foo HLL T1,[ZERO] ; Load foo's offset MOVE T2,(T1) ; Load foo (but gets bar) MOVE T3,@T1 ; Load foo (and gets foo) HALTF% JRST ADRTST .ENDPS END ADRTST 28-Dec-2007 21:24:24-PST,2510;000000000000 Return-Path: Received: from pangtzu.panda.com ([206.124.149.117]) by Lingling.Panda.COM with TCP/SMTP; Fri, 28 Dec 2007 21:20:44 -0800 (PST) X-Return-Path: X-Received: from pangtzu.panda.com ([206.124.149.117]) by Lingling.Panda.COM with TCP/SMTP; Fri, 28 Dec 2007 21:16:22 -0800 (PST) Date: Fri, 28 Dec 2007 21:16:18 -0800 (PST) From: Mark Crispin Sender: mrc@pangtzu.panda.com To: Thomas DeBellis cc: Tops-20 Wizards Subject: Re: Section 0 word pointers from a non-zero section? In-Reply-To: <47755A96.9030206@acedsl.com> Message-ID: References: <47755A96.9030206@acedsl.com> User-Agent: Alpine 1.00 (OSX 882 2007-12-20) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII ReSent-Date: Fri, 28 Dec 2007 21:20:38 -0800 (PST) ReSent-From: TOPS-20 List Moderator ReSent-To: TOPS-20 Distribution: ; ReSent-Subject: Re: Section 0 word pointers from a non-zero section? ReSent-Message-ID: ReSent-User-Agent: Alpine 1.00 (OSX 882 2007-12-20) Refer to pages 1-28 through 1-30 of the PRM, specifically: Global indexing occurs when the address word is global, or the address word is local but the left half of the index register is positive and bits 6-17 contain a nonzero section number. In either case the restult is a global address. When the address word is global, the index is taken as global and is added to Y (bits 6-35 of the global indirect word). This is simply a global extension of local indexing; the address word may contain an address and the index register an unsigned offset, or vice versa; adding a large offset can be the same as subtracting a small one. The case where the address word is local is quite unlike local indexing; the index is assumed to be a global address, and the 18-bit Y is interpreted as a signed displacement (maximum magnitude 2^17), which is added to it algebraically. In other words, in a non-zero section: An index word from an instruction, or an IFIW (bit 0 non-zero, bit 1 zero), is global if, and only if, bit 0 is zero and bits 6-17 are non-zero. An index word from a global indirect word (bit 0 is zero) is always global. -- Mark -- http://panda.com/tops-20 TOPS-20: a great improvement over its successors 31-Dec-2007 08:48:15-PST,2516;000000000000 Return-Path: Received: from pangtzu.panda.com ([206.124.149.117]) by Lingling.Panda.COM with TCP/SMTP; Mon, 31 Dec 2007 08:43:49 -0800 (PST) X-Return-Path: X-Received: from mail1.acecape.com ([66.114.74.12]) by Lingling.Panda.COM with TCP/SMTP; Mon, 31 Dec 2007 08:38:34 -0800 (PST) X-Received: from [192.168.2.7] (p69-214.acedsl.com [66.114.69.214]) by mail1.acecape.com (8.13.8/8.13.8) with ESMTP id lBVGcUCT006562; Mon, 31 Dec 2007 11:38:30 -0500 Message-ID: <47791B05.9090106@acedsl.com> Date: Mon, 31 Dec 2007 11:38:29 -0500 From: Thomas DeBellis User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Mark Crispin CC: Tops-20 Wizards Subject: Re: Section 0 word pointers from a non-zero section? References: <47755A96.9030206@acedsl.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit ReSent-Date: Mon, 31 Dec 2007 08:43:43 -0800 (PST) ReSent-From: TOPS-20 List Moderator ReSent-To: TOPS-20 Distribution: ; ReSent-Subject: Re: Section 0 word pointers from a non-zero section? ReSent-Message-ID: ReSent-User-Agent: Alpine 1.00 (OSX 882 2007-12-20) Yes, having read the material in the PRM and related information in DOC: and regrettably, having failed (relatively speaking) to fully grasp all of its ramifications, I was wondering if perhaps it might not be possible to distill this down to some trivial statements. Is the following true? " If you want to address data in section zero from a non-zero section, you must either use a one word global pointer or global indirection. Simple indexing alone via an index register will not work. " Did I miss anything for this specific simple case? Mark Crispin wrote: > Refer to pages 1-28 through 1-30 of the PRM, specifically: > > ... > > In other words, in a non-zero section: > > An index word from an instruction, or an IFIW (bit 0 non-zero, bit 1 > zero), is global if, and only if, bit 0 is zero and bits 6-17 are non-zero. > > An index word from a global indirect word (bit 0 is zero) is always global. 31-Dec-2007 11:56:15-PST,2363;000000000000 Return-Path: Received: from pangtzu.panda.com ([206.124.149.117]) by Lingling.Panda.COM with TCP/SMTP; Mon, 31 Dec 2007 11:52:24 -0800 (PST) X-Return-Path: X-Received: from b.mail.sonic.net ([64.142.19.5]) by Lingling.Panda.COM with TCP/SMTP; Mon, 31 Dec 2007 11:46:04 -0800 (PST) X-Received: from Amiga.local (64-142-29-114.dsl.static.sonic.net [64.142.29.114]) by b.mail.sonic.net (8.13.8.Beta0-Sonic/8.13.7) with ESMTP id lBVJjx3G011425 for ; Mon, 31 Dec 2007 11:45:59 -0800 Date: Mon, 31 Dec 2007 11:45:59 -0800 (PST) From: Fred Wright X-Sender: fw@Amiga.local Reply-To: Fred Wright To: Tops-20 Wizards Subject: Re: Section 0 word pointers from a non-zero section? In-Reply-To: <47791B05.9090106@acedsl.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII ReSent-Date: Mon, 31 Dec 2007 11:52:14 -0800 (PST) ReSent-From: TOPS-20 List Moderator ReSent-To: TOPS-20 Distribution: ; ReSent-Subject: Re: Section 0 word pointers from a non-zero section? ReSent-Message-ID: ReSent-User-Agent: Alpine 1.00 (OSX 882 2007-12-20) On Mon, 31 Dec 2007, Thomas DeBellis wrote: > Yes, having read the material in the PRM and related information in > DOC: and regrettably, having failed (relatively speaking) to fully > grasp all of its ramifications, I was wondering if perhaps it might > not be possible to distill this down to some trivial statements. > > Is the following true? > > " If you want to address data in section zero from a non-zero > section, you must either use a one word global pointer or global > indirection. Simple indexing alone via an index register will not > work. " > > Did I miss anything for this specific simple case? Section 0 is the "legacy section". Pure extended programs should not use section 0 *at all*. Programs that need to mix extended and nonextended code should overmap sections 0 and 1 (a la TOPS-10 and TOPS-20), so that extended code can reference section 0 through its section 1 alias. And section 37 should be avoided because DDT uses it. Fred Wright 31-Dec-2007 12:03:06-PST,2021;000000000000 Return-Path: Received: from pangtzu.panda.com ([206.124.149.117]) by Lingling.Panda.COM with TCP/SMTP; Mon, 31 Dec 2007 11:59:27 -0800 (PST) X-Return-Path: X-Received: from pangtzu.panda.com ([206.124.149.117]) by Lingling.Panda.COM with TCP/SMTP; Mon, 31 Dec 2007 11:59:11 -0800 (PST) Date: Mon, 31 Dec 2007 11:59:07 -0800 (PST) From: Mark Crispin Sender: mrc@pangtzu.panda.com To: Fred Wright cc: Tops-20 Wizards Subject: Re: Section 0 word pointers from a non-zero section? In-Reply-To: Message-ID: References: User-Agent: Alpine 1.00 (OSX 882 2007-12-20) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed ReSent-Date: Mon, 31 Dec 2007 11:59:20 -0800 (PST) ReSent-From: TOPS-20 List Moderator ReSent-To: TOPS-20 Distribution: ; ReSent-Subject: Re: Section 0 word pointers from a non-zero section? ReSent-Message-ID: ReSent-User-Agent: Alpine 1.00 (OSX 882 2007-12-20) On Mon, 31 Dec 2007, Fred Wright wrote: > Section 0 is the "legacy section". Pure extended programs should not use > section 0 *at all*. Programs that need to mix extended and nonextended > code should overmap sections 0 and 1 (a la TOPS-10 and TOPS-20), so that > extended code can reference section 0 through its section 1 alias. > And section 37 should be avoided because DDT uses it. For the record: I didn't want to say that myself, but since Fred did so for me, I agree with everything he says. I was unhappy to discover that I couldn't remove section 0 entirely when I wrote MAPSER (the TOPS-20 IMAP2 server). -- Mark -- http://panda.com/tops-20 TOPS-20: a great improvement over its successors 31-Dec-2007 18:13:52-PST,4991;000000000000 Return-Path: Received: from pangtzu.panda.com ([206.124.149.117]) by Lingling.Panda.COM with TCP/SMTP; Mon, 31 Dec 2007 18:09:28 -0800 (PST) X-Return-Path: X-Received: from mta5.srv.hcvlny.cv.net ([167.206.4.200]) by Lingling.Panda.COM with TCP/SMTP; Mon, 31 Dec 2007 16:48:44 -0800 (PST) X-Received: from [192.168.1.7] (ool-45720130.dyn.optonline.net [69.114.1.48]) by mta5.srv.hcvlny.cv.net (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTP id <0JTX00GQKWX2H2B0@mta5.srv.hcvlny.cv.net> for TOPS-20@Lingling.Panda.COM; Mon, 31 Dec 2007 19:48:38 -0500 (EST) Date: Mon, 31 Dec 2007 19:48:37 -0500 From: Thomas DeBellis Subject: Re: Section 0 word pointers from a non-zero section? In-reply-to: To: Fred Wright Cc: Tops-20 Wizards Message-id: <47798DE5.7070106@optonline.net> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en References: User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) ReSent-Date: Mon, 31 Dec 2007 18:09:20 -0800 (PST) ReSent-From: TOPS-20 List Moderator ReSent-To: TOPS-20 Distribution: ; ReSent-Subject: Re: Section 0 word pointers from a non-zero section? ReSent-Message-ID: ReSent-User-Agent: Alpine 1.00 (OSX 882 2007-12-20) > Pure extended programs should not use section 0 *at all*. A number of things come to mind about this. Like Mark, I was surprised to find out that I couldn't get rid of section zero. At the time (2004), I thought that not having it around would have been a feature. When we started porting our VAX based Unix programs to our Sun 4, a number of bugs showed up because NUL pointers were being de- referenced. The VAX allows you to de-reference address zero; on SPARC, this produces an error. Because this produces an error, I began to think of it as a very nice hardware feature. Likewise, when programming (in assembler) on the 80286 platform (protected mode segments), you can also set things up in a similar way so that these sorts of de-references produce errors. I expected the same thing for Tops-20. One speculates that this isn't a limitation of the KL pager hardware itself and I have been tempted to do some strategic JFCL'ing in SMAP% (and elsewhere) to see what happens if you do punt section zero. Does anybody know anything about this? That being said, I'm currently stuck with section zero and it seemed like a shame to just have 3% of the virtual address space be off limits. I mean, if I can't have a program detonate by using section zero, what CAN I do with it?? At one point, I had considered setting every page in section zero to point to a guard page, but that seemed like such a waste. Because of the way one word global pointers work, section zero wound up being a fine place to put program text. EFTPSR has a lot of text down there (over 112 pages at this point). I also use it for transient page buffering. Likewise, when sorting a large text file, global one word pointers work just fine; if you can map the file in at section zero (page 1!!!), then you have more virtual address space to play with and can do larger files. On the KL, eliminating two sections (see below), means about a 6% reduction in sort file sizes. Why? > And section 37 should be avoided because DDT uses it. Again, I have mixed feelings about reserving 3% of the virtual address space for the exclusive use of something. Also, as far as DDT is concerned, having it in section 37 hasn't always worked for me. There are situations where patching gronked and you can still smash DDT. For now, my symbol table is up in section 37 with DDT, but the program itself is in section 3. I get more section local virtual address space, that way. However, my vote is still for IDDT. A debugger's true place is where a program can't (easily) get at it. At WPI, our (KA-10 based 6.00 series) Tops-10 monitor was modified to have DDT run in an entirely seperate job. That was nice because you could debug anything, not run out of memory and still not have to worry about DDT getting whacked. Resolved: 1) Section zero should be removable and not autorematerialisable 2) DDT shouldn't be anywhere where a program can get at it But to return to my original point, have I missed anything essential from the summation, below? " If you want to address data in section zero from a non-zero section, you must either use a one word global pointer or global indirection. Simple indexing alone via an index register will not work. " 31-Dec-2007 18:17:41-PST,1724;000000000000 Return-Path: Received: from pangtzu.panda.com ([206.124.149.117]) by Lingling.Panda.COM with TCP/SMTP; Mon, 31 Dec 2007 18:09:41 -0800 (PST) X-Return-Path: X-Received: from pangtzu.panda.com ([206.124.149.117]) by Lingling.Panda.COM with TCP/SMTP; Mon, 31 Dec 2007 18:07:32 -0800 (PST) Date: Mon, 31 Dec 2007 18:07:28 -0800 (PST) From: Mark Crispin Sender: mrc@pangtzu.panda.com To: TOPS-20 Hackers and Yackers Subject: success: One TOPS-20 Per Child Message-ID: User-Agent: Alpine 1.00 (OSX 882 2007-12-20) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII ReSent-Date: Mon, 31 Dec 2007 18:09:35 -0800 (PST) ReSent-From: TOPS-20 List Moderator ReSent-To: TOPS-20 Distribution: ; ReSent-Subject: success: One TOPS-20 Per Child ReSent-Message-ID: ReSent-User-Agent: Alpine 1.00 (OSX 882 2007-12-20) After turning off KLH10's fancy clock handling (setting KLH10_ITIME_SYNC instead of KLH10_ITIME_INTRP), TOPS-20 now run on an OLPC! And I bet that you're all dying to hear the performance figures. An OLPC XO running TOPS-20 does 4,846 Dhrystones/second. Comparable figures, all running TOPS-20: Lingling 31,847 XKL-1 3,163 Nokia N800 2,751 DEC 2065 1,946 DEC 2020 425 For what it's worth, Lingling's host system does 1,020,408 and the OLPC host does 209,643. Current generation x86 hardware does over 2 million. -- Mark -- http://panda.com/tops-20 TOPS-20: a great improvement over its successors 31-Dec-2007 18:39:45-PST,2539;000000000000 Return-Path: Received: from pangtzu.panda.com ([206.124.149.117]) by Lingling.Panda.COM with TCP/SMTP; Mon, 31 Dec 2007 18:36:04 -0800 (PST) X-Return-Path: X-Received: from pangtzu.panda.com ([206.124.149.117]) by Lingling.Panda.COM with TCP/SMTP; Mon, 31 Dec 2007 18:27:47 -0800 (PST) Date: Mon, 31 Dec 2007 18:27:44 -0800 (PST) From: Mark Crispin Sender: mrc@pangtzu.panda.com To: Thomas DeBellis cc: Fred Wright , Tops-20 Wizards Subject: Re: Section 0 word pointers from a non-zero section? In-Reply-To: <47798DE5.7070106@optonline.net> Message-ID: References: <47798DE5.7070106@optonline.net> User-Agent: Alpine 1.00 (OSX 882 2007-12-20) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed ReSent-Date: Mon, 31 Dec 2007 18:35:56 -0800 (PST) ReSent-From: TOPS-20 List Moderator ReSent-To: TOPS-20 Distribution: ; ReSent-Subject: Re: Section 0 word pointers from a non-zero section? ReSent-Message-ID: ReSent-User-Agent: Alpine 1.00 (OSX 882 2007-12-20) On Mon, 31 Dec 2007, Thomas DeBellis wrote: > One speculates that this isn't a limitation of the KL pager hardware > itself and I have been tempted to do some strategic JFCL'ing in SMAP% > (and elsewhere) to see what happens if you do punt section zero. Does > anybody know anything about this? I'll bet that it has something to do with the ACs. The first 16 locations of both section 0 and section 1 are shadowed by the ACs. > At one point, I had considered setting every page in section zero to > point to a guard page, but that seemed like such a waste. I planned on doing that in MAPSER, but never go around to it. IIRC, the only way to have a true guard page is to map it to a non-existant page in a file that is write-protected against the process since anything else will create the page. > However, my vote is still for IDDT. A debugger's true place is where > a program can't (easily) get at it. Well, yes; but the IDDT program itself is hopelessly mired in Tenex. I don't think that it does extended addressing, much less any of the new DDT capabilities. -- Mark -- http://panda.com/tops-20 TOPS-20: a great improvement over its successors