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.

Reply via email to