From KEN Fri Aug 29 00:00:00 1980 From: KEN (Kenneth Kahn) Date: 29 AUG 1980, 00:00 Subject: really a dftp problem but bug-dftp is broken Message-ID: I sent the following message and recieved this COMSAT at MIT-AI 08/29/80 22:50:12 Re: Msg of Friday, 29 August 1980 22:50-EDT Subject: Msg of Friday, 29 August 1980 22:50-EDT A copy of your message is being returned, because: "DFTP-HACKERS" at MIT-AI is an unknown recipient. Message not sent. Failed message follows: ------- KEN at MIT-AI 08/29/80 22:50:07 It seems my directory on the data computer has disappeared. When I :dftp I get dftp.guest rather than dftp.its.ken ... Can it be restored or at least long enough for a tape dump of my files? Could my question please be forwarded to whoever is hacking dftp these days? From MOON at MIT-MC Fri Aug 29 00:00:00 1980 From: MOON at MIT-MC (MOON at MIT-MC) Date: 29 Aug 1980 00:00 Subject: Allocated devices Message-ID: Pnn: and Dnn: as devices work unless they have been "allocated" to the SECOND:, THIRD:, VISION: sort of pack. I don't know whether this is alleged to be a feature or a bug; I can't see any good that derives from it. It's because of the way the file system works on DM, which has actual reserved packs. Actually it could be fixed but it's random to use the numbers rather than the names. Slightly more serious is that there is no way (as far as I know) of knowing what allocated devices there are (in particular .GETSYS knows nothing about them) or what the mapping between pack numbers and allocated devices is. The :DSKUSE # command should print this information, but doesn't currently. There is also no way of telling what directories are allocated to what packs for the allocated directory scheme. The :DSKUSE dirname command prints this information. From PDL Thu Aug 28 00:00:00 1980 From: PDL (P. David Lebling) Date: 28 Aug 1980, 00:00 Subject: [Re: Allocated devices] In-Reply-To: Message of 28 Aug 80 at 0013 EDT by ED@MIT-AI Message-ID: <[MIT-DMS].159324> In fact, DSKUSE does almost everything you are asking for; it will tell what packs are allocated, pack each allocated directory is on, and so on. It doesn't know much about the named pack hack, as this is fairly new, but maybe if I find some time... Dave From ED Thu Aug 28 00:00:00 1980 From: ED (Ed Schwalenberg) Date: 28 AUG 1980, 00:00 Subject: Allocated devices Message-ID: Pnn: and Dnn: as devices work unless they have been "allocated" to the SECOND:, THIRD:, VISION: sort of pack. I don't know whether this is alleged to be a feature or a bug; I can't see any good that derives from it. Slightly more serious is that there is no way (as far as I know) of knowing what allocated devices there are (in particular .GETSYS knows nothing about them) or what the mapping between pack numbers and allocated devices is. There is also no way of telling what directories are allocated to what packs for the allocated directory scheme. I don't think that anybody is being actively screwed by this, but it would be tasteful if a program could find out about such things without experimenting or sending mail to Moon. From RMS Wed Aug 27 00:00:00 1980 From: RMS (Richard M. Stallman) Date: 27 AUG 1980, 00:00 Subject: No subject Message-ID: The device name P15: works for reading but gets Device not Available for writing (from :COPY). From TAA Wed Aug 20 00:00:00 1980 From: TAA (Timothy A. Anderson) Date: 20 Aug 1980, 00:00 Subject: [Re: BUG => ITS] In-Reply-To: <[MIT-DMS].158301> Message-ID: <[MIT-DMS].158305> If the problem with .BATCH;NBATCH BAD was caused by a disk crash, which seems likely, it (shiver) was never reported by the salvager. Could this happen if the file it's sharing with were deleted before the system crashed? -taa From SWG Wed Aug 20 00:00:00 1980 From: SWG (S. W. Galley) Date: 20 Aug 1980, 00:00 Subject: BUG => ITS Message-ID: <[MIT-DMS].158301> The file DM:.BATCH;NBATCH BAD is supposed to have the same contents as DM:.BATCH;NBATCH SAVE, but words 166000-167777 have ASCII text from some other file in them. Could this be from some disk crash since February? From RWK0 at MIT-MC Wed Aug 13 00:00:00 1980 From: RWK0 at MIT-MC (RWK0 at MIT-MC) Date: 13 Aug 1980 00:00 Subject: CNSSET/TCMXV bug Message-ID: When BDG sets his vertical screen size down to 1, ITS crashes at TYOAS7+3 because his cursor position is larger than his screen height. It died when DDT had the TTY, with his DDT at a .CALL CNSGET. It had of course recently done a ^PA. Probably .CALL CNSSET (which he had been playing with in a program of his) should not allow you to set the size below 2 in either dimension... I did not dump this because I wanted to get my buffer back. I hope I got enough info for you to figure out what happened anyway. From RWK at MIT-MC Tue Aug 5 00:00:00 1980 From: RWK at MIT-MC (RWK at MIT-MC) Date: 05 Aug 1980 00:00 Subject: No subject Message-ID: Both FINGER and SUPDUP, when going via CHAOS, are saying: ? Internal error - ISE0 There is no problem, when via ARPA From MOON at MIT-MC Fri Aug 1 00:00:00 1980 From: MOON at MIT-MC (MOON at MIT-MC) Date: 01 Aug 1980 00:00 Subject: rubout problem Message-ID: Perhaps DDT and other programs should be using ECHOIN to solve the rubout problem (where ABDCD echoes as ABDC instead of ABCD). If the rubout problem is the only reason why :MAIL doesn't use PI echoing, then maybe it should use it too. Unfortunately ECHOIN is rather difficult to use. I designed a scheme which would not require any changes to user programs but I don't have nearly enough time to implement it. The basic idea is that when a non-echoing character is typed the system defers echoing, and re-enables it when the next echoing character is read by the program (in the meantime the program may have typed out, for instance to echo erasure for a rubout). This wouldn't be too hard but the refinement to it is to go ahead and echo additional characters so you can see what you're typing, but if the program types anything out erase that echoage and do it again, which is too hard to do right now. I don't suppose there are any competent volunteers? From EAKatMIT-MC Fri Aug 1 00:00:00 1980 From: EAKatMIT-MC (Earl A. Killian) Date: 1 August 1980, 00:00 Subject: rubout problem Message-ID: Perhaps DDT and other programs should be using ECHOIN to solve the rubout problem (where ABDCD echoes as ABDC instead of ABCD). If the rubout problem is the only reason why :MAIL doesn't use PI echoing, then maybe it should use it too.