Sorry, but you are mixing up things in a somehow a-historic manner,
which needs some corrections:
Databases were invented in the mid to late 1970s at IBM (System R, later
SQL/DS, later DB2), and the first database systems were implemented in
PL/1 on the mainframe, and this has nothing to do with C at all. The idea
behind this development is not to do physical reads on files any more,
but to have a language (SQL) that tells the database system what result
is wanted, and let the database care about the physical access path.
It's not about a "physical" replacement of VSAM in the first turn, but
about
a complete different thinking, for example: have the database system
doing the combination of different "tables" using join operations, grouping
and sorting etc. and keep this logic out of the application program.
This is the key principle of database programming. And very important:
with SQL you tell the system the desired result, but you don't tell the
method how the database produces this result (or the sequence of the
steps); this is left completely to the database system.
BTW: you can very easily use DB2 with ASSEMBLER programs, this has NOTHING
to do with the language. And it's great fun.
And: on the mainframe, you can use C perfectly to access OS files
(aka MVS datasets). The C runtime has some wonderful extensions
which allows the C programmer on the mainframe to do all the things
that an ASSEMBLER programmer can do, and more. For example, it is
very easy to open a file by specifying a DD name OR a DSN; the C
runtime does the dynamic allocation. Same goes for members etc.,
when the member name is known at runtime only ... etc. etc.
Again, you are mixing up things, because the MVS file system and
its merits (or pitfalls) has nothing to do with a particular language.
The differences in file handling come from the different platforms
we use today (Windows, Unix, Mainframe etc.). These differences
can be discussed, of course (no equivalent to physical records on
Windows etc.),
but this has nothing to do with C. C has quite good support for physical
records
on z/OS etc.; the needed functions are part of the ANSI function set
(some specific extensions needed for the correct handling of
binary records of varying length, because such a format doesn't
exist on Windows etc.).
HTH, kind regards
Bernd
Am 28.01.2018 um 21:17 schrieb Jon Perryman:
C has adversely impacted the world. Most languages have modeled there I/O off of C's I/O
(streams). Streams and databases are the most prevalent I/O methods in the world. C
programmers are correct in that they CAN do MVS style I/O. The problem is they DON'T
because it's too complicated in C style languages. If they truly understood MVS I/O, they
would never say "extremely efficient on most platforms".
Consider the C major innovations over 50 years: NFS (1984), block locking, and
databases. Block locking has mainly been used for databases because it's too
complex for the average programmer. NFS is Unix's concept of shared dasd it
has the same problems as regular files.
Typical C programmer reads or writes a file (nothing sophisticated). C has
record locking but it requires programmer to do record processing. C
programmers can update a file but most don't. Sophisticated requires using SQL
and databases.
Typical Cobol programmer does not even consider SQL and databases because they
can do it from standard I/O. More important is the programmer does nothing
different or unusual. E.g. open for update.
Consider the major MVS I/O innovations due to records and blocks. There are
many and it's difficult to name them all. VSAM eliminated some of the need for
a database. Record locks. I/O queue management. Transactional VSAM eliminated
more database requirement.
There are so many innovations in MVS I/O and the programmer rarely notices
anything. To start with, the innovations mentioned above. HSM (disk full).
Record insert.
How about creating efficient programmers. C programmers often don't plan for a
record. C have several commands to write and read data from a file. C
programmers often must read each field to find the start of the next record
(unless they planned for it). If a cobol programmer only needs 2 bytes of a
variable length record, they don't need to skip each field.
Much of these innovations exist because HLASM was flexible enough to encourage
their development. Anyone who doubts the significance of HLASM is very naive
because nothing like these were ever developed in C.
Regards, Jon.
