Where do you get your "facts"? > because records and advanced MVS I/O techniques were too complex for a C > usage implementation
https://www.ibm.com/support/knowledgecenter/SSLTBW_2.3.0/com.ibm.zos.v2r3.cbcpx01/cbc1p224.htm > you can use structures but it's not that common Structures are an incredibly common usage in C. A Google search for <c struct> yields 39,900,000 hits. > If C had macro's C has macros. (No "macro's" but I assume you meant macros.) Charles -----Original Message----- From: IBM Mainframe Assembler List [mailto:[email protected]] On Behalf Of Jon Perryman Sent: Monday, January 22, 2018 4:09 PM To: [email protected] Subject: Re: Fair comparison C vs HLASM Rob, what python call mechanism are you referring to? Are you talking about OOP that was taken from C++? You missed the point. Superiority is not about number of lines, optimal code, opinions or preferences. As a programmer, it's about what designs are you willing to implement in the programming language of you choice? What problems are you willing to solve before you consider the solution too complex to code, maintain and upgrade? C is a simple language with many functions. For straight forward programming logic, C is fine. When it's a complex problem, it's not so great. Programmers will not use a complex implementation. Below, I discuss XML to make this clear. Before I do, let me show it's not an isolated issue. Consider MVS with all it's cool features that are accessible thru SYS1.MACLIB. Don't take SYS1.MACLIB so literally. Think about how easily we access those features in HLASM. Show me any possible C implementation that would make it easy to access these features in C (and most other languages too). With that implementation, would a programmer use that feature in C? Is that feature complex to use? Case in point would be I/O. In Unix, you get 1 very basic I/O method (file streams) without records because records and advanced MVS I/O techniques were too complex for a C usage implementation (you can use structures but it's not that common). Making the DCB / ACB features available to C programmers would be a usage nightmare. This choice has led Unix to a problem called "BIG DATA". Companies are struggling to solve the big data problem. It's rare that anyone considers MVS I/O as a brilliant idea nor do they understand why it is so revolutionary. The Unix big data problem is simply where data gets out of hand within the scope of available resources (e.g. an overused small amount of data). In Unix, most often the solution is to analyze and modify all the programs involved to use an SQL database. MVS programmers have several easy solutions before they must resort to an SQL database. If they must resort to an SQL database, they are ready because they designed the data around records. Think about why MVS I/O is such a brilliant idea. Programmers avoid SQL & databases because they require work and maintenance. On the other hand, MVS can often solve the problem without modifying a single program. E.g. convert the file to VSAM and turn on RLS. Define shared resources. Change I/O prioritization. Convert the file to a VSAM KSDS and modify the programs that would benefit from keyed access. We can use record locks instead of data enqueues. I'm sure there are more but you get the idea. C and Unix are about me (the programmer). I have complete flexibility and can do anything I want. The problem is that everything is the programmers responsibility and they must think about how they need to access data and how to secure it. MVS is about what's best for the company. Programmers are given wise choices. HLASM makes it easy to provide what programmers need to get the job done efficiently and easily. At the beginning, I mentioned using XML to demonstrate one of the basic problems with C. There must be over a hundred (red flag 1) available and most written in C. Most are variations of the same basic concept (implement new programming language referred to as a schema (red flag 2) and require 3 user functions be written (element start, element data, element end)(red flag 3)). If you recall my pseudo C logic, it was wrong but no one complained (red flag 4). We only wish it was that easy to code and understand (e.g. you maintain a list of the active lists in proper sequence or add a schema). It only included 5 elements but would certainly be far more complicated with 30, 40 or more elements. Truthfully, it was just easier to code in assembler than integrate an existing XML parser. If C had macro's and loctr, you could code a single statement to populate all 3 functions (element start, element data, element end) and generate the schema required by the C XML parser. As I said before, HLASM is a non-linear programming language.
