cancel
Showing results for 
Search instead for 
Did you mean: 

UNIX to DOS file conversion - extra LF & CR !

former_member216332
Participant
0 Kudos

Hello Experts,

My team is facing a file conversion issue so I thought I'd drop by for some expert advice.

It is a File to File scenario.

The sender & Receiver systems were both UNIX based systems initially & we had no issues then.

Now that the receiver system moved on to Windows based OS, the files we receive from the sender seem  incompatible!

Looks like we have extra "Line Feeds" & "Carriage Returns".

The file when generated in the UNIX system has a "0D" (hex character) embedded at every line end.

When this file is received by the Windows system, an extra "0A" and a "0D" is added to it making it  "0D0D0A" ! & this is causing technical issues while processing the file further.

Is SAP PI 7.1 equipped to solve this issue?

If not, How can the issue be solved ?

Please share your thoughts.

Thanks in advance,

Sam Anish

Accepted Solutions (0)

Answers (3)

Answers (3)

Former Member
0 Kudos

Hi Sam,

Were you able to solve this issue?

Unfortunately even I am facing the same issue.

Thanks,

Swati

former_member216332
Participant
0 Kudos

Hello Swati,

The issue happened quite a while ago when I was in a different project.

We did sort out the issue in the end but I am sorry I do not remember any specifics.

Ill see if can gather any info about the issue. Meanwhile, if you have a resolution to the issue, please feel free to post your solution here so it would benefit someone in the future.

Regards

Sam

Former Member
0 Kudos

Hi Sam,

My scenario was actually FTP-->SFTP with a little mapping. There is an option to select file type in as binary or text. When I selected text, it had 3 more options :

CR

LF

CR/LF

On selecting CR/LF the files went just fine in UNIX format.

PS: The SFTP adapter that we have in our 7.11 system is ADVANCO's.

Thnx,

Swati

jeff_darling2
Explorer
0 Kudos

Try processig as Text and not Binary. DOS text files traditionally have carriage return and line feed pairs as their newline characters while Unix text files have the line feed as their newline characters. When files are procesed as text, this is normally handled automatically when the file is created/generated. But when you process them as binary it's passed through 'as is', and then windows OS adds it's own CR/LF to the already existing LF.

Former Member
0 Kudos

Hi Sam ,

Please try Hexdecimal values for newline and other symbols . when we change the environment from unix to some other . some time we face this issue

for 'nl' = '0x0a'  hexadecimal values .

Regards,

Rudra

former_member216332
Participant
0 Kudos

Thank you Rudra Singh for the reply.

I must have mentioned it earlier. The file generated is a text file.

The generated text file & the received text file looks the same.

The discrepancy can be viewed only if the files are converted to their respective Hex format !

Welcome your thoughts.

Regards
Sam Anish

Former Member
0 Kudos

Hi Sam,

what is the filetype you mentioned in the receiver channel processing parameters

Cheers

Hidayat

former_member216332
Participant
0 Kudos

Hi HIDAYAT ANSARI MOHAMMED,

The file type mentioned is binary. Thoughts ..?