Re: How proprietary is the "COBOL file system"



"Robert" <no@xxxxxx> wrote in message
news:rf53g3da1ej24llejsgp2lsafrq32m3of0@xxxxxxxxxx
On Mon, 1 Oct 2007 10:47:57 -0500, "tlmfru" <lacey@xxxxxxx> 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.

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


.

Relevant Pages

  • Re: Document warehouse for/on VMS??
    ... It is a multiple platform CMS effectively (or this is how I currently ... It uses Oracle as the database, ... Now the question of VMS support. ... VMS customers in their current client list, ...
    (comp.os.vms)
  • Re: Information on migration of DMS2200 to relational databases
    ... later they can migrate to a different platform. ... Since Harry's request specifically *did* include RDMS, ... database is being referenced, then as long as the logic has been coded ... Migrating the database is however just a part of what is ...
    (comp.sys.unisys)
  • Re: Website Development
    ... >>| My only question is which platform makes the most sense. ... > The database and language used will depend upon the service provider ... > suggest that you pick PHP/mySQL provider. ... > infected emails. ...
    (microsoft.public.scripting.jscript)
  • Re: Need your help on this strange loading problem ... Thanks
    ... loading script. ... Platform: ... The database you are loading ... are no longer playing with the database you thought you were playing with? ...
    (comp.databases.informix)
  • Re: Information on migration of DMS2200 to relational databases
    ... Since Harry's request specifically *did* include RDMS, ... to a different platform. ... result is definitely a system that runs on a relational database, ... Migrating the database is however just a part of what is ...
    (comp.sys.unisys)