1-Jan-2008 15:34:28-PST,6624;000000000000 Return-Path: Received: from pangtzu.panda.com ([206.124.149.117]) by Lingling.Panda.COM with TCP/SMTP; Tue, 1 Jan 2008 15:30:01 -0800 (PST) X-Return-Path: X-Received: from mta5.srv.hcvlny.cv.net ([167.206.4.200]) by Lingling.Panda.COM with TCP/SMTP; Tue, 1 Jan 2008 14:04:28 -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 <0JTZ009IKJYVDT70@mta5.srv.hcvlny.cv.net>; Tue, 01 Jan 2008 17:04:08 -0500 (EST) Date: Tue, 01 Jan 2008 17:04:06 -0500 From: Thomas DeBellis Subject: Re: Section 0 word pointers from a non-zero section? In-reply-to: To: Mark Crispin Cc: Tops-20 Wizards Message-id: <477AB8D6.9050303@optonline.net> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en References: <47798DE5.7070106@optonline.net> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) ReSent-Date: Tue, 1 Jan 2008 15:29:52 -0800 (PST) ReSent-From: TOPS-20 List Moderator ReSent-To: TOPS-20 Distribution: ; ReSent-Subject: Re: Section 0 word pointers from a non-zero section? ReSent-Message-ID: ReSent-User-Agent: Alpine 1.00 (OSX 882 2007-12-20) > I planned on doing that in MAPSER, but never got 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. Yes, your eidetic memory may be cursing you yet again (or something). I use guard pages all over the place in the new FTP server, the obvious places being to surround the various stacks and tables that I build along with the file buffers that I use. My buffering logic usually winds up being pretty good, but I always seem to have to do a lot of debugging... But write protecting isn't quite enough if you want a true guard page: a read can still do a copy on-write. You want something that will blow you up no matter how you reference it. What I do is simply call a sub-routine that gets a handle on a 'likely' page that has EFTPSR mapped in: itself. In other words, the subroutine does an XMOVEI and rounds that up by a page (to allow DDT to still work when debugging the code). Once I determine that the handle has a JFN in it (and do some more checking), I assume that this is my own executable. I do a FFFP% to get to the last page of my own executable, add one and then map that post- ultimate page in. Since the process has the .EXE locked, this works fine. You blow up when you touch the page (even if you're running with wheel enabled). I got the approach from you and R. Gorin's book ("Introduction to DECSYSTEM -20 Assembly Language Programming", page 443, footnote 3). However, I can not remember whether the idea of mapping in a page beyond the current process' (locked) executable file was my own or not. Gee, I hope it was! It means that the sub-routine can be used in any program. So, you should be able to just drop this code into MAPSER (when you're doing the work to bring it up to IMAP4 :-) ; Returns page number of guard page in T1, address in T2 FEPAGE: MOVEI P4,^D20 ; Don't look through more than this many pages XMOVEI P3,. ; Load current page address LSH P3,-^D9 ; Convert address to page which we don't ; look at because DDT is probably there DO. ; Now find a page with our JFN in it SOJLE P4,CAINT ; Looked through too many pages? AOS T1,P3 ; Increment and load page number HRLI T1,.FHSLF!FH%EPN ; Looking at this fork RPACS% ; Find out the access ERJMPR TOP. ; Couldn't, go to next page TXNN T2,PA%PEX ; Does the page exist? LOOP. ; No, go look for another one TXNE T2,PA%PRV ; Is the page private? LOOP. ; Yes, we need one with a JFN in it RMAP% ; Get a handle on the page ERJMPR TOP. ; Gronked, go on to next page TXNN T2,PA%PEX ; Sanity Check: does the page still exist? LOOP. ; No, go look for another one HLRZ T1,T1 ; Load just the process/file designator CAIN T1,.FHSLF ; Quick check, this isn't our process, is it? LOOP. ; Yah, it is, bum the GTSTS% GTSTS% ; Otherwise, see if we can use this? ERJMPR TOP. ; No JFN, so just go to the next page TXNN T2,GS%NAM ; Is anything in there a JFN? LOOP. ; No, not safe to use TXNN T2,GS%OPN ; Is the file open? LOOP. ; No, won't be able to PMAP% it TXNE T2,GS%WRF ; Better not be for write LOOP. ; It is, will self-create, then TXNN T2,GS%RND ; Open for non-append access? LOOP. ; No, will extend then ENDDO. ; Keep looping through pages ; Otherwise, we have a safe page to use MOVE P3,T1 ; Save a nice JFN SIZEF% ; Get the number of pages in the file ERJMPR CAINT ; Can't, so just fudge something up HRR T1,P3 ; Load our executable JFN HRL T1,T3 ; Start REAL NEAR the end of the file FFFFP% ; Find the first unused (free) file page ERJMPR CAINT ; Can't, just fudge something up CAMN T1,[-1] ; None?? JRST CAINT ; No, just cons something up MOVE Q1,T1 ; Save as source designator ; Now create a DATA .PSECT guard page DMOVE P3,[EXP ,0] ; Load the address of where to map it LSHC P3,-^D9 ; Convert final offset to page CAIE P4,0 ; Not on a page boundary? ADDI P3,^D1 ; No, round up MOVE P4,P3 ; Store post-ultimate page number HRLI P3,.FHSLF!FH%EPN ; Now have a fork,,page handle LSH P4,^D9 ; Convert page to 30 bit address MOVE T1,Q1 ; Load the source file JFN and page MOVE T2,P3 ; Load destination, .PSECT guard page MOVX T3,PM%EPN ; Going into a non-zero section PMAP% ; Finally map in a bogus page ERJMPR CAINT ; Gronked, go do something else HRRZ T1,P3 ; Load the page number of the guard page MOVE T2,P4 ; Load the address of the guard page MOVE T3,Q1 ; Return file JFN and file page MOVE T3,(P4) ; Test the page, this should fail ERJMPS R ; and we should take this error return FAIL <550 Created guard page has read access> 1-Jan-2008 15:38:01-PST,2949;000000000000 Return-Path: Received: from pangtzu.panda.com ([206.124.149.117]) by Lingling.Panda.COM with TCP/SMTP; Tue, 1 Jan 2008 15:30:36 -0800 (PST) X-Return-Path: X-Received: from mta4.srv.hcvlny.cv.net ([167.206.4.199]) by Lingling.Panda.COM with TCP/SMTP; Tue, 1 Jan 2008 14:04:19 -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 <0JTZ0041CJZ0MVB0@mta4.srv.hcvlny.cv.net>; Tue, 01 Jan 2008 17:04:12 -0500 (EST) Date: Tue, 01 Jan 2008 17:04:10 -0500 From: Thomas DeBellis Subject: Re: Section 0 word pointers from a non-zero section? In-reply-to: To: Mark Crispin Cc: Tops-20 Wizards Message-id: <477AB8DA.1000801@optonline.net> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en References: <47798DE5.7070106@optonline.net> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) ReSent-Date: Tue, 1 Jan 2008 15:30:28 -0800 (PST) ReSent-From: TOPS-20 List Moderator ReSent-To: TOPS-20 Distribution: ; ReSent-Subject: Re: Section 0 word pointers from a non-zero section? ReSent-Message-ID: ReSent-User-Agent: Alpine 1.00 (OSX 882 2007-12-20) > 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. Until about version 4 (or 5?), Columbia's EXEC still had an IDDT command that would splice IDDT in between the EXEC and a particular fork. I remember this working. Very useful. However, I think you're right about the TENEX issue. I remember flipping through IDDT for some reason a few years ago (I think I was trying to build EMACS) and I don't recall seeing any extended anything in there. Small surprise: there was real concern about code not being able to be run on both TENEX and Tops-20 way back when. At one point, the TENEX crowd was still large enough (and loud enough) so that one would think twice about using non-KA instructions (like DMOVE) in code. The old BBN FTP server and TCPSIM do not use the 'newer' instructions. However, that didn't stop Tops-20 sites (like me), from doing it anyway ... For that (and many other reasons), the extended mode FTP server does not run on TENEX. However, given enough brain (damaging) surgery, I could probably make it do this. I have no plans to do so, however. 1-Jan-2008 15:41:42-PST,5613;000000000000 Return-Path: Received: from pangtzu.panda.com ([206.124.149.117]) by Lingling.Panda.COM with TCP/SMTP; Tue, 1 Jan 2008 15:32:06 -0800 (PST) X-Return-Path: X-Received: from mta4.srv.hcvlny.cv.net ([167.206.4.199]) by Lingling.Panda.COM with TCP/SMTP; Tue, 1 Jan 2008 14:04:21 -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 <0JTZ004VQJZ4EZA0@mta4.srv.hcvlny.cv.net> for TOPS-20@Lingling.Panda.COM; Tue, 01 Jan 2008 17:04:16 -0500 (EST) Date: Tue, 01 Jan 2008 17:04:15 -0500 From: Thomas DeBellis Subject: Re: Section 0 word pointers from a non-zero section? In-reply-to: <1199207577.23095.224.camel@tardis.xkl.com> To: Ralph Gorin Cc: Tops-20 Wizards Message-id: <477AB8DF.1080709@optonline.net> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en References: <47798DE5.7070106@optonline.net> <1199207577.23095.224.camel@tardis.xkl.com> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) ReSent-Date: Tue, 1 Jan 2008 15:31:54 -0800 (PST) ReSent-From: TOPS-20 List Moderator ReSent-To: TOPS-20 Distribution: ; ReSent-Subject: Re: Section 0 word pointers from a non-zero section? ReSent-Message-ID: ReSent-User-Agent: Alpine 1.00 (OSX 882 2007-12-20) > Null pointers that address section 7777 ought to hurt anyone who > dereferences them. Ah. I had forgotten about that (come to think of it, I probably never knew it). I'll keep it in mind; but for now, I'm using addresses to a guard page (see previous). But "Null" was perhaps unfortunate wording on my part; what I should have said was "un-initialized" pointers. These typically contain a zero, so they don't blow you up when you de-reference them on the PDP-10 or the VAX. They do blow you up on a SPARC and in the 80286 (and beyond) protected mode, when working with segments. That's caught some bugs for me: I still have a legacy 80286 based OS/2 1.3 machine running the Microsoft C and MASM 6.00B development environment (the last one before they dropped OS/2 support). It's excellent for regression testing; you'd be surprised with what I've bumped into. I don't have anything to get SPARCki with ... > It may be a shame to waste 3% of the address space, but it is such a > pain to make any use of it. The machine is very different in > section 0. If you are using one word global pointers to address text, it isn't a pain at all. It's completely transparent. For example, COMND% is happy to get string pointers to field defaults and noise words from down there. So does PSOUT% and friends. You just can't chain an FDB across sections ... Addressing words is less easy. Inter-section coding is messy. However, a multi-section 0/1 program is useful for doing kludges. Not too long ago, I was (briefly) looking at MM (for some other reasons) and it seemed to me that it wouldn't be an abominable act to make it handle having the mail file in an extended section (please don't kill me, Mark). Most of the code doesn't handle the mail file directly, but rather calls a few routines to do things. By this, I mean that only a few routines actually directly access the mail file. They don't even return pointers. FSCOPY is a candidate (which could also use MOVSJ in certain cases). So, MM proper could still run in section 0 to do its thing. Whenever it needed to actually hack the mail file, it could just bounce up to section one to do the actual work. I'm tired of getting grumped at every couple of months to chop down mail files ... This is another thing that I didn't go very far with because I've been trying to concentrate on the FTP server. So many distractions ... > It doesn't take too much to make versions of KLH and TOPS-20 that > support 27 bit virtual addresses. Another distraction, sigh ... But for right now, I still support KL class machines, so that 3% (or 6%) is enough for me to pay attention. I obviously don't worry about such things on a Toad (which I also support), but I don't use extended string instructions there. > I haven't bothered to banish section 0 from our memory images. I > don't think it would be hard to do so. I would be VERY interested in knowing what happens if you try to get rid of section zero. As much as I'd hate to lose 3% VA, I do think we'd be better off not having it. Nothing in my server depends on the HELP .PSECT being in section zero; it can be anywhere, I just couldn't walk away from section 0 if it HAS to be there. Does it? But all of this makes me wonder about the alternative approach of having a processor mode bit (as Mark has also commented on). The 286 class machines (and above) all have a protected mode bit, so there is no (or 'different') inter-address mode hackery. The only problem with the 286 protected mode was the nonsense that you had to go through to get it back to real mode to run legacy (DOS) programs. Gordon Letwin's patented idea of "turning the car off and on at 60 MPH" still gives me the heeby jeebies ... 1-Jan-2008 16:34:02-PST,4586;000000000000 Return-Path: Received: from pangtzu.panda.com ([206.124.149.117]) by Lingling.Panda.COM with TCP/SMTP; Tue, 1 Jan 2008 16:30:07 -0800 (PST) X-Return-Path: X-Received: from pangtzu.panda.com ([206.124.149.117]) by Lingling.Panda.COM with TCP/SMTP; Tue, 1 Jan 2008 16:28:06 -0800 (PST) Date: Tue, 1 Jan 2008 16:28:01 -0800 (PST) From: Mark Crispin Sender: mrc@pangtzu.panda.com To: Thomas DeBellis cc: Tops-20 Wizards Subject: Re: Section 0 word pointers from a non-zero section? In-Reply-To: <477AB8D6.9050303@optonline.net> Message-ID: References: <47798DE5.7070106@optonline.net> <477AB8D6.9050303@optonline.net> 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: Tue, 1 Jan 2008 16:30:00 -0800 (PST) ReSent-From: TOPS-20 List Moderator ReSent-To: TOPS-20 Distribution: ; ReSent-Subject: Re: Section 0 word pointers from a non-zero section? ReSent-Message-ID: ReSent-User-Agent: Alpine 1.00 (OSX 882 2007-12-20) On Tue, 1 Jan 2008, Thomas DeBellis wrote: > In other words, the subroutine does an XMOVEI and rounds that up by a > page (to allow DDT to still work when debugging the code). Once I > determine that the handle has a JFN in it (and do some more checking), > I assume that this is my own executable. I do a FFFP% to get to the > last page of my own executable, add one and then map that post- > ultimate page in. Since the process has the .EXE locked, this works > fine. You blow up when you touch the page (even if you're running > with wheel enabled). What a hack! I just tried it and verified that it does, in fact, work. PMAP is smart enough to check to see if there's a super-index block for the page, but doesn't check if the file page itself has a mapping. However, you're screwed if the filesize is a multiple of 512 pages. > However, I can not remember whether the idea of mapping in a page > beyond the current process' (locked) executable file was my own or > not. Gee, I hope it was! Using the running process's binary instead of a temporary file is almost certainly your idea. As for updating MAPSER to IMAP4, I think not. The RFC 822 parser in MAPSER, while still servicable and better than MM's, is aging and more importantly there's no MIME parser at all. It would make much more sense to build UW imapd for TOPS-20. There's a bunch of other stuff in the IMAP4 base specification than an IMAP2 implementation didn't have to worry about, such as parsing RFC 822 dates (IMAP2 allowed you to treat it as a blob-string). Unicode and charset support is even more daunting. Fortunately, the c-client library already builds fine on TOPS-20, and it wouldn't be too much trauma to get imapd to build as well (I've just never done it). There aren't any TOPS-20 local file drivers, but it would make more sense to port the mix format driver than mtx (which is more or less the TOPS-20 format) since mtx format lacks metadata that IMAP needs. mbx format has the metadata, but it's 12 years old and flat file formats just aren't much good these days. You can't expect to PMAP% an entire mailbox any more, not when people have 3 and 4 digit MB mailboxes. PMAP%ing the mix index, status, and current data file would make a lot of sense, though. However, the entire project makes no sense until we have some solution for SSL/TLS. Sending passwords in the clear is a bad idea on today's Internet. CRAM-MD5 would be easy enough to do (although the session would then be vulnerable to hijacking...have someone demonstrate hunt to you if you want to become very very scared), but we need support in TOPS-20 for a form of LOGIN% that does not validate passwords. I've thought about doing that from time to time, perhaps something as trivial as adding JUMPE T2,RSKP or, if there's any chance that something already calls LOGIN% with AC2/0, MOVE T1,T2 AOJE T1,RSKP at CHKPSW+1. This ought to be alright since an unlogged in job is effectively WHEEL and CHKPSW is only called from LOGIN%. -- Mark -- http://panda.com/tops-20 TOPS-20: a great improvement over its successors 1-Jan-2008 16:46:00-PST,2196;000000000000 Return-Path: Received: from pangtzu.panda.com ([206.124.149.117]) by Lingling.Panda.COM with TCP/SMTP; Tue, 1 Jan 2008 16:41:57 -0800 (PST) X-Return-Path: X-Received: from pangtzu.panda.com ([206.124.149.117]) by Lingling.Panda.COM with TCP/SMTP; Tue, 1 Jan 2008 16:40:30 -0800 (PST) Date: Tue, 1 Jan 2008 16:40:24 -0800 (PST) From: Mark Crispin Sender: mrc@pangtzu.panda.com To: Thomas DeBellis cc: Ralph Gorin , Tops-20 Wizards Subject: Re: Section 0 word pointers from a non-zero section? In-Reply-To: <477AB8DF.1080709@optonline.net> Message-ID: References: <47798DE5.7070106@optonline.net> <1199207577.23095.224.camel@tardis.xkl.com> <477AB8DF.1080709@optonline.net> User-Agent: Alpine 1.00 (OSX 882 2007-12-20) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed ReSent-Date: Tue, 1 Jan 2008 16:41:48 -0800 (PST) ReSent-From: TOPS-20 List Moderator ReSent-To: TOPS-20 Distribution: ; ReSent-Subject: Re: Section 0 word pointers from a non-zero section? ReSent-Message-ID: ReSent-User-Agent: Alpine 1.00 (OSX 882 2007-12-20) On Tue, 1 Jan 2008, Thomas DeBellis wrote: > Not > too long ago, I was (briefly) looking at MM (for some other reasons) > and it seemed to me that it wouldn't be an abominable act to make it > handle having the mail file in an extended section (please don't kill > me, Mark). No killing needed. IIRC, XKL has already done this. I do, however, feel that as great as MM was for its time, that time has passed. Thanks to MIME, MM has aged less well than the rest of TOPS-20. IMHO, it would be much more interesting to port Alpine to TOPS-20. If GNU Emacs can be ported to TOPS-20, then certainly Alpine can be. -- Mark -- http://panda.com/tops-20 TOPS-20: a great improvement over its successors 2-Jan-2008 08:04:46-PST,2532;000000000000 Return-Path: Received: from pangtzu.panda.com ([206.124.149.117]) by Lingling.Panda.COM with TCP/SMTP; Wed, 2 Jan 2008 08:00:54 -0800 (PST) X-Return-Path: X-Received: from nic.cafax.se ([192.71.228.17]) by Lingling.Panda.COM with TCP/SMTP; Wed, 2 Jan 2008 04:48:50 -0800 (PST) X-Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id m02CmgUK012608; Wed, 2 Jan 2008 13:48:42 +0100 (MET) X-Received: (from bygg@localhost) by nic.cafax.se (8.13.7/8.12.11/Submit) id m02CmgSg007526; Wed, 2 Jan 2008 13:48:42 +0100 (MET) Date: Wed, 2 Jan 2008 13:48:42 WET From: Johnny Eriksson To: Tops-20 Wizards CC: TOPS-20 List Moderator Subject: Re: backwr In-Reply-To: Your message of Sat, 22 Dec 2007 16:30:28 -0500 Message-ID: ReSent-Date: Wed, 2 Jan 2008 08:00:40 -0800 (PST) ReSent-From: TOPS-20 List Moderator ReSent-To: TOPS-20 Distribution: ; ReSent-Subject: Re: backwr ReSent-Message-ID: ReSent-User-Agent: Alpine 1.00 (OSX 882 2007-12-20) > 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'm afraid that the author has not written anything. Yet... It was originally written to do just the task you wanted it for, but for another PDP-10 operating system/PDP-10 simulator, to move files into it. Seems like it is still useful to have around... > 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. My current problem is a severe lack of spare time, but I'll see what I can do. --Johnny 2-Jan-2008 11:14:41-PST,2201;000000000000 Return-Path: Received: from pangtzu.panda.com ([206.124.149.117]) by Lingling.Panda.COM with TCP/SMTP; Wed, 2 Jan 2008 11:10:18 -0800 (PST) X-Return-Path: X-Received: from mail1.panix.com ([166.84.1.72]) by Lingling.Panda.COM with TCP/SMTP; Wed, 2 Jan 2008 10:59:02 -0800 (PST) X-Received: from panix5.panix.com (panix5.panix.com [166.84.1.5]) by mail1.panix.com (Postfix) with ESMTP id A600229412 for ; Wed, 2 Jan 2008 13:58:55 -0500 (EST) X-Received: (from alderson@localhost) by panix5.panix.com (8.11.6p3/8.8.8/PanixN1.1) id m02IwtT09618; Wed, 2 Jan 2008 13:58:55 -0500 (EST) Date: Wed, 2 Jan 2008 13:58:55 -0500 (EST) Message-Id: <200801021858.m02IwtT09618@panix5.panix.com> From: Rich Alderson To: TOPS-20@Lingling.Panda.COM In-reply-to: <477AB8DA.1000801@optonline.net> (message from Thomas DeBellis on Tue, 01 Jan 2008 17:04:10 -0500) Subject: Re: Section 0 word pointers from a non-zero section? References: <47798DE5.7070106@optonline.net> <477AB8DA.1000801@optonline.net> ReSent-Date: Wed, 2 Jan 2008 11:10:10 -0800 (PST) ReSent-From: TOPS-20 List Moderator ReSent-To: TOPS-20 Distribution: ; ReSent-Subject: Re: Section 0 word pointers from a non-zero section? ReSent-Message-ID: ReSent-User-Agent: Alpine 1.00 (OSX 882 2007-12-20) > Date: Tue, 01 Jan 2008 17:04:10 -0500 > From: Thomas DeBellis > Until about version 4 (or 5?), Columbia's EXEC still had an IDDT command that > would splice IDDT in between the EXEC and a particular fork. I remember this > working. Very useful. Just out of curiosity, was this a command that moved IDDT into the process tree between the EXEC and a pre-existing fork? (That would have been an interesting hack to preserve!) Or did it simply start IDDT and point it at an .exe to map in? Rich 2-Jan-2008 11:18:30-PST,2986;000000000000 Return-Path: Received: from pangtzu.panda.com ([206.124.149.117]) by Lingling.Panda.COM with TCP/SMTP; Wed, 2 Jan 2008 11:11:00 -0800 (PST) X-Return-Path: X-Received: from mail1.panix.com ([166.84.1.72]) by Lingling.Panda.COM with TCP/SMTP; Wed, 2 Jan 2008 11:07:04 -0800 (PST) X-Received: from panix5.panix.com (panix5.panix.com [166.84.1.5]) by mail1.panix.com (Postfix) with ESMTP id BED412940F; Wed, 2 Jan 2008 14:06:58 -0500 (EST) X-Received: (from alderson@localhost) by panix5.panix.com (8.11.6p3/8.8.8/PanixN1.1) id m02J6wA20545; Wed, 2 Jan 2008 14:06:58 -0500 (EST) Date: Wed, 2 Jan 2008 14:06:58 -0500 (EST) Message-Id: <200801021906.m02J6wA20545@panix5.panix.com> From: Rich Alderson To: TOPS-20@Lingling.Panda.COM CC: gorin@xkl.com In-reply-to: (message from Mark Crispin on Tue, 1 Jan 2008 16:40:24 -0800 (PST)) Subject: Re: Section 0 word pointers from a non-zero section? References: <47798DE5.7070106@optonline.net> <1199207577.23095.224.camel@tardis.xkl.com> <477AB8DF.1080709@optonline.net> ReSent-Date: Wed, 2 Jan 2008 11:10:50 -0800 (PST) ReSent-From: TOPS-20 List Moderator ReSent-To: TOPS-20 Distribution: ; ReSent-Subject: Re: Section 0 word pointers from a non-zero section? ReSent-Message-ID: ReSent-User-Agent: Alpine 1.00 (OSX 882 2007-12-20) > Date: Tue, 1 Jan 2008 16:40:24 -0800 (PST) > From: Mark Crispin > On Tue, 1 Jan 2008, Thomas DeBellis wrote: >> Not too long ago, I was (briefly) looking at MM (for some other reasons) and >> it seemed to me that it wouldn't be an abominable act to make it handle >> having the mail file in an extended section (please don't kill me, Mark). > No killing needed. IIRC, XKL has already done this. Yes, we had a lot of mail files that were getting pushed over the one-section limit by spam storms, so Ralph eventually did the Right Thing(TM) to make MM a multi-section program. We never released it to the outside world for some reason, I think possibly a reliability concern. > I do, however, feel that as great as MM was for its time, that time has > passed. Thanks to MIME, MM has aged less well than the rest of TOPS-20. > IMHO, it would be much more interesting to port Alpine to TOPS-20. If GNU > Emacs can be ported to TOPS-20, then certainly Alpine can be. Along with GNU Emacs (and many other GNU tools), Dick Helliwell ported the X window system, and Perl 4. Well, that last was really first, as it was needed to do the other ports. Rich 2-Jan-2008 22:02:52-PST,2161;000000000000 Return-Path: Received: from pangtzu.panda.com ([206.124.149.117]) by Lingling.Panda.COM with TCP/SMTP; Wed, 2 Jan 2008 21:58:31 -0800 (PST) X-Return-Path: X-Received: from pangtzu.panda.com ([206.124.149.117]) by Lingling.Panda.COM with TCP/SMTP; Wed, 2 Jan 2008 21:53:05 -0800 (PST) Date: Wed, 2 Jan 2008 21:52:56 -0800 (PST) From: Mark Crispin Sender: mrc@pangtzu.panda.com To: Rich Alderson cc: TOPS-20@Lingling.Panda.COM Subject: Re: Section 0 word pointers from a non-zero section? In-Reply-To: <200801021858.m02IwtT09618@panix5.panix.com> Message-ID: References: <47798DE5.7070106@optonline.net> <477AB8DA.1000801@optonline.net> <200801021858.m02IwtT09618@panix5.panix.com> User-Agent: Alpine 1.00 (OSX 894 2008-01-03) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed ReSent-Date: Wed, 2 Jan 2008 21:58:22 -0800 (PST) ReSent-From: TOPS-20 List Moderator ReSent-To: TOPS-20 Distribution: ; ReSent-Subject: Re: Section 0 word pointers from a non-zero section? ReSent-Message-ID: ReSent-User-Agent: Alpine 1.00 (OSX 894 2008-01-03) On Wed, 2 Jan 2008, Rich Alderson wrote: >> Until about version 4 (or 5?), Columbia's EXEC still had an IDDT command that >> would splice IDDT in between the EXEC and a particular fork. I remember this >> working. Very useful. > Just out of curiosity, was this a command that moved IDDT into the process tree > between the EXEC and a pre-existing fork? (That would have been an interesting > hack to preserve!) Or did it simply start IDDT and point it at an .exe to map > in? If it was anything like the IDDT command in Tenex and early versions of Stanford's EXEC (release 1 days), it spliced in IDDT. -- Mark -- http://panda.com/tops-20 TOPS-20: a great improvement over its successors 3-Jan-2008 08:09:34-PST,2199;000000000000 Return-Path: Received: from pangtzu.panda.com ([206.124.149.117]) by Lingling.Panda.COM with TCP/SMTP; Thu, 3 Jan 2008 08:05:23 -0800 (PST) X-Return-Path: X-Received: from mta4.srv.hcvlny.cv.net ([167.206.4.199]) by Lingling.Panda.COM with TCP/SMTP; Thu, 3 Jan 2008 08:02:22 -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 <0JU200KAYSJQGP61@mta4.srv.hcvlny.cv.net>; Thu, 03 Jan 2008 11:02:15 -0500 (EST) Date: Thu, 03 Jan 2008 11:02:13 -0500 From: Thomas DeBellis Subject: Re: Section 0 word pointers from a non-zero section? In-reply-to: To: Mark Crispin Cc: Rich Alderson , TOPS-20@Lingling.Panda.COM Message-id: <477D0705.5060405@optonline.net> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en References: <47798DE5.7070106@optonline.net> <477AB8DA.1000801@optonline.net> <200801021858.m02IwtT09618@panix5.panix.com> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) ReSent-Date: Thu, 3 Jan 2008 08:05:15 -0800 (PST) ReSent-From: TOPS-20 List Moderator ReSent-To: TOPS-20 Distribution: ; ReSent-Subject: Re: Section 0 word pointers from a non-zero section? ReSent-Message-ID: ReSent-User-Agent: Alpine 1.00 (OSX 894 2008-01-03) It did the splice. Off and on, I have been trying to recover the sources to Columbia's EXEC and monitor (and other things) for years. Mark Crispin wrote: > If it was anything like the IDDT command in Tenex and early versions of > Stanford's EXEC (release 1 days), it spliced in IDDT. 6-Jan-2008 16:46:53-PST,4001;000000000000 Return-Path: Received: from pangtzu.panda.com ([206.124.149.117]) by Lingling.Panda.COM with TCP/SMTP; Sun, 6 Jan 2008 16:42:40 -0800 (PST) X-Return-Path: X-Received: from mta5.srv.hcvlny.cv.net ([167.206.4.200]) by Lingling.Panda.COM with TCP/SMTP; Sun, 6 Jan 2008 16:23:24 -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 <0JU800F4FZQT9NE0@mta5.srv.hcvlny.cv.net>; Sun, 06 Jan 2008 19:23:17 -0500 (EST) Date: Sun, 06 Jan 2008 19:23:15 -0500 From: Thomas DeBellis Subject: Tom's Magic Guard Page Algorythm (TM) In-reply-to: To: Mark Crispin Cc: Tops-20 Wizards Message-id: <478170F3.2090600@optonline.net> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en References: <47798DE5.7070106@optonline.net> <477AB8D6.9050303@optonline.net> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) ReSent-Date: Sun, 6 Jan 2008 16:42:31 -0800 (PST) ReSent-From: TOPS-20 List Moderator ReSent-To: TOPS-20 Distribution: ; ReSent-Subject: Tom's Magic Guard Page Algorythm (TM) ReSent-Message-ID: ReSent-User-Agent: Alpine 1.00 (OSX 894 2008-01-03) > What a hack! I just tried it and verified that it does, in fact, > work. PMAP is smart enough to check to see if there's a super-index > block for the page, but doesn't check if the file page itself has a > mapping. > > However, you're screwed if the filesize is a multiple of 512 pages. Actually, may I ask you to elaborate on this? What does happen and why? Have you verified) it (or could you/would you)? I'm up to about 244 pages in the executable, but I doubt that I'll go much higher than about 260 before the alpha candidate is ready. However ... Should I be doing something like a SIZEF% and then punting if the executable size is this magic number? > Using the running process's binary instead of a temporary file is > almost certainly your idea. Good. I thought of it because I wasn't sure that I'd always be able to create a temporary file (or do it the right way). Maybe I'll package the routine up in a friendly way for other people to use; sort of like what you did with GETCPU and HSTNAM. Guard pages are EXTREMELY useful things to have when doing development/debugging. That and unsolicited breakpoints. I plan on doing a similar sort of packaging with a nice set of macros that I consed up: the 'DCAM' group. If you're going to correctly handle time calculations, then you have to REALLY understand that the Tops-20 internal time format is an unsigned fixed point number, which means that standard CAM/CAI won't always work right. I got bitten by that when writing the crocktastic Unix directory listing code... Yech... So, no problem: you just cast the unsigned time to a signed long and everything works right: DMOVE, DADD, etc. Except ...no DCAM ... I kept getting confused enough about the comparisons that I finally wrote up a set of (what I thought were) intuitively named double compare macros: DCAME, DCAMG, etc. One wonders why these didn't get implemented as EXTENDed instructions. It seems like an obvious enough thing. Or maybe not. But I seem to remember the KL microcode space getting a little tight and some instructions getting removed; I guess that's probably a reasonable enough explanation. 6-Jan-2008 16:50:38-PST,1860;000000000000 Return-Path: Received: from pangtzu.panda.com ([206.124.149.117]) by Lingling.Panda.COM with TCP/SMTP; Sun, 6 Jan 2008 16:42:55 -0800 (PST) X-Return-Path: X-Received: from pangtzu.panda.com ([206.124.149.117]) by Lingling.Panda.COM with TCP/SMTP; Sun, 6 Jan 2008 16:42:34 -0800 (PST) Date: Sun, 6 Jan 2008 16:42:28 -0800 (PST) From: Mark Crispin Sender: mrc@pangtzu.panda.com To: Thomas DeBellis cc: Tops-20 Wizards Subject: Re: Tom's Magic Guard Page Algorythm (TM) In-Reply-To: <478170F3.2090600@optonline.net> Message-ID: References: <47798DE5.7070106@optonline.net> <477AB8D6.9050303@optonline.net> <478170F3.2090600@optonline.net> User-Agent: Alpine 1.00 (OSX 894 2008-01-03) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed ReSent-Date: Sun, 6 Jan 2008 16:42:48 -0800 (PST) ReSent-From: TOPS-20 List Moderator ReSent-To: TOPS-20 Distribution: ; ReSent-Subject: Re: Tom's Magic Guard Page Algorythm (TM) ReSent-Message-ID: ReSent-User-Agent: Alpine 1.00 (OSX 894 2008-01-03) On Sun, 6 Jan 2008, Thomas DeBellis wrote: > > However, you're screwed if the filesize is a multiple of 512 pages. > Actually, may I ask you to elaborate on this? What does happen and > why? The PMAP% will fail if you try to reference a page on in a superindex block that does not exist. -- Mark -- http://panda.com/tops-20 TOPS-20: a great improvement over its successors 12-Jan-2008 16:24:43-PST,2651;000000000000 Return-Path: Received: from pangtzu.panda.com ([206.124.149.117]) by Lingling.Panda.COM with TCP/SMTP; Sat, 12 Jan 2008 16:20:22 -0800 (PST) X-Return-Path: X-Received: from pangtzu.panda.com ([206.124.149.117]) by Lingling.Panda.COM with TCP/SMTP; Sat, 12 Jan 2008 16:17:15 -0800 (PST) Date: Sat, 12 Jan 2008 16:17:09 -0800 (PST) From: Mark Crispin Sender: mrc@pangtzu.panda.com To: TOPS-20 Hackers and Yackers Subject: BASIC-20 vs. DPB Message-ID: User-Agent: Alpine 1.00 (OSX 905 2008-01-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII ReSent-Date: Sat, 12 Jan 2008 16:20:13 -0800 (PST) ReSent-From: TOPS-20 List Moderator ReSent-To: TOPS-20 Distribution: ; ReSent-Subject: BASIC-20 vs. DPB ReSent-Message-ID: ReSent-User-Agent: Alpine 1.00 (OSX 905 2008-01-11) A problem with BASIC-20 got reported to me. An OLD command causes BASIC to snarl with ? ILLEGAL INSTRUCTION EXECUTED ? INTERNAL ERROR AT PC 15636 ? Proceed at your own risk... READY However, it seems that the requested program is loaded in spite of the error. An examination of that location shows that it's a DPB of a memory location that contains -1 in the left half. Testing shows that any DPB with bits 0-5 being 77 will cause an illegal instruction trap on both KLH10 and XKL-1 processors, in keeping with the statement on page 2-87 of the PRM: Giving a pointer with P or S greater than 36 produces an indeterminate result in any instruction that uses it. [...] Giving a one-word global pointer with a P&S number of 63 causes an instruction that uses it to be trapped as an MUUO. However, earlier n page 2-85, we see that "In section 0, the pointer is always of the above type -- local and one word -- and P must be <= 36". So, the question becomes if the trap or the "indeterminate result" applies in section 0. Next, I tried it on dec-10.pdpplanet.com which AFAIK is a real KL10 (but I don't know if it has TOPS-10 or TOPS-20 microcode). It too gave the same illegal instruction trap. Since a real KL does it, I guess that we can conclude that 77 in bits 0-5 gives an MUUO trap even in section 0. The question is, how did this bug in BASIC-20 go unnoticed? My guess is that model A KLs and KSs did not enforce this trap? -- Mark -- http://panda.com/tops-20 TOPS-20: a great improvement over its successors 13-Jan-2008 08:41:53-PST,4082;000000000000 Return-Path: Received: from pangtzu.panda.com ([206.124.149.117]) by Lingling.Panda.COM with TCP/SMTP; Sun, 13 Jan 2008 08:37:29 -0800 (PST) X-Return-Path: X-Received: from smtpoutm.mac.com ([17.148.16.82]) by Lingling.Panda.COM with TCP/SMTP; Sun, 13 Jan 2008 07:31:13 -0800 (PST) X-Received: from mac.com (asmtp009-s [10.150.69.72]) by smtpoutm.mac.com (Xserve/smtpout019/MantshX 4.0) with ESMTP id m0DFUxtl025834; Sun, 13 Jan 2008 07:31:00 -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/asmtp009/MantshX 4.0) with ESMTP id m0DFUubS005363; Sun, 13 Jan 2008 07:30:58 -0800 (PST) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v753) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <02BCD00D-E51B-491B-9930-5587DB5EF8AF@mac.com> Cc: TOPS-20 Hackers and Yackers Content-Transfer-Encoding: 7bit From: John Francini Subject: Re: BASIC-20 vs. DPB Date: Sun, 13 Jan 2008 10:31:17 -0500 To: Mark Crispin X-Mailer: Apple Mail (2.753) ReSent-Date: Sun, 13 Jan 2008 08:37:21 -0800 (PST) ReSent-From: TOPS-20 List Moderator ReSent-To: TOPS-20 Distribution: ; ReSent-Subject: Re: BASIC-20 vs. DPB ReSent-Message-ID: ReSent-User-Agent: Alpine 1.00 (OSX 905 2008-01-11) dec10.pdpplanet.com is a 2065 running 7.04A, which requires KL paging. From late 7.03 onward, the microcode load was the same on both TOPS-10 and TOPS-20. 7.03 was the first TOPS-10 monitor to support user-mode KL paging. 7.02 had KL-paging, but only for the Monitor. User mode programs were restricted to a single section. How long of a program do you need to generate the error? A simple program of the form 10 print "hello" 20 end does not generate it on dec10.pdpplanet.com. And, I presume, BASIC-20 is the same as BASIC-10, i.e., the same Dartmouth-based BASIC; not the same as Basic-Plus or any of the DEC- extended ones for other platforms? john On 12 Jan 2008, at 19:17, Mark Crispin wrote: > A problem with BASIC-20 got reported to me. An OLD command causes > BASIC to snarl with > > ? ILLEGAL INSTRUCTION EXECUTED > ? INTERNAL ERROR AT PC 15636 > ? Proceed at your own risk... > > READY > > However, it seems that the requested program is loaded in spite of > the error. > > An examination of that location shows that it's a DPB of a memory > location that contains -1 in the left half. Testing shows that any > DPB with bits 0-5 being 77 will cause an illegal instruction trap > on both KLH10 and XKL-1 processors, in keeping with the statement > on page 2-87 of the PRM: > Giving a pointer with P or S greater than 36 produces an > indeterminate result in any instruction that uses it. > [...] > Giving a one-word global pointer with a P&S number of 63 > causes an instruction that uses it to be trapped as an MUUO. > > However, earlier n page 2-85, we see that "In section 0, the > pointer is always of the above type -- local and one word -- and P > must be <= 36". So, the question becomes if the trap or the > "indeterminate result" applies in section 0. > > Next, I tried it on dec-10.pdpplanet.com which AFAIK is a real KL10 > (but I don't know if it has TOPS-10 or TOPS-20 microcode). It too > gave the same illegal instruction trap. > > Since a real KL does it, I guess that we can conclude that 77 in > bits 0-5 gives an MUUO trap even in section 0. The question is, > how did this bug in BASIC-20 go unnoticed? > > My guess is that model A KLs and KSs did not enforce this trap? > > -- Mark -- > > http://panda.com/tops-20 > TOPS-20: a great improvement over its successors > 13-Jan-2008 08:47:02-PST,2017;000000000000 Return-Path: Received: from pangtzu.panda.com ([206.124.149.117]) by Lingling.Panda.COM with TCP/SMTP; Sun, 13 Jan 2008 08:43:23 -0800 (PST) X-Return-Path: X-Received: from pangtzu.panda.com ([206.124.149.117]) by Lingling.Panda.COM with TCP/SMTP; Sun, 13 Jan 2008 08:40:03 -0800 (PST) Date: Sun, 13 Jan 2008 08:39:58 -0800 (PST) From: Mark Crispin Sender: mrc@pangtzu.panda.com To: John Francini cc: TOPS-20 Hackers and Yackers Subject: Re: BASIC-20 vs. DPB In-Reply-To: <02BCD00D-E51B-491B-9930-5587DB5EF8AF@mac.com> Message-ID: References: <02BCD00D-E51B-491B-9930-5587DB5EF8AF@mac.com> User-Agent: Alpine 1.00 (OSX 905 2008-01-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed ReSent-Date: Sun, 13 Jan 2008 08:43:15 -0800 (PST) ReSent-From: TOPS-20 List Moderator ReSent-To: TOPS-20 Distribution: ; ReSent-Subject: Re: BASIC-20 vs. DPB ReSent-Message-ID: ReSent-User-Agent: Alpine 1.00 (OSX 905 2008-01-11) On Sun, 13 Jan 2008, John Francini wrote: > How long of a program do you need to generate the error? A simple > program of the form > 10 print "hello" > 20 end > does not generate it on dec10.pdpplanet.com. That's because it doesn't have the same BASIC. xkleten.paulallen.com has the BASIC where you can reproduce the problem. > And, I presume, BASIC-20 is the same as BASIC-10, i.e., the same > Dartmouth-based BASIC; not the same as Basic-Plus or any of the DEC- > extended ones for other platforms? No, it's not the same. The BASIC that has the problems is version 2.1(320) and is native (JSYS not UUO) on TOPS-20. -- Mark -- http://panda.com/tops-20 TOPS-20: a great improvement over its successors 13-Jan-2008 11:24:43-PST,2660;000000000000 Return-Path: Received: from pangtzu.panda.com ([206.124.149.117]) by Lingling.Panda.COM with TCP/SMTP; Sun, 13 Jan 2008 11:20:28 -0800 (PST) X-Return-Path: X-Received: from smtpoutm.mac.com ([17.148.16.73]) by Lingling.Panda.COM with TCP/SMTP; Sun, 13 Jan 2008 11:08:34 -0800 (PST) X-Received: from mac.com (asmtp004-s [10.150.69.67]) by smtpoutm.mac.com (Xserve/smtpout010/MantshX 4.0) with ESMTP id m0DJ8PPm021888; Sun, 13 Jan 2008 11:08:25 -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/asmtp004/MantshX 4.0) with ESMTP id m0DJ8NN7007984; Sun, 13 Jan 2008 11:08:24 -0800 (PST) In-Reply-To: References: <02BCD00D-E51B-491B-9930-5587DB5EF8AF@mac.com> Mime-Version: 1.0 (Apple Message framework v753) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <56BD5294-B375-41F6-BAA3-D320FFEAF783@mac.com> Cc: TOPS-20 Hackers and Yackers Content-Transfer-Encoding: 7bit From: John Francini Subject: Re: BASIC-20 vs. DPB Date: Sun, 13 Jan 2008 14:08:39 -0500 To: Mark Crispin X-Mailer: Apple Mail (2.753) ReSent-Date: Sun, 13 Jan 2008 11:20:21 -0800 (PST) ReSent-From: TOPS-20 List Moderator ReSent-To: TOPS-20 Distribution: ; ReSent-Subject: Re: BASIC-20 vs. DPB ReSent-Message-ID: ReSent-User-Agent: Alpine 1.00 (OSX 905 2008-01-11) ah. I was confused then, because I thought you'd tried it on the DEC-10. j On 13 Jan 2008, at 11:39, Mark Crispin wrote: > On Sun, 13 Jan 2008, John Francini wrote: >> How long of a program do you need to generate the error? A simple >> program of the form >> 10 print "hello" >> 20 end >> does not generate it on dec10.pdpplanet.com. > > That's because it doesn't have the same BASIC. > xkleten.paulallen.com has the BASIC where you can reproduce the > problem. > >> And, I presume, BASIC-20 is the same as BASIC-10, i.e., the same >> Dartmouth-based BASIC; not the same as Basic-Plus or any of the DEC- >> extended ones for other platforms? > > No, it's not the same. The BASIC that has the problems is version > 2.1(320) and is native (JSYS not UUO) on TOPS-20. > > -- Mark -- > > http://panda.com/tops-20 > TOPS-20: a great improvement over its successors 13-Jan-2008 11:29:05-PST,1744;000000000000 Return-Path: Received: from pangtzu.panda.com ([206.124.149.117]) by Lingling.Panda.COM with TCP/SMTP; Sun, 13 Jan 2008 11:25:13 -0800 (PST) X-Return-Path: X-Received: from pangtzu.panda.com ([206.124.149.117]) by Lingling.Panda.COM with TCP/SMTP; Sun, 13 Jan 2008 11:21:19 -0800 (PST) Date: Sun, 13 Jan 2008 11:21:14 -0800 (PST) From: Mark Crispin Sender: mrc@pangtzu.panda.com To: John Francini cc: TOPS-20 Hackers and Yackers Subject: Re: BASIC-20 vs. DPB In-Reply-To: <56BD5294-B375-41F6-BAA3-D320FFEAF783@mac.com> Message-ID: References: <02BCD00D-E51B-491B-9930-5587DB5EF8AF@mac.com> <56BD5294-B375-41F6-BAA3-D320FFEAF783@mac.com> User-Agent: Alpine 1.00 (OSX 905 2008-01-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed ReSent-Date: Sun, 13 Jan 2008 11:25:06 -0800 (PST) ReSent-From: TOPS-20 List Moderator ReSent-To: TOPS-20 Distribution: ; ReSent-Subject: Re: BASIC-20 vs. DPB ReSent-Message-ID: ReSent-User-Agent: Alpine 1.00 (OSX 905 2008-01-11) On Sun, 13 Jan 2008, John Francini wrote: > ah. I was confused then, because I thought you'd tried it on the > DEC-10. Sorry that I was unclear. I tried the LDB on the -10 in DDT to get the same illegal instruction, but the BASIC test was only on the -20. -- Mark -- http://panda.com/tops-20 TOPS-20: a great improvement over its successors 13-Jan-2008 18:40:59-PST,2455;000000000000 Return-Path: Received: from pangtzu.panda.com ([206.124.149.117]) by Lingling.Panda.COM with TCP/SMTP; Sun, 13 Jan 2008 18:36:23 -0800 (PST) X-Return-Path: X-Received: from smtpoutm.mac.com ([17.148.16.71]) by Lingling.Panda.COM with TCP/SMTP; Sun, 13 Jan 2008 18:21:01 -0800 (PST) X-Received: from mac.com (asmtp005-s [10.150.69.68]) by smtpoutm.mac.com (Xserve/smtpout008/MantshX 4.0) with ESMTP id m0E2Kr7v023177; Sun, 13 Jan 2008 18:20:53 -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 m0E2Ko1m004798; Sun, 13 Jan 2008 18:20:51 -0800 (PST) In-Reply-To: References: <02BCD00D-E51B-491B-9930-5587DB5EF8AF@mac.com> <56BD5294-B375-41F6-BAA3-D320FFEAF783@mac.com> Mime-Version: 1.0 (Apple Message framework v753) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <34503FB6-AA11-4348-8A21-134AB692C35C@mac.com> Cc: TOPS-20 Hackers and Yackers Content-Transfer-Encoding: 7bit From: John Francini Subject: Re: BASIC-20 vs. DPB Date: Sun, 13 Jan 2008 21:21:12 -0500 To: Mark Crispin X-Mailer: Apple Mail (2.753) ReSent-Date: Sun, 13 Jan 2008 18:36:12 -0800 (PST) ReSent-From: TOPS-20 List Moderator ReSent-To: TOPS-20 Distribution: ; ReSent-Subject: Re: BASIC-20 vs. DPB ReSent-Message-ID: ReSent-User-Agent: Alpine 1.00 (OSX 905 2008-01-11) No problem. I had completely spaced the fact that DEC did indeed bring a more advanced BASIC to the 36-bit platform than the ancient clunker on TOPS-10. j On 13 Jan 2008, at 14:21, Mark Crispin wrote: > On Sun, 13 Jan 2008, John Francini wrote: >> ah. I was confused then, because I thought you'd tried it on the >> DEC-10. > > Sorry that I was unclear. I tried the LDB on the -10 in DDT to get > the same illegal instruction, but the BASIC test was only on the -20. > > -- Mark -- > > http://panda.com/tops-20 > TOPS-20: a great improvement over its successors 22-Jan-2008 21:11:27-PST,2278;000000000000 Return-Path: Received: from pangtzu.panda.com ([206.124.149.117]) by Lingling.Panda.COM with TCP/SMTP; Tue, 22 Jan 2008 21:06:24 -0800 (PST) X-Return-Path: X-Received: from mail1.acecape.com ([66.114.74.12]) by Lingling.Panda.COM with TCP/SMTP; Tue, 22 Jan 2008 17:11:53 -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 m0N1BkEi020398 for ; Tue, 22 Jan 2008 20:11:46 -0500 Message-ID: <47969450.5060702@acedsl.com> Date: Tue, 22 Jan 2008 20:11:44 -0500 From: Thomas DeBellis User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tops-20 Wizards Subject: SMAP% lossage? Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit ReSent-Date: Tue, 22 Jan 2008 21:06:14 -0800 (PST) ReSent-From: TOPS-20 List Moderator ReSent-To: TOPS-20 Distribution: ; ReSent-Subject: SMAP% lossage? ReSent-Message-ID: ReSent-User-Agent: Alpine 1.00 (OSX 916 2008-01-22) I just had an interesting experience while working on the extended mode FTP server paged file structure code. I had a file open for read-only with 2577 (octal) pages in it and performed the following actions: 1) SMAP% file section 1 (pages 0 to 777) to memory section 10 2) SMAP% file section 2 (pages 1000 to 1777) to memory section 10 3) SMAP% delete memory section 10 4) SMAP% create private memory section 10 5) PMAP% file pages 2000 to 2576 to memory section 10 6) PMAP% guard page to remaining pages in section 10 (10577 to 10777) 7) SMAP% file section 3 to memory section 10 (opps) The SMAP% failed with error LNGFX1,"Page table does not exist and file not open for write". So far, so good. However, when I exited the server into the EXEC (I was debugging), I got popped into the mini-exec and was logged out. I have done this several times and it is not repeatable. No errors were recorded on the CTY. Just lucky, I guess ... 22-Jan-2008 21:15:18-PST,2639;000000000000 Return-Path: Received: from pangtzu.panda.com ([206.124.149.117]) by Lingling.Panda.COM with TCP/SMTP; Tue, 22 Jan 2008 21:08:07 -0800 (PST) X-Return-Path: X-Received: from mail1.acecape.com ([66.114.74.12]) by Lingling.Panda.COM with TCP/SMTP; Tue, 22 Jan 2008 20:04:45 -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 m0N44aG4019577 for ; Tue, 22 Jan 2008 23:04:36 -0500 Message-ID: <4796BCD2.5070103@acedsl.com> Date: Tue, 22 Jan 2008 23:04:34 -0500 From: Thomas DeBellis User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tops-20 Wizards Subject: ILLX07, Pushdown list overflow? Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit ReSent-Date: Tue, 22 Jan 2008 21:07:12 -0800 (PST) ReSent-From: TOPS-20 List Moderator ReSent-To: TOPS-20 Distribution: ; ReSent-Subject: ILLX07, Pushdown list overflow? ReSent-Message-ID: ReSent-User-Agent: Alpine 1.00 (OSX 916 2008-01-22) I have a routine that (legitimately) puts a lot of stuff on the stack. But I called it twice without releasing the intervening stack space and dutifully got myself a stack overflow. My stack handler caught it, but I got an interesting result when I did a GETER% later in the post processing code: .ERR (1405,LSTRX1,) Oh? Really? I set up a test case where I do an ERJMPR after a stack instruction. Same deal, AC1 gets 601405. How about that? I thought there was some error number for this... After all, Consider the following: .ERR (770,ILINS1,) .ERR (1774,ILLX01,) .ERR (1775,ILLX02,) .ERR (1776,ILLX03,) .ERR (1777,ILLX04,) .ERR (2471,ILLX05,) I was thinking that perhaps the following might make sense: .ERR (,ILLX06,) .ERR (,ILLX07,) .ERR (,ILLX08,) Or maybe that would be taking it too far: arithmetic overflows, etc., etc., etc. On the other hand, if you do an ERJMPR after a failing instruction, getting an 601405 in AC1 seems counter-intuitive ... 23-Jan-2008 20:40:28-PST,5125;000000000000 Return-Path: Received: from pangtzu.panda.com ([206.124.149.117]) by Lingling.Panda.COM with TCP/SMTP; Wed, 23 Jan 2008 20:33:29 -0800 (PST) X-Return-Path: X-Received: from mail.math.utah.edu ([155.101.98.135]) by Lingling.Panda.COM with TCP/SMTP; Wed, 23 Jan 2008 14:56:36 -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 m0NMuS5I022178; Wed, 23 Jan 2008 15:56:28 -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 m0NMuSsh000593; Wed, 23 Jan 2008 15:56:28 -0700 (MST) X-Received: (from beebe@localhost) by psi.math.utah.edu (8.13.6/8.13.6/Submit) id m0NMuSMx000591; Wed, 23 Jan 2008 15:56:28 -0700 (MST) Date: Wed, 23 Jan 2008 15:56:28 -0700 (MST) From: "Nelson H. F. Beebe" To: Tops-20 Wizards Cc: beebe@math.utah.edu X-US-Mail: "Department of Mathematics, 110 LCB, University of Utah, 155 S 1400 E RM 233, Salt Lake City, UT 84112-0090, USA" X-Telephone: +1 801 581 5254 X-FAX: +1 801 585 1640, +1 801 581 4148 X-URL: http://www.math.utah.edu/~beebe Subject: [tops-20] comments on cc, mic/exec, and load library order Message-ID: X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0 (mail.math.utah.edu [155.101.98.135]); Wed, 23 Jan 2008 15:56:28 -0700 (MST) ReSent-Date: Wed, 23 Jan 2008 20:33:21 -0800 (PST) ReSent-From: TOPS-20 List Moderator ReSent-To: TOPS-20 Distribution: ; ReSent-Subject: [tops-20] comments on cc, mic/exec, and load library order ReSent-Message-ID: ReSent-User-Agent: Alpine 1.00 (OSX 917 2008-01-23) I have been doing more testing of C code on TOPS-20 with cc (kcc 6.620(c2l3)) @info version Panda Distribution, PANDA TOPS-20 Monitor 7.1(21733)-4 PANDA TOPS-20 Command processor 7.1(4453)-4 @vdir sys:cc.exe TOPS20: CC.EXE.1;P777752 237 485376(9) 14-Jun-96 09:39:38 MRC and hit a problem that can be exhibited with a one-line file: @type tiny.c float tiny = 1.0e-40; @cc -c tiny.c KCC: TINY "tiny.c", line 1: [Error] Floating constant underflow (p.1 l.1): float tiny = 1.0e-40; ?KCC - 1 error detected Treating a source underflow as a fatal error is decidely antisocial; no other compiler of dozens that I've used on other systems does so. A warning would be acceptable, but not an error. I've installed a workaround in my code for this, but it is nevertheless a nuisance. Every occurrence of such constants in my programs is as members of series with decreasing coefficients, so setting an underflowed constant to zero is completely harmless. Here is what my workaround looks like: static const fp_t C[] = { /* sum(k) C[k] = ln(2) */ #define D_ FP(1099511627776.0) /* 0 */ FP(762123384786.) / (D_), /* 1 */ FP(-208412096028.) / (D_ * D_), /* 2 */ FP(-328162086153.) / (D_ * D_ * D_), /* 3 */ FP(-346802666714.) / (D_ * D_ * D_ * D_), #if defined(HAVE_BROKEN_CONSTANT_UNDERFLOW) /* 4 */ FP(0.0) #else /* 4 */ FP(3.0628956078578292712021547409737854e-49) #endif #undef D_ }; When I build my library, I have a .mic file that appends the .rel files in the required topological order, and then runs maklib, but usually fails before the maklib step is reached: @do bldlib.mic .... @append a.rel, b.rel, c.rel lib.tmp ?String space exhausted By experiment, I found that if I logout and login again, I can successfully run the library build ONCE without getting the string-space-exhausted error, but if I do so again in the same login session, then I can reproduce the failure every time. Is there hope that this memory leakage (in the EXEC, I suspect) is repairable? I currently generate the bldmic.mic file on a Unix system from a tool that I wrote to figure out the hierarchical order of the functions, and then issue the file names in a series of append commands as sketched above. Does anyone know of a TOPS-20 tool that would make library building as easy as it is on Unix systems, where two simple commands do the job: % ar r lib.a *.o % ranlib lib.a || true [The "|| true" step handles those Unix systems that lack ranlib, putting its functionality into the ar utility instead.] ------------------------------------------------------------------------------- - Nelson H. F. Beebe Tel: +1 801 581 5254 - - University of Utah FAX: +1 801 581 4148 - - Department of Mathematics, 110 LCB Internet e-mail: beebe@math.utah.edu - - 155 S 1400 E RM 233 beebe@acm.org beebe@computer.org - - Salt Lake City, UT 84112-0090, USA URL: http://www.math.utah.edu/~beebe/ - ------------------------------------------------------------------------------- 3-Feb-2008 09:34:32-PST,2926;000000000000 Return-Path: Received: from pangtzu.panda.com ([206.124.149.117]) by Lingling.Panda.COM with TCP/SMTP; Sun, 3 Feb 2008 09:30:27 -0800 (PST) X-Return-Path: X-Received: from mail1.acecape.com ([66.114.74.12]) by Lingling.Panda.COM with TCP/SMTP; Sun, 3 Feb 2008 08:58: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 m13GwR9U021674 for ; Sun, 3 Feb 2008 11:58:28 -0500 Message-ID: <47A5F2B2.3020104@acedsl.com> Date: Sun, 03 Feb 2008 11:58:26 -0500 From: Thomas DeBellis User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tops-20 Wizards Subject: Symbol tables loss(age)? Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit ReSent-Date: Sun, 3 Feb 2008 09:30:18 -0800 (PST) ReSent-From: TOPS-20 List Moderator ReSent-To: TOPS-20 Distribution: ; ReSent-Subject: Symbol tables loss(age)? ReSent-Message-ID: ReSent-User-Agent: Alpine 1.00 (OSX 922 2008-02-01) Has anybody experienced the case of a symbol table 'partially' disappearing during a debugging session? Many times while I am debugging, DDT stops displaying symbols that it had been perfectly happy to show only moments before. It typically happens while I am stepping over a sub-routine call, but it can also happen when proceeding from a breakppint ($P) or even a GO ($G), although this is less frequent. For example: CALL FOO$X to step into a routine works and the symbols don't go away. However, if I do a CALL FOO$$X to step over the sub- routine, then routine names start disappering. In the example above, the call to FOO might now be displayed as something like CALL 54443 or CALL BAR##+223. DDT still clearly knows about FOO because if I single step into it, once I am physically in the routine, the correct routine name and offsets are displayed. I've tried a couple of things: putting the symbol table in the same section as DDT, having DDT and the symbol table be in the same section as the program. Having them all be separate. Lots of combinations and some things that I saw in other programs, such as setting the entry vector (XSVEC%), blah, blah. Any ideas? Anything I can try? One note: EFTPSR nearly always invokes DDT via an unsolicited breakpoint. I have a SITE local DDT command which maps XDDT into the program, gets the DDT unsolicted breakpoint location via PDVOP% and JSR'ing to the breakpoint. Works fine. It's getting annoying enough that I'm thinking about linking in RDDT, but that has its own problems that I might need to address. 9-Feb-2008 21:29:10-PST,2434;000000000000 Return-Path: Received: from pangtzu.panda.com ([206.124.149.117]) by Lingling.Panda.COM with TCP/SMTP; Sat, 9 Feb 2008 21:24:27 -0800 (PST) X-Return-Path: X-Received: from mail1.acecape.com ([66.114.74.12]) by Lingling.Panda.COM with TCP/SMTP; Sat, 9 Feb 2008 18:38:31 -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 m1A2cOTD021238; Sat, 9 Feb 2008 21:38:24 -0500 Message-ID: <47AE639F.6050805@acedsl.com> Date: Sat, 09 Feb 2008 21:38:23 -0500 From: Thomas DeBellis User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ralph Gorin CC: Tops-20 Wizards Subject: Re: Symbol tables loss(age)? References: <47A5F2B2.3020104@acedsl.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit ReSent-Date: Sat, 9 Feb 2008 21:24:16 -0800 (PST) ReSent-From: TOPS-20 List Moderator ReSent-To: TOPS-20 Distribution: ; ReSent-Subject: Re: Symbol tables loss(age)? ReSent-Message-ID: ReSent-User-Agent: Alpine 1.00 (OSX 929 2008-02-08) I lose display of the symbols, but DDT still knows about them. Although routine FOO does not display in the call, once I'm it in FOO, I get symbols offset from FOO. The FOO symbol never disappears, I can always reference. It just doesn't display consistently. Perhaps my wording for the symbol table was unfortunate? I believe I was thinking that somehow the suppress bit for symbol FOO was getting tweaked. Come to think of it, I write protect the symbol table when I start up so that DDT (and runaway subroutines) would have to work harder to smash it. But how to de-confuse DDT? It typically happens after I $$X something. Ralph Gorin wrote: > Does the symbol table problem affect more than > DDT's display of the instruction (and arguments) > while you are single-stepping? > > I've always thought this more a confusion by DDT > of what typeout mode it's in rather than a symbol > table issue. > > Ralph > > 9-Feb-2008 21:33:12-PST,2975;000000000000 Return-Path: Received: from pangtzu.panda.com ([206.124.149.117]) by Lingling.Panda.COM with TCP/SMTP; Sat, 9 Feb 2008 21:25:03 -0800 (PST) X-Return-Path: X-Received: from mail1.acecape.com ([66.114.74.12]) by Lingling.Panda.COM with TCP/SMTP; Sat, 9 Feb 2008 21:11:04 -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 m1A5Ataj029154 for ; Sun, 10 Feb 2008 00:10:55 -0500 Message-ID: <47AE875E.5050402@acedsl.com> Date: Sun, 10 Feb 2008 00:10:54 -0500 From: Thomas DeBellis User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tops-20 Wizards Subject: Guard Pages, Part 2 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit ReSent-Date: Sat, 9 Feb 2008 21:24:43 -0800 (PST) ReSent-From: TOPS-20 List Moderator ReSent-To: TOPS-20 Distribution: ; ReSent-Subject: Guard Pages, Part 2 ReSent-Message-ID: ReSent-User-Agent: Alpine 1.00 (OSX 929 2008-02-08) For what it's worth, I thought that it was interesting that SMAP% and PMAP% return some different things when mapping past the end of file and that this information extends to what you're told by XRMAP%. The following is a file that I'm using to test retrieves using paged (!) file structures EFTPSR.LST.5;P777700 1425 729213(36) 8-Feb-2008 23:34:00 SLOGIN When running with full section buffers, I use an SMAP% to pull the file in. When setting the mapping at the section level, non-existant pages after the end of file are correctly marked in the page map. Here is an example of the last SMAP% of the above file: Section 10 R, E, special mapping 10000-10620 EFTPSR.LST.5 2000-2620 R, E In this case, it's clear that there is nothing after file page 2620 in this section. However, if I cut my buffer size down to 100 pages, I get different results. Here is the final map from the file: Section 10 R, W, E, Private 10000-10143 EFTPSR.LST.5 2570-2733 R, E 10144-10777 Fork 2 3310 R, E Section 10 is now private and file pages have been specifically mapped in with PMAP%. The remaining pages in the section are mapped to the guard page, which is in the superior (control) fork. If I use XRMAP% to look at (octal) memory page 10031, I find that it says that (octal) file page 2621 is mapped in there. And the access bits are 130000,,0, which means that RM%RD (read access allowed), RM%EX (execute access allowed) and RM%PEX (page exists) are set. But 2621 doesn't exist, so if you happen to have the file opened for read and PMAP%ed for read and try to read it ... 12-Feb-2008 20:22:33-PST,3109;000000000000 Return-Path: Received: from pangtzu.panda.com ([206.124.149.117]) by Lingling.Panda.COM with TCP/SMTP; Tue, 12 Feb 2008 20:18:16 -0800 (PST) X-Return-Path: X-Received: from mail1.acecape.com ([66.114.74.12]) by Lingling.Panda.COM with TCP/SMTP; Tue, 12 Feb 2008 08:15:14 -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 m1CGF5Vi001200 for ; Tue, 12 Feb 2008 11:15:06 -0500 Message-ID: <47B1C61A.4080109@acedsl.com> Date: Tue, 12 Feb 2008 11:15:22 -0500 From: Thomas DeBellis User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tops-20 Wizards Subject: PIOVFW BUGHLT Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit ReSent-Date: Tue, 12 Feb 2008 20:18:09 -0800 (PST) ReSent-From: TOPS-20 List Moderator ReSent-To: TOPS-20 Distribution: ; ReSent-Subject: PIOVFW BUGHLT ReSent-Message-ID: ReSent-User-Agent: Alpine 1.00 (OSX 929 2008-02-08) I just crashed with a PIOVFW BUGHLT. From looking at PSISM in SCHED.MAC, it would appear that this is basically a stack overflow that happens when you are trying to break out of a monitor call to handle a software PSI. You need to save monitor context and if you run out of space while doing that, then you get a PIOVFW. Unfortunately the BUGHLT is jumped to by a number of places in PSISM, so it wasn't clear to me how to back out of it. One thing that came to mind was to simply clobber the fork in question instead gronking the entire system. But I can see that would be Bad in a number of cases. As to what I was doing at the time of the crash: I was testing an RFC959 paged file structure retrieve (!) and was really beating on it (1,425 page file). I was verifying my buffer logic by running section based buffers, tinsy winsy 2 page buffers and buffer sizes in between. Running buffers that small (2 pages) causes a LOT of JSYS overhead. For instance: I spend a lot of time PMAP%ing guard pages to the end of the buffers. To offset the extra load that this puts on the machine, I also had throttling turned on, waiting about 400 milliseconds between SOUT% calls to the network (being simulated with NUL:). EFTPSR will respond to a TELNET "Are you there" query, but this is bound to ^Y during debugging. I was doing a lot of ^Y and ^T to look at some information and SYSDPY'ing the job to monitor some other things. After my second or third try at this, I crashed. Would increasing the size of the stack fix the problem? Or is this a legitmate error indicating a problem elsewhere? As I said, I *was* beating on things: I had the system load all the way up to 3 (which is a bit unusual in these post modern times). However, I had been up since July 5th ... 12-Feb-2008 20:26:14-PST,2624;000000000000 Return-Path: Received: from pangtzu.panda.com ([206.124.149.117]) by Lingling.Panda.COM with TCP/SMTP; Tue, 12 Feb 2008 20:18:29 -0800 (PST) X-Return-Path: X-Received: from mail1.acecape.com ([66.114.74.12]) by Lingling.Panda.COM with TCP/SMTP; Tue, 12 Feb 2008 08:31: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 m1CGVRoR016367 for ; Tue, 12 Feb 2008 11:31:27 -0500 Message-ID: <47B1C9EF.3090402@acedsl.com> Date: Tue, 12 Feb 2008 11:31:43 -0500 From: Thomas DeBellis User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tops-20 Wizards Subject: Fixing LAT the old fashioned way Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit ReSent-Date: Tue, 12 Feb 2008 20:18:21 -0800 (PST) ReSent-From: TOPS-20 List Moderator ReSent-To: TOPS-20 Distribution: ; ReSent-Subject: Fixing LAT the old fashioned way ReSent-Message-ID: ReSent-User-Agent: Alpine 1.00 (OSX 929 2008-02-08) One small benefit of my recent crash has been to enable me to get a bit more information on a LAT problem that I had noticed. As will be remembered, I finally got Tops-20 LAT working and was happily using it. That is, right up until I had to do quarterly backups. Every 90 days, a batch job kicks off that sends me e-mail with directions, pages me and then requests a scratch tape mount. I ^-\ KLH10 and dutifully do the devmount of a .TAP file on a RAID. Then I do an IDENTIFY with OPR which hands the tape over to the batch job. After about a half an hour, the batch job is complete and I do the devunmount, bzip2 the .TAP file and take it offline (I.E., burn it to a CD-ROM). LAT stopped working when I stopped the micro-engine. Everything else works, but LAT never works again. Even if you do lots of things in LCP submode (or get real desperate and turn the NI on and off), it won't come back. I started looking at things with Ethereal, but I put that aside to concentrate on the FTP server. Since the reboot, however, it is working like a charm. But for anybody playing with LAT, that's something that you should keep in mind: stopping KLH10 will break it. Maybe I'll look at this further once I get the FTP extended mode alpha candidate out. 12-Feb-2008 20:42:23-PST,1566;000000000000 Return-Path: Received: from pangtzu.panda.com ([206.124.149.117]) by Lingling.Panda.COM with TCP/SMTP; Tue, 12 Feb 2008 20:38:22 -0800 (PST) X-Return-Path: X-Received: from pangtzu.panda.com ([206.124.149.117]) by Lingling.Panda.COM with TCP/SMTP; Tue, 12 Feb 2008 20:34:56 -0800 (PST) Date: Tue, 12 Feb 2008 20:34:51 -0800 (PST) From: Mark Crispin Sender: mrc@pangtzu.panda.com To: Thomas DeBellis cc: Tops-20 Wizards Subject: Re: PIOVFW BUGHLT In-Reply-To: <47B1C61A.4080109@acedsl.com> Message-ID: References: <47B1C61A.4080109@acedsl.com> User-Agent: Alpine 1.00 (OSX 929 2008-02-08) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed ReSent-Date: Tue, 12 Feb 2008 20:38:15 -0800 (PST) ReSent-From: TOPS-20 List Moderator ReSent-To: TOPS-20 Distribution: ; ReSent-Subject: Re: PIOVFW BUGHLT ReSent-Message-ID: ReSent-User-Agent: Alpine 1.00 (OSX 929 2008-02-08) On Tue, 12 Feb 2008, Thomas DeBellis wrote: > I just crashed with a PIOVFW BUGHLT. I think that I fixed this last April. In STG.MAC, NPSIPG should be 3 instead of 2. I forget if it was due to DEC or Panda changes, but the stack wasn't large enough to handle nested PSIs, just by a hair. -- Mark -- http://panda.com/tops-20 TOPS-20: a great improvement over its successors 12-Feb-2008 21:45:47-PST,1860;000000000000 Return-Path: Received: from pangtzu.panda.com ([206.124.149.117]) by Lingling.Panda.COM with TCP/SMTP; Tue, 12 Feb 2008 21:41:40 -0800 (PST) X-Return-Path: X-Received: from pangtzu.panda.com ([206.124.149.117]) by Lingling.Panda.COM with TCP/SMTP; Tue, 12 Feb 2008 20:38:24 -0800 (PST) Date: Tue, 12 Feb 2008 20:38:19 -0800 (PST) From: Mark Crispin Sender: mrc@pangtzu.panda.com To: Thomas DeBellis cc: Tops-20 Wizards Subject: Re: Fixing LAT the old fashioned way In-Reply-To: <47B1C9EF.3090402@acedsl.com> Message-ID: References: <47B1C9EF.3090402@acedsl.com> User-Agent: Alpine 1.00 (OSX 929 2008-02-08) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed ReSent-Date: Tue, 12 Feb 2008 21:41:33 -0800 (PST) ReSent-From: TOPS-20 List Moderator ReSent-To: TOPS-20 Distribution: ; ReSent-Subject: Re: Fixing LAT the old fashioned way ReSent-Message-ID: ReSent-User-Agent: Alpine 1.00 (OSX 929 2008-02-08) On Tue, 12 Feb 2008, Thomas DeBellis wrote: > LAT stopped working when I stopped the micro-engine. You can prevent the micro-engine from stopping when you CTRL-\ to mount a tape by adding the command "set fe_runnable=1" in your klt20.ini file. This more closely approximates the behavior of a real KL. A side effect of this is that the HALT console command actually does something useful. That command is now standard in the Panda distribution, although I don't know if that change made it into the panda.trailing-edge.com distribution. -- Mark -- http://panda.com/tops-20 TOPS-20: a great improvement over its successors 13-Feb-2008 18:34:06-PST,2405;000000000000 Return-Path: Received: from pangtzu.panda.com ([206.124.149.117]) by Lingling.Panda.COM with TCP/SMTP; Wed, 13 Feb 2008 18:29:45 -0800 (PST) X-Return-Path: X-Received: from mail3.panix.com ([166.84.1.74]) by Lingling.Panda.COM with TCP/SMTP; Wed, 13 Feb 2008 17:16:44 -0800 (PST) X-Received: from panix5.panix.com (panix5.panix.com [166.84.1.5]) by mail3.panix.com (Postfix) with ESMTP id 1140913A79B for ; Wed, 13 Feb 2008 20:16:38 -0500 (EST) X-Received: (from alderson@localhost) by panix5.panix.com (8.11.6p3/8.8.8/PanixN1.1) id m1E1Gbg29468; Wed, 13 Feb 2008 20:16:37 -0500 (EST) Date: Wed, 13 Feb 2008 20:16:37 -0500 (EST) Message-Id: <200802140116.m1E1Gbg29468@panix5.panix.com> From: Rich Alderson To: TOPS-20@lingling.panda.com In-reply-to: (message from Mark Crispin on Tue, 12 Feb 2008 20:38:19 -0800 (PST)) Subject: Re: Fixing LAT the old fashioned way References: <47B1C9EF.3090402@acedsl.com> ReSent-Date: Wed, 13 Feb 2008 18:29:36 -0800 (PST) ReSent-From: TOPS-20 List Moderator ReSent-To: TOPS-20 Distribution: ; ReSent-Subject: Re: Fixing LAT the old fashioned way ReSent-Message-ID: ReSent-User-Agent: Alpine 1.00 (OSX 929 2008-02-08) > Date: Tue, 12 Feb 2008 20:38:19 -0800 (PST) > From: Mark Crispin > On Tue, 12 Feb 2008, Thomas DeBellis wrote: >> LAT stopped working when I stopped the micro-engine. > You can prevent the micro-engine from stopping when you CTRL-\ to mount a > tape by adding the command "set fe_runnable=1" in your klt20.ini file. > This more closely approximates the behavior of a real KL. A side effect > of this is that the HALT console command actually does something useful. > That command is now standard in the Panda distribution, although I don't > know if that change made it into the panda.trailing-edge.com distribution. I happen to have a copy of the trailing-edge distribution. The command is present in files that were last changed in 2002, so everyone should have access to it. Rich 13-Feb-2008 21:46:27-PST,2110;000000000000 Return-Path: Received: from pangtzu.panda.com ([206.124.149.117]) by Lingling.Panda.COM with TCP/SMTP; Wed, 13 Feb 2008 21:41:55 -0800 (PST) X-Return-Path: X-Received: from pangtzu.panda.com ([206.124.149.117]) by Lingling.Panda.COM with TCP/SMTP; Wed, 13 Feb 2008 21:38:23 -0800 (PST) Date: Wed, 13 Feb 2008 21:38:18 -0800 (PST) From: Mark Crispin Sender: mrc@pangtzu.panda.com To: Rich Alderson cc: TOPS-20@lingling.panda.com Subject: Re: Fixing LAT the old fashioned way In-Reply-To: <200802140116.m1E1Gbg29468@panix5.panix.com> Message-ID: References: <47B1C9EF.3090402@acedsl.com> <200802140116.m1E1Gbg29468@panix5.panix.com> User-Agent: Alpine 1.00 (OSX 929 2008-02-08) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII ReSent-Date: Wed, 13 Feb 2008 21:41:47 -0800 (PST) ReSent-From: TOPS-20 List Moderator ReSent-To: TOPS-20 Distribution: ; ReSent-Subject: Re: Fixing LAT the old fashioned way ReSent-Message-ID: ReSent-User-Agent: Alpine 1.00 (OSX 929 2008-02-08) On Wed, 13 Feb 2008, Rich Alderson wrote: >> That command is now standard in the Panda distribution, although I don't >> know if that change made it into the panda.trailing-edge.com distribution. > I happen to have a copy of the trailing-edge distribution. The command is > present in files that were last changed in 2002, so everyone should have > access to it. You misunderstood me. Modern versions of the Panda distribution now have a "set fe_runnable=1" line in the klt20.ini file. Earlier versions do not. I forget whether the trailing-edge snapshot is before or after that; I think that it is before. I will probably send trailing-edge an update sometime this year. -- Mark -- http://panda.com/tops-20 TOPS-20: a great improvement over its successors 13-Feb-2008 22:08:33-PST,2110;000000000000 Return-Path: Received: from pangtzu.panda.com ([206.124.149.117]) by Lingling.Panda.COM with TCP/SMTP; Wed, 13 Feb 2008 22:04:49 -0800 (PST) X-Return-Path: X-Received: from pangtzu.panda.com ([206.124.149.117]) by Lingling.Panda.COM with TCP/SMTP; Wed, 13 Feb 2008 21:38:23 -0800 (PST) Date: Wed, 13 Feb 2008 21:38:18 -0800 (PST) From: Mark Crispin Sender: mrc@pangtzu.panda.com To: Rich Alderson cc: TOPS-20@lingling.panda.com Subject: Re: Fixing LAT the old fashioned way In-Reply-To: <200802140116.m1E1Gbg29468@panix5.panix.com> Message-ID: References: <47B1C9EF.3090402@acedsl.com> <200802140116.m1E1Gbg29468@panix5.panix.com> User-Agent: Alpine 1.00 (OSX 929 2008-02-08) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII ReSent-Date: Wed, 13 Feb 2008 22:04:38 -0800 (PST) ReSent-From: TOPS-20 List Moderator ReSent-To: TOPS-20 Distribution: ; ReSent-Subject: Re: Fixing LAT the old fashioned way ReSent-Message-ID: ReSent-User-Agent: Alpine 1.00 (OSX 929 2008-02-08) On Wed, 13 Feb 2008, Rich Alderson wrote: >> That command is now standard in the Panda distribution, although I don't >> know if that change made it into the panda.trailing-edge.com distribution. > I happen to have a copy of the trailing-edge distribution. The command is > present in files that were last changed in 2002, so everyone should have > access to it. You misunderstood me. Modern versions of the Panda distribution now have a "set fe_runnable=1" line in the klt20.ini file. Earlier versions do not. I forget whether the trailing-edge snapshot is before or after that; I think that it is before. I will probably send trailing-edge an update sometime this year. -- Mark -- http://panda.com/tops-20 TOPS-20: a great improvement over its successors 14-Feb-2008 11:26:31-PST,2863;000000000000 Return-Path: Received: from pangtzu.panda.com ([206.124.149.117]) by Lingling.Panda.COM with TCP/SMTP; Thu, 14 Feb 2008 11:22:11 -0800 (PST) X-Return-Path: X-Received: from mail3.panix.com ([166.84.1.74]) by Lingling.Panda.COM with TCP/SMTP; Thu, 14 Feb 2008 10:45:50 -0800 (PST) X-Received: from panix5.panix.com (panix5.panix.com [166.84.1.5]) by mail3.panix.com (Postfix) with ESMTP id DD71713A8A8; Thu, 14 Feb 2008 13:45:43 -0500 (EST) X-Received: (from alderson@localhost) by panix5.panix.com (8.11.6p3/8.8.8/PanixN1.1) id m1EIjhV03054; Thu, 14 Feb 2008 13:45:43 -0500 (EST) Date: Thu, 14 Feb 2008 13:45:43 -0500 (EST) Message-Id: <200802141845.m1EIjhV03054@panix5.panix.com> From: Rich Alderson To: Mark Crispin CC: tops-20@alderson.users.panix.com, TOPS-20@lingling.panda.com In-reply-to: (message from Mark Crispin on Wed, 13 Feb 2008 21:38:18 -0800 (PST)) Subject: Re: Fixing LAT the old fashioned way References: <47B1C9EF.3090402@acedsl.com> <200802140116.m1E1Gbg29468@panix5.panix.com> ReSent-Date: Thu, 14 Feb 2008 11:21:48 -0800 (PST) ReSent-From: TOPS-20 List Moderator ReSent-To: TOPS-20 Distribution: ; ReSent-Subject: Re: Fixing LAT the old fashioned way ReSent-Message-ID: ReSent-User-Agent: Alpine 1.00 (OSX 929 2008-02-08) > Date: Wed, 13 Feb 2008 21:38:18 -0800 (PST) > From: Mark Crispin > On Wed, 13 Feb 2008, Rich Alderson wrote: >>> That command is now standard in the Panda distribution, although I don't >>> know if that change made it into the panda.trailing-edge.com distribution. >> I happen to have a copy of the trailing-edge distribution. The command is >> present in files that were last changed in 2002, so everyone should have >> access to it. > You misunderstood me. Modern versions of the Panda distribution now have > a "set fe_runnable=1" line in the klt20.ini file. Earlier versions do > not. I forget whether the trailing-edge snapshot is before or after that; > I think that it is before. You're right, I did misunderstand. The trailing-edge snapshot does *not* include the command in its klt20.ini. > I will probably send trailing-edge an update sometime this year. More substantively, is there any reason not to make the default behaviour of KLH10 match that of a KL-10 or an XKL-1 in this regard? Is the KS-10 different in this regard, in which case this could be conditionalized? Rich 14-Feb-2008 12:00:21-PST,2077;000000000000 Return-Path: Received: from pangtzu.panda.com ([206.124.149.117]) by Lingling.Panda.COM with TCP/SMTP; Thu, 14 Feb 2008 11:56:30 -0800 (PST) X-Return-Path: X-Received: from pangtzu.panda.com ([206.124.149.117]) by Lingling.Panda.COM with TCP/SMTP; Thu, 14 Feb 2008 11:56:08 -0800 (PST) Date: Thu, 14 Feb 2008 11:56:02 -0800 (PST) From: Mark Crispin Sender: mrc@pangtzu.panda.com To: Rich Alderson cc: TOPS-20@lingling.panda.com Subject: Re: Fixing LAT the old fashioned way In-Reply-To: <200802141845.m1EIjhV03054@panix5.panix.com> Message-ID: References: <47B1C9EF.3090402@acedsl.com> <200802140116.m1E1Gbg29468@panix5.panix.com> <200802141845.m1EIjhV03054@panix5.panix.com> User-Agent: Alpine 1.00 (OSX 929 2008-02-08) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII ReSent-Date: Thu, 14 Feb 2008 11:56:21 -0800 (PST) ReSent-From: TOPS-20 List Moderator ReSent-To: TOPS-20 Distribution: ; ReSent-Subject: Re: Fixing LAT the old fashioned way ReSent-Message-ID: ReSent-User-Agent: Alpine 1.00 (OSX 929 2008-02-08) On Thu, 14 Feb 2008, Rich Alderson wrote: > More substantively, is there any reason not to make the default behaviour of > KLH10 match that of a KL-10 or an XKL-1 in this regard? Is the KS-10 different > in this regard, in which case this could be conditionalized? I imagine that it's more difficult to debug the klh10 program itself when it is enabled. Nonetheless, I agree that it should be the default for any production system, and that is why it is now so in the Panda distribution. It will be in trailing-edge's copy when I next update it. -- Mark -- http://panda.com/tops-20 TOPS-20: a great improvement over its successors 15-Feb-2008 20:44:42-PST,2435;000000000000 Return-Path: Received: from pangtzu.panda.com ([206.124.149.117]) by Lingling.Panda.COM with TCP/SMTP; Fri, 15 Feb 2008 20:39:49 -0800 (PST) X-Return-Path: X-Received: from mta1.srv.hcvlny.cv.net ([167.206.4.196]) by Lingling.Panda.COM with TCP/SMTP; Fri, 15 Feb 2008 16:06:28 -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 <0JWB00JER1M3EO40@mta1.srv.hcvlny.cv.net>; Fri, 15 Feb 2008 19:06:04 -0500 (EST) Date: Fri, 15 Feb 2008 19:06:02 -0500 From: Thomas DeBellis Subject: Re: Fixing LAT the old fashioned way In-reply-to: To: Mark Crispin Cc: Tops-20 Wizards Message-id: <47B628EA.1090606@optonline.net> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en References: <47B1C9EF.3090402@acedsl.com> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) ReSent-Date: Fri, 15 Feb 2008 20:39:37 -0800 (PST) ReSent-From: TOPS-20 List Moderator ReSent-To: TOPS-20 Distribution: ; ReSent-Subject: Re: Fixing LAT the old fashioned way ReSent-Message-ID: ReSent-User-Agent: Alpine 1.00 (OSX 931 2008-02-15) > > LAT stopped working when I stopped the micro-engine. > You can prevent the micro-engine from stopping when you CTRL-\ to > mount a tape by adding the command "set fe_runnable=1" in your > klt20.ini file. Hmm, maybe I'll do that. On the other hand, figuring out just why LAT stops working would be something that I would find interesting (I'm odd that way). And it's ... annoying ... It should work. Getting annoyed with the FTP server was what got me started on re-writing it in the first place and I've bumped into a lot of things along the way. So I have a stack of bugs that I've been compiling and I'm really looking forward to starting on fixing some of them. And a couple will be really easy--after all, I submitted the SPR on some of them. 20 years ago ... 20-Feb-2008 06:25:51-PST,2495;000000000000 Return-Path: Received: from pangtzu.panda.com ([206.124.149.117]) by Lingling.Panda.COM with TCP/SMTP; Wed, 20 Feb 2008 06:20:56 -0800 (PST) X-Return-Path: X-Received: from sj-iport-3.cisco.com ([171.71.176.72]) by Lingling.Panda.COM with TCP/SMTP; Wed, 20 Feb 2008 02:21:33 -0800 (PST) X-Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-3.cisco.com with ESMTP; 20 Feb 2008 02:21:27 -0800 X-Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id m1KALRZO017829 for ; Wed, 20 Feb 2008 02:21:27 -0800 X-Received: from cisco.com (pita.cisco.com [171.71.177.199]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id m1KALKuL026717 for ; Wed, 20 Feb 2008 10:21:26 GMT X-Received: (from billw@localhost) by cisco.com (8.8.8-Cisco List Logging/8.8.8) id CAA19626 for TOPS-20@Lingling.Panda.COM; Wed, 20 Feb 2008 02:19:00 -0800 (PST) Sender: Bill Westfield Date: Wed, 20 Feb 2008 2:19:00 PST From: William "Chops" Westfield To: TOPS-20@Lingling.Panda.COM Subject: Power requirements of the PDP-10s... Message-ID: DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=148; t=1203502887; x=1204366887; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=billw@cisco.com; z=From:=20William=20=22Chops=22=20Westfield=20 |Subject:=20Power=20requirements=20of=20the=20PDP-10s... |Sender:=20Bill=20Westfield=20; bh=a+VhZs2SGrEQxP7WM4yj3mxCAXE+4h1mL7IiiOXXGeE=; b=qjRALuLauMZVJwvsw8jP73KJ4rvadpVRsisH70vbhU+NR1h4rJDEMjioHl 8poY7Bv8NE57CfZmPUT41gFcHppvAvJyaE6Y0f9Z9V5sESQPQIfK5Q/Rjp8+ RDih4ggunH; Authentication-Results: sj-dkim-4; header.From=billw@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); ReSent-Date: Wed, 20 Feb 2008 06:20:45 -0800 (PST) ReSent-From: TOPS-20 List Moderator ReSent-To: TOPS-20 Distribution: ; ReSent-Subject: Power requirements of the PDP-10s... ReSent-Message-ID: ReSent-User-Agent: Alpine 1.00 (OSX 931 2008-02-15) Anyone happen to know the electrical specs of the PDP10 series? Just the KL would be OK, but knowing several would be better... Thanks Bill W 20-Feb-2008 09:58:23-PST,1641;000000000000 Return-Path: Received: from pangtzu.panda.com ([206.124.149.117]) by Lingling.Panda.COM with TCP/SMTP; Wed, 20 Feb 2008 09:54:16 -0800 (PST) X-Return-Path: X-Received: from pangtzu.panda.com ([206.124.149.117]) by Lingling.Panda.COM with TCP/SMTP; Wed, 20 Feb 2008 09:53:13 -0800 (PST) Date: Wed, 20 Feb 2008 09:53:07 -0800 (PST) From: Mark Crispin Sender: mrc@pangtzu.panda.com To: William Chops Westfield cc: TOPS-20@Lingling.Panda.COM Subject: Re: Power requirements of the PDP-10s... In-Reply-To: Message-ID: References: User-Agent: Alpine 1.00 (OSX 931 2008-02-15) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed ReSent-Date: Wed, 20 Feb 2008 09:54:05 -0800 (PST) ReSent-From: TOPS-20 List Moderator ReSent-To: TOPS-20 Distribution: ; ReSent-Subject: Re: Power requirements of the PDP-10s... ReSent-Message-ID: ReSent-User-Agent: Alpine 1.00 (OSX 931 2008-02-15) On Wed, 20 Feb 2008, William Chops Westfield wrote: > Anyone happen to know the electrical specs of the PDP10 series? > Just the KL would be OK, but knowing several would be better... I still have my DECSYSTEM-20 Site Preparation Guide which has the data for KL and KS systems as of circa 1983. What data do you need? -- Mark -- http://panda.com/tops-20 TOPS-20: a great improvement over its successors 20-Feb-2008 21:03:29-PST,2371;000000000000 Return-Path: Received: from pangtzu.panda.com ([206.124.149.117]) by Lingling.Panda.COM with TCP/SMTP; Wed, 20 Feb 2008 20:59:19 -0800 (PST) X-Return-Path: X-Received: from aussmtpmrkpc120.us.dell.com ([143.166.82.159]) by Lingling.Panda.COM with TCP/SMTP; Wed, 20 Feb 2008 13:00:02 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.25,382,1199685600"; d="scan'208";a="328372570" X-Received: from unknown (HELO M31.equallogic.com) ([12.110.134.31]) by aussmtpmrkpc120.us.dell.com with SMTP; 20 Feb 2008 14:59:56 -0600 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v753) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <0EDFFBE2-CEEC-4BE4-81D3-87E913DAF080@mac.com> Cc: William Chops Westfield , TOPS-20@Lingling.Panda.COM Content-Transfer-Encoding: 7bit From: John Francini Subject: Re: Power requirements of the PDP-10s... Date: Wed, 20 Feb 2008 15:59:48 -0500 To: Mark Crispin X-Mailer: Apple Mail (2.753) X-Return-Path: francini@mac.com X-OriginalArrivalTime: 20 Feb 2008 20:59:53.0700 (UTC) FILETIME=[8A797A40:01C87403] ReSent-Date: Wed, 20 Feb 2008 20:59:07 -0800 (PST) ReSent-From: TOPS-20 List Moderator ReSent-To: TOPS-20 Distribution: ; ReSent-Subject: Re: Power requirements of the PDP-10s... ReSent-Message-ID: ReSent-User-Agent: Alpine 1.00 (OSX 931 2008-02-15) As I manage a lab today (not with KLs but with tons o' storage arrays), I'd be curious how much a KL drew. I have a recollection of something near 100 A/phase at 208V 3ph. j On 20 Feb 2008, at 12:53, Mark Crispin wrote: > On Wed, 20 Feb 2008, William Chops Westfield wrote: >> Anyone happen to know the electrical specs of the PDP10 series? >> Just the KL would be OK, but knowing several would be better... > > I still have my DECSYSTEM-20 Site Preparation Guide which has the > data for KL and KS systems as of circa 1983. What data do you need? > > -- Mark -- > > http://panda.com/tops-20 > TOPS-20: a great improvement over its successors > 20-Feb-2008 21:15:33-PST,2442;000000000000 Return-Path: Received: from pangtzu.panda.com ([206.124.149.117]) by Lingling.Panda.COM with TCP/SMTP; Wed, 20 Feb 2008 21:11:38 -0800 (PST) X-Return-Path: X-Received: from pangtzu.panda.com ([206.124.149.117]) by Lingling.Panda.COM with TCP/SMTP; Wed, 20 Feb 2008 21:11:14 -0800 (PST) Date: Wed, 20 Feb 2008 21:11:09 -0800 (PST) From: Mark Crispin Sender: mrc@pangtzu.panda.com To: John Francini cc: William Chops Westfield , TOPS-20@Lingling.Panda.COM Subject: Re: Power requirements of the PDP-10s... In-Reply-To: <0EDFFBE2-CEEC-4BE4-81D3-87E913DAF080@mac.com> Message-ID: References: <0EDFFBE2-CEEC-4BE4-81D3-87E913DAF080@mac.com> User-Agent: Alpine 1.00 (OSX 931 2008-02-15) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed ReSent-Date: Wed, 20 Feb 2008 21:11:30 -0800 (PST) ReSent-From: TOPS-20 List Moderator ReSent-To: TOPS-20 Distribution: ; ReSent-Subject: Re: Power requirements of the PDP-10s... ReSent-Message-ID: ReSent-User-Agent: Alpine 1.00 (OSX 931 2008-02-15) On Wed, 20 Feb 2008, John Francini wrote: > As I manage a lab today (not with KLs but with tons o' storage > arrays), I'd be curious how much a KL drew. I have a recollection of > something near 100 A/phase at 208V 3ph. A KL10-C/E used in steady state: . 40A/phase in 60Hz, 120V phase to neutral and 208V phase to phase. . 20A/phase in 50Hz, 230V phase to neutral and 380V phase to phase. It surged 500A in 60Hz and 250A in 50Hz, and reached steady state by the 8th cycle. Power consumed was 13,600W, 14.4 KVA, and generated 46,400 Btu/hr. A KS10 was 9.9A/120V in 60Hz, and 4.95A/230V in 50Hz. It surged 25A in 60Hz and 12.5A in 50Hz. Power was 1070W, 1.18 KVA, and generated 3652 Btu/hr. A KL10 was about 4.6 times faster than a KS10. Thus the KS10 was a far more power-efficient processor than the KL10. ISTR that you could replace the Digital power supplies with real ones and get far greater power efficiency (and less heat!) from a KL. -- Mark -- http://panda.com/tops-20 TOPS-20: a great improvement over its successors 21-Feb-2008 08:53:09-PST,2851;000000000000 Return-Path: Received: from pangtzu.panda.com ([206.124.149.117]) by Lingling.Panda.COM with TCP/SMTP; Thu, 21 Feb 2008 08:48:06 -0800 (PST) X-Return-Path: X-Received: from mta1.srv.hcvlny.cv.net ([167.206.4.196]) by Lingling.Panda.COM with TCP/SMTP; Thu, 21 Feb 2008 07:12:56 -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 <0JWL0063TGXD8271@mta1.srv.hcvlny.cv.net> for TOPS-20@lingling.panda.com; Thu, 21 Feb 2008 10:12:50 -0500 (EST) Date: Thu, 21 Feb 2008 10:12:48 -0500 From: Thomas DeBellis Subject: Reasonable column width? To: Tops-20 Wizards Message-id: <47BD94F0.2040107@optonline.net> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) ReSent-Date: Thu, 21 Feb 2008 08:47:51 -0800 (PST) ReSent-From: TOPS-20 List Moderator ReSent-To: TOPS-20 Distribution: ; ReSent-Subject: Reasonable column width? ReSent-Message-ID: ReSent-User-Agent: Alpine 1.00 (OSX 931 2008-02-15) For some possible planned future work in the new FTP server, I need to set up some text messages with 'proper' formatting. By this, I mean that I want to display some lines in such a way as to not have target terminals wrap them. This will not be the case for all messages, only some of them. That means that they have to be less than a certain column width. I was thinking about a 'reasonable' median. I currently format less than 74 columns, which is what the Haziltine 2000 had. This was for 72 columns of standard text and two additional columns to support indicator characters when doing batch mode transmissions and off screen printing. So 72 columns is probably reasonable. Does anybody have any other opinions on what might be line length? I believe the VT05 only had 72 columns... I think there was some terminal (or something) that would only do 64? Some kind of kit (not a Heathkit). But I don't think I want to do 64. I think 72 looks nice. I'm pretty sure that I don't want to do 80 for a number of reasons, but if somebody can come up with a good reason for insisting on it ... Of course, if anybody knows where I could pick up an old Haziltine 2000, I would be thrilled. I have an excellent game (written in Algol!) that I plan on porting after I finish the new FTP server, but it is hard coded for the Haziltine 2000... Yes, I've looked on eBay (for years) 21-Feb-2008 09:42:54-PST,1487;000000000000 Return-Path: Received: from pangtzu.panda.com ([206.124.149.117]) by Lingling.Panda.COM with TCP/SMTP; Thu, 21 Feb 2008 09:39:05 -0800 (PST) X-Return-Path: X-Received: from pangtzu.panda.com ([206.124.149.117]) by Lingling.Panda.COM with TCP/SMTP; Thu, 21 Feb 2008 08:57:21 -0800 (PST) Date: Thu, 21 Feb 2008 08:57:16 -0800 (PST) From: Mark Crispin Sender: mrc@pangtzu.panda.com To: Thomas DeBellis cc: Tops-20 Wizards Subject: Re: Reasonable column width? In-Reply-To: <47BD94F0.2040107@optonline.net> Message-ID: References: <47BD94F0.2040107@optonline.net> User-Agent: Alpine 1.00 (OSX 931 2008-02-15) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII ReSent-Date: Thu, 21 Feb 2008 09:38:58 -0800 (PST) ReSent-From: TOPS-20 List Moderator ReSent-To: TOPS-20 Distribution: ; ReSent-Subject: Re: Reasonable column width? ReSent-Message-ID: ReSent-User-Agent: Alpine 1.00 (OSX 931 2008-02-15) Email uses 76 as the maximum width for MIME quoted-words. 72 was the limit for Model 33 Teletypes and possibly Datapoint/VT05 terminals. Both are now quite extinct, or should be. -- Mark -- http://panda.com/tops-20 TOPS-20: a great improvement over its successors 21-Feb-2008 21:41:31-PST,2713;000000000000 Return-Path: Received: from pangtzu.panda.com ([206.124.149.117]) by Lingling.Panda.COM with TCP/SMTP; Thu, 21 Feb 2008 21:36:17 -0800 (PST) X-Return-Path: X-Received: from mta5.srv.hcvlny.cv.net ([167.206.4.200]) by Lingling.Panda.COM with TCP/SMTP; Thu, 21 Feb 2008 14:02:50 -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 <0JWL00HN8ZVWU3O0@mta5.srv.hcvlny.cv.net>; Thu, 21 Feb 2008 17:02:26 -0500 (EST) Date: Thu, 21 Feb 2008 17:02:19 -0500 From: Thomas DeBellis Subject: Re: Reasonable column width? In-reply-to: To: Mark Crispin Cc: Tops-20 Wizards Message-id: <47BDF4EB.5060006@optonline.net> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en References: <47BD94F0.2040107@optonline.net> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) ReSent-Date: Thu, 21 Feb 2008 21:36:11 -0800 (PST) ReSent-From: TOPS-20 List Moderator ReSent-To: TOPS-20 Distribution: ; ReSent-Subject: Re: Reasonable column width? ReSent-Message-ID: ReSent-User-Agent: Alpine 1.00 (OSX 932 2008-02-21) > 72 was the limit for Model 33 Teletypes and possibly Datapoint/VT05 > terminals. Both are now quite extinct, or should be. Yes, that's right, the VT05 was 72 columns. If I remember correctly, that was a very beautiful yet unfortunate beast. There used to be one of them between the left of 2102 and the right of another machine (Gus, The Languages System? 2137?) on that side of the machine room on the second floor in Marlboro. Late one night while I was wandering around the building (I often did this as my legs would fall asleep after many hours of hacking), I happened across what I thought was the coolest terminal I had ever seen. It looked like a spaceship--something that should have been in 2001, A Space Odyssey. Right until I used it... As I recall (this was 30 years ago ...), it handled lowercase by not displaying it, yet could still send lowercase codes from the keyboard. So you could type characters but not see them. Got me good and confused ... It was at this point that I attained enlightenment for TT%LCA, TT%UOC and TT%LIC ... 21-Feb-2008 21:45:24-PST,4067;000000000000 Return-Path: Received: from pangtzu.panda.com ([206.124.149.117]) by Lingling.Panda.COM with TCP/SMTP; Thu, 21 Feb 2008 21:37:10 -0800 (PST) X-Return-Path: X-Received: from smtp118.sbc.mail.sp1.yahoo.com ([69.147.64.91]) by Lingling.Panda.COM with TCP/SMTP; Thu, 21 Feb 2008 15:46:19 -0800 (PST) X-Received: (qmail 95311 invoked from network); 21 Feb 2008 23:46:13 -0000 X-Received: from unknown (HELO ?204.238.239.101?) (tymshare@att.net@71.141.97.112 with plain) by smtp118.sbc.mail.sp1.yahoo.com with SMTP; 21 Feb 2008 23:46:13 -0000 X-YMail-OSG: UwG3gnAVM1nCXDB498NYjLgFOM0qZOOQLxLmx.LJWqLBpo2D X-Yahoo-Newman-Property: ymail-3 In-Reply-To: <47BD94F0.2040107@optonline.net> References: <47BD94F0.2040107@optonline.net> Mime-Version: 1.0 (Apple Message framework v624) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <03e4cc7c8dc70f31e7e82c5875a63d67@reststop.com> Content-Transfer-Encoding: 7bit Cc: Tops-20 Wizards X-Image-Url: http://www.goldenstategiftbaskets.com/minibasket.jpg From: Carl Baltrunas Subject: Re: Reasonable column width? Date: Thu, 21 Feb 2008 15:46:11 -0800 To: Thomas DeBellis X-Mailer: Apple Mail (2.624) ReSent-Date: Thu, 21 Feb 2008 21:36:59 -0800 (PST) ReSent-From: TOPS-20 List Moderator ReSent-To: TOPS-20 Distribution: ; ReSent-Subject: Re: Reasonable column width? ReSent-Message-ID: ReSent-User-Agent: Alpine 1.00 (OSX 932 2008-02-21) On Feb 21, 2008, at 7:12 AM, Thomas DeBellis wrote: > > So 72 columns is probably reasonable. Does anybody have any other > opinions on what might be line length? I believe the VT05 only had 72 > columns... I think there was some terminal (or something) that would > only do 64? Some kind of kit (not a Heathkit). But I don't think I > want to do 64. I think 72 looks nice. I'm pretty sure that I don't > want to do 80 for a number of reasons, but if somebody can come up > with a good reason for insisting on it ... I recall that most pre-VT-100 terminals worked best with 72 columns and IIRC punch cards when read stripped off everything in cols 73-80 as did some variants of FORTRAN. VT-100 set the standard to 80, and most line printers handled 132, as did VT-100-132 mode. Hazeltine 1500 went to 80 columns as well, so only the older Hazelines were stuck at 72. The only VT05 I remember was the VT05/VT06 emulator on the GT-40 but since everything else went to 80 columns, I don't remember if the actual VT05 (VT06) was 72 or 80. A good place to look would be /etc/termcap to see what terminals have nonstandard (i.e. not 80 columns) widths. I don't know if anyone keeps a termcap definition for all terminals ever made. It would be a real thrill to be able to compare the specs on all existing terminals. The ONLY argument I can see for 64 cols is some portable TDD devices, mobile phones, and I think the French Minitel terminal. Since just about everyone uses xterm, or vt-100 emulated windows in comm software nobody should be stuck to 64 columns these days. > > Of course, if anybody knows where I could pick up an old Haziltine > 2000, I would be thrilled. I have an excellent game (written in > Algol!) that I plan on porting after I finish the new FTP server, but > it is hard coded for the Haziltine 2000... > > Yes, I've looked on eBay (for years) > Hey, we used to write software forms for the Hazeltine 2000 at CUA back in the early 1970s, but I don't remember seeing them at all once I moved to the west coast (Tymshare) in 1980. The MSSD (Model Secondary School for the Deaf) at Gallaudet used newer Hazeltine models that had color and vector graphics capabilities with single-height and double-height character modes. I don't recall if they were 72 or 80 columns, as a lot of the baudot and TDD devices were using the 72 character TTY standard at that time. 22-Feb-2008 08:38:50-PST,4166;000000000000 Return-Path: Received: from pangtzu.panda.com ([206.124.149.117]) by Lingling.Panda.COM with TCP/SMTP; Fri, 22 Feb 2008 08:33:41 -0800 (PST) X-Return-Path: X-Received: from sj-iport-6.cisco.com ([171.71.176.117]) by Lingling.Panda.COM with TCP/SMTP; Fri, 22 Feb 2008 00:47:35 -0800 (PST) X-Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-6.cisco.com with ESMTP; 22 Feb 2008 00:47:30 -0800 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 m1M8lUMc023914; Fri, 22 Feb 2008 00:47:30 -0800 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 m1M8lRR2010434; Fri, 22 Feb 2008 08:47:27 GMT X-Received: (from billw@localhost) by cisco.com (8.8.8-Cisco List Logging/8.8.8) id AAA09024; Fri, 22 Feb 2008 00:45:08 -0800 (PST) Sender: Bill Westfield Date: Fri, 22 Feb 2008 0:45:08 PST From: William "Chops" Westfield To: Thomas DeBellis Cc: TOPS-20 List Moderator , Tops-20 Wizards Subject: Re: Reasonable column width? In-Reply-To: Your message of Thu, 21 Feb 2008 10:12:48 -0500 to the extreme In-Reply-To: Your message of Thu, 21 Feb 2008 09:00:59 -0800 Message-ID: DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1675; t=1203670050; x=1204534050; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=billw@cisco.com; z=From:=20William=20=22Chops=22=20Westfield=20 |Subject:=20Re=3A=20Reasonable=20column=20width? |Sender:=20Bill=20Westfield=20; bh=47J3l3eGzAaVH4f4V5yCrhyw2HwYQ4szft/7Beg42PY=; b=p6hKfOT14abqUTh5VfOkvd4wuO6/HAm4zSbpVbk507+uMEH9UXEuFU+N65 pEmOfmw0VAAnTfGs1lkauEiTsz/C46oz1URcbt6Z/UFfQW7+ZzPIIVPBW7Ki tVaIHOeoNC; Authentication-Results: sj-dkim-2; header.From=billw@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); ReSent-Date: Fri, 22 Feb 2008 08:33:33 -0800 (PST) ReSent-From: TOPS-20 List Moderator ReSent-To: TOPS-20 Distribution: ; ReSent-Subject: Re: Reasonable column width? ReSent-Message-ID: ReSent-User-Agent: Alpine 1.00 (OSX 932 2008-02-21) Of course, if anybody knows where I could pick up an old Haziltine 2000, I would be thrilled. I have an excellent game (written in Algol!) that I plan on porting after I finish the new FTP server, but it is hard coded for the Haziltine 2000... I thought the Haz-2000 had 80 columns? Ah, memories... (The web says 80 columns was an option.) You're not talking about the version of "Star Trek" that was on LIRICS back in the 70s, are you? IIRC that was in algol and had some code for HAZ-2000, though I usually had to play on the ASR33s or the Ti-700. (Hazeltine was a local company, after all. I even spent a summer working there as an electronics Tech.) I wrote some cute display hacks for the H2000 myself; the most memorable being a "CAN[cel] war" program that would automatically kill other users of our PPN. Something PTYs would have rendered meaningless, if they had been enabled on LIRICS. It shouldn't be hard to write an emulator for a hazeltine-2000 on any modern system. terminal emulators are pretty easy, especially when performance is irrelevant... Back to your original question. A fair number of "homebrew" and semi-homebrew terminals and early personal computers had 64 character displays; that was widely believed to be about as much as you could fit in a standard video frame, and of course it made memory addressing much easier. (80 column displays usually used SPECIAL monitors.) The original IBMPC color display (capable of being displayed on a normal TV, supposedly) had a 40 column mode. Nowdays, of course, you can make your X windows whatever width you want, just to be mean :-( BillW 22-Feb-2008 08:42:39-PST,2289;000000000000 Return-Path: Received: from pangtzu.panda.com ([206.124.149.117]) by Lingling.Panda.COM with TCP/SMTP; Fri, 22 Feb 2008 08:34:25 -0800 (PST) X-Return-Path: X-Received: from sesame.cc.columbia.edu ([128.59.59.56]) by Lingling.Panda.COM with TCP/SMTP; Fri, 22 Feb 2008 06:08:27 -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 m1ME8L7h009888; Fri, 22 Feb 2008 09:08:21 -0500 (EST) X-Received: (from fdc@localhost) by sesame.cc.columbia.edu (8.14.1/8.14.1/Submit) id m1ME8KCl009887; Fri, 22 Feb 2008 09:08:20 -0500 (EST) Date: Fri, 22 Feb 2008 9:08:20 EST From: Frank da Cruz To: Thomas DeBellis Cc: TOPS-20 List Moderator , Mark Crispin , Tops-20 Wizards Subject: Re: Reasonable column width? In-Reply-To: <47BDF4EB.5060006@optonline.net> Message-ID: ReSent-Date: Fri, 22 Feb 2008 08:34:18 -0800 (PST) ReSent-From: TOPS-20 List Moderator ReSent-To: TOPS-20 Distribution: ; ReSent-Subject: Re: Reasonable column width? ReSent-Message-ID: ReSent-User-Agent: Alpine 1.00 (OSX 932 2008-02-21) > Yes, that's right, the VT05 was 72 columns. If I remember correctly, > that was a very beautiful yet unfortunate beast... > I happened across what I thought was the coolest terminal I had ever > seen. It looked like a spaceship--something that should have been in > 2001, A Space Odyssey. > Here's one we had at Columbia before you (or the DEC-20s) arrived: http://www.columbia.edu/acis/history/terminet.html Here's the standard DEC marketing picture: http://www.columbia.edu/acis/history/vt05.jpg On Youtube just now I found a little movie of a VT05. Notice the still photo at the beginning -- that's the Columbia machine room, 1965. http://www.google.com/url?sa=t&ct=res&cd=5&url=http%3A%2F%2Fwww.youtube.com%2Fwatch%3Fv%3D7ND6oLXocR0&ei=UNa-R5PwGKOieZSy3PkN&usg=AFQjCNFfldd4d6u7de7i3RYreVDH-vaX1w&sig2=1repAgMVA5DMYMNpG-acVQ - Frank 24-Feb-2008 08:15:24-PST,4240;000000000000 Return-Path: Received: from pangtzu.panda.com ([206.124.149.117]) by Lingling.Panda.COM with TCP/SMTP; Sun, 24 Feb 2008 08:08:57 -0800 (PST) X-Return-Path: X-Received: from smtp02.lnh.mail.rcn.net ([207.172.157.102]) by Lingling.Panda.COM with TCP/SMTP; Sun, 24 Feb 2008 05:47:35 -0800 (PST) X-Received: from mr02.lnh.mail.rcn.net ([207.172.157.22]) by smtp02.lnh.mail.rcn.net with ESMTP; 24 Feb 2008 08:45:26 -0500 X-Received: from smtp01.lnh.mail.rcn.net (smtp01.lnh.mail.rcn.net [207.172.4.11]) by mr02.lnh.mail.rcn.net (MOS 3.8.6-GA) with ESMTP id OLM18906; Sun, 24 Feb 2008 08:45:24 -0500 (EST) X-Received: from c-76-19-133-78.hsd1.ma.comcast.net (HELO [127.0.0.1]) ([76.19.133.78]) by smtp01.lnh.mail.rcn.net with ESMTP; 24 Feb 2008 08:44:22 -0500 Message-ID: <47C174D9.8000403@RCN.Com> Date: Sun, 24 Feb 2008 08:44:57 -0500 From: "Alan H. Martin" User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: TOPS-20@Lingling.Panda.COM Subject: Re: Power requirements of the PDP-10s... References: <0EDFFBE2-CEEC-4BE4-81D3-87E913DAF080@mac.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Junkmail-Whitelist: YES (by domain whitelist at mr02.lnh.mail.rcn.net) ReSent-Date: Sun, 24 Feb 2008 08:08:50 -0800 (PST) ReSent-From: TOPS-20 List Moderator ReSent-To: TOPS-20 Distribution: ; ReSent-Subject: Re: Power requirements of the PDP-10s... ReSent-Message-ID: ReSent-User-Agent: Alpine 1.00 (OSX 933 2008-02-22) Mark Crispin wrote: > On Wed, 20 Feb 2008, John Francini wrote: >> As I manage a lab today (not with KLs but with tons o' storage >> arrays), I'd be curious how much a KL drew. I have a recollection of >> something near 100 A/phase at 208V 3ph. > > A KL10-C/E used in steady state: > . 40A/phase in 60Hz, 120V phase to neutral and 208V phase to phase. > . 20A/phase in 50Hz, 230V phase to neutral and 380V phase to phase. > > It surged 500A in 60Hz and 250A in 50Hz, and reached steady state by the > 8th cycle. The site prep guide for Stevens KL1282 contained a graph of initial AC power consumption over the first few jiffies. IIRC, that 1090D (tall cabinet) system consumed 720A/phase for the first 120th of a second of operation. The graph is notably absent from: http://www.bitsavers.org/pdf/dec/pdp10/KL10/EK-0KL20-IN-001_inst_Aug78.pdf (KL10-Based DECSYSTEM-20 Installation Manual, EK-0KL20-IN-011, 1st Edition, August 1978). Does someone have access to a Site Prep Guide containing such a graph of current over time? The curve initially looks like a classic damped oscillator, then of course settles down to a pure 60Hz sine wave. The inrush current was of interest to Stevens Institute because the college paid for electrical consumption on a monthly basis as a function of *peak* usage. There was concern that the first time the system was powered up, it would push campus usage to a new and unrepresentative high; they didn't want to discover ``congratulations on your new aluminum smelter'' scrawled on the Public Service Electric & Gas bill. In practice, it turned out not to be an issue. At least by the time I researched this a few years ago, utility tariffs for peak-usage industrial billing defined peak usage as a value within a moderate time period (30 minutes in this example: https://www.firstenergycorp.com/Residential_and_Business/Billing_and_Payments/Read_Meter_Form/How_To_Read_Your_Load_Meter.html ). And while I don't know what the billing meters used on campus looked like back then, even in the old days of purely electromechanical metering, at least some meters implemented some form of damping (electrical or mechanical) to avoid billing on too-short spikes. /AHM -- Alan Howard Martin AMartin.MA.UltraNet@RCN.Com 24-Feb-2008 11:28:10-PST,2356;000000000000 Return-Path: Received: from pangtzu.panda.com ([206.124.149.117]) by Lingling.Panda.COM with TCP/SMTP; Sun, 24 Feb 2008 11:23:41 -0800 (PST) X-Return-Path: X-Received: from mta4.srv.hcvlny.cv.net ([167.206.4.199]) by Lingling.Panda.COM with TCP/SMTP; Sun, 24 Feb 2008 10:32:38 -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 <0JWR00L5XA5PF650@mta4.srv.hcvlny.cv.net> for TOPS-20@lingling.panda.com; Sun, 24 Feb 2008 13:32:13 -0500 (EST) Date: Sun, 24 Feb 2008 13:32:12 -0500 From: Thomas DeBellis Subject: Overriding RDDT entry vector? To: Tops-20 Wizards Message-id: <47C1B82C.1000601@optonline.net> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) ReSent-Date: Sun, 24 Feb 2008 11:23:02 -0800 (PST) ReSent-From: TOPS-20 List Moderator ReSent-To: TOPS-20 Distribution: ; ReSent-Subject: Overriding RDDT entry vector? ReSent-Message-ID: ReSent-User-Agent: Alpine 1.00 (OSX 933 2008-02-22) Typically, when I need to DDT, I don't bother with the DEBUG command. EFTPSR has some code to do a GET% of XDDT, pull the address of the unsolicted breakpoint from the PDV, cache it and then do the JSR. This brings up DDT very nicely, which is just what I need almost 100% of the time. I don't carry the weight of the debugger around, but can get it whenever I need it--important when tracing down problems when running as an actual server (I.E., EFTPSR is the top fork, no EXEC). For certain (extremely rare) cases (like I've done it twice in four years), I need DDT before I ask for it. So, I link in RDDT. But this blows away my entry vector: starting EFTPSR now always puts me in DDT. And the REENTER address is not there. This is also what I want almost 100% of the time when RDDT'ing. However, when I don't, how do I have LINK use EFTPSR's entry vector and not stomp it with RDDT's? 24-Feb-2008 19:02:10-PST,1799;000000000000 Return-Path: Received: from pangtzu.panda.com ([206.124.149.117]) by Lingling.Panda.COM with TCP/SMTP; Sun, 24 Feb 2008 18:57:04 -0800 (PST) X-Return-Path: X-Received: from mta5.srv.hcvlny.cv.net ([167.206.4.200]) by Lingling.Panda.COM with TCP/SMTP; Sun, 24 Feb 2008 18:08:16 -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 <0JWR00E65V9GHOE0@mta5.srv.hcvlny.cv.net> for TOPS-20@lingling.panda.com; Sun, 24 Feb 2008 21:08:04 -0500 (EST) Date: Sun, 24 Feb 2008 21:08:03 -0500 From: Thomas DeBellis Subject: XJRSTF documentation bug in SYSREF? To: Tops-20 Wizards Message-id: <47C22303.4080109@optonline.net> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) ReSent-Date: Sun, 24 Feb 2008 18:56:45 -0800 (PST) ReSent-From: TOPS-20 List Moderator ReSent-To: TOPS-20 Distribution: ; ReSent-Subject: XJRSTF documentation bug in SYSREF? ReSent-Message-ID: ReSent-User-Agent: Alpine 1.00 (OSX 933 2008-02-22) In my June 1982 version of SYSREF, at the bottom of page 2-73, the operation of XJRSTF is discussed and how a double word might appropriately be set up with a series of SFM and JSR instructions. However in the first sentence of the next paragraph, it is stated that "... the return is made by XJRSTF M". Shouldn't this be "XJRSTF @M"? 24-Feb-2008 19:09:15-PST,2146;000000000000 Return-Path: Received: from pangtzu.panda.com ([206.124.149.117]) by Lingling.Panda.COM with TCP/SMTP; Sun, 24 Feb 2008 19:05:09 -0800 (PST) X-Return-Path: X-Received: from pangtzu.panda.com ([206.124.149.117]) by Lingling.Panda.COM with TCP/SMTP; Sun, 24 Feb 2008 19:04:55 -0800 (PST) Date: Sun, 24 Feb 2008 19:04:50 -0800 (PST) From: TOPS-20 List Moderator Sender: mrc@pangtzu.panda.com To: Thomas DeBellis cc: Tops-20 Wizards Subject: Re: XJRSTF documentation bug in SYSREF? In-Reply-To: <47C22303.4080109@optonline.net> Message-ID: References: <47C22303.4080109@optonline.net> User-Agent: Alpine 1.00 (OSX 933 2008-02-22) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed ReSent-Date: Sun, 24 Feb 2008 19:04:59 -0800 (PST) ReSent-From: TOPS-20 List Moderator ReSent-To: TOPS-20 Distribution: ; ReSent-Subject: Re: XJRSTF documentation bug in SYSREF? ReSent-Message-ID: ReSent-User-Agent: Alpine 1.00 (OSX 933 2008-02-22) I see nothing of the sort on page 2-73 of the PRM, but there is such text on page 2-75. XJRSTF M is correct. JRSTF takes a flags/PC doubleword from the doubleword at E/E+1. JRSTF, on the other hand, uses E itself for the PC, with the flags coming from the final word used in calculating E. In the (useless) non-indirect form of JRSTF, the flags would come from the JRSTF instruction itself. On Sun, 24 Feb 2008, Thomas DeBellis wrote: > In my June 1982 version of SYSREF, at the bottom of page 2-73, the > operation of XJRSTF is discussed and how a double word might > appropriately be set up with a series of SFM and JSR instructions. > > However in the first sentence of the next paragraph, it is stated that > "... the return is made by XJRSTF M". Shouldn't this be "XJRSTF @M"? > > -- Mark -- http://panda.com/tops-20 TOPS-20: a great improvement over its successors 2-Mar-2008 10:16:03-PST,9517;000000000000 Return-Path: Received: from pangtzu.panda.com ([206.124.149.117]) by Lingling.Panda.COM with TCP/SMTP; Sun, 2 Mar 2008 10:11:08 -0800 (PST) X-Return-Path: X-Received: from mta4.srv.hcvlny.cv.net ([167.206.4.199]) by Lingling.Panda.COM with TCP/SMTP; Sun, 2 Mar 2008 10:06:12 -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 <0JX4000QT7LVPD60@mta4.srv.hcvlny.cv.net> for TOPS-20@Lingling.Panda.COM; Sun, 02 Mar 2008 13:05:55 -0500 (EST) Date: Sun, 02 Mar 2008 13:05:54 -0500 From: Thomas DeBellis Subject: Re: Reasonable column width? In-reply-to: To: William Chops Westfield Cc: Tops-20 Wizards Message-id: <47CAEC82.3070209@optonline.net> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en References: User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) ReSent-Date: Sun, 2 Mar 2008 10:10:58 -0800 (PST) ReSent-From: TOPS-20 List Moderator ReSent-To: TOPS-20 Distribution: ; ReSent-Subject: Re: Reasonable column width? ReSent-Message-ID: ReSent-User-Agent: Alpine 1.00 (OSX 938 2008-02-29) > > Of course, if anybody knows where I could pick up an old Haziltine > > 2000, I would be thrilled. > I thought the Haz-2000 had 80 columns? Ah, memories... (The web > says 80 columns was an option.) Here is what I remember: the Hazeltine 2000 model B (?)--as shipped in approximately 1975--was an uppercase only terminal, although with some contortions, you could key lower case from the (huge) detachable keyboard. Its nickname was 'The Brick'--60 pounds or so--it had two racks of small circuit boards inside. And it needed much padding. A later model (the C?), would do lower case and had a keyboard with sculpted keys. A friend mine at WPI (my MQP partner, actually) bought one of these around the 1980 timeframe. The newer model needed less padding and was a LOT lighter--it only had 3 (large) circuit boards. I do not recall ever seeing the 80 by 25 line model--we all wanted more screen lines, which made for easier TECO'ing. And all of the display code that I was aware of was hardcoded for the 27 line by 74 column unit. Nobody used the terminal line and width parameters. In the early to mid-1970's, the older unit was in use at Commack South Junior High School in Long Island and was used to write several very interesting applications, the first being SCREEN and the second being STAR, the game you reference (but see below). Commack had some money: they even had LA36s. The huge Hazeltine building is still around the corner from me on Pulaski Road, painted the same white and blue colors. It's part of a different company now (I forget the name) doing defence work. I contacted them not that long ago, hoping that one of these beasts might still be lurking in the celler. An old timer there was absolutely thrilled to talk about the unit, but alas ... > > I have an excellent game (written in Algol!) that I plan on > > porting after I finish the new FTP server, but it is hard coded > > for the Haziltine 2000... > You're not talking about the version of "Star Trek" that was on > LIRICS back in the 70s, are you? In fact, this is precisely what I am referring to. Recently (?), I was able to get in touch with one of the original authors (Tony Camas, another WPI acquaintance). Alas, he had no soft copies of either program. My own copy is a paper listing. I tried scanning it several years ago (in late 1990's), but the OCR technology of the day (Windows 98) wasn't up to the task. I also tried paying a local secretary to type it in for me, but it was too long, even at the rate of a five dollars a page. I'm going to try scanning it again, once the extended mode FTP server is stable enough for MRC to consider putting it into the Panda distribution. If that doesn't work, then I am going to finally bite the bullet and type the whole thing in by myself. It is an EXCELLENT game, well regarded as being one of the best 'Star Trek' games ever written due to the close adherence to the Star Fleet Technical Manual and the intellegence of the enemies. As you know, it was not uncommon for one Romulan to commit suicide by ramming you, thus knocking out your shields while the others would start torpedoing you. Klingons were sneakier, taking pot shots at your and then vanishing into hyper-space. The other author, Martin C. Horowitz, was well known for being over my house (with a bunch of my other friends) nearly every Saturday night for all night 'Star Parties'. As one of the authors, he was referred to as the 'Star God' and would modify STAR for any local terminal that I managed to scare up in addition to the HZ2000 that I had (at some points, I had two terminals at home). With two phone lines, I thus had more computer access then some High Schools. Marty drove the nearly infinitely famous 1967 (?) yellow Chevy Impala, which was referred to as the 'Star Chariot'. These parties were also notable for having actual real live girls in attendance, a very rare thing indeed in the mid-1970's timeframe. The person with the highest STAR score was typically Chris Mahon, who had the stamina to keep playing even after we had all passed out snoozing on the couches in the celler. This was quite a feat, considering that everyone was amped out on Pop Shop soda. His nickname was 'Lord Admiral Blood and Guts Mahon'. You probably saw him displayed on five of the top positions in the winners list. Anytime anybody beat him, he would nearly immediately drop what he was doing, come over and play until he got the highest score again. This would happen even before we were sitting down to dinner. Our house had a second entrance to the celler which he could use to sneak down there while we were eating. After my brother and I were done cleaning up, we'd also sneak leftovers down to him. He was able to be over so much by telling his mother that he was studying Calculus with us. I do not understand how he managed to graduate from Huntington High (along with the rest of us). > It shouldn't be hard to write an emulator for a hazeltine-2000 on > any modern system. terminal emulators are pretty easy, especially > when performance is irrelevant... Yes, but writing an emulator would involve hacking something besides MACRO which I am flatly not interested in these days (although I do intend to consider participating in the KLH10 memory upgrade project). I'd also like to get a functional emulated CI and HSC50 on the air. In fact, I did write a terminal emulator at WPI for my friend. WPI had very, very good support for the Adds Consul 520/580 series terminal. It was built into the monitor. We called it 'Automatic Nice Things' and it was used to skip blank spaces to minimize character transmission. It could really substantially speed up perceived transmission rates by cursoring directly to an indent; an important thing when writing block structured code. My emulator got a PTY and put it into Adds mode and then converted the character stream to HZ2000 codes, so you could still have winning output rates--an important thing on 300 baud dial up. It was one of the few legitimate uses of a PTY that I have ever heard of and I had to ask the system manager (AEJ) for special permission to even write it. You weren't the only person engaging in 'can wars' at LIRICS. The HZ2000 also had a batch mode that could be used to buffer characters for rapid transmission. This eliminated the need for the PTY and I also wrote a program to do this, which allowed me to easily log my brother and friends off when they were stuck at school using our ASR33 Teletypes. While home 'sick', I rarely lost a 'can war'. Even with pre-punched paper tape, the ASR33 usually couldn't get the characters in fast enough. Unfortunately, when my brother was at home ... I eventually wrote a program which would sit in a loop waiting for him, displaying nothing but the job number (hey, it was 110 baud). As soon as this happened, we'd hit the paper tape and sometimes catch him. If not, then we would punch up another paper tape with the correct job number and control-O's which sometimes succeeded. These sorts of shenanigans were frowned upon and I was 'talked to' a number of times about it. One assumes that--at 49--I might have grown out of this. However, every so often I find myself getting kicked off of Tommy Timesharing by my brother, apparently just to keep up appearances. But these days it is an UNATTACH instead of a CANCEL (or LOGOUT), so I (usually) don't lose much work. If I recollect correctly, because of the hardware character buffering capability, the HZ2000 was also used to launch a successful attack at WPI (and possibly elsewhere) by doing a SEND to a terminal on a (Tops-10) privileged line. .... But I really should be working on the FTP server .... 3-Mar-2008 17:55:35-PST,3310;000000000000 Return-Path: Received: from pangtzu.panda.com ([206.124.149.117]) by Lingling.Panda.COM with TCP/SMTP; Mon, 3 Mar 2008 17:49:42 -0800 (PST) X-Return-Path: X-Received: from mta3.srv.hcvlny.cv.net ([167.206.4.198]) by Lingling.Panda.COM with TCP/SMTP; Mon, 3 Mar 2008 16:41:48 -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 <0JX6003F5KKKFHQ0@mta3.srv.hcvlny.cv.net> for TOPS-20@lingling.panda.com; Mon, 03 Mar 2008 19:41:08 -0500 (EST) Date: Mon, 03 Mar 2008 19:41:07 -0500 From: Thomas DeBellis Subject: Operation of TCP PSH flag under Tops-20? To: Tops-20 Wizards Message-id: <47CC9AA3.9000504@optonline.net> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) ReSent-Date: Mon, 3 Mar 2008 17:49:34 -0800 (PST) ReSent-From: TOPS-20 List Moderator ReSent-To: TOPS-20 Distribution: ; ReSent-Subject: Operation of TCP PSH flag under Tops-20? ReSent-Message-ID: ReSent-User-Agent: Alpine 1.00 (OSX 941 2008-03-03) Does anybody know about the operation of the TCP PSH flag under Tops-20? I've got two questions: 1) From what I can tell, using SOUTR% will set this. What else? CLOSF%? And an (arcane) BBN JSYS, too, I suppose... Would anything external to the 20 application set this? 2) SINR% will return on receipt of a PSH, but will also do so when the byte count is exhausted. What about when both happen at the same time? Suppose I SOUTR% 10 bytes to a SINR% that is waiting for 10 bytes? Is there any way to tell that a PSH happened? The reason that I'm asking about this is that if certain things are true, I can greatly simplify code and (hopefully), get some major speed ups. I really want that. Although paged file structure transfers do some pretty much wonderful things, they are turning out to be a real dog to implement and the more that I look at the performance, the more dissatisfied I become. For nearly all cases, using straight stream file structures and image (L 36) data types is vastly more efficient in just about every way possible: it uses 1/3 less memory, puts less data over the wire and uses less processor time. Paged file structures only win if you have binary files with partially unfilled pages or holey files. They also have the post transfer FDB cuteness. In many cases, binary files have zeroes already squeezed out of them (.EXE's do). So you really don't get much. And you really lose for ASCII files... Once all the dust settles from all of this, I'm going to give some serious thought to putting some logic into the Tops-20 FTP client to NOT use paged mode transfers unless it KNOWS that the file in question has holes. I'll probably define some extra verbs and report them with FEAT. I can handle post-hacking the FDB that way, also. 3-Mar-2008 21:02:32-PST,2712;000000000000 Return-Path: Received: from pangtzu.panda.com ([206.124.149.117]) by Lingling.Panda.COM with TCP/SMTP; Mon, 3 Mar 2008 20:57:47 -0800 (PST) X-Return-Path: X-Received: from cyteen.hactrn.net ([66.92.66.68]) by Lingling.Panda.COM with TCP/SMTP; Mon, 3 Mar 2008 20:53:35 -0800 (PST) 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 05E752842B for ; Tue, 4 Mar 2008 04:53:25 +0000 (UTC) X-Received: from thrintun.hactrn.net (localhost [IPv6:::1]) by thrintun.hactrn.net (Postfix) with ESMTP id AE75B22808 for ; Mon, 3 Mar 2008 23:53:25 -0500 (EST) Date: Mon, 03 Mar 2008 23:53:25 -0500 From: Rob Austein To: Tops-20 Wizards Subject: Re: Operation of TCP PSH flag under Tops-20? In-Reply-To: <47CC9AA3.9000504@optonline.net> References: <47CC9AA3.9000504@optonline.net> 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: <20080304045325.AE75B22808@thrintun.hactrn.net> ReSent-Date: Mon, 3 Mar 2008 20:57:32 -0800 (PST) ReSent-From: TOPS-20 List Moderator ReSent-To: TOPS-20 Distribution: ; ReSent-Subject: Re: Operation of TCP PSH flag under Tops-20? ReSent-Message-ID: ReSent-User-Agent: Alpine 1.00 (OSX 941 2008-03-03) At Mon, 03 Mar 2008 19:41:07 -0500, Thomas DeBellis wrote: > > 1) From what I can tell, using SOUTR% will set this. What else? > CLOSF%? And an (arcane) BBN JSYS, too, I suppose... Would > anything external to the 20 application set this? CLOSF% presumably sends FIN, PSH would be redundant. > 2) SINR% will return on receipt of a PSH, but will also do so when > the byte count is exhausted. What about when both happen at the > same time? Suppose I SOUTR% 10 bytes to a SINR% that is waiting > for 10 bytes? Is there any way to tell that a PSH happened? If one of the people who hacked TCP on TOPS-20 tells you so, believe them, not me, but from the conceptual model in RFC 793 I'd be surprised if there were any way to tell. PSH is a hint to the receiving TCP implementation that it should stop buffering and wake up the data consumer, but it's not intended as a signal to the data consumer itself. 4-Mar-2008 09:04:58-PST,2859;000000000000 Return-Path: Received: from pangtzu.panda.com ([206.124.149.117]) by Lingling.Panda.COM with TCP/SMTP; Tue, 4 Mar 2008 08:59:27 -0800 (PST) X-Return-Path: X-Received: from pangtzu.panda.com ([206.124.149.117]) by Lingling.Panda.COM with TCP/SMTP; Mon, 3 Mar 2008 21:28:47 -0800 (PST) Date: Mon, 3 Mar 2008 21:28:40 -0800 (PST) From: Mark Crispin Sender: mrc@pangtzu.panda.com To: Tops-20 Wizards Subject: Re: Operation of TCP PSH flag under Tops-20? In-Reply-To: <20080304045325.AE75B22808@thrintun.hactrn.net> Message-ID: References: <47CC9AA3.9000504@optonline.net> <20080304045325.AE75B22808@thrintun.hactrn.net> User-Agent: Alpine 1.00 (OSX 941 2008-03-03) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed ReSent-Date: Tue, 4 Mar 2008 08:59:17 -0800 (PST) ReSent-From: TOPS-20 List Moderator ReSent-To: TOPS-20 Distribution: ; ReSent-Subject: Re: Operation of TCP PSH flag under Tops-20? ReSent-Message-ID: ReSent-User-Agent: Alpine 1.00 (OSX 941 2008-03-03) On Mon, 3 Mar 2008, Rob Austein wrote: >> 2) SINR% will return on receipt of a PSH, but will also do so when >> the byte count is exhausted. What about when both happen at the >> same time? Suppose I SOUTR% 10 bytes to a SINR% that is waiting >> for 10 bytes? Is there any way to tell that a PSH happened? > If one of the people who hacked TCP on TOPS-20 tells you so, believe > them, not me, but from the conceptual model in RFC 793 I'd be > surprised if there were any way to tell. PSH is a hint to the > receiving TCP implementation that it should stop buffering and wake up > the data consumer, but it's not intended as a signal to the data > consumer itself. Unbelievably, the MCRM actually documents that SINR% does this, but I don't see where in the sources it does. AFAICT, SINR% is only implemented inside the SIN% code in IO.MAC. I agree with Rob's advice. This is the first that I have ever heard of a TCP receiving application having the slightest clue of a TCP Push, and I can not guess how this can possibly be of any use. Most other operating systems use the sockets interface, which provides little, or no, application level control over TCP Push; Push is simply set at the end of the data when the TCP runs out of data awaiting transmission on that connection. Apparently, it was too much of a burden for UNIX programmers to have to remember to set Push when it was finished sending and wanted the receiving application to wake up. -- Mark -- http://panda.com/tops-20 TOPS-20: a great improvement over its successors 4-Mar-2008 09:08:40-PST,3190;000000000000 Return-Path: Received: from pangtzu.panda.com ([206.124.149.117]) by Lingling.Panda.COM with TCP/SMTP; Tue, 4 Mar 2008 09:00:13 -0800 (PST) X-Return-Path: X-Received: from mta3.srv.hcvlny.cv.net ([167.206.4.198]) by Lingling.Panda.COM with TCP/SMTP; Tue, 4 Mar 2008 04:08:09 -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 <0JX7003P3GD3YE21@mta3.srv.hcvlny.cv.net> for TOPS-20@lingling.panda.com; Tue, 04 Mar 2008 07:07:51 -0500 (EST) Date: Tue, 04 Mar 2008 07:07:50 -0500 From: Thomas DeBellis Subject: Re: Operation of TCP PSH flag under Tops-20? In-reply-to: <20080304045325.AE75B22808@thrintun.hactrn.net> To: Rob Austein Cc: Tops-20 Wizards Message-id: <47CD3B96.1090600@optonline.net> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en References: <47CC9AA3.9000504@optonline.net> <20080304045325.AE75B22808@thrintun.hactrn.net> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) ReSent-Date: Tue, 4 Mar 2008 09:00:06 -0800 (PST) ReSent-From: TOPS-20 List Moderator ReSent-To: TOPS-20 Distribution: ; ReSent-Subject: Re: Operation of TCP PSH flag under Tops-20? ReSent-Message-ID: ReSent-User-Agent: Alpine 1.00 (OSX 941 2008-03-03) > If one of the people who hacked TCP on TOPS-20 tells you so, believe > them, not me, but from the conceptual model in RFC 793 I'd be > surprised if there were any way to tell. PSH is a hint to the > receiving TCP implementation that it should stop buffering and wake up > the data consumer, but it's not intended as a signal to the data > consumer itself. PSH seems to be something more than that. I never worked on any of this stuff, but from the Wikipedia: An application can force delivery of octets to the output stream using a push operation provided by TCP to the application layer. This operation also causes TCP to set the PSH flag or control bit to ensure that data will be delivered immediately to the application layer by the receiving transport layer. Does this imply that only the application can set PSH? It would appear so. Also, from the monitor calls reference manual (SINR%) For a TCP/IP transmission, SINR will return when a TCP message with the PUSH flag is received, or the byte count is exhausted. This implies that SINR% knows when a message with PSH was set, which might not have use if an intervening node, gateway or router set PSH below the application level. That seems to mean that PSH is for the application, only. Since SINR% seems to know about PSH, how can I find out about it? I guess by reading something from the TCB with TCOPR%? How else? I can get some major speed ups if I know where the end of the data stream is. 4-Mar-2008 09:12:32-PST,3717;000000000000 Return-Path: Received: from pangtzu.panda.com ([206.124.149.117]) by Lingling.Panda.COM with TCP/SMTP; Tue, 4 Mar 2008 09:00:38 -0800 (PST) X-Return-Path: X-Received: from sj-iport-6.cisco.com ([171.71.176.117]) by Lingling.Panda.COM with TCP/SMTP; Mon, 3 Mar 2008 23:39:25 -0800 (PST) X-Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-6.cisco.com with ESMTP; 03 Mar 2008 23:39:19 -0800 X-Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id m247dJTn000455; Mon, 3 Mar 2008 23:39:19 -0800 X-Received: from cisco.com (pita.cisco.com [171.71.177.199]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id m247dJJt015502; Tue, 4 Mar 2008 07:39:19 GMT X-Received: (from billw@localhost) by cisco.com (8.8.8-Cisco List Logging/8.8.8) id XAA22971; Mon, 3 Mar 2008 23:36:58 -0800 (PST) Sender: Bill Westfield Date: Mon, 3 Mar 2008 23:36:58 PST From: William "Chops" Westfield To: Thomas DeBellis Cc: Tops-20 Wizards Subject: Re: Reasonable column width? In-Reply-To: Your message of Sun, 02 Mar 2008 13:05:54 -0500 Message-ID: DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1369; t=1204616359; x=1205480359; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=billw@cisco.com; z=From:=20William=20=22Chops=22=20Westfield=20 |Subject:=20Re=3A=20Reasonable=20column=20width? |Sender:=20Bill=20Westfield=20; bh=aqeXGRdGIIv3SEv8IxvJWt8yWE7Hos8X3BNiswDVGOw=; b=lZXGa+eaIC+E1btQetg2G/eb5YNX0GhzOBR5KLRfZ9mUZ+CXaOaxgQ1EsW NX2xiMzCheTUEqoa6PxaoMZn0ZA6ze9Hl8w2mmnSZdTPa6uD+XKNF87aam2Y TQHli4/bVU; Authentication-Results: sj-dkim-4; header.From=billw@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); ReSent-Date: Tue, 4 Mar 2008 09:00:31 -0800 (PST) ReSent-From: TOPS-20 List Moderator ReSent-To: TOPS-20 Distribution: ; ReSent-Subject: Re: Reasonable column width? ReSent-Message-ID: ReSent-User-Agent: Alpine 1.00 (OSX 941 2008-03-03) > You're not talking about the version of "Star Trek" that was on > LIRICS back in the 70s, are you? It is an EXCELLENT game, well regarded as being one of the best 'Star Trek' games ever written due to the close adherence to the Star Fleet Technical Manual and the intellegence of the enemies. I didn't know that! Anytime anybody beat him, he would nearly immediately drop what he was doing, come over and play until he got the highest score again. Heh. One of my classmates (from "Harborfields") took the size-one galaxy high score for quite some time, I think. IIRC, size-1 strategy consisted of using repulser beams to push the romulan out of the galaxy, and finishing off the klingon with conventional weapons. In this particular game, the "repulser" step caused the klingon and romulan to collide, destroying them both rather quickly, and scoring something like 993 out of a possible 1000 points... Yes, but writing an emulator would involve hacking something besides MACRO which I am flatly not interested in these days The trick is to get someone else to do it for you! A haz-2000 to VT100 converting telnet, or somesuch. Do you know whether the Star haz-2000 code used only traditional cursor manipulation stuff, or whether it used the haz foreground/background stuff? BillW 4-Mar-2008 15:10:54-PST,2238;000000000000 Return-Path: Received: from pangtzu.panda.com ([206.124.149.117]) by Lingling.Panda.COM with TCP/SMTP; Tue, 4 Mar 2008 15:05:50 -0800 (PST) X-Return-Path: X-Received: from cyteen.hactrn.net ([66.92.66.68]) by Lingling.Panda.COM with TCP/SMTP; Tue, 4 Mar 2008 09:36:38 -0800 (PST) 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 EC4D72842B for ; Tue, 4 Mar 2008 17:36:31 +0000 (UTC) X-Received: from thrintun.hactrn.net (localhost [IPv6:::1]) by thrintun.hactrn.net (Postfix) with ESMTP id 9918A22808 for ; Tue, 4 Mar 2008 12:36:31 -0500 (EST) Date: Tue, 04 Mar 2008 12:36:31 -0500 From: Rob Austein To: Tops-20 Wizards Subject: Re: Operation of TCP PSH flag under Tops-20? In-Reply-To: <47CD3B96.1090600@optonline.net> References: <47CC9AA3.9000504@optonline.net> <20080304045325.AE75B22808@thrintun.hactrn.net> <47CD3B96.1090600@optonline.net> 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: <20080304173631.9918A22808@thrintun.hactrn.net> ReSent-Date: Tue, 4 Mar 2008 15:05:34 -0800 (PST) ReSent-From: TOPS-20 List Moderator ReSent-To: TOPS-20 Distribution: ; ReSent-Subject: Re: Operation of TCP PSH flag under Tops-20? ReSent-Message-ID: ReSent-User-Agent: Alpine 1.00 (OSX 941 2008-03-03) PSH is a signal from the sending TCP to the receiving TCP that it should hand data to the receiving application now. The sending application can ask the sending TCP to set PSH, but the receiving application doesn't see it. PSH is unreliable (ie, it doesn't occupy TCP sequence space, therefore can't be ACKed), which argues quite strongly that it was never intended to be an application signal. 4-Mar-2008 15:14:53-PST,3272;000000000000 Return-Path: Received: from pangtzu.panda.com ([206.124.149.117]) by Lingling.Panda.COM with TCP/SMTP; Tue, 4 Mar 2008 15:06:37 -0800 (PST) X-Return-Path: X-Received: from sj-iport-6.cisco.com ([171.71.176.117]) by Lingling.Panda.COM with TCP/SMTP; Tue, 4 Mar 2008 14:44:12 -0800 (PST) X-Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-6.cisco.com with ESMTP; 04 Mar 2008 14:44:05 -0800 X-Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m24Mi5Ks012975; Tue, 4 Mar 2008 14:44:05 -0800 X-Received: from cisco.com (pita.cisco.com [171.71.177.199]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id m24Mi0XK004357; Tue, 4 Mar 2008 22:44:00 GMT X-Received: (from billw@localhost) by cisco.com (8.8.8-Cisco List Logging/8.8.8) id OAA27674; Tue, 4 Mar 2008 14:41:34 -0800 (PST) Sender: Bill Westfield Date: Tue, 4 Mar 2008 14:41:34 PST From: William "Chops" Westfield To: Thomas DeBellis Cc: TOPS-20 List Moderator , Rob Austein , Tops-20 Wizards Subject: Re: Operation of TCP PSH flag under Tops-20? In-Reply-To: Your message of Tue, 04 Mar 2008 07:07:50 -0500 Message-ID: DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=726; t=1204670645; x=1205534645; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=billw@cisco.com; z=From:=20William=20=22Chops=22=20Westfield=20 |Subject:=20Re=3A=20Operation=20of=20TCP=20PSH=20flag=20und er=20Tops-20? |Sender:=20Bill=20Westfield=20; bh=dHpl1VAX/MniFeDLUGdfknknqF8eZfAvNPvnrEV5p+U=; b=CSB4WmY4hlprpwy0BXZBhYUK4i4dyEwa1Snq+67fu2PQ9fZQGKbYFjkPvz azeEtqF3fQNyBJLx87GFg9VCAgWHtJx8sMqBNLTOwpfCEVugTYTj1/0JdWHP EnOXSkIhcYglOKlZloR6SIFqQW6OM0IRl2icZmCetfnxO7aC9IXtc=; Authentication-Results: sj-dkim-1; header.From=billw@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); ReSent-Date: Tue, 4 Mar 2008 15:06:15 -0800 (PST) ReSent-From: TOPS-20 List Moderator ReSent-To: TOPS-20 Distribution: ; ReSent-Subject: Re: Operation of TCP PSH flag under Tops-20? ReSent-Message-ID: ReSent-User-Agent: Alpine 1.00 (OSX 941 2008-03-03) Does this imply that only the application can set PSH? Maybe, but that's not the case. PSH is pretty deprecated; see RFC1122 for some discussion more recent than rfc793. In general, an application should not ever need to cause PSH to be set, nor depend on being able to see whether PSH was received, nor on whether PSH was ever received. I think that most "modern" implementations replace PSH functionality with an option in the receive path to get packets delivered to the application layer as soon as they are available. This is driven somewhat by larger packet sizes, faster CPUs, and the move of the tcp "window" from application space to a measure of network bandwidth and congestion. BillW 4-Mar-2008 20:26:48-PST,2558;000000000000 Return-Path: Received: from pangtzu.panda.com ([206.124.149.117]) by Lingling.Panda.COM with TCP/SMTP; Tue, 4 Mar 2008 20:21:57 -0800 (PST) X-Return-Path: X-Received: from pangtzu.panda.com ([206.124.149.117]) by Lingling.Panda.COM with TCP/SMTP; Tue, 4 Mar 2008 18:53:39 -0800 (PST) Date: Tue, 4 Mar 2008 18:53:34 -0800 (PST) From: Mark Crispin Sender: mrc@pangtzu.panda.com To: William Chops Westfield cc: Thomas DeBellis , Rob Austein , Tops-20 Wizards Subject: Re: Operation of TCP PSH flag under Tops-20? In-Reply-To: Message-ID: References: User-Agent: Alpine 1.00 (OSX 944 2008-03-05) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed ReSent-Date: Tue, 4 Mar 2008 20:21:50 -0800 (PST) ReSent-From: TOPS-20 List Moderator ReSent-To: TOPS-20 Distribution: ; ReSent-Subject: Re: Operation of TCP PSH flag under Tops-20? ReSent-Message-ID: ReSent-User-Agent: Alpine 1.00 (OSX 944 2008-03-05) On Tue, 4 Mar 2008, William Chops Westfield wrote: > PSH is pretty deprecated; see RFC1122 > for some discussion more recent than rfc793. In general, an > application should not ever need to cause PSH to be set, nor depend on > being able to see whether PSH was received, nor on whether PSH was > ever received. I agree with the second sentence, but not the first. I see nothing that implies that PSH is deprecated. In fact, RFC 1122 says: An application program is logically required to set the PUSH flag in a SEND call whenever it needs to force delivery of the data to avoid a communication deadlock. Now, with that said, the sockets interface on UNIX and Windows does not offer a way to set PSH, but rather sets PSH on a short segment following a delay where it seems that the application isn't going to provide any more data in the near future. I, personally, would prefer control over PSH in my applications and only send them when, based upon my knowledge, it is necessary; but that isn't the way that sockets works and I have to admit that it is easier to program if you don't have to worry about it. -- Mark -- http://panda.com/tops-20 TOPS-20: a great improvement over its successors 6-Mar-2008 21:39:16-PST,5231;000000000000 Return-Path: Received: from pangtzu.panda.com ([206.124.149.117]) by Lingling.Panda.COM with TCP/SMTP; Thu, 6 Mar 2008 21:34:05 -0800 (PST) X-Return-Path: X-Received: from mta2.srv.hcvlny.cv.net ([167.206.4.197]) by Lingling.Panda.COM with TCP/SMTP; Thu, 6 Mar 2008 18:45:33 -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 <0JXC00H5QABD3FQ0@mta2.srv.hcvlny.cv.net>; Thu, 06 Mar 2008 21:45:14 -0500 (EST) Date: Thu, 06 Mar 2008 21:45:12 -0500 From: Thomas DeBellis Subject: Re: Operation of TCP PSH flag under Tops-20? In-reply-to: To: Mark Crispin Cc: William Chops Westfield , Rob Austein , Tops-20 Wizards Message-id: <47D0AC38.3070606@optonline.net> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en References: User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) ReSent-Date: Thu, 6 Mar 2008 21:33:58 -0800 (PST) ReSent-From: TOPS-20 List Moderator ReSent-To: TOPS-20 Distribution: ; ReSent-Subject: Re: Operation of TCP PSH flag under Tops-20? ReSent-Message-ID: ReSent-User-Agent: Alpine 1.00 (OSX 954 2008-03-06) > I see nothing that implies that PSH is deprecated. In fact, RFC > 1122 says: > > An application program is logically required to set the PUSH > flag in a SEND call whenever it needs to force delivery of > the data to avoid a communication deadlock. > > Now, with that said, the sockets interface on UNIX and Windows does > not offer a way to set PSH, but rather sets PSH on a short segment > following a delay where it seems that the application isn't going to > provide any more data in the near future. > > I, personally, would prefer control over PSH in my applications and > only send them when, based upon my knowledge, it is necessary; but > that isn't the way that sockets works and I have to admit that it is > easier to program if you don't have to worry about it. The problem with transmitting paged file structures is that you have a 36 bit word stream with headers being stuffed into an 8 bit byte stream. Depending on where things 'unwrap' at the destination, you can wind up wedging on the end of stream. End of stream is commonly signaled via a closed connection, but in the case of paged file structures, it's a marker that is effectively masked by the byte stream. You can't tell where it is until you decode the byte stream, but you can't tell when to stop decoding the byte stream and process the data. That's an oversimplification (and not entirely correct), but the point is that if you know that you have an end of stream, you can take advantage of certain kinds of (simpler) buffering techniques. Right now, the end of a paged file structure stream is marked by a PSH. If this weren't done, then one might never break out of counted SIN%. So SINR% clearly knows about PSH and breaks when it gets one. The implementation of paged file structures under Tops-20 relies on this behavior. I would like to definitively know whether I got the PSH or not. A non-zero character count at the end of a SINR% definitively means that a PSH happened and I can immediately prepare end processing code. The only other case to be considered is that of a PSH happening at exactly the end of the buffer (I.E., SINR% returns with a zero character count). This is an ambiguity that is simple enough to handle, but it bugs me. .... I'd like to know .... With respect to the Windows and Unix paradigm: one is tempted to say that the lack of such an explicit mechanism is an 'un'-feature. When I think of the operating system waiting to determine whether to set PSH or not based on application behavior, I get the impression that things could be speeded up by the application directly signaling to do the push and not having to wait around for a (logical) timer to expire. And what if, for some reason (I can't think of any) the application isn't coded to adhere to the anticipated behavior? Lossage? I think an explicit mechanism to set PSH could yield superior performance. Some brief research shows that some of these PUSH decisions are made in the millisecond timeframe. But, on fast (gigabit and up) backbones, that's a lot of data. Setting the TCP_NODELAY is certainly an approach, but that has its own issues. I think SINR%/SOUTR% approach wins, but I'm obviously biased. And I also probably don't understand all of the other issues involved (I'm good at that ...) I guess the sequenced packet socket type (SOCK_SEQPACKET) really would be the appropriate solution here. 6-Mar-2008 21:43:11-PST,6140;000000000000 Return-Path: Received: from pangtzu.panda.com ([206.124.149.117]) by Lingling.Panda.COM with TCP/SMTP; Thu, 6 Mar 2008 21:35:47 -0800 (PST) X-Return-Path: X-Received: from mta5.srv.hcvlny.cv.net ([167.206.4.200]) by Lingling.Panda.COM with TCP/SMTP; Thu, 6 Mar 2008 20:04:28 -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 <0JXC00IISDZ8M0G0@mta5.srv.hcvlny.cv.net> for TOPS-20@Lingling.Panda.COM; Thu, 06 Mar 2008 23:04:22 -0500 (EST) Date: Thu, 06 Mar 2008 23:04:19 -0500 From: Thomas DeBellis Subject: Re: Reasonable column width? In-reply-to: To: William Chops Westfield Cc: Tops-20 Wizards Message-id: <47D0BEC3.8020108@optonline.net> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en References: User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) ReSent-Date: Thu, 6 Mar 2008 21:35:25 -0800 (PST) ReSent-From: TOPS-20 List Moderator ReSent-To: TOPS-20 Distribution: ; ReSent-Subject: Re: Reasonable column width? ReSent-Message-ID: ReSent-User-Agent: Alpine 1.00 (OSX 954 2008-03-06) > > It is an EXCELLENT game, well regarded as being one of the best > > 'Star Trek' games ever written due to the close adherence to the > > Star Fleet Technical Manual and the intellegence of the enemies. > I didn't know that! Yup, I'll bet you also didn't know that STAR was popular enough so that Marvin Kitman (THE media critic at Newsday) heard about it and (according to The Star God) was going to review it in his column, "The Marvin Kitman Show". In 1977. However, in a fit of visionary ineptitude worthy of Ken Olsen, he decided not to at the very last minute. Too bad, he would have been years ahead of everybody... > Heh. One of my classmates (from "Harborfields") took the size-one > galaxy high score for quite some time, I think. Probably, but not after I got my 2000 at home in late 1976 until we all graduated in 1977. What's interesting is that Chris went on to be a math major at RPI... He was pretty annoyed that he couldn't get to a PDP-10 there (one of the main reasons that I went to WPI, instead). > IIRC, size-1 strategy consisted of using repulser beams to push the > romulan out of the galaxy, and finishing off the klingon with > conventional weapons. In this particular game, the "repulser" step > caused the klingon and romulan to collide, destroying them both > rather quickly, and scoring something like 993 out of a possible > 1000 points... I don't remember, but that sounds about right (or at least familiar). Actually, I have to admit that I had to look at the ALGOL listing just now to even remember that repulsor beams existed. I thought it was only tractor beams... I seem to remember The Star God telling me that a 1000 was impossible because the enemies would have to die before you had a chance to shoot them in the first move. I think Chris finally got a 997, but it took him a LONG time to do this. And he had to keep getting it because the winners list was cleaned from time to time. I don't remember if this was automatic or whether The Star God did it. I do remember Chris whining to him to let him stay on it, though ... > > Yes, but writing an emulator would involve hacking something > > besides MACRO which I am flatly not interested in these days > The trick is to get someone else to do it for you! A haz-2000 to > VT100 converting telnet, or somesuch. Do you know whether the Star > haz-2000 code used only traditional cursor manipulation stuff, or > whether it used the haz foreground/background stuff? Oh? Who? Something has to decode the Hazeltine control stream... STAR made fairly sophisticated usage of the Haziltine 2000 foreground (bright) background (darker) intensity scheme. Bright characters were used to highlight the phaser and torpedo shots. That's obvious enough, but what was MUCH nicer was that explanatory text was displayed below the 'control screen' in foreground. The 2000 had a special clear screen function code to clear only the foreground text. This allowed it to quickly erase displayed messages--on other terminals this had to be done with multiple delete line calls (or something even more painful on an Adds Consul 520/580 ...) The terminal control logic in STAR is implemented in a seperate MACRO module called "CURSES"... This provides a callable interface to all HZ 2000 functions and wraps some to simulate others, such as relative cursoring which--aside from backspace--the 2000 lacked. This was annoying because you could move the cursor 'relatively' from the keyboard as well as insert and delete characters (which you also couldn't do programmatically). The 2000 was also notable for NOT implementing the line feed character. A carriage return did both and the line feed was silently munched. I believe this was to support its batch mode screen buffering implementation, but the details escape me. I do remember that what the 2000 batch mode did was EXACTLY what you wanted done in order to make the use of a half-duplex system (such as the Grumman DTSS on which we also had accounts) even remotely bearable. It really was a wonderful terminal. I sometimes wonder if CBF ever really used one (see INFO:TERMS.INFO). His review is full of inaccuracies. Another thing I have yet to update/correct... Finally, if you can't live without knowing more about this, some kind soul scanned the HZ2000 operating manual in and published it on the web: HI1004A_Hazeltine_2000_Operating_Manual_Jan1975.pdf (I have my own paper copy) 6-Mar-2008 21:52:30-PST,2477;000000000000 Return-Path: Received: from pangtzu.panda.com ([206.124.149.117]) by Lingling.Panda.COM with TCP/SMTP; Thu, 6 Mar 2008 21:48:11 -0800 (PST) X-Return-Path: X-Received: from pangtzu.panda.com ([206.124.149.117]) by Lingling.Panda.COM with TCP/SMTP; Thu, 6 Mar 2008 21:47:25 -0800 (PST) Date: Thu, 6 Mar 2008 21:47:19 -0800 (PST) From: Mark Crispin Sender: mrc@pangtzu.panda.com To: Thomas DeBellis cc: William Chops Westfield , Rob Austein , Tops-20 Wizards Subject: Re: Operation of TCP PSH flag under Tops-20? In-Reply-To: <47D0AC38.3070606@optonline.net> Message-ID: References: <47D0AC38.3070606@optonline.net> User-Agent: Alpine 1.00 (OSX 954 2008-03-06) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed ReSent-Date: Thu, 6 Mar 2008 21:48:03 -0800 (PST) ReSent-From: TOPS-20 List Moderator ReSent-To: TOPS-20 Distribution: ; ReSent-Subject: Re: Operation of TCP PSH flag under Tops-20? ReSent-Message-ID: ReSent-User-Agent: Alpine 1.00 (OSX 954 2008-03-06) On Thu, 6 Mar 2008, Thomas DeBellis wrote: > End of stream is commonly > signaled via a closed connection, but in the case of paged file > structures, it's a marker that is effectively masked by the byte > stream. You can't tell where it is until you decode the byte stream, > but you can't tell when to stop decoding the byte stream and process > the data. If it were me, I'd decode on the fly, and on input grab as much data as possible using SIBE% to get the count to use with SIN%. If SIBE% returns 0, then either do something else, or if you want to block do a single BIN%. Look at how TELNET does it. You do know about that property of SIBE%, don't you? I guess that it may be possible that the network is so much faster than the PDP-10 that the PDP-10 can't keep up, but even so, IMHO using SIBE% is still a better idea that relying upon PSH. What will your server do if it encounters a client that routinely sets PSH for no good reason? -- Mark -- http://panda.com/tops-20 TOPS-20: a great improvement over its successors 7-Mar-2008 08:55:21-PST,3955;000000000000 Return-Path: Received: from pangtzu.panda.com ([206.124.149.117]) by Lingling.Panda.COM with TCP/SMTP; Fri, 7 Mar 2008 08:50:15 -0800 (PST) X-Return-Path: X-Received: from nic.cafax.se ([192.71.228.17]) by Lingling.Panda.COM with TCP/SMTP; Fri, 7 Mar 2008 04:54:59 -0800 (PST) X-Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id m27Csp1Z003931; Fri, 7 Mar 2008 13:54:51 +0100 (MET) X-Received: (from bygg@localhost) by nic.cafax.se (8.13.7/8.12.11/Submit) id m27CspOu028867; Fri, 7 Mar 2008 13:54:51 +0100 (MET) Date: Fri, 7 Mar 2008 13:54:50 WET From: Johnny Eriksson To: TOPS-20 List Moderator , Tops-20 Wizards Subject: Re: Operation of TCP PSH flag under Tops-20? In-Reply-To: Your message of Thu, 06 Mar 2008 21:45:12 -0500 Message-ID: ReSent-Date: Fri, 7 Mar 2008 08:50:04 -0800 (PST) ReSent-From: TOPS-20 List Moderator ReSent-To: TOPS-20 Distribution: ; ReSent-Subject: Re: Operation of TCP PSH flag under Tops-20? ReSent-Message-ID: ReSent-User-Agent: Alpine 1.00 (OSX 954 2008-03-06) > > I see nothing that implies that PSH is deprecated. In fact, RFC > > 1122 says: > > > > An application program is logically required to set the PUSH > > flag in a SEND call whenever it needs to force delivery of > > the data to avoid a communication deadlock. > > > > Now, with that said, the sockets interface on UNIX and Windows does > > not offer a way to set PSH, but rather sets PSH on a short segment > > following a delay where it seems that the application isn't going to > > provide any more data in the near future. > > > > I, personally, would prefer control over PSH in my applications and > > only send them when, based upon my knowledge, it is necessary; but > > that isn't the way that sockets works and I have to admit that it is > > easier to program if you don't have to worry about it. > > The problem with transmitting paged file structures is that you have a > 36 bit word stream with headers being stuffed into an 8 bit byte > stream. Depending on where things 'unwrap' at the destination, you > can wind up wedging on the end of stream. End of stream is commonly > signaled via a closed connection, but in the case of paged file > structures, it's a marker that is effectively masked by the byte > stream. You can't tell where it is until you decode the byte stream, > but you can't tell when to stop decoding the byte stream and process > the data. > > That's an oversimplification (and not entirely correct), but the point > is that if you know that you have an end of stream, you can take > advantage of certain kinds of (simpler) buffering techniques. Right > now, the end of a paged file structure stream is marked by a PSH. If > this weren't done, then one might never break out of counted SIN%. So > SINR% clearly knows about PSH and breaks when it gets one. The > implementation of paged file structures under Tops-20 relies on this > behavior. The PSH flag is not, and has never been, a record marker. From RFC793, page 4: Sometimes users need to be sure that all the data they have submitted to the TCP has been transmitted. For this purpose a push function is defined. To assure that data submitted to a TCP is actually transmitted the sending user indicates that it should be pushed through to the receiving user. A push causes the TCPs to promptly forward and deliver data up to that point to the receiver. The exact push point might not be visible to the receiving user and the push function does not supply a record boundary marker. Note the last line of text. --Johnny 9-Mar-2008 19:55:30-PDT,4769;000000000000 Return-Path: Received: from pangtzu.panda.com ([206.124.149.117]) by Lingling.Panda.COM with TCP/SMTP; Sun, 9 Mar 2008 19:50:47 -0700 (PDT) X-Return-Path: X-Received: from mta3.srv.hcvlny.cv.net ([167.206.4.198]) by Lingling.Panda.COM with TCP/SMTP; Sun, 9 Mar 2008 19:05:30 -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 <0JXH00096SGZOBA0@mta3.srv.hcvlny.cv.net>; Sun, 09 Mar 2008 22:05:24 -0400 (EDT) Date: Sun, 09 Mar 2008 22:05:22 -0400 From: Thomas DeBellis Subject: Re: Operation of TCP PSH flag under Tops-20? In-reply-to: To: Mark Crispin Cc: William Chops Westfield , Rob Austein , Tops-20 Wizards Message-id: <47D49762.7080605@optonline.net> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en References: <47D0AC38.3070606@optonline.net> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) ReSent-Date: Sun, 9 Mar 2008 19:50:33 -0700 (PDT) ReSent-From: TOPS-20 List Moderator ReSent-To: TOPS-20 Distribution: ; ReSent-Subject: Re: Operation of TCP PSH flag under Tops-20? ReSent-Message-ID: ReSent-User-Agent: Alpine 1.00 (OSX 954 2008-03-06) > If it were me, I'd decode on the fly, and on input grab as much data > as possible using SIBE% to get the count to use with SIN%. If SIBE% > returns 0, then either do something else, or if you want to block do > a single BIN%. Look at how TELNET does it. Yes, this is what I'll have to do. It's not the end of the world, it's just harder than I thought (although certainly not back breaking). Once I finally figured out what the code for paged file structures was doing (sending over the wire), implementing it was relatively straightforward, easy and not horribly inefficient. But again, this is typically the slowest way to send a file, requires the most memory and processor time. Aside from that, it's pretty cool. Again, I'm going to see about changing the current FTP client to not use it unless it absolutely has to. So sending isn't that hard. Receiving is just going to need to be architected differently. > You do know about that property of SIBE%, don't you? I once did. Heh. Now I do again. Thanks. For some strange reason, I thought that SIBE% was only for terminals, but it would appear that I was quite wrong in that regard. > I guess that it may be possible that the network is so much faster > than the PDP-10 that the PDP-10 can't keep up, but even so, IMHO > using SIBE% is still a better idea that relying upon PSH. What will > your server do if it encounters a client that routinely sets PSH for > no good reason? Well, for stream mode transfers of file structures, not care. Or even notice. I sit in a SIN% loop. When the transfer is done, I get an EOF and clean up. Easy. I don't know anything about a PSH. I've talked to a bunch of FTP clients (and some servers for third party transfers) and didn't even know about PSH until I saw it being used by the Tops-20 FTP client when sending paged file structures. I still think it's a win for Tops-20 to give the user an ability to set PSH. I don't know about record structure (STRU R). Maybe if I ever find an EBCDIC system to talk to. The RFC959 seems to imply that block mode can keep the data connection open, but I don't implement that either. The Tops-20 FTP client implements block mode, but I don't recollect what it does with the data connection. Again, maybe if I ever get to something EBCDIC. So, the only thing that is going to be sending me paged file structures (and hence do a PSH) is the Tops-20 FTP client. I'll just have to code the server to not care about a PSH and do some sort of cute decoding. What other case would there be? Nobody else ever did paged file structures, did they? I seem to remember a company called FTP Software and that one of the employees posted a message to some FTP mailing list that I was on asking about regression testing and whether their client should implement paged file structures. I don't know anything else about it. 9-Mar-2008 19:59:05-PDT,2085;000000000000 Return-Path: Received: from pangtzu.panda.com ([206.124.149.117]) by Lingling.Panda.COM with TCP/SMTP; Sun, 9 Mar 2008 19:51:06 -0700 (PDT) X-Return-Path: X-Received: from mta5.srv.hcvlny.cv.net ([167.206.4.200]) by Lingling.Panda.COM with TCP/SMTP; Sun, 9 Mar 2008 19:05:48 -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-8.04 (built Feb 28 2007)) with ESMTP id <0JXH00EPHSH3A8F0@mta5.srv.hcvlny.cv.net> for TOPS-20@lingling.panda.com; Sun, 09 Mar 2008 22:05:28 -0400 (EDT) Date: Sun, 09 Mar 2008 22:05:26 -0400 From: Thomas DeBellis Subject: Re: Operation of TCP PSH flag under Tops-20? In-reply-to: To: Johnny Eriksson Cc: Tops-20 Wizards Message-id: <47D49766.1080500@optonline.net> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en References: User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) ReSent-Date: Sun, 9 Mar 2008 19:50:54 -0700 (PDT) ReSent-From: TOPS-20 List Moderator ReSent-To: TOPS-20 Distribution: ; ReSent-Subject: Re: Operation of TCP PSH flag under Tops-20? ReSent-Message-ID: ReSent-User-Agent: Alpine 1.00 (OSX 954 2008-03-06) > The PSH flag is not, and has never been, a record marker. From > RFC793, page 4: > > ... The exact push point might not be visible to the receiving > user and the push function does not supply a record boundary > marker. > > Note the last line of text. Well, that's that. But the other Tops-20 FTP software does a PSH when finished transmitting paged file structures, so I guess I'll do it, too. Don't see why it can hurt. Much. 11-Mar-2008 07:11:56-PDT,1705;000000000000 Return-Path: Received: from pangtzu.panda.com ([206.124.149.117]) by Lingling.Panda.COM with TCP/SMTP; Tue, 11 Mar 2008 07:06:49 -0700 (PDT) X-Return-Path: X-Received: from mta4.srv.hcvlny.cv.net ([167.206.4.199]) by Lingling.Panda.COM with TCP/SMTP; Mon, 10 Mar 2008 12:23:25 -0700 (PDT) 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 <0JXJ002JU4ILA291@mta4.srv.hcvlny.cv.net> for TOPS-20@lingling.panda.com; Mon, 10 Mar 2008 15:23:10 -0400 (EDT) Date: Mon, 10 Mar 2008 15:23:08 -0400 From: Thomas DeBellis Subject: DECUS library? To: Tops-20 Wizards Message-id: <47D58A9C.6040404@optonline.net> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) ReSent-Date: Tue, 11 Mar 2008 07:06:39 -0700 (PDT) ReSent-From: TOPS-20 List Moderator ReSent-To: TOPS-20 Distribution: ; ReSent-Subject: DECUS library? ReSent-Message-ID: ReSent-User-Agent: Alpine 1.00 (OSX 954 2008-03-06) Aside from the tapes on Trailing Edge, is there other stuff from the DECUS catalog online, or otherwise? Trailing Edge doesn't have the complete library and there were things put in there in the 1980's that I'd like to get. Anybody know anything further about this? Some archive at HP? 11-Mar-2008 07:15:49-PDT,7088;000000000000 Return-Path: Received: from pangtzu.panda.com ([206.124.149.117]) by Lingling.Panda.COM with TCP/SMTP; Tue, 11 Mar 2008 07:07:42 -0700 (PDT) X-Return-Path: X-Received: from smtp123.sbc.mail.sp1.yahoo.com ([69.147.64.96]) by Lingling.Panda.COM with TCP/SMTP; Tue, 11 Mar 2008 04:51:50 -0700 (PDT) X-Received: (qmail 50811 invoked from network); 11 Mar 2008 11:51:44 -0000 X-Received: from unknown (HELO ?204.238.239.100?) (tymshare@att.net@71.141.132.105 with plain) by smtp123.sbc.mail.sp1.yahoo.com with SMTP; 11 Mar 2008 11:51:43 -0000 X-YMail-OSG: 9eLmuuMVM1lB2T_jN0HTnR0Z1B_9rOF2VxYnTyg8.wej6sWrWUCmQp4kQjO1egE8y_E- X-Yahoo-Newman-Property: ymail-5 Cc: Tops-20 Wizards Message-Id: <97A12DA4-AD5E-4933-99D4-C21450B7C58C@reststop.com> From: Carl Baltrunas To: Thomas DeBellis In-Reply-To: <47D0AC38.3070606@optonline.net> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v919.2) Subject: Re: Operation of TCP PSH flag under Tops-20? Date: Tue, 11 Mar 2008 04:51:40 -0700 References: <47D0AC38.3070606@optonline.net> X-Mailer: Apple Mail (2.919.2) ReSent-Date: Tue, 11 Mar 2008 07:07:32 -0700 (PDT) ReSent-From: TOPS-20 List Moderator ReSent-To: TOPS-20 Distribution: ; ReSent-Subject: Re: Operation of TCP PSH flag under Tops-20? ReSent-Message-ID: ReSent-User-Agent: Alpine 1.00 (OSX 954 2008-03-06) On Mar 6, 2008, at 6:45 PM, Thomas DeBellis wrote: > > I see nothing that implies that PSH is deprecated. In fact, RFC > > 1122 says: > > > > An application program is logically required to set the PUSH > > flag in a SEND call whenever it needs to force delivery of > > the data to avoid a communication deadlock. > > > > Now, with that said, the sockets interface on UNIX and Windows does > > not offer a way to set PSH, but rather sets PSH on a short segment > > following a delay where it seems that the application isn't going to > > provide any more data in the near future. > > > > I, personally, would prefer control over PSH in my applications and > > only send them when, based upon my knowledge, it is necessary; but > > that isn't the way that sockets works and I have to admit that it is > > easier to program if you don't have to worry about it. > > The problem with transmitting paged file structures is that you have a > 36 bit word stream with headers being stuffed into an 8 bit byte > stream. Depending on where things 'unwrap' at the destination, you > can wind up wedging on the end of stream. End of stream is commonly > signaled via a closed connection, but in the case of paged file > structures, it's a marker that is effectively masked by the byte > stream. You can't tell where it is until you decode the byte stream, > but you can't tell when to stop decoding the byte stream and process > the data. On TYMCOM-X (Sorry, not TOPS-20) with the designed-in mechanism that all connections were via TYMNET, we had similar issues with data transmitted to terminals and to other host systems. TYMNET implemented an out-of-band ball logic, where a yellow-ball was sent down the pipe and when it reached the destination of the pipe, an orange-ball was reflected back, also out-of-band from the data, and you could catch an interrupt on receipt of a yellow or orange ball to know that all the data was sent (for now). This could be done at an EOF, or the equivalent of and EOL (which might have been before an EOL was sent in the case of a data prompt to a terminal requesting a reply. This sounds very much like the PSH to indicate that this is all the current data (for now) and we are waiting for a reply, or an EOF. When a connection is finally terminated, it can require a yellow-ball to be sent (or not) which will wait until all the data has reached the end of the pipe before disconnecting the circuit. This allows the PDP-10 side to disconnect even though the other end of the connection is back-pressured (i.e. ^S/^Q), and the destination end will not lose any data, as it is waiting for the EOF which is indicated by the receipt of a yellow-ball (though it is is out-of- band a yellow-ball sits in the pipe just behind all the data, whereas an orange-ball is passed on, potentially bypassing data which is back-pressured). When received, it knows that it can terminate its half of the connection. So, PSH sounds like a good feature. Too bad there is no reliable way to insure that it is received, and act accordingly. This is one of the ways that TYMCOM-X differs from TOPS-20 (and TOPS-10) as it is native to talking to a wide area network via the Tymnet interface. Echo control is also enabled so that the local node can perform echo, or leave the echo to be done by the host (much slower with long network delays, as well as speed of light delays when connected to a remote host half-way around the world). This is one of the features I certainly miss in UNIX and other systems. > > > That's an oversimplification (and not entirely correct), but the point > is that if you know that you have an end of stream, you can take > advantage of certain kinds of (simpler) buffering techniques. Right > now, the end of a paged file structure stream is marked by a PSH. If > this weren't done, then one might never break out of counted SIN%. So > SINR% clearly knows about PSH and breaks when it gets one. The > implementation of paged file structures under Tops-20 relies on this > behavior. Makes perfect sense to me in this case. I'm not sure why there should be an issue with decoding the data, as a paged file should always be a multiple of the page size, except maybe for the final page, end-filled with zeroes. > > > I would like to definitively know whether I got the PSH or not. A > non-zero character count at the end of a SINR% definitively means that > a PSH happened and I can immediately prepare end processing code. The > only other case to be considered is that of a PSH happening at exactly > the end of the buffer (I.E., SINR% returns with a zero character > count). This is an ambiguity that is simple enough to handle, but it > bugs me. .... I'd like to know .... > > I think an explicit mechanism to set PSH could yield superior > performance. Some brief research shows that some of these PUSH > decisions are made in the millisecond timeframe. But, on fast > (gigabit and up) backbones, that's a lot of data. Setting the > TCP_NODELAY is certainly an approach, but that has its own issues. For a networked system I have to agree. Not sure whether TCP_NODELAY is enough, as it does cause it's own set of problems with potential back-pressure issues. 11-Mar-2008 15:34:01-PDT,7790;000000000000 Return-Path: Received: from pangtzu.panda.com ([206.124.149.117]) by Lingling.Panda.COM with TCP/SMTP; Tue, 11 Mar 2008 15:28:57 -0700 (PDT) X-Return-Path: X-Received: from mta1.srv.hcvlny.cv.net ([167.206.4.196]) by Lingling.Panda.COM with TCP/SMTP; Tue, 11 Mar 2008 12:15:29 -0700 (PDT) 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 <0JXK002D4YT715C0@mta1.srv.hcvlny.cv.net> for TOPS-20@Lingling.Panda.COM; Tue, 11 Mar 2008 15:15:09 -0400 (EDT) Date: Tue, 11 Mar 2008 15:15:02 -0400 From: Thomas DeBellis Subject: Re: Operation of TCP PSH flag under Tops-20? In-reply-to: <97A12DA4-AD5E-4933-99D4-C21450B7C58C@reststop.com> To: Carl Baltrunas Cc: Tops-20 Wizards Message-id: <47D6DA36.5060101@optonline.net> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en References: <47D0AC38.3070606@optonline.net> <97A12DA4-AD5E-4933-99D4-C21450B7C58C@reststop.com> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) ReSent-Date: Tue, 11 Mar 2008 15:28:39 -0700 (PDT) ReSent-From: TOPS-20 List Moderator ReSent-To: TOPS-20 Distribution: ; ReSent-Subject: Re: Operation of TCP PSH flag under Tops-20? ReSent-Message-ID: ReSent-User-Agent: Alpine 1.00 (OSX 958 2008-03-11) > > You can't tell where it is until you decode the byte stream, but > > you can't tell when to stop decoding the byte stream and process > > the data. > TYMNET implemented an out-of-band ball logic, where a yellow-ball > was sent down the pipe and when it reached the destination of the > pipe, an orange-ball was reflected back, also out-of-band from the > data, and you could catch an interrupt on receipt of a yellow or > orange ball to know that all the data was sent (for now). Orange and yellow balls???? How were these names picked and what do they mean? [I'm a new father tripping over lots of little blue and red balls around the playroom] However, an out of band transmission marker sounds like it is probably exactly what I wanted in the first place. TCP can do this. Is out-of-band delivery reliable? It seems so (it's in the TCP header), so perhaps I can publish that capability with FEAT (see RFC2389) and then condition the Tops-20 FTP client to use it (if it exists) with an OPTS or SITE. It already has some code that could be adapted to do something like this. For example, the Tops-20 FTP client checks (in such a way as to not be 100% accurate) to see if it is talking to another 20 or 36 bit machine. > So, PSH sounds like a good feature. Too bad there is no reliable way > to insure that it is received, and act accordingly. I'm not sure whether I have enough information to immediately agree or disagree. From what I understand, "an application can force delivery of octets to the output stream using a push operation provided by TCP to the application layer. This operation also causes TCP to set the PSH flag or control bit to ensure that data will be delivered immediately to the application layer by the receiving transport layer." =========== <- emphasis mine The PSH flag is defined in the TCP header (bit offset 96, after the acknowledgement number) which means that the delivery is reliable and it gets to the receiving stack. So that means that the receiving stack knows about it and that only an application (should have) initiated it. As to what the receiving application does with it afterwards... But I have some tests that I'm going to run later to find out some more about all of this. > This is one of the features I certainly miss in UNIX and other > systems. Oh, yeah? You want a list of things that I miss when I'm using UNIX? Yeah... That would be so long that MRC would probably record record traffic for the Tops-20 list for the year of 2008 before the end of this week! > I'm not sure why there should be an issue with decoding the data, as > a paged file should always be a multiple of the page size, except > maybe for the final page, end-filled with zeroes. No. There are two problems here. First, nearly all files (even text) have unfilled pages at the end. So that case alone is enough to break an accurate prediction. Binary files are another thing entirely. I wasn't convinced of how much the zero clipping code would win, so I put in some code to gather some statistics while I was developing it. The results were not immediately overwhelming. Here is some data: Program File Trailing Simple Total Access Total Or Length Words Header Words Header Words File (Pages) Clipped Words Saved Words Saved ========== ======= ======== ====== ===== ====== ===== TTYLOC.BIN 2 467 8 459 10 457 MONITR.EXE 644 4,256 2,576 1,680 3,220 1,036 EXEC.EXE 173 1,145 692 453 865 280 EMACS.EXE 13 1,072 52 1,020 65 1,007 TECPUR.EXE 11 896 44 852 44 852 JSYSREF 701 48 2,804 -2,756 3,505 -3,457 See what I mean? Given the lack of space saved and accounting for the four to five word overhead for the per-page header, you are not better off using STRU F (no record file structures) and Type I (image mode) in all cases. For the monitor, you'd save about three pages over the wire. But with ASCII files, you're sending five extra pages. So either using paged file structures either doesn't win a lot, isn't really buying you that much or loses (but see below). Particularly with ASCII files, you're better off with straight image type file structures, assuming you are going to another 36 bit machine. To review the ASCII example: for the 701 page JSYS reference file in PS: Received: from pangtzu.panda.com ([206.124.149.117]) by Lingling.Panda.COM with TCP/SMTP; Tue, 11 Mar 2008 20:22:24 -0700 (PDT) X-Return-Path: X-Received: from mail2.panix.com ([166.84.1.73]) by Lingling.Panda.COM with TCP/SMTP; Tue, 11 Mar 2008 17:42:28 -0700 (PDT) X-Received: from panix5.panix.com (panix5.panix.com [166.84.1.5]) by mail2.panix.com (Postfix) with ESMTP id 778193480F for ; Tue, 11 Mar 2008 20:42:22 -0400 (EDT) X-Received: by panix5.panix.com (Postfix, from userid 17662) id 6171B241F0; Tue, 11 Mar 2008 20:42:22 -0400 (EDT) From: Rich Alderson To: TOPS-20@lingling.panda.com In-reply-to: <47D58A9C.6040404@optonline.net> (message from Thomas DeBellis on Mon, 10 Mar 2008 15:23:08 -0400) Subject: Re: DECUS library? References: <47D58A9C.6040404@optonline.net> Message-Id: <20080312004222.6171B241F0@panix5.panix.com> Date: Tue, 11 Mar 2008 20:42:22 -0400 (EDT) ReSent-Date: Tue, 11 Mar 2008 20:22:15 -0700 (PDT) ReSent-From: TOPS-20 List Moderator ReSent-To: TOPS-20 Distribution: ; ReSent-Subject: Re: DECUS library? ReSent-Message-ID: ReSent-User-Agent: Alpine 1.00 (OSX 958 2008-03-11) > Date: Mon, 10 Mar 2008 15:23:08 -0400 > From: Thomas DeBellis > Aside from the tapes on Trailing Edge, is there other stuff from the DECUS > catalog online, or otherwise? Trailing Edge doesn't have the complete > library and there were things put in there in the 1980's that I'd like to > get. Anybody know anything further about this? Some archive at HP? HP has no archive of DECUS software. When Compaq sold itself to HP, the DECUS libraries (such as they were by that point) were dismantled. XKL bought a "complete" set of DECUS 36-bit tapes c. 1992; I loaned those to Tim about 10 years later. As far as I know, that's all the DECUS stuff left in existence. Rich 15-Mar-2008 19:19:48-PDT,2665;000000000000 Return-Path: Received: from pangtzu.panda.com ([206.124.149.117]) by Lingling.Panda.COM with TCP/SMTP; Sat, 15 Mar 2008 19:14:30 -0700 (PDT) X-Return-Path: X-Received: from mail.kahealani.net ([64.65.108.250]) by Lingling.Panda.COM with TCP/SMTP; Fri, 14 Mar 2008 15:17:03 -0700 (PDT) X-Received: by mail.kahealani.net (Postfix, from userid 295) id 37C214F4043; Fri, 14 Mar 2008 12:16:53 -1000 (HST) From: Angela Kahealani Organization: ANGELA KAHEALANI To: TOPS-20 List Moderator , TOPS-20 Wizards Subject: TOPS-20 on KLH-10 on Linux Date: Fri, 14 Mar 2008 12:16:52 -1000 User-Agent: KMail/1.9.6 (enterprise 0.20070907.709405) References: <47C22303.4080109@optonline.net> In-Reply-To: Disposition-Notification-To: Angela Kahealani MIME-Version: 1.0 Content-Type: text/plain; charset="ansi_x3.4-1968" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200803141216.52924.angela@kahealani.com> ReSent-Date: Sat, 15 Mar 2008 19:14:18 -0700 (PDT) ReSent-From: TOPS-20 List Moderator ReSent-To: TOPS-20 Distribution: ; ReSent-Subject: TOPS-20 on KLH-10 on Linux ReSent-Message-ID: ReSent-User-Agent: Alpine 1.10 (OSX 962 2008-03-14) Aloha, Does anyone have a useful pointer (along the lines of, "go RTFM, this FM at some URL") about how to properly configure Linux to: 1. stay out of the way of TOPS-20 using its own ethernet interface? 2. stay out of the way of TOPS-20 using the parallel port for the Panda Panel? (this implies the KLH-10 emulator). 3. where do I RTFM to understand how to join HECNET, and whether I will need my own DECNET "area" to do so? As someone new to the PDP-10 architecture, I've only archived 19 GigaBytes of code and documentation, and not having had time to read through all of that, I'd appreciate the effectiveness of a little guru guidance on where to start. Oh, sure, I was once an actual USER of TOPS-20, but only now am I beginning to learn how to install and administer a Panda TOPS20 KLH-10. So, would someone care to tell me which FM to go RTFM? Aloha, Angela Kahealani -- "(I'll) Be Seeing You..." All information and transactions are private between the parties, and are non negotiable. All rights reserve without prejudice Angela Kahealani. http://kahealani.com 15-Mar-2008 19:34:46-PDT,4245;000000000000 Return-Path: Received: from pangtzu.panda.com ([206.124.149.117]) by Lingling.Panda.COM with TCP/SMTP; Sat, 15 Mar 2008 19:30:54 -0700 (PDT) X-Return-Path: X-Received: from mxout5.cac.washington.edu ([140.142.32.135]) by Lingling.Panda.COM with TCP/SMTP; Sat, 15 Mar 2008 19:30:38 -0700 (PDT) X-Received: from smtp.washington.edu (smtp.washington.edu [140.142.32.141] (may be forged)) by mxout5.cac.washington.edu (8.13.7+UW06.06/8.13.7+UW07.09) with ESMTP id m2G2UU2i015123 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 15 Mar 2008 19:30:30 -0700 X-Auth-Received: from Shimo-Tomobiki.Panda.COM (x104223.dynamic.ppp.asahi-net.or.jp [122.249.104.223]) (authenticated authid=mrc) by smtp.washington.edu (8.13.7+UW06.06/8.13.7+UW07.09) with ESMTP id m2G2UPcw023492 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Sat, 15 Mar 2008 19:30:28 -0700 Date: Sun, 16 Mar 2008 11:30:18 +0900 From: Mark Crispin To: Angela Kahealani cc: TOPS-20 Wizards Subject: Re: TOPS-20 on KLH-10 on Linux In-Reply-To: <200803141216.52924.angela@kahealani.com> Message-ID: References: <47C22303.4080109@optonline.net> <200803141216.52924.angela@kahealani.com> User-Agent: Alpine 1.00 (WNT 958 2008-03-11) Organization: Networks & Distributed Computing Sender: mrc@ndcms.cac.washington.edu MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-PMX-Version: 5.4.1.325704, Antispam-Engine: 2.6.0.325393, Antispam-Data: 2008.3.15.191548 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 Mar 2008 19:30:47 -0700 (PDT) ReSent-From: TOPS-20 List Moderator ReSent-To: TOPS-20 Distribution: ; ReSent-Subject: Re: TOPS-20 on KLH-10 on Linux ReSent-Message-ID: ReSent-User-Agent: Alpine 1.10 (OSX 962 2008-03-14) Hi Angela - Unlike the UNIX community, the TOPS-20 people are generally not "RTFM" type of people; however there's quite a bit more of either stuff not written down at all (and thus only known to folklore) or is written down but not completely useful. Here's a couple of quick notes that will help you on your way, and hopefully help you to ask more specific questions. The klh10-2.0h/doc/usage.txt file is quite helpful, as is cmdref.txt, in configuring your klt20.ini file. The Panda distribution already has much of what's needed set up properly (although you probably want to set fe_runenable ... later versions do that). On my system with a dedicated Ethernet interface to TOPS-20, I have the command defdef ni0 564 ni20 dedic=true ifc=eth1 IIRC, the only stuff that I had to do on the Linux end (since I wasn't otherwise using eth1) was to make it work with DECnet. I had to set the MAC address for DECnet in Linux while the interface was down, since it wouldn't let me change the MAC address while it was up. If you're not going to do DECnet I wouldn't worry about it (but see below). I didn't do anything special in the Linux end for the parallel port; I just defined it in klt20.ini (the default klt20.ini has a suitable definition albeit commented out) and then went from there. As for DECnet...you'll find that there's a lot of "too much documentation" of what you don't care about and "no documentation" for what you do care about. As noted above, I remember having to futz around in Linux startup to set the MAC address the way DECnet wants (thus making TOPS-20's setting it to the same thing being a no-op) but I have yet to actually get DECnet to work so I'm probably not a good source of information here. Maybe someone else can do better. Good luck. -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum. 20-Mar-2008 08:58:36-PDT,7483;000000000000 Return-Path: Received: from pangtzu.panda.com ([206.124.149.117]) by Lingling.Panda.COM with TCP/SMTP; Thu, 20 Mar 2008 08:53:22 -0700 (PDT) X-Return-Path: X-Received: from mta4.srv.hcvlny.cv.net ([167.206.4.199]) by Lingling.Panda.COM with TCP/SMTP; Sun, 16 Mar 2008 11:45:51 -0700 (PDT) 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 <0JXU00EJJ6S6QB40@mta4.srv.hcvlny.cv.net> for TOPS-20@lingling.panda.com; Sun, 16 Mar 2008 14:45:45 -0400 (EDT) Date: Sun, 16 Mar 2008 14:45:41 -0400 From: Thomas DeBellis Subject: Re: TOPS-20 on KLH-10 on Linux In-reply-to: To: Angela Kahealani Cc: TOPS-20 Wizards Message-id: <47DD6AD4.4060801@optonline.net> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en References: <47C22303.4080109@optonline.net> <200803141216.52924.angela@kahealani.com> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) ReSent-Date: Thu, 20 Mar 2008 08:53:14 -0700 (PDT) ReSent-From: TOPS-20 List Moderator ReSent-To: TOPS-20 Distribution: ; ReSent-Subject: Re: TOPS-20 on KLH-10 on Linux ReSent-Message-ID: ReSent-User-Agent: Alpine 1.10 (OSX 962 2008-03-14) Angela, If possible, I would suggest that you get a second Ethernet interface for Tops-20's exclusive use. They can be had for very little money these days. I have seen them for as little as $15. Or even free: you can often yank them from machines that are being thrown out--left on the streets. There are many reasons for and advantages of interface exclusivity. If you are going to try to get DECnet on the air, then you might get to the point where you are going to need to snoop packets off of the wire (by using Ethereal, for example). I have had to do this while developing the new Tops-20 FTP server (and have discovered that I will need to do so again when debugging the incredibly arcane and nearly unused case of a third party transfer to the old BBN Tops-20 FTP server from the new one). Don't ask--it's too horrible for words. That being the case, being able to select packet collection via MAC address is nearly essential. If you have the situation where Unix and Tops-20 are sharing the interface (and hence the MAC address), this can be impossible to do. Even if you have no intention of indulging in the True Joy of reverse engineering undocumented protocols, you may still want to be able to send a packet trace to somebody who does (me, for example). Moreover, my belief is that--at one point--DECnet may have been doing some 'special' things by directly modifying the MAC address of the PDP-10's Ethernet adaptor to elminate the need for implementing a DECnet based ARP. If it still does this and attempts to do so to a shared adaptor, then you may have the case where both your Tops-20 machine and its host go completely 'Off The Air'. Having an additional adaptor can provide you with additional security. Right now, my Tops-20 machine is behind a firewall, while the Linux box isn't (usually). If you have a shared adaptor, then this can be less straightforward to do. With regards to DECnet communication itself: that may be problematic. You don't have many choices. If backward compatibility hasn't been broken with VMS (this happened at one point), then you can talk to some flavor of a VAX. As to why you'd want to do that... Don't get me started on VMS... At one point, you could purchase DECnet for Windows and such packages have surfaced on eBay (I got one for a very reasonable bid). I use the LAT component on my machines for local communications in the house. Otherwise, even if HP is still selling DECnet/LAT for Windows, then the price may be more than you want to pay. Further, from my own (admittedly anecdotal) evidence, the performance of most terminal emulators that use DECnet/LAT is abysmal. Slow. Kermit 95 is a notable exception. I have no information on firmware solutions, yet. Such terminal concentrators do surface on eBay, but the price hasn't seemed reasonable to me (I.E., $400 instead of $40). I plan on spending my money by rewarding myself with a PANDA front panel once my FTP server Alpha candidate is complete. And maybe at some point the price of such terminal concentrators will be more closely aligned with reality. Another alternative is a Linux. There is a open source version of DECnet/LAT, but at least the lasttime I checked that doesn't appear to have been developed for some time. Worse, the current programs have very little error recovery. Actually, I must translate that last sentence from Unix-Speak: no error recovery whatsoever. No error message. Nothing. And debugging a Unix program that has unexpectedly gronked can be difficult. This must be compared with the ease with which Tops-20 facilitates post-mortems. While fixing the bug itself may be difficult, using DDT is still Sheer Heaven as compared some other excuses for debugging environments I might gripe about. On the other hand, you could also use DECnet to talk to another winning Tops-20 system. And that would mean that you'd have Two (2) Tops-20 systems instead of One (1), which surely must be a most highly laudable state of affairs. As far as RTFM is concerned, this is your opportunity to Do Something About It. Find something in Tops-20 to develop or champion. I'm the FTP and Galaxy champion. I mean finding bugs and--more importantly-- fixing them. Even if you don't program, there are other things to do. Documentation bugs, for example. If you find something confusing, incorrectly documented or not documented to your satisfaction, fix it. Write a new document the way you think it should be. I've done this for queued shutdowns also known as ^E cease (and still have to get off my ... to submit it to Mark). Actually, after I'm done sending this message, I'll send the shutdown document to Mark and a copy to you as an example of what I mean. And if you come across Tops-20 (or even Tops-10) software that is otherwise unavailble, be sure to share it so that it isn't lost. This has regrettably happened too many times. Heartbreaking. Finally, I would like to take the opportunity to disagree with Mark about something. Most Tops-20 people are some of the finest Ladies and Gentlemen that the Dear Lord God has ever caused to draw breath. There just isn't any way to compare us with the rest of the misinformed individuals out there masquerading as being actually knowledgeable about computing and The Right Way to Do Things. Regretfully, we are (most of us) busy and don't get paid (yet) to do anything on Tops-20. One hopes that this deplorable state of affairs is speedily remedied. In the meantime, we sometimes won't be able to help as much as we'd like. Kindest Regards, --T 22-Mar-2008 18:00:14-PDT,2555;000000000000 Return-Path: Received: from pangtzu.panda.com ([206.124.149.117]) by Lingling.Panda.COM with TCP/SMTP; Sat, 22 Mar 2008 17:55:02 -0700 (PDT) X-Return-Path: X-Received: from mta5.srv.hcvlny.cv.net ([167.206.4.200]) by Lingling.Panda.COM with TCP/SMTP; Fri, 21 Mar 2008 15:05:38 -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-8.04 (built Feb 28 2007)) with ESMTP id <0JY300AUCPD41GK0@mta5.srv.hcvlny.cv.net> for TOPS-20@lingling.panda.com; Fri, 21 Mar 2008 18:05:28 -0400 (EDT) Date: Fri, 21 Mar 2008 18:05:27 -0400 From: Thomas DeBellis Subject: EPCAP% does not respect SC%SUP To: Tops-20 Wizards Message-id: <47E43127.9060006@optonline.net> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) ReSent-Date: Sat, 22 Mar 2008 17:54:53 -0700 (PDT) ReSent-From: TOPS-20 List Moderator ReSent-To: TOPS-20 Distribution: ; ReSent-Subject: EPCAP% does not respect SC%SUP ReSent-Message-ID: ReSent-User-Agent: Alpine 1.10 (OSX 962 2008-03-14) I was just fixing a bug in my EFTPSR code (not having SC%GTB must force TVFS mode off), when I noticed some unexpected behavior in EPCAP%: it never allows you to change the capabilities of the superior, even if you have SC%SUP and it is enabled. In FORK.MAC at EPCNGO+3, .EPCAP calls SKIIF to see if the caller is trying to manipulate the capabilities of itself or an inferior. If this isn't the case, then it fails the JSYS with a FRKHX2. What is interesting is that this code obviously does NOT respect SC%SUP. So even if the superior fork has allowed an inferior to manipulate itself, the inferior can not side-effect the superior's CAPMSK or CAPENB. I verified this with a short program. I'm not saying that I have to do this, I was just surprised to find that I couldn't. This error is mentioned in MONREF, but it isn't explicitly made clear that--no matter what--you can't change the capability vector of any process but your own or one of your inferior processes. One might be tempted to call this a documentation 'sub-feature'. ... But that would be nit-picking ... 12-Apr-2008 18:15:15-PDT,3281;000000000000 Return-Path: Received: from pangtzu.panda.com ([206.124.149.117]) by Lingling.Panda.COM with TCP/SMTP; Sat, 12 Apr 2008 18:09:43 -0700 (PDT) X-Return-Path: X-Received: from mta1.srv.hcvlny.cv.net ([167.206.4.196]) by Lingling.Panda.COM with TCP/SMTP; Sat, 12 Apr 2008 15:34:29 -0700 (PDT) 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 <0JZ8002LMHCYBOW2@mta1.srv.hcvlny.cv.net> for TOPS-20@lingling.panda.com; Sat, 12 Apr 2008 18:34:10 -0400 (EDT) Date: Sat, 12 Apr 2008 18:34:09 -0400 From: Thomas DeBellis Subject: %Problem on device: MTA0 To: Tops-20 Wizards Message-id: <480138E1.4040707@optonline.net> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) ReSent-Date: Sat, 12 Apr 2008 18:09:35 -0700 (PDT) ReSent-From: TOPS-20 List Moderator ReSent-To: TOPS-20 Distribution: ; ReSent-Subject: %Problem on device: MTA0 ReSent-Message-ID: ReSent-User-Agent: Alpine 1.10 (OSX 1031 2008-04-10) I just finished doing my quarterly full backup (you're all doing backups, right?) and I got the following: 12-Apr-2008 16:16:02 ***BUGINF OVRDTA*** PHYSIO - Overdue transfer aborted, Data: 1, 0, 0, 3 12-Apr-2008 16:16:33 ***BUGINF PH2DNA*** PHYH2 - Done interrupt and channel not active, Data: 1 %Problem on device: MTA0, S.N.=1 Access Path: CHN=1, TM03=0, UNI=0 12-Apr-2008 16:24:41 ***BUGINF OVRDTA*** PHYSIO - Overdue transfer aborted, Data: 1, 0, 0, 3 12-Apr-2008 16:24:43 ***BUGINF PH2DNA*** PHYH2 - Done interrupt and channel not active Job: 11, User: SLOGIN, Data: 1 The batch job itself got: Tape went offline or encountered device error, type to try again. Tape went offline or encountered device error, type to try again. I have some distinctly UN-fond memories of seeing these messages on machines whose tape drives were in the process of going bad. What would they mean here? More importantly, is my backup suspect? Old habits told me that it wasn't. As at this point, the system load had cleared 4.0, I stopped the batch job and had a look around. I saw that it was backing up thousands of small files: my extended FTP server log files. That really slams the file system, so on a hunch I got rid of them all and continued the back job. It then finished with no further complaints... I wonder why? Anyway, I re-ran the backup just to make sure and that worked okay, too. As an aside, I started deleting the files with the EXEC, but that was running slowly also--I think two files a second (I'm sure I remember CU20B being faster). So, I used the extended FTP server's DELE command which is implemented with DELNF%. Boy, that JSYS is REALLY FAST--it whacked over 3,400 files in a little over five seconds. It almost makes me want to modify the EXEC to use it... 13-Apr-2008 15:05:21-PDT,11630;000000000000 Return-Path: Received: from pangtzu.panda.com ([206.124.149.117]) by Lingling.Panda.COM with TCP/SMTP; Sun, 13 Apr 2008 14:59:57 -0700 (PDT) X-Return-Path: X-Received: from mta5.srv.hcvlny.cv.net ([167.206.4.200]) by Lingling.Panda.COM with TCP/SMTP; Sun, 13 Apr 2008 12:16:05 -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-8.04 (built Feb 28 2007)) with ESMTP id <0JZA001VS2UB5NY2@mta5.srv.hcvlny.cv.net> for TOPS-20@lingling.panda.com; Sun, 13 Apr 2008 15:15:47 -0400 (EDT) Date: Sun, 13 Apr 2008 15:15:46 -0400 From: Thomas DeBellis Subject: %Problem on device: MTA0, Part 2 In-reply-to: <480138E1.4040707@optonline.net> To: Tops-20 Wizards Message-id: <48025BE2.10904@optonline.net> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en References: <480138E1.4040707@optonline.net> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) ReSent-Date: Sun, 13 Apr 2008 14:59:39 -0700 (PDT) ReSent-From: TOPS-20 List Moderator ReSent-To: TOPS-20 Distribution: ; ReSent-Subject: %Problem on device: MTA0, Part 2 ReSent-Message-ID: ReSent-User-Agent: Alpine 1.10 (OSX 1031 2008-04-10) It turns out that the original backup that I did wasn't complete and that I was right to rerun it. But not for the obvious (to me) reason. The sharp-eyed among you may have noticed that I did not include the exact lines from the batch log file DUMPER. They are these: 16:41:35 USER % 16:41:35 USER $Tape went offline or encountered device error, type to try again. *Save /Full-Incremental STAR:<*>*.*.* Notice the leading "$"? It's there for a reason. When DUMPER detects that it is being controlled by a PTY, it changes the leading character for messages which request user intervention to a "$", which according to the Batch standard, causes BATCON to get the next line of input from anyone running OPR instead of from the batch file. As can be seen, in this case the dollar sign talisman was not processed by BATCON and the next command in the batch file (a SAVE) was then swallowed. So, there are two concerns here. First, DUMPER is using a .JICPJ to check for 'batch-ness'. That's probably not the best way to do this: .JICPJ tells you whether you are being controlled by a PTY or not. There are a bunch of things that can run DUMPER on a PTY, among them are PTYCON, SYSJOB and early versions of NRT. All of these would return a false positive. The definitive check is to issue a .JIBCH and check OB%BSS. Second, BATCON is in fact doing the right thing: unless @OPERATOR is given in the batch file, "$" will NOT be recognized. See page 2-31 of the Batch Reference for further details: "$" is essentially a form of "PLEASE"'ing into the batch stream. Nice. However, it would appear that this functionality has to be explicitly turned on in the batch file itself. Doing a SUBMIT /ASSISTANCE:YES won't do it--you have to do an @OPERATOR. The problem here is that there doesn't appear to be any way for DUMPER to tell whether its "$" is going to be looked at or not. The returned OB%WTO field from .JIBCH does not change whether @OPERATOR is on or not. Quasar doesn't know, either, so doing a .JIBSN and then a query on the sequence number won't get you what you want. Only BATCON keeps this state and it doesn't even keep it exactly. It flags OPERATOR by simply storing the signal character into the batch stream data base (it's packed into the .JERCD word). Nothing else. Moral of the Story: Use @OPERATOR in your batch files. I'm wondering whether this behavior would have been worth a Galactic SPR. "$" could be viewed as form of /ASSISTANCE and BATCON (or somebody) should set it in the .JIBCH word. For now, silently munching the line can't be the right thing--DUMPER should change to an ESOUT%, but again there is no way to know when to do this. However ... the SPR probably wouldn't have been accepted, anyway ... Finally, here are some test control, log and assembler files that I used to track down the behavior in case anyone else feels like playing with this: Test Batch control and log files BATCH.CTL ========= @OPERATOR @Run Batch.EXE *Nope, must be a BATCON bug @Please Did that actually work? BATCH.LOG ========= 13-Apr-2008 14:30:33 BATCON Version 6(10114) GLXLIB Version 6(1534) Job BATCH Req #54 for SLOGIN in Stream 2 OUTPUT: Nolog TIME-LIMIT: 1:00:00 UNIQUE: No BATCH-LOG: Append RESTART: No ASSISTANCE: Yes ACCOUNT: SEQUENCE: 917 Input from => STAR:BATCH.CTL Output to => STAR:BATCH.LOG 14:30:33 MONTR TOMMYT, PANDA TOPS-20 Monitor 7.1(21737)-5 14:30:33 MONTR Job 7 on TTY21 13-Apr-2008 14:30:33 14:30:33 MONTR Last interactive login 13-Apr-2008 14:03:43 14:30:33 MONTR Last non-interactive login 13-Apr-2008 14:29:43 14:30:34 MONTR End of LOGICALS.CMD.17 14:30:34 MONTR End of BATCH.CMD.4 14:30:34 MONTR End of COMAND.CMD.56 14:30:34 MONTR @ 14:30:34 MONTR [Connected to STAR:] 14:30:34 BATCH @OPERATOR 14:30:34 MONTR @Echo This is a test 14:30:34 MONTR This is a test 14:30:34 MONTR @@Run Batch.EXE 14:30:34 USER 14:30:34 USER $Help! Please help me: 14:30:39 BAOPR From Operator: Fuggetaboutit 14:30:39 USER 14:30:39 USER Fuggetaboutit 14:30:39 USER 14:30:39 MONTR @ *Nope, must be a BATCON bug 14:30:39 BATCH @Please Did that actually work? 14:30:42 BAOPR From Operator: Yes 14:30:42 MONTR 14:30:43 MONTR Killed by OPERATOR, Detached 14:30:43 MONTR Killed Job 7, User SLOGIN, TTY21, at 13-Apr-2008 14:30:42 14:30:43 MONTR Used 0:00:01 in 0:00:09 OPR Dialog 14:30:33 OPRWTO job 2 OPERATOR detached running SYSJB1 Batch-Stream 2 -- Begin -- Job BATCH Req #54 for SLOGIN 14:30:34 OPRWTR job 2 OPERATOR detached running SYSJB1 WTOR code = 152354461624 <20> Batch-Stream 2 JOB #7 -- Message from Batch User -- Job BATCH Req #54 for SLOGIN $Help! Please help me: 14:30:39 OPRCMD from job 11 SLOGIN at terminal 121 node TOMMYT running OPR =>resp 20 Fuggetaboutit 14:30:39 OPRWTR job 2 OPERATOR detached running SYSJB1 WTOR code = 152354461624 <21> Batch-Stream 2 JOB #7 -- Message from Batch User -- Job BATCH Req #54 for SLOGIN Please Did that actually work? 14:30:42 OPRCMD from job 11 SLOGIN at terminal 121 node TOMMYT running OPR =>resp 21 Yes 14:30:44 OPRWTO job 2 OPERATOR detached running SYSJB1 Batch-Stream 2 -- End -- Job BATCH Req #54 for SLOGIN 14:30:44 OPRNFY job 2 OPERATOR detached running SYSJB1 For: job 11 SLOGIN at terminal 121 [From SYSTEM: Job BATCH request #54 finished executing at 14:30:44] MACRO Test program Title Batch Subttl Test "$" processing in BATCON SEARCH MONSYM,MACSYM ; The usual suspects STDAC. ; Standard accumulators CRLF: BYTE (7) .CHCRT,.CHLFD,0,0,0 ; Beginning of line EOL: EXP .CHLFD, 0, ; End of line HELP: ASCIZ /Help! Please help me: / ; Our message to the operator POPR: POINT 7,OPR ; Pointer to operator response ^D80 ; Maximum length of same STACK: BLOCK ^D10 ; Don't need much space OPR: BLOCK ^D80/5 ; Assume single line response BLOCK ^D10 ; But leave a little slop, anyway BATCH: MOVE P,[IOWD ^D10,STACK] ; Set up the stack RESET% ; Reset the world ERCALS ERROR ; Actuall can fail DMOVE T1,[EXP .FHSLF,LSTRX1] ; Process has not encountered any errors SETER% ; Because RESET% leaves it as undefined JSYS ERCALS ERROR ; This fork is seriously ill; leave HRROI T1,CRLF ; Beginning of line PSOUT% ; Make SURE we're there ERCALS ERROR ; Handle error (sort of) MOVX T1,"$" ; Operator signal character PBOUT% ; Initiate dialog ERCALS ERROR ; Handle error (sort of) HRROI T1,HELP ; Our message? PSOUT% ; Get it to the operator ERCALS ERROR ; Handle error (sort of) HRROI T1,CRLF ; Beginning of line PSOUT% ; Make SURE we're there SETZM OPR ; Default response is NOTHING MOVX T1,.PRIIN ; Reading from primary input DMOVE T2,POPR ; Load pointer to response area, MOVX T4,.CHCRT ; maximum length and stop character SIN% ; Read in the response ERCALS ERROR ; Handle error (sort of) DMOVE P1,EOL ; Load end of line IDPB P1,T2 ; Only have a carriage return, so IDPB P2,T2 ; pop in a line feed and tie off ; the string MOVX T1,.PRIIN ; Lets see if there is anything else SIBE% ; Investigate the input buffer IFJE. R ; Investigate the error CAXE T1,LSTRX1 ; Not really an error? CALL ERROR ; A real error, handle it (sort of) MOVX T1,.PRIIN ; Otherwise reload original T1 ENDIF. ; End case of error or otherwise IFN. T2 ; Anything there? DO. ; Yes, get rid of it PBIN% ; Chew something ERCALS ERROR ; Handle error (sort of) SOJG T2,TOP. ; And get anything that's left ENDDO. ; End of crud loop ENDIF. ; End of crud case HRROI T1,CRLF ; Beginning of line PSOUT% ; Make SURE we're there ERCALS ERROR ; Handle error (sort of) MOVE T1,POPR ; Reload the response pointer PSOUT% ; Show what we got ERCALS ERROR ; Handle error (sort of) HRROI T1,CRLF ; Beginning of line PSOUT% ; Make SURE we're there ERCALS ERROR ; Handle error (sort of) HALTF% ; and done JRST BATCH ; Do it over if continued SUBTTL Rudimentary error handler ERRORM: ASCIZ /Error in batch job at / ; Beginning part of error message ERROR: MOVE Q1,T1 ; Save original accumulator POP P,Q3 ; Save the error location MOVX T1,.FHSLF ; This process GETER% ; Get our last error IFJE. R ; Failed?? HRRZI T2,FRKHX1 ; Don't use LSTRX1! ELSE. ; Otherwise we got something TLZ T2,-1 ; So shut off the fork handle ENDIF. ; One way or another have an error MOVE Q2,T2 ; Store the error DO. ; Now tell us all about it HRROI T1,ERRORM ; Load initial error message ESOUT% ; Properly emit it for batch ERJMPR .+1 ; Ignore the error MOVX T1,.PRIOU ; Error continues to primary output MOVE T2,Q3 ; Load the location MOVX T3,^D8 ; Addresses are in base eight! NOUT% ; Say where this happened ERJMPR .+1 ; Ignore the error HRROI T1,[ASCIZ /: / ] ; Space over PSOUT% ; for error ERJMPR .+1 ; Ignore the error MOVX T1,.PRIOU ; Error continues to primary output HRLI T2,.FHSLF ; Load arcane fork handle HRR T2,Q2 ; Load the error SETZ T3, ; No limit to type out ERSTR% ; Translate error number to string ERJMPR .+2 ; Ignore the error ERJMPR .+1 ; Here too HRROI T1,CRLF ; Beginning of line PSOUT% ; Tie off the message ERJMPR .+1 ; Ignore the error HALTF% ; Nothing more to do LOOP. ; Re-emit error if continued ENDDO. END 1,,BATCH ; End of Batch 21-Apr-2008 09:45:27-PDT,15002;000000000000 Return-Path: Received: from pangtzu.panda.com ([206.124.149.117]) by Lingling.Panda.COM with TCP/SMTP; Mon, 21 Apr 2008 09:39:02 -0700 (PDT) X-Return-Path: X-Received: from mta4.srv.hcvlny.cv.net ([167.206.4.199]) by Lingling.Panda.COM with TCP/SMTP; Sun, 20 Apr 2008 19:10:35 -0700 (PDT) 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 <0JZN006HYKPGCK50@mta4.srv.hcvlny.cv.net> for TOPS-20@lingling.panda.com; Sun, 20 Apr 2008 22:10:29 -0400 (EDT) Date: Sun, 20 Apr 2008 22:10:27 -0400 From: Thomas DeBellis Subject: %Problem on device: MTA0, Part 3 In-reply-to: <48025BE2.10904@optonline.net> To: Tops-20 Wizards Message-id: <480BF793.6020107@optonline.net> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en References: <480138E1.4040707@optonline.net> <48025BE2.10904@optonline.net> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) ReSent-Date: Mon, 21 Apr 2008 09:38:53 -0700 (PDT) ReSent-From: TOPS-20 List Moderator ReSent-To: TOPS-20 Distribution: ; ReSent-Subject: %Problem on device: MTA0, Part 3 ReSent-Message-ID: ReSent-User-Agent: Alpine 1.10 (OSX 1031 2008-04-10) This started worrying me (and hence really bugging me) enough so that I came up with a fix. The changes were a simpler than I expected. Symptom: ======== Backup tapes with missing save sets. This only happens in a batch job during tape error processing. Problem: ======== BATCON is swallowing output that is supposed to invoke Operator intervention: 16:41:35 USER % 16:41:35 USER $Tape went offline or encountered device error, type to try again. *Save /Full-Incremental STAR:<*>*.*.* Analysis: ========= DUMPER is changing its output to signal an operator (I.E., a leading '$' sign) based on the fact that it is in a batch job. However, if the batch job is not in operator dialog mode, then BATCON will simply swallow the question as job output. This results in the silently lost save sets. In addition, DUMPER is not properly detecting whether it is in a batch job or not. It is using .JICPJ which indicates whether it is running on a PTY. Other things besides BATCON use PTY's, such as PTYCON and SYSJOB. BATCON is doing the right thing. It is only supposed to look for an Operator input request when it is explicitly put into Operator dialog mode via an @OPERATOR verb in the batch control file. The batch control file in question did not have this. Cure: ===== The canonical test for 'batch'-ness is the value of .JIBAT: this is what BATCON sets (via the MTOPR% .MOBAT function) directly on the PTY. The value that .JIBAT is derived from (PTBAT) is what Tops-20 itself uses to determine 'batch'-ness which, among other things, can drive scheduling decisions. DUMPER should continue signal that Operator input is needed. However, if it appears that this can not happen, then it should produce an error. Unfortunately, this information is currently not available. The fix here is to simply have BATCON put the information in the .JIBCH word via the .SJBAT function of SETJB%. Tops-20 does not check the contents of this word in any way. .JIBCH is an appropriate choice because this is already be used to store batch flags. Finally, a suggested change is made to FINGER to display the information: !INFORMATION BATCH Batch Queue: Job Name Req# Run Time User -------- ------ -------- ------------------------ * BATCH 73 01:00:00 SLOGIN In Stream:2 --Waiting For Operator Response-- Can now also be displayed by: !FINGER User Personal name Job Subsys Idle TTY Console location SLOGIN Thomas DeBellis 9 BATCH 20 Batch Stream: 2, Operator Wait Code: ===== File 1) NEW:MONSYM.MAC[1,5] created: 1635 13-Apr-08 File 2) OLDM:MONSYM.MAC[4,126] created: 2218 05-May-04 1)1 ;[TOMMYT]TOMMYT:MONSYM.MAC.3, 13-Apr-2008 16:33:54, Edit by SLOGIN 1) ;[T48] Make DUMPER aware of the batch operator dialog mode 1) ; Edit= 9158 to MONSYM.MAC on 10-Feb-2002 by MRC **** 2) ; Edit= 9158 to MONSYM.MAC on 10-Feb-2002 by MRC ************** 1)61 OB%DIA==1B9 ;[T48] BATCH JOB IN DIALOG MODE 1) OB%BSS==1B10 ;BATCH STREAM NUMBER SET **** 2)61 OB%BSS==1B10 ;BATCH STREAM NUMBER SET ************** File 1) DSK:BATMAC.MAC[4,106] created: 1143 20-Apr-08 File 2) OLDGM:BATMAC.MAC[4,54] created: 2056 16-Dec-89 1)1 ;[TOMMYT]STAR:BATMAC.MAC.2, 13-Apr-2008 17:19:52, Edit by SLOGIN 1) ;[T48] Make DUMPER aware of the batch operator dialog mode 1) UNIVER BATMAC ;PARAMETER FILE FOR BATCON **** 2)1 UNIVER BATMAC ;PARAMETER FILE FOR BATCON ************** 1)1 BMCDEV==:42 ;[T48] 1) VERSIN(BMC) 1) BMCWHO==2 ;[T48] Customer Editor 1) BMCVER==6 **** 2)1 BMCDEV==:41 2) VERSIN(BMC) 2) BMCWHO==0 2) BMCVER==6 ************** 1)12 .JBATI:! BLOCK 1 ;[T48] Batch information 1) .JSTAT:! BLOCK 1 ;SAVE RESULT OF JOBSTS UUO, FOR BATOPR **** 2)12 .JSTAT:! BLOCK 1 ;SAVE RESULT OF JOBSTS UUO, FOR BATOPR ************** File 1) DSK:BATCON.MAC[4,106] created: 1144 20-Apr-08 File 2) OLDGB:BATCON.MAC[4,54] created: 2050 16-Dec-89 1)1 ;[TOMMYT]STAR:BATCON.MAC.2, 13-Apr-2008 16:45:44, Edit by SLOGIN 1) ;[T48] Make DUMPER aware of the batch operator dialog mode 1) TITLE BATCON -- GALAXY Batch Job Controller **** 2)1 TITLE BATCON -- GALAXY Batch Job Controller ************** 1)2 BTNDEV==:6003 ;[T48] ;DEVELOPMENT EDIT NUMBER 1) VERSIN (BTN) ;GENERATE EDIT NUMBER 1) BTNWHO==2 ;[T48] ;Customer edit 1) BTNVER==6 ;MAJOR VERSION NUMBER **** 2)2 BTNDEV==:6002 ;DEVELOPMENT EDIT NUMBER 2) VERSIN (BTN) ;GENERATE EDIT NUMBER 2) BTNWHO==0 2) BTNVER==6 ;MAJOR VERSION NUMBER ************** 1)32 LOGS.4: TXZ T1,OB%DIA ;[T48] Dialog mode is initially off 1) MOVEM T1,.JBATI(R) ;[T48] Save the batch information 1) SETJB ;DO THE FUNCTION 1) ;**;[4302]At LOGS.4:+1L replace 2 lines with 13 lines JYCW 7-Mar-86 **** 2)32 LOGS.4: SETJB ;DO THE FUNCTION 2) ;**;[4302]At LOGS.4:+1L replace 2 lines with 13 lines JYCW 7-Mar-86 ************** 1)41 BBNOOP: PUSHJ P,COPDIA ;[T48] Clear operator dialog mode 1) SETZ S1, ;CLEAR THE DIALOGUE CHARACTER 1) DPB S1,LDOPCH ;CLEAR IT **** 2)41 BBNOOP: SETZ S1, ;CLEAR THE DIALOGUE CHARACTER 2) DPB S1,LDOPCH ;CLEAR IT ************** 1)41 BBOPER: PUSHJ P,SOPDIA ;[T48] Set operator dialog mode 1) JSP T4,ER..OP ;CALL THE COMMON PROCESS (IT WILL NO RETURN HERE) 1) XWD "$",[ASCIZ/OPERATOR/] ;DEFAULT IS $,CALLER IS OPERATOR 1) LDOPCH: POINT 9,.JERCD(R),17 ;HOW TO LOAD/STORE THE CHARACTER 1) ;[T48] Begin code insertion 1) IFN FTUUOS,< ;Not implemented under Tops-10 1) SOPDIA: REMARK ;Setting operator dialog mode 1) COPDIA: REMARK ;Clearing operator dialog mode 1) > ;END OF IFN FTUUOS 1) IFN FTJSYS,< ;Winning Tops-20 has DUMPER to talk to 1) SOPDIA: MOVX T1,OB%DIA ;Setting dialog mode 1) IORB T1,.JBATI(R) ;Update batch information 1) JRST COPD.1 ;Join clear operator diaglog mode code 1) COPDIA: MOVX T1,^-OB%DIA ;Clearing dialog mode 1) ANDB T1,.JBATI(R) ;Update batch information 1) COPD.1: HRRZ S1,.JJOBN(R) ;Get load this stream's job number 1) MOVEI S2,.SJBAT ;Set batch info 1) SETJB ;Do the function 1) ERJMP .+1 ;Should handle this better ... 1) > ;END IFN FTJSYS 1) POPJ P, ; And return 1) ;[T48] End code insertion 1) ;PLEASE COMMAND - OUTPUT A MESSAGE TO THE OPERATOR (OPTIONALLY WAIT) **** 2)41 BBOPER: JSP T4,ER..OP ;CALL THE COMMON PROCESS (IT WILL NO RETURN HERE) 2) XWD "$",[ASCIZ/OPERATOR/] ;DEFAULT IS $,CALLER IS OPERATOR 2) LDOPCH: POINT 9,.JERCD(R),17 ;HOW TO LOAD/STORE THE CHARACTER 2) ;PLEASE COMMAND - OUTPUT A MESSAGE TO THE OPERATOR (OPTIONALLY WAIT) ************** File 1) DSK:DUMPER.MAC[4,127] created: 2100 20-Apr-08 File 2) OLDD:DUMPER.MAC[4,124] created: 2157 07-Oct-89 1)1 ;[TOMMYT]STAR:DUMPER.MAC.2, 13-Apr-2008 17:56:54, Edit by SLOGIN 1) ;[T48] Make DUMPER aware of the batch operator dialog mode 1) ; Edit= 563 to DUMPER.MAC on 7-Oct-89 by WEINER **** 2)1 ; Edit= 563 to DUMPER.MAC on 7-Oct-89 by WEINER ************** 1)2 .EDIT=^D564 ;[T48] 1) .WHO=2 ;[T48] Customer edit 1) COMMENT + **** 2)2 .EDIT=^D563 2) .WHO=0 2) COMMENT + ************** 1)3 F.BATJ==1B1 ;[T48] If a batch job 1) F.INTR==1B2 ;INTERCHANGE MODE IS ON **** 2)3 F.SUBJ==1B1 ;IF ON A PTY 2) F.INTR==1B2 ;INTERCHANGE MODE IS ON ************** 1)6 OJBATI: BLOCK 1 ;[T48] Our job's batch information 1) CLREND==.-1 **** 2)6 CLREND==.-1 ************** 1)9 SETO T1, ;[T48] This job 1) DMOVE T2, [ -1,,T4 ;[T48] Return answer in T4 1) .JIBAT ] ;[T48] Asking about canonical batchness 1) GETJI% ;[T48] Get the data from Tops-20 1) IFJE. R ;[T48] Handle an error 1) SETZ T4, ;[T48] On an error, assume not batch 1) ENDIF. ;[T48] End case of JSYS error 1) IFN. T4 ;[T48] If not zero, then canonically batch 1) TXO F,F.BATJ ;[T48] and remember this 1) DMOVE T2, [ -1,,T4 ;[T48] Return answer in T4 1) .JIBCH ] ;[T48] Return batch stream and flags 1) GETJI% ;[T48] We care because some messages will "$" 1) IFJE. R ;[T48] Handle an error, say no stream 1) MOVX T4,FLD(.OBNWR,OB%WTO)!FLD(0,OB%DIA)!FLD(0,OB%BSS)!FLD(0,OB%BSN) 1) ENDIF. ;[T48] End case of JSYS error 1) MOVEM T4,OJBATI ;[T48] Store our batch job information 1) ENDIF. ;[T48] End case of canonical batch 1) MOVEI T1,.FHSLF ;Set up interrupts **** 2)9 SETO T1, ;ON A PTY? 2) HRROI T2,T1 2) MOVEI T3,.JICPJ ;WE CARE BECAUSE SOME MESSAGES WILL 2) GETJI% ;THEN GET A "$" LEADER 2) ERJMPS .+2 ;DOESN'T HURT TO ASSUME "YES" 2) CAIL T1,0 2) TXO F,F.SUBJ ;ON A SUBJOB 2) MOVEI T1,.FHSLF ;Set up interrupts ************** 1)37 IFXN. F,F.BATJ ;[T48] In a batch job? 1) MOVE T1,OJBATI ;[T48] Yes, load our job's batch information 1) IFXN. T1,OB%DIA ;[T48] Are we in dialog mode? 1) MOVEI T1,"$" ;[T48] Yes, safe to ask for input 1) ELSE. ;[T48] Otherwise, we'll swallow the 1) MOVEI T1,"?" ;[T48] next line in the batch file 1) ENDIF. ;[T48] End case of batch dialog 1) ENDIF. ;[T48] End case of batch job 1) JRST OUTMSC **** 2)37 TXNE F,F.SUBJ 2) MOVEI T1,"$" 2) JRST OUTMSC ************** 1)40 BADYEN: IFXN. F,F.BATJ ;[T48] In a batch job? 1) MOVE T1,OJBATI ;[T48] Yes, load our job's batch information 1) TXNN T1,OB%DIA ;[T48] Are we in dialog mode? 1) ANSKP. ;[T48] No, then this must be an error 1) CALL IFCRL2 ;[T48] Otherwise get to the first column 1) TYPE [ASCIZ /$Just need a YES or NO here 1) /] ;[T48] 1) ELSE. ;[T48] Not a batch job ?ERROR IS OK. 1) ERROR (,YESNO) ;[T48] 1) ENDIF. ;[T48] End case of batch job test 1) JRST YESNO2 ;IN ANY CASE ASK AGAIN **** 2)40 BADYEN: TXNN F,F.SUBJ ;SUBJOB? 2) ERROR ;NO. ?ERROR IS OK. 2) JRST YESNO2 ;IN ANY CASE ASK AGAIN ************** 1)40 IFXE. F,F.BATJ ;[T48] Batch job? 1) MOVX T3, ;[T48] No, just space over 1) ELSE. ;[T48] Otherwise, not interactive! 1) MOVE T3,OJBATI ;[T48] so load our batch information 1) TXNN T3,OB%DIA ;[T48] Are we in dialog mode? 1) IFSKP. ;[T48] Yes, safe to ask for operator input 1) MOVX T3, ;[T48] So use standard signal character 1) ELSE. ;[T48] Otherwise, we'll swallow batch input 1) MOVX T3, ;[T48] So must flag an error 1) ENDIF. ;[T48] End case of operator dialog check 1) ENDIF. ;[T48] End case of batch job decision 1) MOVEM T3,(T2) **** 2)40 MOVX T3, 2) TXNE F,F.SUBJ 2) MOVX T3, 2) MOVEM T3,(T2) ************** GETLOC.MAC suggested change. Replace .DOBAT with the following: ================================================================ .DOBAT: MOVE C,A ;Save the job number MOVE A,PTR ;Get back the pointer TXZ FL,GL%ALL-GL%BAT ;Clear all but Batch TXZE FL,GL%TST ;Do we want to test? TXNE FL,GL%BAT ;Yes, do we want batch jobs? SKPA ;Yes, go ahead RETSKP ;No, go back now TXO FL,GL%TST!GL%USD!GL%BAT ;Say this is a batch job TXNN FL,GL%DES ;Only description? IFSKP. MOVEI B,[ASCIZ \Batch\] ;Get our description JRST .DOSTR ;Return that ENDIF. TXNE FL,GL%LOC ;Are we doing TTYLOC? IFSKP. MOVE A,C ;Load the job number HRROI B,D ;Put word in D MOVEI C,.JIBCH ;Get batch stream information GETJI% ;and flags (set by BATCON)) IFJER. ;Did this fail? SETZ D, ;Yes, just say the stream is not set ENDIF. ;But this should never fail, really MOVE A,PTR ;Load the pointer TXNE D,OB%BSS ;Check to see if we have a stream IFSKP. ;No, BATCON must still be setting up the job MOVE B,[POINT 7,[ASCIZ \Batch Job\]] ;So just vaguely say CALL CPYSTR ;that it's a batch frob ELSE. ;Otherwise, say something useful MOVE B,[POINT 7,[ASCIZ \Batch Stream: \]] ; CALL CPYSTR ;Begin the text LOAD B,OB%BSN,D ;Load the batch stream number MOVEI C,^D10 ;Radix decimal NOUT% ;Output it ERJMPS .+1 ;Ignore the error, preserve the pointer TXNN D,OB%DIA ;In Operator dialog mode? IFSKP. ;Yes! Find out some more about it MOVE D,A ;First save the output designator HRRI A,.TTYJO ;Looking for TTY/JOB information HRL A,TTYNUM ;Load the line number GETAB% ;Get the table entry IFJE. R ;Did this gronk?? SETO A, ;Pretend not waiting for input ENDIF. ;End JSYS failure handler HRRZ B,A ;Load the wait word MOVE A,D ;Restore the output pointer CAIN B,-1 ;Anybody waiting? IFSKP. ;Yes, explain about it MOVE B,[POINT 7,[ASCIZ \, Operator Wait\]] ; CALL CPYSTR ;Copy it over ENDIF. ;End case of waiting for input ENDIF. ;End case of batch operator dialog mode ENDIF. ;End case of batch stream check RETSKP ;Go back +2 ENDIF. MOVE B,[POINT 7,[ASCIZ \Batch: \]] ;Otherwise, set up line CALL CPYSTR ;Add this line to our location TXO FL,GL%BAT ;Say we were a batch job CALLRET ADDLOC ;Add our regular TTYLOC location now 27-Apr-2008 21:18:40-PDT,5960;000000000000 Return-Path: Received: from pangtzu.panda.com ([206.124.149.117]) by Lingling.Panda.COM with TCP/SMTP; Sun, 27 Apr 2008 21:11:47 -0700 (PDT) X-Return-Path: X-Received: from mta4.srv.hcvlny.cv.net ([167.206.4.199]) by Lingling.Panda.COM with TCP/SMTP; Sun, 27 Apr 2008 20:13:43 -0700 (PDT) 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 <0K000011MMAE0S80@mta4.srv.hcvlny.cv.net> for TOPS-20@lingling.panda.com; Sun, 27 Apr 2008 23:13:27 -0400 (EDT) Date: Sun, 27 Apr 2008 23:13:25 -0400 From: Thomas DeBellis Subject: Data area initialization issue in GLXOTS To: Tops-20 Wizards Message-id: <481540D5.5070800@optonline.net> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) ReSent-Date: Sun, 27 Apr 2008 21:11:36 -0700 (PDT) ReSent-From: TOPS-20 List Moderator ReSent-To: TOPS-20 Distribution: ; ReSent-Subject: Data area initialization issue in GLXOTS ReSent-Message-ID: ReSent-User-Agent: Alpine 1.10 (OSX 1031 2008-04-10) Symptom ======= Galaxy programs can crash when they are continued. Problem ======= GLXLIB is not properly initializing the data storage area. This area is zero on program start up, but is not when a program is continued. However, there are other issues (see below) Cure ==== The arguments to .ZCHNK in CREPAG (in GLXOTS) are wrong. The negative length of the data area is calculated and the end of the data area is given instead of the beginning. In addition, given that GLXLIB is a section zero library, the use of XMOVEI's is probably inappropriate. In a non-zero section, a section number could conceivably cause the register checking logic in .ZCHNK to break. Code ==== File 1) DSK:GLXOTS.MAC[4,106] created: 2234 27-Apr-08 File 2) OG:GLXOTS.MAC[4,54] created: 1650 08-Mar-88 1)1 ;[TOMMYT]STAR:GLXOTS.MAC.2, 27-Apr-2008 22:15:41, Edit by SLOGIN 1) ;[T49] Have GLXOTS properly initialize the data area 1) 1) TITLE GLXOTS - Primary Module for GALAXY Runtime System **** 2)1 TITLE GLXOTS - Primary Module for GALAXY Runtime System ************** 1)1 OTSMAN==:1 ;[T49] ;Maintenance edit number 1) OTSDEV==:21 ;Development edit number **** 2)1 OTSMAN==:0 ;Maintenance edit number 2) OTSDEV==:21 ;Development edit number ************** 1)7 MOVEI S1,D%END##-D%BEG ;[T49] GET LENGTH OF PAGE PAGES 1) MOVEI S2,D%BEG ;[T49] POINT TO LAST DATA WORD 1) $CALL .ZCHNK ;ZAP ALL WORDS **** 2)7 XMOVEI S1,D%BEG-D%END## ;GET LENGTH OF PAGE PAGES 2) XMOVEI S2,D%END## ;POINT TO LAST DATA WORD 2) $CALL .ZCHNK ;ZAP ALL WORDS ************** Remarks ======= The problem was probably never noticed because it is relatively benign; most Galaxy programs (Quasar, Orion, MOUNTR, etc) are never continued--they are started once and run for the run of the operating system. However, OPR, PLEASE (and I forget which others) are user programs which can be kept and continued. I do this with OPR. A closer look at the Tops-10 code would seem to offer part of an explanation as to how this bug came to be. Tops-10 issues a PAGE. UUO to determine whether it needs to create the data area; it does this by checking the last page: D%END. One of these days I think I am going to go through every message that I ever posted on the Tops-20 Wizards list about Galaxy and see how many (or IF ANY) of my patches ever made it in. It's just kind of a bummer. I worked really hard on that stuff and we all sweated through a number of Galaxy beta tests. :-( Anyway, here is the original posting. If I got it wrong, I'd really like to know about it. Alternatively, I'd be curious to know why a lot of these fixes never seem to have made it in ... Or maybe I'd rather NOT know ... 5-Aug-86 07:45:23-PDT,1497;000000000000 Return-Path: Received: from CU20B.COLUMBIA.EDU by SU-SCORE.ARPA with TCP; Tue 5 Aug 86 07:45:00-PDT Date: Tue 5 Aug 86 10:45:45-EDT From: Thomas De Bellis Subject: Memory allocation bug in GLXOTS To: Tops-20@SU-SCORE.ARPA Message-ID: <12228392415.174.SY.SLOGIN@CU20B.COLUMBIA.EDU> GLXOTS has a routine called CREDAT which is used to create data pages so that the memory initializing routines get the correct count of available pages. It also performs the function of setting these pages to a known initial value. Unfortunately, it sets the arguments to .ZCHNK, a routine that eventually does a BLT to zero out memory space, backwards; it gives a negative amount of space to zero and starts from the end. This could cause either GLXMEM to not know how many pages can be used for user programs or blow away part of the GLXLIB segment. The code to be replaced is at the end of GLXOTS a few lines up from OTS%L: Old code: TOPS20 < ;TOPS-20 ONLY XMOVEI S1,D%BEG-D%END## ;GET LENGTH OF PAGE PAGES XMOVEI S2,D%END## ;POINT TO LAST DATA WORD $CALL .ZCHNK ;ZAP ALL WORDS POPJ P, ;RETURN > ;END OF TOPS-20 CONDITIONAL New Code: TOPS20 < ;TOPS-20 ONLY XMOVEI S1,D%END##-D%BEG ;C122 ;Get positive length of data area XMOVEI S2,D%BEG ;C122 ;Point to the first word $CALL .ZCHNK ;ZAP ALL WORDS POPJ P, ;RETURN > -- Tom De Bellis Columbia Systems Group ------- 4-May-2008 13:57:04-PDT,2065;000000000000 Return-Path: Received: from pangtzu.panda.com ([206.124.149.117]) by Lingling.Panda.COM with TCP/SMTP; Sun, 4 May 2008 13:50:56 -0700 (PDT) X-Return-Path: X-Received: from mta1.srv.hcvlny.cv.net ([167.206.4.196]) by Lingling.Panda.COM with TCP/SMTP; Sun, 4 May 2008 11:19:07 -0700 (PDT) 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 <0K0C008Z0W7OJE80@mta1.srv.hcvlny.cv.net> for TOPS-20@lingling.panda.com; Sun, 04 May 2008 14:19:00 -0400 (EDT) Date: Sun, 04 May 2008 14:18:59 -0400 From: Thomas DeBellis Subject: Tops-20 Labels To: Tops-20 Wizards Message-id: <481DFE13.3070107@optonline.net> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) ReSent-Date: Sun, 4 May 2008 13:50:48 -0700 (PDT) ReSent-From: TOPS-20 List Moderator ReSent-To: TOPS-20 Distribution: ; ReSent-Subject: Tops-20 Labels ReSent-Message-ID: ReSent-User-Agent: Alpine 1.10 (OSX 1045 2008-05-02) As Columbia's Galaxy person, I was responsible for keeping MOUNTR happy and well fed. In the early days, this could be quite challanging at times, particularly during the 4.2 beta-test. But MOUNTR eventually got to be healthy. A pity they took DECtape support out of it... Or at least I recall seeing that hooks were there. At some point, I was either sent or came across a rather slim volume describing the labeled tape formats. For a future project that I have in mind, I would REALLY like to have this information. Must have it, actually. Does anybody know where it is? I mean, aside from looking at the source code for MOUNTR... 4-May-2008 14:01:11-PDT,2632;000000000000 Return-Path: Received: from pangtzu.panda.com ([206.124.149.117]) by Lingling.Panda.COM with TCP/SMTP; Sun, 4 May 2008 13:51:50 -0700 (PDT) X-Return-Path: X-Received: from mta3.srv.hcvlny.cv.net ([167.206.4.198]) by Lingling.Panda.COM with TCP/SMTP; Sun, 4 May 2008 11:34:11 -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 <0K0C003R3WWEU370@mta3.srv.hcvlny.cv.net> for TOPS-20@lingling.panda.com; Sun, 04 May 2008 14:33:50 -0400 (EDT) Date: Sun, 04 May 2008 14:33:49 -0400 From: Thomas DeBellis Subject: Re: SAIL In-reply-to: To: Frank da Cruz Cc: Tops-20 Wizards Message-id: <481E018D.9030207@optonline.net> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en References: User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) ReSent-Date: Sun, 4 May 2008 13:51:42 -0700 (PDT) ReSent-From: TOPS-20 List Moderator ReSent-To: TOPS-20 Distribution: ; ReSent-Subject: Re: SAIL ReSent-Message-ID: ReSent-User-Agent: Alpine 1.10 (OSX 1045 2008-05-02) > > I wish I had a copy of the SAIL manual to give you. > I wish you had a SAIL manual, too. Even a paper copy. Maybe > something out at Stanford? Our library? I though that MIT had a > copy of of all their stuff. Including HAKMEM. > > ... we didn't have the source to the SAIL RTS and couldn't fix it > > ... We kept running up against brick walls with it and eventually > > gave up. It was a great language, about 1000% better than C, > > but there was no interest at Stanford in maintaining it. You're not going to believe this, but while rooting around in my celler, I actually came across a SAIL manual. It's from 1976. It is was published by the Stanford Artificial Intelligence Laboratory. It's memo AIM-289, Computer Science Department Report No. STAN-CS-76-574. I think this may have been Howard's and I kept it after he left. I wonder if you can still order these? I though you could order HAKMEM. If not, maybe I've recovered something of interest? But I suppose the source for SAIL itself is lost... Sigh. 4-May-2008 14:31:14-PDT,2239;000000000000 Return-Path: Received: from pangtzu.panda.com ([206.124.149.117]) by Lingling.Panda.COM with TCP/SMTP; Sun, 4 May 2008 14:25:57 -0700 (PDT) X-Return-Path: X-Received: from sesame.cc.columbia.edu ([128.59.59.56]) by Lingling.Panda.COM with TCP/SMTP; Sun, 4 May 2008 14:15:45 -0700 (PDT) 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 m44LFXOP017028; Sun, 4 May 2008 17:15:33 -0400 (EDT) X-Received: (from fdc@localhost) by sesame.cc.columbia.edu (8.14.1/8.14.1/Submit) id m44LFX6A017027; Sun, 4 May 2008 17:15:33 -0400 (EDT) Date: Sun, 4 May 2008 17:15:32 EDT From: Frank da Cruz To: Thomas DeBellis Cc: TOPS-20 List Moderator , Tops-20 Wizards Subject: Re: Tops-20 Labels In-Reply-To: <481DFE13.3070107@optonline.net> Message-ID: ReSent-Date: Sun, 4 May 2008 14:25:49 -0700 (PDT) ReSent-From: TOPS-20 List Moderator ReSent-To: TOPS-20 Distribution: ; ReSent-Subject: Re: Tops-20 Labels ReSent-Message-ID: ReSent-User-Agent: Alpine 1.10 (OSX 1045 2008-05-02) > As Columbia's Galaxy person, I was responsible for keeping MOUNTR > happy and well fed. In the early days, this could be quite > challanging at times, particularly during the 4.2 beta-test. But > MOUNTR eventually got to be healthy. A pity they took DECtape support > out of it... Or at least I recall seeing that hooks were there. > > At some point, I was either sent or came across a rather slim volume > describing the labeled tape formats. For a future project that I have > in mind, I would REALLY like to have this information. Must have it, > actually. > > Does anybody know where it is? I mean, aside from looking at the > source code for MOUNTR... > Look at this file: ftp://kermit.columbia.edu/kermit/a/aatape.hlp There is also some code in the programs in this directory: ftp://kermit.columbia.edu/kermit/tu/ (Tape Utilities) - Frank 4-May-2008 14:36:00-PDT,2046;000000000000 Return-Path: Received: from pangtzu.panda.com ([206.124.149.117]) by Lingling.Panda.COM with TCP/SMTP; Sun, 4 May 2008 14:27:08 -0700 (PDT) X-Return-Path: X-Received: from mail.ultimate.com ([199.201.145.150]) by Lingling.Panda.COM with TCP/SMTP; Sun, 4 May 2008 14:21:13 -0700 (PDT) X-Received: from ultimate.com (localhost [127.0.0.1]) by mail.ultimate.com (8.14.1/8.14.1) with ESMTP id m44LL1pP000491 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 4 May 2008 17:21:01 -0400 (EDT) (envelope-from phil@ultimate.com) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=ultimate.com; s=default; t=1209936061; bh=R2Q1SbXRZZ3eplgyqxZTZ7sbvDSq0xc3yMyDwAK DEtM=; h=Received:Date:From:Message-Id:To:Subject:Cc:In-Reply-To; b=YrJ8Z3z3qJT7/PF9bHS3H3Q6ZxHdBMe7Pei4XQOp7yYE1KN8P8h7wOTVDZW6ckB7Z VCHBWhvOg0QuJhbyhABwaRGMCurwm2X2vd4mkgbfJX8TWrFNFPOsL3U1TR1zIQeiWOV gM2QooOLfniYeAu70rzDERrR/WDP8qhg4OOlZLQ= X-Received: (from phil@localhost) by ultimate.com (8.14.1/8.14.1/Submit) id m44LL1gR000490; Sun, 4 May 2008 17:21:01 -0400 (EDT) (envelope-from phil) Date: Sun, 4 May 2008 17:21:01 -0400 (EDT) From: Phil Budne Message-Id: <200805042121.m44LL1gR000490@ultimate.com> To: fdc@columbia.edu, slogin@optonline.net Subject: Re: SAIL Cc: TOPS-20@Lingling.Panda.COM In-Reply-To: <481E018D.9030207@optonline.net> ReSent-Date: Sun, 4 May 2008 14:26:56 -0700 (PDT) ReSent-From: TOPS-20 List Moderator ReSent-To: TOPS-20 Distribution: ; ReSent-Subject: Re: SAIL ReSent-Message-ID: ReSent-User-Agent: Alpine 1.10 (OSX 1045 2008-05-02) > But I suppose the source for SAIL itself is lost... Sigh. Not lost: ftp://ftp.ultimate.com/pdp10/sail.tar.gz These came off an old DECUS tape I have an image file of somewhere that also includes the binaries... The listing of those tapes can be seen at: ftp://ftp.ultimate.com/pdp10/decus/ 4-May-2008 18:17:04-PDT,2571;000000000000 Return-Path: Received: from pangtzu.panda.com ([206.124.149.117]) by Lingling.Panda.COM with TCP/SMTP; Sun, 4 May 2008 18:09:59 -0700 (PDT) X-Return-Path: X-Received: from b.mail.sonic.net ([64.142.19.5]) by Lingling.Panda.COM with TCP/SMTP; Sun, 4 May 2008 15:43:23 -0700 (PDT) X-Received: from Amiga.local (64-142-29-114.dsl.static.sonic.net [64.142.29.114]) by b.mail.sonic.net (8.13.8.Beta0-Sonic/8.13.7) with ESMTP id m44MhH4q020827 for ; Sun, 4 May 2008 15:43:17 -0700 Date: Sun, 4 May 2008 15:43:17 -0700 (PDT) From: Fred Wright X-Sender: fw@Amiga.local Reply-To: Fred Wright To: Tops-20 Wizards Subject: Re: Tops-20 Labels In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII ReSent-Date: Sun, 4 May 2008 18:09:51 -0700 (PDT) ReSent-From: TOPS-20 List Moderator ReSent-To: TOPS-20 Distribution: ; ReSent-Subject: Re: Tops-20 Labels ReSent-Message-ID: ReSent-User-Agent: Alpine 1.10 (OSX 1045 2008-05-02) On Sun, 4 May 2008, Frank da Cruz wrote: > > As Columbia's Galaxy person, I was responsible for keeping MOUNTR > > happy and well fed. In the early days, this could be quite > > challanging at times, particularly during the 4.2 beta-test. But > > MOUNTR eventually got to be healthy. A pity they took DECtape support > > out of it... Or at least I recall seeing that hooks were there. > > > > At some point, I was either sent or came across a rather slim volume > > describing the labeled tape formats. For a future project that I have > > in mind, I would REALLY like to have this information. Must have it, > > actually. > > > > Does anybody know where it is? I mean, aside from looking at the > > source code for MOUNTR... > > > Look at this file: > > ftp://kermit.columbia.edu/kermit/a/aatape.hlp > > There is also some code in the programs in this directory: > > ftp://kermit.columbia.edu/kermit/tu/ (Tape Utilities) Tape labels are an ANSI standard, although there may be some TOPS-20-specific information in some fields. Bear in mind that the standard was updated some time in the 90s to fix the Y2K problem (which is probably not reflected in MOUNTR). The updated version still has a Y3K problem. Fred Wright 4-May-2008 18:24:06-PDT,1632;000000000000 Return-Path: Received: from pangtzu.panda.com ([206.124.149.117]) by Lingling.Panda.COM with TCP/SMTP; Sun, 4 May 2008 18:19:43 -0700 (PDT) X-Return-Path: X-Received: from pangtzu.panda.com ([206.124.149.117]) by Lingling.Panda.COM with TCP/SMTP; Sun, 4 May 2008 18:18:18 -0700 (PDT) Date: Sun, 4 May 2008 18:18:13 -0700 (PDT) From: Mark Crispin Sender: mrc@pangtzu.panda.com To: Fred Wright cc: Tops-20 Wizards Subject: Re: Tops-20 Labels In-Reply-To: Message-ID: References: User-Agent: Alpine 1.10 (OSX 1045 2008-05-02) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed ReSent-Date: Sun, 4 May 2008 18:19:34 -0700 (PDT) ReSent-From: TOPS-20 List Moderator ReSent-To: TOPS-20 Distribution: ; ReSent-Subject: Re: Tops-20 Labels ReSent-Message-ID: ReSent-User-Agent: Alpine 1.10 (OSX 1045 2008-05-02) On Sun, 4 May 2008, Fred Wright wrote: > Bear in mind that the > standard was updated some time in the 90s to fix the Y2K problem (which is > probably not reflected in MOUNTR). The updated version still has a Y3K > problem. How did they contrive to have a Y3K problem? Are they using some form of BCD? -- Mark -- http://panda.com/tops-20 TOPS-20: a great improvement over its successors 5-May-2008 07:15:25-PDT,2581;000000000000 Return-Path: Received: from pangtzu.panda.com ([206.124.149.117]) by Lingling.Panda.COM with TCP/SMTP; Mon, 5 May 2008 07:09:58 -0700 (PDT) X-Return-Path: X-Received: from serrano.cc.columbia.edu ([128.59.29.6]) by Lingling.Panda.COM with TCP/SMTP; Mon, 5 May 2008 04:22:13 -0700 (PDT) X-Received: from [192.168.1.4] (pool-96-240-12-5.nwrknj.fios.verizon.net [96.240.12.5]) (user=rossman mech=PLAIN bits=0) by serrano.cc.columbia.edu (8.14.1/8.14.1) with ESMTP id m45BM60C027799 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 5 May 2008 07:22:07 -0400 (EDT) In-Reply-To: <481DFE13.3070107@optonline.net> References: <481DFE13.3070107@optonline.net> Mime-Version: 1.0 (Apple Message framework v753) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <48CCCE0C-0B88-4341-BA1C-34878C3C4BC6@columbia.edu> Cc: Tops-20 Wizards Content-Transfer-Encoding: 7bit From: Ken Rossman Subject: Re: Tops-20 Labels Date: Mon, 5 May 2008 07:22:20 -0400 To: Thomas DeBellis X-Mailer: Apple Mail (2.753) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.63 on 128.59.29.6 ReSent-Date: Mon, 5 May 2008 07:09:47 -0700 (PDT) ReSent-From: TOPS-20 List Moderator ReSent-To: TOPS-20 Distribution: ; ReSent-Subject: Re: Tops-20 Labels ReSent-Message-ID: ReSent-User-Agent: Alpine 1.10 (OSX 1045 2008-05-02) TOPS-20 tape labels were, more or less, ANSI standard tape labels. And you should be able to find the spec for that out on the net somewhere. I'm thinking there's *got* to be an online document out there somewhere that also describes the specifics of the fields that TOPS-20 used in the ANSI format, though... K > As Columbia's Galaxy person, I was responsible for keeping MOUNTR > happy and well fed. In the early days, this could be quite > challanging at times, particularly during the 4.2 beta-test. But > MOUNTR eventually got to be healthy. A pity they took DECtape support > out of it... Or at least I recall seeing that hooks were there. > > At some point, I was either sent or came across a rather slim volume > describing the labeled tape formats. For a future project that I have > in mind, I would REALLY like to have this information. Must have it, > actually. > > Does anybody know where it is? I mean, aside from looking at the > source code for MOUNTR... 6-May-2008 07:44:24-PDT,3191;000000000000 Return-Path: Received: from pangtzu.panda.com ([206.124.149.117]) by Lingling.Panda.COM with TCP/SMTP; Tue, 6 May 2008 07:38:35 -0700 (PDT) X-Return-Path: X-Received: from mail1.panix.com ([166.84.1.72]) by Lingling.Panda.COM with TCP/SMTP; Tue, 6 May 2008 05:38:49 -0700 (PDT) X-Received: from mailbackend.panix.com (mailbackend.panix.com [166.84.1.89]) by mail1.panix.com (Postfix) with ESMTP id 3F0CB29422; Tue, 6 May 2008 08:38:43 -0400 (EDT) X-Received: from mail.panix.com (localhost [127.0.0.1]) by mailbackend.panix.com (Postfix) with ESMTP id C9D496905; Tue, 6 May 2008 08:38:42 -0400 (EDT) X-Panix-Received: from 24.185.216.178 (SquirrelMail authenticated user rick@panix.com) by mail.panix.com with HTTP; Tue, 6 May 2008 08:38:43 -0400 (EDT) Message-ID: <33616.24.185.216.178.1210077523.squirrel@mail.panix.com> In-Reply-To: <481DFE13.3070107@optonline.net> References: <481DFE13.3070107@optonline.net> Date: Tue, 6 May 2008 08:38:43 -0400 (EDT) Subject: Re: Tops-20 Labels From: "Rick Ace" To: "Thomas DeBellis" Cc: TOPS-20@Lingling.Panda.COM User-Agent: SquirrelMail/1.4.13 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 X-Priority: 3 (Normal) Importance: Normal Content-Transfer-Encoding: quoted-printable ReSent-Date: Tue, 6 May 2008 07:38:26 -0700 (PDT) ReSent-From: TOPS-20 List Moderator ReSent-To: TOPS-20 Distribution: ; ReSent-Subject: Re: Tops-20 Labels ReSent-Message-ID: ReSent-User-Agent: Alpine 1.10 (OSX 1045 2008-05-02) > As Columbia's Galaxy person, I was responsible for keeping MOUNTR > happy and well fed. In the early days, this could be quite > challanging at times, particularly during the 4.2 beta-test. But > MOUNTR eventually got to be healthy. A pity they took DECtape support > out of it... Or at least I recall seeing that hooks were there. As the lead engineer at DEC for MOUNTR, I'm a good source of trivia about it :-). In particular, all the labeled tape processing was my purview. > At some point, I was either sent or came across a rather slim volume > describing the labeled tape formats. For a future project that I have > in mind, I would REALLY like to have this information. Must have it, > actually. As Ken Rossman mentioned, there are two tiers of organization within the metadata on the tapes: ANSI X3.27 and Digital's parochial usage of the vendor-reserved fields within the ANSI spec. Google will likely help you understand the ANSI part. (found this site right off that bat) http://it-dep-fio-ds.web.cern.ch/it-dep-fio-ds/Documentation/tapedrive/la= bels.html As for the DEC-specific layer, I've unfortunately long since discarded an= y DEC docs that explained the corporate standard. But if you mail me a question I'll try to answer it from recollection. Note also that interpreting metadata happens in two places: MOUNTR (volum= e and headers of first file) and the monitor module TAPE.MAC (file labels and intra-file data). Rick 6-May-2008 22:29:31-PDT,2224;000000000000 Return-Path: Received: from pangtzu.panda.com ([206.124.149.117]) by Lingling.Panda.COM with TCP/SMTP; Tue, 6 May 2008 22:24:03 -0700 (PDT) X-Return-Path: X-Received: from mail2.panix.com ([166.84.1.73]) by Lingling.Panda.COM with TCP/SMTP; Tue, 6 May 2008 12:48:15 -0700 (PDT) X-Received: from panix5.panix.com (panix5.panix.com [166.84.1.5]) by mail2.panix.com (Postfix) with ESMTP id 5D9053482A for ; Tue, 6 May 2008 15:48:08 -0400 (EDT) X-Received: by panix5.panix.com (Postfix, from userid 17662) id 4560E241AF; Tue, 6 May 2008 15:48:08 -0400 (EDT) From: Rich Alderson To: TOPS-20@lingling.panda.com In-reply-to: <481DFE13.3070107@optonline.net> (message from Thomas DeBellis on Sun, 04 May 2008 14:18:59 -0400) Subject: Re: Tops-20 Labels References: <481DFE13.3070107@optonline.net> Message-Id: <20080506194808.4560E241AF@panix5.panix.com> Date: Tue, 6 May 2008 15:48:08 -0400 (EDT) ReSent-Date: Tue, 6 May 2008 22:23:54 -0700 (PDT) ReSent-From: TOPS-20 List Moderator ReSent-To: TOPS-20 Distribution: ; ReSent-Subject: Re: Tops-20 Labels ReSent-Message-ID: ReSent-User-Agent: Alpine 1.10 (OSX 1045 2008-05-02) > Date: Sun, 04 May 2008 14:18:59 -0400 > From: Thomas DeBellis > At some point, I was either sent or came across a rather slim volume > describing the labeled tape formats. For a future project that I have > in mind, I would REALLY like to have this information. Must have it, > actually. The manual you remember is probably "TOPS-20 Tape Processing", which details the internals of ANSI, DEC, and IBM standard labels. I know that I have a copy of this manual in my personal collection, meaning that it is moderately buried in a storage locker; I've got to get all those manuals out one of these days. The primary distinction between ANSI and DEC is that the latter includes VOL2 and EOV2 extensions to the ANSI standard set, if I remember correctly. Rich 6-May-2008 22:33:17-PDT,2701;000000000000 Return-Path: Received: from pangtzu.panda.com ([206.124.149.117]) by Lingling.Panda.COM with TCP/SMTP; Tue, 6 May 2008 22:24:34 -0700 (PDT) X-Return-Path: X-Received: from mail.math.utah.edu ([155.101.98.135]) by Lingling.Panda.COM with TCP/SMTP; Tue, 6 May 2008 16:16:45 -0700 (PDT) X-Received: from tortola.math.utah.edu (tortola.math.utah.edu [155.101.96.48]) by mail.math.utah.edu (8.13.6/8.13.6) with ESMTP id m46NGX6G017151; Tue, 6 May 2008 17:16:33 -0600 (MDT) X-Received: from tortola.math.utah.edu (localhost [127.0.0.1]) by tortola.math.utah.edu (8.13.6/8.13.6) with ESMTP id m46NGXaH006655; Tue, 6 May 2008 17:16:33 -0600 (MDT) X-Received: (from bowman@localhost) by tortola.math.utah.edu (8.13.6/8.13.6/Submit) id m46NGXgH006654; Tue, 6 May 2008 17:16:33 -0600 (MDT) Date: Tue, 6 May 2008 17:16:33 -0600 (MDT) From: Pieter Bowman To: Thomas DeBellis Cc: bowman@math.utah.edu, TOPS-20 List Moderator , Tops-20 Wizards X-US-Mail: "University of Utah, Department of Mathematics, 155 S 1400 E RM 233, Salt Lake City, UT 84112-0090" X-Telephone: 801-581-5252 X-Fax: 801-581-4148 Subject: Re: Tops-20 Labels In-Reply-To: Your message of Sun, 04 May 2008 14:18:59 -0400 Message-ID: X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0 (mail.math.utah.edu [155.101.98.135]); Tue, 06 May 2008 17:16:34 -0600 (MDT) ReSent-Date: Tue, 6 May 2008 22:24:22 -0700 (PDT) ReSent-From: TOPS-20 List Moderator ReSent-To: TOPS-20 Distribution: ; ReSent-Subject: Re: Tops-20 Labels ReSent-Message-ID: ReSent-User-Agent: Alpine 1.10 (OSX 1045 2008-05-02) >> ... >> At some point, I was either sent or came across a rather slim volume >> describing the labeled tape formats. For a future project that I have >> in mind, I would REALLY like to have this information. Must have it, >> actually. >> >> Does anybody know where it is? I mean, aside from looking at the >> source code for MOUNTR... >> ... I have a copy of the TOPS-20 Tape Processing Manual AA-H180A-TM from January 1980 and a printout of a file called "tape.doc" (not a MS Word file). I scanned both to PDF files and did OCR on them. They can be found at: http://www.math.utah.edu/~bowman/tops-20_tape_processing_manual.pdf http://www.math.utah.edu/~bowman/tape.doc.pdf I have not proofread them, so am sure that the OCR has errors. Hope this helps. Pieter 6-May-2008 22:37:22-PDT,1938;000000000000 Return-Path: Received: from pangtzu.panda.com ([206.124.149.117]) by Lingling.Panda.COM with TCP/SMTP; Tue, 6 May 2008 22:25:00 -0700 (PDT) X-Return-Path: X-Received: from mail2.panix.com ([166.84.1.73]) by Lingling.Panda.COM with TCP/SMTP; Tue, 6 May 2008 12:56:33 -0700 (PDT) X-Received: from panix5.panix.com (panix5.panix.com [166.84.1.5]) by mail2.panix.com (Postfix) with ESMTP id 2612E34827 for ; Tue, 6 May 2008 15:56:26 -0400 (EDT) X-Received: by panix5.panix.com (Postfix, from userid 17662) id 0FF3A241AF; Tue, 6 May 2008 15:56:26 -0400 (EDT) From: Rich Alderson To: TOPS-20@Lingling.Panda.COM In-reply-to: <200805042121.m44LL1gR000490@ultimate.com> (message from Phil Budne on Sun, 4 May 2008 17:21:01 -0400 (EDT)) Subject: Re: SAIL References: <200805042121.m44LL1gR000490@ultimate.com> Message-Id: <20080506195626.0FF3A241AF@panix5.panix.com> Date: Tue, 6 May 2008 15:56:25 -0400 (EDT) ReSent-Date: Tue, 6 May 2008 22:24:49 -0700 (PDT) ReSent-From: TOPS-20 List Moderator ReSent-To: TOPS-20 Distribution: ; ReSent-Subject: Re: SAIL ReSent-Message-ID: ReSent-User-Agent: Alpine 1.10 (OSX 1045 2008-05-02) > Date: Sun, 4 May 2008 17:21:01 -0400 (EDT) > From: Phil Budne [quoting Tom DeBellis] >> But I suppose the source for SAIL itself is lost... Sigh. > Not lost: > ftp://ftp.ultimate.com/pdp10/sail.tar.gz > These came off an old DECUS tape I have an image file of somewhere > that also includes the binaries... The listing of those tapes can be > seen at: > ftp://ftp.ultimate.com/pdp10/decus/ It's also available on the PDPplanet Toad-1, in PS:. Rich 7-May-2008 08:05:26-PDT,2817;000000000000 Return-Path: Received: from pangtzu.panda.com ([206.124.149.117]) by Lingling.Panda.COM with TCP/SMTP; Wed, 7 May 2008 07:59:09 -0700 (PDT) X-Return-Path: X-Received: from sj-iport-3.cisco.com ([171.71.176.72]) by Lingling.Panda.COM with TCP/SMTP; Tue, 6 May 2008 23:11:05 -0700 (PDT) X-Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-3.cisco.com with ESMTP; 06 May 2008 23:10:51 -0700 X-Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m476ApYf006276; Tue, 6 May 2008 23:10:51 -0700 X-Received: from cisco.com (pita.cisco.com [171.71.177.199]) by sj-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m476ApZA000080; Wed, 7 May 2008 06:10:51 GMT X-Received: (from billw@localhost) by cisco.com (8.8.8-Cisco List Logging/8.8.8) id XAA27089; Tue, 6 May 2008 23:08:02 -0700 (PDT) Sender: Bill Westfield Date: Tue, 6 May 2008 23:08:02 PDT From: William "Chops" Westfield To: Rich Alderson Cc: TOPS-20 List Moderator , TOPS-20@Lingling.Panda.COM Subject: Re: SAIL In-Reply-To: Your message of Tue, 6 May 2008 15:56:25 -0400 (EDT) Message-ID: DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=483; t=1210140651; x=1211004651; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=billw@cisco.com; z=From:=20William=20=22Chops=22=20Westfield=20 |Subject:=20Re=3A=20SAIL |Sender:=20Bill=20Westfield=20; bh=atCrmp6JqPG02P+c+1TB9gFgTs6mZmViCUYrn1JYFBI=; b=u/D1eskZT63SwRhviGdekZKl1y3/TpBDioRq4kiW/4ne6QB+7O5aQ+CIzR W2bxyq5E65J3DOZLG537jqjLkX2YPbkN5PzVGhT+NdJwH75W+n1B+bQfub0x ofTNyrX1MA; Authentication-Results: sj-dkim-2; header.From=billw@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); ReSent-Date: Wed, 7 May 2008 07:58:50 -0700 (PDT) ReSent-From: TOPS-20 List Moderator ReSent-To: TOPS-20 Distribution: ; ReSent-Subject: Re: SAIL ReSent-Message-ID: ReSent-User-Agent: Alpine 1.10 (OSX 1045 2008-05-02) Also, at the 36 anniversary dinner in Los Altos a few years back, the Stanford folk were showing off the 3.5inch hard disk that they had managed to copy ALL of the SAIL backup tapes to. Presumably some of those tapes had source... Did anything ever happen with that collection of data? IIRC, they were starting to wrestle with the legal issues surrounding access to 20years worth of random people's personal files, and I never heard anything further about it... BillW 7-May-2008 20:23:10-PDT,2958;000000000000 Return-Path: Received: from pangtzu.panda.com ([206.124.149.117]) by Lingling.Panda.COM with TCP/SMTP; Wed, 7 May 2008 20:17:26 -0700 (PDT) X-Return-Path: X-Received: from mail.math.utah.edu ([155.101.98.135]) by Lingling.Panda.COM with TCP/SMTP; Wed, 7 May 2008 17:23:11 -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 m480N460021206; Wed, 7 May 2008 18:23:04 -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 m480N4Vb016097; Wed, 7 May 2008 18:23:04 -0600 (MDT) X-Received: (from beebe@localhost) by psi.math.utah.edu (8.13.6/8.13.6/Submit) id m480N47q016096; Wed, 7 May 2008 18:23:04 -0600 (MDT) Date: Wed, 7 May 2008 18:23:04 -0600 (MDT) From: "Nelson H. F. Beebe" To: Tops-20 Wizards Cc: beebe@math.utah.edu X-US-Mail: "Department of Mathematics, 110 LCB, University of Utah, 155 S 1400 E RM 233, Salt Lake City, UT 84112-0090, USA" X-Telephone: +1 801 581 5254 X-FAX: +1 801 585 1640, +1 801 581 4148 X-URL: http://www.math.utah.edu/~beebe Subject: Re: Tops-20 Labels Message-ID: X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0 (mail.math.utah.edu [155.101.98.135]); Wed, 07 May 2008 18:23:05 -0600 (MDT) ReSent-Date: Wed, 7 May 2008 20:17:19 -0700 (PDT) ReSent-From: TOPS-20 List Moderator ReSent-To: TOPS-20 Distribution: ; ReSent-Subject: Re: Tops-20 Labels ReSent-Message-ID: ReSent-User-Agent: Alpine 1.10 (OSX 1045 2008-05-02) We sent out hundreds of tapes written with tputil, a TOPS-20 MACRO program that I did at lot of work on from 30 to 25 years ago. I've just scanned my TOPS-20 filesystem archives, and pulled up the most recent copy, and then put it at this unlinked-to Web site for any list readers who wish to grab it: http://www.math.utah.edu/~beebe/software/tputil/tputil.mac http://www.math.utah.edu/~beebe/software/tputil/tputil.doc I've not run it in two decades, and we don't have any devices here that it will talk to, our last 9-track drives having been retired more than 15 years ago. ------------------------------------------------------------------------------- - Nelson H. F. Beebe Tel: +1 801 581 5254 - - University of Utah FAX: +1 801 581 4148 - - Department of Mathematics, 110 LCB Internet e-mail: beebe@math.utah.edu - - 155 S 1400 E RM 233 beebe@acm.org beebe@computer.org - - Salt Lake City, UT 84112-0090, USA URL: http://www.math.utah.edu/~beebe/ - ------------------------------------------------------------------------------- 7-May-2008 20:27:01-PDT,2958;000000000000 Return-Path: Received: from pangtzu.panda.com ([206.124.149.117]) by Lingling.Panda.COM with TCP/SMTP; Wed, 7 May 2008 20:18:56 -0700 (PDT) X-Return-Path: X-Received: from mail.math.utah.edu ([155.101.98.135]) by Lingling.Panda.COM with TCP/SMTP; Wed, 7 May 2008 17:23:11 -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 m480N460021206; Wed, 7 May 2008 18:23:04 -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 m480N4Vb016097; Wed, 7 May 2008 18:23:04 -0600 (MDT) X-Received: (from beebe@localhost) by psi.math.utah.edu (8.13.6/8.13.6/Submit) id m480N47q016096; Wed, 7 May 2008 18:23:04 -0600 (MDT) Date: Wed, 7 May 2008 18:23:04 -0600 (MDT) From: "Nelson H. F. Beebe" To: Tops-20 Wizards Cc: beebe@math.utah.edu X-US-Mail: "Department of Mathematics, 110 LCB, University of Utah, 155 S 1400 E RM 233, Salt Lake City, UT 84112-0090, USA" X-Telephone: +1 801 581 5254 X-FAX: +1 801 585 1640, +1 801 581 4148 X-URL: http://www.math.utah.edu/~beebe Subject: Re: Tops-20 Labels Message-ID: X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0 (mail.math.utah.edu [155.101.98.135]); Wed, 07 May 2008 18:23:05 -0600 (MDT) ReSent-Date: Wed, 7 May 2008 20:18:41 -0700 (PDT) ReSent-From: TOPS-20 List Moderator ReSent-To: TOPS-20 Distribution: ; ReSent-Subject: Re: Tops-20 Labels ReSent-Message-ID: ReSent-User-Agent: Alpine 1.10 (OSX 1045 2008-05-02) We sent out hundreds of tapes written with tputil, a TOPS-20 MACRO program that I did at lot of work on from 30 to 25 years ago. I've just scanned my TOPS-20 filesystem archives, and pulled up the most recent copy, and then put it at this unlinked-to Web site for any list readers who wish to grab it: http://www.math.utah.edu/~beebe/software/tputil/tputil.mac http://www.math.utah.edu/~beebe/software/tputil/tputil.doc I've not run it in two decades, and we don't have any devices here that it will talk to, our last 9-track drives having been retired more than 15 years ago. ------------------------------------------------------------------------------- - Nelson H. F. Beebe Tel: +1 801 581 5254 - - University of Utah FAX: +1 801 581 4148 - - Department of Mathematics, 110 LCB Internet e-mail: beebe@math.utah.edu - - 155 S 1400 E RM 233 beebe@acm.org beebe@computer.org - - Salt Lake City, UT 84112-0090, USA URL: http://www.math.utah.edu/~beebe/ - ------------------------------------------------------------------------------- 11-May-2008 11:30:19-PDT,2366;000000000000 Return-Path: Received: from pangtzu.panda.com ([206.124.149.117]) by Lingling.Panda.COM with TCP/SMTP; Sun, 11 May 2008 11:23:50 -0700 (PDT) X-Return-Path: X-Received: from b.mail.sonic.net ([64.142.19.5]) by Lingling.Panda.COM with TCP/SMTP; Sun, 11 May 2008 11:19:26 -0700 (PDT) X-Received: from Amiga.local (64-142-29-114.dsl.static.sonic.net [64.142.29.114]) by b.mail.sonic.net (8.13.8.Beta0-Sonic/8.13.7) with ESMTP id m4BIJKcZ027921 for ; Sun, 11 May 2008 11:19:20 -0700 Date: Sun, 11 May 2008 11:19:20 -0700 (PDT) From: Fred Wright X-Sender: fw@Amiga.local Reply-To: Fred Wright To: Tops-20 Wizards Subject: Re: Tops-20 Labels In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII ReSent-Date: Sun, 11 May 2008 11:23:42 -0700 (PDT) ReSent-From: TOPS-20 List Moderator ReSent-To: TOPS-20 Distribution: ; ReSent-Subject: Re: Tops-20 Labels ReSent-Message-ID: ReSent-User-Agent: Alpine 1.10 (OSX 1045 2008-05-02) On Sun, 4 May 2008, Mark Crispin wrote: > On Sun, 4 May 2008, Fred Wright wrote: > > Bear in mind that the > > standard was updated some time in the 90s to fix the Y2K problem (which is > > probably not reflected in MOUNTR). The updated version still has a Y3K > > problem. > > How did they contrive to have a Y3K problem? Are they using some form of > BCD? If by "BCD" you mean "unpacked BCD", then I suppose you could call it that. :-) As with a large majority of Y2K-affected formats, the year was stored as two decimal digits of text (ASCII or EBCDIC). The one saving grace is that there was *one* spare position to the left of the year, which was originally specified as "blank". The extension involved permitting this position to be a decimal digit. Thus: Old: Year field = BYY, where B = blank, representing the year 19YY New: Year field = CYY: Year = 19YY if C = blank Year = 2CYY if C is a digit It looks like I implemented this in TAPE.MAC, though I didn't do anything to MOUNTR. Fred Wright 11-May-2008 11:44:49-PDT,1553;000000000000 Return-Path: Received: from pangtzu.panda.com ([206.124.149.117]) by Lingling.Panda.COM with TCP/SMTP; Sun, 11 May 2008 11:39:44 -0700 (PDT) X-Return-Path: X-Received: from pangtzu.panda.com ([206.124.149.117]) by Lingling.Panda.COM with TCP/SMTP; Sun, 11 May 2008 11:35:12 -0700 (PDT) Date: Sun, 11 May 2008 11:35:07 -0700 (PDT) From: Mark Crispin Sender: mrc@pangtzu.panda.com To: Fred Wright cc: Tops-20 Wizards Subject: Re: Tops-20 Labels In-Reply-To: Message-ID: References: User-Agent: Alpine 1.10 (OSX 1031 2008-04-10) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed ReSent-Date: Sun, 11 May 2008 11:39:37 -0700 (PDT) ReSent-From: TOPS-20 List Moderator ReSent-To: TOPS-20 Distribution: ; ReSent-Subject: Re: Tops-20 Labels ReSent-Message-ID: ReSent-User-Agent: Alpine 1.10 (OSX 1045 2008-05-02) On Sun, 11 May 2008, Fred Wright wrote: > It looks like I implemented this in TAPE.MAC, though I didn't do anything > to MOUNTR. Thanks for the information. Would you be willing to share that TAPE.MAC patch with the list? -- Mark -- http://panda.com/tops-20 TOPS-20: a great improvement over its successors 17-May-2008 09:39:55-PDT,1289;000000000000 Return-Path: Received: from pangtzu.panda.com ([206.124.149.117]) by Lingling.Panda.COM with TCP/SMTP; Sat, 17 May 2008 09:34:12 -0700 (PDT) X-Return-Path: X-Received: from pangtzu.panda.com ([206.124.149.117]) by Lingling.Panda.COM with TCP/SMTP; Sat, 17 May 2008 09:33:00 -0700 (PDT) Date: Sat, 17 May 2008 09:32:55 -0700 (PDT) From: Mark Crispin Sender: mrc@pangtzu.panda.com To: TOPS-20 Hackers and Yackers Subject: 25 years ago today... Message-ID: User-Agent: Alpine 1.10 (OSX 1054 2008-05-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII ReSent-Date: Sat, 17 May 2008 09:34:05 -0700 (PDT) ReSent-From: TOPS-20 List Moderator ReSent-To: TOPS-20 Distribution: ; ReSent-Subject: 25 years ago today... ReSent-Message-ID: ReSent-User-Agent: Alpine 1.10 (OSX 1054 2008-05-14) At 2PM Eastern Daylight time on May 17, 1983, 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 17-May-2008 18:14:36-PDT,2171;000000000000 Return-Path: Received: from pangtzu.panda.com ([206.124.149.117]) by Lingling.Panda.COM with TCP/SMTP; Sat, 17 May 2008 18:09:28 -0700 (PDT) X-Return-Path: X-Received: from mta3.srv.hcvlny.cv.net ([167.206.4.198]) by Lingling.Panda.COM with TCP/SMTP; Sat, 17 May 2008 17:06:05 -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-8.04 (built Feb 28 2007)) with ESMTP id <0K1100DSMEXQJ7C0@mta3.srv.hcvlny.cv.net> for TOPS-20@lingling.panda.com; Sat, 17 May 2008 20:05:50 -0400 (EDT) X-Received: from [10.240.3.212] (Forwarded-For: 64.72.85.122, [10.240.3.212]) by mstr3.srv.hcvlny.cv.net (mshttpd); Sun, 18 May 2008 00:05:50 +0000 (GMT) Date: Sun, 18 May 2008 00:05:50 +0000 (GMT) From: slogin@optonline.net Subject: Tops-20 Keyboard Lock? To: Tops-20 Wizards Message-id: MIME-version: 1.0 X-Mailer: Sun Java(tm) System Messenger Express 6.2-8.04 (built Feb 28 2007) 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, 17 May 2008 18:09:18 -0700 (PDT) ReSent-From: TOPS-20 List Moderator ReSent-To: TOPS-20 Distribution: ; ReSent-Subject: Tops-20 Keyboard Lock? ReSent-Message-ID: ReSent-User-Agent: Alpine 1.10 (OSX 1054 2008-05-14) I need a CUSP to lock a keyboard. By that, I mean you say something like 'lock' and it asks you for a lock password which it does not echo. Then it clears the screen and you can't do anything with the job until the password is correctly typed back in. Or maybe it locks the keyboard and doesn't unlock until you type in the login password (which it checks with an ACCES%?) I seem to remember something like this on Tops-20 or maybe ITS? At least at Columbia, it didn't work because of our PACX terminal concentrator and it was considered anti-social, anyway. 19-May-2008 20:01:10-PDT,2629;000000000000 Return-Path: Received: from pangtzu.panda.com ([206.124.149.117]) by Lingling.Panda.COM with TCP/SMTP; Mon, 19 May 2008 19:54:43 -0700 (PDT) X-Return-Path: X-Received: from smtpoutm.mac.com ([17.148.16.69]) by Lingling.Panda.COM with TCP/SMTP; Mon, 19 May 2008 17:17:13 -0700 (PDT) X-Received: from mac.com (asmtp001-s [10.150.69.64]) by smtpoutm.mac.com (Xserve/smtpout006/MantshX 4.0) with ESMTP id m4K0H7Vj004185; Mon, 19 May 2008 17:17:07 -0700 (PDT) X-Received: from [192.168.1.58] (c-24-147-40-233.hsd1.nh.comcast.net [24.147.40.233]) (authenticated bits=0) by mac.com (Xserve/asmtp001/MantshX 4.0) with ESMTP id m4K0H5Zn010856 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 19 May 2008 17:17:06 -0700 (PDT) Cc: Tops-20 Wizards Message-Id: From: John Francini To: slogin@optonline.net In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v919.2) Subject: Re: Tops-20 Keyboard Lock? Date: Mon, 19 May 2008 20:17:05 -0400 References: X-Mailer: Apple Mail (2.919.2) ReSent-Date: Mon, 19 May 2008 19:54:35 -0700 (PDT) ReSent-From: TOPS-20 List Moderator ReSent-To: TOPS-20 Distribution: ; ReSent-Subject: Re: Tops-20 Keyboard Lock? ReSent-Message-ID: ReSent-User-Agent: Alpine 1.10 (OSX 1054 2008-05-14) Dumb-ass question: why not simply DETACH the job? Then you can't connect back to it without a password. It was the way I did it back in the day on DEC-10s when they weren't busy (and when I was a developer on KL1026), before using a VAXstation as a 'terminal concentrator'. john On 17 May 2008, at 20:05, slogin@optonline.net wrote: > I need a CUSP to lock a keyboard. By that, I mean you say something > like 'lock' and it asks you for a lock password which it does not > echo. > > Then it clears the screen and you can't do anything with the job until > the password is correctly typed back in. Or maybe it locks the > keyboard and doesn't unlock until you type in the login password > (which it checks with an ACCES%?) > > I seem to remember something like this on Tops-20 or maybe ITS? At > least at Columbia, it didn't work because of our PACX terminal > concentrator and it was considered anti-social, anyway. > 20-May-2008 05:34:36-PDT,2495;000000000000 Return-Path: Received: from pangtzu.panda.com ([206.124.149.117]) by Lingling.Panda.COM with TCP/SMTP; Tue, 20 May 2008 05:27:33 -0700 (PDT) X-Return-Path: X-Received: from smtp02.lnh.mail.rcn.net ([207.172.157.102]) by Lingling.Panda.COM with TCP/SMTP; Tue, 20 May 2008 04:06:31 -0700 (PDT) X-Received: from mr02.lnh.mail.rcn.net ([207.172.157.22]) by smtp02.lnh.mail.rcn.net with ESMTP; 20 May 2008 07:06:25 -0400 X-Received: from smtp01.lnh.mail.rcn.net (smtp01.lnh.mail.rcn.net [207.172.4.11]) by mr02.lnh.mail.rcn.net (MOS 3.8.6-GA) with ESMTP id ORJ48803; Tue, 20 May 2008 07:06:21 -0400 (EDT) X-Received: from c-76-19-133-78.hsd1.ma.comcast.net (HELO [127.0.0.1]) ([76.19.133.78]) by smtp01.lnh.mail.rcn.net with ESMTP; 20 May 2008 07:06:21 -0400 Message-ID: <4832B0AC.3070101@RCN.Com> Date: Tue, 20 May 2008 07:06:20 -0400 From: "Alan H. Martin" User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: John Francini CC: slogin@optonline.net, Tops-20 Wizards Subject: Re: Tops-20 Keyboard Lock? References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Junkmail-Whitelist: YES (by domain whitelist at mr02.lnh.mail.rcn.net) ReSent-Date: Tue, 20 May 2008 05:27:19 -0700 (PDT) ReSent-From: TOPS-20 List Moderator ReSent-To: TOPS-20 Distribution: ; ReSent-Subject: Re: Tops-20 Keyboard Lock? ReSent-Message-ID: ReSent-User-Agent: Alpine 1.10 (OSX 1054 2008-05-14) John Francini wrote: > Dumb-ass question: why not simply DETACH the job? Then you can't > connect back to it without a password. It was the way I did it back in > the day on DEC-10s when they weren't busy (and when I was a developer on > KL1026), before using a VAXstation as a 'terminal concentrator'. Back In The Day, at sufficiently small timesharing sites a session's most important resource could well be the controlling terminal hardware itself. If one detached their job to secure it over a bathroom break, one might return to find someone else using the terminal. /AHM -- Alan Howard Martin AMartin.MA.UltraNet@RCN.Com 20-May-2008 23:17:01-PDT,2668;000000000000 Return-Path: Received: from pangtzu.panda.com ([206.124.149.117]) by Lingling.Panda.COM with TCP/SMTP; Tue, 20 May 2008 23:10:40 -0700 (PDT) X-Return-Path: X-Received: from aussmtpmrkpc120.us.dell.com ([143.166.82.159]) by Lingling.Panda.COM with TCP/SMTP; Tue, 20 May 2008 13:29:28 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.27,517,1204524000"; d="scan'208";a="349400502" X-Received: from unknown (HELO M31.equallogic.com) ([12.110.134.31]) by aussmtpmrkpc120.us.dell.com with SMTP; 20 May 2008 15:29:18 -0500 In-Reply-To: <4832B0AC.3070101@RCN.Com> References: <4832B0AC.3070101@RCN.Com> Mime-Version: 1.0 (Apple Message framework v753) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <4CD4BFAB-286E-4E21-A092-E1E45BB606B1@mac.com> Cc: slogin@optonline.net, Tops-20 Wizards Content-Transfer-Encoding: 7bit From: John Francini Subject: Re: Tops-20 Keyboard Lock? Date: Tue, 20 May 2008 16:28:58 -0400 To: "Alan H. Martin" X-Mailer: Apple Mail (2.753) X-Return-Path: francini@mac.com X-OriginalArrivalTime: 20 May 2008 20:29:00.0347 (UTC) FILETIME=[22F7C0B0:01C8BAB8] ReSent-Date: Tue, 20 May 2008 23:10:33 -0700 (PDT) ReSent-From: TOPS-20 List Moderator ReSent-To: TOPS-20 Distribution: ; ReSent-Subject: Re: Tops-20 Keyboard Lock? ReSent-Message-ID: ReSent-User-Agent: Alpine 1.10 (OSX 1054 2008-05-14) Admittedly true; however, it also depended on (a) whether you were 'just a luser' or on the staff, or (b) how busy the terminal room was. Late at night was often a fine time to do that; 12:00 noon on final projects-due week wasn't. j On 20 May 2008, at 7:06, Alan H. Martin wrote: > John Francini wrote: >> Dumb-ass question: why not simply DETACH the job? Then you can't >> connect back to it without a password. It was the way I did it >> back in the day on DEC-10s when they weren't busy (and when I was >> a developer on KL1026), before using a VAXstation as a 'terminal >> concentrator'. > > Back In The Day, at sufficiently small timesharing sites a > session's most important resource could well be the controlling > terminal hardware itself. If one detached their job to secure it > over a bathroom break, one might return to find someone else using > the terminal. > /AHM > -- > Alan Howard Martin AMartin.MA.UltraNet@RCN.Com > > 20-May-2008 23:21:32-PDT,2732;000000000000 Return-Path: Received: from pangtzu.panda.com ([206.124.149.117]) by Lingling.Panda.COM with TCP/SMTP; Tue, 20 May 2008 23:11:03 -0700 (PDT) X-Return-Path: X-Received: from aussmtpmrkps320.us.dell.com ([143.166.224.254]) by Lingling.Panda.COM with TCP/SMTP; Tue, 20 May 2008 13:31:46 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.27,517,1204524000"; d="scan'208";a="365012377" X-Received: from unknown (HELO M31.equallogic.com) ([12.110.134.31]) by aussmtpmrkps320.us.dell.com with SMTP; 20 May 2008 15:31:40 -0500 In-Reply-To: <200805201524.m4KFO64b2604663@shell01.TheWorld.com> References: <4832B0AC.3070101@RCN.Com> <200805201524.m4KFO64b2604663@shell01.TheWorld.com> Mime-Version: 1.0 (Apple Message framework v753) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <441F9960-20FA-4A10-986D-F0BBFA99C508@mac.com> Cc: AMartin.MA.UltraNet@RCN.Com, slogin@optonline.net, TOPS-20@Lingling.Panda.COM Content-Transfer-Encoding: 7bit From: John Francini Subject: Re: Tops-20 Keyboard Lock? Date: Tue, 20 May 2008 16:31:01 -0400 To: "Jonathan A. Solomon" X-Mailer: Apple Mail (2.753) X-Return-Path: francini@mac.com X-OriginalArrivalTime: 20 May 2008 20:31:03.0542 (UTC) FILETIME=[6C65D160:01C8BAB8] ReSent-Date: Tue, 20 May 2008 23:10:46 -0700 (PDT) ReSent-From: TOPS-20 List Moderator ReSent-To: TOPS-20 Distribution: ; ReSent-Subject: Re: Tops-20 Keyboard Lock? ReSent-Message-ID: ReSent-User-Agent: Alpine 1.10 (OSX 1054 2008-05-14) Those programs were usually locally written; there wasn't, if I recall, a DEC-supplied CUSP to go killing detached jobs. On the -10, the INITIA program running on FRCLIN would change its name to TTY STOMPR and stomp (set baud rate to 0) on any terminal lines that were seen to be running open. john On 20 May 2008, at 11:24, Jonathan A. Solomon wrote: > yeah the other problem is that there was a program running > on the TOPS-10 which k/b'd the detached jobs. > > What was worse was that there was a program which deleted > Old files which were still on the disk, freeing up > valualble space while forcing people to keep magtape > or even DECtape or foreign disk, to keep files active. > > That was the DEC-10 at Stevens.... > > detaching the job to tops-20 will work unless they have > a process which logs out these jobs... > > that all depends on the avialable resources.... the -10 at > Stevens was very small and limited. > > --jsol 6-Jun-2008 10:50:24-PDT,1636;000000000000 Return-Path: Received: from pangtzu.panda.com ([206.124.149.117]) by Lingling.Panda.COM with TCP/SMTP; Fri, 6 Jun 2008 10:44:15 -0700 (PDT) X-Return-Path: X-Received: from mta5.srv.hcvlny.cv.net ([167.206.4.200]) by Lingling.Panda.COM with TCP/SMTP; Fri, 6 Jun 2008 09:18:01 -0700 (PDT) X-Received: from Whitestar2 (ool-4577982f.dyn.optonline.net [69.119.152.47]) by mta5.srv.hcvlny.cv.net (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with SMTP id <0K2100M6FULPXM91@mta5.srv.hcvlny.cv.net> for TOPS-20@lingling.panda.com; Fri, 06 Jun 2008 12:17:50 -0400 (EDT) Date: Fri, 06 Jun 2008 12:17:45 -0400 From: Mike Ross Subject: pdp-10 for sale To: TOPS-20@lingling.panda.com Message-id: <4noi44pt90pi707htbhobu806gbouil2ad@4ax.com> 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: Fri, 6 Jun 2008 10:44:05 -0700 (PDT) ReSent-From: TOPS-20 List Moderator ReSent-To: TOPS-20 Distribution: ; ReSent-Subject: pdp-10 for sale ReSent-Message-ID: ReSent-User-Agent: Alpine 1.10 (OSX 1074 2008-06-04) I've finally gone and done it: http://cgi.ebay.com/ws/eBayISAPI.dll?ViewItem&item=150256074674 Don't really want to, but if a deep-pocket collector decides to bite, it's gone. (I'd consider a trade involving a TOAD or System/360(!) ) Mike -- http://www.corestore.org 'As I walk along these shores I am the history within' 5-Jul-2008 09:54:18-PDT,5446;000000000000 Return-Path: Received: from pangtzu.panda.com ([206.124.149.117]) by Lingling.Panda.COM with TCP/SMTP; Sat, 5 Jul 2008 09:48:25 -0700 (PDT) X-Return-Path: X-Received: from mta5.srv.hcvlny.cv.net ([167.206.4.200]) by Lingling.Panda.COM with TCP/SMTP; Sat, 5 Jul 2008 09:32:27 -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-8.04 (built Feb 28 2007)) with ESMTP id <0K3J007C0KLO6460@mta5.srv.hcvlny.cv.net> for TOPS-20@lingling.panda.com; Sat, 05 Jul 2008 12:32:13 -0400 (EDT) Date: Sat, 05 Jul 2008 12:32:11 -0400 From: Thomas DeBellis Subject: ULKSTZ BUGCHK on IOX10 SINR% error To: Tops-20 Wizards Message-id: <486FA20B.9090103@optonline.net> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) ReSent-Date: Sat, 5 Jul 2008 09:48:17 -0700 (PDT) ReSent-From: TOPS-20 List Moderator ReSent-To: TOPS-20 Distribution: ; ReSent-Subject: ULKSTZ BUGCHK on IOX10 SINR% error ReSent-Message-ID: ReSent-User-Agent: Alpine 1.10 (OSX 1074 2008-06-04) While debugging the paged store code in the new FTP server, I ran across some unexpected behavior. This looks like a bug in both cases, but I should hasten to add here that what I'm doing probably wouldn't be done in practice. For debugging purposes, the new server has commands to override network input and output and read from or write to a file. The network 'input' file in question is a 1,656 page 8 bit file which contains the results of a paged retrieve. In other words, I wrote a test file with the known working paged retrieve code by diverting the network output into a file. It's straightforward enough, viz: @g eftpsr @reenter 220 TOMMYT TOPS20 FTP Server V7.1(15839) on Sat Jul 5, 2008 12:14:52PM-EDT EFTPSER>buffer 512 200 Transfer buffer size set to 512 pages, maximum 512 pages, minimum 2 pages. EFTPSER>type I 200 Type I ok. EFTPSER>stru p 200 Structure P ok. EFTPSER>override input NUL: 200 Network input override set to: NUL: EFTPSER>override output eftpsr.8bit 200 Network output override set to: STAR:EFTPSR.8BIT EFTPSER>retR (a file) eftpsr.lsT.8 150 Retrieving STAR:EFTPSR.LST.8, Image (36), Non-printing, Stream, Paged 250 Inferior fork retrieved STAR:EFTPSR.LST.8 (521.25 kB/s) This produces the following file: STAR: EFTPSR.8BIT.1;P777700 1656 3389963(8) 4-Jul-2008 20:34:47 SLOGIN To test the paged store code, I simply override the network input JFN with a disk file and read from that with a SINR%. This is done into a 512 page section which is then processed. Such a section will store 1,048,576 (^D512*^D512*^D4) 8 bit bytes. Setting up such a situation is also straightforward: @g eftpsr @reenter 220 TOMMYT TOPS20 FTP Server V7.1(15839) on Sat Jul 5, 2008 12:19:37PM-EDT EFTPSER>buffer 512 200 Transfer buffer size set to 512 pages, maximum 512 pages, minimum 2 pages. EFTPSER>type I 200 Type I ok. EFTPSER>stru P 200 Structure P ok. EFTPSER>override input eftpsr.8bit 200 Network input override set to: STAR:EFTPSR.8BIT EFTPSER>override output NUL: 200 Network output override set to: NUL: EFTPSER>stor eftpsr.output 150 Storing file STAR:EFTPSR.OUTPUT.34, Image (36), Non-printing, Stream, Paged While doing the STOR, the unexpected behavior happens in two (2) cases. First, if I set the EXACT number of bytes in the SINR% call to the above number (1,048,576), I get an ILLX01, (Illegal memory read). I couldn't be reading off the end of the 'network' file and the negative count should keep me from storing one more byte than the buffer will hold. It seems to me that I should only get either a IOX4 (End of file reached) or a IOX10 (Record is longer than user requested). If I got the input count wrong, then I would have anticipated an ILLX02 (Illegal memory write). Second, while trouble shooting the code, I passed in the same arguments to SINR%, but with one less word under the assumption that I had committed my typical off-by-one error. In this case, I get the expected IOX10 error, but I also generate ULKSTZ BUGCHK. (!) The system has been up over 3,457 hours, but this particular job has been logged in for 'only' 142 hours. I thought it might be anti- social to try to replicate this behavior on other systems and decided to ask first before giving it a closer look. Case I - SINR% of the exact number of bytes in the buffer. $1B>>DSINR#/ SINR% 1[ 6 1,,T2[ 540005,,0 1,,T3[ 777774,,0 1,,T4[ 0 $x DSINR#+1/ ERJMPR DSINR#+3 3,,47670 DSINR#+3/ CAIN T1,PAT..+211 1[ 601774 Case II - SINR% of one word less $1B>>DSINR#/ SINR% 1[ 6 1,,T2[ 540005,,0 1,,T3[ 777774,,4 1,,T4[ 0 $x DSINR#+1/ ERJMPR DSINR#+3 3,,47670 DSINR#+3/ CAIN T1,PAT..+211 1[ 601240 5-Jul-2008 12:07:55 ***BUGCHK ULKSTZ*** Overly decremented structure lock Job: 9, User: SLOGIN 5-Jul-2008 10:07:18-PDT,1993;000000000000 Return-Path: Received: from pangtzu.panda.com ([206.124.149.117]) by Lingling.Panda.COM with TCP/SMTP; Sat, 5 Jul 2008 10:02:50 -0700 (PDT) X-Return-Path: X-Received: from pangtzu.panda.com ([206.124.149.117]) by Lingling.Panda.COM with TCP/SMTP; Sat, 5 Jul 2008 10:02:18 -0700 (PDT) Date: Sat, 5 Jul 2008 10:02:13 -0700 (PDT) From: Mark Crispin Sender: mrc@pangtzu.panda.com To: Thomas DeBellis cc: Tops-20 Wizards Subject: Re: ULKSTZ BUGCHK on IOX10 SINR% error In-Reply-To: <486FA20B.9090103@optonline.net> Message-ID: References: <486FA20B.9090103@optonline.net> User-Agent: Alpine 1.10 (OSX 1074 2008-06-04) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII ReSent-Date: Sat, 5 Jul 2008 10:02:41 -0700 (PDT) ReSent-From: TOPS-20 List Moderator ReSent-To: TOPS-20 Distribution: ; ReSent-Subject: Re: ULKSTZ BUGCHK on IOX10 SINR% error ReSent-Message-ID: ReSent-User-Agent: Alpine 1.10 (OSX 1074 2008-06-04) If I had to guess, the reason for the ILL0X1 for a read that ends at a section boundary is that something is looking at the very next byte afterwards, perhaps with a view to writing a NUL. I don't understand why you're still using SINR%; as far as I know SINR% is only truly useful for magtapes and perhaps DECnet for VMS. I doubt that anyone other than you has ever tried to use that kludge in which SINR% follows TCP Push; as we've been trying to tell you Push is not a record marker and you shouldn't treat it as such. It's certainly not useful for the disk. The ULKSTZ bugchk is definitely a bug. Do you have a short program which reproduces it? -- Mark -- http://panda.com/tops-20 TOPS-20: a great improvement over its successors 5-Jul-2008 16:48:55-PDT,3913;000000000000 Return-Path: Received: from pangtzu.panda.com ([206.124.149.117]) by Lingling.Panda.COM with TCP/SMTP; Sat, 5 Jul 2008 16:43:25 -0700 (PDT) X-Return-Path: X-Received: from mta5.srv.hcvlny.cv.net ([167.206.4.200]) by Lingling.Panda.COM with TCP/SMTP; Sat, 5 Jul 2008 12:44:58 -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-8.04 (built Feb 28 2007)) with ESMTP id <0K3J008QUTIRSRA0@mta5.srv.hcvlny.cv.net>; Sat, 05 Jul 2008 15:44:52 -0400 (EDT) Date: Sat, 05 Jul 2008 15:44:50 -0400 From: Thomas DeBellis Subject: Re: ULKSTZ BUGCHK on IOX10 SINR% error In-reply-to: To: Mark Crispin Cc: Tops-20 Wizards Message-id: <486FCF32.6070000@optonline.net> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en References: <486FA20B.9090103@optonline.net> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) ReSent-Date: Sat, 5 Jul 2008 16:43:17 -0700 (PDT) ReSent-From: TOPS-20 List Moderator ReSent-To: TOPS-20 Distribution: ; ReSent-Subject: Re: ULKSTZ BUGCHK on IOX10 SINR% error ReSent-Message-ID: ReSent-User-Agent: Alpine 1.10 (OSX 1074 2008-06-04) > If I had to guess, the reason for the ILL0X1 for a read that ends at > a section boundary is that something is looking at the very next > byte afterwards, perhaps with a view to writing a NUL. Yes, my suspicion is that this is an off by one error. In IO.MAC, it looks like you reworked some of that code at one point to trap errors on some XCT's, so maybe some of that may jog your memory. I didn't see anything obvious (which means absolutely nothing). > I don't understand why you're still using SINR%; as far as I know SINR% > is only truly useful for magtapes and perhaps DECnet for VMS. I doubt > that anyone other than you has ever tried to use that kludge in which > SINR% follows TCP Push; as we've been trying to tell you Push is not a > record marker and you shouldn't treat it as such. It's certainly not > useful for the disk. I'm using SINR% because I can pick up some speed if I know that a PSH happened. Even if it doesn't work right (or at all), the code will recover and do the right thing (it will just be slower). I'm doing a SINR% from the disk because that involved less code change while debugging. In other words, I wanted to exercise the same code path just using different JFNs. > The ULKSTZ bugchk is definitely a bug. Do you have a short program > which reproduces it? See below. Remove the +4 on the arguments to the SINR% to replicate the ILLOX1. Note that the code executes out of section zero and still produces the errors indicated above. TITLE ULKSTZ SEARCH MONSYM,MACSYM STDAC. ULKSTZ: DMOVE T1, [ -1,,[ASCIZ /EFTPSR.8BIT/] ] GTJFN% ERJMPR DONE HRRZS P4,T1 MOVX T2, OPENF% ERJMPR DONE SETZ T1, DMOVE T2, [ .FHSLF,,5 ] SMAP% ERJMPR DONE MOVE T1,P4 MOVX T2,<.P08!<5,,0>> DMOVE T3, [ -<^D512*^D512*^D4> + 4 0 ] SINR% ERJMPR DONE SETZ T1, DONE: HALTF% JRST ULKSTZ END 1,,ULKSTZ 6-Jul-2008 12:37:52-PDT,1657;000000000000 Return-Path: Received: from pangtzu.panda.com ([206.124.149.117]) by Lingling.Panda.COM with TCP/SMTP; Sun, 6 Jul 2008 12:31:55 -0700 (PDT) X-Return-Path: X-Received: from b.mail.sonic.net ([64.142.19.5]) by Lingling.Panda.COM with TCP/SMTP; Sun, 6 Jul 2008 12:15:30 -0700 (PDT) X-Received: from Amiga.local (64-142-29-114.dsl.static.sonic.net [64.142.29.114]) by b.mail.sonic.net (8.13.8.Beta0-Sonic/8.13.7) with ESMTP id m66JFOe3010489 for ; Sun, 6 Jul 2008 12:15:24 -0700 Date: Sun, 6 Jul 2008 12:15:23 -0700 (PDT) From: Fred Wright X-Sender: fw@Amiga.local Reply-To: Fred Wright To: Tops-20 Wizards Subject: Re: ULKSTZ BUGCHK on IOX10 SINR% error In-Reply-To: <486FCF32.6070000@optonline.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII ReSent-Date: Sun, 6 Jul 2008 12:31:44 -0700 (PDT) ReSent-From: TOPS-20 List Moderator ReSent-To: TOPS-20 Distribution: ; ReSent-Subject: Re: ULKSTZ BUGCHK on IOX10 SINR% error ReSent-Message-ID: ReSent-User-Agent: Alpine 1.10 (OSX 1074 2008-06-04) On Sat, 5 Jul 2008, Thomas DeBellis wrote: > I'm using SINR% because I can pick up some speed if I know that a PSH > happened. Even if it doesn't work right (or at all), the code will No modern TCP implementation makes any use of PSH whatsoever. It's unconditionally set on transmit, and ignored on receive. Fred Wright 6-Jul-2008 16:09:02-PDT,2307;000000000000 Return-Path: Received: from pangtzu.panda.com ([206.124.149.117]) by Lingling.Panda.COM with TCP/SMTP; Sun, 6 Jul 2008 16:04:12 -0700 (PDT) X-Return-Path: X-Received: from mta2.srv.hcvlny.cv.net ([167.206.4.197]) by Lingling.Panda.COM with TCP/SMTP; Sun, 6 Jul 2008 13:15:12 -0700 (PDT) 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 <0K3L00973PL5QW40@mta2.srv.hcvlny.cv.net> for TOPS-20@lingling.panda.com; Sun, 06 Jul 2008 16:15:05 -0400 (EDT) Date: Sun, 06 Jul 2008 16:15:04 -0400 From: Thomas DeBellis Subject: Re: ULKSTZ BUGCHK on IOX10 SINR% error In-reply-to: To: Fred Wright Cc: Tops-20 Wizards Message-id: <487127C8.4000609@optonline.net> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en References: User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) ReSent-Date: Sun, 6 Jul 2008 16:04:03 -0700 (PDT) ReSent-From: TOPS-20 List Moderator ReSent-To: TOPS-20 Distribution: ; ReSent-Subject: Re: ULKSTZ BUGCHK on IOX10 SINR% error ReSent-Message-ID: ReSent-User-Agent: Alpine 1.10 (OSX 1074 2008-06-04) > > I'm using SINR% because I can pick up some speed if I know that a > > PSH > No modern TCP implementation makes any use of PSH whatsoever. It's > unconditionally set on transmit, and ignored on receive. One hesitates to characterise how 'modern' the Tops-20 TCP/IP implementation is. However, PSH is set (via a final SOUTR%) by the Tops-20 FTP client and Tops-20 appears to respect this (or at least I thought it did the last time I perused that particular code) But again, the code in question is a heuristic--I really, REALLY have gotten the message to NOT depend on PSH. Honest! At worst case, I won't be any slower than I would be otherwise. 6-Jul-2008 16:12:10-PDT,2810;000000000000 Return-Path: Received: from pangtzu.panda.com ([206.124.149.117]) by Lingling.Panda.COM with TCP/SMTP; Sun, 6 Jul 2008 16:04:39 -0700 (PDT) X-Return-Path: X-Received: from cyteen.hactrn.net ([66.92.66.68]) by Lingling.Panda.COM with TCP/SMTP; Sun, 6 Jul 2008 15:58:42 -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 ESMTPS id 9457D28426 for ; Sun, 6 Jul 2008 22:58:35 +0000 (UTC) X-Received: from thrintun.hactrn.net (localhost [IPv6:::1]) by thrintun.hactrn.net (Postfix) with ESMTP id 5610B22808 for ; Sun, 6 Jul 2008 18:58:35 -0400 (EDT) Date: Sun, 06 Jul 2008 18:58:35 -0400 From: Rob Austein To: Tops-20 Wizards Subject: Re: ULKSTZ BUGCHK on IOX10 SINR% error In-Reply-To: References: <486FCF32.6070000@optonline.net> 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: <20080706225835.5610B22808@thrintun.hactrn.net> ReSent-Date: Sun, 6 Jul 2008 16:04:24 -0700 (PDT) ReSent-From: TOPS-20 List Moderator ReSent-To: TOPS-20 Distribution: ; ReSent-Subject: Re: ULKSTZ BUGCHK on IOX10 SINR% error ReSent-Message-ID: ReSent-User-Agent: Alpine 1.10 (OSX 1074 2008-06-04) At Sun, 6 Jul 2008 12:15:23 -0700 (PDT), Fred Wright wrote: > > No modern TCP implementation makes any use of PSH whatsoever. It's > unconditionally set on transmit, and ignored on receive. Not quite true. There's at least one implementation (I used to maintain it, you'll have to form your own opinion about whether it's "modern", but last I heard it was the stack in PalmOS, among other more deeply embedded devices) which does something a little more complicated: if there's more outbound data buffered than will fit in a single segment (eg, because the send window was closed, or a bulk transfer application is queuing data faster than the TCP engine can send it), the TCP engine only sets PSH automatically on the segment that clears the outbound queue. Whether any user of this stack has ever even noticed this behavior, much less cared, is another matter. Certainly applications should not care, PSH is just an efficiency hack at the transport layer. 6-Jul-2008 16:16:52-PDT,2501;000000000000 Return-Path: Received: from pangtzu.panda.com ([206.124.149.117]) by Lingling.Panda.COM with TCP/SMTP; Sun, 6 Jul 2008 16:12:47 -0700 (PDT) X-Return-Path: X-Received: from pangtzu.panda.com ([206.124.149.117]) by Lingling.Panda.COM with TCP/SMTP; Sun, 6 Jul 2008 16:11:25 -0700 (PDT) Date: Sun, 6 Jul 2008 16:11:20 -0700 (PDT) From: Mark Crispin Sender: mrc@pangtzu.panda.com To: Fred Wright cc: Tops-20 Wizards Subject: Re: ULKSTZ BUGCHK on IOX10 SINR% error In-Reply-To: Message-ID: References: User-Agent: Alpine 1.10 (OSX 1074 2008-06-04) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed ReSent-Date: Sun, 6 Jul 2008 16:12:37 -0700 (PDT) ReSent-From: TOPS-20 List Moderator ReSent-To: TOPS-20 Distribution: ; ReSent-Subject: Re: ULKSTZ BUGCHK on IOX10 SINR% error ReSent-Message-ID: ReSent-User-Agent: Alpine 1.10 (OSX 1074 2008-06-04) On Sun, 6 Jul 2008, Fred Wright wrote: > No modern TCP implementation makes any use of PSH whatsoever. It's > unconditionally set on transmit, and ignored on receive. Other than this strange hack for SINR% (which I don't really understand), TOPS-20 ignores PSH on receive. Certainly none of my TOPS-20 application programs ever cared. On transmit, TOPS-20 tries to fill segments before sending them unless the application specifies setting PSH. Thus, TOPS-20 would tend to send full segments without PSH, and partially-filled segments with PSH. The main impact is that application programmers could be lazy and not bother buffering small outputs since the kernel would do it. In my applications, I would set PSH with the final CRLF before going into input, and otherwise not. I don't have any real comment about whether TOPS-20 or the sockets way of doing things is better. Certainly the sockets way avoids the deadlock bugs in which an application goes into input wait, but the last bit of sent data isn't seen by by the other side due to lack of PSH. But the TOPS-20 way tends to use fewer segments. -- Mark -- http://panda.com/tops-20 TOPS-20: a great improvement over its successors 6-Jul-2008 19:21:30-PDT,2802;000000000000 Return-Path: Received: from pangtzu.panda.com ([206.124.149.117]) by Lingling.Panda.COM with TCP/SMTP; Sun, 6 Jul 2008 19:16:21 -0700 (PDT) X-Return-Path: X-Received: from b.mail.sonic.net ([64.142.19.5]) by Lingling.Panda.COM with TCP/SMTP; Sun, 6 Jul 2008 19:12:00 -0700 (PDT) X-Received: from Amiga.local (64-142-29-114.dsl.static.sonic.net [64.142.29.114]) by b.mail.sonic.net (8.13.8.Beta0-Sonic/8.13.7) with ESMTP id m672BkYe003312 for ; Sun, 6 Jul 2008 19:11:46 -0700 Date: Sun, 6 Jul 2008 19:11:46 -0700 (PDT) From: Fred Wright X-Sender: fw@Amiga.local Reply-To: Fred Wright To: Tops-20 Wizards Subject: Re: ULKSTZ BUGCHK on IOX10 SINR% error In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII ReSent-Date: Sun, 6 Jul 2008 19:16:13 -0700 (PDT) ReSent-From: TOPS-20 List Moderator ReSent-To: TOPS-20 Distribution: ; ReSent-Subject: Re: ULKSTZ BUGCHK on IOX10 SINR% error ReSent-Message-ID: ReSent-User-Agent: Alpine 1.10 (OSX 1074 2008-06-04) On Sun, 6 Jul 2008, Mark Crispin wrote: > On Sun, 6 Jul 2008, Fred Wright wrote: > > No modern TCP implementation makes any use of PSH whatsoever. It's > > unconditionally set on transmit, and ignored on receive. [...] > > I don't have any real comment about whether TOPS-20 or the sockets way of > doing things is better. Certainly the sockets way avoids the deadlock > bugs in which an application goes into input wait, but the last bit of > sent data isn't seen by by the other side due to lack of PSH. But the > TOPS-20 way tends to use fewer segments. Modern implementations also implement the Nagle algorithm (at least by default), which means that they'll send mostly full segments unless the send rate is less than network speed, in which case sending short segments is probably desirable, anyway. Sitting on data during idle times increases latency. And any application that wants to send data to the OS in little bits and pieces (at one OS call per each) and then wants PSH for "efficiency" is seriously confused. I recall doing something Nagle-related in TOPS-10/20, but I forget whether it was implementing it or modifying it. :-) The problem with PSH is that it was too poorly specified and inconsistently implemented to actually be useful, hence its de facto deprecation. Although RFC1122 clarified the meaning, by that time BSD (the de facto reference implementation) had abandoned it. Fred Wright 6-Jul-2008 21:02:19-PDT,2808;000000000000 Return-Path: Received: from pangtzu.panda.com ([206.124.149.117]) by Lingling.Panda.COM with TCP/SMTP; Sun, 6 Jul 2008 20:56:52 -0700 (PDT) X-Return-Path: X-Received: from pangtzu.panda.com ([206.124.149.117]) by Lingling.Panda.COM with TCP/SMTP; Sun, 6 Jul 2008 20:45:17 -0700 (PDT) Date: Sun, 6 Jul 2008 20:45:11 -0700 (PDT) From: Mark Crispin Sender: mrc@pangtzu.panda.com To: Fred Wright cc: Tops-20 Wizards Subject: Re: ULKSTZ BUGCHK on IOX10 SINR% error In-Reply-To: Message-ID: References: User-Agent: Alpine 1.10 (OSX 1074 2008-06-04) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed ReSent-Date: Sun, 6 Jul 2008 20:56:45 -0700 (PDT) ReSent-From: TOPS-20 List Moderator ReSent-To: TOPS-20 Distribution: ; ReSent-Subject: Re: ULKSTZ BUGCHK on IOX10 SINR% error ReSent-Message-ID: ReSent-User-Agent: Alpine 1.10 (OSX 1074 2008-06-04) On Sun, 6 Jul 2008, Fred Wright wrote: > Modern implementations also implement the Nagle algorithm (at least by > default), which means that they'll send mostly full segments unless the > send rate is less than network speed, in which case sending short segments > is probably desirable, anyway. Nagle is mostly important for sockets, since applications don't have control over push with sockets. IIRC, for TOPS-20 the main use for Nagle is for TVTs. > And any application that wants to send data to the OS > in little bits and pieces (at one OS call per each) and then wants PSH for > "efficiency" is seriously confused. That's like saying that any TOPS-10 program that uses TTCALL instead of the TTY: device is seriously confused. For better or worse, TOPS-20 programmers like using some of the convenient system calls (such as NOUT%) instead of buffering. With the exception of large volumes of data, it doesn't really matter. > The problem with PSH is that it was too poorly specified and > inconsistently implemented to actually be useful, hence its de facto > deprecation. Although RFC1122 clarified the meaning, by that time BSD > (the de facto reference implementation) had abandoned it. Agreed, but every PDP-10 OS programmer understood that PSH was the equivalent of the NCP force operator. TOPS-10, WAITS, ITS, Tenex, and TOPS-20 all had the concept. The problem was telling those UNIX guys... -- Mark -- http://panda.com/tops-20 TOPS-20: a great improvement over its successors 25-Jul-2008 10:11:30-PDT,1690;000000000000 Return-Path: Received: from pangtzu.panda.com ([206.124.149.117]) by Lingling.Panda.COM with TCP/SMTP; Fri, 25 Jul 2008 10:04:57 -0700 (PDT) X-Return-Path: X-Received: from mail1.acecape.com ([66.114.74.12]) by Lingling.Panda.COM with TCP/SMTP; Fri, 25 Jul 2008 09:37:52 -0700 (PDT) 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 m6PGbjGC021957 for ; Fri, 25 Jul 2008 12:37:46 -0400 Message-ID: <488A0158.10203@acedsl.com> Date: Fri, 25 Jul 2008 12:37:44 -0400 From: Thomas DeBellis User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tops-20 Wizards Subject: Double Float and Round Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit ReSent-Date: Fri, 25 Jul 2008 10:04:46 -0700 (PDT) ReSent-From: TOPS-20 List Moderator ReSent-To: TOPS-20 Distribution: ; ReSent-Subject: Double Float and Round ReSent-Message-ID: ReSent-User-Agent: Alpine 1.10 (OSX 1074 2008-06-04) After 20 years ... I have a double word integer that I want to convert to (KL) double floating format. There are instructions to float a single word integer to single word floating format and others to do the same sort of conversions to the G (VAX) format. I don't see how to do it for the regular KL format and can't remember. Anybody care to jog my pathetic memory? 26-Jul-2008 10:38:47-PDT,3077;000000000000 Return-Path: Received: from pangtzu.panda.com ([206.124.149.117]) by Lingling.Panda.COM with TCP/SMTP; Sat, 26 Jul 2008 10:32:48 -0700 (PDT) X-Return-Path: X-Received: from an-out-0708.google.com ([209.85.132.246]) by Lingling.Panda.COM with TCP/SMTP; Sat, 26 Jul 2008 08:47:59 -0700 (PDT) X-Received: by an-out-0708.google.com with SMTP id c17so801559anc.55 for ; Sat, 26 Jul 2008 08:47:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=BGMxs/a0xChLClrGHyiPiyl+/XAWKWaabVIRS8tl4ps=; b=RH0Dvkzc8zxzp7IV3T/t4lPbHQCuuIaLcy5kG/r51J5qRF54qwMsc64DO+Wx/6N0JN TdTgkbIbQOocYt11Z5B4BToYWbNjPcE3QGeR8K2eWQttKeH7qlRKRPhzn1gv/taDMUK0 Xiy/GXGahrti242tXyEvO0HsB9WQHBKI2L3wA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=rd9FWb6F94DRXZyJ4mZtzQjKI+kM8WVD68YAgYNNUGiG4kdEp2sT4bATEhDm71KIl3 N//R9ZqkooXlXpHleqXI7D/MchtCRpXceCgMDVkrfhxH3R+O1eUGrEkmPhmG6fpySweQ EOVfqg2DJO9Ncc+sg+c7KVZTl3IPuItOf8qgA= X-Received: by 10.100.112.9 with SMTP id k9mr5100624anc.111.1217087273294; Sat, 26 Jul 2008 08:47:53 -0700 (PDT) X-Received: by 10.151.13.20 with HTTP; Sat, 26 Jul 2008 08:47:53 -0700 (PDT) Message-ID: <1a6457e90807260847y212f7a2enaf02b38cbf8fcadc@mail.gmail.com> Date: Sat, 26 Jul 2008 09:47:53 -0600 From: "Chris Smith" To: TOPS-20@lingling.panda.com Subject: Re: Double Float and Round In-Reply-To: <488A0158.10203@acedsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <488A0158.10203@acedsl.com> ReSent-Date: Sat, 26 Jul 2008 10:32:40 -0700 (PDT) ReSent-From: TOPS-20 List Moderator ReSent-To: TOPS-20 Distribution: ; ReSent-Subject: Re: Double Float and Round ReSent-Message-ID: ReSent-User-Agent: Alpine 1.10 (OSX 1074 2008-06-04) gcc lacks floatdidf except for gfloat and for XKL2 which has DDFLTR. Here's an attempt. I think it works for negative numbers. ; Double Integer in (e,e+1) ; to D Float in (t1,t2) fltr t1,e ; high word and sign, f float fsc t1,35. ; binary point is 35 bits to the right setz t2, ; d float move t3,e+1 ; low word tlz t3,0400000 ; sign bit off, would add -2^35 fltr t3,t3 ; low word, f float setz t4, ; d float dfad t1,t3 ; add sign, high, low 26-Jul-2008 10:43:01-PDT,2604;000000000000 Return-Path: Received: from pangtzu.panda.com ([206.124.149.117]) by Lingling.Panda.COM with TCP/SMTP; Sat, 26 Jul 2008 10:33:07 -0700 (PDT) X-Return-Path: X-Received: from an-out-0708.google.com ([209.85.132.242]) by Lingling.Panda.COM with TCP/SMTP; Sat, 26 Jul 2008 08:50:06 -0700 (PDT) X-Received: by an-out-0708.google.com with SMTP id c17so801690anc.55 for ; Sat, 26 Jul 2008 08:50:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=amSvQc2ujDy1ivbA3Fw10tyqRtVicy92No2y4T/ebno=; b=cEOO1HNfwyG9KnvXPo080FCi34GnmItGVMr+GYwC7oQCiQ5fp5dPbG/UtQ/QJFULDI qzRWnqFgc7wSJAbbxzkqNNzh+H0oWzSthRzKEcl1YN9QBLz0ubIJWVvviMpbCSLBNJNN PjoiJAYYMCwk0nYJnn61lj18eB/cEsgU7usBc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=wkeZDbcEDQjd3r/0YZ6/NaGCsEQ3iNOZFykfTExQPkZuYsirUQ87erfdoj1FJwQrIq BtTzPnXOumjCL76jNm/S1UXq/IbG63wRAbFuRKkWBkKJHO2sHBN03wf2tp4FLWu6ddcs L7FjfFad/dcBkS2LEydMZlztDZKRiMPyxhggs= X-Received: by 10.100.7.1 with SMTP id 1mr5109942ang.99.1217087400754; Sat, 26 Jul 2008 08:50:00 -0700 (PDT) X-Received: by 10.151.13.20 with HTTP; Sat, 26 Jul 2008 08:50:00 -0700 (PDT) Message-ID: <1a6457e90807260850u58d9c71k3c9e889a38b47b9a@mail.gmail.com> Date: Sat, 26 Jul 2008 09:50:00 -0600 From: "Chris Smith" To: TOPS-20@lingling.panda.com Subject: Re: Double Float and Round In-Reply-To: <1a6457e90807260847y212f7a2enaf02b38cbf8fcadc@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <488A0158.10203@acedsl.com> <1a6457e90807260847y212f7a2enaf02b38cbf8fcadc@mail.gmail.com> ReSent-Date: Sat, 26 Jul 2008 10:32:59 -0700 (PDT) ReSent-From: TOPS-20 List Moderator ReSent-To: TOPS-20 Distribution: ; ReSent-Subject: Re: Double Float and Round ReSent-Message-ID: ReSent-User-Agent: Alpine 1.10 (OSX 1074 2008-06-04) Oops. Never mind. I guess it needs to be split into 3 pieces. 26-Jul-2008 16:26:34-PDT,3249;000000000000 Return-Path: Received: from pangtzu.panda.com ([206.124.149.117]) by Lingling.Panda.COM with TCP/SMTP; Sat, 26 Jul 2008 16:21:07 -0700 (PDT) X-Return-Path: X-Received: from rv-out-0708.google.com ([209.85.198.243]) by Lingling.Panda.COM with TCP/SMTP; Sat, 26 Jul 2008 14:01:12 -0700 (PDT) X-Received: by rv-out-0708.google.com with SMTP id c5so6434730rvf.52 for ; Sat, 26 Jul 2008 14:00:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=QO2SiMngELG7wZti6lJFTsgsI8Akj/pbQres1DwuK/s=; b=YpDc0p6H2W3Zdt6Om1XwAzTX0OhsECeX3VygRu3DN1bETXBzCpyiGg8mChxfMB1sCK lZipCkvb9gZEzBguGOHQyCrFnZaK3nmFspHrqVjowepD4rQR5eBs2//ziq8YwP8D4i6D UCZYpVUlbq/rv+0/n9hRx/kHq4X2dNJLap1aE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=atY8Eg/KvyXQ5kibr2xMSoIVltxzLLIn5S295MO5jSaXJHPftLcq7wSLLZc/YEcYqb /SUoOn1oVEbIoKZt6GcbSrwA48hAjNON4wod/wj+OZauR599bxAwnYOBvKzvrdcI/Ywh BR5hDWnc8GOGlnkPLDwvgl1GFv82jLwje2OD4= X-Received: by 10.141.145.11 with SMTP id x11mr1565633rvn.215.1217106058486; Sat, 26 Jul 2008 14:00:58 -0700 (PDT) X-Received: by 10.141.211.19 with HTTP; Sat, 26 Jul 2008 14:00:58 -0700 (PDT) Message-ID: <1a6457e90807261400s5dfda7ccm8954ff63455a8cc0@mail.gmail.com> Date: Sat, 26 Jul 2008 15:00:58 -0600 From: "Chris Smith" To: TOPS-20@lingling.panda.com Subject: Re: Double Float and Round In-Reply-To: <1a6457e90807260850u58d9c71k3c9e889a38b47b9a@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <488A0158.10203@acedsl.com> <1a6457e90807260847y212f7a2enaf02b38cbf8fcadc@mail.gmail.com> <1a6457e90807260850u58d9c71k3c9e889a38b47b9a@mail.gmail.com> ReSent-Date: Sat, 26 Jul 2008 16:20:55 -0700 (PDT) ReSent-From: TOPS-20 List Moderator ReSent-To: TOPS-20 Distribution: ; ReSent-Subject: Re: Double Float and Round ReSent-Message-ID: ReSent-User-Agent: Alpine 1.10 (OSX 1074 2008-06-04) This hakmem-like thing works in 777000000000000 .. 000777777777777 tsc t1,0276000 dfad t1,[000000000000000000000000] otherwise the general case, something more like hlre t1,e ; sign and hi 17 fltr t1,t1 ; f float fsc t1,18.+35. ; binary point is 18 then 35 bits to right setz t2, ; d float dmove t3,e ; next 27 ashc t3,9 ; and t3,[000777777777] ; fltr t3,t3 ; f float fsc t3,26. ; binary point is 26 bits to right setz t4, ; d float dfad t2,t4 ; 18 + 27 bits move t3,e+1 ; last 26 and t3,[000377777777] fltr t3,t3 ; f float setz t4, ; d float dfad t2,t4 ; 18 + 27 + 26 bits 27-Jul-2008 14:46:07-PDT,8296;000000000000 Return-Path: Received: from pangtzu.panda.com ([206.124.149.117]) by Lingling.Panda.COM with TCP/SMTP; Sun, 27 Jul 2008 14:40:35 -0700 (PDT) X-Return-Path: X-Received: from rv-out-0708.google.com ([209.85.198.246]) by Lingling.Panda.COM with TCP/SMTP; Sun, 27 Jul 2008 12:58:21 -0700 (PDT) X-Received: by rv-out-0708.google.com with SMTP id c5so6835459rvf.52 for ; Sun, 27 Jul 2008 12:58:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:in-reply-to:mime-version:content-type:references; bh=Z/4pwoqO2D+80PBVGEq5im1zbtiX3ig8bIEzDyWIrRE=; b=uh7em/Nf39gllOuj49SWRgJJgiuCcqVHtyPmsqEGYBLEnEaurKhgyj0nxxonoFpu9I PK6VMbizVeXJoFbZ9ZCiZ6RC8OA8ZEPK1BUw5qlZipFKmay3Hynkcgg8Wd+rgiO795Vv tBx6svaqTEa7lqgG4B6IY5rUgR4bsioPER9xU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:in-reply-to:mime-version :content-type:references; b=QNf7vs95/nUIr/pZ92EecbZd0vWocoUJkAxD8wtYCvDCmw44uqccYtFzq21m/qTDy6 wlDIeVfbMNtATUDImxVB5KC2F8pjEdo+wLkw2Chdl1NKpcIKDIXO3dB8KNXaKWPH8kSn YFn1PPVskWh/+wxUNfW7ARL69WYSyDVCYnnx0= X-Received: by 10.140.144.6 with SMTP id r6mr1960533rvd.293.1217188695165; Sun, 27 Jul 2008 12:58:15 -0700 (PDT) X-Received: by 10.141.211.19 with HTTP; Sun, 27 Jul 2008 12:58:15 -0700 (PDT) Message-ID: <1a6457e90807271258r112f1ebeu79c29a2af8c2d2d3@mail.gmail.com> Date: Sun, 27 Jul 2008 13:58:15 -0600 From: "Chris Smith" To: tops-20@lingling.panda.com Subject: Re: Double Float and Round In-Reply-To: <488C7230.5090400@RCN.Com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_7321_26380531.1217188695159" References: <488A0158.10203@acedsl.com> <1a6457e90807260847y212f7a2enaf02b38cbf8fcadc@mail.gmail.com> <1a6457e90807260850u58d9c71k3c9e889a38b47b9a@mail.gmail.com> <1a6457e90807261400s5dfda7ccm8954ff63455a8cc0@mail.gmail.com> <488BE109.9000606@RCN.Com> <1a6457e90807270557ye02c3c6l344e102198668ace@mail.gmail.com> <488C7230.5090400@RCN.Com> ReSent-Date: Sun, 27 Jul 2008 14:40:25 -0700 (PDT) ReSent-From: TOPS-20 List Moderator ReSent-To: TOPS-20 Distribution: ; ReSent-Subject: Re: Double Float and Round ReSent-Message-ID: ReSent-User-Agent: Alpine 1.10 (OSX 1074 2008-06-04) ------=_Part_7321_26380531.1217188695159 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Ok, final answer. ------=_Part_7321_26380531.1217188695159 Content-Type: application/octet-stream; name=ditest.mac Content-Transfer-Encoding: base64 X-Attachment-Id: f_fj62o0om0 Content-Disposition: attachment; filename=ditest.mac ICAgICAgICB0aXRsZSBkaXRlc3QKCiAgICAgICAgc2VhcmNoIG1vbnN5bQogICAgICAgIAogICAg ICAgIHQxPTEKICAgICAgICB0Mj0yCiAgICAgICAgdDM9MwogICAgICAgIHQ0PTQKICAgICAgICB0 NT01CiAgICAgICAgcD0xNwoKOzs7IHRlc3QgRElERiwgYmVsb3cKCnN0YXJ0OiAgbW92ZSBwLFst bnN0YWNrLCxzdGFja10KICAgICAgICB4bW92ZWkgdDEsREl0YWIKICAgICAgICBtb3ZlbSB0MSxw dHIKICAgICAgICBtb3ZlaSB0MSxuREl0YWIKICAgICAgICBtb3ZlbSB0MSxjbnQKbHAxOiAgICBk bW92ZSB0MSxAcHRyCiAgICAgICAgcHVzaGogcCxvY3RvdXQKICAgICAgICBocnJvaSB0MSxbYXNj aXogLyAgICAvXQogICAgICAgIHBzb3V0CiAgICAgICAgZG1vdmUgdDEsQHB0cgogICAgICAgIHB1 c2hqIHAsRElERgogICAgICAgIHB1c2hqIHAsb2N0b3V0CiAgICAgICAgaHJyb2kgdDEsW2FzY2l6 IC8gICAgL10KICAgICAgICBwc291dAogICAgICAgIGRtb3ZlIHQxLEBwdHIKICAgICAgICBocnIg dDEsdDIKICAgICAgICBmbHRyIHQxLHQxCiAgICAgICAgcHVzaGogcCxzbmdvdXQKICAgICAgICBo cnJvaSB0MSxbYXNjaXogLwovXQogICAgICAgIHBzb3V0CiAgICAgICAgYW9zIHB0cgogICAgICAg IGFvcyBwdHIKICAgICAgICBzb3NlIGNudAogICAgICAgICBqcnN0IGxwMQogICAgICAgIGhhbHRm CgpwdHI6ICAgIGJsb2NrIDEKY250OiAgICBibG9jayAxCgpESXRhYjogIG9jdCAwMDAwMDAwMDAw MDAsMDAwMDAwMDAwMDAwCiAgICAgICAgb2N0IDAwMDAwMDAwMDAwMCwwMDAwMDAwMDAwMDUKICAg ICAgICBvY3QgMDAwNzc3Nzc3Nzc3LDc3Nzc3Nzc3Nzc3NwogICAgICAgIG9jdCA3Nzc3Nzc3Nzc3 NzcsNzc3Nzc3Nzc3Nzc3CiAgICAgICAgb2N0IDc3NzAwMDAwMDAwMCwwMDAwMDAwMDAwMDEKICAg ICAgICBvY3QgNzc3MDAwMDAwMDAwLDAwMDAwMDAwMDAwMAoKICAgICAgICBvY3QgMDAxNzc3Nzc3 Nzc3LDc3Nzc3Nzc3Nzc3NgogICAgICAgIG9jdCAwMDM3Nzc3Nzc3NzcsNzc3Nzc3Nzc3Nzc0CiAg ICAgICAgb2N0IDAwNzc3Nzc3Nzc3Nyw3Nzc3Nzc3Nzc3NzAKICAgICAgICBvY3QgMDE3Nzc3Nzc3 Nzc3LDc3Nzc3Nzc3Nzc2MAogICAgICAgIG9jdCAwMzc3Nzc3Nzc3NzcsNzc3Nzc3Nzc3NzQwCiAg ICAgICAgb2N0IDA3Nzc3Nzc3Nzc3Nyw3Nzc3Nzc3Nzc3MDAKICAgICAgICBvY3QgMTc3Nzc3Nzc3 Nzc3LDc3Nzc3Nzc3NzYwMAogICAgICAgIG9jdCAzNzc3Nzc3Nzc3NzcsNzc3Nzc3Nzc3NDAwCgog ICAgICAgIG9jdCAwMDE3Nzc3Nzc3NzcsNzc3Nzc3Nzc3Nzc3CiAgICAgICAgb2N0IDAwMzc3Nzc3 Nzc3Nyw3Nzc3Nzc3Nzc3NzYKICAgICAgICBvY3QgMDA3Nzc3Nzc3Nzc3LDc3Nzc3Nzc3Nzc3NAog ICAgICAgIG9jdCAwMTc3Nzc3Nzc3NzcsNzc3Nzc3Nzc3NzcwCiAgICAgICAgb2N0IDAzNzc3Nzc3 Nzc3Nyw3Nzc3Nzc3Nzc3NjAKICAgICAgICBvY3QgMDc3Nzc3Nzc3Nzc3LDc3Nzc3Nzc3Nzc0MAog ICAgICAgIG9jdCAxNzc3Nzc3Nzc3NzcsNzc3Nzc3Nzc3NzAwCiAgICAgICAgb2N0IDM3Nzc3Nzc3 Nzc3Nyw3Nzc3Nzc3Nzc2MDAKCiAgICAgICAgb2N0IDAwMDAwMDAwMDAwMCwzNzc3Nzc3Nzc3NzcK ICAgICAgICBvY3QgMzc3Nzc3Nzc3Nzc3LDAwMDAwMDAwMDAwMAoKICAgICAgICBvY3QgNDAwMDAw MDAwMDAwLDAwMDAwMDAwMDAwMAogICAgICAgIG9jdCA0MDAwMDAwMDAwMDAsMDAwMDAwMDAwMDAx CiAgICAgICAgb2N0IDQwMDAwMDAwMDAwMCwwMDAwMDAwMDAyMDAKICAgICAgICBvY3QgNDAwMDAw MDAwMDAwLDAwMDAwMDAwMDQwMAogICAgICAgIG9jdCA0MDAwMDAwMDAwMDAsMDAwMDAwMDAxMDAw CgogICAgICAgIG9jdCA3NzYwMDAwMDAwMDAsMDAwMDAwMDAwMDAwCiAgICAgICAgb2N0IDc3NjAw MDAwMDAwMCwwMDAwMDAwMDAwMDEKICAgICAgICBvY3QgNzc2MDAwMDAwMDAwLDAwMDAwMDAwMDAw MgoKICAgICAgICBvY3QgNDAwNzc3Nzc3Nzc3LDc3Nzc3Nzc3Nzc3NgogICAgICAgIG9jdCA0MDE3 Nzc3Nzc3NzcsNzc3Nzc3Nzc3Nzc0CiAgICAgICAgb2N0IDQwMzc3Nzc3Nzc3Nyw3Nzc3Nzc3Nzc3 NzAKICAgICAgICBvY3QgNDA3Nzc3Nzc3Nzc3LDc3Nzc3Nzc3Nzc2MAogICAgICAgIG9jdCA0MTc3 Nzc3Nzc3NzcsNzc3Nzc3Nzc3NzQwCiAgICAgICAgb2N0IDQzNzc3Nzc3Nzc3Nyw3Nzc3Nzc3Nzc3 MDAKICAgICAgICBvY3QgNDc3Nzc3Nzc3Nzc3LDc3Nzc3Nzc3NzYwMAogICAgICAgIG9jdCA1Nzc3 Nzc3Nzc3NzcsNzc3Nzc3Nzc3NDAwCiAgICAgICAgb2N0IDc3Nzc3Nzc3Nzc3Nyw3Nzc3Nzc3Nzcw MDAKCiAgICAgICAgb2N0IDQwMDc3Nzc3Nzc3Nyw3Nzc3Nzc3Nzc3NzcKICAgICAgICBvY3QgNDAx Nzc3Nzc3Nzc3LDc3Nzc3Nzc3Nzc3NgogICAgICAgIG9jdCA0MDM3Nzc3Nzc3NzcsNzc3Nzc3Nzc3 Nzc0CiAgICAgICAgb2N0IDQwNzc3Nzc3Nzc3Nyw3Nzc3Nzc3Nzc3NzAKICAgICAgICBvY3QgNDE3 Nzc3Nzc3Nzc3LDc3Nzc3Nzc3Nzc2MAogICAgICAgIG9jdCA0Mzc3Nzc3Nzc3NzcsNzc3Nzc3Nzc3 NzQwCiAgICAgICAgb2N0IDQ3Nzc3Nzc3Nzc3Nyw3Nzc3Nzc3Nzc3MDAKICAgICAgICBvY3QgNTc3 Nzc3Nzc3Nzc3LDc3Nzc3Nzc3NzYwMAogICAgICAgIG9jdCA3Nzc3Nzc3Nzc3NzcsNzc3Nzc3Nzc3 NDAwCgpuREl0YWI9PC4tREl0YWI+LzIKICAgICAgICAKbnN0YWNrPT0xMDAKc3RhY2s6ICBibG9j ayBuc3RhY2sKCgo7OzsgYXJnczogdDEtdDIvIERJIGludGVnZXIsIGhpZ2ggOSBiaXRzIGFsbCBz aWducwo7OzsgcmV0OiAgdDEtdDIvIHJvdW5kZWQgdG8gREYKCkRJREZ4OiAgdGxjIHQxLDAyNzYw MDAKICAgICAgICBkZmFkIHQxLFtleHAgMCwwXQogICAgICAgIHBvcGogcCwKICAgICAgICAKCjs7 OyBhcmdzOiB0MS10Mi8gREkgaW50ZWdlciwgdW5yZXN0cmljdGVkCjs7OyByZXQ6ICB0MS10Mi8g cm91bmRlZCB0byBERgoKRElERjogICBtb3ZlIHQzLHQyCiAgICAgICAgc2V0emIgdDIsdDQKICAg ICAgICBhc2hjIHQxLC0wMTAKICAgICAgICB0bGMgdDEsMDMwNjAwMAogICAgICAgIHRseiB0Myww NDAwMDAwCiAgICAgICAgYXNoYyB0MywtMDEwCiAgICAgICAgdGxjIHQzLDAyNDMwMDAKICAgICAg ICBkZmFkIHQxLHQzCiAgICAgICAgcG9waiBwLAoKCjs7OyBhcmdzOiB0MS10Mi8gREkgaW50ZWdl cgo7OzsgcHJpbnRlZCBpbiBvY3RhbCBvbiBzdGRvdXQKCm9jdG91dDogZG1vdmVtIHQxLG9jdHZh bAogICAgICAgIGRtb3ZlIHQyLG9jdHZhbAogICAgICAgIG1vdmVpIHQ0LDMwCiAgICAgICAgbW92 ZWkgdDUsNwpvY3QxOiAgIG1vdmVpIHQxLCIgIgogICAgICAgIHNvam4gdDUsb2N0MgogICAgICAg ICBwYm91dAogICAgICAgICBtb3ZlaSB0NSw2Cm9jdDI6ICAgbW92ZSB0MSx0MgogICAgICAgIGxz aCB0MSwtNDEKICAgICAgICBhZGRpIHQxLCIwIgogICAgICAgIHBib3V0CiAgICAgICAgbHNoYyB0 MiwzCiAgICAgICAgc29qZyB0NCxvY3QxCiAgICAgICAgcG9waiBwLCAKCm9jdHZhbDogYmxvY2sg MgoKCjs7OyBhcmdzOiB0MS8gU0kgaW50ZWdlcgo7OzsgcHJpbnRlZCBpbiBvY3RhbCBvbiBzdGRv dXQKCnNuZ291dDogbW92ZSB0Mix0MQogICAgICAgIG1vdmVpIHQ0LDE0CiAgICAgICAgbW92ZWkg dDUsNwpzb2N0MTogIG1vdmVpIHQxLCIgIgogICAgICAgIHNvam4gdDUsc29jdDIKICAgICAgICAg cGJvdXQKICAgICAgICAgbW92ZWkgdDUsNgpzb2N0MjogIG1vdmUgdDEsdDIKICAgICAgICBsc2gg dDEsLTQxCiAgICAgICAgYWRkaSB0MSwiMCIKICAgICAgICBwYm91dAogICAgICAgIGxzaCB0Miwz CiAgICAgICAgc29qZyB0NCxzb2N0MQogICAgICAgIHBvcGogcCwgCgogICAgICAgIGVuZCBzdGFy dAoKCgo= ------=_Part_7321_26380531.1217188695159-- 1-Aug-2008 21:13:01-PDT,1724;000000000000 Return-Path: Received: from pangtzu.panda.com ([206.124.149.117]) by Lingling.Panda.COM with TCP/SMTP; Fri, 1 Aug 2008 21:05:06 -0700 (PDT) X-Return-Path: X-Received: from pangtzu.panda.com ([206.124.149.117]) by Lingling.Panda.COM with TCP/SMTP; Fri, 1 Aug 2008 21:04:49 -0700 (PDT) Date: Fri, 1 Aug 2008 21:04:43 -0700 (PDT) From: Mark Crispin Sender: mrc@pangtzu.panda.com To: TOPS-20 Hackers and Yackers Subject: fun with TOPS-20 SMTP servers Message-ID: User-Agent: Alpine 1.10 (OSX 1074 2008-06-04) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII ReSent-Date: Fri, 1 Aug 2008 21:04:56 -0700 (PDT) ReSent-From: TOPS-20 List Moderator ReSent-To: TOPS-20 Distribution: ; ReSent-Subject: fun with TOPS-20 SMTP servers ReSent-Message-ID: ReSent-User-Agent: Alpine 1.10 (OSX 1074 2008-06-04) There has suddenly been a huge amount of SMTP activity on Lingling in the past few hours. Most of the incoming IP addresses seem to be legitimate mail servers, but nothing is actually making it into Lingling's mailer queues. It's not a denial-of-service attack, since it'd be pretty easy to grab all 8 available SMTP forks. I guess that some spam run forged a bogus Lingling address as the Return-Path and/or used one of the throwaway addresses that I used in an RFC. It's cool watching how TOPS-20 is taking all this with aplomb. -- Mark -- http://panda.com/tops-20 TOPS-20: a great improvement over its successors 2-Aug-2008 23:27:41-PDT,1747;000000000000 Return-Path: Received: from pangtzu.panda.com ([206.124.149.117]) by Lingling.Panda.COM with TCP/SMTP; Sat, 2 Aug 2008 23:24:15 -0700 (PDT) X-Return-Path: X-Received: from omr2.networksolutionsemail.com ([205.178.146.52]) by Lingling.Panda.COM with TCP/SMTP; Sat, 2 Aug 2008 22:05:18 -0700 (PDT) X-Received: from mail.networksolutionsemail.com (ns-omr2.mgt.netsol.com [10.49.6.65]) by omr2.networksolutionsemail.com (8.13.6/8.13.6) with SMTP id m734jnTB026039 for ; Sun, 3 Aug 2008 00:45:49 -0400 X-Received: (qmail 14306 invoked by uid 78); 3 Aug 2008 04:45:49 -0000 X-Received: from unknown (HELO ?192.168.10.162?) (74.192.168.94) by ns-omr2.lb.hosting.dc2.netsol.com with SMTP; 3 Aug 2008 04:45:49 -0000 Message-Id: <7242519A-2B00-43A9-9134-848C64F7BFA1@raulersons.com> From: Paul Raulerson To: TOPS-20 Hackers and Yackers Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v928.1) Subject: Web Server & CGI Programs Date: Sat, 2 Aug 2008 23:45:49 -0500 X-Mailer: Apple Mail (2.928.1) ReSent-Date: Sat, 2 Aug 2008 23:24:04 -0700 (PDT) ReSent-From: TOPS-20 List Moderator ReSent-To: TOPS-20 Distribution: ; ReSent-Subject: Web Server & CGI Programs ReSent-Message-ID: ReSent-User-Agent: Alpine 1.10 (OSX 1074 2008-06-04) Probably been answered somewhere before, but has Panda got a web server running under TOPS-20? If so, is it capable of running CGI programs - and in what language? Thanks -Paul 3-Aug-2008 12:49:38-PDT,3896;000000000000 Return-Path: Received: from pangtzu.panda.com ([206.124.149.117]) by Lingling.Panda.COM with TCP/SMTP; Sun, 3 Aug 2008 12:43:53 -0700 (PDT) X-Return-Path: X-Received: from mta2.srv.hcvlny.cv.net ([167.206.4.197]) by Lingling.Panda.COM with TCP/SMTP; Sun, 3 Aug 2008 12:24:43 -0700 (PDT) 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 <0K51005RYGIRQ010@mta2.srv.hcvlny.cv.net>; Sun, 03 Aug 2008 14:54:28 -0400 (EDT) Date: Sun, 03 Aug 2008 14:54:26 -0400 From: Thomas DeBellis Subject: Re: fun with TOPS-20 SMTP servers In-reply-to: To: Mark Crispin Cc: Tops-20 Wizards Message-id: <4895FEE2.3090002@optonline.net> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en References: User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) ReSent-Date: Sun, 3 Aug 2008 12:43:45 -0700 (PDT) ReSent-From: TOPS-20 List Moderator ReSent-To: TOPS-20 Distribution: ; ReSent-Subject: Re: fun with TOPS-20 SMTP servers ReSent-Message-ID: ReSent-User-Agent: Alpine 1.10 (OSX 1074 2008-06-04) > It's cool watching how TOPS-20 is taking all this with aplomb. Indeed. You wouldn't believe how much baloney I get (actually, you certainly would). I have no small amount of code that detects typical script attacks (which wouldn't work on my implementation, anyway) and throws those unmentionable cretins right off. The only thing I haven't done yet is implement an IP address based black list (I have one for user ids). I don't know why I didn't think of that... Anyway, it's on the list of Things To Do. But the real problem is that my current implementation still expends too much processor time getting rid of unmentionables. I parse the system commend file on every FTP job start up, which isn't particularly quick. First, I have some reworking to do to speed up the parsing logic. Second, I need to implement some sort of a binary file that can be written post-parsing which is then mapped on FTP job start up. Something like what the mail system does with MAILING-LISTS.TXT. But I think the real problem right now is the way FTP start up is architected to begin with. As soon as a connection happens, a NOT- LOGGED-IN Tops-20 job is fired up which then has to decide what to do. At least on my machine, putting a job together just to have it go away almost immediately doesn't sound like the best approach if you're getting a lot of hits. I could save that overhead by not having NETSRV handle incoming FTP connections. I'd split the FTP server into two halves. One would be a multi-forking server (ala NETSRV) which would have all of the login validation and idiot detection logic. On an incoming connection, there would be no fork start up time; simply an activation with an already mapped binary file. This would also enable me to keep some sort of a central list of IP addresses that I had already punted. Given that, I could then have a heuristic to decide whether I should even pay attention to an incoming connection attempt. I can't easily do that with seperate FTP jobs. But this is the way the BBN server is architected, so for right now, this is the way I do it. So basically, the Tops-20 Extended Mode Server is taking it all with a plum ... --T (Who is finally finishing the paged structure receive code) 3-Aug-2008 20:18:55-PDT,8604;000000000000 Return-Path: Received: from pangtzu.panda.com ([206.124.149.117]) by Lingling.Panda.COM with TCP/SMTP; Sun, 3 Aug 2008 20:14:26 -0700 (PDT) X-Return-Path: X-Received: from mta4.srv.hcvlny.cv.net ([167.206.4.199]) by Lingling.Panda.COM with TCP/SMTP; Sun, 3 Aug 2008 19:43:14 -0700 (PDT) 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 <0K52006XO270C9E0@mta4.srv.hcvlny.cv.net> for TOPS-20@lingling.panda.com; Sun, 03 Aug 2008 22:42:37 -0400 (EDT) Date: Sun, 03 Aug 2008 22:42:35 -0400 From: Thomas DeBellis Subject: Re: fun with TOPS-20 SMTP servers In-reply-to: <48964B21.3070809@RCN.Com> To: "Alan H. Martin" Cc: Tops-20 Wizards Message-id: <48966C9B.1090200@optonline.net> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en References: <4895FEE2.3090002@optonline.net> <48964B21.3070809@RCN.Com> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) ReSent-Date: Sun, 3 Aug 2008 20:14:18 -0700 (PDT) ReSent-From: TOPS-20 List Moderator ReSent-To: TOPS-20 Distribution: ; ReSent-Subject: Re: fun with TOPS-20 SMTP servers ReSent-Message-ID: ReSent-User-Agent: Alpine 1.10 (OSX 1074 2008-06-04) > Or what some app (whose name slips my mind) did with logical name > definitions in bulk. > > I don't know how it represented the set of logical name definitions > on disk, but I wouldn't be surprised in the least if it was a bunch > of JSYS argument blocks, all ready to loop over. Really?? What kind of application would use THAT many logical names? If you happen to remember, please do tell; I'm really curious. Anybody else? I would dearly love to either take credit for or claim to have independently invented the idea of saving parse tables and other such information to disk. Alas, no ... The Columbia Galaxy did this sort of stuff. On start up, our LPTSPL would check the date of our (local) LPFORM.BIN file and, if it was older than LPFORM.INI, LPTSPL would parse LPFORM.INI and then save those parse tables to disk. Later LPTSPL fire up was a LOT faster. Whaaay faster. I think it shaved something like one or two MINUTES off of our system boot start time. And the system had a lot lower load level when you were allowed to log in because there were no LPTSPLs running around gobbling up cycles each trying to parse LPFORM.INI. Columbia had *** A LOT *** of printers--even a DN200 and other IBM stuff off of a DN65. And everything could print to everything else (I also wrote the code to do that). So we needed to run more than a couple of LPTSPLs. Printing got to be pretty hairy towards the end ... Eventually, it seemed to me that it would be more logical to have all of that form information be communicated to LPTSPL via Orion to centralize the stuff that you had to configure in order to get printing on the air. In any event, I thought the LPFORM.INI/BIN code was pretty neat (one major reason being that I wrote it). But I got the idea from somewhere else... I think from our Exec (Keng?). This is a logical thing to do with the Extended mode FTP server, which can be configured both at start up (via an installation wide EFTPSR.CMD file) and on job log in (via the user's EFTPSR.CMD file). Given the number of parameters that you can set, that can get to be a fair amount of parsing. You need to be able to set all of this stuff to prevent EFTPSR from taking over your system (if you've got more than 2 active users), saturating your network connection and to condition the auto-bonehead detection logic. There is also some amount of 'Unix' configuration, depending on how brain damaged your FTP client is. Some graphical FTP clients are specticularly brain damaged (I'm grinding my teeth right now just thinking about one in particular). Given the above, start up time would probably be improved by using the .BIN approach that I did in LPTSPL. I just haven't done the measurements yet to see what a win it would be. That actual work itself might not be all that bad. .PSECTs make certain things much easier than they used to be. I think I used some sort of LOC/RELOC/ORG hackery to make the LPFORM.BIN stuff work. Can't remember ... > I've never written a network application on Tops-20 *or* Unix, Avoid programming the Unix networking interface if at all possible unless you happen to like getting hives, computationally speaking. Use the pure and natural Tops-20 JSYS interface which, in comparison, is sheer hackerly delight. This is no exaggeration. > but the current architecture smells like a design that puts user > validation where it belongs - in the job that needs to access the > user's files. It does smell, but this is most likely because of its age and lack of proper preservatives. It's hard to judge the BBN architecture. It's been around in various forms for a LONG time, since at least the NCP days when FTP was used to deliver mail. In antiquity, it was (relatively) easy to identify people messing around and show them the true disdain that they merited (or the door). The BBN architecture clearly was not designed for a lot of rapid connections, many of which may get abandoned. 'Modern' FTP clients (the graphical ones) can make some pretty hefty demands in that regard, opening a connection, getting a listing, punting the connection, making another one for a transfer and then a couple more to have multiple transfers happen in flight. For an FTP server that keeps forks lying around, one or more may already be ready for a connection, in which case they can simply be 'continued'. That's pretty efficient. Starting up a job is not as efficient. I certainly can not remember even the gross details, but I know some things get locked and JSB's and PSB's have to get allocated and all that fine stuff. That's even before you connect the 'proto-job' to the TVT and FTPSER gets invoked. It stinks that all of this bit banging happens and the network connection is then immediately tossed and the job punted because of the (regretably necessary) cretin detection and action logic. It would be nicer to not even bother with all that unless you were SURE that you had a valid user (and not a script kiddie) > Splitting the server in half for a hypothetical performance > bottleneck implies creating a trusted backchannel between the half > of the FTP server responsible for security and the half willing to > perform file I/O on behalf of anyone that can fake a validated > request. I'm not talking about splitting the FTP server in half for transfer performance bottleneck reasons, the point is to split out the validation code so that you could decide whether to even bother with the job start up. Once the user is logged in, file transfer performance would be unchanged. > If so, any hacker worth their salt would set a high priority on > inventing a way to feed requests to the second half of the server. Heh... In that regard, the server is already split in half. The control connection is handled by the (cleverly named) control fork whose purpose in life is to parse RFC959 verbs and then do something useful with them. When a command can not be immediately satisfied (or has the potential for any sort of a block), the (similarly cleverly named) data fork is invoked. This is commonly done for file transfers such as STOR and RETR, but is also done for LIST, NLST and SMNT (hey, those disk mounts can sure take a while ...) This portion of the server is (partially) architected to allow for multiple in flight data transfers which RF959 seems to imply, but does not define. This also allows the server to trivially implement IP and ABOR handling. Error handling is just as easy: got a problem? KFORK% the data fork; no recovery logic needed. However, considering the etymology of salery with respect to the computer science field and hacking in particular, one is led to the inexorable conclusion that salt just ain't what it used to be. We live in barbaric times. 3-Aug-2008 20:20:59-PDT,6464;000000000000 Return-Path: Received: from pangtzu.panda.com ([206.124.149.117]) by Lingling.Panda.COM with TCP/SMTP; Sun, 3 Aug 2008 20:15:06 -0700 (PDT) X-Return-Path: X-Received: from mta5.srv.hcvlny.cv.net ([167.206.4.200]) by Lingling.Panda.COM with TCP/SMTP; Sun, 3 Aug 2008 20:08:54 -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-8.04 (built Feb 28 2007)) with ESMTP id <0K52003KS3E2RWF0@mta5.srv.hcvlny.cv.net> for TOPS-20@lingling.panda.com; Sun, 03 Aug 2008 23:08:27 -0400 (EDT) Date: Sun, 03 Aug 2008 23:08:25 -0400 From: Thomas DeBellis Subject: Re: Double Float and Round In-reply-to: <1a6457e90807271258r112f1ebeu79c29a2af8c2d2d3@mail.gmail.com> To: Chris Smith Cc: Tops-20 Wizards Message-id: <489672A9.2080205@optonline.net> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en References: <488A0158.10203@acedsl.com> <1a6457e90807260847y212f7a2enaf02b38cbf8fcadc@mail.gmail.com> <1a6457e90807260850u58d9c71k3c9e889a38b47b9a@mail.gmail.com> <1a6457e90807261400s5dfda7ccm8954ff63455a8cc0@mail.gmail.com> <488BE109.9000606@RCN.Com> <1a6457e90807270557ye02c3c6l344e102198668ace@mail.gmail.com> <488C7230.5090400@RCN.Com> <1a6457e90807271258r112f1ebeu79c29a2af8c2d2d3@mail.gmail.com> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) ReSent-Date: Sun, 3 Aug 2008 20:14:59 -0700 (PDT) ReSent-From: TOPS-20 List Moderator ReSent-To: TOPS-20 Distribution: ; ReSent-Subject: Re: Double Float and Round ReSent-Message-ID: ReSent-User-Agent: Alpine 1.10 (OSX 1074 2008-06-04) Chris Smith wrote: > Ok, final answer. Chris Gee Thanks!! That's an interesting bit of code; I'm enjoying noodling over it. Here is what I wound up doing (which I did before I got your final response). Basically what I was interested in was doing some floating point on some numbers whose mantissa's would not fit in 28 bits, but were not substantially larger than that. And not negative. My approach is fairly straightforward (and largely uninformed). If number had a non-zero high order, then I floated that and used the exponent to determine how to position the double word mantissa, accounting for the extra magnitude in the exponent. If the number had a zero high order, then I floated the low order, and used that exponent as a seed for a (larger) shift, but left the exponential magnitude alone. At least for the few trivial cases that I tried, this is doing want I want. Have a look (any math heros have any opinion here?) ^L SUBTTL Routine to implement double float ; Call: T1,T2 - KL/KI double integer ; Ret: T1,T2 - double float of above (non-KA format) ; The routine assumes that the exponent will always be positive (I.E., ; greater than 128 decimal, 200 octal). This is--by definition-- ; always true for integers: there will never be fractions, much less ; values less than 1 other than zero (0) or a negative. ; ; It also assumes that the number will be positive. If this is not ; the case, it takes the magitude of the integer and multiplies the ; eventual result by double floating negative 1. This will slow down ; the execution for negative numbers, but in this program we never ; produce those. ; ; It also doesn't do any rounding. Since the numbers in question are ; not going to be THAT large, this is not a problem. We're just ; looking to keep the original number in the mantissa and hence need ; the additional word of dynamic range FXPMAG== ; Floating exponent magnitude EXPMAG: POINTR. T1,FXPMAG ; Pointer to floating exponent magnitude FFRACM== ; Floating fractional mask DFLOAT: SAVEAC ; Will need some scratch CAIGE T1,0 ; Something positivishly flavored? IFSKP. ; Nothing much to do, then JUMPE T2,R ; If no low order, it's zero; done MOVE T4,T2 ; Quickly save a copy of the low order SETZB Q2,T3 ; flag positivity; quickly zero high order ELSE. ; Otherwise make positive and fix later DMOVN T3,T1 ; Negatively postivize the double SETO Q2, ; Flag negativity ENDIF. ; End case of negative signed double ; Figure out what to float and float it CAIE T3,0 ; No high order? IFSKP. ; No, don't need to worry about shifting FLTR T1,T4 ; Float the low order LDB T2,EXPMAG ; Grab the (always positive) magnitude MOVEI Q1,^D<35+35-8> ; But are shifting an additional word over SUB Q1,T2 ; Construct full double shift TXZ T1,FFRACM ; Stomp everything but the exponent ELSE. ; Otherwise have a BIG number FLTR T1,T3 ; Float the high order LDB T2,EXPMAG ; Grab the (always positive) magnitude MOVEI Q1,^D<35-8> ; Maximum original shift (excluding the exponent) SUB Q1,T2 ; Calculate the original entire shift ADDI T2,^D35 ; Full signed word worth of magnitude to exponent MOVX T1,<1B1> ; Set up for excess 128 exponent DPB T2,EXPMAG ; Set the exponent magnitude ENDIF. ; End case of floating something ; Now paste everything together ASHC T3,(Q1) ; Normalize the double integer IOR T1,T3 ; OR in high order mantissa of double float MOVE T2,T4 ; Can simply drop in the low order ; Now have non-rounded number CAIE Q2,0 ; Was the original negative?? DFMP T1,[EXP -1.,.INFIN] ;Yes, (re)negativize our result (slowly) RET ; Done 5-Aug-2008 07:49:24-PDT,1345;000000000000 Return-Path: Received: from pangtzu.panda.com ([206.124.149.117]) by Lingling.Panda.COM with TCP/SMTP; Tue, 5 Aug 2008 07:46:34 -0700 (PDT) X-Return-Path: X-Received: from pangtzu.panda.com ([206.124.149.117]) by Lingling.Panda.COM with TCP/SMTP; Mon, 4 Aug 2008 23:46:34 -0700 (PDT) Date: Mon, 4 Aug 2008 23:46:29 -0700 (PDT) From: Mark Crispin Sender: mrc@pangtzu.panda.com To: TOPS-20 Hackers and Yackers Subject: bizarre crash Message-ID: User-Agent: Alpine 1.10 (OSX 1074 2008-06-04) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII ReSent-Date: Tue, 5 Aug 2008 07:46:15 -0700 (PDT) ReSent-From: TOPS-20 List Moderator ReSent-To: TOPS-20 Distribution: ; ReSent-Subject: bizarre crash ReSent-Message-ID: ReSent-User-Agent: Alpine 1.10 (OSX 1074 2008-06-04) I just got an ILPSEC bughlt. In trying to debug it, I put a breakpoint at PFAID and did an XJRSTF TRAPFL to retry. Instead of faulting again, the system resumed normally! I wonder what happened. -- Mark -- http://panda.com/tops-20 TOPS-20: a great improvement over its successors 5-Aug-2008 09:20:50-PDT,1039;000000000000 Return-Path: Received: from pangtzu.panda.com ([206.124.149.117]) by Lingling.Panda.COM with TCP/SMTP; Tue, 5 Aug 2008 09:18:29 -0700 (PDT) X-Return-Path: X-Received: from xkleten.paulallen.com ([216.220.195.10]) by Lingling.Panda.COM with TCP/SMTP; Tue, 5 Aug 2008 09:16:02 -0700 (PDT) Date: Tue, 5 Aug 2008 09:15:20 -0700 From: JSol Subject: ILPSEC bughlt. To: mrc@lINGLING.PANDA.COM, TOPS-20@lINGLING.PANDA.COM Message-ID: <14334997906.9.JSOL@xkleten.paulallen.com> ReSent-Date: Tue, 5 Aug 2008 09:18:22 -0700 (PDT) ReSent-From: TOPS-20 List Moderator ReSent-To: TOPS-20 Distribution: ; ReSent-Subject: ILPSEC bughlt. ReSent-Message-ID: ReSent-User-Agent: Alpine 1.10 (OSX 1074 2008-06-04) I have had a problem like that before, where DDT create a space which it uses itself, but that the program it is debugging are also using..... --jsol ------- 6-Aug-2008 06:41:48-PDT,2094;000000000000 Return-Path: Received: from pangtzu.panda.com ([206.124.149.117]) by Lingling.Panda.COM with TCP/SMTP; Wed, 6 Aug 2008 06:39:13 -0700 (PDT) X-Return-Path: X-Received: from mta3.srv.hcvlny.cv.net ([167.206.4.198]) by Lingling.Panda.COM with TCP/SMTP; Wed, 6 Aug 2008 04:18:23 -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 <0K5600HWIFEGFQA1@mta3.srv.hcvlny.cv.net>; Wed, 06 Aug 2008 07:18:16 -0400 (EDT) Date: Wed, 06 Aug 2008 07:18:15 -0400 From: Thomas DeBellis Subject: Re: bizarre crash In-reply-to: To: Mark Crispin Cc: Tops-20 Wizards Message-id: <48998877.8070404@optonline.net> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en References: User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) ReSent-Date: Wed, 6 Aug 2008 06:39:01 -0700 (PDT) ReSent-From: TOPS-20 List Moderator ReSent-To: TOPS-20 Distribution: ; ReSent-Subject: Re: bizarre crash ReSent-Message-ID: ReSent-User-Agent: Alpine 1.10 (OSX 1074 2008-06-04) Boy, now that's interesting. How much detail did you get and/or record? In particular, what information were you able to glean about the memory reference? (page, section, etc.) Mark Crispin wrote: > I just got an ILPSEC bughlt. In trying to debug it, I put a breakpoint > at PFAID and did an XJRSTF TRAPFL to retry. Instead of faulting again, > the system resumed normally! > > I wonder what happened. > > -- Mark -- > > http://panda.com/tops-20 > TOPS-20: a great improvement over its successors > > 6-Aug-2008 06:44:41-PDT,2122;000000000000 Return-Path: Received: from pangtzu.panda.com ([206.124.149.117]) by Lingling.Panda.COM with TCP/SMTP; Wed, 6 Aug 2008 06:43:12 -0700 (PDT) X-Return-Path: X-Received: from pangtzu.panda.com ([206.124.149.117]) by Lingling.Panda.COM with TCP/SMTP; Wed, 6 Aug 2008 06:42:25 -0700 (PDT) Date: Wed, 6 Aug 2008 06:42:20 -0700 (PDT) From: Mark Crispin Sender: mrc@pangtzu.panda.com To: Thomas DeBellis cc: Tops-20 Wizards Subject: Re: bizarre crash In-Reply-To: <48998877.8070404@optonline.net> Message-ID: References: <48998877.8070404@optonline.net> User-Agent: Alpine 1.10 (OSX 1074 2008-06-04) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed ReSent-Date: Wed, 6 Aug 2008 06:43:04 -0700 (PDT) ReSent-From: TOPS-20 List Moderator ReSent-To: TOPS-20 Distribution: ; ReSent-Subject: Re: bizarre crash ReSent-Message-ID: ReSent-User-Agent: Alpine 1.10 (OSX 1074 2008-06-04) That's the point. There was nothing at all remarkable about that memory reference. As far as I could tell, it was just doing a TRVAR in section 6. That's why did the XJRSTF TRAPFL to dismiss it, so I could actually see the fault as it happened since I assumed that I was seeing was not the real fault. On Wed, 6 Aug 2008, Thomas DeBellis wrote: > Boy, now that's interesting. How much detail did you get and/or > record? In particular, what information were you able to glean > about the memory reference? (page, section, etc.) > > Mark Crispin wrote: > >> I just got an ILPSEC bughlt. In trying to debug it, I put a breakpoint >> at PFAID and did an XJRSTF TRAPFL to retry. Instead of faulting again, >> the system resumed normally! >> >> I wonder what happened. -- Mark -- http://panda.com/tops-20 TOPS-20: a great improvement over its successors 6-Aug-2008 18:27:35-PDT,3972;000000000000 Return-Path: Received: from pangtzu.panda.com ([206.124.149.117]) by Lingling.Panda.COM with TCP/SMTP; Wed, 6 Aug 2008 18:24:14 -0700 (PDT) X-Return-Path: X-Received: from yw-out-1718.google.com ([74.125.46.155]) by Lingling.Panda.COM with TCP/SMTP; Wed, 6 Aug 2008 15:36:56 -0700 (PDT) X-Received: by yw-out-1718.google.com with SMTP id 5so75072ywm.52 for ; Wed, 06 Aug 2008 15:36:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=/KQ5LaLiiJs62LCzsLmphAN6RDu2pvmBtDcEtnR3KOM=; b=L8DFD3IUk3ZPIlyzxMf+NcffsyPygHNH2/Hi3oyjxThnt1UbHjGIyK57x3zpfMWX3T x65zxrzThgKUoYKk9z1/6CaxMku8QKH20T2HE8nufuNtqegGXtb36DhSiQPsObby/Mb9 yzJqe1yWkdFBNXQ6pb6zZIt8G6t011Oh+6yi4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=smaCQz9VJTSJ45ADz+u7pyIYFxoHTRshidDsRRVTaohowI603c4eFJTFpbQLBjR5G6 ZOYh7wIzgLbFdi531VfwJwiHV/igXK3c5pB7DKRFtAVkVQ/ZyOlqVbq+FkP8RGhh+zb+ ZPYTwDgCP0LDC6lWinQvvdOIy4B8bSCT89/X4= X-Received: by 10.151.145.11 with SMTP id x11mr1725916ybn.109.1218062210431; Wed, 06 Aug 2008 15:36:50 -0700 (PDT) X-Received: by 10.151.13.20 with HTTP; Wed, 6 Aug 2008 15:36:50 -0700 (PDT) Message-ID: <1a6457e90808061536x59f53b94vf0a5b82ae54b06d0@mail.gmail.com> Date: Wed, 6 Aug 2008 16:36:50 -0600 From: "Chris Smith" To: "Thomas DeBellis" Subject: Re: Double Float and Round Cc: "Tops-20 Wizards" In-Reply-To: <489672A9.2080205@optonline.net> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <488A0158.10203@acedsl.com> <1a6457e90807260847y212f7a2enaf02b38cbf8fcadc@mail.gmail.com> <1a6457e90807260850u58d9c71k3c9e889a38b47b9a@mail.gmail.com> <1a6457e90807261400s5dfda7ccm8954ff63455a8cc0@mail.gmail.com> <488BE109.9000606@RCN.Com> <1a6457e90807270557ye02c3c6l344e102198668ace@mail.gmail.com> <488C7230.5090400@RCN.Com> <1a6457e90807271258r112f1ebeu79c29a2af8c2d2d3@mail.gmail.com> <489672A9.2080205@optonline.net> ReSent-Date: Wed, 6 Aug 2008 18:24:06 -0700 (PDT) ReSent-From: TOPS-20 List Moderator ReSent-To: TOPS-20 Distribution: ; ReSent-Subject: Re: Double Float and Round ReSent-Message-ID: ReSent-User-Agent: Alpine 1.10 (OSX 1074 2008-06-04) >At least for the few trivial cases that I tried, this is doing want I >want. Have a look (any math heros have any opinion here?) Hi Thomas! In lieu of an opinion I plugged DFLOAT into ditest.mac and it would like to have a word. I did not try to chase any of them down but from the test output there are problems with large integers, perhaps the pieces are not getting lined up right. The 'final answer' DIDF does not totally work. It works on klh, and simh, and a real KL (dec-10.pdpplanet.org). It does not work on a real XKL (xkleten.paulallen.com). That machine does not like the sum of two unnormalized numbers. This version does work. Also I think you can bum another instruction but I'm already at two final answers. ;;; args: t1-t2/ DI integer, unrestricted ;;; ret: t1-t2/ rounded to DF DIDF: move t3,t2 setzb t2,t4 ashc t1,-010 tlc t1,0306000 tlz t3,0400000 ashc t3,-010 tlc t3,0243000 + dfad t1,[exp 0,0] dfad t1,t3 popj p, 6-Aug-2008 18:29:05-PDT,1876;000000000000 Return-Path: Received: from pangtzu.panda.com ([206.124.149.117]) by Lingling.Panda.COM with TCP/SMTP; Wed, 6 Aug 2008 18:25:32 -0700 (PDT) X-Return-Path: X-Received: from xkleten.paulallen.com ([216.220.195.10]) by Lingling.Panda.COM with TCP/SMTP; Wed, 6 Aug 2008 16:47:58 -0700 (PDT) Date: Wed, 6 Aug 2008 16:47:15 -0700 From: JSol Subject: playing with the BBN UNIX SMTP server To: tops-20@lingling.panda.com Message-ID: <14335342320.20.JSOL@xkleten.paulallen.com> ReSent-Date: Wed, 6 Aug 2008 18:25:25 -0700 (PDT) ReSent-From: TOPS-20 List Moderator ReSent-To: TOPS-20 Distribution: ; ReSent-Subject: playing with the BBN UNIX SMTP server ReSent-Message-ID: ReSent-User-Agent: Alpine 1.10 (OSX 1074 2008-06-04) Subject: re: playing with bbn smtp server.. When I worked for BBN their UNIXites had problems, particularly BBN-UNIX.ARPA, which was hung most of the time and had to be rebooted in order to even do backups... there were alot of duplicate mail being queued and sent at the same time... What I did was create a top level process, which would create a database of process-ID's of given smtp forks, and allow only a few of them to go through. These smtp process were hung if you had more mail coming through, and refused until help arrived (releasing more smtp server ID's). The SMTP server was basically unmodified from what it did before, they just made a modified command line which the top level fork would invoke. On BBN-UNIX.ARPA the amount was about 2k or 4k, but at least it fixed the problem for good. they were able to set the command line with the number of processes they want. --jsol --m76NaJvd007144.1218066065/TheWorld.com-- ------- 13-Aug-2008 15:14:07-PDT,10291;000000000000 Return-Path: Received: from pangtzu.panda.com ([206.124.149.117]) by Lingling.Panda.COM with TCP/SMTP; Wed, 13 Aug 2008 15:11:38 -0700 (PDT) X-Return-Path: X-Received: from wf-out-1314.google.com ([209.85.200.171]) by Lingling.Panda.COM with TCP/SMTP; Sun, 10 Aug 2008 18:04:48 -0700 (PDT) X-Received: by wf-out-1314.google.com with SMTP id 26so2306250wfd.13 for ; Sun, 10 Aug 2008 18:04:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:in-reply-to:mime-version:content-type:references; bh=ixhUH0Jcx+KcMBNdWx0GCI5D4X5GFpk/sTRL5iWYv7g=; b=x3oWahxUFMLpqvIhq6Xbf9ekRDdjJ7S93zJyjh1isf9EExQ6k/Acmp28kBcz26zWVl g1ZPOHykiEY3EwXH7iO9PH+jC7QPqkyu1m11GLu0f7bZnhBzjtHiFFDlGcJSEw3UnI6R CIjS8c/7VT9lud2gNV1lMU8tTec344lfuLydQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:in-reply-to:mime-version :content-type:references; b=O6RuT3H5HzSh0b3BTQDU0OzPYLaVprpn6hAODB0dKB9MQa2Pt9HWsB1V/ASLv3nSiG ve1yLBMhJGm1ilMhyW4ZQKagLbNCvkTpTcdPI6iDMNLbiMhNnOlreNdTV/QOCp5nDOKy phEPwNNOS4SU8Df1E7PFtVt5qU3t/vZGZbV5U= X-Received: by 10.142.52.18 with SMTP id z18mr1887536wfz.295.1218416682261; Sun, 10 Aug 2008 18:04:42 -0700 (PDT) X-Received: by 10.142.125.11 with HTTP; Sun, 10 Aug 2008 18:04:42 -0700 (PDT) Message-ID: <1a6457e90808101804u520a4f6fi29c3a00557f00fc9@mail.gmail.com> Date: Sun, 10 Aug 2008 19:04:42 -0600 From: "Chris Smith" To: "Tops-20 Wizards" Subject: Re: Double Float and Round In-Reply-To: <1a6457e90808061536x59f53b94vf0a5b82ae54b06d0@mail.gmail.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_61796_8433970.1218416682257" References: <488A0158.10203@acedsl.com> <1a6457e90807260847y212f7a2enaf02b38cbf8fcadc@mail.gmail.com> <1a6457e90807260850u58d9c71k3c9e889a38b47b9a@mail.gmail.com> <1a6457e90807261400s5dfda7ccm8954ff63455a8cc0@mail.gmail.com> <488BE109.9000606@RCN.Com> <1a6457e90807270557ye02c3c6l344e102198668ace@mail.gmail.com> <488C7230.5090400@RCN.Com> <1a6457e90807271258r112f1ebeu79c29a2af8c2d2d3@mail.gmail.com> <489672A9.2080205@optonline.net> <1a6457e90808061536x59f53b94vf0a5b82ae54b06d0@mail.gmail.com> ReSent-Date: Wed, 13 Aug 2008 15:11:30 -0700 (PDT) ReSent-From: TOPS-20 List Moderator ReSent-To: TOPS-20 Distribution: ; ReSent-Subject: Re: Double Float and Round ReSent-Message-ID: ReSent-User-Agent: Alpine 1.10 (OSX 1074 2008-06-04) ------=_Part_61796_8433970.1218416682257 Content-Type: multipart/alternative; boundary="----=_Part_61797_31063414.1218416682257" ------=_Part_61797_31063414.1218416682257 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Ok, how about this ;;; args: t1-t2/ DI integer, unrestricted ;;; ret: t1-t2/ rounded to DF DIDF: move t4,t2 dmove t2,[oct 0,276000000000] ashc t1,-8 tlc t1,306000 dfad t1,t3 popj p, XKL-1 still needs a normalizing dfad (the attached ditest.mac has it) ------=_Part_61797_31063414.1218416682257 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
Ok, how about this

;;; args: t1-t2/ DI integer, unrestricted
;;; ret:  t1-t2/ rounded to DF

DIDF:   move t4,t2
        dmove t2,[oct 0,276000000000]
        ashc t1,-8
        tlc t1,306000
        dfad t1,t3
        popj p,

XKL-1 still needs a normalizing dfad (the attached ditest.mac has it)

------=_Part_61797_31063414.1218416682257-- ------=_Part_61796_8433970.1218416682257 Content-Type: application/octet-stream; name=ditest.mac Content-Transfer-Encoding: base64 X-Attachment-Id: f_fjqdrx0u0 Content-Disposition: attachment; filename=ditest.mac ICAgICAgICB0aXRsZSBkaXRlc3QKCiAgICAgICAgc2VhcmNoIG1vbnN5bQoKO2RlZmluZSBwc291 dCA8IG91dHN0ciAodDEpID4KO2RlZmluZSBwYm91dCA8IG91dGNociB0MSA+CjtkZWZpbmUgaGFs dGYgPCBleGl0ID4KCiAgICAgICAgdDE9MQogICAgICAgIHQyPTIKICAgICAgICB0Mz0zCiAgICAg ICAgdDQ9NAogICAgICAgIHQ1PTUKICAgICAgICBwPTE3Cgo7OzsgdGVzdCBESURGLCBiZWxvdwoK c3RhcnQ6ICBtb3ZlIHAsWy1uc3RhY2ssLHN0YWNrXQogICAgICAgIHhtb3ZlaSB0MSxESXRhYgog ICAgICAgIG1vdmVtIHQxLHB0cgogICAgICAgIG1vdmVpIHQxLG5ESXRhYgogICAgICAgIG1vdmVt IHQxLGNudApscDE6ICAgIGRtb3ZlIHQxLEBwdHIKICAgICAgICBwdXNoaiBwLG9jdG91dAogICAg ICAgIGhycm9pIHQxLFthc2NpeiAvICAgIC9dCiAgICAgICAgcHNvdXQKICAgICAgICBkbW92ZSB0 MSxAcHRyCiAgICAgICAgcHVzaGogcCxESURGCiAgICAgICAgcHVzaGogcCxvY3RvdXQKICAgICAg ICBocnJvaSB0MSxbYXNjaXogLyAgICAvXQogICAgICAgIHBzb3V0CiAgICAgICAgZG1vdmUgdDEs QHB0cgogICAgICAgIGhyciB0MSx0MgogICAgICAgIGZsdHIgdDEsdDEKICAgICAgICBwdXNoaiBw LHNuZ291dAogICAgICAgIGhycm9pIHQxLFthc2NpeiAvCi9dCiAgICAgICAgcHNvdXQKICAgICAg ICBhb3MgcHRyCiAgICAgICAgYW9zIHB0cgogICAgICAgIHNvc2UgY250CiAgICAgICAgIGpyc3Qg bHAxCiAgICAgICAgaGFsdGYKCnB0cjogICAgYmxvY2sgMQpjbnQ6ICAgIGJsb2NrIDEKCkRJdGFi OiAgb2N0IDAwMDAwMDAwMDAwMCwwMDAwMDAwMDAwMDAKICAgICAgICBvY3QgMDAwMDAwMDAwMDAw LDAwMDAwMDAwMDAwNQogICAgICAgIG9jdCAwMDA3Nzc3Nzc3NzcsNzc3Nzc3Nzc3Nzc3CglvY3Qg MDAwNzc3Nzc3Nzc3LDAwMDc3Nzc3Nzc3NwoJb2N0IDAwMDc3Nzc3Nzc3NywwMDAwMDAwMDAwMDAK CW9jdCAwMDAwMDAwMDAwMDAsMDAwNzc3Nzc3Nzc3CglvY3QgMDAxNzc3Nzc3Nzc3LDAwMDc3Nzc3 Nzc3NwoJb2N0IDAwMDc3Nzc3Nzc3NywwMDE3Nzc3Nzc3NzcKCiAgICAgICAgb2N0IDc3Nzc3Nzc3 Nzc3Nyw3Nzc3Nzc3Nzc3NzcKICAgICAgICBvY3QgNzc3MDAwMDAwMDAwLDAwMDAwMDAwMDAwMQog ICAgICAgIG9jdCA3NzcwMDAwMDAwMDAsMDAwMDAwMDAwMDAwCiAgICAgICAgb2N0IDc3Nzc3Nzc3 Nzc3Nyw3NzcwMDAwMDAwMDAKICAgICAgICBvY3QgNzc3MDAwMDAwMDAwLDc3Nzc3Nzc3Nzc3Nwog ICAgICAgIG9jdCA3Nzc3Nzc3Nzc3NzcsMDAwMDAwMDAwMDAwCiAgICAgICAgb2N0IDc3Nzc3Nzc3 Nzc3NywyMDAwMDAwMDAwMDAKICAgICAgICBvY3QgNzc3Nzc3Nzc3Nzc3LDc3Nzc3Nzc3NzAwMAog ICAgICAgIG9jdCA3Nzc3Nzc3Nzc3NzcsNzc3Nzc3Nzc3NDAwCgogICAgICAgIG9jdCAwMDE3Nzc3 Nzc3NzcsNzc3Nzc3Nzc3Nzc2CiAgICAgICAgb2N0IDAwMzc3Nzc3Nzc3Nyw3Nzc3Nzc3Nzc3NzQK ICAgICAgICBvY3QgMDA3Nzc3Nzc3Nzc3LDc3Nzc3Nzc3Nzc3MAogICAgICAgIG9jdCAwMTc3Nzc3 Nzc3NzcsNzc3Nzc3Nzc3NzYwCiAgICAgICAgb2N0IDAzNzc3Nzc3Nzc3Nyw3Nzc3Nzc3Nzc3NDAK ICAgICAgICBvY3QgMDc3Nzc3Nzc3Nzc3LDc3Nzc3Nzc3NzcwMAogICAgICAgIG9jdCAxNzc3Nzc3 Nzc3NzcsNzc3Nzc3Nzc3NjAwCiAgICAgICAgb2N0IDM3Nzc3Nzc3Nzc3Nyw3Nzc3Nzc3Nzc0MDAK CiAgICAgICAgb2N0IDAwMTc3Nzc3Nzc3Nyw3Nzc3Nzc3Nzc3NzcKICAgICAgICBvY3QgMDAzNzc3 Nzc3Nzc3LDc3Nzc3Nzc3Nzc3NgogICAgICAgIG9jdCAwMDc3Nzc3Nzc3NzcsNzc3Nzc3Nzc3Nzc0 CiAgICAgICAgb2N0IDAxNzc3Nzc3Nzc3Nyw3Nzc3Nzc3Nzc3NzAKICAgICAgICBvY3QgMDM3Nzc3 Nzc3Nzc3LDc3Nzc3Nzc3Nzc2MAogICAgICAgIG9jdCAwNzc3Nzc3Nzc3NzcsNzc3Nzc3Nzc3NzQw CiAgICAgICAgb2N0IDE3Nzc3Nzc3Nzc3Nyw3Nzc3Nzc3Nzc3MDAKICAgICAgICBvY3QgMzc3Nzc3 Nzc3Nzc3LDc3Nzc3Nzc3NzYwMAoKICAgICAgICBvY3QgMDAwMDAwMDAwMDAwLDM3Nzc3Nzc3Nzc3 NwogICAgICAgIG9jdCAzNzc3Nzc3Nzc3NzcsMDAwMDAwMDAwMDAwCgogICAgICAgIG9jdCA0MDAw MDAwMDAwMDAsMDAwMDAwMDAwMDAwCiAgICAgICAgb2N0IDQwMDAwMDAwMDAwMCwwMDAwMDAwMDAw MDEKICAgICAgICBvY3QgNDAwMDAwMDAwMDAwLDAwMDAwMDAwMDIwMAogICAgICAgIG9jdCA0MDAw MDAwMDAwMDAsMDAwMDAwMDAwNDAwCiAgICAgICAgb2N0IDQwMDAwMDAwMDAwMCwwMDAwMDAwMDEw MDAKCiAgICAgICAgb2N0IDc3NjAwMDAwMDAwMCwwMDAwMDAwMDAwMDAKICAgICAgICBvY3QgNzc2 MDAwMDAwMDAwLDAwMDAwMDAwMDAwMQogICAgICAgIG9jdCA3NzYwMDAwMDAwMDAsMDAwMDAwMDAw MDAyCgogICAgICAgIG9jdCA0MDA3Nzc3Nzc3NzcsNzc3Nzc3Nzc3Nzc2CiAgICAgICAgb2N0IDQw MTc3Nzc3Nzc3Nyw3Nzc3Nzc3Nzc3NzQKICAgICAgICBvY3QgNDAzNzc3Nzc3Nzc3LDc3Nzc3Nzc3 Nzc3MAogICAgICAgIG9jdCA0MDc3Nzc3Nzc3NzcsNzc3Nzc3Nzc3NzYwCiAgICAgICAgb2N0IDQx Nzc3Nzc3Nzc3Nyw3Nzc3Nzc3Nzc3NDAKICAgICAgICBvY3QgNDM3Nzc3Nzc3Nzc3LDc3Nzc3Nzc3 NzcwMAogICAgICAgIG9jdCA0Nzc3Nzc3Nzc3NzcsNzc3Nzc3Nzc3NjAwCiAgICAgICAgb2N0IDU3 Nzc3Nzc3Nzc3Nyw3Nzc3Nzc3Nzc0MDAKICAgICAgICBvY3QgNzc3Nzc3Nzc3Nzc3LDc3Nzc3Nzc3 NzAwMAoKICAgICAgICBvY3QgNDAwNzc3Nzc3Nzc3LDc3Nzc3Nzc3Nzc3NwogICAgICAgIG9jdCA0 MDE3Nzc3Nzc3NzcsNzc3Nzc3Nzc3Nzc2CiAgICAgICAgb2N0IDQwMzc3Nzc3Nzc3Nyw3Nzc3Nzc3 Nzc3NzQKICAgICAgICBvY3QgNDA3Nzc3Nzc3Nzc3LDc3Nzc3Nzc3Nzc3MAogICAgICAgIG9jdCA0 MTc3Nzc3Nzc3NzcsNzc3Nzc3Nzc3NzYwCiAgICAgICAgb2N0IDQzNzc3Nzc3Nzc3Nyw3Nzc3Nzc3 Nzc3NDAKICAgICAgICBvY3QgNDc3Nzc3Nzc3Nzc3LDc3Nzc3Nzc3NzcwMAogICAgICAgIG9jdCA1 Nzc3Nzc3Nzc3NzcsNzc3Nzc3Nzc3NjAwCiAgICAgICAgb2N0IDc3Nzc3Nzc3Nzc3Nyw3Nzc3Nzc3 Nzc0MDAKCm5ESXRhYj08Li1ESXRhYj4vMgogICAgICAgIApuc3RhY2s9PTEwMApzdGFjazogIGJs b2NrIG5zdGFjawoKCjs7OyBhcmdzOiB0MS10Mi8gREkgaW50ZWdlciwgaGlnaCA5IGJpdHMgYWxs IHNpZ25zCjs7OyByZXQ6ICB0MS10Mi8gcm91bmRlZCB0byBERgoKRElERng6ICB0bGMgdDEsMDI3 NjAwMAogICAgICAgIGRmYWQgdDEsW2V4cCAwLDBdCiAgICAgICAgcG9waiBwLAogICAgICAgIAoK Ozs7IGFyZ3M6IHQxLXQyLyBESSBpbnRlZ2VyLCB1bnJlc3RyaWN0ZWQKOzs7IHJldDogIHQxLXQy LyByb3VuZGVkIHRvIERGCgpESURGOiAgIG1vdmUgdDQsdDIKICAgICAgICBkbW92ZSB0Mixbb2N0 IDAsMjc2MDAwMDAwMDAwXQogICAgICAgIGFzaGMgdDEsLTgKICAgICAgICB0bGMgdDEsMzA2MDAw CiAgICAgICAgZGZhZCB0MSxbZXhwIDAsMF0KICAgICAgICBkZmFkIHQxLHQzCiAgICAgICAgcG9w aiBwLAoKOzs7IGFyZ3M6IHQxLXQyLyBESSBpbnRlZ2VyCjs7OyBwcmludGVkIGluIG9jdGFsIG9u IHN0ZG91dAoKb2N0b3V0OiBkbW92ZW0gdDEsb2N0dmFsCiAgICAgICAgZG1vdmUgdDIsb2N0dmFs CiAgICAgICAgbW92ZWkgdDQsMzAKICAgICAgICBtb3ZlaSB0NSw3Cm9jdDE6ICAgbW92ZWkgdDEs IiAiCiAgICAgICAgc29qbiB0NSxvY3QyCiAgICAgICAgIHBib3V0CiAgICAgICAgIG1vdmVpIHQ1 LDYKb2N0MjogICBtb3ZlIHQxLHQyCiAgICAgICAgbHNoIHQxLC00MQogICAgICAgIGFkZGkgdDEs IjAiCiAgICAgICAgcGJvdXQKICAgICAgICBsc2hjIHQyLDMKICAgICAgICBzb2pnIHQ0LG9jdDEK ICAgICAgICBwb3BqIHAsIAoKb2N0dmFsOiBibG9jayAyCgoKOzs7IGFyZ3M6IHQxLyBTSSBpbnRl Z2VyCjs7OyBwcmludGVkIGluIG9jdGFsIG9uIHN0ZG91dAoKc25nb3V0OiBtb3ZlIHQyLHQxCiAg ICAgICAgbW92ZWkgdDQsMTQKICAgICAgICBtb3ZlaSB0NSw3CnNvY3QxOiAgbW92ZWkgdDEsIiAi CiAgICAgICAgc29qbiB0NSxzb2N0MgogICAgICAgICBwYm91dAogICAgICAgICBtb3ZlaSB0NSw2 CnNvY3QyOiAgbW92ZSB0MSx0MgogICAgICAgIGxzaCB0MSwtNDEKICAgICAgICBhZGRpIHQxLCIw IgogICAgICAgIHBib3V0CiAgICAgICAgbHNoIHQyLDMKICAgICAgICBzb2pnIHQ0LHNvY3QxCiAg ICAgICAgcG9waiBwLCAKCiAgICAgICAgZW5kIHN0YXJ0Cg== ------=_Part_61796_8433970.1218416682257-- 24-Aug-2008 10:18:31-PDT,1055;000000000000 Return-Path: Received: from pangtzu.panda.com ([206.124.149.117]) by Lingling.Panda.COM with TCP/SMTP; Sun, 24 Aug 2008 10:16:14 -0700 (PDT) X-Return-Path: X-Received: from xkleten.paulallen.com ([216.220.195.10]) by Lingling.Panda.COM with TCP/SMTP; Sun, 24 Aug 2008 10:01:52 -0700 (PDT) Date: Sun, 24 Aug 2008 10:01:00 -0700 From: JSol Subject: tops-20 on linux... To: tops-20@lingling.panda.com Reply-To: JSol@MIT.EDU Message-ID: <14339986955.18.JSOL@xkleten.paulallen.com> ReSent-Date: Sun, 24 Aug 2008 10:16:05 -0700 (PDT) ReSent-From: TOPS-20 List Moderator ReSent-To: TOPS-20 Distribution: ; ReSent-Subject: tops-20 on linux... ReSent-Message-ID: ReSent-User-Agent: Alpine 1.10 (OSX 1074 2008-06-04) Do any of you have time to help me bring this system up? I need someone who is familiar with KLH-KL, and someone familiar with linux. thanx, --jsol ------- 1-Sep-2008 19:38:58-PDT,2214;000000000000 Return-Path: Received: from pangtzu.panda.com ([206.124.149.117]) by Lingling.Panda.COM with TCP/SMTP; Mon, 1 Sep 2008 19:36:14 -0700 (PDT) X-Return-Path: X-Received: from fed1rmmtao106.cox.net ([68.230.241.40]) by Lingling.Panda.COM with TCP/SMTP; Sat, 30 Aug 2008 12:42:25 -0700 (PDT) X-Received: from fed1rmimpo02.cox.net ([70.169.32.72]) by fed1rmmtao106.cox.net (InterMail vM.7.08.02.01 201-2186-121-102-20070209) with ESMTP id <20080830194219.TCJS8615.fed1rmmtao106.cox.net@fed1rmimpo02.cox.net> for ; Sat, 30 Aug 2008 15:42:19 -0400 X-Received: from duro ([68.12.115.220]) by fed1rmimpo02.cox.net with bizsmtp id 8jiK1a00J4lNohg04jiLRM; Sat, 30 Aug 2008 15:42:20 -0400 To: tops-20@lingling.panda.com Subject: TCP/IP, Lisp, and TOPS-20? From: Chris Brannon Date: Sat, 30 Aug 2008 14:39:17 -0500 Message-ID: <87sksme1i2.fsf@cox.net> User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii ReSent-Date: Mon, 1 Sep 2008 19:36:08 -0700 (PDT) ReSent-From: TOPS-20 List Moderator ReSent-To: TOPS-20 Distribution: ; ReSent-Subject: TCP/IP, Lisp, and TOPS-20? ReSent-Message-ID: ReSent-User-Agent: Alpine 2.00 (OSX 1167 2008-08-23) Hello, Has anyone managed to do TCP/IP communication from one of the Lisp systems available on TOPS-20? Here is one strategy that I am investigating. When the .fasl directive is supplied to the MIDAS assembler, it writes .fasl files that are compatible with MACLISP. Apparently, one can extend MACLISP using assembly language. I am looking at sys:*.mid for some inspiration. It doesn't seem possible to obtain, read, or write a raw JFN from MACLISP, so here are the functions I would have to implement in assembly: (connect foreign-address foreign-port [local-address local-port]) (listen local-port [local-address]) (tcp-close connection) (read-tcp connection) (write-tcp connection data) Is this a worthwhile line of investigation? -- Chris 1-Sep-2008 19:45:37-PDT,1519;000000000000 Return-Path: Received: from pangtzu.panda.com ([206.124.149.117]) by Lingling.Panda.COM with TCP/SMTP; Mon, 1 Sep 2008 19:44:17 -0700 (PDT) X-Return-Path: X-Received: from pangtzu.panda.com ([206.124.149.117]) by Lingling.Panda.COM with TCP/SMTP; Mon, 1 Sep 2008 19:42:09 -0700 (PDT) Date: Mon, 1 Sep 2008 19:42:06 -0700 (PDT) From: Mark Crispin Sender: mrc@pangtzu.panda.com To: Chris Brannon cc: tops-20@lingling.panda.com Subject: Re: TCP/IP, Lisp, and TOPS-20? In-Reply-To: <87sksme1i2.fsf@cox.net> Message-ID: References: <87sksme1i2.fsf@cox.net> User-Agent: Alpine 2.00 (OSX 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed ReSent-Date: Mon, 1 Sep 2008 19:44:11 -0700 (PDT) ReSent-From: TOPS-20 List Moderator ReSent-To: TOPS-20 Distribution: ; ReSent-Subject: Re: TCP/IP, Lisp, and TOPS-20? ReSent-Message-ID: ReSent-User-Agent: Alpine 2.00 (OSX 1167 2008-08-23) On Sat, 30 Aug 2008, Chris Brannon wrote: > Hello, > Has anyone managed to do TCP/IP communication from one of the Lisp systems > available on TOPS-20? I know that it was done in Interlisp, and almost certainly doable in MAClisp and Common Lisp. -- Mark -- http://panda.com/tops-20 TOPS-20: a great improvement over its successors 2-Sep-2008 08:17:22-PDT,8412;000000000000 Return-Path: Received: from pangtzu.panda.com ([206.124.149.117]) by Lingling.Panda.COM with TCP/SMTP; Tue, 2 Sep 2008 08:14:42 -0700 (PDT) X-Return-Path: X-Received: from klais.its.uu.se ([130.238.7.59]) by Lingling.Panda.COM with TCP/SMTP; Mon, 1 Sep 2008 23:04:07 -0700 (PDT) X-Received: from Buzz.Victor.SE (90-227-78-45-no63.tbcn.telia.com [90.227.78.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by klais.its.uu.se (Postfix) with ESMTP id A7AF1382873; Tue, 2 Sep 2008 08:04:00 +0200 (CEST) X-DKIM: Sendmail DKIM Filter v0.6.4 klais.its.uu.se A7AF1382873 DKIM-Signature: v=0.5; a=rsa-sha256; c=simple/simple; d=uu.se; s=centralsmtp; t=1220335441; bh=7VjI1mXewoy7E3hkvuSepYs0ehvlMrlf7Sz 3Ga/ZZxE=; h=Message-ID:Date:From:User-Agent:MIME-Version:To:CC: Subject:References:In-Reply-To:X-Enigmail-Version:Content-Type: X-Virus-Scanned; b=Kq5QbwQuLQokoRp9yc0u2d1gf7qFPz4wtJxZ8LLp7j1Ss3r GLNTkbFNWa7/+GYz7lTLigrqJSUaq/ZqERgn+GmbyHOQkGycErvEiBRmrc74wH6KdSE XzdZIhEafyq09RhZvEggSP0DNKjEr0+4BopaAwckwwoV1fTrCN8unsKzk= Message-ID: <48BCD750.70007@it.uu.se> Date: Tue, 02 Sep 2008 08:04:00 +0200 From: =?ISO-8859-1?Q?Bj=F6rn_Victor?= User-Agent: Thunderbird 2.0.0.16 (Macintosh/20080707) MIME-Version: 1.0 To: Chris Brannon CC: tops-20@lingling.panda.com Subject: Re: TCP/IP, Lisp, and TOPS-20? References: <87sksme1i2.fsf@cox.net> In-Reply-To: <87sksme1i2.fsf@cox.net> X-Enigmail-Version: 0.95.7 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms060800070504090703030106" X-Virus-Scanned: Debian amavisd-new at klais.its.uu.se ReSent-Date: Tue, 2 Sep 2008 08:14:34 -0700 (PDT) ReSent-From: TOPS-20 List Moderator ReSent-To: TOPS-20 Distribution: ; ReSent-Subject: Re: TCP/IP, Lisp, and TOPS-20? ReSent-Message-ID: ReSent-User-Agent: Alpine 2.00 (OSX 1167 2008-08-23) This is a cryptographically signed message in MIME format. --------------ms060800070504090703030106 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 2008-08-30 21.39, Chris Brannon wrote: > Hello, > Has anyone managed to do TCP/IP communication from one of the Lisp syst= ems > available on TOPS-20? >=20 > Here is one strategy that I am investigating. > When the .fasl directive is supplied to the MIDAS assembler, it writes > .fasl files that are compatible with MACLISP. > Apparently, one can extend MACLISP using assembly language. > I am looking at sys:*.mid for some inspiration. > It doesn't seem possible to obtain, read, or write a raw JFN from MACLI= SP, > so here are the functions I would have to implement in assembly: > (connect foreign-address foreign-port [local-address local-port]) > (listen local-port [local-address]) > (tcp-close connection) > (read-tcp connection) > (write-tcp connection data) >=20 > Is this a worthwhile line of investigation? I spent a little bit of time trying to port my Maclisp web server for ITS (http://up DOT update.uu.se/httpd.html) to TOPS-20, but found the TOPS-20 TCP implementation too poor. I still have the T20 code, but I don't remember its exact state. (The ITS version works pretty well, although it occasionally stumbles on bugs in Maclisp.) -- Bj=F6rn --------------ms060800070504090703030106 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJfTCC AxkwggKCoAMCAQICEE+vatCCcoHGDWcrJIdDo6UwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UE BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA4MDMyMTExMzgyN1oX DTA5MDMyMTExMzgyN1owfDEPMA0GA1UEBBMGVmljdG9yMR0wGwYDVQQqDBRCasO2cm4gSW5n ZW1hciBGcmFuczEkMCIGA1UEAwwbQmrDtnJuIEluZ2VtYXIgRnJhbnMgVmljdG9yMSQwIgYJ KoZIhvcNAQkBFhVCam9ybi5WaWN0b3JAaXQudXUuc2UwggEiMA0GCSqGSIb3DQEBAQUAA4IB DwAwggEKAoIBAQDJRkk/imyJ/Xb8vhL6JvDpOmzfza0syb1t4etZvXcjnySDc3roMb98kF+e A/5ypDn7V7pTPeksGZ8j9JWnVXHSZDX2kpQebfBNdq3Z2H7HfTtSiBzeq0gCf71SZcudOUW8 Fjb8mpzezvAnC+xb1o4ivgiT4trcu8KHaHmSO5rdefTMs8sUgFYmmYxoBbpDdgcKlDF1a4nZ W3RAES9uSilntGT8kDf6F+tcyhBw+MLnvVb9sHWFhDlUgcD77HUFkOxFT0XfoLjAs+t+CCAl bDaC3I4i976ftkZbmwIeaCnvqSRCipLR8ChMiAXwoR73+BkPPWFHOMxraDn+LqjFb3JrAgMB AAGjMjAwMCAGA1UdEQQZMBeBFUJqb3JuLlZpY3RvckBpdC51dS5zZTAMBgNVHRMBAf8EAjAA MA0GCSqGSIb3DQEBBQUAA4GBAE8RlOWiGgNa7rQbFgN/OAD+cFBougf2aR7tjMp3QoqkQLZm 3iPpIsNHCxzRphG2T1OnzCj13j7bZ1ij83/xrZDxSPysGlU7IcaNEJCrAebtYRB6pdjlYMPY 08ETtVMuLVIoSqBFIjFMnko7U6/Vk+QD+h7wNxW0/kWasqBB7o73MIIDGTCCAoKgAwIBAgIQ T69q0IJygcYNZyskh0OjpTANBgkqhkiG9w0BAQUFADBiMQswCQYDVQQGEwJaQTElMCMGA1UE ChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNv bmFsIEZyZWVtYWlsIElzc3VpbmcgQ0EwHhcNMDgwMzIxMTEzODI3WhcNMDkwMzIxMTEzODI3 WjB8MQ8wDQYDVQQEEwZWaWN0b3IxHTAbBgNVBCoMFEJqw7ZybiBJbmdlbWFyIEZyYW5zMSQw IgYDVQQDDBtCasO2cm4gSW5nZW1hciBGcmFucyBWaWN0b3IxJDAiBgkqhkiG9w0BCQEWFUJq b3JuLlZpY3RvckBpdC51dS5zZTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMlG ST+KbIn9dvy+Evom8Ok6bN/NrSzJvW3h61m9dyOfJINzeugxv3yQX54D/nKkOftXulM96SwZ nyP0ladVcdJkNfaSlB5t8E12rdnYfsd9O1KIHN6rSAJ/vVJly505RbwWNvyanN7O8CcL7FvW jiK+CJPi2ty7wodoeZI7mt159MyzyxSAViaZjGgFukN2BwqUMXVridlbdEARL25KKWe0ZPyQ N/oX61zKEHD4wue9Vv2wdYWEOVSBwPvsdQWQ7EVPRd+guMCz634IICVsNoLcjiL3vp+2Rlub Ah5oKe+pJEKKktHwKEyIBfChHvf4GQ89YUc4zGtoOf4uqMVvcmsCAwEAAaMyMDAwIAYDVR0R BBkwF4EVQmpvcm4uVmljdG9yQGl0LnV1LnNlMAwGA1UdEwEB/wQCMAAwDQYJKoZIhvcNAQEF BQADgYEATxGU5aIaA1rutBsWA384AP5wUGi6B/ZpHu2MyndCiqRAtmbeI+kiw0cLHNGmEbZP U6fMKPXePttnWKPzf/GtkPFI/KwaVTshxo0QkKsB5u1hEHql2OVgw9jTwRO1Uy4tUihKoEUi MUyeSjtTr9WT5AP6HvA3FbT+RZqyoEHujvcwggM/MIICqKADAgECAgENMA0GCSqGSIb3DQEB BQUAMIHRMQswCQYDVQQGEwJaQTEVMBMGA1UECBMMV2VzdGVybiBDYXBlMRIwEAYDVQQHEwlD YXBlIFRvd24xGjAYBgNVBAoTEVRoYXd0ZSBDb25zdWx0aW5nMSgwJgYDVQQLEx9DZXJ0aWZp Y2F0aW9uIFNlcnZpY2VzIERpdmlzaW9uMSQwIgYDVQQDExtUaGF3dGUgUGVyc29uYWwgRnJl ZW1haWwgQ0ExKzApBgkqhkiG9w0BCQEWHHBlcnNvbmFsLWZyZWVtYWlsQHRoYXd0ZS5jb20w HhcNMDMwNzE3MDAwMDAwWhcNMTMwNzE2MjM1OTU5WjBiMQswCQYDVQQGEwJaQTElMCMGA1UE ChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNv bmFsIEZyZWVtYWlsIElzc3VpbmcgQ0EwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAMSm PFVzVftOucqZWh5owHUEcJ3f6f+jHuy9zfVb8hp2vX8MOmHyv1HOAdTlUAow1wJjWiyJFXCO 3cnwK4Vaqj9xVsuvPAsH5/EfkTYkKhPPK9Xzgnc9A74r/rsYPge/QIACZNenprufZdHFKlSF D0gEf6e20TxhBEAeZBlyYLf7AgMBAAGjgZQwgZEwEgYDVR0TAQH/BAgwBgEB/wIBADBDBgNV HR8EPDA6MDigNqA0hjJodHRwOi8vY3JsLnRoYXd0ZS5jb20vVGhhd3RlUGVyc29uYWxGcmVl bWFpbENBLmNybDALBgNVHQ8EBAMCAQYwKQYDVR0RBCIwIKQeMBwxGjAYBgNVBAMTEVByaXZh dGVMYWJlbDItMTM4MA0GCSqGSIb3DQEBBQUAA4GBAEiM0VCD6gsuzA2jZqxnD3+vrL7CF6FD lpSdf0whuPg2H6otnzYvwPQcUCCTcDz9reFhYsPZOhl+hLGZGwDFGguCdJ4lUJRix9sncVcl jd2pnDmOjCBPZV+V2vf3h9bGCE6u9uo05RAaWzVNd+NWIXiC3CEZNd4ksdMdRv9dX2VPMYID ZDCCA2ACAQEwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcg KFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3Vpbmcg Q0ECEE+vatCCcoHGDWcrJIdDo6UwCQYFKw4DAhoFAKCCAcMwGAYJKoZIhvcNAQkDMQsGCSqG SIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDgwOTAyMDYwNDAwWjAjBgkqhkiG9w0BCQQxFgQU EgqADRLSW8imU2aO5tMFXNnwLpowUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggq hkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgYUG CSsGAQQBgjcQBDF4MHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0 aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1 aW5nIENBAhBPr2rQgnKBxg1nKySHQ6OlMIGHBgsqhkiG9w0BCRACCzF4oHYwYjELMAkGA1UE BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhBPr2rQgnKBxg1nKySHQ6Ol MA0GCSqGSIb3DQEBAQUABIIBAKXeCqL41/WxemzfolJunq8BTaK8Az8TBsH/ASf1hS7yyJWp CrGYPGPteNeEQpX7VbQAJ97ruR0/+qTaIk+bu2R0GYqxnfHqq1mJPMA2hYa7KwHaHK3DICP5 RIetFmPQRN/5robGmjK4gSimsiBIQa0XvQiXFCi0usDIFA01vctaINAZvB6MutsGVmcuNiXI ZAEd+09OAy7oKqsikqAzFTPOEOi699NmASVqbT90RdXg1g7BLuwV0+WhgI4STUx8zkY28txe UbbP8hVnwmBomaWIr/D1U2ZJOX5xSmyB5VqKMGPwZxOyItjiPbNgoHwkv/9RT9XV0T3SQRFE MEYE60UAAAAAAAA= --------------ms060800070504090703030106-- 2-Sep-2008 08:18:51-PDT,2999;000000000000 Return-Path: Received: from pangtzu.panda.com ([206.124.149.117]) by Lingling.Panda.COM with TCP/SMTP; Tue, 2 Sep 2008 08:15:03 -0700 (PDT) X-Return-Path: X-Received: from sj-iport-6.cisco.com ([171.71.176.117]) by Lingling.Panda.COM with TCP/SMTP; Tue, 2 Sep 2008 01:49:31 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.32,315,1217808000"; d="scan'208";a="150825942" X-Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-6.cisco.com with ESMTP; 02 Sep 2008 08:49:26 +0000 X-Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id m828nQV1032649; Tue, 2 Sep 2008 01:49:26 -0700 X-Received: from cisco.com (pita.cisco.com [171.71.177.199]) by sj-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id m828nQiN015743; Tue, 2 Sep 2008 08:49:26 GMT X-Received: (from billw@localhost) by cisco.com (8.8.8-Cisco List Logging/8.8.8) id BAA12069; Tue, 2 Sep 2008 01:49:13 -0700 (PDT) Sender: Bill Westfield Date: Tue, 2 Sep 2008 1:49:13 PDT From: William "Chops" Westfield To: Chris Brannon Cc: TOPS-20 List Moderator , tops-20@lingling.panda.com Subject: Re: TCP/IP, Lisp, and TOPS-20? In-Reply-To: Your message of Sat, 30 Aug 2008 14:39:17 -0500 Message-ID: DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=530; t=1220345366; x=1221209366; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=billw@cisco.com; z=From:=20William=20=22Chops=22=20Westfield=20 |Subject:=20Re=3A=20TCP/IP,=20Lisp,=20and=20TOPS-20? |Sender:=20Bill=20Westfield=20; bh=WVh0oEwUR+bxhgwiUZHExbQdWney4eDe6AuYu35Y/IQ=; b=UGz8hruGh2DcGIf0qqm24/GqBJiVg2u3QR29zx6MNjfO0YEhySmkfFWYYc oHL3Y9Y2OFDi9a5RkpRpVQ6dou7BDeaFsKYY3f98nIBGpXHZ5NGe6sOKxfO4 IIs+CNV8pw; Authentication-Results: sj-dkim-4; header.From=billw@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); ReSent-Date: Tue, 2 Sep 2008 08:14:51 -0700 (PDT) ReSent-From: TOPS-20 List Moderator ReSent-To: TOPS-20 Distribution: ; ReSent-Subject: Re: TCP/IP, Lisp, and TOPS-20? ReSent-Message-ID: ReSent-User-Agent: Alpine 2.00 (OSX 1167 2008-08-23) I worked on a tops20 file archiver that would copy files over a network to a unix system (with cheap disks), written in MacLisp at FLAIR. However, I don't recall whether it did it's own network communications, or just set up copies using some CUSP. (My main contribution was to convert from v5.x to v6.x symbols for the quaser interface.) Are you sure you can't do enough just through the filename interface to the DEC TCP api? As I recall, you could get pretty far without having to use special OS calls... BillW 2-Sep-2008 23:28:23-PDT,2279;000000000000 Return-Path: Received: from pangtzu.panda.com ([206.124.149.117]) by Lingling.Panda.COM with TCP/SMTP; Tue, 2 Sep 2008 23:26:07 -0700 (PDT) X-Return-Path: X-Received: from eastrmmtao104.cox.net ([68.230.240.46]) by Lingling.Panda.COM with TCP/SMTP; Tue, 2 Sep 2008 23:19:51 -0700 (PDT) X-Received: from eastrmimpo01.cox.net ([68.1.16.119]) by eastrmmtao104.cox.net (InterMail vM.7.08.02.01 201-2186-121-102-20070209) with ESMTP id <20080903061943.QCLV2096.eastrmmtao104.cox.net@eastrmimpo01.cox.net>; Wed, 3 Sep 2008 02:19:43 -0400 X-Received: from duro ([68.12.115.220]) by eastrmimpo01.cox.net with bizsmtp id A6Kh1a0014lNohg026KhkT; Wed, 03 Sep 2008 02:19:41 -0400 To: William "Chops" Westfield Cc: tops-20@lingling.panda.com Subject: Re: TCP/IP, Lisp, and TOPS-20? References: From: Chris Brannon Date: Wed, 03 Sep 2008 01:15:35 -0500 In-Reply-To: (William Westfield's message of "Tue\, 2 Sep 2008 1\:49\:13 PDT") Message-ID: <87myip7o1k.fsf@cox.net> User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii ReSent-Date: Tue, 2 Sep 2008 23:25:58 -0700 (PDT) ReSent-From: TOPS-20 List Moderator ReSent-To: TOPS-20 Distribution: ; ReSent-Subject: Re: TCP/IP, Lisp, and TOPS-20? ReSent-Message-ID: ReSent-User-Agent: Alpine 2.00 (OSX 1167 2008-08-23) William "Chops" Westfield writes: > Are you sure you can't do enough just through the filename interface to the > DEC TCP api? As I recall, you could get pretty far without having to use > special OS calls... The filename interface is nice, but the "open" functions of various languages can mangle filenames before passing them on to GTJFN. Also, MacLisp doesn't seem to allow one to open a file for both input and output. I'm afraid that in order to do network I/O, I'll have to make calls to the monitor. Granted, I'm way out of my league. I only started using TOPS-20 two months ago, but it sure is fun! -- Chris 3-Sep-2008 19:59:40-PDT,2676;000000000000 Return-Path: Received: from pangtzu.panda.com ([206.124.149.117]) by Lingling.Panda.COM with TCP/SMTP; Wed, 3 Sep 2008 19:57:27 -0700 (PDT) X-Return-Path: X-Received: from mta1.srv.hcvlny.cv.net ([167.206.4.196]) by Lingling.Panda.COM with TCP/SMTP; Wed, 3 Sep 2008 17:52:31 -0700 (PDT) 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 <0K6N005KIBRC8AG0@mta1.srv.hcvlny.cv.net> for TOPS-20@lingling.panda.com; Wed, 03 Sep 2008 20:52:26 -0400 (EDT) Date: Wed, 03 Sep 2008 20:52:24 -0400 From: Thomas DeBellis Subject: Re: TCP/IP, Lisp, and TOPS-20? In-reply-to: <48BCD750.70007@it.uu.se> To: =?ISO-8859-1?Q?Bj=F6rn_Victor?= Cc: Tops-20 Wizards Message-id: <48BF3148.5070906@optonline.net> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en References: <87sksme1i2.fsf@cox.net> <48BCD750.70007@it.uu.se> 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, 3 Sep 2008 19:57:14 -0700 (PDT) ReSent-From: TOPS-20 List Moderator ReSent-To: TOPS-20 Distribution: ; ReSent-Subject: Re: TCP/IP, Lisp, and TOPS-20? ReSent-Message-ID: ReSent-User-Agent: Alpine 2.00 (OSX 1167 2008-08-23) > I spent a little bit of time trying to port my Maclisp web server > for ITS (http://up DOT update.uu.se/httpd.html) to TOPS-20, but > found the TOPS-20 TCP implementation too poor. May I ask you to elaborate on the problems that you had with the Tops-20 TCP/IP implementation? I have been programming this for several years now with few problems. In fact, in some respects, I may be beating on it harder than it ever got used in the past. In particular, I am shoving section sized buffers into it and have cleared 280 KB/s transfer rates (I regularly get over 220 KB/s). That being said, I seldom do this with more than two or three concurrent sessions. One assumes that running more simultaneous transfers would more fully exercise the monitor code. The only problem that I seem to have is that sometimes on server start up, buffered output from one control connection seems to show up in another. This obviously confuses the FTP client ... But this happens on any TVT start up, so I assumed that it was a problem with the TVT code. 7-Sep-2008 17:55:04-PDT,4252;000000000000 Return-Path: Received: from pangtzu.panda.com ([206.124.149.117]) by Lingling.Panda.COM with TCP/SMTP; Sun, 7 Sep 2008 17:52:27 -0700 (PDT) X-Return-Path: X-Received: from mail1.acecape.com ([66.114.74.12]) by Lingling.Panda.COM with TCP/SMTP; Sun, 7 Sep 2008 16:50:16 -0700 (PDT) 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 m87NoAcC026131 for ; Sun, 7 Sep 2008 19:50:10 -0400 Message-ID: <48C468B1.9010700@acedsl.com> Date: Sun, 07 Sep 2008 19:50:09 -0400 From: Thomas DeBellis User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tops-20 Wizards Subject: LINK MAP off by one calculation? Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit ReSent-Date: Sun, 7 Sep 2008 17:52:18 -0700 (PDT) ReSent-From: TOPS-20 List Moderator ReSent-To: TOPS-20 Distribution: ; ReSent-Subject: LINK MAP off by one calculation? ReSent-Message-ID: ReSent-User-Agent: Alpine 2.00 (OSX 1167 2008-08-23) I was wondering if I ran into some sort of a LINK off by one printing issue for large blocks. I was putting in a little code to chase down a buffering issue (so what else is new). The following definitions are in the FTP extended mode server universal file. The section skips are to pick up any off by one read or write issues. INDORG==<05,,000000> ; Input data in section 5 page 0 OUTORG==<07,,000000> ; Output data in section 7 page 0 PAGORG==<11,,000000> ; Page structure conversion in section 11 page 0 The following definitions are in the final module: BUFLEN==<^O777777> ; Length of our section based buffers INTERN BUFLEN ; Just in case anybody else wants to know .PSECT INPUT,INDORG ; File map in or network read area INDBEG:: BLOCK BUFLEN ; Precisely an SMAP% length INDEND:: REMARK ; Mark the end of the section .ENDPS INPUT ; Close the .PSECT .PSECT OUTPUT,OUTORG ; File map out or network write area OUTBEG:: BLOCK BUFLEN ; Precisely an SMAP% length OUTEND:: REMARK ; Mark the end of the section .ENDPS OUTPUT ; Close the .PSECT .PSECT PAGE,PAGORG ; Page structure conversion PAGBEG:: BLOCK BUFLEN ; Precisely an SMAP% length (like others) PAGEND:: REMARK ; Mark the end of the section .ENDPS PAGE ; Close the .PSECT From the listing, MACRO appears to be doing the expected thing: 46187 777777 BUFLEN==<^O777777> 46188 INTERN BUFLEN 46189 46190 .PSECT INPUT,INDORG 46191 000000'06 INDBEG:: BLOCK BUFLEN 46192 777777'06 INDEND:: REMARK 46193 .ENDPS INPUT 46194 46195 .PSECT OUTPUT,OUTORG 46196 000000'07 OUTBEG:: BLOCK BUFLEN 46197 777777'07 OUTEND:: REMARK 46198 .ENDPS OUTPUT 46199 46200 .PSECT PAGE,PAGORG 46201 000000'10 PAGBEG:: BLOCK BUFLEN 46202 777777'10 PAGEND:: REMARK 46203 .ENDPS PAGE 46204 However, these are what LINK's .MAP file shows: Psect PAGE starts at 11000000 ends at 11777776 length 777777 (octal),262143. (decimal) Psect OUTPUT starts at 7000000 ends at 7777776 length 777777 (octal),262143. (decimal) Psect INPUT starts at 5000000 ends at 5777776 length 777777 (octal),262143. (decimal) Shouldn't the ending addresses be ending in 7 instead of 6? Or am I missing something? 8-Sep-2008 07:12:40-PDT,2859;000000000000 Return-Path: Received: from pangtzu.panda.com ([206.124.149.117]) by Lingling.Panda.COM with TCP/SMTP; Mon, 8 Sep 2008 07:10:27 -0700 (PDT) X-Return-Path: X-Received: from nic.cafax.se ([192.71.228.17]) by Lingling.Panda.COM with TCP/SMTP; Mon, 8 Sep 2008 00:43:50 -0700 (PDT) X-Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id m887hfrr003737; Mon, 8 Sep 2008 09:43:41 +0200 (MEST) X-Received: (from bygg@localhost) by nic.cafax.se (8.13.7/8.12.11/Submit) id m887hfwv000471; Mon, 8 Sep 2008 09:43:41 +0200 (MEST) Date: Mon, 8 Sep 2008 9:43:41 WET DST From: Johnny Eriksson To: Thomas DeBellis Cc: TOPS-20 List Moderator , Tops-20 Wizards Subject: Re: LINK MAP off by one calculation? In-Reply-To: Your message of Sun, 07 Sep 2008 19:50:09 -0400 Message-ID: ReSent-Date: Mon, 8 Sep 2008 07:10:18 -0700 (PDT) ReSent-From: TOPS-20 List Moderator ReSent-To: TOPS-20 Distribution: ; ReSent-Subject: Re: LINK MAP off by one calculation? ReSent-Message-ID: ReSent-User-Agent: Alpine 2.00 (OSX 1167 2008-08-23) > I was wondering if I ran into some sort of a LINK off by one printing > issue for large blocks. > > I was putting in a little code to chase down a buffering issue (so > what else is new). The following definitions are in the FTP extended > mode server universal file. The section skips are to pick up any off > by one read or write issues. > > INDORG==<05,,000000> ; Input data in section 5 page 0 > OUTORG==<07,,000000> ; Output data in section 7 page 0 > PAGORG==<11,,000000> ; Page structure conversion in section 11 page 0 > > The following definitions are in the final module: > > BUFLEN==<^O777777> ; Length of our section based buffers > INTERN BUFLEN ; Just in case anybody else wants to know [...] > However, these are what LINK's .MAP file shows: > > Psect PAGE starts at 11000000 ends at 11777776 length 777777 (octal),262143. (decimal) [...] > Shouldn't the ending addresses be ending in 7 instead of 6? > Or am I missing something? In my opinion, a buffer of, say, 7 words, starting at 11000000 should end at 11000006, for a total of 7 words, addresses ending in 0, 1, ... and 6. With BUFLEN equal to 777777 you are defining the buffer to be one word short of a full section, and the last word of the buffer should then end in a 6. Maybe you should try to define BUFLEN as <1,,0> instead, if you really want to use the full section. Might *this* be your off-by-one bug? --Johnny 24-Sep-2008 16:05:14-PDT,5315;000000000000 Return-Path: Received: from pangtzu.panda.com ([206.124.149.117]) by Lingling.Panda.COM with TCP/SMTP; Wed, 24 Sep 2008 16:02:42 -0700 (PDT) X-Return-Path: X-Received: from mail.math.utah.edu ([155.101.98.135]) by Lingling.Panda.COM with TCP/SMTP; Wed, 24 Sep 2008 15:38:46 -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 m8OMcNRf012955; Wed, 24 Sep 2008 16:38:23 -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 m8OMcNca017674; Wed, 24 Sep 2008 16:38:23 -0600 (MDT) X-Received: (from beebe@localhost) by psi.math.utah.edu (8.13.6/8.13.6/Submit) id m8OMcNLH017672; Wed, 24 Sep 2008 16:38:23 -0600 (MDT) Date: Wed, 24 Sep 2008 16:38:23 -0600 (MDT) From: "Nelson H. F. Beebe" To: Tops-20 Wizards Cc: beebe@math.utah.edu X-US-Mail: "Department of Mathematics, 110 LCB, University of Utah, 155 S 1400 E RM 233, Salt Lake City, UT 84112-0090, USA" X-Telephone: +1 801 581 5254 X-FAX: +1 801 585 1640, +1 801 581 4148 X-URL: http://www.math.utah.edu/~beebe Subject: [tops-20] Jay Lepreau obituary Message-ID: X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0 (mail.math.utah.edu [155.101.98.135]); Wed, 24 Sep 2008 16:38:23 -0600 (MDT) ReSent-Date: Wed, 24 Sep 2008 16:02:35 -0700 (PDT) ReSent-From: TOPS-20 List Moderator ReSent-To: TOPS-20 Distribution: ; ReSent-Subject: [tops-20] Jay Lepreau obituary ReSent-Message-ID: ReSent-User-Agent: Alpine 2.00 (OSX 1167 2008-08-23) I returned from a trip yesterday and learned of the loss last week of an long-time friend and colleague, Jay Lepreau: http://www.legacy.com/saltlaketribune/Obituaries.asp?Page=Lifestory&PersonId=117597321 Jay was the one who ported Steve Johnson's Portable C Compiler to the PDP-10 under TOPS-20, as pcc-20, back in the early 1980s. The compiler gave me my first hands-on access to the C language, after having just been able to read about it, and Unix, in research reports and articles by Bell Labs researchers. I'm still writing in C more than 25 years later. Jay went on to a productive career in advanced networking, founding and heading the Flux Research Group in the School of Computing at the University of Utah (in the old days, UTAH-CS.ARPA, one of the five founding institutions behind the Internet [See the figure of the original backbone on p. 49 of Katie Hafner and Matthew Lyon's book, ``Where wizards stay up late: the origins of the Internet'', ISBN 0-684-81201-0 (1996)]). See the Web sites http://www.cs.utah.edu/info/jaylepreau.shtml http://www.cs.utah.edu/flux/ for more about Jay. A scan of my old TOPS-20 archives shows these file dates for PCC-20: % ls -l ps/subsys/pcc/c*.exe -rw-rw---- 1 beebe staff 227836 Jan 16 1988 ps/subsys/pcc/c1.exe -rw-rw---- 1 beebe staff 143356 Mar 26 1983 ps/subsys/pcc/c2.exe -rw-rw---- 1 beebe staff 94715 Jan 13 1986 ps/subsys/pcc/cc.exe -rw-rw---- 1 beebe staff 110074 May 12 1986 ps/subsys/pcc/cpp.exe % ls -ltr ps/subsys/pcc/ | head total 1614 -rw-rw-r-- 1 beebe beebe 721 Mar 17 1981 ctype.h -rw-rw-r-- 1 beebe beebe 375 Mar 18 1981 math.h -rw-rw-r-- 1 beebe beebe 275 Mar 25 1981 Cdefs.unv -rw-rw-r-- 1 beebe beebe 395 Mar 25 1981 Mdefs.unv -rw-rw-r-- 1 beebe beebe 81 Mar 28 1981 lib.ccl -rw-rw-r-- 1 beebe beebe 60716 May 7 1981 monerr.h -rw-rw-r-- 1 beebe beebe 24 May 8 1981 setjmp.h -rw-rw---- 1 beebe beebe 40957 Dec 31 1981 numtab.exe -rw-rw-r-- 1 beebe beebe 19 Jan 9 1982 valign.h The PCC-20 files contain "Copyright (c) 1981 Jay Lepreau", and monerr.h says inside "Created from monsym.mac by J.Lepreau, Univ. of Utah, 4/10/81". The oldest C-related file that I could find is cos/lepreau/cpp/dist/comm1.c dated 17-Nov-1980. Time stamps for Ken Harrenstien's kcc-20 executables in my tree are from April 1988, and the *.doc files are as old as 17-Sep-1986. The oldest C file that I can find that I wrote on our then DEC-20/40, UTAH-SCIENCE.ARPA, is dated 22-Apr-1982, and on 20-May-1983, I last edited ctoftn.mac, a PDP-10 MACRO file whose description comment says: This routine provides for linkage between TOPS-20 C-language programs compiled by the Portable C Compiler (pcc) with FORTRAN programs. The main program MUST be in C, and the FORTRAN programs may not perform I/O (a fatal error is likely if they do). ------------------------------------------------------------------------------- - Nelson H. F. Beebe Tel: +1 801 581 5254 - - University of Utah FAX: +1 801 581 4148 - - Department of Mathematics, 110 LCB Internet e-mail: beebe@math.utah.edu - - 155 S 1400 E RM 233 beebe@acm.org beebe@computer.org - - Salt Lake City, UT 84112-0090, USA URL: http://www.math.utah.edu/~beebe/ - ------------------------------------------------------------------------------- 17-Nov-2008 07:54:28-PST,3454;000000000000 Return-Path: Received: from hsinghsing.panda.com ([206.124.149.116]) by Lingling.Panda.COM with TCP/SMTP; Mon, 17 Nov 2008 07:52:16 -0800 (PST) X-Return-Path: X-Received: from mail1.panix.com ([166.84.1.72]) by Lingling.Panda.COM with TCP/SMTP; Sun, 16 Nov 2008 23:33:05 -0800 (PST) X-Received: from panix5.panix.com (panix5.panix.com [166.84.1.5]) by mail1.panix.com (Postfix) with ESMTP id 31BBC29408 for ; Mon, 17 Nov 2008 02:32:58 -0500 (EST) X-Received: by panix5.panix.com (Postfix, from userid 17662) id 243B824205; Mon, 17 Nov 2008 02:32:58 -0500 (EST) From: Rich Alderson To: tops-20@lingling.panda.com Subject: Building KLH10 under Mac OS X 10.4 Message-Id: <20081117073258.243B824205@panix5.panix.com> Date: Mon, 17 Nov 2008 02:32:58 -0500 (EST) ReSent-Date: Mon, 17 Nov 2008 07:52:08 -0800 (PST) ReSent-From: TOPS-20 List Moderator ReSent-To: TOPS-20 Distribution: ; ReSent-Subject: Building KLH10 under Mac OS X 10.4 ReSent-Message-ID: ReSent-User-Agent: Alpine 2.00 (OSX 1167 2008-08-23) I built the early release of KLH10 under 10.2 a long time ago. Attempting to build the latest bits under 10.4, I get the following: bld/osxppc> setenv KLH10_HOME ~/panda bld/osxppc> cd ../bld/osxppc/ bld/osxppc> make base-kl make kn10-kl dprpxx dptm03 dpni20 wfconv tapedd vdkfmt wxtest uexbconv \ "SRC = ../../src" \ "CC = cc" \ "CFLAGS = -c -g3 -O -I. -I../../src " \ "LDFLAGS = " \ "LIBS = " \ "CENVFLAGS = -DENV_SYS_MACOSX=1 -DCENV_CPU_PPC=1 -DCENV_SYS_FREEBSD=1 -DCENV_CPUF_BIGEND=1" \ "CONFFLAGS = \ -DKLH10_CPU_KLX=1 \ -DKLH10_SYS_T20=1 \ -DKLH10_EVHS_INT=1 \ -DKLH10_DEV_DPNI20=1 \ -DKLH10_DEV_DPTM03=1 \ -DKLH10_DEV_DPRPXX=1 \ -DKLH10_MEM_SHARED=1 \ -DKLH10_RTIME_OSGET=1 \ -DKLH10_ITIME_INTRP=1 \ -DKLH10_CTYIO_INT=1 \ -DKLH10_APRID_SERIALNO=1 \ -DKLH10_CLIENT=\\\"MyKL\\\" \ " cc -c -g3 -O -I. -I../../src -DENV_SYS_MACOSX=1 -DCENV_CPU_PPC=1 -DCENV_SYS_FREEBSD=1 -DCENV_CPUF_BIGEND=1 -DKLH10_CPU_KLX=1 -DKLH10_SYS_T20=1 -DKLH10_EVHS_INT=1 -DKLH10_DEV_DPNI20=1 -DKLH10_DEV_DPTM03=1 -DKLH10_DEV_DPRPXX=1 -DKLH10_MEM_SHARED=1 -DKLH10_RTIME_OSGET=1 -DKLH10_ITIME_INTRP=1 -DKLH10_CTYIO_INT=1 -DKLH10_APRID_SERIALNO=1 -DKLH10_CLIENT=\"MyKL\" ../../src/kn10ops.c ../../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 make[1]: *** [kn10ops.o] Error 1 make: *** [base-kl] Error 2 bld/osxppc> bld/osxppc> cc --version powerpc-apple-darwin8-gcc-4.0.1 (GCC) 4.0.1 (Apple Computer, Inc. build 5250) Copyright (C) 2005 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. Has anyone with real C skills (I'm a Macro-20 programmer, with some skills in Pascal-20) built this on Mac OS X 10.4? Rich Alderson 17-Nov-2008 08:27:31-PST,8002;000000000000 Return-Path: Received: from hsinghsing.panda.com ([206.124.149.116]) by Lingling.Panda.COM with TCP/SMTP; Mon, 17 Nov 2008 08:25:49 -0800 (PST) X-Return-Path: X-Received: from klais.its.uu.se ([130.238.7.59]) by Lingling.Panda.COM with TCP/SMTP; Mon, 17 Nov 2008 08:12:58 -0800 (PST) X-Received: from buzz.it.uu.se (buzz.it.uu.se [130.238.8.225]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by klais.its.uu.se (Postfix) with ESMTP id 8879C382B81; Mon, 17 Nov 2008 17:12:50 +0100 (CET) X-DKIM: Sendmail DKIM Filter v0.6.4 klais.its.uu.se 8879C382B81 DKIM-Signature: v=0.5; a=rsa-sha256; c=simple/simple; d=uu.se; s=centralsmtp; t=1226938370; bh=k74FXcvQdoD7xwo+yeViRUeujplutDnFEE3 a0UVnVCg=; h=Message-ID:Date:From:User-Agent:MIME-Version:To:CC: Subject:References:In-Reply-To:X-Enigmail-Version:Content-Type: X-Virus-Scanned; b=AUlzR+Vsfv5BTBZrqwISk2Xv184iXhA/QXfU3DMLhn/at7q zNjFszXwWsSrzFo/Az82BzDHuTWHRBd8VdpLP8JLfV2z6AW1JVGXnryCtlkS8GD5g6r jcGIoPioywFfuMsrQGsYD6la/kq361i5QYEXn1vakXpySeDeVba+Cx94A= Message-ID: <49219801.30000@it.uu.se> Date: Mon, 17 Nov 2008 17:12:49 +0100 From: =?ISO-8859-1?Q?Bj=F6rn_Victor?= User-Agent: Thunderbird 2.0.0.17 (Macintosh/20080914) MIME-Version: 1.0 To: Rich Alderson CC: tops-20@lingling.panda.com Subject: Re: Building KLH10 under Mac OS X 10.4 References: <20081117073258.243B824205@panix5.panix.com> In-Reply-To: <20081117073258.243B824205@panix5.panix.com> X-Enigmail-Version: 0.95.7 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms060603060101070300070408" X-Virus-Scanned: Debian amavisd-new at klais.its.uu.se ReSent-Date: Mon, 17 Nov 2008 08:25:38 -0800 (PST) ReSent-From: TOPS-20 List Moderator ReSent-To: TOPS-20 Distribution: ; ReSent-Subject: Re: Building KLH10 under Mac OS X 10.4 ReSent-Message-ID: ReSent-User-Agent: Alpine 2.00 (OSX 1167 2008-08-23) This is a cryptographically signed message in MIME format. --------------ms060603060101070300070408 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 2008-11-17 08.32, Rich Alderson wrote: > bld/osxppc> cc --version > powerpc-apple-darwin8-gcc-4.0.1 (GCC) 4.0.1 (Apple Computer, Inc. build= 5250) > Copyright (C) 2005 Free Software Foundation, Inc. > This is free software; see the source for copying conditions. There is= NO > warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURP= OSE. >=20 > Has anyone with real C skills (I'm a Macro-20 programmer, with some ski= lls in > Pascal-20) built this on Mac OS X 10.4? I think it's an issue with gcc 4 rather than Mac OS - my workaround (for gcc) was to remove the "register" declarations, but perhaps there is a flag for gcc to ignore them, or just give warnings rather than errors? -- Bj=F6rn --------------ms060603060101070300070408 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJfTCC AxkwggKCoAMCAQICEE+vatCCcoHGDWcrJIdDo6UwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UE BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA4MDMyMTExMzgyN1oX DTA5MDMyMTExMzgyN1owfDEPMA0GA1UEBBMGVmljdG9yMR0wGwYDVQQqDBRCasO2cm4gSW5n ZW1hciBGcmFuczEkMCIGA1UEAwwbQmrDtnJuIEluZ2VtYXIgRnJhbnMgVmljdG9yMSQwIgYJ KoZIhvcNAQkBFhVCam9ybi5WaWN0b3JAaXQudXUuc2UwggEiMA0GCSqGSIb3DQEBAQUAA4IB DwAwggEKAoIBAQDJRkk/imyJ/Xb8vhL6JvDpOmzfza0syb1t4etZvXcjnySDc3roMb98kF+e A/5ypDn7V7pTPeksGZ8j9JWnVXHSZDX2kpQebfBNdq3Z2H7HfTtSiBzeq0gCf71SZcudOUW8 Fjb8mpzezvAnC+xb1o4ivgiT4trcu8KHaHmSO5rdefTMs8sUgFYmmYxoBbpDdgcKlDF1a4nZ W3RAES9uSilntGT8kDf6F+tcyhBw+MLnvVb9sHWFhDlUgcD77HUFkOxFT0XfoLjAs+t+CCAl bDaC3I4i976ftkZbmwIeaCnvqSRCipLR8ChMiAXwoR73+BkPPWFHOMxraDn+LqjFb3JrAgMB AAGjMjAwMCAGA1UdEQQZMBeBFUJqb3JuLlZpY3RvckBpdC51dS5zZTAMBgNVHRMBAf8EAjAA MA0GCSqGSIb3DQEBBQUAA4GBAE8RlOWiGgNa7rQbFgN/OAD+cFBougf2aR7tjMp3QoqkQLZm 3iPpIsNHCxzRphG2T1OnzCj13j7bZ1ij83/xrZDxSPysGlU7IcaNEJCrAebtYRB6pdjlYMPY 08ETtVMuLVIoSqBFIjFMnko7U6/Vk+QD+h7wNxW0/kWasqBB7o73MIIDGTCCAoKgAwIBAgIQ T69q0IJygcYNZyskh0OjpTANBgkqhkiG9w0BAQUFADBiMQswCQYDVQQGEwJaQTElMCMGA1UE ChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNv bmFsIEZyZWVtYWlsIElzc3VpbmcgQ0EwHhcNMDgwMzIxMTEzODI3WhcNMDkwMzIxMTEzODI3 WjB8MQ8wDQYDVQQEEwZWaWN0b3IxHTAbBgNVBCoMFEJqw7ZybiBJbmdlbWFyIEZyYW5zMSQw IgYDVQQDDBtCasO2cm4gSW5nZW1hciBGcmFucyBWaWN0b3IxJDAiBgkqhkiG9w0BCQEWFUJq b3JuLlZpY3RvckBpdC51dS5zZTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMlG ST+KbIn9dvy+Evom8Ok6bN/NrSzJvW3h61m9dyOfJINzeugxv3yQX54D/nKkOftXulM96SwZ nyP0ladVcdJkNfaSlB5t8E12rdnYfsd9O1KIHN6rSAJ/vVJly505RbwWNvyanN7O8CcL7FvW jiK+CJPi2ty7wodoeZI7mt159MyzyxSAViaZjGgFukN2BwqUMXVridlbdEARL25KKWe0ZPyQ N/oX61zKEHD4wue9Vv2wdYWEOVSBwPvsdQWQ7EVPRd+guMCz634IICVsNoLcjiL3vp+2Rlub Ah5oKe+pJEKKktHwKEyIBfChHvf4GQ89YUc4zGtoOf4uqMVvcmsCAwEAAaMyMDAwIAYDVR0R BBkwF4EVQmpvcm4uVmljdG9yQGl0LnV1LnNlMAwGA1UdEwEB/wQCMAAwDQYJKoZIhvcNAQEF BQADgYEATxGU5aIaA1rutBsWA384AP5wUGi6B/ZpHu2MyndCiqRAtmbeI+kiw0cLHNGmEbZP U6fMKPXePttnWKPzf/GtkPFI/KwaVTshxo0QkKsB5u1hEHql2OVgw9jTwRO1Uy4tUihKoEUi MUyeSjtTr9WT5AP6HvA3FbT+RZqyoEHujvcwggM/MIICqKADAgECAgENMA0GCSqGSIb3DQEB BQUAMIHRMQswCQYDVQQGEwJaQTEVMBMGA1UECBMMV2VzdGVybiBDYXBlMRIwEAYDVQQHEwlD YXBlIFRvd24xGjAYBgNVBAoTEVRoYXd0ZSBDb25zdWx0aW5nMSgwJgYDVQQLEx9DZXJ0aWZp Y2F0aW9uIFNlcnZpY2VzIERpdmlzaW9uMSQwIgYDVQQDExtUaGF3dGUgUGVyc29uYWwgRnJl ZW1haWwgQ0ExKzApBgkqhkiG9w0BCQEWHHBlcnNvbmFsLWZyZWVtYWlsQHRoYXd0ZS5jb20w HhcNMDMwNzE3MDAwMDAwWhcNMTMwNzE2MjM1OTU5WjBiMQswCQYDVQQGEwJaQTElMCMGA1UE ChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNv bmFsIEZyZWVtYWlsIElzc3VpbmcgQ0EwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAMSm PFVzVftOucqZWh5owHUEcJ3f6f+jHuy9zfVb8hp2vX8MOmHyv1HOAdTlUAow1wJjWiyJFXCO 3cnwK4Vaqj9xVsuvPAsH5/EfkTYkKhPPK9Xzgnc9A74r/rsYPge/QIACZNenprufZdHFKlSF D0gEf6e20TxhBEAeZBlyYLf7AgMBAAGjgZQwgZEwEgYDVR0TAQH/BAgwBgEB/wIBADBDBgNV HR8EPDA6MDigNqA0hjJodHRwOi8vY3JsLnRoYXd0ZS5jb20vVGhhd3RlUGVyc29uYWxGcmVl bWFpbENBLmNybDALBgNVHQ8EBAMCAQYwKQYDVR0RBCIwIKQeMBwxGjAYBgNVBAMTEVByaXZh dGVMYWJlbDItMTM4MA0GCSqGSIb3DQEBBQUAA4GBAEiM0VCD6gsuzA2jZqxnD3+vrL7CF6FD lpSdf0whuPg2H6otnzYvwPQcUCCTcDz9reFhYsPZOhl+hLGZGwDFGguCdJ4lUJRix9sncVcl jd2pnDmOjCBPZV+V2vf3h9bGCE6u9uo05RAaWzVNd+NWIXiC3CEZNd4ksdMdRv9dX2VPMYID ZDCCA2ACAQEwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcg KFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3Vpbmcg Q0ECEE+vatCCcoHGDWcrJIdDo6UwCQYFKw4DAhoFAKCCAcMwGAYJKoZIhvcNAQkDMQsGCSqG SIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDgxMTE3MTYxMjQ5WjAjBgkqhkiG9w0BCQQxFgQU jDAr5i2BgBbRv00oEjr53Yn4E+owUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggq hkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgYUG CSsGAQQBgjcQBDF4MHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0 aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1 aW5nIENBAhBPr2rQgnKBxg1nKySHQ6OlMIGHBgsqhkiG9w0BCRACCzF4oHYwYjELMAkGA1UE BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhBPr2rQgnKBxg1nKySHQ6Ol MA0GCSqGSIb3DQEBAQUABIIBAFb/1pSkOONy0ZQ4o1pMFYcADiAXg3ugratwOoBI81iBPaEx Ajdz7StiAz8MyaXV+K0FL6ceAc8+I2SYWgkCj18MrHFDViS2voBqzmrrfEkTOw9y7KNCUecx Hn56vJZBD7KN6vpRKriTGqrL9I3pUem5++ieqo5EGurMI8Y2DX/2t7+IUeDSA0q4Jz5g/vJi mmCLZCAKeikicG12C9rPkmHSILlxuEOQL8L7101oTmf2CDgmjNSTj6C1OolrWDp5/em58sxD mDvM0u4IAAEcDt/PWfT4xtQ7SyRk1Nhd85h6FLrKT14Wqn9beKIfoK/vxeAIHthaakLrbJq4 kC5i7msAAAAAAAA= --------------ms060603060101070300070408-- 17-Nov-2008 08:28:59-PST,2181;000000000000 Return-Path: Received: from hsinghsing.panda.com ([206.124.149.116]) by Lingling.Panda.COM with TCP/SMTP; Mon, 17 Nov 2008 08:26:30 -0800 (PST) X-Return-Path: X-Received: from a.mail.sonic.net ([64.142.16.245]) by Lingling.Panda.COM with TCP/SMTP; Mon, 17 Nov 2008 08:15:24 -0800 (PST) X-Received: from Amiga.local (64-142-29-114.dsl.static.sonic.net [64.142.29.114]) by a.mail.sonic.net (8.13.8.Beta0-Sonic/8.13.7) with ESMTP id mAHGFInR024711 for ; Mon, 17 Nov 2008 08:15:18 -0800 Date: Mon, 17 Nov 2008 08:15:17 -0800 (PST) From: Fred Wright X-Sender: fw@Amiga.local Reply-To: Fred Wright To: tops-20@Lingling.Panda.COM Subject: Re: Building KLH10 under Mac OS X 10.4 In-Reply-To: <20081117073258.243B824205@panix5.panix.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII ReSent-Date: Mon, 17 Nov 2008 08:26:17 -0800 (PST) ReSent-From: TOPS-20 List Moderator ReSent-To: TOPS-20 Distribution: ; ReSent-Subject: Re: Building KLH10 under Mac OS X 10.4 ReSent-Message-ID: ReSent-User-Agent: Alpine 2.00 (OSX 1167 2008-08-23) On Mon, 17 Nov 2008, Rich Alderson wrote: > I built the early release of KLH10 under 10.2 a long time ago. > > Attempting to build the latest bits under 10.4, I get the following: [...] > ../../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 > make[1]: *** [kn10ops.o] Error 1 > make: *** [base-kl] Error 2 [...] Remove the "register" qualifier from the declaration. GCC4 is more pedantic about the "you can't take a pointer to a register variable" rule. Of course it might not occur to a PDP-10 programmer that there's anything wrong with taking a pointer to a register. :-) Fred Wright 17-Nov-2008 09:19:06-PST,2315;000000000000 Return-Path: Received: from hsinghsing.panda.com ([206.124.149.116]) by Lingling.Panda.COM with TCP/SMTP; Mon, 17 Nov 2008 09:17:21 -0800 (PST) X-Return-Path: X-Received: from hsinghsing.panda.com ([206.124.149.116]) by Lingling.Panda.COM with TCP/SMTP; Mon, 17 Nov 2008 08:42:30 -0800 (PST) Date: Mon, 17 Nov 2008 08:42:23 -0800 (PST) From: Mark Crispin Sender: mrc@hsinghsing.panda.com To: Fred Wright cc: tops-20@Lingling.Panda.COM Subject: Re: Building KLH10 under Mac OS X 10.4 In-Reply-To: Message-ID: References: User-Agent: Alpine 2.00 (OSX 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed ReSent-Date: Mon, 17 Nov 2008 09:17:12 -0800 (PST) ReSent-From: TOPS-20 List Moderator ReSent-To: TOPS-20 Distribution: ; ReSent-Subject: Re: Building KLH10 under Mac OS X 10.4 ReSent-Message-ID: ReSent-User-Agent: Alpine 2.00 (OSX 1167 2008-08-23) On Mon, 17 Nov 2008, Fred Wright wrote: > Remove the "register" qualifier from the declaration. GCC4 is more > pedantic about the "you can't take a pointer to a register variable" rule. > Of course it might not occur to a PDP-10 programmer that there's anything > wrong with taking a pointer to a register. :-) As KLH points out, K&R implies that if you can't do it, the "register" qualifier is just ignored. The rule is a so-called "bug fix" that ANSI made to their definition of C. There are several of these ANSI "bug fixes" that fall under the category of "we don't understand why this is useful, so we will just ban it" or "it will be difficult to implement this in my compiler, so I want it banned." I guess that this is the normal evolution of designs. The once clean design gets layered with increasingly dubious "bug fixes" and "features"; and the very worst are the ones to protect baby programmers from themselves. -- Mark -- http://panda.com/tops-20 TOPS-20: a great improvement over its successors 10-Dec-2008 21:17:30-PST,1621;000000000000 Return-Path: Received: from hsinghsing.panda.com ([206.124.149.116]) by Lingling.Panda.COM with TCP/SMTP; Wed, 10 Dec 2008 21:15:14 -0800 (PST) X-Return-Path: X-Received: from asmtpout016.mac.com ([17.148.16.91]) by Lingling.Panda.COM with TCP/SMTP; Wed, 10 Dec 2008 20:56:21 -0800 (PST) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=US-ASCII; format=flowed; delsp=yes X-Received: from [192.168.1.52] (c-24-61-92-169.hsd1.nh.comcast.net [24.61.92.169]) by asmtp016.mac.com (Sun Java(tm) System Messaging Server 6.3-7.03 (built Aug 7 2008; 32bit)) with ESMTPSA id <0KBP003NT4DD8D30@asmtp016.mac.com> for tops-20@lingling.panda.com; Wed, 10 Dec 2008 20:56:12 -0800 (PST) Message-id: From: John Francini To: Tops-20 Wizards In-reply-to: <49219801.30000@it.uu.se> Subject: Happy DEC-10 Day! Date: Wed, 10 Dec 2008 23:55:59 -0500 References: <20081117073258.243B824205@panix5.panix.com> <49219801.30000@it.uu.se> X-Mailer: Apple Mail (2.929.2) ReSent-Date: Wed, 10 Dec 2008 21:15:04 -0800 (PST) ReSent-From: TOPS-20 List Moderator ReSent-To: TOPS-20 Distribution: ; ReSent-Subject: Happy DEC-10 Day! ReSent-Message-ID: ReSent-User-Agent: Alpine 2.00 (OSX 1167 2008-08-23) Had no chance to get to my e-mail until now, but a happy DEC-10 day to all of those who fondly remember the "other" OS on the PDP-10! John Francini 10-Dec-2008 21:53:11-PST,2271;000000000000 Return-Path: Received: from hsinghsing.panda.com ([206.124.149.116]) by Lingling.Panda.COM with TCP/SMTP; Wed, 10 Dec 2008 21:51:33 -0800 (PST) X-Return-Path: X-Received: from QMTA01.westchester.pa.mail.comcast.net ([76.96.62.16]) by Lingling.Panda.COM with TCP/SMTP; Wed, 10 Dec 2008 21:41:10 -0800 (PST) X-Received: from OMTA11.westchester.pa.mail.comcast.net ([76.96.62.36]) by QMTA01.westchester.pa.mail.comcast.net with comcast id pV4x1a01s0mv7h051hh3iG; Thu, 11 Dec 2008 05:41:03 +0000 X-Received: from [10.0.1.2] ([24.62.230.208]) by OMTA11.westchester.pa.mail.comcast.net with comcast id phh11a0024WRhhk3Xhh1g5; Thu, 11 Dec 2008 05:41:03 +0000 Mime-Version: 1.0 Message-Id: In-Reply-To: References: <20081117073258.243B824205@panix5.panix.com> <49219801.30000@it.uu.se> Date: Thu, 11 Dec 2008 00:41:00 -0500 To: John Francini , Tops-20 Wizards From: Paul Wexelblat Subject: Re: Happy DEC-10 Day! Content-Type: text/plain; charset="us-ascii" ReSent-Date: Wed, 10 Dec 2008 21:51:05 -0800 (PST) ReSent-From: TOPS-20 List Moderator ReSent-To: TOPS-20 Distribution: ; ReSent-Subject: Re: Happy DEC-10 Day! ReSent-Message-ID: ReSent-User-Agent: Alpine 2.00 (OSX 1167 2008-08-23) At 11:55 PM -0500 12/10/08, John Francini wrote: >Had no chance to get to my e-mail until now, but a happy DEC-10 day to all of those who fondly remember the "other" OS on the PDP-10! > >John Francini Well, I've got code in a few of them TOPS-10 (Mostly SCNCER and ANF-10, PMW on the listings) (Marlboro) TOPS-20 IPCF code for TOPS-10 & TOPS-20 (also Marlboro) Tenex (whilst at BBN - before Marlboro) and "The Compatability Package" TOPS-10/Tenex (also at BBN) KA's, KI's and KL's Started as a user with Level C/D (on DECtape distribution for the BBN KA's) -- P.M. Wexelblat PhD Erst of the Dept. of Computer Science University of Massachusetts Lowell One University Ave Lowell, MA 01854 10-Dec-2008 23:20:14-PST,3892;000000000000 Return-Path: Received: from hsinghsing.panda.com ([206.124.149.116]) by Lingling.Panda.COM with TCP/SMTP; Wed, 10 Dec 2008 23:18:22 -0800 (PST) X-Return-Path: X-Received: from smtp122.sbc.mail.sp1.yahoo.com ([69.147.64.95]) by Lingling.Panda.COM with TCP/SMTP; Wed, 10 Dec 2008 23:13:24 -0800 (PST) X-Received: (qmail 37754 invoked from network); 11 Dec 2008 07:13:18 -0000 X-Received: from unknown (HELO ?204.238.239.101?) (carl@71.141.100.109 with plain) by smtp122.sbc.mail.sp1.yahoo.com with SMTP; 11 Dec 2008 07:13:18 -0000 X-YMail-OSG: qP.OP44VM1kdsB2p7oi4R28G_cIXLlnu1AFZJ9OirBc12lnyXLhjhEK2uaNGNb2inXTdcDpklxgdDpqoTh2P_cbtY7zhReRwWNu1EVXpmojXFStm_xiWGGBM5CxA9oOnvzw- X-Yahoo-Newman-Property: ymail-3 In-Reply-To: References: <20081117073258.243B824205@panix5.panix.com> <49219801.30000@it.uu.se> Mime-Version: 1.0 (Apple Message framework v624) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <50131d65354b6c190cc2391491bf03df@reststop.com> Content-Transfer-Encoding: 7bit Cc: John Francini , Tops-20 Wizards X-Image-Url: http://www.goldenstategiftbaskets.com/minibasket.jpg From: Carl Baltrunas Subject: Re: Happy DEC-10 Day! Date: Wed, 10 Dec 2008 23:13:15 -0800 To: Paul Wexelblat X-Mailer: Apple Mail (2.624) ReSent-Date: Wed, 10 Dec 2008 23:18:14 -0800 (PST) ReSent-From: TOPS-20 List Moderator ReSent-To: TOPS-20 Distribution: ; ReSent-Subject: Re: Happy DEC-10 Day! ReSent-Message-ID: ReSent-User-Agent: Alpine 2.00 (OSX 1167 2008-08-23) I can't say I have code in all of them, but can say that I've worked on most of them, logged into my own accounts or watched others on just about all of them. Mostly private mods at CUA & Gallaudet, and lots of things in TYMCOM-X at Tymshare. TOPS-10 5.03C through 6.03A at Catholic University & Gallaudet College '72-'80, 7.01 @ U of A for a month in '80 ITS on MIT-AI/ML/MC no idea what versions, access via MITRE-TIP '74-'80; '81-?? via Office-11 TYMCOM-X/XX '80-'96 at Tymshare and subsequent companies that bought us, e.g. MCI '94-'96 TENEX at Tymshare on Office-11 TOPS-20 at Tymshare, briefly in '83-'84, again at MCI in '96-'98 on TOAD-1, '99-present on TOAD-1 in my garage WAITS-10 at SAIL (watched over shoulders on tour of AI Lab visiting Brian Harvey after DECUS '78) TOPS-20 at LOTS (watched over shoulders on tour of LOTS visiting JSOL, possibly same trip '78, or later in '80) also worked on PDP-11, aka DEC-11 :-) tomorrow RSTS/E '73 RT-11 '74-'80 RSX-11 '76-'80 and hacked several stand-alone programs for the GT-40 (PDP-11/05 w/ VR-14 or VR-17 display) '74-'80 Started with 5.03C at CUA. Tymshare's TYMCOM-X split from TOPS-10 at 5.02, so went full circle :-) On Dec 10, 2008, at 9:41 PM, Paul Wexelblat wrote: > At 11:55 PM -0500 12/10/08, John Francini wrote: >> Had no chance to get to my e-mail until now, but a happy DEC-10 day >> to all of those who fondly remember the "other" OS on the PDP-10! >> >> John Francini > > Well, I've got code in a few of them > > TOPS-10 (Mostly SCNCER and ANF-10, PMW on the listings) (Marlboro) > TOPS-20 IPCF code for TOPS-10 & TOPS-20 (also Marlboro) > Tenex (whilst at BBN - before Marlboro) > and "The Compatability Package" TOPS-10/Tenex (also at BBN) > > KA's, KI's and KL's > > Started as a user with Level C/D (on DECtape distribution for the BBN > KA's) > > -- > P.M. Wexelblat PhD > Erst of the Dept. of Computer Science > University of Massachusetts Lowell > One University Ave > Lowell, MA 01854 > 20-Dec-2008 12:26:18-PST,1397;000000000000 Return-Path: Received: from hsinghsing.panda.com ([206.124.149.116]) by Lingling.Panda.COM with TCP/SMTP; Sat, 20 Dec 2008 12:24:30 -0800 (PST) X-Return-Path: X-Received: from hsinghsing.panda.com ([206.124.149.116]) by Lingling.Panda.COM with TCP/SMTP; Sat, 20 Dec 2008 12:23:05 -0800 (PST) Date: Sat, 20 Dec 2008 12:23:00 -0800 (PST) From: Mark Crispin Sender: mrc@hsinghsing.panda.com To: TOPS-20 Hackers and Yackers Subject: Happy DEC-20 day! Message-ID: User-Agent: Alpine 2.00 (OSX 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII ReSent-Date: Sat, 20 Dec 2008 12:24:19 -0800 (PST) ReSent-From: TOPS-20 List Moderator ReSent-To: TOPS-20 Distribution: ; ReSent-Subject: Happy DEC-20 day! ReSent-Message-ID: ReSent-User-Agent: Alpine 2.00 (OSX 1167 2008-08-23) Since nobody else has done the honors yet, I will. Best to everybody in this year where we celebrate 44 years of 36-bits and (by my reckoning) 32 years of the DECSYSTEM-20 (I think that first customer ships were in 1976). -- Mark -- http://panda.com/tops-20 TOPS-20: a great improvement over its successors 20-Dec-2008 14:40:20-PST,911;000000000000 Return-Path: Received: from hsinghsing.panda.com ([206.124.149.116]) by Lingling.Panda.COM with TCP/SMTP; Sat, 20 Dec 2008 14:38:42 -0800 (PST) X-Return-Path: X-Received: from xkleten.paulallen.com ([216.220.195.10]) by Lingling.Panda.COM with TCP/SMTP; Sat, 20 Dec 2008 12:40:34 -0800 (PST) Date: Sat, 20 Dec 2008 12:35:11 -0800 From: JSol Subject: happy dec-20 day.. To: tops-20@LINGLING.PANDA.COM Message-ID: <14370958937.9.JSOL@xkleten.paulallen.com> ReSent-Date: Sat, 20 Dec 2008 14:38:34 -0800 (PST) ReSent-From: TOPS-20 List Moderator ReSent-To: TOPS-20 Distribution: ; ReSent-Subject: happy dec-20 day.. ReSent-Message-ID: ReSent-User-Agent: Alpine 2.00 (OSX 1167 2008-08-23) I agree. Happy DEC-20 day!!! ------- 20-Dec-2008 18:09:39-PST,3536;000000000000 Return-Path: Received: from hsinghsing.panda.com ([206.124.149.116]) by Lingling.Panda.COM with TCP/SMTP; Sat, 20 Dec 2008 18:07:57 -0800 (PST) X-Return-Path: X-Received: from vms173001pub.verizon.net ([206.46.173.1]) by Lingling.Panda.COM with TCP/SMTP; Sat, 20 Dec 2008 17:16:25 -0800 (PST) X-Received: from bob-smiths-computer.local ([96.231.203.19]) by vms173001.mailsrvcs.net (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPA id <0KC700EFBCV1FLH6@vms173001.mailsrvcs.net>; Sat, 20 Dec 2008 19:16:14 -0600 (CST) Date: Sat, 20 Dec 2008 20:16:14 -0500 From: bob smith Subject: Re: Happy DEC-20 day! In-reply-to: To: Mark Crispin Cc: TOPS-20 Hackers and Yackers Reply-to: Bob Message-id: <494D98DE.8030102@verizon.net> MIME-version: 1.0 Content-type: multipart/alternative; boundary=------------030309090503030702070805 References: User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.1.18) Gecko/20081031 SeaMonkey/1.1.13 ReSent-Date: Sat, 20 Dec 2008 18:07:48 -0800 (PST) ReSent-From: TOPS-20 List Moderator ReSent-To: TOPS-20 Distribution: ; ReSent-Subject: Re: Happy DEC-20 day! ReSent-Message-ID: ReSent-User-Agent: Alpine 2.00 (OSX 1167 2008-08-23) This is a multi-part message in MIME format. --------------030309090503030702070805 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Mark Crispin wrote: > Since nobody else has done the honors yet, I will. > > Best to everybody in this year where we celebrate 44 years of 36-bits > and (by my reckoning) 32 years of the DECSYSTEM-20 (I think that first > customer ships were in 1976). > > -- Mark -- > > http://panda.com/tops-20 > TOPS-20: a great improvement over its successors > > same back to you! and to everyone! bob -- =============================================== Command Line Interface - the only way to feel like you control the computer. --------------030309090503030702070805 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Mark Crispin wrote:
Since nobody else has done the honors yet, I will.

Best to everybody in this year where we celebrate 44 years of 36-bits and (by my reckoning) 32 years of the DECSYSTEM-20 (I think that first customer ships were in 1976).

-- Mark --

http://panda.com/tops-20
TOPS-20: a great improvement over its successors


same back to you! and to everyone!
bob

-- 
===============================================
Command Line Interface - the only way to feel like you control the computer.
--------------030309090503030702070805-- 21-Dec-2008 21:55:57-PST,1220;000000000000 Return-Path: Received: from hsinghsing.panda.com ([206.124.149.116]) by Lingling.Panda.COM with TCP/SMTP; Sun, 21 Dec 2008 21:54:17 -0800 (PST) X-Return-Path: X-Received: from xkleten.paulallen.com ([216.220.195.10]) by Lingling.Panda.COM with TCP/SMTP; Sun, 21 Dec 2008 19:51:42 -0800 (PST) Date: Sun, 21 Dec 2008 19:46:17 -0800 From: JSol Subject: batch and mm.... To: tops-20@lingling.panda.com Message-ID: <14371299562.10.JSOL@xkleten.paulallen.com> ReSent-Date: Sun, 21 Dec 2008 21:54:08 -0800 (PST) ReSent-From: TOPS-20 List Moderator ReSent-To: TOPS-20 Distribution: ; ReSent-Subject: batch and mm.... ReSent-Message-ID: ReSent-User-Agent: Alpine 2.00 (OSX 1167 2008-08-23) checkout [xkleten.paulallen.com]mm.ctl. e-mail from a do file works, but submitting a batch job doesn't deliver and no notice is sent sayinug the mail has been refused or whatever. mm.log is telling me the mail got queued, but I couldn't find anything (some of the tops-20 sites don't support mmailr.log in mail: --jsol ------- 21-Dec-2008 22:37:27-PST,1753;000000000000 Return-Path: Received: from hsinghsing.panda.com ([206.124.149.116]) by Lingling.Panda.COM with TCP/SMTP; Sun, 21 Dec 2008 22:35:57 -0800 (PST) X-Return-Path: X-Received: from hsinghsing.panda.com ([206.124.149.116]) by Lingling.Panda.COM with TCP/SMTP; Sun, 21 Dec 2008 22:32:39 -0800 (PST) Date: Sun, 21 Dec 2008 22:31:54 -0800 (PST) From: Mark Crispin Sender: mrc@hsinghsing.panda.com To: JSol cc: tops-20@lingling.panda.com Subject: Re: batch and mm.... In-Reply-To: <14371299562.10.JSOL@xkleten.paulallen.com> Message-ID: References: <14371299562.10.JSOL@xkleten.paulallen.com> User-Agent: Alpine 2.00 (OSX 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII ReSent-Date: Sun, 21 Dec 2008 22:35:48 -0800 (PST) ReSent-From: TOPS-20 List Moderator ReSent-To: TOPS-20 Distribution: ; ReSent-Subject: Re: batch and mm.... ReSent-Message-ID: ReSent-User-Agent: Alpine 2.00 (OSX 1167 2008-08-23) On Sun, 21 Dec 2008, JSol wrote: > mm.log is telling me the mail got queued, but I couldn't > find anything (some of the tops-20 sites don't support mmailr.log > in mail: If it says mail queued then it wrote the queue file. I also verified in a test that it mailing from a batch file works. I think the problem with your file is with Cingular. I haven't had email/SMS working right for me to my AT&T mobile phone for about 2 weeks now. -- Mark -- http://panda.com/tops-20 TOPS-20: a great improvement over its successors