Inserting CRLF in mainframe FTP program

Mainframe FTP Program
The following question was posted by another person on Feb. 19, 2007. I am having a problem with FTP'ing a file that does not contain CRLF to the mainframe. Because the source file does not contain a CRLF to signify the end of line, only the data up to the LRECL of the file will be transferred. The remainder of the data is truncated and discarded. I have tried binary and ASCII file transfers without success, and ebcdiic isn't supported. Please let me know if there are other parameters that I might try. I have the same problem with a company FTPing me a file to an Intel machine without CRLF on a regular basis. I have a scheduled mainframe job that FTPs this file from the Intel machine to the mainframe and the resulting file contains only one record. I was told this file was created in Unix. My temporary solution is to manually FTP the file to a desktop, use Textpad to read and save it with file format = 'PC' instead of 'UNIX,' and then FTP it to mainframe manually. Using this method means that I cannot automate the mainframe job. Is there any parameter(s) that I can use to insert CRLF in the mainframe FTP program? Thank you for the help.

Answer Wiki

Thanks. We'll let you know when a new response is added.

If you’re FTPing from the host, you can use the “site” subcommand to set the attributes for the file that is to receive the data. The site subcommand allows you to specify just about any data set attribute available in JCL. For instance, if you wanted the FTPed file to look like a card image, you could enter:

site lrecl=80 blksize=3120

To which FTP will respond:
>>> SITE lrecl=80 blksize=3120
200 SITE command was accepted

After you’ve entered the proper data set attributes you may use the “stat” subcommand to check:

211-Record format FB, Lrecl: 80, Blocksize: 3120

Note that the line above is a snippet of stat output. Normally the command produces several screens of data.
You can still use stat if you initiate the FTP from another platform, you just prefix it with “quote,” as shown below:

quote site lrecl=80 blksize=3120

Here, “quote” command is kind of an escape verb that directs the text following it to be processed by the host FTP server.

Discuss This Question: 3  Replies

There was an error processing your information. Please try again later.
Thanks. We'll let you know when a new response is added.
Send me notifications when members answer or reply to this question.
  • Indoubt88
    I don't believe the answer from Wiki will do what you are looking for. There is a parameter in the system stettings for FTP on the mainframe that control whether the data wraps to a new line or follows the value of the TRUNCATE FTP setting: WRAPRECORD FALSE ; (S) Specify what to do if no new-line ; is encountered before reaching ; the MVS data set record length ; limit as defined by LRECL when ; transferring data to MVS. ; TRUE = Wrap data to new record ; FALSE (D) = Defer to the TRUNCATE ; setting to determine if the ; record is truncated or the file ; transfer fails If the above FTP system parameter is changed to TRUE instead of FALSE, the data will wrap at the record length of the receiving file. This will only work out right if all of the 'records' on the distributed end are the same length as the file length of the mainframe file. There will also be more work to do on the file once transferred if there are any extra characters inserted by the distributed end after the end of each 'line' of data (I am not that familiar with UNIX so I do know for sure how it differentiates lines). If characters are added you may have to increase the record length so they all fall at the end of the file and then deal with them on the mainframe (ignore them if you control the program reading the file or strip them off with another program to get to the originally desired file length before processing it with the current program). If you are initiating the transfer from the mainframe in a batch job, you can over-ride the system defaults setup for your system for this one job by coding (or over-riding) the SYSFTPD DD statement to point to a copy of your FTP parms with just the WRAPRECORD value changed. If you don't know where to find the parameters being used on your system or how to add/over-ride the DD statement, discuss this with the person supporting FTP on your mainframe. As a side note, I would not run with the default for TRUNCATE set to TRUE like the system you are using appears to be because I would rather the FTP fail than succeed with partial data but that is more of a preference as both have advantages. HTH, Greg
    45 pointsBadges:
  • petkoa
    Well, if it's possible to open the file in the textpad and save it in PC format without damaging it, why don't you do the same on the unix machine? GNU nano can save files in unix, pc, mac formats. You can accomplish this with sed : sed -i.bak 's/$/^M/' test.txt This command will work "in-place", creating a backup file test.txt.bak ( -i.bak ) and put before the unix end-of-line LF ($) a CR character ( ^M = ctrl-M = CR ). To put ^M in the command line you'll have to use escaped-input-sequence ( ctrl-V in bash, csh, tcsh, so if you use another one, start a subshell - any unix will have csh). Hope this helps, BR, Petko
    3,140 pointsBadges:
  • ktyson

    For FB file transfers to the mainframe from a Windows Client.

    If you have the file on Windows and can install Notepad++, you can see and manipulate the end-of-line markers/chars to your advantage.

    Many text files, even the ones IBM sends have an EOL marker/char that is just a line feed - LF.  Sometimes the transfer method will convert the file to LF only.  These EOL chars should be translated from LF to CRLF  (or just CR - experiment) to behave the way you want on a mainframe file transfer. 

    Simply open the file in Notepad++, it should appear normal with fixed length records.  The "Encoding" tab should show either ANSI or UTF8.  In the "View" tab, click on "show symbols" then "all characters" or "end of line".  You should now see either LF or CR or CRLF highlighted at the end of each line.  If it is already CRLF and you have a transfer problem, it is probably a record length LRECL mis-match.

    If it shows LF, then you can simply click on the "Edit" tab, then  "EOL conversion", then click on Windows for CRLF or Mac for CR.

    Save the file with a txt qualifier - for clarity if you like - and you are ready to transfer using the ASCII or BINARY transfer depending on how you will use the data on the mainframe. 

    If you are not sure how long the lines are, the bottom of the screen in Notepad++ tells you where your cursor is, line and column.

    I like indoubt88's reply on making the transfer fail on mismatch, that's how I would set it up too - but be aware there may already exist some production file transfers that rely on the truncation and cond=0.  If you change the whole system default from truncate to fail you must be prepared for any fallout if a production job fails.  A custom SYSFTPD DD as indoubt88 mentions is perfect if you are running batch transfers or even on TSO you can re-allocate it.

    However from Windows client FTP I can't think of a way to change it on the fly. An ASCII LF is X'0A' - it translates to an X'25' in EBCDIC on the mainframe.  CRLF is X'0D0A' if that helps for your other utilities. 

    Good luck.

    10 pointsBadges:

Forgot Password

No problem! Submit your e-mail address below. We'll send you an e-mail containing your password.

Your password has been sent to:

To follow this tag...

There was an error processing your information. Please try again later.

Thanks! We'll email you when relevant content is added and updated.


Share this item with your network: