WTF? IMS was well before the 1970's, to say nothing of the database for SABRE. Outside of IBM there was at least one database on GCOS (nee GECOS).
-- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 ________________________________________ From: IBM Mainframe Assembler List <[email protected]> on behalf of Bernd Oppolzer <[email protected]> Sent: Sunday, January 28, 2018 4:47 PM To: [email protected] Subject: Re: Fair comparison C vs HLASM 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. >
