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
