Hello,
While using the file writer service available in the WmSamples package, the /n or carriage return at the end of the each line in the string is converted to a junk character looking like a square.

When the output file is viewed using notepad, it appears as a single record delimited by this square character, but was supposed to be a set of multiple records of fixed length.

Could anyone help us to sort this out?

Details of BC!
Version 4.6.

Thanks as usual.
Bhavani Shankar

Try viewing your file using Textpad or Ultraedit. You will find the contents as multiple records.

Hello Karthik,
Just to make the problem more clear. The same string when “Put” using FTP did not contain this character and the file appeared with fixed width. But we are facing this problem only when the File Writer service is used.

We are using notepad to view both the files. Have I missed something when using File writer??

Hope I have made it much more clearer!

\n will appear as an empty square in Notepad (pre-XP). It is not junk–Notepad just displays stand-alone \n and \r chars that way. The XP version of Notepad will display \n as expected.

When FTP’ing the file, what mode is being used? Text or binary? In text mode, I believe the receiving server is free to “normalize” end of line markers–changing \n to \r\n. That’s why Notepad would start showing the data as expected.

Rob - How do we normalize the end of line markers and force ‘\n’ to ‘\r\n’.

The reason for this question is we are having one service at the IS side received flatfiles from different systems (mainframe, windows, http protocol, etc). When we analyse the incoming stream, some systems send it with only ‘\n’ character and some have ‘\r\n’ character. The creates problems when we use convertToValues service along with flatfile schema with the file length as +2 (to accomodate \r\n). I need a way to force all the incoming data with \r\n when I receive only \n character.

Should I use a content handler to handle this ?

If you’re talking about incoming files sent by FTP, then Rob’s right - using text (or ASCII) mode will cause the \n characters to be converted to \r\n.

If you’re talking about using the file writer service, then the problem is a little different. The service will write whatever string you send it, by default using \r\n for any carriage returns. If you want it to use just \n on a Windows platform, you need your own file writer service that will properly convert the newlines. I use BufferedWriter.newline() when I want a newline character while writing out a file - that generates \n on Windows and \r\n on Unix.

Skip,
Should the string I have in the pipeline be tokenised. Later the String list must written line by line with a BufferedWriter.newline() in between? Guess, this would make the processing time far more, when the flatfile size is high.

The convertToValues output which is a fixed width string needs to be saved in a folder for further processing. But the Filewriter is unable to normalize the content.

Rob,
Details of FTP-PUT :
Transfermode = ASCII
Transfertype = PASSIVE

Thanks for the information and looking forward for more!!!

Bhavani Shankar