|
|
| Author |
Message |
Aneesh
New User
Joined: 30 Sep 2006
Posts: 19
|
|
|
|
I have a tab delimited file that I need to ftp for processing. The issue that I'm facing is that the ftp is causing the data in the entire file to be put as a single record in the sequential file - the line breaks are not coming into effect when I ftp the file.
The end of the line value in the ftp'd file is x'0D' but the data is one single continuous record and not getting split into multiple lines.
Is there a way around this?
Aneesh. |
|
| Back to top |
|
 |
References
|
 Posted: Mon May 05, 2008 2:29 am Post subject: Re: FTP a tab delimited file |
|
|
|
|
superk
Moderator Team Head
Joined: 26 Apr 2004
Posts: 3008
Location: Charlotte,NC USA
|
|
|
|
From the topic on the LOCSITE sub-command from the z/OS V1R9.0 Comm Svr: IP User's Guide and Commands manual:
| Quote: |
SBSENDEOL
Specifies which end-of-line sequence to use when ENCODING is SBCS, the data transfer type is ASCII, and data is being sent to the server. The following are possible values:
CRLF
Append both carriage return (X'0D') and line feed (X'0A') end-of-line sequences to each line of translated text. This is the default and the standard sequence defined by RFC 959. The z/OS server can receive ASCII data in this format only.
CR
Append only a carriage return (X'0D') end-of-line sequence to each line of translated text.
LF
Append only a line feed (X'0A') end-of-line sequence to each line of translated text.
NONE
Do not append an end-of-line sequence to the line of translated text.
Tip: The srestart subcommand is disabled if you configure a SBSENDEOL value other than CRLF.
Rules:
Most servers support only the CRLF value for incoming ASCII data. Do not specify another value for SBSENDEOL unless you have verified that the server is expecting the end-of-line sequence that you specify.
Do not use an end-of-line sequence other than CRLF if the server is a z/OS FTP server. The z/OS FTP server supports only the CRLF value for incoming data.
If you send a file to a server while SBSENDEOL has a value other than CRLF, a subsequent SIZE command to that server targeting the file you sent could yield unpredictable results. Any size indicated in the server reply for such a file might not be reliable.
|
To summarize, to receive a file in ASCII format, the file MUST contain a CRLF pair. If there's absolutely no way to get around this, then all you can do is transmit the file in BINARY mode, then translate it to EBCDIC using rules YOU specify. |
|
| Back to top |
|
|
Aneesh
New User
Joined: 30 Sep 2006
Posts: 19
|
|
|
|
| Thanks a lot. |
|
| Back to top |
|
|
|
|
