Out of curiosity, does anyone know what protocol is used for file transfers by the ISPF Workstation Agent (WSA.EXE)? Dave Salt
SimpList(tm) - try it; you'll get it! http://www.mackinney.com/products/program-development/simplist.html > Date: Wed, 19 Sep 2012 09:39:37 -0500 > From: [email protected] > Subject: Re: Why File transfer through TSO IND$FILE is slower than TCP/IP FTP > ? > To: [email protected] > > On 09/19/2012 07:39 AM, 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); wash, rinse, repeat until all data is > > transferred. The protocol and data translation (if any) overhead on ftp is > > much less. > > > > The above is just my SWAG based on some knowledge of how IND$FILE works > > internally. > > > TSO File Transfer was also slow when TN3270 and IP were out of the > picture and you just had a coax-attached PC 3270 emulator with only > VTAM, 3270 protocol, and 3274 controllers involved. Considering the age > of IND$FILE on MVS, there is probably minimal buffering used for > reading/writing the file under TSO on MVS. Depending on DASD block size > and latency times, Just failing to adequately buffer the DASD file I/O > could easily degrade the throughput by an order of magnitude. That, > plus the inefficiencies of trying to kludge arbitrary data into > half-duplex 3270 data-stream protocol, which was designed and optimized > for sending formatted text fields, is probably sufficient to explain why > this has never been a good way to transfer data files unless they were > very small. > > Given the typical product and product-version unique, tedious, and > therefore error-prone methods for specifying IND$FILE file attributes > and file sizes on various 3270 emulators, I also found that even for > transferring small files with non-standard attributes, success was > easier and sooner obtained with FTP and MVS-consistent "quote site" > attribute overrides than trying to re-discover how to specify the > correct attributes through the unique GUI interfaces of some emulator > product or to decipher/modify existing transfer profiles unique to a > specific PC instance of that product. I ceased to use IND$FILE except > when no other option for file transfer was available and the experience > in those few cases was frequently unpleasant by comparison. > > -- > Joel C. Ewing, Bentonville, AR [email protected] > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to [email protected] with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
