View previous topic :: View next topic
|
Author |
Message |
AJAYREDDY
New User
Joined: 17 Feb 2007 Posts: 52 Location: USA
|
|
|
|
I am GETing .TXT file from non-mainframe server to Mainframe using JCL. I am able to successfully retrieve (GET) 4 .TXT files from the server. These are having less than 50000 records.
But one of the file which contains around 4 to 5 million records is not creating the file properly. It is FB 404 .TXT file. I am using TAPE file to retrieve data. After running the JCL it is creating VB 256 with below FTP log even though I am creating FB 404 Tape file. Did anyone get similar problem? Why Data is getting truncated?
226 File transfer completed successfully.
EZA1617I 1909582801 bytes transferred in 761.990 seconds.
EZA2802I Data was truncated.
EZA1460I Command:
EZA1736I quit
EZA1701I >>> QUIT
221 QUIT subcommand received.
Thanks |
|
Back to top |
|
|
Robert Sample
Global Moderator
Joined: 06 Jun 2008 Posts: 8696 Location: Dubuque, Iowa, USA
|
|
|
|
Is the file preallocated before the FTP step runs?
If not, do you have LOCSITE values for RECFM LRECL BLKSIZE?
If not, your results would not be unusual as the IBM default is for FTP to use RECFM=VB, LRECL=256 if there's no other source of DCB data (although this can be overridden by your site in the TCP PARMS for FTP). You can confirm this by using QUOTE LOCSTAT in your FTP commands to see what values FTP defaults to. |
|
Back to top |
|
|
AJAYREDDY
New User
Joined: 17 Feb 2007 Posts: 52 Location: USA
|
|
|
|
Yes the file is preallocated before the FTP runs. I asked non-mainframe people to reduce the file size to 10000 records and run FTP step again. This time it worked creating FB 404 without any truncation. I am still trying to figure out whether FTP can handle millions of records at a time or not. |
|
Back to top |
|
|
Robert Sample
Global Moderator
Joined: 06 Jun 2008 Posts: 8696 Location: Dubuque, Iowa, USA
|
|
|
|
We run -- daily -- over 13 GB of data through FTP (that total is for sending and receiving) and peak at over 30 GB in a day. I have monthly processes where I'm downloading from a server and uploading to a mainframe 6 to 8 GB in a day. One of those files has just over 2 million records. So if FTP is set up at your site correctly, the number of records is not a concern.
However, you may have to work with your site support group to resolve network issues -- often there are limits inside the network on traffic and those limits, not any issue with FTP, can cause the FTP to fail. They may also need to tweak some of the FTP default settings. |
|
Back to top |
|
|
superk
Global Moderator
Joined: 26 Apr 2004 Posts: 4652 Location: Raleigh, NC, USA
|
|
|
|
I'll bet that there's a record in the source file that's longer than the specified LRECL. |
|
Back to top |
|
|
superk
Global Moderator
Joined: 26 Apr 2004 Posts: 4652 Location: Raleigh, NC, USA
|
|
|
|
I don't understand. Can the FTP process really override values specified in the JCL for the RECFM, LRECL, and BLKSIZE? |
|
Back to top |
|
|
Robert Sample
Global Moderator
Joined: 06 Jun 2008 Posts: 8696 Location: Dubuque, Iowa, USA
|
|
|
|
Kevin, you can specify these values on the LOCSITE or SITE commands in FTP. Since FTP is a running program, the values specified in the FTP should override the JCL values as documented in the JCL manual. I'm not sure I've tested this specific scenario, though. |
|
Back to top |
|
|
superk
Global Moderator
Joined: 26 Apr 2004 Posts: 4652 Location: Raleigh, NC, USA
|
|
|
|
Don't know for a 100% sure. The documentation DOES state:
Quote: |
When a data set is allocated using a ddname and the DCB information is needed before open, the FTP client must be able to find the DCB information on the DD statement that was used to allocate the data set.
DCB attributes for a ddname allocation are acquired using the attributes or data set name specified in the DD statement DCB parameter. See the z/OS MVS JCL Reference for restrictions on using backward references in the DCB parameter.
If the DD statement refers to a cataloged DASD data set, any DCB attributes that are not specified are retrieved from the DSCB. DCB attributes on the DD statement that override those found in the DSCB, except that LRECL=0 and BLKSIZE=0 do not override a different value in the DSCB.
If the DD statement refers to a tape data set that is to be opened for input (PUT //DD:), the record format that is specified on the DD statement is used instead of the READTAPEFormat setting. If no record format (RECFM) is specified on the DD statement, the READTAPEFormat setting (if any) is used.
Once the data set is opened by FTP, its attributes are set using the data returned in the DCB by open.
|
|
|
Back to top |
|
|
AJAYREDDY
New User
Joined: 17 Feb 2007 Posts: 52 Location: USA
|
|
|
|
Thank you guys. I will work with FTP folks and find out information. I will update any findings later. |
|
Back to top |
|
|
|