How proprietary is the "COBOL file system"

Can anyone tell me if MicroFocus COBOL can read Fujitsu ISAM files, and vice
versa? What about Realia?

Obviously, at the source code level (SELECT and FD/01) the code is
compatible, but what about object level?

Is there a single PC ISAM system, or do all the COBOL vendors have their own
proprietary indexed system which is delivered with their COBOL compiler?

I know what I THINK the answer is, but would be gald to hear any other
facts/opinions about this.

Pete.
--
"I used to write COBOL...now I can do anything."

My memory (without verifying this) is that they canNOT read each other's
proprietary systems.  However, I think (but again am not positive) that all 
of
them have an option for using C-ISAM *instead* of their own "native" systems
.  I
don't know if this helps, but it might.

--
Bill Klein
wmklein <at> ix.netcom.com
"Pete Dashwood" <dashwood@removethis.enternet.co.nz> wrote in message
news:5m8mc4Fcb1ukU1@mid.individual.net...
> Can anyone tell me if MicroFocus COBOL can read Fujitsu ISAM files, and vi
ce
> versa? What about Realia?
>
> Obviously, at the source code level (SELECT and FD/01) the code is compati
ble,
> but what about object level?
>
> Is there a single PC ISAM system, or do all the COBOL vendors have their o
wn
> proprietary indexed system which is delivered with their COBOL compiler?
>
> I know what I THINK the answer is, but would be gald to hear any other
> facts/opinions about this.
>
> Pete.
> --
> "I used to write COBOL...now I can do anything."
>

On Sun, 30 Sep 2007 17:18:10 +1300, "Pete Dashwood" <dashwood@removethis.ent
ernet.co.nz>
wrote:

>Can anyone tell me if MicroFocus COBOL can read Fujitsu ISAM files, and vic
e
>versa? What about Realia?
>
>Obviously, at the source code level (SELECT and FD/01) the code is
>compatible, but what about object level?
>
>Is there a single PC ISAM system, or do all the COBOL vendors have their ow
n
>proprietary indexed system which is delivered with their COBOL compiler?
>
>I know what I THINK the answer is, but would be gald to hear any other
>facts/opinions about this.


All three are proprietary.

On Windows, Micro Focus uses its own External File System (extfs). On Unix, 
extfs is
available but the default is C-ISAM, which is owned by Informix, which is ow
ned by IBM.
There has been bad blood between the companies in recent years. MF refers su
pport
questions to Informix. They want you to use extfs.

I don't know about Fujitsu. I assume it's proprietary.

Realia is very proprietary. Marc Sokol said they spent more time developing 
the file
systsem than the compiler. In the MS-DOS era, it was blindingly fast.

The most likely place to find interoperability is in ODBC drivers.

On Sun, 30 Sep 2007 17:18:10 +1300, "Pete Dashwood" <dashwood@removethis.ent
ernet.co.nz>
wrote:

>Can anyone tell me if MicroFocus COBOL can read Fujitsu ISAM files, and vic
e
>versa? What about Realia?
>
>Obviously, at the source code level (SELECT and FD/01) the code is
>compatible, but what about object level?
>
>Is there a single PC ISAM system, or do all the COBOL vendors have their ow
n
>proprietary indexed system which is delivered with their COBOL compiler?
>
>I know what I THINK the answer is, but would be gald to hear any other
>facts/opinions about this.

Let's assume you have a Fujitsu program that wants to access Micro Focus fil
es.

1.  Write a file access program, compile under MF to a .dll, call it from Fu
jitsu.

2.  The MF extfh functions are well defined. Call them directly from Fujitsu
.

3.  Use ODBC.

--
"I used to write COBOL...now I can do anything."
"Robert" <no@e.mail> wrote in message
 news:a8huf3ppubdf9pd0gmtuiiv3s5efn19r0b@
4ax.com...
> On Sun, 30 Sep 2007 17:18:10 +1300, "Pete Dashwood"
> <dashwood@removethis.enternet.co.nz>
> wrote:
> 
>
> Let's assume you have a Fujitsu program that wants to access Micro Focus
> files.
>
> 1.  Write a file access program, compile under MF to a .dll, call it from
> Fujitsu.
>
> 2.  The MF extfh functions are well defined. Call them directly from
> Fujitsu.
>
> 3.  Use ODBC.

The requirement  is to access around 100 Fujitsu ISAM files. ODBC is not an
option. (I don't believe they provide a driver for their ISAM anyway, and
even if they did, it would be too unwieldy to set up every file on ODBC.  I
do use ODBC for access to RDB and find it very useful, especially for moving
RDBMS)

Currently, I generate a COBOL program to read the ISAM and write the
Database. This is a reasonable solution but has led to the (now solved)
problem of having  to remotely Batch compile COBOL  (covered in another
thread).

It was precisely because I have no easy way to access the ISAM from anything
OTHER THAN COBOL that I had to go for a COBOL generation, and that in turn,
made me think about the "illusion" of cross platform standardization that
COBOL is supposed to provide...

This "closed" COBOL file system has been one of the major contributors to
the decline of COBOL. I remember certain programmers feeling very smug in
the mid-80s because the corporate data resource was (apparently) locked into
COBOL and this therefore guaranteed COBOL's future. (I wonder where they are
now...)

Thanks for your response.

Pete.
--
"I used to write COBOL...now I can do anything."

"William M. Klein" <wmklein@nospam.netcom.com> wrote in message
news:qMGLi.150556$HU1.29309@fe05.news.easynews.com...
> My memory (without verifying this) is that they canNOT read each other's
> proprietary systems.  However, I think (but again am not positive) that
> all of them have an option for using C-ISAM *instead* of their own
> "native" systems.  I don't know if this helps, but it might.
>

Thanks, Bill.

I think that's right.  The problem is solved, (at least for this customer)
and I now have a tool set that can automatically migrate data and structure
from ISAM/ VSAM-KSDS to RDB, given the COBOL source definitions of the
Indexed files, without manual intervention.

I think most sites have converted to RDB long ago (it is quite a painful
manual process), but this will help with the ones who haven't... :-)

Pete.
--
"I used to write COBOL...now I can do anything."
> --
> Bill Klein
> wmklein <at> ix.netcom.com
> "Pete Dashwood" <dashwood@removethis.enternet.co.nz> wrote in message
> news:5m8mc4Fcb1ukU1@mid.individual.net... 
>
>

On Sep 30, 5:48 pm, "William M. Klein" <wmkl...@nospam.netcom.com>
wrote:
> My memory (without verifying this) is that they canNOT read each other's
> proprietary systems.  However, I think (but again am not positive) that al
l of
> them have an option for using C-ISAM *instead* of their own "native" syste
ms.  I
> don't know if this helps, but it might.

You may be thinking of Btrieve.

On Sep 30, 4:18 pm, "Pete Dashwood"
<dashw...@removethis.enternet.co.nz> wrote:
> Can anyone tell me if MicroFocus COBOL can read Fujitsu ISAM files, and vi
ce
> versa? What about Realia?
>
> Obviously, at the source code level (SELECT and FD/01) the code is
> compatible, but what about object level?

This is no better nor worse than with RDBMS or other databases. One
cannot put an Oracle database file into a PostgresSQL system. MySQL
data files can't work with Informix, etc.  Of course the _source_ SQL
is (mostly) compatible, but data has to be extracted and reloaded to
move it, possibly with conversion.

> Is there a single PC ISAM system, or do all the COBOL vendors have their o
wn
> proprietary indexed system which is delivered with their COBOL compiler?

C-ISAM file system is an X-Open standard and used by Informix, C (or
any C callable language), and MF Cobol. However, other ISAM systems
are faster, more compact, and more reliable.  Btrieve was another ISAM
system that tried to be a standard system for all languages.

> I know what I THINK the answer is, but would be gald to hear any other
> facts/opinions about this.

On Sep 30, 6:20 pm, Robert <n...@e.mail> wrote:
> On Sun, 30 Sep 2007 17:18:10 +1300, "Pete Dashwood" <dashw...@removethis.e
nternet.co.nz>
> wrote:
> 
> 
> 
> 
>
> All three are proprietary.
>
> On Windows, Micro Focus uses its own External File System (extfs). On Unix
, extfs is
> available but the default is C-ISAM, which is owned by Informix, which is owned by
 IBM.

You seem to miss the point about 'extfs', it means that _ALL_ formats
are external, ie not built into the base runtime system. C-ISAM is
external, C2 is external, BTrieve is external, your own homegrown is
external. Usually the one that is used is C-ISAM on Unix and C2 on DOS/
Windows and both of these are in 'extfs.dll' (or similar).

> There has been bad blood between the companies in recent years. MF refers 
support
> questions to Informix. They want you to use extfs.
>
> I don't know about Fujitsu. I assume it's proprietary.

Fujitsu uses mechanisms derived from their mainframe range to give
compressed data (RLL) and indexes in the data file.

> Realia is very proprietary. Marc Sokol said they spent more time developin
g the file
> systsem than the compiler. In the MS-DOS era, it was blindingly fast.
>
> The most likely place to find interoperability is in ODBC drivers.

This is not useful if the programs do READ/WRITE.

On Sep 30, 8:29 pm, "Pete Dashwood"
<dashw...@removethis.enternet.co.nz> wrote:
> --
> "I used to write COBOL...now I can do anything.""Robert" <n...@e.mail> wro
te in message
>
>  news:a8huf3ppubdf9pd0gmtuiiv3s5efn19r0b@
4ax.com...
>
>
> 
> 
> 
> 
> 
> 
> 
> 
> 
>
> The requirement  is to access around 100 Fujitsu ISAM files. ODBC is not a
n
> option. (I don't believe they provide a driver for their ISAM anyway, and
> even if they did, it would be too unwieldy to set up every file on ODBC.  
I
> do use ODBC for access to RDB and find it very useful, especially for movi
ng
> RDBMS)

Fujitsu on Linux provides a Callable File Handler that can be called
from C (or compatible) to access all Fujitsu files. It should be
possible to call this from MF.

This is also available in Windows, see 'File Access Subroutine Guide'.


> Currently, I generate a COBOL program to read the ISAM and write the
> Database. This is a reasonable solution but has led to the (now solved)
> problem of having  to remotely Batch compile COBOL  (covered in another
> thread).
>
> It was precisely because I have no easy way to access the ISAM from anythi
ng
> OTHER THAN COBOL that I had to go for a COBOL generation, and that in turn
,
> made me think about the "illusion" of cross platform standardization that
> COBOL is supposed to provide...
>
> This "closed" COBOL file system has been one of the major contributors to
> the decline of COBOL. I remember certain programmers feeling very smug in
> the mid-80s because the corporate data resource was (apparently) locked in
to
> COBOL and this therefore guaranteed COBOL's future. (I wonder where they a
re
> now...)
>
> Thanks for your response.
>
> Pete.
> --
> "I used to write COBOL...now I can do anything."