"Edward J. Rovera" <EJR9006%UCSFVM.bitnet@ugw.utcs.utoronto.ca> (02/03/90)
We are running FAL 1.2.1 on our production 4381-92E and have just connected up our new 3090-200S to the ethernet. Both machines are running VM/XA 2.0 with VM/HPO 5 running underneath. The FAL code is running on the HPO systems, not in XA. In the midst of doing some FTP's between the production 4381 and the new machine we discovered that MACLIBS were getting corrupted. The reported symtom was that X'FF' was being converted to X'07'. Since we are running VANILLA FAL code right off the tape (and I have not done any futzing with any translate tables) I strongly suspect that what happened happened due to something that came with FTP and is due to something we didn't do during the FTP process. Does one have to issue a BINARY command before FTP'ing between VM systems? If so, why? I also encountered a specification exception running a module that I had FTP'ed to the 3090 that disappears when I used the sneakernet (i.e, VMFPLC2 DUMP to tape and sneaker it down to the new machine room) to move the module. I don't know if this was a random glitch or related to the MACLIB translation problem. Had I had more time, I would have done more detectiving but I was in a hurry and just got what I needed done. Thanks.
Doug Nelson <08071TCP%MSU.bitnet@ugw.utcs.utoronto.ca> (02/03/90)
> In the midst of doing some FTP's between the production 4381 and >the new machine we discovered that MACLIBS were getting corrupted. >The reported symtom was that X'FF' was being converted to X'07'. >Since we are running VANILLA FAL code right off the tape (and I have >not done any futzing with any translate tables) I strongly suspect >that what happened happened due to something that came with FTP and is >due to something we didn't do during the FTP process. Does one have >to issue a BINARY command before FTP'ing between VM systems? If so, >why? Yes, you have to issue a BINARY command if you're transferring binary data. Why? Because the FTP spec says that ASCII is the default, that's why, plain and simple. In general, binary files are going to be useless when sent from one OS to another, and there's no way to determine for sure that both systems are running the same OS. Doug Nelson Michigan State University
Jay Elinsky <ELINSKY%YKTVMT.bitnet@ugw.utcs.utoronto.ca> (02/04/90)
I use EBCDIC representation and block mode (REP E, MODE B) to transfer binary files between VM systems. Block mode preserves record boundaries, while stream mode might create a false end-of-record. I think this is in the User's Manual, but I don't have it at home so I can't check it now. Jay Elinsky IBM T.J. Watson Research Center Yorktown Heights, NY
Benzi mizrahi <VSBENZI%WEIZMANN.bitnet@ugw.utcs.utoronto.ca> (02/04/90)
On Fri, 2 Feb 90 17:59:37 EST Doug Nelson said: >> In the midst of doing some FTP's between the production 4381 and >>the new machine we discovered that MACLIBS were getting corrupted. >>The reported symtom was that X'FF' was being converted to X'07'. >>Since we are running VANILLA FAL code right off the tape (and I have >>not done any futzing with any translate tables) I strongly suspect >>that what happened happened due to something that came with FTP and is >>due to something we didn't do during the FTP process. Does one have >>to issue a BINARY command before FTP'ing between VM systems? If so, >>why? > >Yes, you have to issue a BINARY command if you're transferring binary >data. Why? Because the FTP spec says that ASCII is the default, that's >why, plain and simple. In general, binary files are going to be useless >when sent from one OS to another, and there's no way to determine for >sure that both systems are running the same OS. > You can use EBCDIC command if you're transfering binary files VM-to-VM, you may want to use MODE BLOCK to preserve the file structure. FAL FTP SYstem, subcommand tells you what remote OS you're talking to. Benzi Weizmann Institute of Sceience, Computing Center, Rehovot, Israel.
Dick McCarthy <SP0003%BINGVMB.bitnet@ugw.utcs.utoronto.ca> (02/05/90)
ASCII is the default and that will warp binary files. Fig 2.2 on page 2-2 of command reference says VM to VM should be EBCDIC,BLOCK. That should be faster than BINARY which will work too. Regards, Dick ===================================================================== SP0003@BINGVMB.BITNET - or - SP0003@BINGVMB.CC.BINGHAMTON.EDU State University of New York at Binghamton (607) 777-6106
Melvin Klassen <KLASSEN%UVVM.bitnet@ugw.utcs.utoronto.ca> (02/05/90)
>On Fri, 2 Feb 90 17:59:37 EST Doug Nelson said: >>>In the midst of doing some FTP's between the production 4381 and >>>the new machine, we discovered that MACLIBS were getting corrupted. The directory for a MACLIB contains non-standard, non-displayable characters. >>>Does one have to issue a BINARY command before FTP'ing >>>between VM systems? If so, why? >> ... >>Yes, you have to issue a BINARY command if you're transferring binary >>data, because the FTP spec says that ASCII is the default. It's necessary, but not sufficient, to issue the BINARY command. See Table 2-1 on page 2-2 of GC09-1204-02 'IBM TCP/IP for VM Command Reference Manual, Release 1.2'. Basically, it recommends to use 'TYPE EBCDIC' and 'MODE STREAM' when transferring "text" between two VM systems. (Experimentally, "text" can be any of the 256 hex. codes, except X'15'; although the manual states that "text" excludes X'1E'. Hmmm.) It recommends to use 'TYPE EBCDIC' and 'MODE BLOCK' when transmitting "binary" files, e.g., MODULE, TXTLIB, and LOADLIB files. In this case, I recommend to do what IBM says, and you'll be OK.
"Philip G. Pishioneri" <PGP%PSUVM.bitnet@ugw.utcs.utoronto.ca> (02/06/90)
Does EBCDIC, STREAM for readable text, and EBCDIC, BLOCK for "binary" mean that VM-to-VM (or MVS) MPUTs or MGETs of a combination of such files are not possible? Or can one just get away with specifying EBCDIC, BLOCK and take a little more overhead in the FTP session for the text files? -Phil
Dick McCarthy <SP0003%BINGVMB.bitnet@ugw.utcs.utoronto.ca> (02/08/90)
As I understand it, your second statement is true as far as reduction of overhead. If you set type E, mode B, both binary and text would arrive fine. If you just had text, the stream mode is less overhead because block headers are not sent. Regards, Dick ===================================================================== SP0003@BINGVMB.BITNET - or - SP0003@BINGVMB.CC.BINGHAMTON.EDU State University of New York at Binghamton (607) 777-6106