4-Jan-2007 17:16:56-PST,1637;000000000000
Return-Path: <
[email protected]>
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: <
[email protected]>
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 <
[email protected]>
Sender:
[email protected]
To: TOPS-20 Hackers and Yackers <
[email protected]>
Subject: TOPS-20 list traffic: second highest year ever!
Message-ID: <
[email protected]>
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 <
[email protected]>
ReSent-To: TOPS-20 Distribution: ;
ReSent-Subject: TOPS-20 list traffic: second highest year ever!
ReSent-Message-ID: <
[email protected]>
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: <
[email protected]>
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: <
[email protected]>
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 <
[email protected]> for
[email protected]; 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:
[email protected]
Subject: Floating Away, Doubly So
To:
[email protected]
Message-id: <
[email protected]>
MIME-version: 1.0
X-Mailer: Sun Java(tm) System Messenger Express 6.2-6.01 (built Apr 3 2006)
Content-type: text/plain; charset=us-ascii
Content-language: en
Content-transfer-encoding: 7BIT
Content-disposition: inline
X-Accept-Language: en
Priority: normal
ReSent-Date: Sat, 10 Feb 2007 21:06:30 -0800 (PST)
ReSent-From: TOPS-20 List Moderator <
[email protected]>
ReSent-To: TOPS-20 Distribution: ;
ReSent-Subject: Floating Away, Doubly So
ReSent-Message-ID: <
[email protected]>
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: <
[email protected]>
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: <
[email protected]>
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 <
[email protected]>
Sender:
[email protected]
To: TOPS-20 Hackers and Yackers <
[email protected]>
Subject: TOPS-20 mailing list SMTP server now doing HELO validation
Message-ID: <
[email protected]>
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 <
[email protected]>
ReSent-To: TOPS-20 Distribution: ;
ReSent-Subject: TOPS-20 mailing list SMTP server now doing HELO validation
ReSent-Message-ID: <
[email protected]>
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,
[email protected], 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: <
[email protected]>
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: <
[email protected]>
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 <
[email protected]> for
[email protected]; 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:
[email protected]
Subject: Cancelled tape mount requests inconsistently detected in batch streams
In-reply-to: <
[email protected]>
To: TOPS-20 Wizards <
[email protected]>
Message-id: <
[email protected]>
MIME-version: 1.0
X-Mailer: Sun Java(tm) System Messenger Express 6.2-6.01 (built Apr 3 2006)
Content-type: text/plain; charset=us-ascii
Content-language: en
Content-transfer-encoding: 7BIT
Content-disposition: inline
X-Accept-Language: en
Priority: normal
References: <
[email protected]>
ReSent-Date: Fri, 23 Feb 2007 10:01:20 -0800 (PST)
ReSent-From: TOPS-20 List Moderator <
[email protected]>
ReSent-To: TOPS-20 Distribution: ;
ReSent-Subject: Cancelled tape mount requests inconsistently detected in
batch streams
ReSent-Message-ID: <
[email protected]>
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 <CR><LF>? 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 <CR>
<LF>?.
Sometimes, although not always, you will get <CR><LF>^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 <CR><LF> 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: <
[email protected]>
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: <
[email protected]>
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 <
[email protected]> for
[email protected]; 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:
[email protected]
Subject: FIND issues with non-ASCII files
In-reply-to: <
[email protected]>
To: TOPS-20 Wizards <
[email protected]>
Message-id: <
[email protected]>
MIME-version: 1.0
X-Mailer: Sun Java(tm) System Messenger Express 6.2-6.01 (built Apr 3 2006)
Content-type: text/plain; charset=us-ascii
Content-language: en
Content-transfer-encoding: 7BIT
Content-disposition: inline
X-Accept-Language: en
Priority: normal
References: <
[email protected]>
<
[email protected]>
ReSent-Date: Sat, 24 Feb 2007 21:32:44 -0800 (PST)
ReSent-From: TOPS-20 List Moderator <
[email protected]>
ReSent-To: TOPS-20 Distribution: ;
ReSent-Subject: FIND issues with non-ASCII files
ReSent-Message-ID: <
[email protected]>
Symptom:
========
FIND can crash on files with incorrect byte counts, among other
things.
Example:
========
!VDIRECTORY (VERBOSE, OF FILES) TOMMYT:<GAMES>CAVE.DAT.1
TOMMYT:<GAMES>
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:<GAMES>CAVE.DAT.1
FIND>INF
Files to search specified are:
1. TOMMYT:<GAMES>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:<SWSKIT>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 <Skipping a file with a corrupt FDB >
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 <Skipping a non-existant file >
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 <Skipping a directory file >
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 <Skipping a off-line file >
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 <OPENF failed, skipping file >
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 <Skipping file with corrupt page table >
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 <Skipping non-contiguous file >
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 <OPENF failed, skipping file > ;NO, GIVE THIS MESSAGE
2) TXNE T3,FB%OFF ;OFF-LINE?
2) WARN <Off-line file skipped - > ;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 <Skipping file unmappable pages >
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 <Cannot map input file>]
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: <
[email protected]>
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: <
[email protected]>
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 <
[email protected]> for
[email protected]; Sun, 25 Feb 2007 11:04:45 -0500 (EST)
Date: Sun, 25 Feb 2007 11:04:45 -0500
From: Rick Ace <
[email protected]>
Subject: Re: FIND issues with non-ASCII files
To: "
[email protected]" <
[email protected]>
Message-id: <optobax7vy3n3e18@amd2>
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 <
[email protected]>
ReSent-To: TOPS-20 Distribution: ;
ReSent-Subject: Re: FIND issues with non-ASCII files
ReSent-Message-ID: <
[email protected]>
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: <
[email protected]>
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: <
[email protected]>
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 <
[email protected]>
Sender:
[email protected]
To: Rick Ace <
[email protected]>
cc: "
[email protected]" <
[email protected]>
Subject: Re: FIND issues with non-ASCII files
In-Reply-To: <optobax7vy3n3e18@amd2>
Message-ID: <
[email protected]>
References: <optobax7vy3n3e18@amd2>
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 <
[email protected]>
ReSent-To: TOPS-20 Distribution: ;
ReSent-Subject: Re: FIND issues with non-ASCII files
ReSent-Message-ID: <
[email protected]>
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: <
[email protected]>
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: <
[email protected]>
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" <
[email protected]>
To: "
[email protected]" <
[email protected]>
Cc:
[email protected]
X-US-Mail: "Department of Mathematics, 110 LCB, University of Utah, 155 S
1400 E RM 233, Salt Lake City, UT 84112-0090, USA"
X-Telephone: +1 801 581 5254
X-FAX: +1 801 585 1640, +1 801 581 4148
X-URL:
http://www.math.utah.edu/~beebe
Subject: Re: FIND issues with non-ASCII files
Message-ID: <
[email protected]>
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 <
[email protected]>
ReSent-To: TOPS-20 Distribution: ;
ReSent-Subject: Re: FIND issues with non-ASCII files
ReSent-Message-ID: <
[email protected]>
On the subject of improving the TOPS-20 string-search utility, find,
Mark Crispin <
[email protected]> 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:
[email protected] -
- 155 S 1400 E RM 233
[email protected] [email protected] -
- Salt Lake City, UT 84112-0090, USA URL:
http://www.math.utah.edu/~beebe/ -
-------------------------------------------------------------------------------
19-Mar-2007 10:47:32-PDT,3156;000000000000
Return-Path: <
[email protected]>
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: <
[email protected]>
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 <
[email protected]>; 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 <
[email protected]>; Mon, 19 Mar 2007 10:40:52 -0700
Date: Mon, 19 Mar 2007 10:40:46 -0700 (PDT)
From: Mark Crispin <
[email protected]>
Sender:
[email protected]
To: TOPS-20 Hackers and Yackers <
[email protected]>
Subject: Re: PDP-10 floating point with un-normalized operands (fwd)
Message-ID: <
[email protected]>
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 <
[email protected]>
ReSent-To: TOPS-20 Distribution: ;
ReSent-Subject: Re: PDP-10 floating point with un-normalized operands (fwd)
ReSent-Message-ID: <
[email protected]>
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 <
[email protected]>
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: <
[email protected]>
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: <
[email protected]>
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: <
[email protected]>
References: <
[email protected]>
Mime-Version: 1.0 (Apple Message framework v752.2)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <
[email protected]>
Cc: TOPS-20 Hackers and Yackers <
[email protected]>
Content-Transfer-Encoding: 7bit
From: Angela Kahealani <
[email protected]>
Subject: Encryption
Date: Mon, 19 Mar 2007 08:00:49 -1000
To: Mark Crispin <
[email protected]>
X-Mailer: Apple Mail (2.752.2)
ReSent-Date: Mon, 19 Mar 2007 11:27:47 -0700 (PDT)
ReSent-From: TOPS-20 List Moderator <
[email protected]>
ReSent-To: TOPS-20 Distribution: ;
ReSent-Subject: Encryption
ReSent-Message-ID: <
[email protected]>
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: <
[email protected]>
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: <
[email protected]>
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 <
[email protected]> for
[email protected]; 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:
[email protected]
Subject: LAT (Finally!)
In-reply-to: <
[email protected]>
To:
[email protected]
Message-id: <
[email protected]>
MIME-version: 1.0
X-Mailer: Sun Java(tm) System Messenger Express 6.2-6.01 (built Apr 3 2006)
Content-type: text/plain; charset=us-ascii
Content-language: en
Content-transfer-encoding: 7BIT
Content-disposition: inline
X-Accept-Language: en
Priority: normal
References: <
[email protected]>
ReSent-Date: Thu, 29 Mar 2007 22:17:11 -0700 (PDT)
ReSent-From: TOPS-20 List Moderator <
[email protected]>
ReSent-To: TOPS-20 Distribution: ;
ReSent-Subject: LAT (Finally!)
ReSent-Message-ID: <
[email protected]>
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:<ACJ>
!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: <
[email protected]>
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: <
[email protected]>
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 <
[email protected]>
Sender:
[email protected]
To:
[email protected]
cc:
[email protected]
Subject: Re: LAT (Finally!)
In-Reply-To: <
[email protected]>
Message-ID: <
[email protected]>
References: <
[email protected]>
<
[email protected]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=us-ascii; format=flowed
ReSent-Date: Thu, 29 Mar 2007 22:25:13 -0700 (PDT)
ReSent-From: TOPS-20 List Moderator <
[email protected]>
ReSent-To: TOPS-20 Distribution: ;
ReSent-Subject: Re: LAT (Finally!)
ReSent-Message-ID: <
[email protected]>
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: <
[email protected]>
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: <
[email protected]>
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: <p06240800c232a13a4bff@[192.168.1.52]>
In-Reply-To: <
[email protected]>
References: <
[email protected]>
<
[email protected]>
Date: Fri, 30 Mar 2007 07:18:29 -0400
To:
[email protected],
[email protected]
From: John Francini <
[email protected]>
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 <
[email protected]>
ReSent-To: TOPS-20 Distribution: ;
ReSent-Subject: Re: LAT (Finally!)
ReSent-Message-ID: <
[email protected]>
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,
[email protected]
"The journey is more important than the destination -- that's part of life.
If you only live for getting to the end, you're almost always disappointed."
-- Donald Knuth
30-Mar-2007 10:31:48-PDT,7547;000000000000
Return-Path: <
[email protected]>
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: <
[email protected]>
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 <
[email protected]> for
[email protected]; 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:
[email protected]
Subject: Re: LAT (Finally!)
In-reply-to: <p06240800c232a13a4bff@[192.168.1.52]>
To: John Francini <
[email protected]>
Cc:
[email protected]
Message-id: <
[email protected]>
MIME-version: 1.0
X-Mailer: Sun Java(tm) System Messenger Express 6.2-6.01 (built Apr 3 2006)
Content-type: text/plain; charset=us-ascii
Content-language: en
Content-transfer-encoding: 7BIT
Content-disposition: inline
X-Accept-Language: en
Priority: normal
References: <
[email protected]>
<
[email protected]> <p06240800c232a13a4bff@[192.168.1.52]>
ReSent-Date: Fri, 30 Mar 2007 10:24:06 -0700 (PDT)
ReSent-From: TOPS-20 List Moderator <
[email protected]>
ReSent-To: TOPS-20 Distribution: ;
ReSent-Subject: Re: LAT (Finally!)
ReSent-Message-ID: <
[email protected]>
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:
[email protected],
[email protected]
>
> 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,
[email protected]
>
> "The journey is more important than the destination -- that's
> part of life. If you only live for getting to the end, you're
> almost always disappointed." -- Donald Knuth
>
30-Mar-2007 10:35:22-PDT,2751;000000000000
Return-Path: <
[email protected]>
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: <
[email protected]>
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 <
[email protected]>
To:
[email protected]
Cc: TOPS-20 List Moderator <
[email protected]>,
[email protected]
Subject: Re: LAT (Finally!)
In-Reply-To: <
[email protected]>
Message-ID: <
[email protected]>
ReSent-Date: Fri, 30 Mar 2007 10:25:33 -0700 (PDT)
ReSent-From: TOPS-20 List Moderator <
[email protected]>
ReSent-To: TOPS-20 Distribution: ;
ReSent-Subject: Re: LAT (Finally!)
ReSent-Message-ID: <
[email protected]>
> 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: <
[email protected]>
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: <
[email protected]>
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 <
[email protected]>; 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:
[email protected]
Subject: Re: LAT (Finally!)
In-reply-to: <
[email protected]>
To: Mark Crispin <
[email protected]>
Cc:
[email protected]
Message-id: <
[email protected]>
MIME-version: 1.0
X-Mailer: Sun Java(tm) System Messenger Express 6.2-6.01 (built Apr 3 2006)
Content-type: text/plain; charset=us-ascii
Content-language: en
Content-transfer-encoding: 7BIT
Content-disposition: inline
X-Accept-Language: en
Priority: normal
References: <
[email protected]>
<
[email protected]>
<
[email protected]>
ReSent-Date: Fri, 30 Mar 2007 10:25:50 -0700 (PDT)
ReSent-From: TOPS-20 List Moderator <
[email protected]>
ReSent-To: TOPS-20 Distribution: ;
ReSent-Subject: Re: LAT (Finally!)
ReSent-Message-ID: <
[email protected]>
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:
[email protected]
> Cc:
[email protected]
>
> 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: <
[email protected]>
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: <
[email protected]>
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 <
[email protected]>; 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: <
[email protected]>
From: Rich Alderson <
[email protected]>
To:
[email protected]
In-reply-to: <
[email protected]> (
[email protected])
Subject: Re: LAT (Finally!)
References: <
[email protected]>
<
[email protected]> <p06240800c232a13a4bff@[192.168.1.52]> <
[email protected]>
ReSent-Date: Fri, 30 Mar 2007 20:32:03 -0700 (PDT)
ReSent-From: TOPS-20 List Moderator <
[email protected]>
ReSent-To: TOPS-20 Distribution: ;
ReSent-Subject: Re: LAT (Finally!)
ReSent-Message-ID: <
[email protected]>
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: <
[email protected]>
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: <
[email protected]>
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 <
[email protected]>
Date: Fri, 30 Mar 2007 18:18:58 PDT
From: William "Chops" Westfield <
[email protected]>
To:
[email protected]
Cc: TOPS-20 List Moderator <
[email protected]>,
Mark Crispin <
[email protected]>,
[email protected]
Subject: Re: LAT (Finally!)
In-Reply-To: Your message of Fri, 30 Mar 2007 14:47:49 +0000 (GMT)
Message-ID: <CMM.0.90.4.1175303938.billw@pita>
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;
[email protected];
z=From:=20William=20=22Chops=22=20Westfield=20<
[email protected]>
|Subject:=20Re=3A=20LAT=20(Finally!)
|Sender:=20Bill=20Westfield=20<
[email protected]>;
bh=GB0uFxvO/+VNSAzBGYMxo0Puh6wI99A/7rfdf/atZcg=;
b=WEU/eBWd06rxidi9qUkhs66vT8sN/lJt99qQsuvJu5pxXEli5gNvBmrUEdgHbm1uOy1gri+w
YmPG8y8lUQ2pojYuDv5So6PPs7NKwhXuhqGDAhBZtP94QhOP1X1rjDXuq8QTguaAVh4r7mVCjJ
UXK3hBuLNzECazK6gkD01IZ2o=;
Authentication-Results: sj-dkim-1;
[email protected]; 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 <
[email protected]>
ReSent-To: TOPS-20 Distribution: ;
ReSent-Subject: Re: LAT (Finally!)
ReSent-Message-ID: <
[email protected]>
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: <
[email protected]>
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: <
[email protected]>
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 <
[email protected]> for
[email protected]; 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:
[email protected]
Subject: Re: LAT (Finally!)
In-reply-to: <
[email protected]>
To: Frank da Cruz <
[email protected]>
Cc:
[email protected]
Message-id: <
[email protected]>
MIME-version: 1.0
X-Mailer: Sun Java(tm) System Messenger Express 6.2-6.01 (built Apr 3 2006)
Content-type: text/plain; charset=us-ascii
Content-language: en
Content-transfer-encoding: 7BIT
Content-disposition: inline
X-Accept-Language: en
Priority: normal
References: <
[email protected]>
<
[email protected]>
ReSent-Date: Fri, 30 Mar 2007 20:33:24 -0700 (PDT)
ReSent-From: TOPS-20 List Moderator <
[email protected]>
ReSent-To: TOPS-20 Distribution: ;
ReSent-Subject: Re: LAT (Finally!)
ReSent-Message-ID: <
[email protected]>
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: <
[email protected]>
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: <
[email protected]>
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 <
[email protected]>
Sender:
[email protected]
To: Rich Alderson <
[email protected]>
cc:
[email protected]
Subject: Re: LAT (Finally!)
In-Reply-To: <
[email protected]>
Message-ID: <
[email protected]>
References: <
[email protected]>
<
[email protected]> <p06240800c232a13a4bff@[192.168.1.52]>
<
[email protected]>
<
[email protected]>
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 <
[email protected]>
ReSent-To: TOPS-20 Distribution: ;
ReSent-Subject: Re: LAT (Finally!)
ReSent-Message-ID: <
[email protected]>
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: <
[email protected]>
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: <
[email protected]>
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
[email protected]; 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
[email protected]; Sat, 31 Mar 2007 01:30:51 -0400
Mime-Version: 1.0 (Apple Message framework v624)
In-Reply-To: <
[email protected]>
References: <
[email protected]> <
[email protected]> <p06240800c232a13a4bff@[192.168.1.52]> <
[email protected]>
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <
[email protected]>
Content-Transfer-Encoding: 7bit
X-Image-Url:
http://www.goldenstategiftbaskets.com/minibasket.jpg
From: Carl Baltrunas <
[email protected]>
Subject: Re: LAT (Finally!)
Date: Fri, 30 Mar 2007 22:30:48 -0700
To: TOPS-20 Hackers and Yackers <
[email protected]>
X-Mailer: Apple Mail (2.624)
ReSent-Date: Fri, 30 Mar 2007 22:46:40 -0700 (PDT)
ReSent-From: TOPS-20 List Moderator <
[email protected]>
ReSent-To: TOPS-20 Distribution: ;
ReSent-Subject: Re: LAT (Finally!)
ReSent-Message-ID: <
[email protected]>
On Mar 30, 2007, at 8:43 AM,
[email protected] 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: <
[email protected]>
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: <
[email protected]>
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 <
[email protected]>
Sender:
[email protected]
To: Carl Baltrunas <
[email protected]>
cc: TOPS-20 Hackers and Yackers <
[email protected]>
Subject: Re: LAT (Finally!)
In-Reply-To: <
[email protected]>
Message-ID: <
[email protected]>
References: <
[email protected]>
<
[email protected]> <p06240800c232a13a4bff@[192.168.1.52]>
<
[email protected]>
<
[email protected]>
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 <
[email protected]>
ReSent-To: TOPS-20 Distribution: ;
ReSent-Subject: Re: LAT (Finally!)
ReSent-Message-ID: <
[email protected]>
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: <
[email protected]>
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: <
[email protected]>
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 <
[email protected]>; 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 <
[email protected]>; Sat, 31 Mar 2007 10:43:12 -0400 (EDT)
Date: Sat, 31 Mar 2007 10:43:12 -0400
From: Rob Austein <
[email protected]>
To: TOPS-20 Hackers and Yackers <
[email protected]>
Subject: Re: LAT (Finally!)
In-Reply-To: <
[email protected]>
References: <
[email protected]>
<
[email protected]>
<p06240800c232a13a4bff@[192.168.1.52]>
<
[email protected]>
<
[email protected]>
<
[email protected]>
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: <
[email protected]>
ReSent-Date: Sat, 31 Mar 2007 11:22:58 -0700 (PDT)
ReSent-From: TOPS-20 List Moderator <
[email protected]>
ReSent-To: TOPS-20 Distribution: ;
ReSent-Subject: Re: LAT (Finally!)
ReSent-Message-ID: <
[email protected]>
At Sat, 31 Mar 2007 00:45:08 -0700 (PDT), Mark Crispin <
[email protected]> 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: <
[email protected]>
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: <
[email protected]>
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 <
[email protected]>
To:
[email protected]
Cc:
[email protected]
Subject: Re: LAT (Finally!)
In-Reply-To: <
[email protected]>
Message-ID: <
[email protected]>
ReSent-Date: Sat, 31 Mar 2007 11:23:44 -0700 (PDT)
ReSent-From: TOPS-20 List Moderator <
[email protected]>
ReSent-To: TOPS-20 Distribution: ;
ReSent-Subject: Re: LAT (Finally!)
ReSent-Message-ID: <
[email protected]>
> 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: <
[email protected]>
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: <
[email protected]>
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 <
[email protected]>; 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
[email protected]; Sat, 31 Mar 2007 12:23:43 -0400
Date: Sat, 31 Mar 2007 12:23:43 -0400
From: John Wilson <
[email protected]>
Message-Id: <
[email protected]>
To:
[email protected]
Subject: Re: LAT (Finally!)
ReSent-Date: Sat, 31 Mar 2007 11:24:05 -0700 (PDT)
ReSent-From: TOPS-20 List Moderator <
[email protected]>
ReSent-To: TOPS-20 Distribution: ;
ReSent-Subject: Re: LAT (Finally!)
ReSent-Message-ID: <
[email protected]>
From: Mark Crispin <
[email protected]>
>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: <
[email protected]>
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: <
[email protected]>
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" <
[email protected]>
To:
[email protected]
Cc:
[email protected]
X-US-Mail: "Department of Mathematics, 110 LCB, University of Utah, 155 S
1400 E RM 233, Salt Lake City, UT 84112-0090, USA"
X-Telephone: +1 801 581 5254
X-FAX: +1 801 585 1640, +1 801 581 4148
X-URL:
http://www.math.utah.edu/~beebe
Subject: [tops20] inbound FTP performance issue
Message-ID: <
[email protected]>
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0 (mail.math.utah.edu [155.101.98.135]); Sat, 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 <
[email protected]>
ReSent-To: TOPS-20 Distribution: ;
ReSent-Subject: [tops20] inbound FTP performance issue
ReSent-Message-ID: <
[email protected]>
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>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:
[email protected] -
- 155 S 1400 E RM 233
[email protected] [email protected] -
- Salt Lake City, UT 84112-0090, USA URL:
http://www.math.utah.edu/~beebe/ -
-------------------------------------------------------------------------------
31-Mar-2007 11:51:26-PDT,1819;000000000000
Return-Path: <
[email protected]>
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: <
[email protected]>
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 <
[email protected]>
Sender:
[email protected]
To: Rob Austein <
[email protected]>
cc: TOPS-20 Hackers and Yackers <
[email protected]>
Subject: Re: LAT (Finally!)
In-Reply-To: <
[email protected]>
Message-ID: <
[email protected]>
References: <
[email protected]>
<
[email protected]> <p06240800c232a13a4bff@[192.168.1.52]>
<
[email protected]> <
[email protected]>
<
[email protected]>
<
[email protected]>
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 <
[email protected]>
ReSent-To: TOPS-20 Distribution: ;
ReSent-Subject: Re: LAT (Finally!)
ReSent-Message-ID: <
[email protected]>
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: <
[email protected]>
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: <
[email protected]>
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 <
[email protected]>; 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: <
[email protected]>
From: Rich Alderson <
[email protected]>
To:
[email protected]
In-reply-to: <
[email protected]> (message
from Mark Crispin on Fri, 30 Mar 2007 21:05:07 -0700 (PDT))
Subject: Re: LAT (Finally!)
References: <
[email protected]>
<
[email protected]> <p06240800c232a13a4bff@[192.168.1.52]>
<
[email protected]>
<
[email protected]> <
[email protected]>
ReSent-Date: Sun, 1 Apr 2007 12:43:06 -0700 (PDT)
ReSent-From: TOPS-20 List Moderator <
[email protected]>
ReSent-To: TOPS-20 Distribution: ;
ReSent-Subject: Re: LAT (Finally!)
ReSent-Message-ID: <
[email protected]>
> Date: Fri, 30 Mar 2007 21:05:07 -0700 (PDT)
> From: Mark Crispin <
[email protected]>
> 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: <
[email protected]>
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: <
[email protected]>
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 <
[email protected]>
Sender:
[email protected]
To: Rich Alderson <
[email protected]>
cc:
[email protected]
Subject: Re: LAT (Finally!)
In-Reply-To: <
[email protected]>
Message-ID: <
[email protected]>
References: <
[email protected]>
<
[email protected]> <p06240800c232a13a4bff@[192.168.1.52]>
<
[email protected]> <
[email protected]>
<
[email protected]>
<
[email protected]>
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 <
[email protected]>
ReSent-To: TOPS-20 Distribution: ;
ReSent-Subject: Re: LAT (Finally!)
ReSent-Message-ID: <
[email protected]>
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: <
[email protected]>
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: <
[email protected]>
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 <
[email protected]>; 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 <
[email protected]>; Sun, 1 Apr 2007 17:21:44 -0400 (EDT)
Date: Sun, 01 Apr 2007 17:21:44 -0400
From: Rob Austein <
[email protected]>
To:
[email protected]
Subject: Re: LAT (Finally!)
In-Reply-To: <
[email protected]>
References: <
[email protected]>
<
[email protected]>
<p06240800c232a13a4bff@[192.168.1.52]>
<
[email protected]>
<
[email protected]>
<
[email protected]>
<
[email protected]>
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: <
[email protected]>
ReSent-Date: Sun, 1 Apr 2007 16:45:23 -0700 (PDT)
ReSent-From: TOPS-20 List Moderator <
[email protected]>
ReSent-To: TOPS-20 Distribution: ;
ReSent-Subject: Re: LAT (Finally!)
ReSent-Message-ID: <
[email protected]>
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: <
[email protected]>
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: <
[email protected]>
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: <
[email protected]>
References: <
[email protected]>
Mime-Version: 1.0 (Apple Message framework v624)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <
[email protected]>
Content-Transfer-Encoding: 7bit
Cc:
[email protected]
X-Image-Url:
http://www.goldenstategiftbaskets.com/minibasket.jpg
From: Carl Baltrunas <
[email protected]>
Subject: Re: [tops20] inbound FTP performance issue
Date: Sun, 1 Apr 2007 16:16:58 -0700
To: "Nelson H. F. Beebe" <
[email protected]>
X-Mailer: Apple Mail (2.624)
ReSent-Date: Sun, 1 Apr 2007 16:45:36 -0700 (PDT)
ReSent-From: TOPS-20 List Moderator <
[email protected]>
ReSent-To: TOPS-20 Distribution: ;
ReSent-Subject: Re: [tops20] inbound FTP performance issue
ReSent-Message-ID: <
[email protected]>
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: <
[email protected]>
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: <
[email protected]>
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 <
[email protected]> for
[email protected]; 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:
[email protected]
Subject: Re: [tops20] inbound FTP performance issue
In-reply-to: <
[email protected]>
To: "Nelson H. F. Beebe" <
[email protected]>
Cc:
[email protected],
[email protected]
Message-id: <
[email protected]>
MIME-version: 1.0
X-Mailer: Sun Java(tm) System Messenger Express 6.2-6.01 (built Apr 3 2006)
Content-type: text/plain; charset=us-ascii
Content-language: en
Content-transfer-encoding: 7BIT
Content-disposition: inline
X-Accept-Language: en
Priority: normal
References: <
[email protected]>
ReSent-Date: Sun, 1 Apr 2007 21:35:36 -0700 (PDT)
ReSent-From: TOPS-20 List Moderator <
[email protected]>
ReSent-To: TOPS-20 Distribution: ;
ReSent-Subject: Re: [tops20] inbound FTP performance issue
ReSent-Message-ID: <
[email protected]>
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:
[email protected]
Cc:
[email protected]
> 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: <
[email protected]>
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: <
[email protected]>
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 <
[email protected]> for
[email protected]; Sat, 05 May 2007 22:37:24 -0400 (EDT)
Date: Sat, 05 May 2007 22:37:22 -0400
From: Thomas DeBellis <
[email protected]>
Subject: .DVNFT
In-reply-to: <
[email protected]>
To:
[email protected]
Message-id: <
[email protected]>
MIME-version: 1.0
Content-type: text/plain; charset=us-ascii; format=flowed
Content-transfer-encoding: 7BIT
X-Accept-Language: en-us, en
References: <
[email protected]>
<
[email protected]> <p06240800c232a13a4bff@[192.168.1.52]>
<
[email protected]>
<
[email protected]>
<
[email protected]>
<
[email protected]>
<
[email protected]>
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 <
[email protected]>
ReSent-To: TOPS-20 Distribution: ;
ReSent-Subject: .DVNFT
ReSent-Message-ID: <
[email protected]>
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: <
[email protected]>
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: <
[email protected]>
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 <
[email protected]>
Sender:
[email protected]
To: Thomas DeBellis <
[email protected]>
cc:
[email protected]
Subject: Re: .DVNFT
In-Reply-To: <
[email protected]>
Message-ID: <
[email protected]>
References: <
[email protected]>
<
[email protected]> <p06240800c232a13a4bff@[192.168.1.52]>
<
[email protected]> <
[email protected]>
<
[email protected]>
<
[email protected]> <
[email protected]>
<
[email protected]>
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 <
[email protected]>
ReSent-To: TOPS-20 Distribution: ;
ReSent-Subject: Re: .DVNFT
ReSent-Message-ID: <
[email protected]>
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: <
[email protected]>
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: <
[email protected]>
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 <
[email protected]>
Sender:
[email protected]
To: TOPS-20 Hackers and Yackers <
[email protected]>
Subject: 24 years ago today...
Message-ID: <
[email protected]>
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 <
[email protected]>
ReSent-To: TOPS-20 Distribution: ;
ReSent-Subject: 24 years ago today...
ReSent-Message-ID: <
[email protected]>
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: <
[email protected]>
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: <
[email protected]>
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 <
[email protected]> for
[email protected]; Sat, 26 May 2007 17:16:19 -0400 (EDT)
Date: Sat, 26 May 2007 17:16:18 -0400
From: Thomas DeBellis <
[email protected]>
Subject: SC%MMN, SC%MPP, SC%SDV
To:
[email protected]
Message-id: <
[email protected]>
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 <
[email protected]>
ReSent-To: TOPS-20 Distribution: ;
ReSent-Subject: SC%MMN, SC%MPP, SC%SDV
ReSent-Message-ID: <
[email protected]>
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: <
[email protected]>
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: <
[email protected]>
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 <
[email protected]>
Sender:
[email protected]
To: Thomas DeBellis <
[email protected]>
cc:
[email protected]
Subject: Re: SC%MMN, SC%MPP, SC%SDV
In-Reply-To: <
[email protected]>
Message-ID: <
[email protected]>
References: <
[email protected]>
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 <
[email protected]>
ReSent-To: TOPS-20 Distribution: ;
ReSent-Subject: Re: SC%MMN, SC%MPP, SC%SDV
ReSent-Message-ID: <
[email protected]>
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: <
[email protected]>
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: <
[email protected]>
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 <
[email protected]>; 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 <
[email protected]>; 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
[email protected]; Mon, 11 Jun 2007 23:58:31 -0700 (PDT)
Sender: Bill Westfield <
[email protected]>
Date: Mon, 11 Jun 2007 23:58:31 PDT
From: William "Chops" Westfield <
[email protected]>
To:
[email protected]
Subject: Unix MM...
Message-ID: <CMM.0.90.4.1181631511.billw@pita>
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;
[email protected];
z=From:=20William=20=22Chops=22=20Westfield=20<
[email protected]>
|Subject:=20Unix=20MM...
|Sender:=20Bill=20Westfield=20<
[email protected]>;
bh=OO3tOSUGzhWImWD5CmdbIJm3BmBtJLP9K8IUftPdEKk=;
b=gZILGvOh7QLYTXu/mVTinK9Tisl3/NiycP7rUdFwtZL89wO0O7SEtx/cqZBkv3iBeKGs3Y+3
A/DSfDLhkUF36qEiAWbMg5Er4v3xfisy/E5Z54l8TLKvQy1j0Jc/Ev3v;
Authentication-Results: sj-dkim-2;
[email protected]; 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 <
[email protected]>
ReSent-To: TOPS-20 Distribution: ;
ReSent-Subject: Unix MM...
ReSent-Message-ID: <
[email protected]>
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: <
[email protected]>
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: <
[email protected]>
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 <
[email protected]>
To: William "Chops" Westfield <
[email protected]>
Cc: TOPS-20 List Moderator <
[email protected]>,
[email protected]
Subject: Re: Unix MM...
In-Reply-To: <CMM.0.90.4.1181631511.billw@pita>
Message-ID: <
[email protected]>
ReSent-Date: Tue, 12 Jun 2007 17:33:16 -0700 (PDT)
ReSent-From: TOPS-20 List Moderator <
[email protected]>
ReSent-To: TOPS-20 Distribution: ;
ReSent-Subject: Re: Unix MM...
ReSent-Message-ID: <
[email protected]>
> 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: <
[email protected]>
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: <
[email protected]>
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: <
[email protected]>
From: Rich Alderson <
[email protected]>
To:
[email protected]
CC:
[email protected]
In-reply-to: <CMM.0.90.4.1181631511.billw@pita>
Subject: Re: Unix MM...
References: <CMM.0.90.4.1181631511.billw@pita>
ReSent-Date: Tue, 12 Jun 2007 17:33:27 -0700 (PDT)
ReSent-From: TOPS-20 List Moderator <
[email protected]>
ReSent-To: TOPS-20 Distribution: ;
ReSent-Subject: Re: Unix MM...
ReSent-Message-ID: <
[email protected]>
> Date: Mon, 11 Jun 2007 23:58:31 PDT
> From: William "Chops" Westfield <
[email protected]>
> 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: <
[email protected]>
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: <
[email protected]>
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" <
[email protected]>
To: William "Chops" Westfield <
[email protected]>
Cc:
[email protected], TOPS-20 List Moderator <
[email protected]>,
[email protected]
X-US-Mail: "Department of Mathematics, 110 LCB, University of Utah, 155 S
1400 E RM 233, Salt Lake City, UT 84112-0090, USA"
X-Telephone: +1 801 581 5254
X-FAX: +1 801 585 1640, +1 801 581 4148
X-URL:
http://www.math.utah.edu/~beebe
Subject: Re: Unix MM...
In-Reply-To: <CMM.0.90.4.1181631511.billw@pita>
Message-ID: <
[email protected]>
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0 (mail.math.utah.edu [155.101.98.135]); Tue, 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 <
[email protected]>
ReSent-To: TOPS-20 Distribution: ;
ReSent-Subject: Re: Unix MM...
ReSent-Message-ID: <
[email protected]>
William "Chops" Westfield <
[email protected]> 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:
[email protected] -
- 155 S 1400 E RM 233
[email protected] [email protected] -
- Salt Lake City, UT 84112-0090, USA URL:
http://www.math.utah.edu/~beebe/ -
-------------------------------------------------------------------------------
12-Jun-2007 17:56:34-PDT,3888;000000000000
Return-Path: <
[email protected]>
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: <
[email protected]>
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" <
[email protected]>
To:
[email protected]
Cc:
[email protected]
X-US-Mail: "Department of Mathematics, 110 LCB, University of Utah, 155 S
1400 E RM 233, Salt Lake City, UT 84112-0090, USA"
X-Telephone: +1 801 581 5254
X-FAX: +1 801 585 1640, +1 801 581 4148
X-URL:
http://www.math.utah.edu/~beebe
Subject: [tops-20] Bliss require-file problem
Message-ID: <
[email protected]>
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0 (mail.math.utah.edu [155.101.98.135]); Tue, 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 <
[email protected]>
ReSent-To: TOPS-20 Distribution: ;
ReSent-Subject: [tops-20] Bliss require-file problem
ReSent-Message-ID: <
[email protected]>
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:
[email protected] -
- 155 S 1400 E RM 233
[email protected] [email protected] -
- Salt Lake City, UT 84112-0090, USA URL:
http://www.math.utah.edu/~beebe/ -
-------------------------------------------------------------------------------
12-Jun-2007 18:02:18-PDT,3888;000000000000
Return-Path: <
[email protected]>
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: <
[email protected]>
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" <
[email protected]>
To:
[email protected]
Cc:
[email protected]
X-US-Mail: "Department of Mathematics, 110 LCB, University of Utah, 155 S
1400 E RM 233, Salt Lake City, UT 84112-0090, USA"
X-Telephone: +1 801 581 5254
X-FAX: +1 801 585 1640, +1 801 581 4148
X-URL:
http://www.math.utah.edu/~beebe
Subject: [tops-20] Bliss require-file problem
Message-ID: <
[email protected]>
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0 (mail.math.utah.edu [155.101.98.135]); Tue, 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 <
[email protected]>
ReSent-To: TOPS-20 Distribution: ;
ReSent-Subject: [tops-20] Bliss require-file problem
ReSent-Message-ID: <
[email protected]>
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:
[email protected] -
- 155 S 1400 E RM 233
[email protected] [email protected] -
- Salt Lake City, UT 84112-0090, USA URL:
http://www.math.utah.edu/~beebe/ -
-------------------------------------------------------------------------------
13-Jun-2007 20:20:33-PDT,3905;000000000000
Return-Path: <
[email protected]>
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: <
[email protected]>
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: <
[email protected]>
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 <
[email protected]>
To: "Nelson H. F. Beebe" <
[email protected]>
Cc: TOPS-20 List Moderator <
[email protected]>
Subject: Re: Unix MM...
In-Reply-To: <
[email protected]>
Message-ID: <
[email protected]>
X-ReSent-Date: Wed, 13 Jun 2007 20:13:12 -0700 (PDT)
X-ReSent-From: Mark Crispin <
[email protected]>
X-ReSent-To: TOPS-20 Hackers and Yackers <
[email protected]>
X-ReSent-Subject: Re: Unix MM...
X-ReSent-Message-ID: <
[email protected]>
ReSent-Date: Wed, 13 Jun 2007 20:13:55 -0700 (PDT)
ReSent-From: TOPS-20 List Moderator <
[email protected]>
ReSent-To: TOPS-20 Distribution: ;
ReSent-Subject: Re: Unix MM...
ReSent-Message-ID: <
[email protected]>
> William "Chops" Westfield <
[email protected]> 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: <
[email protected]>
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: <
[email protected]>
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: <
[email protected]>
Date: Sat, 16 Jun 2007 15:17:17 -0400
From: "Alan H. Martin" <
[email protected]>
User-Agent: Thunderbird 2.0.0.4 (Windows/20070604)
MIME-Version: 1.0
To: "Nelson H. F. Beebe" <
[email protected]>
CC:
[email protected]
Subject: Re: [tops-20] Bliss require-file problem
References: <
[email protected]>
In-Reply-To: <
[email protected]>
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 <
[email protected]>
ReSent-To: TOPS-20 Distribution: ;
ReSent-Subject: Re: [tops-20] Bliss require-file problem
ReSent-Message-ID: <
[email protected]>
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
[email protected]
16-Jun-2007 12:57:19-PDT,1541;000000000000
Return-Path: <
[email protected]>
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: <
[email protected]>
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 <
[email protected]>
Sender:
[email protected]
To: "Alan H. Martin" <
[email protected]>
cc: "Nelson H. F. Beebe" <
[email protected]>,
[email protected]
Subject: Re: [tops-20] Bliss require-file problem
In-Reply-To: <
[email protected]>
Message-ID: <
[email protected]>
References: <
[email protected]>
<
[email protected]>
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 <
[email protected]>
ReSent-To: TOPS-20 Distribution: ;
ReSent-Subject: Re: [tops-20] Bliss require-file problem
ReSent-Message-ID: <
[email protected]>
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: <
[email protected]>
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: <
[email protected]>
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 <
[email protected]>; Tue, 19 Jun 2007 17:32:01 -0400 (EDT)
(envelope-from
[email protected])
X-Received: (from phil@localhost)
by ultimate.com (8.13.8/8.13.8/Submit) id l5JLW1lU030906
for
[email protected]; 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 <
[email protected]>
Message-Id: <
[email protected]>
To:
[email protected]
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 <
[email protected]>
ReSent-To: TOPS-20 Distribution: ;
ReSent-Subject: Fwd: Anyone got a working DEC10 (or a running emulator?)
ReSent-Message-ID: <
[email protected]>
> Date: Tue, 19 Jun 2007 15:49:44 -0500
> From: "Graham Toal" <
[email protected]>
> To:
[email protected]
> Subject: Anyone got a working DEC10 (or a running emulator?)
> Reply-To: "General Discussion: On-Topic and Off-Topic Posts"
> <
[email protected]>
> List-Id: "General Discussion: On-Topic and Off-Topic Posts"
> <cctalk.classiccmp.org>
> List-Unsubscribe: <
http://www.classiccmp.org/mailman/listinfo/cctalk>,
> <mailto:
[email protected]?subject=unsubscribe>
> List-Archive: <
http://www.classiccmp.org/pipermail/cctalk>
> List-Post: <mailto:
[email protected]>
> List-Help: <mailto:
[email protected]?subject=help>
> List-Subscribe: <
http://www.classiccmp.org/mailman/listinfo/cctalk>,
> <mailto:
[email protected]?subject=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: <
[email protected]>
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: <
[email protected]>
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 <
[email protected]>; 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" <
[email protected]>
To: <
[email protected]>
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 <
[email protected]>
ReSent-To: TOPS-20 Distribution: ;
ReSent-Subject: Conferencing software?
ReSent-Message-ID: <
[email protected]>
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
<html xmlns:v=3D"urn:schemas-microsoft-com:vml" =
xmlns:o=3D"urn:schemas-microsoft-com:office:office" =
xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:m=3D"
http://schemas.microsoft.com/office/2004/12/omml" =
xmlns=3D"
http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<meta name=3DGenerator content=3D"Microsoft Word 12 (filtered medium)">
<style>
<!--
/* Font Definitions */
@font-face
{font-family:Wingdings;
panose-1:5 0 0 0 0 0 0 0 0 0;}
@font-face
{font-family:Wingdings;
panose-1:5 0 0 0 0 0 0 0 0 0;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri","sans-serif";}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
span.EmailStyle17
{mso-style-type:personal-compose;
font-family:"Calibri","sans-serif";
color:windowtext;}
MsoChpDefault
{mso-style-type:export-only;}
@page Section1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.Section1
{page:Section1;}
-->
</style>
<!--[if gte mso 9]><xml>
<o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext=3D"edit">
<o:idmap v:ext=3D"edit" data=3D"1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang=3DEN-US link=3Dblue vlink=3Dpurple>
<div class=3DSection1>
<p class=3DMsoNormal>Does anyone know of any conferencing software on =
TOPS-20? Or
if not, anyone have any opinions they want to share and discuss? =
<o:p></o:p></p>
<p class=3DMsoNormal><o:p> </o:p></p>
<p class=3DMsoNormal>I’m thinking of a hobby project something =
along these
lines: <o:p></o:p></p>
<p class=3DMsoNormal><o:p> </o:p></p>
<p class=3DMsoNormal>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<o:p></o:p></p>
<p class=3DMsoNormal>Front-end GUI=A0 <span =
style=3D'font-family:Wingdings'>=DF</span>=A0
TCPIP <span style=3D'font-family:Wingdings'>=E0</span>=A0 =A0=A0Unpriv =
account=A0=A0 <span
style=3D'font-family:Wingdings'>=DF</span> <span =
style=3D'font-family:Wingdings'>=E0</span>
=A0=A0and users and so forth<o:p></o:p></p>
<p class=3DMsoNormal>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<o:p></o:p></p>
<p class=3DMsoNormal><o:p> </o:p></p>
<p class=3DMsoNormal>Since both ends of the connection would be =
absolutely
controlled, it could have the best of both worlds,<o:p></o:p></p>
<p class=3DMsoNormal>And be tailored to do just about what anyone wants =
it to do.
<o:p></o:p></p>
<p class=3DMsoNormal><o:p> </o:p></p>
<p class=3DMsoNormal>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. =
<o:p></o:p></p>
<p class=3DMsoNormal>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. <o:p></o:p></p>
<p class=3DMsoNormal><o:p> </o:p></p>
<p class=3DMsoNormal>Any ideas, suggestions, or pointers are welcome. =
<o:p></o:p></p>
<p class=3DMsoNormal><o:p> </o:p></p>
<p class=3DMsoNormal>Yours,<o:p></o:p></p>
<p class=3DMsoNormal>-Paul<o:p></o:p></p>
<p class=3DMsoNormal><o:p> </o:p></p>
<p class=3DMsoNormal><o:p> </o:p></p>
</div>
</body>
</html>
------=_NextPart_000_0004_01C7B657.9E9C6C90--
24-Jun-2007 11:32:20-PDT,4192;000000000000
Return-Path: <
[email protected]>
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: <
[email protected]>
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 <
[email protected]>; 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" <
[email protected]>
To: <
[email protected]>
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 <
[email protected]>
ReSent-To: TOPS-20 Distribution: ;
ReSent-Subject: Tapes?
ReSent-Message-ID: <
[email protected]>
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
<html xmlns:v=3D"urn:schemas-microsoft-com:vml" =
xmlns:o=3D"urn:schemas-microsoft-com:office:office" =
xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:m=3D"
http://schemas.microsoft.com/office/2004/12/omml" =
xmlns=3D"
http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<meta name=3DGenerator content=3D"Microsoft Word 12 (filtered medium)">
<style>
<!--
/* Font Definitions */
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri","sans-serif";}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
span.EmailStyle17
{mso-style-type:personal;
font-family:"Calibri","sans-serif";
color:windowtext;}
span.EmailStyle18
{mso-style-type:personal-reply;
font-family:"Calibri","sans-serif";
color:#1F497D;}
MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}
@page Section1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.Section1
{page:Section1;}
-->
</style>
<!--[if gte mso 9]><xml>
<o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext=3D"edit">
<o:idmap v:ext=3D"edit" data=3D"1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang=3DEN-US link=3Dblue vlink=3Dpurple>
<div class=3DSection1>
<p class=3DMsoNormal><span style=3D'color:#1F497D'>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? <o:p></o:p></span></p>
<p class=3DMsoNormal><span =
style=3D'color:#1F497D'><o:p> </o:p></span></p>
<p class=3DMsoNormal><span =
style=3D'color:#1F497D'>-Paul<o:p></o:p></span></p>
<p class=3DMsoNormal><span =
style=3D'color:#1F497D'><o:p> </o:p></span></p>
</div>
</body>
</html>
------=_NextPart_000_0001_01C7B661.ECA5A4B0--
24-Jun-2007 12:29:01-PDT,1722;000000000000
Return-Path: <
[email protected]>
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: <
[email protected]>
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 <
[email protected]>
Sender:
[email protected]
To: Paul Raulerson <
[email protected]>
cc:
[email protected]
Subject: Re: Tapes?
In-Reply-To: <000001c7b68b$d57bacb0$80730610$@com>
Message-ID: <
[email protected]>
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 <
[email protected]>
ReSent-To: TOPS-20 Distribution: ;
ReSent-Subject: Re: Tapes?
ReSent-Message-ID: <
[email protected]>
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: <
[email protected]>
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: <
[email protected]>
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" <
[email protected]>
To:
[email protected]
Cc:
[email protected]
X-US-Mail: "Department of Mathematics, 110 LCB, University of Utah, 155 S
1400 E RM 233, Salt Lake City, UT 84112-0090, USA"
X-Telephone: +1 801 581 5254
X-FAX: +1 801 585 1640, +1 801 581 4148
X-URL:
http://www.math.utah.edu/~beebe
Subject: Re: [tops-20] Bliss require-file problem
Message-ID: <
[email protected]>
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 <
[email protected]>
ReSent-To: TOPS-20 Distribution: ;
ReSent-Subject: Re: [tops-20] Bliss require-file problem
ReSent-Message-ID: <
[email protected]>
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:<BEEBE>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:
[email protected] -
- 155 S 1400 E RM 233
[email protected] [email protected] -
- Salt Lake City, UT 84112-0090, USA URL:
http://www.math.utah.edu/~beebe/ -
-------------------------------------------------------------------------------
27-Jun-2007 12:08:10-PDT,3496;000000000000
Return-Path: <
[email protected]>
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: <
[email protected]>
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" <
[email protected]>
To:
[email protected]
Cc:
[email protected]
X-US-Mail: "Department of Mathematics, 110 LCB, University of Utah, 155 S
1400 E RM 233, Salt Lake City, UT 84112-0090, USA"
X-Telephone: +1 801 581 5254
X-FAX: +1 801 585 1640, +1 801 581 4148
X-URL:
http://www.math.utah.edu/~beebe
Subject: [tops-20] Bliss and floating-point arithmetic
Message-ID: <
[email protected]>
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 <
[email protected]>
ReSent-To: TOPS-20 Distribution: ;
ReSent-Subject: [tops-20] Bliss and floating-point arithmetic
ReSent-Message-ID: <
[email protected]>
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:
[email protected] -
- 155 S 1400 E RM 233
[email protected] [email protected] -
- Salt Lake City, UT 84112-0090, USA URL:
http://www.math.utah.edu/~beebe/ -
-------------------------------------------------------------------------------
19-Jul-2007 17:00:26-PDT,2065;000000000000
Return-Path: <
[email protected]>
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: <
[email protected]>
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 <
[email protected]> for
[email protected]; Wed, 18 Jul 2007 21:50:38 -0400 (EDT)
Date: Wed, 18 Jul 2007 21:50:37 -0400
From: Thomas DeBellis <
[email protected]>
Subject: Extended Address Limit
To:
[email protected]
Message-id: <
[email protected]>
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 <
[email protected]>
ReSent-To: TOPS-20 Distribution: ;
ReSent-Subject: Extended Address Limit
ReSent-Message-ID: <
[email protected]>
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: <
[email protected]>
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: <
[email protected]>
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 <
[email protected]> for
[email protected]; Tue, 07 Aug 2007 00:09:43 -0400 (EDT)
Date: Tue, 07 Aug 2007 00:09:38 -0700
From: Mike Ross <
[email protected]>
Subject: RSX-20F
To:
[email protected]
Message-id: <
[email protected]>
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 <
[email protected]>
ReSent-To: TOPS-20 Distribution: ;
ReSent-Subject: RSX-20F
ReSent-Message-ID: <
[email protected]>
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: <
[email protected]>
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: <
[email protected]>
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 <
[email protected]>
Sender:
[email protected]
To: Mike Ross <
[email protected]>
cc:
[email protected]
Subject: Re: RSX-20F
In-Reply-To: <
[email protected]>
Message-ID: <
[email protected]>
References: <
[email protected]>
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 <
[email protected]>
ReSent-To: TOPS-20 Distribution: ;
ReSent-Subject: Re: RSX-20F
ReSent-Message-ID: <
[email protected]>
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: <
[email protected]>
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: <
[email protected]>
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 <
[email protected]>
Sender:
[email protected]
To: Mike Ross <
[email protected]>
cc:
[email protected]
Subject: Re: RSX-20F
In-Reply-To: <
[email protected]>
Message-ID: <
[email protected]>
References: <
[email protected]> <
[email protected]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=us-ascii; format=flowed
ReSent-Date: Mon, 6 Aug 2007 23:18:12 -0700 (PDT)
ReSent-From: TOPS-20 List Moderator <
[email protected]>
ReSent-To: TOPS-20 Distribution: ;
ReSent-Subject: Re: RSX-20F
ReSent-Message-ID: <
[email protected]>
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: <
[email protected]>
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: <
[email protected]>
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 <
[email protected]>; Tue,
07 Aug 2007 06:50:49 -0400 (EDT)
Date: Tue, 07 Aug 2007 06:50:44 -0700
From: Mike Ross <
[email protected]>
Subject: Re: RSX-20F
In-reply-to: <
[email protected]>
To: Mark Crispin <
[email protected]>
Cc:
[email protected]
Message-id: <
[email protected]>
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: <
[email protected]>
<
[email protected]>
<
[email protected]>
ReSent-Date: Tue, 7 Aug 2007 11:31:15 -0700 (PDT)
ReSent-From: TOPS-20 List Moderator <
[email protected]>
ReSent-To: TOPS-20 Distribution: ;
ReSent-Subject: Re: RSX-20F
ReSent-Message-ID: <
[email protected]>
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: <
[email protected]>
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: <
[email protected]>
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 <
[email protected]>; 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
[email protected]; Tue, 7 Aug 2007 15:29:11 -0400
Date: Tue, 7 Aug 2007 15:29:11 -0400
From: John Wilson <
[email protected]>
Message-Id: <
[email protected]>
To:
[email protected]
Subject: Re: RSX-20F
ReSent-Date: Tue, 7 Aug 2007 18:36:44 -0700 (PDT)
ReSent-From: TOPS-20 List Moderator <
[email protected]>
ReSent-To: TOPS-20 Distribution: ;
ReSent-Subject: Re: RSX-20F
ReSent-Message-ID: <
[email protected]>
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: <
[email protected]>
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: <
[email protected]>
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 <
[email protected]>
Sender:
[email protected]
To: TOPS-20 Hackers and Yackers <
[email protected]>
Subject: spammers hammering TOPS-20 servers?
Message-ID: <
[email protected]>
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 <
[email protected]>
ReSent-To: TOPS-20 Distribution: ;
ReSent-Subject: spammers hammering TOPS-20 servers?
ReSent-Message-ID: <
[email protected]>
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: <
[email protected]>
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: <
[email protected]>
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 <
[email protected]>; Mon,
03 Sep 2007 12:06:40 -0400 (EDT)
Date: Mon, 03 Sep 2007 12:06:37 -0400
From: Thomas DeBellis <
[email protected]>
Subject: Re: spammers hammering TOPS-20 servers?
In-reply-to: <
[email protected]>
To: Mark Crispin <
[email protected]>
Cc: TOPS-20 Hackers and Yackers <
[email protected]>
Message-id: <
[email protected]>
MIME-version: 1.0
Content-type: text/plain; charset=us-ascii; format=flowed
Content-transfer-encoding: 7BIT
X-Accept-Language: en-us, en
References: <
[email protected]>
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 <
[email protected]>
ReSent-To: TOPS-20 Distribution: ;
ReSent-Subject: Re: spammers hammering TOPS-20 servers?
ReSent-Message-ID: <
[email protected]>
> 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:<SPOOL> (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: <
[email protected]>
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: <
[email protected]>
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 <
[email protected]>
Sender:
[email protected]
To: Thomas DeBellis <
[email protected]>
cc: TOPS-20 Hackers and Yackers <
[email protected]>
Subject: Re: spammers hammering TOPS-20 servers?
In-Reply-To: <
[email protected]>
Message-ID: <
[email protected]>
References: <
[email protected]> <
[email protected]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
ReSent-Date: Mon, 3 Sep 2007 12:16:24 -0700 (PDT)
ReSent-From: TOPS-20 List Moderator <
[email protected]>
ReSent-To: TOPS-20 Distribution: ;
ReSent-Subject: Re: spammers hammering TOPS-20 servers?
ReSent-Message-ID: <
[email protected]>
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: <
[email protected]>
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: <
[email protected]>
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 <
[email protected]> for
[email protected]; Wed, 14 Nov 2007 23:04:08 -0500 (EST)
Date: Wed, 14 Nov 2007 23:04:07 -0500
From: Thomas DeBellis <
[email protected]>
Subject: Holey File Batman!
To: TOPS-20 Wizards <
[email protected]>
Message-id: <
[email protected]>
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 <
[email protected]>
ReSent-To: TOPS-20 Distribution: ;
ReSent-Subject: Holey File Batman!
ReSent-Message-ID: <
[email protected]>
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: <
[email protected]>
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: <
[email protected]>
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 <
[email protected]>; Wed, 14 Nov 2007 23:05:04 -0500
Message-ID: <
[email protected]>
Date: Wed, 14 Nov 2007 23:05:03 -0500
From: Thomas DeBellis <
[email protected]>
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 <
[email protected]>
Subject: Re: <SPOOL>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 <
[email protected]>
ReSent-To: TOPS-20 Distribution: ;
ReSent-Subject: Re: <SPOOL>PRIMARY-MASTER-QUEUE-FILE.QUASAR
ReSent-Message-ID: <
[email protected]>
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: <SY.SLOGIN%
[email protected]>
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 <Sy.SLogin%
[email protected]>
Subject: Re: <SPOOL>PRIMARY-MASTER-QUEUE-FILE.QUASAR
To:
[email protected]
Cc:
[email protected],
[email protected]
In-Reply-To: Message from "
[email protected]" 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:<GALAXY-SOURCES>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:<GALAXY-SOURCES>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: <
[email protected]>
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: <
[email protected]>
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 <
[email protected]>
Sender:
[email protected]
To: Thomas DeBellis <
[email protected]>
cc: TOPS-20 Wizards <
[email protected]>
Subject: Re: Holey File Batman!
In-Reply-To: <
[email protected]>
Message-ID: <
[email protected]>
References: <
[email protected]>
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 <
[email protected]>
ReSent-To: TOPS-20 Distribution: ;
ReSent-Subject: Re: Holey File Batman!
ReSent-Message-ID: <
[email protected]>
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: <
[email protected]>
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: <
[email protected]>
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 <
[email protected]>
Sender:
[email protected]
To: TOPS-20 Hackers and Yackers <
[email protected]>
Subject: klh10 compilation error
Message-ID: <
[email protected]>
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 <
[email protected]>
ReSent-To: TOPS-20 Distribution: ;
ReSent-Subject: klh10 compilation error
ReSent-Message-ID: <
[email protected]>
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: <
[email protected]>
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: <
[email protected]>
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 <
[email protected]>
Sender:
[email protected]
To: TOPS-20 Hackers and Yackers <
[email protected]>
Subject: TOPS-20 in a shirt pocket!
Message-ID: <
[email protected]>
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 <
[email protected]>
ReSent-To: TOPS-20 Distribution: ;
ReSent-Subject: TOPS-20 in a shirt pocket!
ReSent-Message-ID: <
[email protected]>
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: <
[email protected]>
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: <
[email protected]>
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: <
[email protected]>
References: <
[email protected]>
Mime-Version: 1.0 (Apple Message framework v752.2)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <
[email protected]>
Cc: TOPS-20 Hackers and Yackers <
[email protected]>
Content-Transfer-Encoding: 7bit
From: John Francini <
[email protected]>
Subject: Re: klh10 compilation error
Date: Mon, 26 Nov 2007 01:46:46 -0500
To: Mark Crispin <
[email protected]>
X-Mailer: Apple Mail (2.752.2)
ReSent-Date: Sun, 25 Nov 2007 23:46:54 -0800 (PST)
ReSent-From: TOPS-20 List Moderator <
[email protected]>
ReSent-To: TOPS-20 Distribution: ;
ReSent-Subject: Re: klh10 compilation error
ReSent-Message-ID: <
[email protected]>
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: <
[email protected]>
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: <
[email protected]>
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 <
[email protected]>
Sender:
[email protected]
To: John Francini <
[email protected]>
cc: TOPS-20 Hackers and Yackers <
[email protected]>
Subject: Re: klh10 compilation error
In-Reply-To: <
[email protected]>
Message-ID: <
[email protected]>
References: <
[email protected]> <
[email protected]>
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 <
[email protected]>
ReSent-To: TOPS-20 Distribution: ;
ReSent-Subject: Re: klh10 compilation error
ReSent-Message-ID: <
[email protected]>
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: <
[email protected]>
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: <
[email protected]>
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: <
[email protected]>
References: <
[email protected]> <
[email protected]> <
[email protected]>
Mime-Version: 1.0 (Apple Message framework v752.2)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <
[email protected]>
Cc: TOPS-20 Hackers and Yackers <
[email protected]>
Content-Transfer-Encoding: 7bit
From: John Francini <
[email protected]>
Subject: Re: klh10 compilation error
Date: Wed, 28 Nov 2007 00:22:08 -0500
To: Mark Crispin <
[email protected]>
X-Mailer: Apple Mail (2.752.2)
ReSent-Date: Tue, 27 Nov 2007 22:20:29 -0800 (PST)
ReSent-From: TOPS-20 List Moderator <
[email protected]>
ReSent-To: TOPS-20 Distribution: ;
ReSent-Subject: Re: klh10 compilation error
ReSent-Message-ID: <
[email protected]>
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: <
[email protected]>
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: <
[email protected]>
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 <
[email protected]>
Sender:
[email protected]
To: John Francini <
[email protected]>
cc: TOPS-20 Hackers and Yackers <
[email protected]>
Subject: Re: klh10 compilation error
In-Reply-To: <
[email protected]>
Message-ID: <
[email protected]>
References: <
[email protected]> <
[email protected]> <
[email protected]> <
[email protected]>
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 <
[email protected]>
ReSent-To: TOPS-20 Distribution: ;
ReSent-Subject: Re: klh10 compilation error
ReSent-Message-ID: <
[email protected]>
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: <
[email protected]>
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: <
[email protected]>
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: <
[email protected]>
References: <
[email protected]> <
[email protected]> <
[email protected]> <
[email protected]> <
[email protected]>
Mime-Version: 1.0 (Apple Message framework v752.3)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <
[email protected]>
Cc: TOPS-20 Hackers and Yackers <
[email protected]>
Content-Transfer-Encoding: 7bit
From: John Francini <
[email protected]>
Subject: Re: klh10 compilation error
Date: Wed, 28 Nov 2007 12:35:03 -0500
To: Mark Crispin <
[email protected]>
X-Mailer: Apple Mail (2.752.3)
X-Return-Path:
[email protected]
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 <
[email protected]>
ReSent-To: TOPS-20 Distribution: ;
ReSent-Subject: Re: klh10 compilation error
ReSent-Message-ID: <
[email protected]>
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: <
[email protected]>
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: <
[email protected]>
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 <
[email protected]>
Sender:
[email protected]
To: John Francini <
[email protected]>
cc: TOPS-20 Hackers and Yackers <
[email protected]>
Subject: Re: klh10 compilation error
In-Reply-To: <
[email protected]>
Message-ID: <
[email protected]>
References: <
[email protected]> <
[email protected]> <
[email protected]> <
[email protected]> <
[email protected]>
<
[email protected]>
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 <
[email protected]>
ReSent-To: TOPS-20 Distribution: ;
ReSent-Subject: Re: klh10 compilation error
ReSent-Message-ID: <
[email protected]>
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: <
[email protected]>
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: <
[email protected]>
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: <
[email protected]>
References: <
[email protected]> <
[email protected]> <
[email protected]> <
[email protected]> <
[email protected]> <
[email protected]> <
[email protected]>
Mime-Version: 1.0 (Apple Message framework v752.3)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <
[email protected]>
Cc: TOPS-20 Hackers and Yackers <
[email protected]>
Content-Transfer-Encoding: 7bit
From: John Francini <
[email protected]>
Subject: Re: klh10 compilation error
Date: Wed, 28 Nov 2007 14:21:56 -0500
To: Mark Crispin <
[email protected]>
X-Mailer: Apple Mail (2.752.3)
X-Return-Path:
[email protected]
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 <
[email protected]>
ReSent-To: TOPS-20 Distribution: ;
ReSent-Subject: Re: klh10 compilation error
ReSent-Message-ID: <
[email protected]>
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: <
[email protected]>
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: <
[email protected]>
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 <
[email protected]>; Sun, 2 Dec 2007 15:19:51 -0600 (CST)
From: Andy Valencia <
[email protected]>
To:
[email protected]
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: <
[email protected]>
ReSent-Date: Fri, 7 Dec 2007 20:20:07 -0800 (PST)
ReSent-From: TOPS-20 List Moderator <
[email protected]>
ReSent-To: TOPS-20 Distribution: ;
ReSent-Subject: Help with dual RP07 system structure
ReSent-Message-ID: <
[email protected]>
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: <
[email protected]>
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: <
[email protected]>
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 <
[email protected]> for
[email protected]; Sun, 09 Dec 2007 12:11:39 -0500 (EST)
Date: Sun, 09 Dec 2007 12:11:37 -0500
From: Thomas DeBellis <
[email protected]>
Subject: DELNF% is very disrespectful to DF%NRJ
In-reply-to: <
[email protected]>
To: Tops-20 Wizards <
[email protected]>
Message-id: <
[email protected]>
MIME-version: 1.0
Content-type: text/plain; charset=us-ascii; format=flowed
Content-transfer-encoding: 7BIT
X-Accept-Language: en-us, en
References: <
[email protected]>
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 <
[email protected]>
ReSent-To: TOPS-20 Distribution: ;
ReSent-Subject: DELNF% is very disrespectful to DF%NRJ
ReSent-Message-ID: <
[email protected]>
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:<FTP>
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
<ERSKP>
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 <OPNF> ; 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: <
[email protected]>
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: <
[email protected]>
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: <
[email protected]>
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 <
[email protected]> for
[email protected]; Sun, 09 Dec 2007 09:42:39 -0500 (EST)
Date: Sun, 09 Dec 2007 09:42:37 -0500
From: Thomas DeBellis <
[email protected]>
Subject: Re: Help with dual RP07 system structure
In-reply-to: <
[email protected]>
To: Andy Valencia <
[email protected]>
Cc: Mark Crispin <
[email protected]>
Message-id: <
[email protected]>
MIME-version: 1.0
Content-type: text/plain; charset=us-ascii; format=flowed
Content-transfer-encoding: 7BIT
X-Accept-Language: en-us, en
References: <
[email protected]>
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 <
[email protected]>
X-ReSent-To: TOPS-20 Hackers and Yackers <
[email protected]>
X-ReSent-Subject: Re: Help with dual RP07 system structure
X-ReSent-Message-ID: <
[email protected]>
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 <
[email protected]>
ReSent-To: TOPS-20 Distribution: ;
ReSent-Subject: Re: Help with dual RP07 system structure
ReSent-Message-ID: <
[email protected]>
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:<DOCUMENTATION> 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: <
[email protected]>
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: <
[email protected]>
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 <
[email protected]>
Sender:
[email protected]
To: Thomas DeBellis <
[email protected]>
cc: TOPS-20 Hackers and Yackers <
[email protected]>
Subject: Re: Help with dual RP07 system structure
In-Reply-To: <
[email protected]>
Message-ID: <
[email protected]>
References: <
[email protected]> <
[email protected]>
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 <
[email protected]>
ReSent-To: TOPS-20 Distribution: ;
ReSent-Subject: Re: Help with dual RP07 system structure
ReSent-Message-ID: <
[email protected]>
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: <
[email protected]>
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: <
[email protected]>
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 <
[email protected]>
Sender:
[email protected]
To: Thomas DeBellis <
[email protected]>
cc: TOPS-20 Hackers and Yackers <
[email protected]>
Subject: Re: Help with dual RP07 system structure
In-Reply-To: <
[email protected]>
Message-ID: <
[email protected]>
References: <
[email protected]> <
[email protected]>
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 <
[email protected]>
ReSent-To: TOPS-20 Distribution: ;
ReSent-Subject: Re: Help with dual RP07 system structure
ReSent-Message-ID: <
[email protected]>
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: <
[email protected]>
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: <
[email protected]>
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 <
[email protected]>
Sender:
[email protected]
To: Thomas DeBellis <
[email protected]>
cc: Tops-20 Wizards <
[email protected]>
Subject: Re: DELNF% is very disrespectful to DF%NRJ
In-Reply-To: <
[email protected]>
Message-ID: <
[email protected]>
References: <
[email protected]> <
[email protected]>
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 <
[email protected]>
ReSent-To: TOPS-20 Distribution: ;
ReSent-Subject: Re: DELNF% is very disrespectful to DF%NRJ
ReSent-Message-ID: <
[email protected]>
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: <
[email protected]>
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: <
[email protected]>
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 <
[email protected]>; Sun,
09 Dec 2007 22:41:17 -0500 (EST)
Date: Sun, 09 Dec 2007 22:41:16 -0500
From: Thomas DeBellis <
[email protected]>
Subject: Re: DELNF% is very disrespectful to DF%NRJ
In-reply-to: <
[email protected]>
To: Mark Crispin <
[email protected]>
Cc: Tops-20 Wizards <
[email protected]>
Message-id: <
[email protected]>
MIME-version: 1.0
Content-type: text/plain; charset=us-ascii; format=flowed
Content-transfer-encoding: 7BIT
X-Accept-Language: en-us, en
References: <
[email protected]>
<
[email protected]>
<
[email protected]>
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 <
[email protected]>
ReSent-To: TOPS-20 Distribution: ;
ReSent-Subject: Re: DELNF% is very disrespectful to DF%NRJ
ReSent-Message-ID: <
[email protected]>
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: <
[email protected]>
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: <
[email protected]>
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 <
[email protected]>
Sender:
[email protected]
To: Thomas DeBellis <
[email protected]>
cc: Tops-20 Wizards <
[email protected]>
Subject: Re: DELNF% is very disrespectful to DF%NRJ
In-Reply-To: <
[email protected]>
Message-ID: <
[email protected]>
References: <
[email protected]> <
[email protected]> <
[email protected]> <
[email protected]>
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 <
[email protected]>
ReSent-To: TOPS-20 Distribution: ;
ReSent-Subject: Re: DELNF% is very disrespectful to DF%NRJ
ReSent-Message-ID: <
[email protected]>
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: <
[email protected]>
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: <
[email protected]>
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: <
[email protected]>
From: Rich Alderson <
[email protected]>
To: Mark Crispin <
[email protected]>
CC:
[email protected], TOPS-20 Distribution: ;,
[email protected]
In-reply-to: <
[email protected]> (message
from Mark Crispin on Sun, 9 Dec 2007 10:07:15 -0800 (PST))
Subject: Re: Help with dual RP07 system structure
References: <
[email protected]> <
[email protected]> <
[email protected]>
ReSent-Date: Tue, 11 Dec 2007 22:36:08 -0800 (PST)
ReSent-From: TOPS-20 List Moderator <
[email protected]>
ReSent-To: TOPS-20 Distribution: ;
ReSent-Subject: Re: Help with dual RP07 system structure
ReSent-Message-ID: <
[email protected]>
ReSent-User-Agent: Alpine 1.00 (OSX 862 2007-12-11)
> Date: Sun, 9 Dec 2007 10:07:15 -0800 (PST)
> From: Mark Crispin <
[email protected]>
> 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: <
[email protected]>
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: <
[email protected]>
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 <
[email protected]>
Sender:
[email protected]
To: TOPS-20 Hackers and Yackers <
[email protected]>
Subject: Re: Help with dual RP07 system structure
In-Reply-To: <
[email protected]>
Message-ID: <
[email protected]>
References: <
[email protected]> <
[email protected]> <
[email protected]> <
[email protected]>
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 <
[email protected]>
ReSent-To: TOPS-20 Distribution: ;
ReSent-Subject: Re: Help with dual RP07 system structure
ReSent-Message-ID: <
[email protected]>
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: <
[email protected]>
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: <
[email protected]>
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 <
[email protected]>; Wed,
12 Dec 2007 09:42:35 -0500 (EST)
Date: Wed, 12 Dec 2007 09:42:33 -0500
From: Thomas DeBellis <
[email protected]>
Subject: Re: Help with dual RP07 system structure
In-reply-to: <
[email protected]>
To: Mark Crispin <
[email protected]>
Cc: TOPS-20 Hackers and Yackers <
[email protected]>
Message-id: <
[email protected]>
MIME-version: 1.0
Content-type: text/plain; charset=us-ascii; format=flowed
Content-transfer-encoding: 7BIT
X-Accept-Language: en-us, en
References: <
[email protected]>
<
[email protected]>
<
[email protected]>
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 <
[email protected]>
ReSent-To: TOPS-20 Distribution: ;
ReSent-Subject: Re: Help with dual RP07 system structure
ReSent-Message-ID: <
[email protected]>
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" <
[email protected]>
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: <
[email protected]>
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: <
[email protected]>
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 <
[email protected]>; 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: <
[email protected]>
From: Rich Alderson <
[email protected]>
To:
[email protected]
In-reply-to: <
[email protected]> (message from Thomas DeBellis on
Sun, 09 Dec 2007 12:11:37 -0500)
Subject: Re: DELNF% is very disrespectful to DF%NRJ
References: <
[email protected]> <
[email protected]>
ReSent-Date: Wed, 12 Dec 2007 17:23:34 -0800 (PST)
ReSent-From: TOPS-20 List Moderator <
[email protected]>
ReSent-To: TOPS-20 Distribution: ;
ReSent-Subject: Re: DELNF% is very disrespectful to DF%NRJ
ReSent-Message-ID: <
[email protected]>
ReSent-User-Agent: Alpine 1.00 (OSX 862 2007-12-11)
> Date: Sun, 09 Dec 2007 12:11:37 -0500
> From: Thomas DeBellis <
[email protected]>
> 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: <
[email protected]>
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: <
[email protected]>
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 <
[email protected]>
Sender:
[email protected]
To: TOPS-20 Hackers and Yackers <
[email protected]>
Subject: Re: DELNF% is very disrespectful to DF%NRJ
In-Reply-To: <
[email protected]>
Message-ID: <
[email protected]>
References: <
[email protected]> <
[email protected]> <
[email protected]>
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 <
[email protected]>
ReSent-To: TOPS-20 Distribution: ;
ReSent-Subject: Re: DELNF% is very disrespectful to DF%NRJ
ReSent-Message-ID: <
[email protected]>
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: <
[email protected]>
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: <
[email protected]>
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 <
[email protected]>
Sender:
[email protected]
To: Thomas DeBellis <
[email protected]>
cc: TOPS-20 Hackers and Yackers <
[email protected]>
Subject: Re: Help with dual RP07 system structure
In-Reply-To: <
[email protected]>
Message-ID: <
[email protected]>
References: <
[email protected]> <
[email protected]> <
[email protected]> <
[email protected]>
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 <
[email protected]>
ReSent-To: TOPS-20 Distribution: ;
ReSent-Subject: Re: Help with dual RP07 system structure
ReSent-Message-ID: <
[email protected]>
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: <
[email protected]>
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: <
[email protected]>
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 <
[email protected]>
Sender:
[email protected]
To: Thomas DeBellis <
[email protected]>
cc: TOPS-20 Hackers and Yackers <
[email protected]>
Subject: Re: Help with dual RP07 system structure
In-Reply-To: <
[email protected]>
Message-ID: <
[email protected]>
References: <
[email protected]> <
[email protected]> <
[email protected]> <
[email protected]>
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 <
[email protected]>
ReSent-To: TOPS-20 Distribution: ;
ReSent-Subject: Re: Help with dual RP07 system structure
ReSent-Message-ID: <
[email protected]>
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: <
[email protected]>
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: <
[email protected]>
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 <
[email protected]> for
[email protected]; Thu, 13 Dec 2007 11:40:49 -0500 (EST)
Date: Thu, 13 Dec 2007 11:40:47 -0500
From: Thomas DeBellis <
[email protected]>
Subject: Re: DELNF% is very disrespectful to DF%NRJ
In-reply-to: <
[email protected]>
To: Rich Alderson <
[email protected]>
Cc:
[email protected]
Message-id: <
[email protected]>
MIME-version: 1.0
Content-type: text/plain; charset=us-ascii; format=flowed
Content-transfer-encoding: 7BIT
X-Accept-Language: en-us, en
References: <
[email protected]>
<
[email protected]> <
[email protected]>
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 <
[email protected]>
ReSent-To: TOPS-20 Distribution: ;
ReSent-Subject: Re: DELNF% is very disrespectful to DF%NRJ
ReSent-Message-ID: <
[email protected]>
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: <
[email protected]>
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: <
[email protected]>
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 <
[email protected]>; Thu,
13 Dec 2007 12:23:40 -0500 (EST)
Date: Thu, 13 Dec 2007 12:23:39 -0500
From: Thomas DeBellis <
[email protected]>
Subject: EFTPSR TVFS activity
To: Tops-20 Wizards <
[email protected]>
Cc: Rich Alderson <
[email protected]>,
Mark Crispin <
[email protected]>
Message-id: <
[email protected]>
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 <
[email protected]>
ReSent-To: TOPS-20 Distribution: ;
ReSent-Subject: EFTPSR TVFS activity
ReSent-Message-ID: <
[email protected]>
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:<FTP>" is current directory.
LIST e*.mac.0
150 List started for STAR:<FTP>E*.MAC.0
STAR:<FTP>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:<FTP>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:<FTP>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:<FTP>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:<FTP>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:<FTP>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:<FTP>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:<FTP>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:<FTP>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:<FTP>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:<FTP>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:<FTP>E*.MAC.0
STAR:<FTP>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:<FTP>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:<FTP>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:<FTP>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:<FTP>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:<FTP>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:<FTP>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:<FTP>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:<FTP>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:<FTP>E*.MAC.0
13-Dec-2007 17:55:57-PST,2770;000000000000
Return-Path: <
[email protected]>
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: <
[email protected]>
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 <
[email protected]>; 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: <
[email protected]>
From: Rich Alderson <
[email protected]>
To:
[email protected]
In-reply-to: <
[email protected]> (message from Thomas DeBellis on
Thu, 13 Dec 2007 11:40:47 -0500)
Subject: Re: DELNF% is very disrespectful to DF%NRJ
References: <
[email protected]>
<
[email protected]> <
[email protected]> <
[email protected]>
ReSent-Date: Thu, 13 Dec 2007 17:51:42 -0800 (PST)
ReSent-From: TOPS-20 List Moderator <
[email protected]>
ReSent-To: TOPS-20 Distribution: ;
ReSent-Subject: Re: DELNF% is very disrespectful to DF%NRJ
ReSent-Message-ID: <
[email protected]>
ReSent-User-Agent: Alpine 1.00 (OSX 867 2007-12-13)
> Date: Thu, 13 Dec 2007 11:40:47 -0500
> From: Thomas DeBellis <
[email protected]>
>>> 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: <
[email protected]>
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: <
[email protected]>
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 <
[email protected]> for
[email protected]; Fri, 14 Dec 2007 21:11:41 -0500 (EST)
Date: Fri, 14 Dec 2007 21:11:39 -0500
From: Thomas DeBellis <
[email protected]>
Subject: Re: DELNF% is very disrespectful to DF%NRJ
In-reply-to: <
[email protected]>
To: Rich Alderson <
[email protected]>
Cc:
[email protected]
Message-id: <
[email protected]>
MIME-version: 1.0
Content-type: text/plain; charset=us-ascii; format=flowed
Content-transfer-encoding: 7BIT
X-Accept-Language: en-us, en
References: <
[email protected]>
<
[email protected]> <
[email protected]>
<
[email protected]> <
[email protected]>
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 <
[email protected]>
ReSent-To: TOPS-20 Distribution: ;
ReSent-Subject: Re: DELNF% is very disrespectful to DF%NRJ
ReSent-Message-ID: <
[email protected]>
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: <
[email protected]>
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: <
[email protected]>
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" <
[email protected]>
To:
[email protected]
Cc:
[email protected]
X-US-Mail: "Department of Mathematics, 110 LCB, University of Utah, 155 S
1400 E RM 233, Salt Lake City, UT 84112-0090, USA"
X-Telephone: +1 801 581 5254
X-FAX: +1 801 585 1640, +1 801 581 4148
X-URL:
http://www.math.utah.edu/~beebe
Subject: [tops-20] a significant birthday: the transistor turns 60
Message-ID: <
[email protected]>
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0 (mail.math.utah.edu [155.101.98.135]); Sat, 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 <
[email protected]>
ReSent-To: TOPS-20 Distribution: ;
ReSent-Subject: [tops-20] a significant birthday: the transistor turns 60
ReSent-Message-ID: <
[email protected]>
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:
[email protected] -
- 155 S 1400 E RM 233
[email protected] [email protected] -
- Salt Lake City, UT 84112-0090, USA URL:
http://www.math.utah.edu/~beebe/ -
-------------------------------------------------------------------------------
15-Dec-2007 10:25:48-PST,2823;000000000000
Return-Path: <
[email protected]>
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: <
[email protected]>
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: <
[email protected]>
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 <
[email protected]>
To: Thomas DeBellis <
[email protected]>
Cc: TOPS-20 List Moderator <
[email protected]>
Subject: Re: DELNF% is very disrespectful to DF%NRJ
In-Reply-To: <
[email protected]>
Message-ID: <
[email protected]>
X-ReSent-Date: Sat, 15 Dec 2007 10:17:20 -0800 (PST)
X-ReSent-From: Mark Crispin <
[email protected]>
X-ReSent-To: TOPS-20 Hackers and Yackers <
[email protected]>
X-ReSent-Subject: Re: DELNF% is very disrespectful to DF%NRJ
X-ReSent-Message-ID: <
[email protected]>
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 <
[email protected]>
ReSent-To: TOPS-20 Distribution: ;
ReSent-Subject: Re: DELNF% is very disrespectful to DF%NRJ
ReSent-Message-ID: <
[email protected]>
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: <
[email protected]>
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: <
[email protected]>
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 <
[email protected]>; 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 <
[email protected]>; Sat, 15 Dec 2007 21:12:12 -0800
Date: Sat, 15 Dec 2007 21:12:08 -0800 (PST)
From: Mark Crispin <
[email protected]>
Sender:
[email protected]
To: TOPS-20 Hackers and Yackers <
[email protected]>
Subject: Re: panda dist TOPS-20 question (fwd)
Message-ID: <
[email protected]>
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 <
[email protected]>
ReSent-To: TOPS-20 Distribution: ;
ReSent-Subject: Re: panda dist TOPS-20 question (fwd)
ReSent-Message-ID: <
[email protected]>
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 <
[email protected]>
To: Mark Crispin <
[email protected]>
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: <
[email protected]>
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: <
[email protected]>
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 <
[email protected]>
Subject: Happy DEC-20 Day!
To:
[email protected]
Reply-To:
[email protected]
Message-ID: <
[email protected]>
ReSent-Date: Thu, 20 Dec 2007 11:29:01 -0800 (PST)
ReSent-From: TOPS-20 List Moderator <
[email protected]>
ReSent-To: TOPS-20 Distribution: ;
ReSent-Subject: Happy DEC-20 Day!
ReSent-Message-ID: <
[email protected]>
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, <Directory> 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:<DOMAIN>
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: <
[email protected]>
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: <
[email protected]>
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 <
[email protected]> for
[email protected]; Thu, 20 Dec 2007 21:27:38 -0500 (EST)
Date: Thu, 20 Dec 2007 21:27:36 -0500
From: Thomas DeBellis <
[email protected]>
Subject: Re: Happy DEC-20 Day!
In-reply-to: <
[email protected]>
To:
[email protected]
Cc:
[email protected]
Message-id: <
[email protected]>
MIME-version: 1.0
Content-type: text/plain; charset=us-ascii; format=flowed
Content-transfer-encoding: 7BIT
X-Accept-Language: en-us, en
References: <
[email protected]>
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 <
[email protected]>
ReSent-To: TOPS-20 Distribution: ;
ReSent-Subject: Re: Happy DEC-20 Day!
ReSent-Message-ID: <
[email protected]>
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: <
[email protected]>
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: <
[email protected]>
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 <
[email protected]>; 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: <
[email protected]>
From: Rich Alderson <
[email protected]>
To:
[email protected]
In-reply-to: <
[email protected]> (message from Thomas DeBellis on
Thu, 20 Dec 2007 21:27:36 -0500)
Subject: Re: Happy DEC-20 Day!
References: <
[email protected]> <
[email protected]>
ReSent-Date: Fri, 21 Dec 2007 12:15:09 -0800 (PST)
ReSent-From: TOPS-20 List Moderator <
[email protected]>
ReSent-To: TOPS-20 Distribution: ;
ReSent-Subject: Re: Happy DEC-20 Day!
ReSent-Message-ID: <
[email protected]>
ReSent-User-Agent: Alpine 1.00 (OSX 882 2007-12-20)
> Date: Thu, 20 Dec 2007 21:27:36 -0500
> From: Thomas DeBellis <
[email protected]>
> > 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: <
[email protected]>
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: <
[email protected]>
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 <
[email protected]> for
[email protected]; Sat, 22 Dec 2007 16:30:33 -0500 (EST)
Date: Sat, 22 Dec 2007 16:30:28 -0500
From: Thomas DeBellis <
[email protected]>
Subject: backwr
In-reply-to: <
[email protected]>
To: Tops-20 Wizards <
[email protected]>
Message-id: <
[email protected]>
MIME-version: 1.0
Content-type: text/plain; charset=us-ascii; format=flowed
Content-transfer-encoding: 7BIT
X-Accept-Language: en-us, en
References: <
[email protected]>
<
[email protected]> <
[email protected]>
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 <
[email protected]>
ReSent-To: TOPS-20 Distribution: ;
ReSent-Subject: backwr
ReSent-Message-ID: <
[email protected]>
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:<DOCUMENTATION>.
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: <
[email protected]>
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: <
[email protected]>
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 <
[email protected]>
Sender:
[email protected]
To: TOPS-20 Hackers and Yackers <
[email protected]>
Subject: One TOPS-20 Per Child
Message-ID: <
[email protected]>
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 <
[email protected]>
ReSent-To: TOPS-20 Distribution: ;
ReSent-Subject: One TOPS-20 Per Child
ReSent-Message-ID: <
[email protected]>
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: <
[email protected]>
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: <
[email protected]>
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 <
[email protected]>; Wed, 26 Dec 2007 11:55:44 -0500
Message-ID: <
[email protected]>
Date: Wed, 26 Dec 2007 11:55:43 -0500
From: Thomas DeBellis <
[email protected]>
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 <
[email protected]>
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 <
[email protected]>
ReSent-To: TOPS-20 Distribution: ;
ReSent-Subject: HLRI-HLRZI / XHLRI-XLRZI?
ReSent-Message-ID: <
[email protected]>
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: <
[email protected]>
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: <
[email protected]>
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 <
[email protected]>; Fri, 28 Dec 2007 15:20:39 -0500
Message-ID: <
[email protected]>
Date: Fri, 28 Dec 2007 15:20:38 -0500
From: Thomas DeBellis <
[email protected]>
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 <
[email protected]>
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 <
[email protected]>
ReSent-To: TOPS-20 Distribution: ;
ReSent-Subject: Section 0 word pointers from a non-zero section?
ReSent-Message-ID: <
[email protected]>
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: <
[email protected]>
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: <
[email protected]>
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 <
[email protected]>
Sender:
[email protected]
To: Thomas DeBellis <
[email protected]>
cc: Tops-20 Wizards <
[email protected]>
Subject: Re: Section 0 word pointers from a non-zero section?
In-Reply-To: <
[email protected]>
Message-ID: <
[email protected]>
References: <
[email protected]>
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 <
[email protected]>
ReSent-To: TOPS-20 Distribution: ;
ReSent-Subject: Re: Section 0 word pointers from a non-zero section?
ReSent-Message-ID: <
[email protected]>
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: <
[email protected]>
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: <
[email protected]>
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: <
[email protected]>
Date: Mon, 31 Dec 2007 11:38:29 -0500
From: Thomas DeBellis <
[email protected]>
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 <
[email protected]>
CC: Tops-20 Wizards <
[email protected]>
Subject: Re: Section 0 word pointers from a non-zero section?
References: <
[email protected]> <
[email protected]>
In-Reply-To: <
[email protected]>
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 <
[email protected]>
ReSent-To: TOPS-20 Distribution: ;
ReSent-Subject: Re: Section 0 word pointers from a non-zero section?
ReSent-Message-ID: <
[email protected]>
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: <
[email protected]>
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: <
[email protected]>
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 <
[email protected]>; Mon, 31 Dec 2007 11:45:59 -0800
Date: Mon, 31 Dec 2007 11:45:59 -0800 (PST)
From: Fred Wright <
[email protected]>
X-Sender:
[email protected]
Reply-To: Fred Wright <
[email protected]>
To: Tops-20 Wizards <
[email protected]>
Subject: Re: Section 0 word pointers from a non-zero section?
In-Reply-To: <
[email protected]>
Message-ID: <
[email protected]>
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 <
[email protected]>
ReSent-To: TOPS-20 Distribution: ;
ReSent-Subject: Re: Section 0 word pointers from a non-zero section?
ReSent-Message-ID: <
[email protected]>
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: <
[email protected]>
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: <
[email protected]>
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 <
[email protected]>
Sender:
[email protected]
To: Fred Wright <
[email protected]>
cc: Tops-20 Wizards <
[email protected]>
Subject: Re: Section 0 word pointers from a non-zero section?
In-Reply-To: <
[email protected]>
Message-ID: <
[email protected]>
References: <
[email protected]>
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 <
[email protected]>
ReSent-To: TOPS-20 Distribution: ;
ReSent-Subject: Re: Section 0 word pointers from a non-zero section?
ReSent-Message-ID: <
[email protected]>
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: <
[email protected]>
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: <
[email protected]>
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 <
[email protected]> for
[email protected]; Mon, 31 Dec 2007 19:48:38 -0500 (EST)
Date: Mon, 31 Dec 2007 19:48:37 -0500
From: Thomas DeBellis <
[email protected]>
Subject: Re: Section 0 word pointers from a non-zero section?
In-reply-to: <
[email protected]>
To: Fred Wright <
[email protected]>
Cc: Tops-20 Wizards <
[email protected]>
Message-id: <
[email protected]>
MIME-version: 1.0
Content-type: text/plain; charset=us-ascii; format=flowed
Content-transfer-encoding: 7BIT
X-Accept-Language: en-us, en
References: <
[email protected]>
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 <
[email protected]>
ReSent-To: TOPS-20 Distribution: ;
ReSent-Subject: Re: Section 0 word pointers from a non-zero section?
ReSent-Message-ID: <
[email protected]>
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: <
[email protected]>
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: <
[email protected]>
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 <
[email protected]>
Sender:
[email protected]
To: TOPS-20 Hackers and Yackers <
[email protected]>
Subject: success: One TOPS-20 Per Child
Message-ID: <
[email protected]>
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 <
[email protected]>
ReSent-To: TOPS-20 Distribution: ;
ReSent-Subject: success: One TOPS-20 Per Child
ReSent-Message-ID: <
[email protected]>
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: <
[email protected]>
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: <
[email protected]>
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 <
[email protected]>
Sender:
[email protected]
To: Thomas DeBellis <
[email protected]>
cc: Fred Wright <
[email protected]>, Tops-20 Wizards <
[email protected]>
Subject: Re: Section 0 word pointers from a non-zero section?
In-Reply-To: <
[email protected]>
Message-ID: <
[email protected]>
References: <
[email protected]> <
[email protected]>
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 <
[email protected]>
ReSent-To: TOPS-20 Distribution: ;
ReSent-Subject: Re: Section 0 word pointers from a non-zero section?
ReSent-Message-ID: <
[email protected]>
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
