WANCHO@SIMTEL20.ARPA ("Frank J. Wancho") (06/08/88)
Bob, There still is a definite need for TYPE L <bytesize>, in particular, TYPE L 8, TYPE L 32, and TYPE L 36. Most important is TYPE L 8 because it is the only way to correctly transfer our 8-bit binary files to a non-PDP10 host. It would be short-sighted to assume transfers of 8-bit binary data even between hosts of the same word length would be correct using TYPE IMAGE or TYPE L nn as the byte order within the word may not be the same. Similar cases can be made to be able to specify other possible bytesizes. --Frank
braden@VENERA.ISI.EDU (06/08/88)
Frank, I must admit I never thought about byte order. Are there actually any FTP's for little-endian machines that would send "swapped" bytes, ie, not in byte order but in halfword or word order for those machines?? Bob Braden
ado@VAX.BBN.COM (Buz Owen) (06/08/88)
In addition to being useful with 36 bit pdp10 and related machines, local byte size 8 is useful with the BBN C/70, which has a 20 bit word and a 10 bit byte size. While a discussion of choices of reasonable machine word sizes, and important or unimportant machine architectures would be inappropriate (and boring, or maybe annoying) on this list, type L 8 is useful to tell the C/70 to send just the low 8 bits of each byte, a common type of file on the C/70 -- what you normally get as output from a C program that writes an 8 bit binary file -- or store such a file. Using Image mode instead, you get the unused zero bits sent through the net, wasting network bandwidth and machine cycles, as the C/70 laboriously repacks bits into 8 bit bytes -- and then have to run a program to strip the bits out at the other end. So for both the C/70 and pdp10 type architectures, type L 8 tells the machine to skip over unused bit positions -- the pdp10 put these bits at the end of each word, the C/70 puts them in the high order position of each byte. Thus local byte size is important if you want to assure compatibility with possible "odd" machines in the future, or with existing ones you know you need to communicate with already. User and server FTP's for 8 bit machines sometimes do not initially implement even type L 8 because the author knew that there was no special local interpretation of for it, i.e. that it would be treated the same as image, and therefore deemed it unnecessary. But it eventually has to be added in order to talk to odd machines which do place an interesting -- i.e. different than image -- interpretation on it at the other end. To be general, at least any local byte size that seems equivalent to type image ought to be accepted by the server and settable by the user process, and then treated identically to type Image -- this costs almost nothing in the implementation. As far as I know, only a few cases really seem to be needed. On an 8 bit machine, multiples of 8 seem like they might be equivalent to image, but then since the spec does not say a particular local byte type means, it being a local matter, it is hard to rule out that you might someday need to talk to a machine that needs to be told "type L 5". What should this mean on a an 8 bit machine? The user ftp "quote" command is a reasonable hedge against this unlikely case except that some user ftp processes withhold the type command and send it just before the "stor" or "retr" command. Buz