You are here : Funding  >  MACSIS / MITS  >  Technical Documentation  >  EOL Issues Revisited
End of Line Markers Revisited

It strikes me that with HIPAA related changes, we are going to return to the Valley of Confusion about what could be, should be, and is going to be used as the End-of-Line (EOL) marker within the data files being constructed and exchanged in the new MACSIS HIPAA related world. I thought it might be time for another pedagogical device – or at least another handout.

In this explanation, I am really striving to reach everyone I can – please forgive me if it would appear I am “talking down” to you, I am trying to make no assumptions about what my reader might already know, so this is supposed to be something like “The Dummy’s Guide to End of Line Marker.”

Something a lot of people never have cause to realize is that How the Computer does things is not necessarily very intuitive and in fact, it can be downright confusing if not devious. When you look at the above sentence, the first line ends with “is not,” and the next line begins “necessarily.” Somehow the software needs to understand where the line ends, i.e., when to go on to the next line. That location, the intended “end of line” is marked or indicated by the use of a “non-printable” code. If you want to get technical and “picky,” everything I have typed (and you read) is encoded. That is, the computer does not store these nice screen (or print) letters, but what are called ASCII codes which represent those letters.

That’s why, having typed up a note, you can decide to change the font. If the computer actually stored pictures of these little letters, how would it know to use a different typeface. Fact is your computer encodes everything, typically into ASCII code values. You computer also places a code to indicate when you indicated a particular line should end – something for our purposes we will cleverly call the “End-of-Line (EOL) marker.”

The operating system of your computer determines what EOL code or marker will “typically” be used. No, let me say that a little better. Most application software will use the EOL code that has been built into the operating system of your computer. There is no reason however, that it has to do so – software which “builds and saves” a file has the option to use whatever it wants as the EOL (or even the End of File) code. Most of the time, application software uses the computer’s operating system’s built-in or default value.

That makes our world a little easier, one does not have to think about or declare an EOL code – somebody else, either the application software or the operating system will take care of it. Unfortunately this well- meaning situation, while it makes your world easier in one sense, does not necessarily make it more simple. When you make file to give to someone else, especially a “data file,” you may well need to understand what EOL code they expect and ensure that your file meets their expectations.

Back to top

Before we get to that, let me give you just a bit more on EOL codes. As I said, any given application software can use whatever it wants as the EOL marker for its internal use, most software uses one of the typical or standard-possible codes. Windows/DOS machine have always used a two-byte (two character) code for EOL: Carriage Return (CR) and Line Feed (LF) are the names for these codes. In fancy computer language we “techies” would say ‘0A’x and ‘0D’x – or “zero-A” and “zero-D” hex (hexadecimal). Most flavors of the Unix operating system use only ‘0A’x (line feed) only as their End of Line Marker. I believe older Macintosh systems used ‘0D’x (carriage return) only, I am not conversant with the new OS-X Macintosh operating system.

A bottom line: You wish or need to send me a data file. I need to well (and easily) understand where each line ends and the next begins. We’re specifying that a data file submitted to MACSIS for the HIPAA process to use a LF only End-of-Line marker. That is, we want the segment delimiter in your ANSI X12 837 Professional claim to be ‘0A’x.

Now, don’t be alarmed. Its possible to get worried at this point: “What if I make my file on a Windows PC? Won’t that use LF-CR, but you want LF only! Do I have a problem?” The simple answer is no, you do not have a real problem at all. The world of computers came up with a solution to this dilemma a long time ago. If you understand what EOL marker you have in your data file, and what EOL marker is expected by those you would share or send your file, then the solution is relatively easy. Peace and happiness need just that much knowledge (and a touch of compulsivity).

The MACSIS project has always supported file transfer using FTP software (and protocol). FTP governed file transfer has a couple of “modes” or styles – the use of the ‘correct or needed’ style for your transfer circumstances will quite likely solve your problems about having a EOL code that does not match what someone else needs. Let me run a couple of possible scenarios by you to help clarify:

Situation 1: You are building your data file (ANSI X12 837 Professional) on a Windows 2000 PC with software that uses the machine’s operating system (OS) to determine each line’s End of Line marker. So all your data lines, what the ANSI X12 world calls “segments,” end in ‘CR,LF’ codes.

Problem? No. When this file is transferred to us, if you simply use the ASCII mode of FTP, the file’s EOL codes will be translated into what is needed on our machine’s operating system. In other words, ASCII mode of FTP is sometimes referred to as “look ahead” mode: inquire what the OS is of the host or recipient, and translate what you find here (on the sender) to what is needed (on the host). Your “CR,LF” codes will be reset to “LF” as received on our server.

If your software has used your operating system’s default EOL marker, this ASCII mode of FTP solution should work like a charm. No matter what your computer or our computer, FTP (in ASCII mode) takes care of things.

Back to top

Situation 2: You are constructing your data file on a Unix server, using software that sets the EOL code by the OS’s default (LF only).

You have no problem. We would recommend again you use ASCII mode of FTP in your file transfer. Your computer running FTP should look ahead, see a fellow unix computer, and leave the LF end-of-line-markers as they are, no translation necessary.

So the most basic rule is simple use ASCII mode of file transfer and let the software handling the file movement to get this End-of-Line marker business correct all by itself! One little caveat though, all the FTP software that I know of, including the MACSIS Project’s “standard” FTP software (WSPRO from Ipswitch Software) makes the assumption that your data file will have the End of Line code that is the default value of your computer’s operating system.

Let’s consider a third, and more messy Situation 3: You are using a Windows/DOS computer to build your data files – but – that application software does not use the Windows OS standard “CR,LF” codes to indicate End-of-Line. Instead, for whatever vendor reasons or logic, your application software uses “LF” only to indicate a new line (even though this is a Windows computer). As I said early on, application software programmers have the ability to declare any EOL code they wish.

So rats!, even though you are working on a Windows machine and might expect that “CR,LF” end each segment or line, instead your file actually uses “LF” only. Hey, wait a minute. “LF” only is what (those clowns at) MACSIS want, I don’t have a problem! Well, truth is. You don’t have a problem, and you do. It depends on how you handle or transfer the file. If you simply fired up your FTP program and used ASCII mode to transfer the file – you have a problem. ASCII mode would sense you have a windows machine, it would then expect every line ends with “CR,LF” and it would try to faithfully translate those into “LF” only – but it gets confused because “where are the CR codes?” Things will get knocked askew.

In this Situation 3, you need to understand that the file you have made on your computer is not “standard to your operating system.” You also will need to know the nature of the host machine to which you are sending your file. In this example, if you knew our host machine was a Unix (AIX) computer and that you had a data file with “LF” only end-of-line markers – you would simply use Binary mode in your FTP. Binary (or image mode) instructs your FTP software NOT to look again, move this file exactly as it is to the receiving computer. Your “LF” only EOL file would come to our Unix server and we’d be very happy.

Back to top

The MACSIS bottom line: we need to receive a well formed ANSI X12 837 Professional Claim with “LF” only (‘0A’x) as the segment or end-of-line marker. Its easy if your application software uses your OS default EOL marker – then everyone handling the file should just use ASCII mode of FTP (or its equivalent). You do need know what EOL code your software is using! If by chance it is not the standard for your computer’s OS, you will need to come to understand the necessary handling steps that might be needed.

We can help with that if you need it. I think you can trust that it will not be difficult to come to understand the steps needed. Then its just attention to detail (if not compulsivity). Probably the most important thing to understand at this point is that you must comprehend both (1) how the data file was constructed and (2) how it was handled in its journey to the MACSIS process.

Jonpaul R. Martin, Ph.D.
MACSIS Technical Support
Office of Information Services
Ohio Department of Mental Health

Postscript: Its been my experience that folks who normally would be perturbed to have to know about things like hexadecimal codes and such still can get curious at times and want to see these things first hand – yes, it’s a touch of “nerdness” that can overtake you in a weak moment. Make your self a little data file: using Word or Word Perfect or Wordpad, etc. Type some numbers, then hit Return and go to the next line and type a few more – do this for 3-4 data lines. Now save the file as text or ASCII. Do not save it as a Document. Now, if you can find a decent “editor” software, you can look at the file in ASCII or you can look at the file in hexadecimal (or both at the same time in fancier software). For this kind of task we often use Visual Slick Editor, that’s our Project’s standard editor software. Opening a file with this product and you can very quickly mouse-click to a hex view – and see the codes which mark the end-of-each-line. You can actually do some of this even with a product like Word by “turning on the formatting marks,” problem is it will not show you the hex codes per se, it will just should you a symbolic marker. Such things (ASCII codes) are much easier to see with real file editing software.