View previous topic :: View next topic
|
Author |
Message |
Jay Villaverde
New User
Joined: 08 Mar 2014 Posts: 27 Location: USA
|
|
|
|
Hello. Hopefully this will make sense. I am trying to FTP a file to the mainframe using IpSwitch WS_FTP Pro and for certain files I only get the first recrord although it runs as if it's transferring all the records. Could be a end of file issue perhaps but don't know what to try to see what it could be. Only happens with certain client files we get.
Thanks |
|
Back to top |
|
|
steve-myers
Active Member
Joined: 30 Nov 2013 Posts: 917 Location: The Universe
|
|
|
|
- Is the transfer a "binary" transfer or a text transfer?
- What are the DCB attributes of the mainframe data set?
- If it is a text transfer, does the workstation file have any non-printable characters in it?
- If it is a text transfer, are all lines in the work station file properly terminated with a newline character in a *nix environment or the CR LF character pair in a Windoze environment?
- If it is a text transfer, are there any characters containing 8 binary 0 bits?
|
|
Back to top |
|
|
Bill Woodger
Moderator Emeritus
Joined: 09 Mar 2011 Posts: 7309 Location: Inside the Matrix
|
|
|
|
Have you got a pre-defined file? LRECL and RECFM on the Mainframe? Does the first record actually have appended to it all the other records? |
|
Back to top |
|
|
Jay Villaverde
New User
Joined: 08 Mar 2014 Posts: 27 Location: USA
|
|
|
|
I haven't tried pre defining a file on the mainframe. Normally don't have to do that for others that work but will give it a try.
The first record is just the first record, nothing else is appended to it on the mainframe if that's what you mean.
In FTP PRO I did use the site command to enter the LRECL and RECFM before transferring. |
|
Back to top |
|
|
steve-myers
Active Member
Joined: 30 Nov 2013 Posts: 917 Location: The Universe
|
|
|
|
Jay Villaverde wrote: |
... In FTP PRO I did use the site command to enter the LRECL and RECFM before transferring. |
I think that's a good idea, but I've tended to believe you're usually better off preallocating the target data set. Automation defaults tend to be wrong, which is sort of OK if they turn out to be too high, but terrible if they are low.
In any event, I asked 5 questions and have not yet heard a response to any of them. |
|
Back to top |
|
|
Jay Villaverde
New User
Joined: 08 Mar 2014 Posts: 27 Location: USA
|
|
|
|
Sorry, had answered the questions but must have not hit submit.
Is the transfer a "binary" transfer or a text transfer? - Text
What are the DCB attributes of the mainframe data set? - Since I haven't pre-deifned the mainframe dataset the attributes would be what I set using SITE on FTP PRO
If it is a text transfer, does the workstation file have any non-printable characters in it? - No all alpha numeric characters on supplier file.
If it is a text transfer, are all lines in the work station file properly terminated with a newline character in a *nix environment or the CR LF character pair in a Windoze environment? - That I'm not sure of and could be part of the problem.
If it is a text transfer, are there any characters containing 8 binary 0 bits? - No |
|
Back to top |
|
|
Robert Sample
Global Moderator
Joined: 06 Jun 2008 Posts: 8696 Location: Dubuque, Iowa, USA
|
|
|
|
Quote: |
If it is a text transfer, are all lines in the work station file properly terminated with a newline character in a *nix environment or the CR LF character pair in a Windoze environment? - That I'm not sure of and could be part of the problem. |
This is where to start looking. If a Windows text file doesn't have CR LF at the end of each line (which could happen with a transfer from a Unix-based system to the Windows machine), the entire file would go to the mainframe as one record. The lack of line terminators would keep FTP from ending a record and starting a new one. I've seen this situation more than once. |
|
Back to top |
|
|
steve-myers
Active Member
Joined: 30 Nov 2013 Posts: 917 Location: The Universe
|
|
|
|
Robert Sample wrote: |
... If a Windows text file doesn't have CR LF at the end of each line (which could happen with a transfer from a Unix-based system to the Windows machine), ... |
Robert - I think the only way that could happen is through a "binary" transfer of a *nix text file from*nix to Windoze. I don't have ready access to the formal definition of FTP transfers, but I think the standard is to insert a *nix new line at the end of each text record. In other words, a Windoze based FTP replaces the Windoze CR LF with a *nix new line when it sends data, and replaces a *nix new line with a CR LF pair when it receives data. Similarly, an MVS based FTP terminates an MVS record when it encounters a *nix new line when it receives text data, and inserts a *nix new line when it encounters an end of record when it sends text data. |
|
Back to top |
|
|
Robert Sample
Global Moderator
Joined: 06 Jun 2008 Posts: 8696 Location: Dubuque, Iowa, USA
|
|
|
|
There is a z/OS FTP SITE option which is relevant -- SBSENDEOL. Values allowed are CRLF, CR, LF, NONE and they apply only when the transfer type is ASCII (text). I have seen one-line file transfers when the SBSENDEOL is incorrectly specified. Since the problem only occurs with some client transfers, those client transfers could be having line terminator issues (for example, sending a Cygwin file to the mainframe will send a file with only the LF on each line).
There are other z/OS options for FTP which can have a similar impact, although they would be unusual -- for example, STRUCTURE FILE transfers data as a continuous stream of bytes (as opposed to STRUCTURE RECORD which transfers data as a series of records). |
|
Back to top |
|
|
|