Troubleshooting
Problem
An FTP transfer from a remote system in ASCII mode does not properly break the file into multiple lines. The symptoms occur on the z/OS system when receiving a file, either the client doing a GET or a PUT initiated from a remote client.
Symptom
The exact symptoms observed will vary according to the FTP options currently in effect. These can include:
- Incorrect record boundaries.
- Loss of data after the first record.
- File transfer failures, with a 'File transfer failed. File contains records that are longer than the LRECL of the new file.' message as either a 451 response code from the server or an EZA2537E message at the client.
Cause
The remote side that is sending the file is not properly terminating the individual lines in the outbound data stream. The most likely cause is that the file is not in the proper format on the remote system, causing the sending FTP process to not detect where the line boundaries are supposed to be located.
Resolving The Problem
Investigate the source of the file on the remote system, and correct the process generating it. If this file was itself transferred using FTP from another system, it is possible that the transfer was performed in BINARY (instead of ASCII) from a system that uses a different file structure.
For example: When a file is transferred from an Apple Macintosh system (which uses a Carriage Return as a line delimiter) to a UNIX (based) system (which uses a Line Feed as a line delimiter), use of a BINARY mode transfer will not contain the proper line delimiters on the receiving system. Operations on that system (including further FTPs) will process the file as if it were a single long line.
A temporary bypass of this problem that can be used until the root cause is fixed would be to transfer the file with the WRAPRECORD option enabled, either:
- Via a SITE WRAPRECORD command, for PUTs issued to a z/OS server.
NOTE: Some clients may require this to be prefixed with a QUOTE command. - Via a LOCSITE WRAPRECORD command, for GETs issued from a z/OS client.
- By specifying WRAPRECORD TRUE in the FTP.DATA input on the side receiving the file as the default.
Once the file has been received, a program or REXX exec can be used to read the data set as a continuous stream, detect the lone <CR> or <LF> characters and rewrite the data set with the proper record boundaries.
Was this topic helpful?
Document Information
Modified date:
15 June 2018
UID
swg21164111