MVSFORUMS.com

[kirank]

Hi,

I'm trying to run an FTP jcl to transfer a file(60000 records) from one mainframe server to another mainframe server. But it is taking 20 mins of time and when I cancelled the job, the destination file contains only 40000 records.


Could you please help me in how to send the files faster thru FTP jcl.


Thanks,

Kirank

[Nic Clouston]

Not exactly a JCL question but a Utilities question.

Please show, with confidential data disguised, your control cards, JCL and any relevant SYSOUT.
_________________
Utility and Program control cards are NOT, repeat NOT, JCL.

[expat]

And also have a chat with your network guys to see if they are having any problems.
_________________
If it's true that we are here to help others,
then what exactly are the others here for ?

[kolusu]

kirank,

Use meaningful topics (don't use the Forum name/PGM Name for the topic). Use a descriptive Title to explain your problem. I have edited the title for you. From next time, I expect you to follow the rules

Apart from the networking issues, Is the sending file blocked properly? For example if you create a FB file with LRECL=80 and BLKSIZE=80, then it would result in reading the file 1 record per block. Had the file been created with BLKSIZE=27920, then you would have read 349 records per block. So make sure that the files are created properly.
_________________
Kolusu
www.linkedin.com/in/kolusu

[Spolacek]

I apologize for responding late to this post. I hope that someone may find my information helpful.

Three factors come into play in any computer process:
1. The environment
2. The program
3. The data

Kirank wrote that the file transfer is slow. I would ask if this a regular job and did it run faster in the past? If so, then if you have not changed the FTP parameters and the volume and composition of the data has not changed, the issue must be with the environment. For example, at the time the job runs, is the mainframe busier than it was in the past? Perhaps you could schedule the job at a time when the mainframe is less busy. If the particular LPAR on which the job runs has become busier, perhaps you could direct the job to a less busy LPAR.

As Expat suggested, you may want to speak with the people in your shop who support the telecommunication network and bring the slow transfer time you experienced to their attention. If there has been a degradation in performance of the network, it is possible they are not aware of it and could then address it.

Regarding the data, as Kolusu suggested you may want to check the characteristics of the mainframe source dataset. For maximum I/O performance, it should have a half-track block size. If you defined the dataset with SDB (system determined block size), then you can assume that it has the optimal block size.

Regarding mainframe FTP parameters that may reduce transfer time, I’ve found that specifying additional buffers for the mainframe dataset will decrease FTP runtime by reducing the number of physical I/O operations. You can do this through the BUFNO parameter on the LOCSITE subcommand.

For example, add the following statement to your FTP script to cause FTP to read 1 cylinder of data at a time (assuming the dataset blocking factor is half-track):

LOCSITE BUFNO=30

Here is the documentation that describes LOCSITE and BUFNO.

LOCSIte subcommand
Specifies information used by the local host to provide services specific to that host system.

BUfno
Specifies the number of access method buffers used when data is read from or written to a data set. The valid range is 1-35. The default value is 5.

This FTP transfers data from one mainframe to another. I assume that the FTP script has a SITE command in which you specify the characteristics (RECFM, LRECL, BLKSIZE, etc) of the dataset you are creating on the target system. You may want to add BUFNO=30 to the SITE command to cause the receiving mainframe to write 1 cylinder of data per I/O operation.