Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!tut.cis.ohio-state.edu!ucbvax!WSMR-SIMTEL20.ARMY.MIL!MRC From: MRC@WSMR-SIMTEL20.ARMY.MIL (Mark Crispin) Newsgroups: comp.binaries.ibm.pc.d Subject: re: Tenex mode Message-ID: Date: 28 May 89 22:01:53 GMT References: Sender: daemon@ucbvax.BERKELEY.EDU Lines: 91 Earl - Speaking as one of many individuals who have used the PDP-10 computer (which is what TOPS-20 runs on) for *decades*, I can assure you that there are excellent reasons why we are fond of the hardware and software architecture. There is a reason why, for example, the Japanese use TOPS-20 systems as a central facility in their AI and 5th Generation labs. It is not for price or performance reasons!!! The people who throw bricks at TOPS-20 are either irrational or merely don't know. Since I know you from Usenet, I have reason to believe you're in the latter category. I'm going to try to enlighten you, and perhaps help you in getting the situation improved at your end. The basic problem is in the FTP protocol itself. An FTP server is a slave to the instructions of the FTP client. In your case, the FTP server is running on a DEC-20 and your FTP client is an old version of the Unix client. FTP's default is ASCII. This means that on the network the data is a stream of 7-bit characters in 8-bit bytes, with new lines indicated by a carriage return character followed by a line feed character. On Unix, this requires the replacement of a Unix new line character with the carriage return/line feed pair. On the DEC-20, this involves unpacking successive 7-bit bytes from 36-bit words, 5 bytes per word. [Yes, one bit is wasted every 5 characters on the DEC-20, but on Unix one bit is wasted each character. C'est la vie]. Image mode means data from the file as a bitstream taken 8 bits at a time with no character substitution. On an 8-bit byte based machine (such as most but by no means not all Unix systems!) this means a byte-by-byte transfer of data. On the DEC-20, this means taking four 8-bit bytes from the high order 32-bits of a word, a byte from the low order 4-bits of that word and the high-order 4 bits of the next word, and four 8-bit bytes from the low order 32-bits of that next word -- for a total of 9 bytes per pair of words. This would be fine and good, except that this is an unnatural way to store 8-bit data on the DEC-20. A more natural form is to store it as 4 8-bit bytes per word, in the high order 32-bits of each word. SIMTEL20 stores its data in that format, which "wastes" 4 bits but is significantly easier to deal with (since you can easily grab 32-bit quantities). The "tenex" command to the Unix FTP client tells the server to use "your local 8-bit image type" as opposed to "binary type". This, in itself, isn't objectionable. In fact, there is no reason why Unix FTP servers can't implement the exact same binary mode as an alias for image mode. They should if they don't -- then you'd only have a single command to memorize. So much for different data modes. As long as you accept the idea that some computers may want to use other data formats than a stream of 8-bit bytes you have to accept the idea of data format conversion. It's a shame that Unix has promulgated 8-bit thinking -- we are in serious danger of becoming wedged in that mode. It certainly does not give us any growth for the future. Japan uses a 14-bit character set. Some people think that successive powers of two are the way to go, keeping the basic structure of 8-bit bytes. The problem is, some computers store bytes in backwards order (e.g. VAX) while most computers (even the PDP-10/DEC-20) stores bytes in forwards order. If you take 32-bit data from one machine -- even one Unix -- to another you often have to have the bytes of binary data swapped!!!!! Now, to turn to your problem. You have a very old version of the Unix FTP client. Modern versions will automatically switch from "local 8" (the so-called "Tenex" type) to "ASCII" when doing a directory command. Alas, the server is *forbidden* by the protocol from unilaterally doing this. If the FTP client says "give me a directory in local 8 mode" the server really has no idea of what to do. We *could* make the server pretend it is in ASCII mode and *perhaps* your client will work, but there is no guarantee that it will -- or, that if we make it work for you that it would work for someone else (perhaps on a machine whose bytes are swapped from yours). So, whenever possible, we encourage users who have this problem to get on your system programmers' case until they update your FTP software. I guess another way of putting it is -- we are following the FTP protocol as it is set out. We don't like it, and we agree it is stupid at times. We are, however, quite afraid of deliberately introducing a violation at our end to compensate for a violation at another end -- even a common violation -- since it may cause problems down the line. If I can assist you in locating a better version of Unix FTP, please let me know. I for one would not tolerate such a broken Unix FTP on *my* Unix workstation (a NeXT). On a side note, if you've had performance problems in getting to SIMTEL20, that is not the fault of the operating system but rather of the network topology in which SIMTEL20 lives. That *is* being worked on. -- Mark -- Systems Programmer, SIMTEL20 -------