>>>>I am trying to import data from a .dat file. I've got the data and am having only one problem.
>>>>There is a compression character evidently on a numeric field i.e. 38.50 is 385}
>>>>
>>>>I guess I need to know what characters represent 1,2,3,4,5,6,7,8,and 9. Can anyone help me?
>>>
>>>Look up "Hollerith" see if that's it. Those characters might be for negatives.
>>
>>The "trailing sign overpunch" format? It's been decades since I last heard of that.
>
>
>Yes. When I worked on a government contract in late 90s, early 2000s, we used that system for data processed out of COBOL-based mainframe accounting systems written back in the day. It came in three-entry-per-line formats with a right-most single digit identifying the type of data line. Typically a header record indicated how many detail lines to expect. But, there were still errors decades later. :-)
>
>Most exciting to decode a system like that in VFP which was never really designed to handle multi-record formats in a single table.

Oh, I had a bunch of those. I specially liked RM cobol, which mixed index and record blocks (and sometimes produced lots of slack in there), regularly had some redundant columns, and loved BCD packed decimals. And, of course, had no special format for dates, so the programmers regularly used ddmmyy format (this was the nineties, and code written in 70s and later).

But I get a chuckle out of the usual question "how do I open a dat file" (which is not a case in this thread). There are about five million in-house apps, written in cobol, which routinely created their files as .dat, which internally had all kinds of their own data types and no header - headers were in code. And on top of that, there are oodles of apps out there, written by unimaginative programmers (probably students of the first bunch) who again made their apps produce .dat files... so, by now, there may be millions of those. So the answer to "which program opens a dat file" has only two sure-fire answers: 1) it depends, 2) hex editor.