Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations Mike Lewis on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

convert MicroFocus Cobol/2 .dat files

Status
Not open for further replies.

sammydafish

IS-IT--Management
Feb 5, 2004
7
0
0
US
I need access to data in a software package who's publisher has been out of business for better than a decade. As far as I can tell the files are MicroFocus Cobol/2 data files. .dat and .idx files I have no cobol source files. The application has no tools for exporting data. Is there any way to do this? I've found a few different tools to try to get ODBC connections or simply dump to a txt file but nothing I have found seems to work.

If its helpful, I can get this info from the executable that runs the application.

Micro Focus COBOL/2 Toolset Version 2.4.18
RUN TIME ENVIRONMENT V2.3 rev 013 Copyright (C) 1985,1990 Micro Focus Ltd.
URN AREPA/ZZ0/00000 Ref 001.
 
First, you have to figure out the layout of the data in the records. If you have a report that displays or prints the data, that is a help. You also need to know how the data is formatted in the record.

COBOL supports several numeric data formats. In most formats, the numbers are scaled to units (this is called "fixed point" in some documentation) and then converted to the specified base. For example, take the value $1.25. If this in DISPLAY NUMERIC the value might be expressed as "00000125" or "0000012E". The same value in PACKED DECIMAL would be X"00 00 12 5F" or X"00 00 12 5C". In BINARY it would be X"00 00 00 7D"

Non-numeric data is usually in straight ascii format.

Next you need to know how the records are formatted. The .IDX file has no appllication data in it and can be ignored. The .DAT file contains records in VARIABLE RECORD LENGTH format (even if the records are all the same size, which is usually the case)).

The records start with a header field. This fields i either 2 or 4 bytes long. The first 4 bits of this field is the record type code. The next 12 or 28 bits is the length of the record in binary, which excludes the header & trailer fields. The length is the length of the data. The actual length of the record is the data plus the header plus trailer bytes. There will be 0-3 traileer bytes to make the length of the record a multiple of 4 bytes.

As you can see, extracting the data is quite conplex ane requires knowledge of the file structure as well as the application data.

I have a canned routine which will extract the application data. Code must be added to it to extract the various applications fields.
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top