Cobol's File System Vs. RDBMs...

Hi Folks,

Many years ago most Cobol developers have came to the
conclusion that Cobol's file system is closed, especially
when access to corporate data is required, and perhaps it
should be replaced by RDBs wherever possible.

Thus my question is:

Why Cobol's vendors do not develop their indexed file
systems to be as open and robust as, file systems in
database management systems such as SQLs, SAP and
Oracle?

Appreciate your comments.....

"softWare design" <sabraham@baxglobal.com> wrote in message
news:ad48ac76-1b00-452e-b289-22d66a366228@56g2000hsm.googlegroups.com...
>
> Why Cobol's vendors do not develop their indexed file
> systems to be as open and robust as, file systems in
> database management systems such as SQLs, SAP and
> Oracle?

First, comparing COBOL [compilers] with SAP and/orOracle[is comparing
applies and oranges. COBOL is a programming language, SAP an applications
suite, and Oracle either a DBMS or application suite.

COBOL v SQL is a fairer comparison in that both are standard
'languages')....however, neither has anything do with "openness" beyond its
officially supported syntax.

"Robustness" is more appropriately considered in the context of brand
comparisons of like products.

Second - a guess to answer the question as I think you meant to ask it.. or
perhaps answering the question which should have been asked....

COBOL compliler vendors do not offer more extensive data access facilities
because vendors as of COBOL compilers they are concerned with supporting the
COBOL access verbs, not with trying to create a competive standalone DBMS;
nor are they particularly interested in supporting access by
non-COBOL-developed programs, since that would be cutting their own throats.

FWIW, many vendors do offer "Applications Programming Interfaces" to their
own DBMS systems, supported by the COBOL "CALL" verb. If you don't like the
'native' file management system provided by the compiler vendor, you are
perfectly free and able to use another data management scheme.... bearing in
mind those other systems have no obligation to support the COBOL syntax for
media storage access.

MCM

On Wed, 23 Jul 2008 12:29:57 -0700 (PDT), softWare design
<sabraham@baxglobal.com> wrote:

>Many years ago most Cobol developers have came to the
>conclusion that Cobol's file system is closed, especially
>when access to corporate data is required, and perhaps it
>should be replaced by RDBs wherever possible.
>
>Thus my question is:
>
>Why Cobol's vendors do not develop their indexed file
>systems to be as open and robust as, file systems in
>database management systems such as SQLs, SAP and
>Oracle?
>
>Appreciate your comments.....

I suspect most CoBOL developers work with mainframe & mini computers.
In that case, they use the same file systems as everybody else.

So I infer that you find indexed file systems used by Windows based
CoBOL programs to be less than robust. Those are where the file
system had to be created by compiler makers to make up for Windows
shortcomings. I haven't had experience with them - what are their
lacks?

On Jul 23, 1:22*pm, Howard Brazee <how...@brazee.net> wrote:
>
> I suspect most CoBOL developers work with mainframe & mini computers.
> In that case, they use the same file systems as everybody else.
>
> So I infer that you find indexed file systems used by Windows based
> CoBOL programs to be less than robust. * *Those are where the file
> system had to be created by compiler makers to make up for Windows
> shortcomings. * *I haven't had experience with them - what are their
> lacks?


Yes, I am referring to indexed file systems that are created by
compiler makers on Windows based networks (2k and XP).
They tend to get corrupted frequently for various reasons
especially when storing massive number of records.

They are also considered to be Closed systems. Accessing
them by external clients or customers would require creating
new programs to get into the data with the desired formats.

On Jul 24, 7:29*am, softWare design <sabra...@baxglobal.com> wrote:
> Hi Folks,
>
> Many years ago most Cobol developers have came to the
> conclusion that Cobol's file system is closed, especially
> when access to corporate data is required,

What survey data did use to come to this conclusion ?

On mainframes and many other systems the 'Cobol file system' is the
'Operating System's file system'.

> and perhaps it
> should be replaced by RDBs wherever possible.

Being replaced by RDBs was for the functionality, not because of lack
of access.


> Thus my question is:
>
> Why Cobol's vendors do not develop their indexed file
> systems to be as open

On Unix and DOS/Windows where there is no built-in indexed file system
many Cobols give the facility to use C-ISAM (which was adopted by X/
Open as a standard) and/or BTrieve which is common with Netware.

Several also use a call interface which allows replacement of the file
system by some other and/or use of the called routines by other
languages.

> and robust as, file systems in

I find that the Microfocus and Fujitsu indexed systems to be robust.
But then I use these on Linux.

> database management systems such as SQLs, SAP and
> Oracle?

These file systems are proprietry and are _NOT_ 'open'.

On Jul 24, 9:49*am, softWare design <sabra...@baxglobal.com> wrote:
> On Jul 23, 1:22*pm, Howard Brazee <how...@brazee.net> wrote:
>
>
>
> > I suspect most CoBOL developers work with mainframe & mini computers.
> > In that case, they use the same file systems as everybody else.
>
> > So I infer that you find indexed file systems used by Windows based
> > CoBOL programs to be less than robust. * *Those are where the file
> > system had to be created by compiler makers to make up for Windows
> > shortcomings. * *I haven't had experience with them - what are their
> > lacks?
>
> Yes, I am referring to indexed file systems that are created by
> compiler makers on Windows based networks (2k and XP).
> They tend to get corrupted frequently for various reasons
> especially when storing massive number of records.

Then do not use Windows. Use a more reliable system.

> They are also considered to be Closed systems. *Accessing
> them by external clients or customers would require creating
> new programs to get into the data with the desired formats.

Cobol has been able to access SQL databases for many years, some, such
as Fujitsu, have SQL preprocessor included, for others you would use
the preprocessor that comes with your database system.

There are also products that give ODBC access to the Cobol files.

The "external's" (how it works and how you specify it in the language) of COBOL
formats (sequential, indexed, and relative) are specified in the ANSI/ISO
Standards (and have been for decades). ORIGINALLY, most COBOL vendors worked in
environments where these file systems were provided by the operations system
(usually sold and developed by the same person as the hardware).

When it comes to Unix (Linux) and Windows (previously DOS and OS/2), this is NOT
true. There are some "independent" file systems (particularly for indexed
files) such as Btrieve and C-ISAM. Most (possibly all?) COBOL compilers that
work in such environments provide support for interfacing with those (indexed)
file systems. I think (but am not positive) there are some that also allow for
an RDBMS to be the "physical" system behind a COBOL indexed file system.

HOWEVER, many *nix/Windows users WANT to use an indexed system that doesn't
require any "add-on" product (indexed file system or RDBMS). For those users an
"ANSI-conforming" (proprietary) Indexed system is provided by most (all?)
vendors that operate in such environments. The "robustness" of those file
systems are in direct relationship to how many PAYING customers demand/expect
robust indexed file systems for their applications.

MOST (certainly not all) COBOL applications that are now "developed" for
production use on *nix/Windows use RDBMS for data storage. The robustness of
such systems are, again, in direct relationship to how customers use them (and
what they are will to pay for).

--
Bill Klein
wmklein <at> ix.netcom.com
"softWare design" <sabraham@baxglobal.com> wrote in message
news:bec7bcc3-f0ba-4db3-8a72-439c686373e5@m73g2000hsh.googlegroups.com...
On Jul 23, 1:22 pm, Howard Brazee <how...@brazee.net> wrote:
>
> I suspect most CoBOL developers work with mainframe & mini computers.
> In that case, they use the same file systems as everybody else.
>
> So I infer that you find indexed file systems used by Windows based
> CoBOL programs to be less than robust. Those are where the file
> system had to be created by compiler makers to make up for Windows
> shortcomings. I haven't had experience with them - what are their
> lacks?


Yes, I am referring to indexed file systems that are created by
compiler makers on Windows based networks (2k and XP).
They tend to get corrupted frequently for various reasons
especially when storing massive number of records.

They are also considered to be Closed systems. Accessing
them by external clients or customers would require creating
new programs to get into the data with the desired formats.

softWare design wrote:
> On Jul 23, 1:22 pm, Howard Brazee <how...@brazee.net> wrote:
>>
>> I suspect most CoBOL developers work with mainframe & mini computers.
>> In that case, they use the same file systems as everybody else.
>>
>> So I infer that you find indexed file systems used by Windows based
>> CoBOL programs to be less than robust. Those are where the file
>> system had to be created by compiler makers to make up for Windows
>> shortcomings. I haven't had experience with them - what are their
>> lacks?
>
>
> Yes, I am referring to indexed file systems that are created by
> compiler makers on Windows based networks (2k and XP).
> They tend to get corrupted frequently for various reasons
> especially when storing massive number of records.
>
> They are also considered to be Closed systems. Accessing
> them by external clients or customers would require creating
> new programs to get into the data with the desired formats.

The inability of external clients or customers to get into a file an muck
about is a benefit, not a shortcoming.

"softWare design" <sabraham@baxglobal.com> wrote in message
news:bec7bcc3-f0ba-4db3-8a72-439c686373e5@m73g2000hsh.googlegroups.com...
On Jul 23, 1:22 pm, Howard Brazee <how...@brazee.net> wrote:
>
> I suspect most CoBOL developers work with mainframe & mini computers.
> In that case, they use the same file systems as everybody else.
>
> So I infer that you find indexed file systems used by Windows based
> CoBOL programs to be less than robust. Those are where the file
> system had to be created by compiler makers to make up for Windows
> shortcomings. I haven't had experience with them - what are their
> lacks?

[Pete]

That's a bit unfair, Howard.

The COBOL file system on Windows desktops was not implemented to make up for
Windows shortcomings, it was because you can't call it "COBOL" unless you
provide these modules of the language.

You might as well say that Indexed Sequential files on mainframes were
invented because of shortcomings in the IBM OS.

[/Pete]


Yes, I am referring to indexed file systems that are created by
compiler makers on Windows based networks (2k and XP).
They tend to get corrupted frequently for various reasons
especially when storing massive number of records.

They are also considered to be Closed systems. Accessing
them by external clients or customers would require creating
new programs to get into the data with the desired formats.

[Pete]

There are some connotations to the word "closed" that can cause
misunderstanding.

I agree with you that the COBOL file system is "closed", inasmuch as you
need to write a COBOL (or other) program which knows the structure of it, in
order to access it. Certainly, some systems have ODBC drivers that permit
access but the basic problem is that, unlike a DBMS, the structure of the
data is not held in the file... (there is no metadata).

This means that unless you can write a program or get one written, you can't
access it. (Compare this with an RDBMS, for example, where anyone who knows
SQL and has the right permissions can access the data.)

When I first started using RDBMS with COBOL (early 1990s) I was amazed at
how much better it was. Spread sheets could import and export data from the
repository, with COBOL managing the grunt work. Unfortunately my excitement
was not shared by people in CLC who saw open accessibility to data as
undermining their authority as COBOL programmers. There were some heated
exchanges until the landslide started and they were all overtaken by it.
Today it is rare to see people pulling out the old chestnuts about
performance and security of data (although we still get the occasional
fossil who won't roll over :-))

(Don't take HeyBub's post seriously... he is winding you up... :-))

Nevertheless, as you can see from this thread, there are still people here
who will argue that the COBOL file system is NOT closed. It really depends
on what you mean by "closed"...

As far as I'm concerned, if it requires special knowledge (like the
structure of the data) to access it, and the system can't tell me that
information, then it is closed.

Here's a comparatively recent (3 years ago) discussion about exactly this:

http://coding.derkeiler.com/Archive/.../msg00385.html

As for Windows implementations of the COBOL file system being flaky, I've
been using it for more than twenty years and have never experienced data
corruption with either Fujitsu or MicroFocus implementations under Windows
or DOS. But then, I've never used it to store 64 million records... :-)

If proper regular housekeeping and reorganization is done, there is less
likely to be trouble.

It is certainly true that if programs abend, and proper cleanup is not
instituted, there is a risk of data corruption. But that has ALWAYS been
true on mainframes OR PCs. RDBMS automatically take care of this and that is
one reason why they are perceived as more "stable".

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

On Wed, 23 Jul 2008 14:49:13 -0700 (PDT), softWare design <sabraham@baxglobal.com> wrote:

>On Jul 23, 1:22*pm, Howard Brazee <how...@brazee.net> wrote:
>>
>> I suspect most CoBOL developers work with mainframe & mini computers.
>> In that case, they use the same file systems as everybody else.
>>
>> So I infer that you find indexed file systems used by Windows based
>> CoBOL programs to be less than robust. * *Those are where the file
>> system had to be created by compiler makers to make up for Windows
>> shortcomings. * *I haven't had experience with them - what are their
>> lacks?
>
>
>Yes, I am referring to indexed file systems that are created by
>compiler makers on Windows based networks (2k and XP).
>They tend to get corrupted frequently for various reasons
>especially when storing massive number of records.

Most professionally developed Cobol systems abandoned indexed files and switched to
databases, starting in the 1980s. The ones still using indexed files tend to be amateurs
and small shops, who stayed with indexed because databases were expensive. That reason
disappeared in the late 1990s when full-featured free databases such as PostgreSQL and
MySQL became available.

>They are also considered to be Closed systems. Accessing
>them by external clients or customers would require creating
>new programs to get into the data with the desired formats.

There are ODBC drivers for proprietary Cobol file systems that allow any SQL tool to
access the data. The drivers are not free.
http://www.datamystic.com/datapipe/odbc_vendors.html

There are free programs to translate a Cobol indexed file to CSV (comma delimited), which
can easily be loaded to a database or spreadsheet. I posted the source for one here. It
uses a copybook defining the Cobol file.
http://groups.google.com/group/comp....ceca276724555f