Re: How proprietary is the "COBOL file system"



"tlmfru" <lacey@xxxxxxx> wrote in message
news:9H8Mi.8185$or1.184@xxxxxxxxxxxxxxx

Pete Dashwood <dashwood@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:5m953cFc85a2U1@xxxxxxxxxxxxxxxxxxxxx

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


.

Relevant Pages

  • Re: PowerCOBOL conversion to DotNET
    ... COBOL from the seventies, which have been converted and migrated across ... Presentation layer. ... comes to platform change. ... Moving to C# is not really about the language; ...
    (comp.lang.cobol)
  • Re: PowerCOBOL conversion to DotNET
    ... COBOL from the seventies, which have been converted and migrated across ... Presentation layer. ... comes to platform change. ... Moving to C# is not really about the language; ...
    (comp.lang.cobol)
  • Re: How proprietary is the "COBOL file system"
    ... COBOL is supposed to provide... ... This "closed" COBOL file system has been one of the major contributors to ... Yes, in its time, COBOL made an effort to cross platform boundaries and ... My point was that some programmers LIKED having everything in a closed file ...
    (comp.lang.cobol)
  • Re: PowerCOBOL conversion to DotNET
    ... COBOL from the seventies, which have been converted and migrated ... Presentation layer. ... comes to platform change. ... I think it was a major oversight in PowerCOBOL. ...
    (comp.lang.cobol)
  • Re: How proprietary is the "COBOL file system"
    ... COBOL is supposed to provide... ... This "closed" COBOL file system has been one of the major contributors to ... Yes, in its time, COBOL made an effort to cross platform boundaries and ... system where a COBOL program had to be written in order to access it. ...
    (comp.lang.cobol)