Tsai Laurence wrote: >as the subject, test file transfer through TSO IND$FILE & TCP/IP FTP , and >found TSO IND$FILE is much slower than FTP. Any idea why ?
Blocksize, 3270 screen size limits and overhead of TSO between VTAM as well as IND$FILE which needs to work with the emulator handling that session. McKown, John wrote: >ftp does not go through as many transitions. Basically, there is an IP >connection to a server which write directly to a file. The only encode/decode >is if you do an ASCII translation. With TSO IND$FILE, you must encode and >decode all your data into a 3270 data stream. Which, due to TSO, is half >duplex (like the old walkie talkies, only one side talks at a time). You then >IP connect your TN3270 emulator to a TN3270 server which encodes the 3270 data >stream. Also, then IND$FILE transfer is limited to the size of your TSO >screen. I.e. send one screen of encoded data (at most 80x24, or 1920, bytes >for a -2; 27*132==3564 for a -5); wait and decode the response (protocol >overhead); >The above is just my SWAG based on some knowledge of how IND$FILE works >internally. SWAG is 100% correct. ;-D Fact is: screen based (3270) emulators are not really meant for file transfers. 3270 transfers to/from PC/mainframe are done in blocks, just as you are saying. >wash, rinse, repeat until all data is transferred. must be 'wash, rinse, repeat until all data is transferred *IN SEQUENCE*'. FTP, being moderner, is using better packaging of data, using full-duplexing and handling bigger data in an efficient way. Also the data is being send over in big packets. These packets don't need to arrive at the destination in the correct sequence. I think other IBM-MAIN members can fill in more reasons and perhaps give some useful background info. Groete / Greetings Elardus Engelbrecht ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
