Access MF ISAM Files from not COBOL

[dbleyl]

Hello,

I need to get at some data that resides in files manipulated by COBOL. The COBOL version appears to be: Micro Focus Object COBOL V4.0 revision 007.

The files have idx, db and fd extensions. The idx appears to be mostly binary in vi, with some text, and the db appears to be mostly text with some binary.

The record layout has COMP, COMP-3 records. The data is 'live', and updated throughout the course of the day. The COBOL programmer has called the file an indexed isam file with a key.

However, I'm not a COBOL programmer, I just need to get at the data through Java, C++ or VB (in order of preference).

Any ideas appreciated. Thanks.

 

[Truusvlugindewind]

See thread209-683567

 

[dbleyl]

Thanks for the link. I actually read the post before posting - the problem is, our COBOL programmers are not familiar with that library (or whatever it is...), and I am not a COBOL person <i>yet</i>.

In the meantime, we have discovered a COBOL dll that exposes the files as a Win32 library. We are modifying that to suit our needs. The process has lead to more questions about COBOL, which I will ask presently in a separate thread.

Thanks again.

 

[Truusvlugindewind]

Your COBOL programmers are not familiar with that 'whatever'. That makes sence. When you code COBOL and compile with Micro Focus the 'whatever' is automatically included in the loads. Transparent to the COBOL programmer.

When you want to access those files from another language you must use this 'whatever'.
I would call it API's .
When you study the Micro Focus documentation (linked in the thread) it should be clear enough.

So, don't ask your COBOL programmers, they are not the target group, YOU ARE, programming in another language trying to access MF-files.

 

[dbleyl]

&quot;...a loadable file handling subsystem with an open architecture&quot; OK, so ExtFH is an API for non-COBOL programmers, well, there's one incomplete example in C.

The documentation is devoid of any type declarations, no header files, no include statements, no mention of libraries or object files, no procedures demonstrating how to load the modules/linking. No instruction on setting up the runtime, or what's required to use it.

I asked the COBOL programmers, because a.) it's in their manual, b.) the majority of examples are in ... COBOL.
I can see why they wouldn't be familiar - because they don't need to use it. So why are all the examples in COBOL?

Not very many hits on using this, most look like this:

http://groups.google.com/groups?q="...0210101636.21cf8f75@posting.google.com&rnum=6

Without answers. So as a C, Java, VB, Perl or <other> programmer, you're left with &quot;just what is required for me to use this <i>library</i> from my environment?&quot;.

So I prefer the 'whatever' to API, because this is just to nebulous to be called an interface. I have read this document 3 times, the workbench reference, all the threads I can find, and I just can't find any information.

But I found this:

http://supportline.microfocus.com/examplesandutilities/nesamp.asp#MixedLanguage

Which seems to advocate by exclusion, the use of a dll to expose COBOL file services to other languages.

 

[k5tm]

dbleyl, may I suggest another approach, Relativity, which makes the COBOL files available as an ODBC/JDBC datasource providing SQL access to your data.

http://www.liant.com/products/relativity/

We have many happy Micro Focus COBOL customers using this product.

Tom Morrison

http://www.liant.com

 

[jplubell3619]

The .idx files are just indexes to the primary data base files .db. The .fd -- My guess -- The files COBOL discription -- Thats how you know about the COMP fields? ODBC should access these files? But thats not allways possible with older versions of ISAM (The revsion you gave is fine). I's not clear if the .db file
is a ISAM file or some other database format. My guess is that its a Microfocus ISAM. M. Access should be able to
a least open this file to confirm the ODBC link -- if not try EXCEL (Should be easier and you can fiddle with the driver untill you find the right one)

Note: Sorry to say this about COBOL -- but if that file is indeed a ISAM format your ODBC may not be able to retrive the COMP data. The internal format of COMP data -- in most COBOL dilacts -- is set at compile time -- and they do very.

 

[Dimandja]

Another argument against the continued use of COBOL-only data types. Luckily, the COBOL compilers I use now allow for an INTEGER data type; which I now use in all new COBOL applications.

Dimandja

 

[k5tm]

jplubell3619,

You state: Note: Sorry to say this about COBOL -- but if that file is indeed a ISAM format your ODBC may not be able to retrive the COMP data. The internal format of COMP data -- in most COBOL dilacts -- is set at compile time -- and they do very.

Indeed, COMP data does vary in representation, often at the behest of compile-time directives or command line parameters. This variation is within the ANSI/ISO standard, so any reasonable product must either deal with COMP in all its variations or be a very flawed product.

I am happy to report that Relativity does not have this flaw. Indeed the issues of mapping between COBOL data types (including many implementor-defined -- the ANSI term -- data representations) and SQL data types is a complex matter. Of course, you missed an even more difficult issue: converting all of the many date formats invented over the course of computing history into SQL's native date data types; Relativity solves this problem too. See US Patent 5,826,076.

So, be assured that the concerns about which you now or might speculate have long ago been dealt with. Relativity works!

Tom Morrison

http://www.liant.com