Extracting data from .dat cobol files
Charles W. Cribbs II
like just data files you open in wordpad or word. they are not files made
for word processors at all. depending on the type of files they can be two
associated files one being an index that will be unreadable to you and the
data part of the file.
your best bet to try to make they out is to use a product like transoft that
can perform queries based on the data fields.
you may have files that are random access, sequential, line sequential or
indexed. the only one you will be able to read easily is the line
sequential. you are going to have to figure out the record size and the
fields within the record before you can even design a table because if you
have the wrong data type you are screwed.
Ed Regan <ted....@virgin.net> wrote in message
news:8QIN5.81631$hk2.1...@news6-win.server.ntlworld.com...
> Our company has an antiquated stock control system that is programmed in
> Cobol and is very old. I'm in the process of upgrading the system in MS
> Access. I need to export the data files from the Cobol program into tables
> in Access, but there seems to be no logical structure in those data files
> i.e. they are not comman delimited or fixed width. I assume the format in
> which the data is saved was upto the discression of the person who
> programmed the original system. I have looked at the .dat files in a text
> editor and they seem to have no immidiatly recognisable structure
(although
> obviouly they must have). It would be unpactical to manually re-enter the
> data, as the customer file (cusma.dat) alone is > 20Mb.
>
> There are no report features in the program, so I can't retrieve the
> information this way. Also, the source code must have been lost in the
sands
> of time.
>
> Does anybody know of a way in which I can get my hands on this data
> considering I have no Cobol programming skills? Any help would be greatly
> appreciated.
>
> Thanks,
>
> Ed Regan.
>
>
Ed Regan
NA
Ed Regan <ted....@virgin.net> wrote:
[snippage]
>Does anybody know of a way in which I can get my hands on this data
>considering I have no Cobol programming skills?
Sure I know of a way... hire someone who *does*!
>Any help would be greatly
>appreciated.
(what are the odds that Mr Regan retracts this?)
DD
Russell Styles
the database with known values, ie "AAAAAAA" for first text
field,
"BBBBBBBBB" for second. Use numbers like 1111111.11 and
222222.22
for numeric fields. If you believe that the numeric fields are
packed or binary,
use a value that would be easy to spot in dump.
"Ed Regan" <ted....@virgin.net> wrote in message
news:8QIN5.81631$hk2.1...@news6-win.server.ntlworld.com...
Vadim Maslov
- We have a C++ library that can read Cobol data files and
convert them to "regular" non-Cobol formats used in C++, Java, VB.
It is called DataAccess.
- DataAccess can read indexed Cobol data files produced by
these Cobols: MF, FSC, RM, ACU, and sequential Cobol files
produced by any Cobol program.
- DataAccess handles any Cobol usage and PIC, and it handles
RENAMES and REDEFINES used in record description.
- A number of Cobol data file converters is built on top of this
library:
- Cobol file to Flat file (CSV).
- Cobol file to dBase IV DBF files.
- Data Reader for Crystal Reports.
- Flat CSV (comma-separated values) files
can be easily imported into Access or SQL database.
- You can license both the DataAccess library and
the specific converter tools.
- More details at http://www.siber.com/sct/datafile/
- You can start by sending us your data file for analysis.
We can recorver the record description even without
having the source for Cobol program that wrote these files.
Best regards,
Vadim Maslov
Siber Systems
Ed Guy
>
> When you say "there are no report features in the program" I presume you
> mean there are no report generation facilities. For the system to deserve
> the title of a "stock control system" it must produce many reports detailing
> the Stock, Customers, etc.
>
> Capture any of these relevant reports to a file, then write some simple
> programs to extract the information from these files and write to whatever
> type of data file you require. Of course you may have to capture the data
> from more than one report to, for example, get the complete Product file,
> but this is not complex.
>
> We have been using this method successfully for the last 20 odd years to
> convert new clients from their old systems to ours without requiring manual
> data entry.
ParseRat (http://www.guysoftware.com/parserat.htm) is one way to extract the data from
such re-directed print files (as well as a whole bunch of other file types). I wrote it
originally because I got fed up with writing "one off throwaways" for that purpose and
then marketed it at a level where your programmer must be REALLY cheap for the one-off
to be more economical.
--
Ed Guy P.Eng,CDP,MIEE
Information Technology Consultant
Internet: ed_...@NOSPAMguysoftware.com remove NOSPAM from email address.
http://www.guysoftware.com
"Check out HELLLP!, WinHelp author tool for WinWord 2.0 through 2000,
PlanBee Project Management Planning and Scheduling
and ParseRat, the File Parser, Converter and Reorganizer"
Robert Kovacic
mean there are no report generation facilities. For the system to deserve
the title of a "stock control system" it must produce many reports detailing
the Stock, Customers, etc.
Capture any of these relevant reports to a file, then write some simple
programs to extract the information from these files and write to whatever
type of data file you require. Of course you may have to capture the data
from more than one report to, for example, get the complete Product file,
but this is not complex.
We have been using this method successfully for the last 20 odd years to
convert new clients from their old systems to ours without requiring manual
data entry.
Regards, Robert Kovacic.
Lucas, Todd
created the files? That would be a starting point. Another would be to
obtain the source code of the program creating the file. In it would be
the definition and layout of the record structure, which may provide you
a clue of how to interpret it...
Hope it helps.
TL
Ed Regan <ted....@virgin.net> wrote in message
news:8QIN5.81631$hk2.1...@news6-win.server.ntlworld.com...
> Our company has an antiquated stock control system that is programmed
in
> Cobol and is very old. I'm in the process of upgrading the system in
MS
> Access. I need to export the data files from the Cobol program into
tables
> in Access, but there seems to be no logical structure in those data
files
<snip>
mitch...@my-deja.com
docd...@clark.net ( NA) wrote:
> In article <8QIN5.81631$hk2.1...@news6-win.server.ntlworld.com>,
> Ed Regan <ted....@virgin.net> wrote:
>
> [snippage]
>
> >Does anybody know of a way in which I can get my hands on this data
> >considering I have no Cobol programming skills?
>
> Sure I know of a way... hire someone who *does*!
>
> >Any help would be greatly
> >appreciated.
>
> (what are the odds that Mr Regan retracts this?)
>
> DD
>
>
Sent via Deja.com http://www.deja.com/
Before you buy.
NA
>In article <T_IN5.3060$5v6....@iad-read.news.verio.net>,
> docd...@clark.net ( NA) wrote:
>> Ed Regan <ted....@virgin.net> wrote:
>>
>> [snippage]
>>
>> >Does anybody know of a way in which I can get my hands on this data
>> >considering I have no Cobol programming skills?
>>
>> Sure I know of a way... hire someone who *does*!
Not at the rates I've seen him post, no.
DD
JamesC7460
> would be greatly appreciated.
>
> Thanks,
>
> Ed Regan.
Ed,
I can think of three things at the moment ...
1) Hire me.
2) Hire someone else.
3) Look for a product called Data Junction.
I know this since, having worked with COBOL for over 10 years and MS Access for
-, I know that Access will never understand the fixed field length, fixed
record length smacked-decimal with decimal point assumed data that are used in
most COBOL implementations. The data will have to be converted before you can
load and use it in Access and the only question left is how.
I'd suggest starting with #3 since if you did decide to hire me I'd probably go
that way too.
Good luck with your data conversion,
Jim
lcccpi...@my-deja.com
was used to write the program with the file structure in it. A
Copybook is often used to contain the file structure. It would be
catalogged in one of the system catalogs if it still exists. If you
could copy a small portion of the file you might be able to determine
the record size by using a window in Windows 95/98/NT and making it one
character larger at a time until stuff starts lining up. Some files
dont have line returns; you just have to know how long each record is!
If there is a sort in the job control that is used to execute the
program, look for the length of the record in the sort command!!!
A friend of mine used a program called EZTRIEVE it just converts files
to the appropriate structure. That might be worth looking into. He
couldn't even program in COBOL. COBOL doesnt used any delimiter for
fixed files. Sometimes files contain more than one record type or
organization. We have a file with nine seperate record types. All of
the record types would have some kind of key that identifies them.
It might be worth it to hire someone part-time or on the side to help
you.
In article <8QIN5.81631$hk2.1...@news6-win.server.ntlworld.com>,
"Ed Regan" <ted....@virgin.net> wrote: