Fixed record

OH 4711 K0815 20130530

LIN0001S123 0005000009990

LIN0002H456 0003000017950

This an extremely simple example, but it covers the basics.

Let’s go through each line in detail.

OH 4711 K0815 20130530

• OH stands for order header here. This is the record type identifier that allows the software (or a human) to recognise what kind of record is being transmitted.The identifier is always three characters long, and is completed here with a space.
• 4711 is the order number, which is eight characters long and completed with spaces.
• K0815 is the customer number, which has the same length and is completed in the same way.
• 20130530 at the end is the order date, in yyyymmdd format (i.e. 8 characters long).
• Behind that comes another space, only you can’t see it right now (though you will later).

LIN0001S123 0005000009990

• LIN is the line item identifier. Because it already takes up three characters, there is no need to add a space to it.
• 0001 is the item number. It has a length of four characters and is completed with leading zeroes.
• S123 is the item number, followed by spaces to take it up to eight characters.
• 0005 is the quantity, which is four characters long, with zeroes added to take it up to the character limit.
• 000009990 represents 9.99, completed with filler zeroes before the value. Instead of using a decimal separator, it is simply specified that the last three digits represent the numbers after the decimal point. Total length 9.

Now, add the lengths of these different fields together. What do you get? 28, both times. To achieve this, a space is added to the end of the header line. If there were more than these two record types, they would all need to be long enough to make room for the longest one. Alternatively, you can just choose a standard computing number such as 64,

128 or 256. This is fairly typical for data formats of this kind, but not really compulsory. In principle, every record type can have its own unique length; however, that length would then need to be precisely defined.

By applying the rule that every record type must be the appropriate length, we can dispense with line separators (which are incompatible with many systems) and put everything together in one long sequence:

OH 4711 K0815 20130530 LIN0001S123 0005000009990LIN0002H456 0003000017950

Now you can see the space at the end of the order header.

An individual message is typically made up of various parts. These might include a header (as in the example above), and often a trailer record at the end, as well as information on individual shipments, call-offs etc., details on line items, and so on. In many formats, the record type appears right at the beginning. This is extremely practical, as we can then apply just one simple rule:

Look at the first characters of the file to find out what the record type is. With the help of the format definition, we now know how long this record type is and what values appear where. And then we simply need to look at the following characters to find out what is coming next.

All this talk of exact lengths for each record type is very nice in theory, but there are a few variations in practice. If we are taking a purist approach, then every record type really will need to be exactly the right length and have spaces added to fill up any unused characters. In addition, there is no line separation – everything is printed in one long sequence. That’s

great for machines to read, but not particularly pleasant for humans (see above). As such, individual records are often separated from each other by line breaks in practice.

Yet that in turn isn’t so great for the computer, since it will read the line breaks as extraneous characters and will need to take them into account when calculating the lengths of the records. In other words, a record type with 128 characters will in fact have 129 or 130 characters (LF or CRLF).

If we do separate the record types with line breaks, we can also omit the filler characters at the end while we’re at it. As a result, the header record above would suddenly be only 27 characters long, instead of the formally required 28 characters. This isn’t exactly what we initially expected from this format, but you will encounter these variations time and time again out in the wild.

There are a few other rules that aren’t necessarily compulsory, but are sometimes applied

in recognised fixed-record data formats:

• Numerical values are generally brought up to their defined character length using leading zeroes.
• Non-numerical values, by contrast, are completed using spaces added to the right of the actual value.
• Floating-point numbers generally aren’t represented using decimal separators; instead, we use a fixed number of implicit decimal places. For example, 3.05 (with leading filler characters) would become 00003050. The last three characters here are implicit decimal places. The number of decimal places in each case is usually specified individually for each value.
• Dates and times can also normally be written without a separator, and the formats yymmdd or yyyymmdd and hhmm or hhmmss are widely used instead.
• The record type identifiers generally appear at the beginning of the record – however, there are also formats (typically company-specific ones) that place the identifier somewhere in the middle of the data.
• Of course, if there is only one kind of record then we can dispense with identifiers altogether.

The two best-known exponents are Fortras and VDA (discussed here in their older formats). Both of these were developed and adopted by consortiums, and are discussed in their own dedicated articles. Then there is also the older IDoc format from SAP, which also forms the subject of its own asection. However, exports from databases (for example) are also often structured in this way – especially when the data come from an AS/400 (IBM iSeries). Every column in the table then has its own defined length, and often everything is written in one column in a single standard-length string. A few other programs also use files in fixedrecord format for imports and exports, as they are very easy to read. You simply move the file pointer along by e.g. 128 characters each time in order to automatically reach the next data set – and even within a single data set, you can just jump to the positions specified at the beginning in order to find the desired values. Back when most programs still stored their data in custom structures on CDs (or even floppy disks) instead of using generally accessible databases (which weren’t so readily available back then), this was the most practical solution for situations when not everything would fit on the storage medium.