GUBBINS@RADC-TOPS20.ARPA.UUCP (12/03/87)
The problems in FTPing from a 36-bit TOPS-20 to a 32-bit VAX is not a problem of the DEC VAX. It is a funadmental problem with VMS, the stock VAX OS from DEC. The UNIXes that are commonly run on a VAX have TCP/IP (THE Network protocol, which is large, gross, computation pig, but is the only standard that works) built into the 'core' of the UNIX (Berkley?) OS. Therefore, TCP/IP is part of the UNIX OS that is used on the Internet. FTP, TELNET, and SMAIL (standard email) are standardized application programs that interface to the TCP/IP protocol. Since everyone is generally running the same flavors of the same UNIX OS, and that the UNIX FTP is 'robust' from years of use, it is quite functional and all cases of transfer have been implemented. Now the nasty bit: TCP/IP and the VMS OS do not get along, it is not a part of VMS and DEC doesn't sell it. You want to put a VAX VMS on the Internet, you must by one of several third party 'Hack & Kludge' to 'add' to VMS, which was designed to run DECnet (totally incompatible down to the 'core'). It comes down to if the third party vendor: 1) Implemented the TCP/IP, FTP, etc. properly, 2) Took 36 to 32-bit translation cases into account as they SHOULD have (Very few vendors have access to 36-bitters or even know that they exist!). 3) If you can FTP properly, great, if not, have your System people work on it (If they can) or buy the TCP/IP from someone else. As a sub-sub-subfunction of one of my tasks, I am looking into 'clean and neat' ways to implement TCP/IP on VAX VMS, preferably 'on the board' and not in VMS. Also, the problem is compounded by that fact that Bytes are stored differently on not-divisable-by-8 machines. On the Z-100, all 'normal' micros, PDP-11s, VAXen, etc. ASCII is stored in the same way as binary. ASCII is 8-bits, a Byte is 8-bits and these machines do not distingish ASCII from Bytes. Example: A 32-bit VAX stores 4 ASCII characters or 4 Bytes in one 32-bit word. Multics (another 36-bit mainframe) stores Binary Bytes 4 to a word, then a nybble of the 5th byte (I believe the TOPS-20 also stores Binary this way). But for ASCII, Multics stores 8-bit ASCII with a 9th junk-bit on each character and stores it 4 8-bit+1-junk-bit to a 36-bit word. You can also have Multics store your binary this way by telling the FTP that it is ASCII, then use ASCII KERMIT mode. The TOPS-20 stores ASCII in a different way, something like each character cut to 7-bits and all strung together. The upshot of all this is: Assumming you have a proper FTP, etc., you must take into account the modes and the format of the data that you are FTPing and again while KERMITing. FTP does all the translations from host formats for ASCII transfers, as does KERMIT for ASCII mode. Binary is stored as a bit stream (all strung together spanning word boundaries). Binary Bytes only span word boundaries on OCTAL (12-bit, 36-bit, etc) machines and fit nicely on HEX (8-bit, 16-bit, 32-bit, 64-bit, etc) machines that also usually store ASCII as 8-bit Bytes. For SIMTEL-20: If you also have a TOPS-20, use paged mode FTP (default) and use KERMIT in ASCII mode for ASCII and 8-bit for binary. For Hex machines, use ASCII mode for FTPing ASCII and for Binary use Binary/8-bit/(syntax completely differnet based on your FTP implementation), KERMIT usually doesn't have different modes. For Multics it is up to the version and syntax of the FTP, consult your wizard (But I have been completely successful in the past - Experiment!!!). In all cases, try ASCII transfers first. It should also be readable on your host. Experiment!!! Then consult your wizard! If you are on a OCTAL machine and FTPing from a HEX machine and targeting to your HEX micro, you can speed your transfers up by doing it all in binary mode, you just won't be able to read the ASCII files on your OCTAL mainframe, but you will on your micro (did you follow that???) Cheers, Gern -------