Well, I've been programming since 1960, have used everything from Assembler (D) to HLASM, write macros at the drop of a hat and have consistently defended the use of assemblers, but I have3 to disagree with you.
While there is a good deal of theology in the OO camp about the one true definition of object oriented programming, I believe that none of them would accept the facilities you cite as encapsulation, methods, objects or polymorphism and I'm certain that none of them would accept MVS as an OO OS; in fact, I doubt that you could find an MVS developer who would accept the claim. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 ________________________________________ From: IBM Mainframe Assembler List <ASSEMBLER-LIST@listserv.uga.edu> on behalf of Jon Perryman <jperr...@pacbell.net> Sent: Tuesday, February 13, 2018 10:48 PM To: ASSEMBLER-LIST@listserv.uga.edu Subject: Re: Solution OOP in HLASM Real HLASM OOP follows. Real HLASM programmers will understand why I said called certain people are incompetent when say things like "you can't HLASM OOP without jumping thru hoops", "another gem from Jon" and "doesn't understand OOP". Clearly they only know basic HLASM but believe they are well versed. For the HLASM programmers, here are C programmers beloved terminology that is important to OOP (using MVS I/O as example): 1. "object": IBM macros DCB & ACB work well to create multiple file objects. In this case at compile time instead of run time. 2. "methods": IBM macro's (Open, close, read and write) execute the functionality and require the DCB / ACB to identify the object. 3. "encapsulation": The DCB / ACB macros contain all the information about the object and open/close/read/write macros are the functions related to the ACB / DCB. 4. "polymorphism": "able to morph into many different things". JCL allows DSN=, SYSOUT= and SUBSYS= which completely change the nature of the DCB. In fact, there are many morphing features (DCB(dsorg, macrf, recfm, lrecl, ...), SSI, exits, ...). 5. "inheritance". If the DCB does not specify LRECL, it will be inherited from the JCL. DISP= does not exist in the DCB, yet the DCB will somehow inherit this attribute. HLASM OOP is a radically different (and far more versatile) OOP concept compared to other languages (probable exception is PLI). Here is comparison of the HLASM implementation compared to C++ which shows HLASM OOP is very impressive: 1. Objects: Represented any way you choose. E.g. by name (enq) or in some cases object is assumed unless you specify it. C++ always requires a variable to identify the object. 2. Inheritance: Functionality is dynamic and runtime ( E.g. dataset's. SMS, GRS, DFP, system commands and JCL can determine or override attributes). In fact, you can add OEM products to add to the functionality. In C++, you must specify inherited attributes in the object definition (class). 3. Polymorphism on steroids: From above, you can see some morphing examples. You are limited by your imagination. C++ has "function overload" to morph. This sad feature creates unique function names that include the argument types. E.g. Programmer uses aaa(num) which will call function aaa(num) instead of function aaa(string). 4. Encapsulation on steroids: Many features to contain an object (CSECTs, LOCTR, macro's and ...). C++ is limited to "class" which is a simple container. 5. Methods on steroids: You are limited by your imagination on how programmers use your functionality (e.g. multiple parms combined). In C++ you only have the function name (which is why they need "function overload" mentiioned above). MVS is an OOP OS. Some of the MVS objects that exhibit OOP traits mentioned above are SSI, records, components (e.g. JES2, JES3, DFP, HSM, TCP, TSO, CICS, IMS, GRS, SQL, databases, ...), component exits, OEM products and much much more. Does anyone know if IBM did this on purpose or if they simply stumbled upon the OOP concept? Why do C programmers need to know every little detail when it can easily be hidden? The worst thing to happen in the IT industry is the C mentality. C++ is a mediocre OOP implementation. When it was created, they had the chance to make it very significant improvements. Unix would have greatly benefited if it went OOP. C programmers here who proclaim they understand HLASM & MVS concepts clearly don't because they are professing C and C++ were well done compared to HLASM. If they were right, then Unix would not be struggling to deal with "big data" and "cloud" which MVS addressed decades ago. Are they actually helping Unix to evolve into something better or are they trying to drag MVS down to their level? I think they are doing more harm than good. I worked on a product for the NASDAQ, Yahoo, and ???). Each combination of the product had a different set of calls (standard, encrypt, guaranteed delivery, broadcast, 2 phase commit, ..., encrypt+broadcast, encrypt+guarantee, ...). C++ OOP does not solve this type of problem. Most C programmers simply don't have the skills to do OOP without a tool (e.g. C++) that does the work for them. An incompetent worker blames it on his tools. The C programmers here say you can't write OOP C (only OOD C - design) and must use C++. Unix file I/O clearly shows OOP is possible in C. In reality, you can write OOP in any language. C++ gives programmers who can't code OOP C, a foolproof tool to code OOP C in a simple way. This simplicity comes at a cost. E.g. What is the meaning of "global variables". On the SSI, it's SSCTUSR. In CICS, its the comm area. IMS probably must have a method. IBM will assign OEM products an anchor reserved for their products. C global variables are rarely a solution for the real problem. Incompetence is often buried in misunderstood terminology that is not clearly defined. If people have problems with "string", then they don't stand a chance with OOP terminology. As a side note, a string has a beginning, end and everything in between. Can you actually have a string less than 3 bytes? I don't believe that the beginning and end are part of the definition. Shouldn't a string begin at the first non-null character and end with next null character? It boggles the mind that C programmers see OOP in many languages, but could not see that as a valid HLASM solution. To implement C++ style OOP, everything you need to know is apparent by looking at samples in those langauges. The important points are listed here: 1. An object (e.g. a specific leg of the spider robot) contains all the functions specific to that object. 2. Functions are called thru the object using a branch table (ASM term) or callback table (C term). 3. The caller must have a Variable that is always used to reference the object and it's functions. 4. Passing global data depends means different things on MVS (sysplex, system, job, task or ???). C "global" variables only work for very specific situations. In HLASM, you have several choices: -4a. Use an MVS named token for the system, job or task. -4b. a specific register is reserved in all programs for this use (e.g. R7). -4c. From the save area of a known program (TCB or RB chain) -4d. Store it in the first save area (tcbfsa). -4e. Use "identify" to make it visible to the load macro. -4f. Use an SSCT entry to make this value available. -4g. Exit area reserved for this use. -4h. probably more that I forgot. Apparently, they see this as a complicated (almost impossible) thing to write. The HLASM guys were onto the solution and would have solved it. Regards, Jon.
