iSeries to Unix FTP problem

25 pts.
Tags:
FTP
IBM iSeries
Physical File
Unix
I've a physical file with single field (64 chars long) and want to transfer it across to our Unix system using FTP. When I transfer the file across, I don't get CR/LF characters at the end of each record. All physical file records appear in a single line. If I retrieve the same file from my PC using FTP, its fine and I find all physical file records in line after another. Why is it not doing the same when I transfer from iseries to Unix box. What am I doing wrong here?

Answer Wiki

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

Hi,

Try the FTP command STRUCT R – This should cause FTP to send the data as records instead of a stream of data.

Hope this helps,

Martin Gilbert.

Discuss This Question: 6  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.

REGISTER or login:

Forgot Password?
By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy
  • Maverick69
    Hi Martin, It doesn't seem to like "STRUCT R" command when FTPing to a Unix box. I get the following error. 504 Unimplemented STRU type. It works fine when connected to another iSeries machine. Any help on this is much appreciated. Thanks.
    25 pointsBadges:
    report
  • bvining
    I must admit I'm a little confused. Normally this type of problem surfaces when sending from Unix rather than to Unix. Windows uses the combination of carriage return and line feed to represent end of record, while Unix uses only the line feed. To help address this difference FTP defines that when moving files in ASCII mode that both carriage return and line feed are used, with the platform implementations then adding or removing these controls as necessary when working with the local file system. Are you using ASCII mode? If so, how are you "looking" at the Unix file? You should not find a carriage return, nor should you need one for processing of the file. Hope this helps, Bruce Vining
    6,495 pointsBadges:
    report
  • Maverick69
    Yes, I'm using ASCII mode. I'm looking at the file from my Windows PC. I've a drive mapped to our Unix box.
    25 pointsBadges:
    report
  • bvining
    If you google 'UNIX windows carriage return' you will find various ways to convert the Unix file to a windows format (and that this is a fairly common problem...). But do you need to? Are you simply viewing the file from Windows to verify the contents and planning to process the file in a UNIX application? If so, you're probably ready to go. The verification isn't working due to the lack of a carriage return, but a UNIX application isn't going to need it anyway.
    6,495 pointsBadges:
    report
  • LabNuke
    Context/ is a nice editor that can view/edit files that do not have CR/LF like you are describing. It has some good language highlighters. The feature I like the most is being able to mark/edit columns in a text file. Not a lot of editors can do that.
    90 pointsBadges:
    report
  • FJD
    Just a note that if you use Wordpad to view the file that is in a UNIX format it will be displayed correctly. Notepad will not display the file correctly as it expect the line terminator to be <CR><LF>. Frazer Dixon
    10 pointsBadges:
    report

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.

REGISTER or login:

Forgot Password?
By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy

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

Following