[Default] On 12 Oct 2017 09:03:14 -0700, in bit.listserv.ibm-main [email protected] ([email protected]) wrote:
>Hi John > > Could you give us a sample of the ftp job or the rexx? > >Thanks a lot ! A major consideration, at least on the z series side is the cpu and MSU costs of doing the transfer with compression versus the costs of doing it without compression. Clark Morris > >Jason Cai > > >>>?My first though is to "tune" your network. I'm assuming you are talking >>>from z/OS to Linux via TCPIP over ethernet. ?From what little I know, most >seem to use an MTU of 1500. You might get better throughput if you could >configure the MTU to be larger. This is oft times called "jumbo frames" ( >https://en.wikipedia.org/wiki/Jumbo_frame ). > >Whether to compress or not is basically a trade off between how long it >takes to compress-transfer-uncompress vs. just transfer. This will depend >on the power of the boxes on each end and the "size of the pipe" between >them. > >Assuming a "large pipe" (that is 10 Gib/s or larger): >I am not certain how you generate the list of files to be transferred. But >what I would possibly do is multiple concurrent FTP jobs running at the >same time. For example: job 1 in the job stream finds all the DSNs to be >transferred. For each DSN, it creates an FTP "put" control card. Assuming >REXX as the language of choice, each control card is recorded in a stem >variable. Something like: ftp_control.0=<number of ftp control cards>; >ftp_control.1="put ...."; and so on. Now determine the number of concurrent >FTPs you want to do. Divide the number of ftp control cards by this number. >Create a normal batch job where each job runs a single FTP step which has >"n" ftp_control cards in it. Submit each job to z/OS using the internal >reader. Have enough initiators running to run those jobs. Let them all (or >a subset) run at one time. The extreme of this is to have each job do a >single FTP. And have "n" initiators running those jobs. You could generate, >say, 20 FTP jobs, and run 5 at a time by having 5 initiators set up & >dedicated to running just those jobs (by dedicating a specific JOBCLASS to >this purpose). > >Anyway, I was just thinking that instead of serially compressing, >transferring, and uncompressing the data; it might be faster with a "large >pipe" to do multiple transfers concurrently. > > ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
