> Databases were invented in the mid to late 1970s > at IBM (System R, later SQL/DS, later DB2)
IMS and Codasyl were invented in 1960's. > the first database systems were implemented in PL/1 on the mainframe Since I've never seen source code, I can't say for sure but I suspect that IMS and DB2 were most likely written in PL/S and ASM. Without the IMS and codasyl experience, the different technologies and advancements would have been delayed by many years. > The idea behind this development is not to do > physical reads on files any more, > but to have a language (SQL) with the desired results I think the idea behind databases is to more effectively access data. Databases and SQL still have the record concept (fields in table) and records are still read in a sequential method. Files have the record as a single piece and require the programmer read the entire record even when they only needed one field. Databases allow records to be broken into pieces allowing the DB admin to structure elements of that record in a more efficient to use method. SQL allows the programmer to interface with the database using all the features provided by the database. If the database was designed correctly, this could substantially reduce resource usage. > It's not about a "physical" replacement of VSAM in > the first turn, but about a complete different thinking More often even with the overhead, VSAM will suffice. Actually, VSAM and databases have commonality. It's not about replacement. It's about balancing simplicity with complexity. A database such as DB2 can give the programmer a lot of flexibility but this comes with complexity. In an ideal world, every dataset would be in a database. In reality, there is no way a DB admin could deal with that many databases. DB admin must analyze data and remain current to the data requirements. > And: on the mainframe, you can use C perfectly to access OS files I agree that IBM did a good job with IBM C. Since using these features means the program is not portable, then the choice comes down where you can best solve the problem. > Again, you are mixing up things, because > the MVS file system and its merits (or pitfalls) has > nothing to do with a particular language. Actually, I'm not mixing it up. Look at the history of systems built with C versus systems built with HLASM. They are dramatically different because C had to settle with language limitations. > The differences in file handling come from > the different platforms. but this has nothing to do with C. > C has quite good support for physical records on z/OS etc.; Cobol has quite good support too and it is at compile time. This has everything to do with C. C as an application programming language is as good as cobol. As a system language, it simply does not meet the needs of MVS. In 50 years, how has C improved file I/O? *nix is a hodgepodge of low-value technologies that make *nix acceptatable. E.g. createfile has a high value to Unix but compared to LDS is pitiful. It's not much better than VIO C uses the HLASM api for file handling. My point is that implementing MVS file handling in C would be a nightmare. I don't know anyone that would attempt a small part in C (e.g. DCB). There's a reason MVS file handling does not exist in Unix. Thanks, Jon.
