export data from Cobol data files 1

[piterb]

Hello
I have a problem. I need to export data from Cobol data files (dat, inx) to anything else (txt, cvs, excel access, whatever). I need to do this using C# and .NET platform. But I cannot open or read this files (I tried as flat file with fixed row size and separator, I tried different data readers like SiberDataViewer or even simple notepad) if open file I can see only strange characters. I wonder I anyone know some ODBC driver or data reader which will be able to open and read this files (free or with demos, trials to check if it works witch my dat,inx files before I buy it). About files – I know that they contain information about daily incomes/outcomes, guests, rooms, services etc. in hotel chain. Hotels use Cobol application called ReHot which store data in dat(data), inx(indexes) files. Software vendor of course won’t help and application cannot export data to different files only print them on fiscal printer.
I will be very glad for any help/advice/suggestion you can offer me to solve this problem.
Piter

 

[Glenn9999]

It sounds like some kind of VSAM implementation (DAT = records themselves; IDX = index to the records). The first thing that would be useful would be to identify the compiler/development environment that this program was created in, which might shed some light on the files involved.

The files are in simple binary code, unless some encryption hasn't been applied. Which means it would be useful if you had the source describing the record format of these files. If I read your post right in saying that "the vendor won't help", that probably means all you have is the executable, which means you won't have this.

The vendor would have likely made this closed-source, which probably means there are EULA considerations involved. Speaking of which, I'm not finding anything when I google the terms you used.

Anyhow, unless you have the record format of the file (Is this on the vendor website?), you're pretty much out of luck.

----------
Measurement is not management.

 

[mikrom]

Here is such a tool, which should convert data from different COBOL file formats:

http://www.adtools.com/products/windows/dconv.htm#3

 

[piterb]

Vendor name is gip (unfortunately web site is in Polish so you wont be able to read it but I checked and there is only description of the software for customers, nothing for programmers )

Also I don’t have any record format of these files. If I had this format probably I wouldn’t need yours help. But right now I still need :/

 

[Glenn9999]

Well you can try loading the DAT file up in a hex editor and then start making guesses based on what you see, relating it to the known data from within the program (like text strings). Then test by writing the data to see if the record is identical to what the program writes. Trial and error, more or less.

Sorry that there isn't more help, but that's really all you can do without having the record definition.

----------
Measurement is not management.

 

[mrregan]

Another possiblity might be to somehow divert the printed reports to a file instead of the printer. Then you would have to parse the print lines as data.

 

[v0520]

Are you sure this isnt an ebcdic format file also?
Thats a possibility..

If its mainframe or mini based, its probably ebcdic, you can use ftp to download local and then it should convert ebcdic back to ascii..


Gilbert M. Vanegas
Senior Programmer Analyst
County of San Bernardino - ISD

 

[fredericofonseca]

no. if it is from a mainframe, downloading the file to ascii will most likely just make it unusable.

If you can determine what is the COBOL vendor/version used on those programs, then it will make it easier to determine which tool can help you do it yourself.

The vendor SHOULD give you this information, as well as the FILE layout of all your files (but not necessaraly the relation between each one).

The other option is as mrregan mentioned, to print all type of extracts into a flat file, and then process that file using your language of choice

Regards

Frederico Fonseca
SysSoft Integrated Ltd

http://www.syssoft-int.com

FAQ219-2884
FAQ181-2886

 

[mikrom]

Are you sure, that the application is written in COBOL?
I remember, that e.g. Foxpro index files had suffixes *.INX too.

At the bottom of

http://www.gip.com.pl/download/ReHot.pdf?tl=5

they write about daily and mothly reports in Excel format and about storing the statistics reports (daily and monthly) in central a SQL database.

To identify the format of the mentioned data file, it would be best, if you can post elsewhere an sample *.DAT file to download.

 

[mikrom]

According to

http://www.gip.com.pl/dp/cms/producti.xml?mp=mid117&mi=mid117

it's not on mainframe. The ReHot software should run on dedicated server (Novell, Windows 2000) or without server (Windows XP)

 

[mikrom]

It could be RM/COBOL. It has .DAT and .INX files
see e.g here:

http://www.liant.com/download/pdf/CnvGuide.pdf

http://www.liant.com/download/pdf/rmcug80.pdf

 

[mikrom]

You can find some things about COBOL data formats here at wotsit:

http://www.wotsit.org/list.asp?search=COBOL

 

[piterb]

Thx for all your advices I checked most of them (still checking ).
“At the bottom of

http://www.gip.com.pl/download/ReHot.pdf?tl=5

they write about daily and mothly reports in Excel format and about storing the statistics reports (daily and monthly) in central a SQL database.”
- Yes but this is not a ReHot feature but extra paid addon :/ and I don’t know if my client has it (checking right know)
Meanwhile I attached some files maybe one of you will be able to open it

http://www.box.net/shared/vce1r4rohh

Piter

 

[mrregan]

The 'dat' files appear to contain mostly comp numeric
fields, not binary. Comp numeric fields store some number of digits in half the space of the picture, for example: 10 digits in 5 bytes. Impossible to say what the values mean or where they start and stop. The inx files are meaningless to the data in question.

 

[mikrom]

I tried convert the DAT-files using DataTools contained in the NetExpress Free edition, but without success.
Then I tried to analyze the file in HEX. The most frequent are characters 00 and the characters 0F occure regularly. So it seems that 0F could be field and/or record delimiter.

 

[mikrom]

In the previous post I examined the file Bp081005.dat
The file seems to have a record of the length 774 bytes and seems to contain 277 records.
If you multiply record length with number of records, i.e 774*277 = 214398, what exactly is the file length of Bp081005.dat.

 

[piterb]

Thx I will check it and see if I can use this info
Maybe I wwill find size of the collumns
Piter

 

[webrabbit]

This is not Micro Focus indexed file format, must be something else.

The X'0F' is in a way a delimiter. This is the last byte of a packed decimal field. The 0 is the last (rightmost) digit of the value, and the F is the sign (none). The first half-byte could be any decimal digit, the second half-byte could be any hex value > 9. C, D, and F are most common. B & D are treated as negative, F is unsigned but treated as positive, A and E are uncommon but would be treated as positive.

 

[mikrom]

> Maybe I will find size of the collumns
The column (or field) separator seems to be the hex character 0F so for column length you only need count the bytes between 2 separators.

 

[piterb]

I checked it and nothing… I even read whole file to byte table and try to read anything like this

FileStream fs = File.OpenRead(@"C:\file.DAT");
BinaryReader br = new BinaryReader(fs);
byte[] by = new byte[br.BaseStream.Length];
by = br.ReadBytes(Convert.ToInt32(br.BaseStream.Length));
for (i = 0; i < by.Length-10;i++)
{
richTextBox1.Text +="\n"+i.ToString()+ " -> "+ BitConverter.ToInt16(by, i) + " "
+ BitConverter.ToInt32(by, i) + " "
+ BitConverter.ToInt64(by, i) + " "
+ BitConverter.ToChar(by, i) + " "
+ BitConverter.ToDouble(by, i) + " "

And so on.
And found nothing.
But thx you all for suggesions. If somenoe come up witch sth else let me know.