Extracting Data from COBOL produced .DAT file

[doktord]

Hey guys,

I'm working on a program to run in conjunction with some software that was written in COBOL. The software produces and stores information in .DAT and .KEY files located on a server.

I need to access the data stored in these files to use with a program I'm writing in VB.

I've been searching around the forums and there really aren't too many threads out there about decrypting .DAT files and even fewer are able to successfully do it.

I've tried just simply opening the .DAT files in notepad and all I get are random numbers and symbols. I also tried opening the files in a free trial of DataViewer, which worked to a certain extent but still butchered some of the data.

I can provide pretty much any information that would be helpful in figuring this out. I can provide files to tinker with, some small programs, and I'm waiting to hear back from the software people as to what compiler was used to compile the COBOL program that makes the .DAT files.

I really appreciate your time and patience. I'm just a moderate level (if that) hobby programmer trying to get this program to work in conjunction with this software.

 

[doktord]

Thank you all for the input.. It makes a lot of sense now that I've been reading up on COBOL code and language.

Would you all agree that the .DAT/.KEY files are somehow linked indexed files? I can't seem to find anything ANYWHERE about the .KEY extension. In some cases, the .KEY file is larger in size than it's .DAT counterpart.

If this is the case, would COBOL automatically recognize the .KEY file as the indexing file when I write the code to open a .DAT file?

 

[doktord]

Also, I've just been informed that the compiler used to create the COBOL software was MF visual Cobol 3.6.

 

[Glenn9999]

Neither of these are tables or arrays - they are simple string variables - in C etc they may be arrays but in COBOL, and other languages, they are simple variables. Tables, aka arrays, are repeating variables e.g.

If you actually followed the conversation, I was trying to instruct a VB programmer how to read those variables into his VB program.

It is not possible for anyone to acknowledge truth when their salary depends on them not doing it.

 

[Glenn9999]

Would you all agree that the .DAT/.KEY files are somehow linked indexed files?

If this is the case, would COBOL automatically recognize the .KEY file as the indexing file when I write the code to open a .DAT file?

This is an implementation of a data file with an indexed file, which is called VSAM in mainframe terminology. In COBOL if you were to use this file, you would have to specially code for it in defining the file, and link it to a specific key field in the file record. The advantage of this file organization is that you can read the whole file sequentially, or give it a specific key and have the system look for a specific record. The second function is what the KEY file is for.

Also, I've just been informed that the compiler used to create the COBOL software was MF visual Cobol 3.6.

The Microfocus company does this compiler, which works on Windows, UNIX, and Linux (depending on the specific compiler) on the PC. So it should be relatively easy to get the file to something you can use in VB.

It is not possible for anyone to acknowledge truth when their salary depends on them not doing it.

 

[doktord]

Thanks guys.

I'll try writing some quick 'n' dirty COBOL code to see if I can't convert them to .CSV or some other delimited file.

I believe the key would be the item numbers, so I'll see if I can't get the indexing to work.

 

[k5tm]

The Visual COBOL for this situation is mbp compiler acquired by Micro Focus many years ago, and it was sunset probably a decade ago, and therefore unsupported. ODBC drivers and other data access tools are probably not available.

This is not to be confused with the recently released Visual COBOL, which is a new product released at the same time Microsoft released Visual Studio 2010.

So, your best alternative is to do what you have already started: write a COBOL program to extract the data. You will need to use the same compiler, because the indexed file formats are (most likely) proprietary.

Concerning the index or indices: can the same folks that provided ITEMFL.fd also provide a COPY file which contains the SELECT statement for the file? The SELECT statement contains the key (index) definitions.

Tom Morrison
Micro Focus

 

[doktord]

About the indexes, I'm pretty sure I know what the definitions are, but if I need to use the same compiler, I might just forgo the indexing. Its not that crucial that I use it.

As far as compilers are concerned, any suggestions as to which one to use? I looked into OpenCOBOL and Tiny Cobol. I've been having some problems with the OpenCOBOL installation. I'm running Cygwin along with it. Anyone have experience with either of these two freeware compilers?

 

[mikrom]

IMHO, the VSAM files created by several COBOL compilers are not binary compatible. So when your DAT-file was created by MF-compiler, I don't understand why are you lookng at the other compilers.

 

[Glenn9999]

We'll see. I already have PC code to go COMP-3 to text laying somewhere.

I went ahead and put this code into a DLL, and wrote a small text file for documentation. For this current case, it is probably best if it could be done in COBOL. But for whoever that wants to experiment with it, you can get the DLL here.

As said in the file, it's just TEST code, so I wouldn't be surprised if there was a problem or two somewhere.

It is not possible for anyone to acknowledge truth when their salary depends on them not doing it.

 

[k5tm]

Doktord,

It is quite possible that you can read the .DAT file as a sequential file without benefit of indexes. That was a 'feature' on a couple of the PC COBOLs which used the two file format, and it may have been a feature of mbp COBOL.

To try this, in the SELECT sentence (FILE-CONTROL paragraph), try ORGANIZATION BINARY SEQUENTIAL, and refer to the .DAT file with the ASSIGN clause. You should be able to use the ITEMFL.fd you have shown as is in the FILE SECTION (DATA DIVISION).

Good luck.

Tom Morrison
Micro Focus

 

[TonHu]

Are you getting the data from the file in a working (and a continues working) system, or is this a one-time conversion?

If the Cobol system keeps running you might want to look at Transoft U/SQL for a ODBC driver (

http://www.transoft.com/products/usql),

but you would need to create a UDD to match the data to be able to read it.
There are other suppliers for connectors like this, but we've been using this one for ages.

 

[doktord]

TonHu, the COBOL sowftware that creates the .DAT files will always be continuously running. This small program I am writing will only have to be run once a week.

 

[sirragu]

doktord,

this is a vsam (indexed file) send me the file and the layout and I will create you either a sequential or csv file, your choice....

 

[doktord]

sirragu,

I greatly appreciate you being willing to do that for me, but that wouldn't solve my problem.. I actually need to be able to do it multiple times when the program runs.. So I would need an executable file or the code itself to be able to read it over and over again.

 

[doktord]

Code itself would be ideal, so that way I could modify it to work with all the files I need to access. It's a slow process working with the programmers to find out which files contain the pieces of information I need to work with. At the moment I'm looking at at least 5 separate files, and figuring out the COBOL code to read them is proving to be a slow going process.

 

[Glenn9999]

It's been a little while, so I have to ask. How are things, progressing, doktord?

It is not possible for anyone to acknowledge truth when their salary depends on them not doing it.

 

[doktord]

Well Glenn,

I finally got my hands on the MicroFocus compiler, so at the moment I'm going through a book I found on COBOL language and I'm just trying to get a feel for the basic layout of the code. Slowly but surely I'm beginning to get used to it.

 

[webrabbit]

Define the file as RECORD SEQUENTIAL with variable length records (even if all records are the same length)

 

[doktord]

I tried to define it as RECORD SEQUENTIAL but it threw back errors. Should I be able to read/treat the indexed file as sequential?

 

[webrabbit]

What errrors resulted? It may not work the same way with that compiler as it is not originally Micro Focus.