Cobol - How proprietary is the "COBOL file system"

Author

How proprietary is the "COBOL file system"

Pete Dashwood

2007-09-30, 3:55 am

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."

William M. Klein

2007-09-30, 3:55 am

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 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."
>

Robert

2007-09-30, 3:55 am

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

>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.

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.
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.

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.

Robert

2007-09-30, 3:55 am

Pete Dashwood

2007-09-30, 3:55 am

--
"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."

Pete Dashwood

2007-09-30, 7:55 am

"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...
>
>

Robert

2007-09-30, 6:55 pm

On Sun, 30 Sep 2007 21:29:31 +1300, "Pete Dashwood" <dashwood@removethis.enternet.co.nz>
wrote:

>The requirement is to access around 100 Fujitsu ISAM files. ...
>
>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).

If that's all you want to do, you don't need remote compilation.

1. Have your program do the copybook interpretation at execution time, build the SQL
dynamically. One compilation would handle all 100 ISAM files. I posted such a program
here. It converted any ISAM (with copybook) to comma delimited (CSV), which could then be
loaded into a spreadsheet or database.

2. Fujitsu shipped a tool that converts ISAM to flat file. Run that tool remotely and
transmit (FTP) the flat file. The data portion of a C-ISAM file with no deleted records is
already a flat file.

3. Transmit (FTP) the ISAM file/index and do the conversion locally.

4. Mount the remote directory on your file system and do the conversion locally. If both
machines are running Windows, they already have the software to do that: SMB. The user
knows it as Network Neighborhood and Sharing. If your end is Unix, Samba gives the same
functionality.

5. Use an ODBC driver from http://www.transoft.com/products/ts_sqlgate.htm or
http://ww2.pervasive.com/Integratio...onnectors.aspx. Since
you're already writing a schema for the database, it would be easy to write a second
version for the driver.

>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...

Many conversion tools have been developed. There are even tools that go the other way, by
making a database look like an ISAM file so you can 'leverage your investment'. Most Cobol
programmers do that manually, converting files to tables one-for-one.

>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...)

Some are still defending that turf. They regard outsiders with better ideas as the enemy.

Richard

2007-09-30, 6:55 pm

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 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.

You may be thinking of Btrieve.

Richard

2007-09-30, 6:55 pm

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 vice
> 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 own
> 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.

Richard

2007-09-30, 6:55 pm

On Sep 30, 6:20 pm, Robert <n...@e.mail> wrote:
> On Sun, 30 Sep 2007 17:18:10 +1300, "Pete Dashwood" <dashw...@removethis.enternet.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 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.

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

Richard

2007-09-30, 6:55 pm

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> wrote in message
>
> news:a8huf3ppubdf9pd0gmtuiiv3s5efn19r0b@
4ax.com...
>
>
>
>
>
>
>
>
>
>
>
>
> 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)

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 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."

Pete Dashwood

2007-09-30, 6:55 pm

"Richard" <riplin@Azonic.co.nz> wrote in message
news:1191179230.655139.4510@22g2000hsm.googlegroups.com...
> On Sep 30, 6:20 pm, Robert <n...@e.mail> wrote:
>
> 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).
>
>
> Fujitsu uses mechanisms derived from their mainframe range to give
> compressed data (RLL) and indexes in the data file.
>
>
> This is not useful if the programs do READ/WRITE.

Thanks for this, Richard. Very interesting.

I'm curious about your last statement.

I have only ever used ODBC to access RDBs, although I understand there are
some ODBC drivers available now to access indexed files also.

Why would writing with ODBC be a problem? Can you elaborate? I've never had
trouble reading and writing Databases.

Cheers,

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

Pete Dashwood

2007-09-30, 6:55 pm

"Robert" <no@e.mail> wrote in message
news:c9mvf3hoqs5j2fcdeqf3iq5dic1mq4tq1i@
4ax.com...
> On Sun, 30 Sep 2007 21:29:31 +1300, "Pete Dashwood"
> <dashwood@removethis.enternet.co.nz>
> wrote:
>
>
>
> If that's all you want to do, you don't need remote compilation.

I am sure there are many ways to achieve what I want. But that is not "all I
want to do" (This is only one aspect of a toolset that dleivers many things)

If COBOL is not running on the machine where I want to run the output, then
it makes sense to access it remotely.

Besides, there may be many reasons I would want to compile COBOL from any
machine on the network, without buying additional COBOL licences.
>
> 1. Have your program do the copybook interpretation at execution time,
> build the SQL
> dynamically.

>One compilation would handle all 100 ISAM files. I posted such a program
> here. It converted any ISAM (with copybook) to comma delimited (CSV),
> which could then be
> loaded into a spreadsheet or database.

Yes, I already have software to do that, it's trivial. That is not the
problem. I need to analyse the COPYBOOK and generate DDL (NOT SQL) for any
one of several target RDBMS systems. This creates tables on the database and
these are normalized to 3NF, repeating groups removed, key dependencies
checked and combined. It is a lot more than simply transferring data from
ISAM to a replicated structure.

>
> 2. Fujitsu shipped a tool that converts ISAM to flat file. Run that tool
> remotely and
> transmit (FTP) the flat file. The data portion of a C-ISAM file with no
> deleted records is
> already a flat file.

And how would I get the needed DB structure from doing that?
>
> 3. Transmit (FTP) the ISAM file/index and do the conversion locally.

No idea what you are talking about here. The conversion IS done locally
using a single integrated toolset. That toolset obtains data and compiles
COBOL whenever it needs to, and does it locally or remotely, transparently
to the user.

>
> 4. Mount the remote directory on your file system and do the conversion
> locally. If both
> machines are running Windows, they already have the software to do that:
> SMB. The user
> knows it as Network Neighborhood and Sharing. If your end is Unix, Samba
> gives the same
> functionality.

I think you have completely misunderstood what is going on here. You keep
saying "do the conversion locally". It isn't about "conversion". It is about
creating a database and loading it. It may be done one or more files at a
time. The existing COBOL access code also has to be converted and they may
want to do that on a subsystem basis. They need ot be able to dynamically
modify their copybooks and instantly regenerate and load the affected
tables. There is much more to it than I have described here.
>
> 5. Use an ODBC driver from http://www.transoft.com/products/ts_sqlgate.htm
> or
> http://ww2.pervasive.com/Integratio...onnectors.aspx.
> Since
> you're already writing a schema for the database, it would be easy to
> write a second
> version for the driver.
>
>
> Many conversion tools have been developed. There are even tools that go
> the other way, by
> making a database look like an ISAM file so you can 'leverage your
> investment'. Most Cobol
> programmers do that manually, converting files to tables one-for-one.
>
>
> Some are still defending that turf. They regard outsiders with better
> ideas as the enemy.

I appreciate the imaginative solutions siggested, Robert, but you do not
have a complete problem definition here.

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

Pete Dashwood

2007-09-30, 6:55 pm

"Richard" <riplin@Azonic.co.nz> wrote in message
news:1191182351.443023.186010@o80g2000hse.googlegroups.com...
> On Sep 30, 8:29 pm, "Pete Dashwood"
> <dashw...@removethis.enternet.co.nz> wrote:
>
> 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.

Thanks Richard, I didn't know that.

However, MF is not involved in this anywhere and I have no intention of
buying any further products from Fujitsu. They did me a favour by giving me
the kick I needed to move off COBOL, and that is the end of the relationship
as far as I'm concerned.

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

Pete Dashwood

2007-09-30, 6:55 pm

"Richard" <riplin@Azonic.co.nz> wrote in message
news:1191178815.162798.149670@r29g2000hsg.googlegroups.com...
>
> On Sep 30, 4:18 pm, "Pete Dashwood"
> <dashw...@removethis.enternet.co.nz> wrote:
>
> 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.

It is trivial to export and import data and structure between RDBMS, and you
don't need to write a program to do it. The data is open and accessible. It
isn't trivial to do so with ISAM.

I agree that "interpretations" of the SQL standard are different between
various RDBMS and this is problematic for me at the moment as I need to
generate DDL for different RDBMS. I was surprised that DDL from ACCESS was
totally incompatible with MySQL and even with SQL Server (although less so
there). Some constructs like ALTER TABLE seem to work in any RDBMS without
change, others (PRIMARY KEY and referential integrity constraints are the
two worst offenders) need serious massaging. I have a separate called C#
program that reformats an ACCESS DDL "Baseline" to whatever is required and
the SQL generated into the load programs is automatically modified for the
target RDBMS. It is all working fine, but it was a lot of work...:-)

>
>
> 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.
>
>
>
>

Richard

2007-09-30, 6:55 pm

On Oct 1, 7:59 am, Richard <rip...@Azonic.co.nz> wrote:
> On Sep 30, 8:29 pm, "Pete Dashwood"
>
>
>
> <dashw...@removethis.enternet.co.nz> wrote:
>
>
>
>
>
>
>
>
>
>
>
>
> 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'.

Further to that it may be possible to write an 'extfh' for MF that
filters out particular files and calls the Fujitsu file handler so
that MF can transparently access both file systems.
[color=darkred]
>
>
>
>
>

Judson McClendon

2007-09-30, 6:55 pm

"Richard" <riplin@Azonic.co.nz> wrote:
> "William M. Klein" <wmkl...@nospam.netcom.com> wrote:
>
> You may be thinking of Btrieve.

MF COBOL & Net Express can most definitely use Btrieve. Been doing
that for nearly 20 years.
--
Judson McClendon judmc@sunvaley0.com (remove zero)
Sun Valley Systems http://sunvaley.com
"For God so loved the world that He gave His only begotten Son, that
whoever believes in Him should not perish but have everlasting life."

Robert

2007-09-30, 6:55 pm

On Mon, 1 Oct 2007 09:13:22 +1300, "Pete Dashwood" <dashwood@removethis.enternet.co.nz>
wrote:

>I have only ever used ODBC to access RDBs, although I understand there are
>some ODBC drivers available now to access indexed files also.

One ODBC driver can access flat files. You can do WHERE, join (for regression testing)
and self-join (to find duplicates) even though there is no index. Performance is
surprisingly good up to a million records, which is the largest I've tried.

It is also good for loading a flat file into a database, using TOAD or msquery (comes free
with Excel).

It comes standard with Windows. Look in Control Panel/Admin/Data Sources/Microsoft Text
File. The schema goes in a flat file. All flat files (tables) must be in a single
directory.

Robert

2007-09-30, 6:55 pm

On Mon, 1 Oct 2007 09:34:59 +1300, "Pete Dashwood" <dashwood@removethis.enternet.co.nz>
wrote:

>"Robert" <no@e.mail> wrote in message
> news:c9mvf3hoqs5j2fcdeqf3iq5dic1mq4tq1i@
4ax.com...

>
>Yes, I already have software to do that, it's trivial. That is not the
>problem. I need to analyse the COPYBOOK and generate DDL (NOT SQL) for any
>one of several target RDBMS systems. This creates tables on the database and
>these are normalized to 3NF, repeating groups removed, key dependencies
>checked and combined. It is a lot more than simply transferring data from
>ISAM to a replicated structure.

Analyzing copybooks can get you to 1NF. Analyzing data can get you to 2NF. How do you
automate detection of transitive dependencies to get 3NF?

>
>And how would I get the needed DB structure from doing that?

It wouldn't.

>
>I think you have completely misunderstood what is going on here. You keep
>saying "do the conversion locally". It isn't about "conversion". It is about
>creating a database and loading it. It may be done one or more files at a
>time. The existing COBOL access code also has to be converted and they may
>want to do that on a subsystem basis. They need to be able to dynamically
>modify their copybooks and instantly regenerate and load the affected
>tables. There is much more to it than I have described here.

I've worked with normalized databases and with poorly factored ones. Normalized is faster,
but requires SQL that many consider intimidating. Ten way joins are common. Objections can
be reduced by providing views that look like traditional files. Your tool could define
them automatically, thus easing conversion of Cobol access code.

Richard

2007-09-30, 6:55 pm

On Oct 1, 8:13 am, "Pete Dashwood"
<dashw...@removethis.enternet.co.nz> wrote:
> "Richard" <rip...@Azonic.co.nz> wrote in message
>
> news:1191179230.655139.4510@22g2000hsm.googlegroups.com...
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> Thanks for this, Richard. Very interesting.
>
> I'm curious about your last statement.
>
> I have only ever used ODBC to access RDBs, although I understand there are
> some ODBC drivers available now to access indexed files also.
>
> Why would writing with ODBC be a problem? Can you elaborate? I've never had
> trouble reading and writing Databases.

Perhaps I should have been clearer. "if the existing program uses the
READ statement or WRITE statement". ODBC uses EXEC SQL and so program
conversion would be necessary.

Richard

2007-09-30, 6:55 pm

On Oct 1, 8:40 am, "Pete Dashwood"
<dashw...@removethis.enternet.co.nz> wrote:
> "Richard" <rip...@Azonic.co.nz> wrote in message
>
> news:1191182351.443023.186010@o80g2000hse.googlegroups.com...
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> Thanks Richard, I didn't know that.
>
> However, MF is not involved in this anywhere and I have no intention of
> buying any further products from Fujitsu. They did me a favour by giving me
> the kick I needed to move off COBOL, and that is the end of the relationship
> as far as I'm concerned.

I was answering your question:

"""Can anyone tell me if MicroFocus COBOL can read Fujitsu ISAM
files, ..."""

It turns out that this isn't the question you wanted an answer to.

Robert

2007-09-30, 9:55 pm

On Mon, 1 Oct 2007 09:50:07 +1300, "Pete Dashwood" <dashwood@removethis.enternet.co.nz>
wrote:

>
>I agree that "interpretations" of the SQL standard are different between
>various RDBMS and this is problematic for me at the moment as I need to
>generate DDL for different RDBMS. I was surprised that DDL from ACCESS was
>totally incompatible with MySQL and even with SQL Server (although less so
>there). Some constructs like ALTER TABLE seem to work in any RDBMS without
>change, others (PRIMARY KEY and referential integrity constraints are the
>two worst offenders) need serious massaging. I have a separate called C#
>program that reformats an ACCESS DDL "Baseline" to whatever is required and
>the SQL generated into the load programs is automatically modified for the
>target RDBMS. It is all working fine, but it was a lot of work...:-)

I would have used the 1992 ANS/ISO SQL Standard as baseline. It is the most likely to work
on all databases. For example, primary key and referential constraints are written this
way according to the Standard:

CREATE TABLE vendors (
vendor INTEGER NOT NULL,
name VARCHAR(50) NOT NULL,
CONSTRAINT pk_vendor PRIMARY KEY(vendor)
)

CREATE TABLE materials (
material INTEGER NOT NULL,
vendor INTEGER NOT NULL,
quantity_on_hand NUMBER,
CONSTRAINT pk_material PRIMARY KEY(material),
CONSTRAINT fk_vendor FOREIGN KEY(vendor) REFERENCES vendors(vendor)
)

I'd be surprised if that didn't work everywhere. Some databases let you omit NOT NULL from
the primary key, but using it doesn't hurt. Some let you omit the name of the parent
table's column or the type of the child's column, but specifying it is valid.

LX-i

2007-10-01, 3:55 am

Richard wrote:
> On Sep 30, 4:18 pm, "Pete Dashwood"
> <dashw...@removethis.enternet.co.nz> wrote:
>
> 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.

But at least with SQL, your program can *read* the source database. :)
It's tough to generate output with no input. (Well, meaningful
output, anyway...)

--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~~~~~
~ / \/ _ o ~ Live from Albuquerque, NM! ~
~ _ /\ | ~ ~
~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
~ Business E-mail ~ daniel @ "Business Website" below ~
~ Business Website ~ http://www.djs-consulting.com ~
~ Tech Blog ~ http://www.djs-consulting.com/linux/blog ~
~ Personal E-mail ~ "Personal Blog" as e-mail address ~
~ Personal Blog ~ http://daniel.summershome.org ~
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~~~~~

GEEKCODE 3.12 GCS/IT d s-:+ a C++ L++ E--- W++ N++ o? K- w$ !O M--
V PS+ PE++ Y? !PGP t+ 5? X+ R* tv b+ DI++ D+ G- e h---- r+++ z++++

"Who is more irrational? A man who believes in a God he doesn't see,
or a man who's offended by a God he doesn't believe in?" - Brad Stine

Pete Dashwood

2007-10-01, 6:55 pm

"Richard" <riplin@Azonic.co.nz> wrote in message
news:1191195795.978155.209550@n39g2000hsh.googlegroups.com...
> On Oct 1, 8:13 am, "Pete Dashwood"
> <dashw...@removethis.enternet.co.nz> wrote:
>
> Perhaps I should have been clearer. "if the existing program uses the
> READ statement or WRITE statement". ODBC uses EXEC SQL and so program
> conversion would be necessary.
>
Ah, clear. Thanks.

Yes, after migration, code conversion is the next major effort. I'm hoping
to help them automate some (maybe even most...) of that too. There are a few
hundred COBOL programs and, unfortunately, it isn't just a simple matter of
converting Indexed access verbs to SQL. There are many implications with
group fields defined in COBOL, different handling of Date types, OCCURS and
REDEFINES. It is pretty huge. I've just finished writing a 20 page document
that identifies the problem areas, looks at what could be automated and how,
and examines possible strategies to accomplish the code conversion.

For example, the existing code references various group fields, but the RDB
cannot support group fields.(It has to be stored as a separate element on
the DB, or could be saved as a View) It may be possible to generate a stored
procedure that will automatically update the group field whenever one of the
constituent fields changes, but the ideal thing would be to drop references
to group fields and replace them with SQL. It really depends on how much
referencing there is and how process critical it is.

Initially, we will want to make the minimum changes to the existing COBOL
code, but we may have no choice as work progresses. This is another reason
why we may convert subsytems at a time rather than doing all the data
migration then all the code conversion.

At least they are staying with COBOL, in the meantime, anyway :-)

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

Pete Dashwood

2007-10-01, 6:55 pm

X-Trace: individual.net 6tVo9+S/++USDdBuLigccgiwdhMQl2lZtQ3/YHT5nGG1mGI7Ni
Cancel-Lock: sha1:9a2KhfoaL6LJNKFwr2/FlYUkkAU=
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.3138
X-RFC2646: Format=Flowed; Original
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138
Bytes: 4443
Xref: number1.nntp.dca.giganews.com comp.lang.cobol:168901

"Robert" <no@e.mail> wrote in message
news:1aa0g3dkekdlcrv26f6vbu041l03m7snoj@
4ax.com...
> On Mon, 1 Oct 2007 09:34:59 +1300, "Pete Dashwood"
> <dashwood@removethis.enternet.co.nz>
> wrote:
>
>
>
> Analyzing copybooks can get you to 1NF. Analyzing data can get you to 2NF.
> How do you
> automate detection of transitive dependencies to get 3NF?

You can't always... However, what I have does achieve it most of the time.
>
>
> It wouldn't.
>
>
> I've worked with normalized databases and with poorly factored ones.
> Normalized is faster,
> but requires SQL that many consider intimidating. Ten way joins are
> common. Objections can
> be reduced by providing views that look like traditional files. Your tool
> could define
> them automatically, thus easing conversion of Cobol access code.
>
It does have a facility to allow people with no SQL knowledge to access the
DB, using COBOL record layouts. It is based around a data layer that is part
of an n-tier architecture and COBOL simply calls the bottom layer. (Access
modules for each table are generated the same way that Load modules are,
except that the access modules don't read ISAM; they provide Select, Insert,
Change, and Delete functionality, instead. This is intended as a an aid
while people are learning SQL, I certainly don't want to encourage continued
"record" based processing. There won't be any 10 way joins ... :-)

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

Pete Dashwood

2007-10-01, 6:55 pm

"Richard" <riplin@Azonic.co.nz> wrote in message
news:1191196299.791798.142510@k79g2000hse.googlegroups.com...
> On Oct 1, 8:40 am, "Pete Dashwood"
> <dashw...@removethis.enternet.co.nz> wrote:
>
> I was answering your question:
>
> """Can anyone tell me if MicroFocus COBOL can read Fujitsu ISAM
> files, ..."""
>
> It turns out that this isn't the question you wanted an answer to.
>
Well, actually, I did want an answer to that but only in passing :-) I meant
it more as an example.

Nevertheless, I od appreciate the responses received from all who posted. It
has been very helpful.

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

tlmfru

2007-10-01, 6:55 pm

Pete Dashwood <dashwood@removethis.enternet.co.nz> wrote in message
news:5m953cFc85a2U1@mid.individual.net...

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...)
>

It's a bit much, isn't it, to blame the language for the differing ways that
implementors chose to write their I/O handlers? I don't know that the
standards ever specified how the files should be implemented. For that
matter, how could they have done so? At the very minimum, they'd have had
cope with EBCDIC vs. ASCII, and count-key-data vs. fixed address disk
drives. And that was long before PC days.

Is there any file system or DB system - any file mechanism whatsoever that
is completely platform-independent?

PL

Howard Brazee

2007-10-01, 6:55 pm

On Mon, 1 Oct 2007 09:34:59 +1300, "Pete Dashwood"
<dashwood@removethis.enternet.co.nz> wrote:

>Besides, there may be many reasons I would want to compile COBOL from any
>machine on the network, without buying additional COBOL licences.

I suspect a lot of the reason Java has succeeded and CoBOL is dying is
related to this. It is easy to try out Java on any system -
including your home PC. You write something in Java, and anybody can
use it without legal issues.

Pete Dashwood

2007-10-01, 6:55 pm

"tlmfru" <lacey@mts.net> wrote in message
news:9H8Mi.8185$or1.184@newsfe19.lga...
>
> Pete Dashwood <dashwood@removethis.enternet.co.nz> wrote in message
> news:5m953cFc85a2U1@mid.individual.net...
>
> It was precisely because I have no easy way to access the ISAM from
> anything
> turn,
> into
> are
>
>
> It's a bit much, isn't it, to blame the language for the differing ways
> that
> implementors chose to write their I/O handlers?

I'm not blaming COBOL, that would be stupid.

In fact, blaming anybody for anything is a pretty fruitless exercise; it
changes nothing and simply demotivates everyone. When things go wrong there
are two things that must happen:

1. The person or persons responsible must take responsibility and do
whatever they can to fix it. (Usually this works best when they get the
support of everyone else, and assigning blame or castigating them is not
conducive to that process.)

2. The lessons as to what went wrong, and why, should be absorbed by all
concerned, so that mistakes are not repeated.

> I don't know that the
> standards ever specified how the files should be implemented.

I would hope that they didn't.

Might be better if we leave the Standards out of this. I see that as an even
more contributory factor to the decline of COBOL than a closed file
system... :-)

>For that
> matter, how could they have done so? At the very minimum, they'd have had
> cope with EBCDIC vs. ASCII, and count-key-data vs. fixed address disk
> drives. And that was long before PC days.

Yes, in its time, COBOL made an effort to cross platform boundaries and
succeeded to the extent that you could compile mainly the same code on
different platforms and it would run.

My point was that some programmers LIKED having everything in a closed file
system where a COBOL program had to be written in order to access it. They
short-sightedly supposed that this would give them job security for a long
time to come. The same people resisted the introduction of open platforms
like RDB, for the same reason. I have not forgotten the scorn and
villification I received in a predecessor of this very forum, when I
suggested that moving to RDB might be a good thing. The world voted with
its feet; they were not going to write COBOL programs to access data if they
didn't HAVE to... COBOL was left behind.
>
> Is there any file system or DB system - any file mechanism whatsoever
> that
> is completely platform-independent?

You're really not trying, Peter :-)

1. Text files. (unicode)
2. HTML files
3. CSV files
4. XML files
5. Service Data Objects (SDO)
6. Any RDBMS (These are open storage systems in the sense that they can be
accessed locally and remotely, across platforms, without needing to write
program code to do so. Object brokerage and facilities like ODBC are layers
that make this possible.)

I could add half a dozen audio and another dozen video formats that are
platform independent, inasmuch as they will run on any platform that
supports them (You can't play TV on your mainframe, not because the file
formats are incompatible, but because there is no hardware support.)

You asked for 1, there's two dozen...:-)

In fact, ANY file system that contains metadata which describes itself, can
be platform independent.

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

Robert

2007-10-01, 9:55 pm

On Mon, 1 Oct 2007 10:47:57 -0500, "tlmfru" <lacey@mts.net> wrote:

>Is there any file system or DB system - any file mechanism whatsoever that
>is completely platform-independent?

Sure. Every data interchange file is, by definition, platform independent. Examples are
text files, HTML, XML, PDF, now defunct EDI. Relational databases are platform independent
at the low technical level of atomic data types.

A better question is whether the database is application independent. You can tell by
asking whether an application rewrite would require a database redesign. The answer will
be no if the database is fully normalized. If the answer is yes, as is usually the case,
the database structure is modeled after the application's procedural structure. It is not
tied to a hardware platform or language, it is tied to an application.

At first, files were tied to languages. For example, a file written by a Cobol program was
almost always a persistent image of a Cobol memory structure. Strings were padded with
spaces, numbers had implied decimal points, the location of which was known only to the
Cobol program. Most files were structured for the convenience of procedural batch
processing.

Second, we got relational databases, whose data types did not match Cobol's. Translation
between database types and Cobol types was time consuming (expensive) and LOSSY. Forcing a
database string or number into a Cobol picture can cause loss of information, which
becomes permanent if the datum is updated. At a higher level, the database structure
might or might not follow procedural structure. It does when database tables are
organized like indexed files.

Third, we got object databases, which are a return to language dependence. The difference
is that you, rather than the Standard, design the language. You define data types as
classes and access logic as methods. As with RDBMS, database structure may or may not be
modeled after procedural structure. It is more likely to be with ODBMS because .. this is
the great irony .. RDBMS is oriented toward declaratives and thus data, whereas ODBMS is
oriented toward behavior and thus procedure.

tlmfru

2007-10-01, 9:55 pm

Pete Dashwood <dashwood@removethis.enternet.co.nz> wrote in message
news:5mdff6Fcooh8U1@mid.individual.net...
>
>
> "tlmfru" <lacey@mts.net> wrote in message
> You're really not trying, Peter :-)
>
> 1. Text files. (unicode)
> 2. HTML files
> 3. CSV files
> 4. XML files
> 5. Service Data Objects (SDO)
> 6. Any RDBMS (These are open storage systems in the sense that they can be
> accessed locally and remotely, across platforms, without needing to write
> program code to do so. Object brokerage and facilities like ODBC are
layers
> that make this possible.)
>
> I could add half a dozen audio and another dozen video formats that are
> platform independent, inasmuch as they will run on any platform that
> supports them (You can't play TV on your mainframe, not because the file
> formats are incompatible, but because there is no hardware support.)
>
> You asked for 1, there's two dozen...:-)
>

Yeah, well, I realized about eleven seconds too late what I'd said. It was
meant to be a rhetorical statement that physical files on different
platforms aren't usually readable on another. Tsk.

PL

Pete Dashwood

2007-10-01, 9:55 pm

"Robert" <no@e.mail> wrote in message
news:rf53g3da1ej24llejsgp2lsafrq32m3of0@
4ax.com...
> On Mon, 1 Oct 2007 10:47:57 -0500, "tlmfru" <lacey@mts.net> wrote:
>
>
> Sure. Every data interchange file is, by definition, platform independent.
> Examples are
> text files, HTML, XML, PDF, now defunct EDI. Relational databases are
> platform independent
> at the low technical level of atomic data types.
>
> A better question is whether the database is application independent. You
> can tell by
> asking whether an application rewrite would require a database redesign.
> The answer will
> be no if the database is fully normalized. If the answer is yes, as is
> usually the case,
> the database structure is modeled after the application's procedural
> structure. It is not
> tied to a hardware platform or language, it is tied to an application.

This is a very succinct statement of one of the most important reasons for
bothering to design a database properly.
So many people never realize this or even consider it.

I have no illusions that migrating data to a RDB gives a good RDB; it
doesn't, even if the new database is normalized. The best I can hope for is
a platform that gets them started and buys them time to tinker with the bits
that need tinkering. (Moving to RDB, even an imperfect one, DOES open up
their data resource and it does make it easier to add functionality, but it
is NOT a silver bullet...)

There is really no substitute for proper object modelling and use case
analysis, reflected in a design that supports all of this from scratch.

You have made a very important point, Robert.
>
> At first, files were tied to languages. For example, a file written by a
> Cobol program was
> almost always a persistent image of a Cobol memory structure. Strings were
> padded with
> spaces, numbers had implied decimal points, the location of which was
> known only to the
> Cobol program. Most files were structured for the convenience of
> procedural batch
> processing.
>
> Second, we got relational databases, whose data types did not match
> Cobol's. Translation
> between database types and Cobol types was time consuming (expensive) and
> LOSSY. Forcing a
> database string or number into a Cobol picture can cause loss of
> information, which
> becomes permanent if the datum is updated. At a higher level, the
> database structure
> might or might not follow procedural structure. It does when database
> tables are
> organized like indexed files.
>
> Third, we got object databases, which are a return to language dependence.
> The difference
> is that you, rather than the Standard, design the language. You define
> data types as
> classes and access logic as methods. As with RDBMS, database structure may
> or may not be
> modeled after procedural structure. It is more likely to be with ODBMS
> because .. this is
> the great irony .. RDBMS is oriented toward declaratives and thus data,
> whereas ODBMS is
> oriented toward behavior and thus procedure.

I think the jury is still out on ODBMS... I find that well designed RDBMS
support OO processing without problem. I know a lot has been said in various
papers about object persistence and optimized object storage, but, for me at
least, it hasn't been a problem (maybe I need to get out more... :-) Next
year...)

I don't know if you've had a look at LINQ, Query Expressions, and Lamdas,
Robert. I think this is where it's going... C# already supports query
expressions and these support parallel processing, deferred execution,
Lambdas (basically, representing an entire Query with a single symbol that
can be passed around), and media independence. (new molecular storage
technologies, for example, can be accessed in this way...)

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

Robert

2007-10-02, 3:55 am

On Tue, 2 Oct 2007 15:41:21 +1300, "Pete Dashwood" <dashwood@removethis.enternet.co.nz>
wrote:

>
>I think the jury is still out on ODBMS...

I think ODBMS is just a file system for objects. I once wrote an OS that simply made all
objects persistent. Its address space was the disk; there was no temporary 'memory'. You
construct an object today, it's still there tomorrow. How simple is that?

>I find that well designed RDBMS
>support OO processing without problem.

Critics say that's a BIG problem, because it is no longer relational. They say relational
is a two-dimensional world. Replacing atomic data with objects adds at least one dimension
-- the internal structure of the object. Given that components can also be objects, the
table becomes n-dimensional.

There is an inherent conflict between the relational way of finding things via association
and data values (ad hoc heaps and caches) versus the OO way of finding things via
navigational pointers.

There is a conflict between hiding data in objects versus exposing it in an RDBMS.

A solved these in the OS by saying there are two kinds of classes: relational and atomic.
For simplicity, let's say there is only one relational class: collection. An RDBMS row is
a collection of columns, a table is a collection of rows, a schema is a collection of
tables. One could duplicate the functionality of an RDBMS with a well-designed collection
class and a few simple ones for number, string, integer, float, date, etc. Then the object
base would be open to the addition of new atomic classes without destroying its relational
flavor. The caveat is that compound classes, let's call them molecules, are not allowed to
bind their atoms using their own devices, they have to do it through the collection class.
That empowers outsiders to find any data based on association and value rather than the
class' private pointers.

If two dimensions is the holy grail, think of three dimensions as recursive use of two.
Foreign keys add a third dimension, yet no one objects to that. Stored procedures and
views also add a third dimension. Multiple schemas, instances, links to other databases
and URLs make every database n-dimensional.

>I know a lot has been said in various
>papers about object persistence and optimized object storage, but, for me at
>least, it hasn't been a problem (maybe I need to get out more... :-) Next
>year...)

When they talk about performance, that's the giveaway we're back to the Good Old Days.
They're designing for the machine's convenience. It's too late; we've gone beyond that for
all but huge databases.

>I don't know if you've had a look at LINQ, Query Expressions, and Lamdas,
>Robert. I think this is where it's going... C# already supports query
>expressions and these support parallel processing, deferred execution,
>Lambdas (basically, representing an entire Query with a single symbol that
>can be passed around), and media independence. (new molecular storage
>technologies, for example, can be accessed in this way...)

LINQ is Microsoft's new improved SQL, in the same way C# is their new improved Java.
Whether you love or hate Microsoft is a religious question.

Query expressions are a new name for multithreading. Databases have been doing parallel
subqueries and parallel partition searches for at least a decade.

Lamdas are math theory, not a developed programming tool. I don't see the difference
between passing a Lamda and passing a function pointer, the name of a method or the handle
of a collection.

Pete Dashwood

2007-10-02, 7:55 am

"Robert" <no@e.mail> wrote in message
news:bkg3g3pl2rhs3n58t3ahp95677lhdtshe6@
4ax.com...
> On Tue, 2 Oct 2007 15:41:21 +1300, "Pete Dashwood"
> <dashwood@removethis.enternet.co.nz>
> wrote:
>
>
> I think ODBMS is just a file system for objects. I once wrote an OS that
> simply made all
> objects persistent. Its address space was the disk; there was no temporary
> 'memory'. You
> construct an object today, it's still there tomorrow. How simple is that?
>
>
> Critics say that's a BIG problem, because it is no longer relational. They
> say relational
> is a two-dimensional world. Replacing atomic data with objects adds at
> least one dimension
> -- the internal structure of the object. Given that components can also be
> objects, the
> table becomes n-dimensional.

That's only problematic if you care about strict compliance with theory.
Most of us have spent our careers making things work. For me, standards and
theory are fine, but I'll bend them if it helps me get what I want. If
someone criticised what I did as violating Relational theory, I'd say: "Yes,
from a CS point of view, it's pretty crap really... Have you talked to the
Users?" The point is that it doesn't matter what theoretical objections
people have, as long as the results are obtained. Having said that, I don't
deliberately break the rules unless there is a sound reason for doing so.

(I'm also not "precious" about what I design or write...)

>
> There is an inherent conflict between the relational way of finding things
> via association
> and data values (ad hoc heaps and caches) versus the OO way of finding
> things via
> navigational pointers.

I have not considered it in that way, but I don't disagree.
>
> There is a conflict between hiding data in objects versus exposing it in
> an RDBMS.

Sometimes... :-) Depends on the lifetime of the data...
>
> A solved these in the OS by saying there are two kinds of classes:
> relational and atomic.
> For simplicity, let's say there is only one relational class: collection.
> An RDBMS row is
> a collection of columns, a table is a collection of rows, a schema is a
> collection of
> tables. One could duplicate the functionality of an RDBMS with a
> well-designed collection
> class and a few simple ones for number, string, integer, float, date, etc.
> Then the object
> base would be open to the addition of new atomic classes without
> destroying its relational
> flavor. The caveat is that compound classes, let's call them molecules,
> are not allowed to
> bind their atoms using their own devices, they have to do it through the
> collection class.
> That empowers outsiders to find any data based on association and value
> rather than the
> class' private pointers.

An interesting approach...
>
> If two dimensions is the holy grail, think of three dimensions as
> recursive use of two.
> Foreign keys add a third dimension, yet no one objects to that. Stored
> procedures and
> views also add a third dimension. Multiple schemas, instances, links to
> other databases
> and URLs make every database n-dimensional.
>
>
> When they talk about performance, that's the giveaway we're back to the
> Good Old Days.
> They're designing for the machine's convenience. It's too late; we've gone
> beyond that for
> all but huge databases.
>
>
> LINQ is Microsoft's new improved SQL, in the same way C# is their new
> improved Java.
> Whether you love or hate Microsoft is a religious question.

I don't see it quite as black and white as that :-) I neither love nor hate
MicroSoft, or any other software company. I appreciate that they make
powerful products available for free, whether out of sound business sense or
otherwise. I like C#; it delivers what it promised, I like VS 2005, it is
light years ahead of other IDEs (possibly excepting Eclipse, which is also
excellent), I'm very happy with MS Office, use it every day and it serves me
well, I have grown very attached to Windows XP and IE7, but I'm in no hurry
to move to Vista (I believe it will be much better after SP1...meantime, XP
is behaving very well - I have never had a crash or hang or BSOD on
Bigblack which has been running now for almost a year (I think a more
powerful processor and 2GB of main memory may be the reason, but I don't
care... I just enjoy it :-), and my most favourite thing about MS would be
the DotNET framework:-)

I'm not happy about the exorbitant cost of Vista Ultimate 64 bit, which is
what I'll go to when I move. By the time I get to it the price will probably
be a bit lower.

It is all swings and roundabouts. I am generating revenue with something
they gave me for free, so of course that predisposes me in their favour.
I've also found them to be helpful and courteous when I have needed support
(two occasions in 7 years and one was really a Fujitsu problem.) The user
community is also very helpful.

>
> Query expressions are a new name for multithreading. Databases have been
> doing parallel
> subqueries and parallel partition searches for at least a decade.

Yes, but you had to encourage them to do so, and deferred processing was not
an option. Now you can have a series of processes react to a given Lambda
without any actual data transfer taking place. (It is Functional
Programming...) Steps in the process can modify the Lambda and only at the
end is data actually accessed, and then it is only what is needed for the
final result. It is pretty smart.

I don't know if it is still available, but there was a really excellent
video of Anders Hejlsberg (who invented C#) talking about this.

Ah, here it is:
http://blogs.msdn.com/charlie/archi...rogramming.aspx

I think you'll really enjoy this. I found it like a breath of

oxygen...
it cleared my head :-) The "ORCAS" he refers to is C# version 3 which is now
released and downloadable from:
http://www.microsoft.com/downloads/...&displaylang=en

>
> Lamdas are math theory, not a developed programming tool. I don't see the
> difference
> between passing a Lamda and passing a function pointer, the name of a
> method or the handle
> of a collection.

I agree the similarity, but combining this with Query Expression goes a
quantum leap beyond current SQL. (I believe that embedded SQL is already
obsolete; and I'm gradually weaning myself away from it :-)) Integrating
Query Expressions as classes in the Language is, in my opinion, a much
better approach. Functional Programming rules!

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

Pete Dashwood

2007-10-02, 7:55 am

Bill Gunshannon

2007-10-02, 7:55 am

In article <5mdff6Fcooh8U1@mid.individual.net>,
"Pete Dashwood" <dashwood@removethis.enternet.co.nz> writes:
>
>
> "tlmfru" <lacey@mts.net> wrote in message
> news:9H8Mi.8185$or1.184@newsfe19.lga...
>
> I'm not blaming COBOL, that would be stupid.
>
> In fact, blaming anybody for anything is a pretty fruitless exercise; it
> changes nothing and simply demotivates everyone. When things go wrong there
> are two things that must happen:
>
> 1. The person or persons responsible must take responsibility and do
> whatever they can to fix it. (Usually this works best when they get the
> support of everyone else, and assigning blame or castigating them is not
> conducive to that process.)
>
> 2. The lessons as to what went wrong, and why, should be absorbed by all
> concerned, so that mistakes are not repeated.
>
>
> I would hope that they didn't.
>
> Might be better if we leave the Standards out of this. I see that as an even
> more contributory factor to the decline of COBOL than a closed file
> system... :-)
>
>
> Yes, in its time, COBOL made an effort to cross platform boundaries and
> succeeded to the extent that you could compile mainly the same code on
> different platforms and it would run.

Still true, if you stick to COBOL and leave off the proprietary extensions.
But then, other languages suffer the same.

>
> My point was that some programmers LIKED having everything in a closed file
> system where a COBOL program had to be written in order to access it. They
> short-sightedly supposed that this would give them job security for a long
> time to come.

It's been a long time since I was a full-time COBOL programmer (and I
really wish I still was or could be one again) but I never knew anyone
for whom that was motivation. And I worked on a number of architectural
migrations involving COBOL.

> The same people resisted the introduction of open platforms
> like RDB, for the same reason. I have not forgotten the scorn and
> villification I received in a predecessor of this very forum, when I
> suggested that moving to RDB might be a good thing. The world voted with
> its feet; they were not going to write COBOL programs to access data if they
> didn't HAVE to... COBOL was left behind.

I keep hearing this, but experience proves otherwise. I have lietened
to someone locally talking about how a local insurance company (think
blimp & beagle) is abandoning COBOL in favor of Java. I have spoken
with the people who do the COBOL and they just laugh.

>
> You're really not trying, Peter :-)
>
> 1. Text files. (unicode)
> 2. HTML files
> 3. CSV files
> 4. XML files
> 5. Service Data Objects (SDO)

Sorry, but none of these is truly platform-independant. Not even text
files. Ever try moving a text file from VMS to Unix (as a binary as
moving as a text will result in automatic conversion) and then editing
it with something like vi? Even DOS (and I a fairly certain current
implementations of FAT) had more than one "type" of text file which
coulf not be edited by editors that did not know what the difference
was and how to deal with it.

> 6. Any RDBMS (These are open storage systems in the sense that they can be
> accessed locally and remotely, across platforms, without needing to write
> program code to do so. Object brokerage and facilities like ODBC are layers
> that make this possible.)

Actually, they just provide the wedge in the form of some ?DBC. You
may not have top write special code to handle it, but someone did.

>
> I could add half a dozen audio and another dozen video formats that are
> platform independent, inasmuch as they will run on any platform that
> supports them (You can't play TV on your mainframe, not because the file
> formats are incompatible, but because there is no hardware support.)

While the internal format of the data may be common and platform
independant, the files they are stored in are not guaranteed to
be so. I need merely point out VMS again. At the user level all
files are wrapped in RMS and it is very proprietary.

>
> You asked for 1, there's two dozen...:-)
>
> In fact, ANY file system that contains metadata which describes itself, can
> be platform independent.

Funny, I would have said the exact opposite. Unix files, which have no
meta-data and are merely streams of bytes seem the most independant.
VMS which always has meta-data the least.

bill

--
Bill Gunshannon | de-moc-ra-cy (di mok' ra see) n. Three wolves
bill@cs.scranton.edu | and a sheep voting on what's for dinner.
University of Scranton |
Scranton, Pennsylvania | #include <std.disclaimer.h>

Howard Brazee

2007-10-02, 6:55 pm

On Tue, 2 Oct 2007 15:41:21 +1300, "Pete Dashwood"
<dashwood@removethis.enternet.co.nz> wrote:

>This is a very succinct statement of one of the most important reasons for
>bothering to design a database properly.
>So many people never realize this or even consider it.

And to understand the database and its limits properly.

With CoBOL we sometimes have compiler options that override the
standard implementation used in calculations of decimal values. This
can cause confusion, but we can see how our numbers are stored and all
of our calculations are done in front of us with our language's rules.

Sometimes it is not obvious how an external process stores and
processes numbers that we use. It is easy to make assumptions.

Howard Brazee

2007-10-02, 6:55 pm

On 2 Oct 2007 12:43:15 GMT, bill@triangle.cs.uofs.edu (Bill
Gunshannon) wrote:

>
>I keep hearing this, but experience proves otherwise. I have lietened
>to someone locally talking about how a local insurance company (think
>blimp & beagle) is abandoning COBOL in favor of Java. I have spoken
>with the people who do the COBOL and they just laugh

It wasn't too long ago when most everybody here thought CoBOL would
outlast Java.

Besides features of the languages, there are other reasons for
businesses to keep their old language, or to go to a new language:

- Most companies have or want packaged software as part of their IS.
When they maintain those packages, they will want to have workers who
are skilled in whatever languages those packages are written in.

- Most companies have expanded their IS to include Web features. Often
they have mainframe programmers and web programmers. I haven't come
across any mainframe shops using CoBOL for their web apps.

- Companies like to hire programmers with experience programming in a
particular language. Anybody can acquire experience using Java at no
great expense. And the projects they do can be easily demonstrated.

- Companies are moving towards centralized databases and data
warehouses. The new

tools that make it easy to use those are
often web based - at least those tools that the decision makers use
are.

- Companies get bought out by other companies. This often means that
one company's IS gets taken over, and their data get combined. The
easiest way to do this is by using standard databases and distributed
systems.

- Or my company's not changing, don't risk changing the IS.

William M. Klein

2007-10-02, 6:55 pm

<previous notes "snipped" to raise a point>

I just wanted to follow-up on the question in subject of this thread. Thinking
about this ...

When COBOL started, the hardware, operating system, and compilers were usually
(almost always?) created by the same vendor, IBM and "BUNCH" or whichever
acronym you want.

At that time, it was (almost?) universal that the operating system provides the
file system for use by all languages (high-level and low-level) and that these
were "portable" across languages - but NOT across platforms. Somewhere early in
this stage, "ANSI unlabeled tapes" severed the purpose of transferring data
across systems. (Similar - IMHO - to the INTENT of XML today).

The COBOL language for I/O was designed to "match" those file systems that were
already provided by the O/S. As COBOL was "extended" some O/S had to "add"
features to their O/S. (As late as the mid-80s IBM did NOT support variable
length relative files - when the '85 Standard required it. IBM first introduced
a "simulation" facility and then added this to their VSAM system.)

To show the differences between "those days" and "these days" - the concept of
"interactive input-output" was NOT something that was "universal" in O/S - and
so COBOL's Accept/Display was almost ALL implementor defined. (X/Open was - as
far as I know - the first definition to try and make this "portable" because
they could assume that Unix systems all had "character screen" facilities.) For
languages introduced in the last decade (or more) it was more or less "assumed"
that some sort of "screen" system (library, services, whatever) were available.

The bottom-Line (as I see it), is that COBOL has "portable" language for
dealing with file system that it ASSUMED would always be present OUTSIDE the
COBOL product. This assumption is now false (especially for Unix, Windows,
Linux, etc). This has led COBOL vendors being "forced" to provide systems that
certainly are not portable. The original "solution" of creating flat files
(with USAGE DISPLAY and SIGN IS SEPARATE) output will still work - but seem
(often) to be more of imposition than would have been seen in the days of
standard-label ASCII tapes.

Even with SQL, the "language" is portable but the file systems are not. One
STILL needs to "unload" and "reload" when moving from one system to another.
However, as THIS is seen as "common" today, it is also seen as less of an
imposition than the comparable COBOL requirement.

..... Or at least that's how I see things <G>

--
Bill Klein
wmklein <at> ix.netcom.com

William M. Klein

2007-10-02, 6:55 pm

"Robert" <no@e.mail> wrote in message
news:rf53g3da1ej24llejsgp2lsafrq32m3of0@
4ax.com...
> On Mon, 1 Oct 2007 10:47:57 -0500, "tlmfru" <lacey@mts.net> wrote:
>
<snip>
> At first, files were tied to languages. For example, a file written by a Cobol
> program was
> almost always a persistent image of a Cobol memory structure. Strings were
> padded with
> spaces, numbers had implied decimal points, the location of which was known
> only to the
> Cobol program. Most files were structured for the convenience of procedural
> batch
> processing.
>

Robert,
See my separate note. It is my impression that "at first, files were O/S
specific" and languages mapped to what the O/S offered. An IBM flat, indexed,
or relative file could be handled by any IBM (same O/S) language whether COBOL,
PL/I or even Assembler. As far as I know this was also true on all the other
O/S where COBOL was first available.

--
Bill Klein
wmklein <at> ix.netcom.com

Bill Gunshannon

2007-10-02, 6:55 pm

In article <47m4g3tm2lirakmdvg0t1j8i6ruls60qa0@4ax.com>,
Howard Brazee <howard@brazee.net> writes:
> On 2 Oct 2007 12:43:15 GMT, bill@triangle.cs.uofs.edu (Bill
> Gunshannon) wrote:
>
>
> It wasn't too long ago when most everybody here thought CoBOL would
> outlast Java.

You talk like it hasn't. Still lot's of COBOL around and it shows no
signs of leaving anytime soon.

>
> Besides features of the languages, there are other reasons for
> businesses to keep their old language, or to go to a new language:
>
> - Most companies have or want packaged software as part of their IS.
> When they maintain those packages, they will want to have workers who
> are skilled in whatever languages those packages are written in.
>
> - Most companies have expanded their IS to include Web features. Often
> they have mainframe programmers and web programmers. I haven't come
> across any mainframe shops using CoBOL for their web apps.

I have seen some web apps written directly in COBOL and am looking
into doing some myself (just for fun at the moment but I do hope
to eventually get back into COBOL fulltime. Hint. Hint.) But there
are a lot of sites where things are three tiered. DB in the backend,
WEB Frontend and COBOL doin g the real work in the middle. Probably
a good idea as one should always use the right tool for any job.

>
> - Companies like to hire programmers with experience programming in a
> particular language. Anybody can acquire experience using Java at no
> great expense. And the projects they do can be easily demonstrated.

Maybe, but is the language truly suited for the tasks that are done
now using COBOL? Much COBOL is still being done on IBM under CICS.
Somehow I can't imagine Java in this environment.

>
> - Companies are moving towards centralized databases and data
> warehouses. The new

tools that make it easy to use those are
> often web based - at least those tools that the decision makers use
> are.

But the web stuff mayonly be the frontend. At least, it should be.

>
> - Companies get bought out by other companies. This often means that
> one company's IS gets taken over, and their data get combined. The
> easiest way to do this is by using standard databases and distributed
> systems.
>
> - Or my company's not changing, don't risk changing the IS.

I have seen a number of white-papers recently pointing out the idea
that COBOL is not likely to go away anytime soon and it's use may,
in fact, be growing still. I, for one, am not planning on abandoning
my COBOL skills just yet.

bill

--
Bill Gunshannon | de-moc-ra-cy (di mok' ra see) n. Three wolves
bill@cs.scranton.edu | and a sheep voting on what's for dinner.
University of Scranton |
Scranton, Pennsylvania | #include <std.disclaimer.h>

Howard Brazee

2007-10-02, 6:55 pm

On 2 Oct 2007 17:27:01 GMT, bill@cs.uofs.edu (Bill Gunshannon) wrote:

....
[color=darkred]
>Maybe, but is the language truly suited for the tasks that are done
>now using COBOL? Much COBOL is still being done on IBM under CICS.
>Somehow I can't imagine Java in this environment.

Yes, but I was giving reasons that aren't related to features of the
languages. Features that managers might be more comfortable
evaluating. Don't count on upper management to evaluate things by
the same criteria that you use.

....

>I have seen a number of white-papers recently pointing out the idea
>that COBOL is not likely to go away anytime soon and it's use may,
>in fact, be growing still. I, for one, am not planning on abandoning
>my COBOL skills just yet.

CoBOL is a native language for me - it's too ingrained for me to
abandon those skills. But I'm preparing myself for alternatives.

Anybody much younger than myself would be foolish to count on his
CoBOL skills to last through retirement.

Richard

2007-10-02, 6:55 pm

On Oct 3, 3:47 am, "William M. Klein" <wmkl...@nospam.netcom.com>
wrote:

> The bottom-Line (as I see it), is that COBOL has "portable" language for
> dealing with file system that it ASSUMED would always be present OUTSIDE the
> COBOL product. This assumption is now false (especially for Unix, Windows,
> Linux, etc). This has led COBOL vendors being "forced" to provide systems that
> certainly are not portable. The original "solution" of creating flat files
> (with USAGE DISPLAY and SIGN IS SEPARATE) output will still work - but seem
> (often) to be more of imposition than would have been seen in the days of
> standard-label ASCII tapes.

Portability is just different. Vendors that started with Cobol on PCs
or Unix wrote their own file systems that were portable to wherever
their system ran. So RM Cobol data files could be moved from DOS to
Unix and would just work with the RM Cobol there. ACCU the same.
Microfocus started with a CIS ISAM format (on CP/M) then changed to
LevelII format which was based on C-ISAM and this not only could be
shifted between various operating systems without reformatting
(mostly) but could be used (with care) with other languages if you had
the C-ISAM library. The C2 format, however, doesn't have C-ISAM
limitations and is 30% faster or so, so it is sensible to use this.
Other languages can just call the extfh. Fujitsu too has callable file
handler for other languages to use.

Btrive was a network file system that tried to be a database for all
languages but was mainly for Novell Server OS. Various other language
and OS independent ISAM systems have been available.

Robert

2007-10-02, 9:56 pm

On Tue, 02 Oct 2007 15:47:19 GMT, "William M. Klein" <wmklein@nospam.netcom.com> wrote:

>The bottom-Line (as I see it), is that COBOL has "portable" language for
>dealing with file system that it ASSUMED would always be present OUTSIDE the
>COBOL product. This assumption is now false (especially for Unix, Windows,
>Linux, etc). This has led COBOL vendors being "forced" to provide systems that
>certainly are not portable.

Today, database access can be assumed.

> The original "solution" of creating flat files
>(with USAGE DISPLAY and SIGN IS SEPARATE) output will still work - but seem
>(often) to be more of imposition than would have been seen in the days of
>standard-label ASCII tapes.

XML is now the default interchange format. The fallback is CSV.

>Even with SQL, the "language" is portable but the file systems are not. One
>STILL needs to "unload" and "reload" when moving from one system to another.
>However, as THIS is seen as "common" today, it is also seen as less of an
>imposition than the comparable COBOL requirement.

It is normal for the database and application to be on different machines (systems). It is
semi-common for the database to be of unknown brand, ownership and location. We write
'select name from customer@XYZCORP where id = :cutomer_id' without caring whether the
database named XYZCORP is inside or outside the company, whether it is Oracle on Unix, DB2
on mainframe or Excel on a desktop. If the link is slow and we access it often, we *might*
create a local copy with a materialized view like so:

create materialized view customerXYZ
build immediate refresh on demand
enable query rewrite
as
select id, name from customer@XYZCORP

Now we have a local copy of XYZ's customer table with scheduled resynchronization and
bidirectional updates. Creating it didn't require an unload/load. One SQL statement
defined the table, populated it, rerouted queries to customer@XYZCORP to it, and added it
to the synchronization schedule. If the view were deleted or unavailable, queries would
automatically go to the remote database.

I recently did a high volume (TB) unload/load where one of the databases WAS on the same
machine (apparently, it was actually in a disk array). Someone in management thought a
single machine would make the process go faster. When the unload started I noticed a lot
of network activity caused by the 300 application processes talking to the database
processes through the network (sent back by the first router). I thought that was silly,
it would go faster if the apps were talking through shared memory pipes (Fast Local
Transport) or even normal pipes (domain socket transfer). The administrator said they
tried that and found it slower. Silly me.

On THAT operating system (Unix) and THAT alignment of the planets, talking to another
machine was faster than talking to a 'local' disk.

I worked on a machine in Chicagoland that had 10,000 disk drives in Atlanta, an automated
tape library in Dallas and high speed printers elsewhere in Atlanta. Was that one system
or four systems?

Robert

2007-10-02, 9:56 pm

On Tue, 2 Oct 2007 21:52:37 +1300, "Pete Dashwood" <dashwood@removethis.enternet.co.nz>
wrote:

>I'm not happy about the exorbitant cost of Vista Ultimate 64 bit, which is
>what I'll go to when I move. By the time I get to it the price will probably
>be a bit lower.

Did you know a big company running Windows servers pays Microsoft about a million dollars
a year in licensing fees? Most people think companies 'buy' Windows for a few hundred
dollars, same as they do at home.

>I agree the similarity, but combining this with Query Expression goes a
>quantum leap beyond current SQL. (I believe that embedded SQL is already
>obsolete; and I'm gradually weaning myself away from it :-)) Integrating
>Query Expressions as classes in the Language is, in my opinion, a much
>better approach. Functional Programming rules!

Don't make the user stare at a blank screen while the query runs. Instead, ANTICIPATE the
query and cache its output. The user will think you're a genius for making the query run
in milliseconds. :)

Most computers are idle 99% of the time. USE those cycles for something. Users will come
out ahead, even if most of the work is never used.

Pete Dashwood

2007-10-02, 9:56 pm

"Bill Gunshannon" <bill@triangle.cs.uofs.edu> wrote in message
news:5mesn3Fd7fo5U1@mid.individual.net...
> In article <5mdff6Fcooh8U1@mid.individual.net>,
> "Pete Dashwood" <dashwood@removethis.enternet.co.nz> writes:
>
> Still true, if you stick to COBOL and leave off the proprietary
> extensions.
> But then, other languages suffer the same.

Yes, I said "mainly"... :-)
>
>
> It's been a long time since I was a full-time COBOL programmer (and I
> really wish I still was or could be one again) but I never knew anyone
> for whom that was motivation. And I worked on a number of architectural
> migrations involving COBOL.

Our experience obviously differs. I knew a number of people on a number of
sites in different couintries who felt this way.
>
>
> I keep hearing this, but experience proves otherwise.

That, of course, would be YOUR experience... :-)

I have lietened
> to someone locally talking about how a local insurance company (think
> blimp & beagle) is abandoning COBOL in favor of Java. I have spoken
> with the people who do the COBOL and they just laugh.

Yes, I wonder if they'll still be laughing in 2015...

Did you tallk to the Java people? Any chuckles from that area?
>
>
> Sorry, but none of these is truly platform-independant. Not even text
> files. Ever try moving a text file from VMS to Unix (as a binary as
> moving as a text will result in automatic conversion) and then editing
> it with something like vi? Even DOS (and I a fairly certain current
> implementations of FAT) had more than one "type" of text file which
> coulf not be edited by editors that did not know what the difference
> was and how to deal with it.

I'm not going to argue this because it is pointless.Obviously if encoding
forbids transfer (and as you said yourself, the transfer software converts
automatically), then the file is not readable by standard software on the
target platform. However, that doesn't make it non-platform independent. If
software written for that platform CAN read it, then it is accessible. As
for your example, why would I try moving something as a binary when I know
that that can't work?

>
>
> Actually, they just provide the wedge in the form of some ?DBC. You
> may not have top write special code to handle it, but someone did.

And how does that affect me when I want to access it? Apart from being
thankful that facilities exist to allow me to do so (I don't really mind who
they were written by), I just see it as an open subsystem. Can't do that
with ISAM. The point here is that I can log into ANY RDBMS on ANY platform
and access the data (always provided I have the necessary permissions, of
course). In fact, from a single program I can (and actually have done so...)
access three different RDBMS subsystems, running on completely different
hardware. I cannot do that with ISAM or VSAM. (OK, let's leave VSAM out of
it because it doesn't pretend ot run across platforms...confine it to ISAM.
That was the point of my original post; the ISAM subsytems are NOT
compatible, but are proprietary to each COBOL vendor.

The real key to all this is that they are NOT "self describing". If they
were, they would be platform independent. It is this closed nature, which
requires a COBOL program to be written instead of being able to use standard
tools like scripting, which, in my opinion, has been a contributing factor
to the decline of COBOL.
>
>
> While the internal format of the data may be common and platform
> independant, the files they are stored in are not guaranteed to
> be so. I need merely point out VMS again. At the user level all
> files are wrapped in RMS and it is very proprietary.
>
>
> Funny, I would have said the exact opposite. Unix files, which have no
> meta-data and are merely streams of bytes seem the most independant.
> VMS which always has meta-data the least.

OK, I hope the above explains where I'm coming from. It isn't just about
data streams.

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

Pete Dashwood

2007-10-02, 9:57 pm

"Bill Gunshannon" <bill@cs.uofs.edu> wrote in message
news:5mfdb5Fdbh7iU1@mid.individual.net...
> In article <47m4g3tm2lirakmdvg0t1j8i6ruls60qa0@4ax.com>,
> Howard Brazee <howard@brazee.net> writes:
>
> You talk like it hasn't. Still lot's of COBOL around and it shows no
> signs of leaving anytime soon.
>
>
> I have seen some web apps written directly in COBOL and am looking
> into doing some myself (just for fun at the moment but I do hope
> to eventually get back into COBOL fulltime. Hint. Hint.) But there
> are a lot of sites where things are three tiered. DB in the backend,
> WEB Frontend and COBOL doin g the real work in the middle. Probably
> a good idea as one should always use the right tool for any job.
>
>
> Maybe, but is the language truly suited for the tasks that are done
> now using COBOL? Much COBOL is still being done on IBM under CICS.
> Somehow I can't imagine Java in this environment.
>
>
> But the web stuff mayonly be the frontend. At least, it should be.
>
>
> I have seen a number of white-papers recently pointing out the idea
> that COBOL is not likely to go away anytime soon and it's use may,
> in fact, be growing still. I, for one, am not planning on abandoning
> my COBOL skills just yet.
>
Fair enough. Your opinion is as good as anyone else's, including mine :-)

It's pretty easy to check the "growth" and popularity of COBOL vs the
alternatives. Try GOOGLing on "COBOL Program", "VB program" "JAVA program",
"C# program" and "Ruby on Rails program". Check the hit count. Doesn't
prove anything, but certainly gives an indication. Then check any web based
job site and try searching with COBOL as a required skill and the other
languages mentioned. This is the REAL world, not the hallowed halls of
Acadaemia, where White Papers shape opinions.

You may have missed a paradigm shift, Bill. The world moved to OO and the
web. Even though COBOL CAN be used for these thngs (I have been writing OO
COBOL for almost 10 years now and I have used COBOL to good effect with CGI
and ISAPI on web sites), it suffers by comparison to the other tools
available. There is no comparison between COBOL and C# or Java when it comes
to web programming, or even application programming that is component based
(and these days, nearly everything is...)

One question: When you say "COBOL" do you include OO COBOL?

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

Robert

2007-10-03, 3:55 am

On Tue, 02 Oct 2007 15:47:19 GMT, "William M. Klein" <wmklein@nospam.netcom.com> wrote:

><previous notes "snipped" to raise a point>
>
>I just wanted to follow-up on the question in subject of this thread. Thinking
>about this ...
>
>When COBOL started, the hardware, operating system, and compilers were usually
>(almost always?) created by the same vendor, IBM and "BUNCH" or whichever
>acronym you want.
>
>At that time, it was (almost?) universal that the operating system provides the
>file system for use by all languages (high-level and low-level) and that these
>were "portable" across languages - but NOT across platforms.

IBM ported VSAM to ru