@Arí-Ricardo-Ody said in Notepad++ change characters while open a file?:
There is a cobol program on an IBM mainframe that requires the data it handles to have a hex x’0D’ after the last byte of each line.
I’m just trying to prepare a text file in Notepad++ that will be transmitted to the mainframe.
As @Alan-Kilborn said, that means your mainframe is expecting Macintosh-style line endings.
In case you don’t understand line endings (most Windows users do not – though I would think anyone who was working on a Windows machine for an IBM mainframe would), there are three common sets of bytes that refer to the end of a line for text/source-code files:
Unix/Linux: uses a line feed (ASCII 10, aka x’0A’ in your hex-based nomenclature, aka LF)
Old Macintosh (and apparently IBM mainframe cobol compilers): uses a carriage return (ASCII 13, aka x’0D’, aka CR)
Windows: uses a carriage return followed by a linefeed (ASCII 13 then ASCII 10, aka x’0D’ x’0A’, aka CRLF)
Notepad++ defaults to using Windows line endings… unless you are opening a file that already has a Linux or Mac style line ending consistently used throughout, in which case it will auto-detect the right ending.
So this means you are creating a new file from scratch, and thus it defaulted to Windows CRLF endings. Use the method Alan showed (or right clicking on the “Windows (CRLF)” on the lower-right of the Notepad++ status bar) to change the line endings.
f268559d-77b7-4293-80ee-55a4016969bc-image.png
Also, if you are using FTP to get the cobol source code from the Windows PC to your mainframe, you will have to pay attention to ASCII vs BINARY transfer mode: BINARY will transmit the bytes as-is; ASCII will convert CRLF on your PC to the native line-ending format of the destination machine, and vice versa, as long as the FTP server on the other end is configured correctly. Make sure you understand how your FTP client (or whatever file-transfer protocol you use: rcp, sftp, ftps, going across a SAMBA server, or whatever) deals with line endings, because no matter how careful you are in your text editor, if your transfer protocol changes things, you will get more confused.
I didn’t understand your censure when you say that I’m doing it wrong, without knowing the reason why I’m doing it.
His censure was because you were going about it wrong. (And more over, his actual phrasing was “don’t do what you are attempting… unless you can provide sound reason for doing so”. There was a sound reason for wanting x’0D’ as the line ending (because your IBM mainframe Cobol compiler wants that line ending)… but you were just going about the process in the wrong way when trying to get a necessary line ending (or at least, what you described yourself as doing was wrong; I cannot know whether you were actually doing it right and just didn’t describe it correctly).
To clarify why the way you described is the wrong way: just arbitrarily adding the x’0D` byte to the end of lines that already have x’0D’ x’0A’ as the line ending won’t do what you want… because then the bytes will be either x’0D’ x’0D’ x’0A’ or x’0D’ x’0A’ x’0D’ (depending on where on the “end” of the line you added the x’0D’), which will not be what your compiler would want. The way you described things, you were fighting against the way that both KEDIT and Notepad++ deal with line endings, and hoping it would come out right, rather than understanding line endings and the tools you were using to get them to natively use the right line endings.
So your end goal was reasonable. And Alan and I have now explained how to make Notepad++ give you your end-goal in the correct manner.