OOP

[Glen]

Someone wrote:


  "OOP is, I think, quite a bit more than a calling standard - it boils 
down to an


abstracted thought process that you simply cannot do in Assembler.

As noted however, you an certainly write a dynamite compiler in HLASM that

compiles a OOP language. "

You can write OOP in Fortran 66, as I have known it done, and you can 
also do it in HLASM.


Yes it is an abstraction, and yes Fortran 66 and HLASM don't help you so 
much, but


the abstraction itself can be written in pretty much any language. Some 
languages have


protection that stops you from cheating, but you can decide not to cheat.

Some have features that help with readability, but again HLASM doesn't.

Re: OOP

[Paul Raulerson]

Hi Glen - like I said, I am willing to be convinced otherwise, but I have never 
seen an OOP program written in Fortran 66. Object Fortran - maybe. ;) 

Care to share an example of what you are talking about? It is possible we are 
not talking about the same things.  In my experience, OOP requires specific 
facilities in a language and run time that just are not there in straight 
procedural languages. 

-Paul 


> On Feb 6, 2018, at 11:41 PM, Glen  wrote:
> 
> Someone wrote:
> 
> 
>   "OOP is, I think, quite a bit more than a calling standard - it boils down 
> to an
> 
> abstracted thought process that you simply cannot do in Assembler.
> 
> As noted however, you an certainly write a dynamite compiler in HLASM that
> 
> compiles a OOP language. "
> 
> You can write OOP in Fortran 66, as I have known it done, and you can also do 
> it in HLASM.
> 
> Yes it is an abstraction, and yes Fortran 66 and HLASM don't help you so 
> much, but
> 
> the abstraction itself can be written in pretty much any language. Some 
> languages have
> 
> protection that stops you from cheating, but you can decide not to cheat.
> 
> Some have features that help with readability, but again HLASM doesn't.

Re: OOP

[Bernd Oppolzer]

I have to admit that I have not much experience with OOP,
I only wrote some C++ programs to do an introductory class
for C programmers on C++ and OOP concepts.

For me, a good OOP example would be, for example, templates.
I coded something in C which I consider OO design, that's a
AVL tree routine, which stores arbitrary data structures addressed
by arbitrary key structures in an automatically balanced AVL tree
https://en.wikipedia.org/wiki/AVL_tree

Because C has no OO support, I had to write it as an include file,
where the types of key and nodes and the compare functions etc.
are inserted by macro variables. This is what C++ tried to solve 
historically:

avoid the use of the preprocessor for such things and make for example
types as parameters of templates a feature of the language.

Regarding ASSEMBLER: with ASSEMBLER, you could do this by passing
entry points (of compare routines etc.) as part of the call of (for 
example)

AVL tree insert functions, and sizes of nodes (which differ) etc. etc.

That is: I'm sure you could find a solution similar to my C solution using
HLASM and its macro language. Will it be readable? May be ...

But IMO that's not really OOP, because true OOP has parametrized types
(types within types) and templates as part of the language ...

My 2 cents ...

BTW: I don't really like C++ because of the hidden overhead and the
lack of control ... I like my C solution very much :-) ...
it works on the mainframe (and on every other platform) without
any problem and yields amazing results.

Kind regards

Bernd



Am 07.02.2018 um 06:57 schrieb Paul Raulerson:

Hi Glen - like I said, I am willing to be convinced otherwise, but I have never 
seen an OOP program written in Fortran 66. Object Fortran - maybe. ;)

Care to share an example of what you are talking about? It is possible we are 
not talking about the same things.  In my experience, OOP requires specific 
facilities in a language and run time that just are not there in straight 
procedural languages.

-Paul

Re: OOP

[Bernd Oppolzer]

Something important about these AVL trees which would make
an ASSEMBLER implementation difficult (not impossible, of course)
is the recursive nature of the problem. The searching is done using
a recursive function which calls itself as often as the tree has levels.

With ASSEMBLER, you would either have to change the algorithm
or you would have to do all the bookkeeping of the recursive calls
yourself (which both is about the same effort).

Maybe you already have an existing mechanism for providing
automatic variables in ASSEMBLER ... but you will still have to take
care to stack the return addresses (and maybe base registers)
of the search function ...

BTW: the comparison between HLLs (C in this case, considered a HLL,
maybe disputable) and ASM should focus on such technical differences
instead of religion.

Kind regards

Bernd



Am 07.02.2018 um 07:21 schrieb Bernd Oppolzer:

I have to admit that I have not much experience with OOP,
I only wrote some C++ programs to do an introductory class
for C programmers on C++ and OOP concepts.

For me, a good OOP example would be, for example, templates.
I coded something in C which I consider OO design, that's a
AVL tree routine, which stores arbitrary data structures addressed
by arbitrary key structures in an automatically balanced AVL tree
https://en.wikipedia.org/wiki/AVL_tree

Because C has no OO support, I had to write it as an include file,
where the types of key and nodes and the compare functions etc.
are inserted by macro variables. This is what C++ tried to solve 
historically:

avoid the use of the preprocessor for such things and make for example
types as parameters of templates a feature of the language.

Regarding ASSEMBLER: with ASSEMBLER, you could do this by passing
entry points (of compare routines etc.) as part of the call of (for 
example)

AVL tree insert functions, and sizes of nodes (which differ) etc. etc.

That is: I'm sure you could find a solution similar to my C solution 
using

HLASM and its macro language. Will it be readable? May be ...

But IMO that's not really OOP, because true OOP has parametrized types
(types within types) and templates as part of the language ...

My 2 cents ...

BTW: I don't really like C++ because of the hidden overhead and the
lack of control ... I like my C solution very much :-) ...
it works on the mainframe (and on every other platform) without
any problem and yields amazing results.

Kind regards

Bernd



Am 07.02.2018 um 06:57 schrieb Paul Raulerson:
Hi Glen - like I said, I am willing to be convinced otherwise, but I 
have never seen an OOP program written in Fortran 66. Object Fortran 
- maybe. ;)


Care to share an example of what you are talking about? It is 
possible we are not talking about the same things.  In my experience, 
OOP requires specific facilities in a language and run time that just 
are not there in straight procedural languages.


-Paul

Re: OOP

[Jon Perryman]

> Someone wrote:

> "OOP is, I think, quite a bit more than a calling 
> standard - it boils down to an abstracted thought process 
> that you simply cannot do in Assembler.

We can simplify OOP. Some background information: OOP is a programming concept 
derived from our ability to classify. (e.g. When you see a child, you know what 
child can / can't do and when  you see an adult, you know they can / can't 
different things than the child. You have heard a lot of terminology that 
correctly describes OOP but it's  difficult to tie together. Let's try to 
forget the terminology and ignore the computer programming aspect for the 
moment.

You are a teacher who has "objects" in your classroom where each object has a 
name. These objects have several traits in common so we will classify("class") 
these traits as children. Children can run and play (methods) so you can now 
tell james to play. "class" Children doesn't have "method" study. We need 
"class" children to "inherit" "class" students. "class" student has "method" 
study so you can now tell james to study. You want James and nancy use the 
bathroom. You need a "class" boys and "class" girls. Objects that are boys must 
inherit boys and girls must inherit girls. As an alternative, you could add 
"method" bathroom to "class" children. You need variable ("attribute" or 
"property") gender. You would set "attribute" gender to boy or girl where 
"method" can choose the restroom. 

Time to learn terminology so you can talk with others:
"object" - each thing you want to control
"Method" - functions that the object can do.
"class" - this is where methods are defined instead of defining them for each 
object.
"attribute" - variable associated to an object or class.
"property" - same as attribute.
"absstraction" - You only care that an object can do something. You don't care 
how it is performed.

Each programming language may be different on implementation. There is more 
terminology. Hopefully this gives you a basic understanding of OOP.

Regards, Jon.

Re: OOP

[Dave Wade]

> -Original Message-
> From: IBM Mainframe Assembler List [mailto:ASSEMBLER-
> l...@listserv.uga.edu] On Behalf Of Jon Perryman
> Sent: 07 February 2018 09:50
> To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
> Subject: Re: OOP
> 
> > Someone wrote:
> 
> > "OOP is, I think, quite a bit more than a calling standard - it boils
> > down to an abstracted thought process that you simply cannot do in
> > Assembler.
> 
> We can simplify OOP. Some background information: OOP is a programming
> concept derived from our ability to classify. (e.g. When you see a child, you
> know what child can / can't do and when  you see an adult, you know they
> can / can't different things than the child. You have heard a lot of 
> terminology
> that correctly describes OOP but it's  difficult to tie together. Let's try to
> forget the terminology and ignore the computer programming aspect for the
> moment.
> 
> You are a teacher who has "objects" in your classroom where each object has
> a name. These objects have several traits in common so we will
> classify("class") these traits as children. Children can run and play 
> (methods)
> so you can now tell james to play. "class" Children doesn't have "method"
> study. We need "class" children to "inherit" "class" students. "class" student
> has "method" study so you can now tell james to study. You want James and
> nancy use the bathroom. You need a "class" boys and "class" girls. Objects
> that are boys must inherit boys and girls must inherit girls. As an 
> alternative,
> you could add "method" bathroom to "class" children. You need variable
> ("attribute" or "property") gender. You would set "attribute" gender to boy
> or girl where "method" can choose the restroom.
> 
> Time to learn terminology so you can talk with others:
> "object" - each thing you want to control "Method" - functions that the
> object can do.
> "class" - this is where methods are defined instead of defining them for each
> object.
> "attribute" - variable associated to an object or class.
> "property" - same as attribute.
> "absstraction" - You only care that an object can do something. You don't
> care how it is performed.
> 
> Each programming language may be different on implementation. There is
> more terminology. Hopefully this gives you a basic understanding of OOP.

What about events?  In .NET some objects fire events? Is this generally part of 
OOP or some extension...

> 
> Regards, Jon.


Dave

Re: OOP

[Paul Raulerson]

I do think you are trying to assume expertise you do not have here, though 
points for trying. 

I’ll just drop out of the conversation with you until you produce this HLASM 
object you say you have coded. That might make for interesting conversation 
indeed! 

Typos courtesy of my iPhone and my fat fingers!

On Feb 7, 2018, at 03:49, Jon Perryman  wrote:

>> Someone wrote:
> 
>> "OOP is, I think, quite a bit more than a calling 
>> standard - it boils down to an abstracted thought process 
>> that you simply cannot do in Assembler.
> 
> We can simplify OOP. Some background information: OOP is a programming 
> concept derived from our ability to classify. (e.g. When you see a child, you 
> know what child can / can't do and when  you see an adult, you know they can 
> / can't different things than the child. You have heard a lot of terminology 
> that correctly describes OOP but it's  difficult to tie together. Let's try 
> to forget the terminology and ignore the computer programming aspect for the 
> moment.
> 
> You are a teacher who has "objects" in your classroom where each object has a 
> name. These objects have several traits in common so we will 
> classify("class") these traits as children. Children can run and play 
> (methods) so you can now tell james to play. "class" Children doesn't have 
> "method" study. We need "class" children to "inherit" "class" students. 
> "class" student has "method" study so you can now tell james to study. You 
> want James and nancy use the bathroom. You need a "class" boys and "class" 
> girls. Objects that are boys must inherit boys and girls must inherit girls. 
> As an alternative, you could add "method" bathroom to "class" children. You 
> need variable ("attribute" or "property") gender. You would set "attribute" 
> gender to boy or girl where "method" can choose the restroom. 
> 
> Time to learn terminology so you can talk with others:
> "object" - each thing you want to control
> "Method" - functions that the object can do.
> "class" - this is where methods are defined instead of defining them for each 
> object.
> "attribute" - variable associated to an object or class.
> "property" - same as attribute.
> "absstraction" - You only care that an object can do something. You don't 
> care how it is performed.
> 
> Each programming language may be different on implementation. There is more 
> terminology. Hopefully this gives you a basic understanding of OOP.
> 
> Regards, Jon.

Re: OOP

[Paul Gilmartin]

On 2018-02-06, at 23:34:29, Bernd Oppolzer wrote:

> Something important about these AVL trees which would make
> an ASSEMBLER implementation difficult (not impossible, of course)
> is the recursive nature of the problem. The searching is done using
> a recursive function which calls itself as often as the tree has levels.
> 
> With ASSEMBLER, you would either have to change the algorithm
> or you would have to do all the bookkeeping of the recursive calls
> yourself (which both is about the same effort).
> 
> Maybe you already have an existing mechanism for providing
> automatic variables in ASSEMBLER ... but you will still have to take
> care to stack the return addresses (and maybe base registers)
> of the search function ...
>  
Don't dynamically opbtained work areas and chained register save
areas provide that function?

-- gil

Re: OOP

[Gary Weinhold]

I think of assembler as the preferred language for efficient recursive 
algorithms; as Gil points out, we already have standard macros to implement 
saving status as we chain deeper and restoring status as we climb back out.  
And we can avoid getmains at every level by acquiring memory for a stack as we 
enter the algorithm or using the hardware stack.  It could be argued that 
assembler could implement recursion better because it would allow more levels 
due to the ability to code for minimal stack requirements and flexibility in 
stack location.

Gary Weinhold
Senior Application Architect

DATAKINETICS | Data Performance & Optimization

Phone:  +1.613.523.5500 x216
Email:  weinh...@dkl.com

[http://www.dkl.com/wp-content/uploads/2015/07/dkl_logo.png]

Visit us online at www.DKL.com

[http://www.dkl.com/wp-content/uploads/2015/08/banner.png]

E-mail Notification: The information contained in this email and any 
attachments is confidential and may be subject to copyright or other 
intellectual property protection. If you are not the intended recipient, you 
are not authorized to use or disclose this information, and we request that you 
notify us by reply mail or telephone and delete the original message from your 
mail system.



__
On 2018-02-07 09:50, Paul Gilmartin wrote:

On 2018-02-06, at 23:34:29, Bernd Oppolzer wrote:



Something important about these AVL trees which would make
an ASSEMBLER implementation difficult (not impossible, of course)
is the recursive nature of the problem. The searching is done using
a recursive function which calls itself as often as the tree has levels.

With ASSEMBLER, you would either have to change the algorithm
or you would have to do all the bookkeeping of the recursive calls
yourself (which both is about the same effort).

Maybe you already have an existing mechanism for providing
automatic variables in ASSEMBLER ... but you will still have to take
care to stack the return addresses (and maybe base registers)
of the search function ...



Don't dynamically opbtained work areas and chained register save
areas provide that function?

-- gil

Re: OOP

[Jeremy Nicoll]

On Wed, 7 Feb 2018, at 06:34, Bernd Oppolzer wrote:
> Something important about these AVL trees which would make
> an ASSEMBLER implementation difficult (not impossible, of course)
> is the recursive nature of the problem. The searching is done using
> a recursive function which calls itself as often as the tree has levels.
> 
> With ASSEMBLER, you would either have to change the algorithm
> or you would have to do all the bookkeeping of the recursive calls
> yourself (which both is about the same effort).

About 35 years ago I took one of the recusrive sorting algorithms
out of Knuth's TAOCP and implemented it as a subroutine in a
COBOL program; I replaced recursion with storage of local variables 
in successive elements of arrays.  

-- 
Jeremy Nicoll - my opinions are my own.

Re: OOP

[Paul Gilmartin]

On 2018-02-07, at 09:12:35, bernd.oppol...@t-online.de wrote:

> yes, I Had to do the Same, when I implemented Quicksort in REXX, because 
> the OS/2 Implementation of REXX only supported some 32 nesting Levels.
>  
I just tried Regina on Linux.  A minimal program SIGSEGVed at over 29,000
levels.  Bad: That error should have been reported more cleanly.  Good:
29,000 is greater than 32.

Regina appears to be avaiable for OS/2:

http://sourceforge.net/projects/regina-rexx/files/regina-rexx/3.9.1/regina391os2.zip

-- gil

Re: OOP

[Bernd Oppolzer]

The following article describes my REXX implementation of Quicksort,
it is in German, unfortunately. But it contains the whole source code,
first the recursive solution, which didn't work, and then the non-recursive
solution. In fact, the problem occured at 45 levels with OS/2 REXX.

http://bernd-oppolzer.de/blog_20150115_151000.htm

Kind regards

Bernd



Am 07.02.2018 um 20:48 schrieb Paul Gilmartin:

On 2018-02-07, at 09:12:35, bernd.oppol...@t-online.de wrote:


yes, I Had to do the Same, when I implemented Quicksort in REXX, because
the OS/2 Implementation of REXX only supported some 32 nesting Levels.
  

I just tried Regina on Linux.  A minimal program SIGSEGVed at over 29,000
levels.  Bad: That error should have been reported more cleanly.  Good:
29,000 is greater than 32.

Regina appears to be avaiable for OS/2:
 
http://sourceforge.net/projects/regina-rexx/files/regina-rexx/3.9.1/regina391os2.zip

-- gil

Re: OOP

[Seymour J Metz]

Why not OOREXX on Linux?


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3


From: IBM Mainframe Assembler List  on behalf 
of Paul Gilmartin <0014e0e4a59b-dmarc-requ...@listserv.uga.edu>
Sent: Wednesday, February 7, 2018 2:48 PM
To: ASSEMBLER-LIST@listserv.uga.edu
Subject: Re: OOP

On 2018-02-07, at 09:12:35, bernd.oppol...@t-online.de wrote:

> yes, I Had to do the Same, when I implemented Quicksort in REXX, because
> the OS/2 Implementation of REXX only supported some 32 nesting Levels.
>
I just tried Regina on Linux.  A minimal program SIGSEGVed at over 29,000
levels.  Bad: That error should have been reported more cleanly.  Good:
29,000 is greater than 32.

Regina appears to be avaiable for OS/2:

http://secure-web.cisco.com/1mb1ioXThpSogvpE7ywWcuM1wyhVmF_iCW9GEqpL-7Sg9FXNRHPoZ_0EgssSS8V6lczzjl5dSd3lFIj_3J1IW-lnzmSKYZr-b1SHZl0SXvEDKFJm4QkuIh_VMCK0c-DvpzSQ_oF1tc6DzC-deghHNffZwue4ai28FQjaIjuwV8vJjmKwemn-MGUlycnl5oD-Yx7BdZXzBLsDiumv1WpXw6v2cU7bHMgijlbv81K-nZaj6fdD4zazf1zI3uOi_VyDuKLMGGDWGYE91MJmGlSmZVwmynzt5DoFdG4mLqgSX7VKnflMPj8LKj8nKn8lgcu6KdRDW2ZD45wEowEQdqXXxxwauK30iNHIReUPn4n_qoks6aqZULV8hqIudSFWjM1hMlaQtTicIAQDLZ3LtC4ovPZNQXRtHfK_-L7bdFNcQxPW-lh71cbotbirc7az6JrCh/http%3A%2F%2Fsourceforge.net%2Fprojects%2Fregina-rexx%2Ffiles%2Fregina-rexx%2F3.9.1%2Fregina391os2.zip

-- gil

Re: OOP

[Paul Gilmartin]

On 2018-02-08, at 09:20:33, Seymour J Metz wrote:

> Why not OOREXX on Linux?
>  
Yah.  But I concentrate on developing portable skills.

-- gil

OOP in HLASM

[Jon Perryman]

> Poster wrote: reflects the poster's lack of knowledge of OOP. 


> Poster wrote (Yes, many differences. The weakness of my example 

> kind of proves the larger point: HLASM is not an OOP language.)


This poster and several C programmers here believe OOP is difficult in HLASM. 
Very basic objects are extremely simple to implement (a few objects with 
methods and private attributes). It would take me less than 5 minutes to code. 



Is there a C programmer here who knows assembler well enough to tell us how to 
create a few simple objects with methods and private attributes? If you can't 
easily do this, then you don't know HLASM as well as you think. Who (C 
programmers) knows how to create simple objects in HLASM?


OOP is not rocket science. Most system problems don't need full blown OOP. 
There are many examples in z/OS where this simple implementation is all that we 
need. It has the benefit that it is very low overhead. In C++, you either have 
objects or you don't. If you are writing a large applications in HLASM, then 
Inheritance, virtual functions, overloading and ... may become necessary. Each 
of these can be handled as needed without much difficulty. 


> Poster wrote:

> I guess you can kind of do inheritance in HLASM. You could define 

> your own DCBD extensions and piggyback them


Clearly this poster doesn't know HLASM well enough. This does not require any 
complicated strange solution. 


> Poster wrote:

> IMHO the biggest lack in HLASM in this sort of regard is lack of variable 
> scope. 

> If I want to define a struct for C I can blithely name my variables input 

> and output. In an HLASM DSECT, I have to "fake" scope by naming my 

> symbols CM_input, CM_output and still hope for the 

> best -- there is still no guarantee of no name collisions. 


The very simple solution is well documented in the HLASM reference. We do this 
when we need to use a dsect twice at the same time. I think you know enough 
HLASM to be dangerous. Maybe I'm wrong and you can figure this out.


Regards, Jon.


> Charles Mills wrote: 


> IMHO the biggest lack in HLASM in this sort of regard is 

> lack of variable scope. The support for named DSECTs got us 

> halfway there, but symbols still must be unique. If I want 

> to define a struct for C I can blithely name my variables input 

> and output and count and size and so forth. In an HLASM DSECT 

> I have to "fake" scope by naming my symbols CM_input, CM_output, 

> CM_count, CM_size and so forth -- and still hope for the 

> best -- there is still no guarantee of no name collisions. 



> The assertion that you can do OOP in HLASM just reflects the 

> poster's lack of knowledge of OOP. To your list, add inheritance, 

> overloading, virtual functions, ... 



> I guess you can kind of do inheritance in HLASM. You could define 

> your own DCBD extensions and piggyback them on the end of the 

> IHADCB DSECT -- whatever additional fields you wanted to associate 

> with a DCB such a buffer pointers, counts, NOTE words, etc. In a 

> sense you have defined a child class of IHADCB. You could then 

> GETMAIN storage for this combined DSECT, kind of like instantiating 

> a child class. (Yes, many differences. The weakness of my example 

> kind of proves the larger point: HLASM is not an OOP language.)

AW: Re: OOP

[bernd.oppol...@t-online.de]

yes, I Had to do the Same, when I implemented Quicksort in REXX, because 
the OS/2 Implementation of REXX only supported some 32 nesting Levels.

Kind regards Bernd



Gesendet mit der Telekom Mail App
<http://www.t-online.de/service/redir/email_app_android_sendmail_footer.htm>



--- Original-Nachricht ---
Von: Jeremy Nicoll
Betreff: Re: OOP
Datum: 07.02.2018, 16:49 Uhr
An: ASSEMBLER-LIST@LISTSERV.UGA.EDU





On Wed, 7 Feb 2018, at 06:34, Bernd Oppolzer wrote:
> Something important about these AVL trees which would make
> an ASSEMBLER implementation difficult (not impossible, of course)
> is the recursive nature of the problem. The searching is done using
> a recursive function which calls itself as often as the tree has levels.
>
> With ASSEMBLER, you would either have to change the algorithm
> or you would have to do all the bookkeeping of the recursive calls
> yourself (which both is about the same effort).

About 35 years ago I took one of the recusrive sorting algorithms
out of Knuth's TAOCP and implemented it as a subroutine in a
COBOL program; I replaced recursion with storage of local variables
in successive elements of arrays.

--
Jeremy Nicoll - my opinions are my own.

Re: OOP in HLASM

[Paul Raulerson]

> On Feb 6, 2018, at 7:09 PM, Jon Perryman  wrote:
> 
>> Poster wrote: reflects the poster's lack of knowledge of OOP. 
> 
> 
>> Poster wrote (Yes, many differences. The weakness of my example 
> 
>> kind of proves the larger point: HLASM is not an OOP language.)
> 
> 
> This poster and several C programmers here believe OOP is difficult in HLASM. 
> Very basic objects are extremely simple to implement (a few objects with 
> methods and private attributes). It would take me less than 5 minutes to 
> code. 
> 
> 
> 
> Is there a C programmer here who knows assembler well enough to tell us how 
> to create a few simple objects with methods and private attributes? If you 
> can't easily do this, then you don't know HLASM as well as you think. Who (C 
> programmers) knows how to create simple objects in HLASM?
> 
> 
> OOP is not rocket science. Most system problems don't need full blown OOP. 
> There are many examples in z/OS where this simple implementation is all that 
> we need. It has the benefit that it is very low overhead. In C++, you either 
> have objects or you don't. If you are writing a large applications in HLASM, 
> then Inheritance, virtual functions, overloading and ... may become 
> necessary. Each of these can be handled as needed without much difficulty. 
> 
[snip]

Clearly, this is getting silly.  Let’s be clear here, you can not write Object 
Oriented Programs (OOP) in HLASM. The language does not support Object Oriented 
Programming.

You *can* write programs that implement Object Oriented Design (OOD) in HLASM, 
but you can do that in just about *any* language. It is much more difficult in 
HLASM than other languages, mostly because of “old school” programmers who 
scoff at things like data typing. (“I can move any kind of data I want into 
that memory area…!”)   Well of course they can, but that is not objected 
oriented design or programming in HLASM. (shrug) 

If you want to argue that, show me an example of an object you have designed in 
HLASM, defining the object, the class it defines and what inheritance it has, 
as well as the interface and package in whatever form you choose to implement. 
I purposely used the more generic terms here, rather than the terms from any 
specific language or implementation. Extra points, write a test hardness that 
shows us it actually works the way you designed it. 

I do not believe you can do it satisfactorily. You can code an OOP language in 
HLASM, I will grant, but I hold serious doubts you can do what you claim there. 

C - K&R C that is, does not support OOP either.  But like almost every other 
language, you can implement Object Oriented Design (OOD) in the language. 

This is all pretty basic stuff and it is hard to argue with. 

Please consider, HLASM is a fantastic platform for writing Bottom Up Design 
programs. It is fun to hack away in the weeds and see a really cool result pop 
out. 

It is also really good for coding detailed low level logic in. Yes of course 
you an read a record from a file with HLASM, but it doesn’t really shine in 
doing so until you read files with variable length data and dozens of variable 
length trailers - all of which require intense fiddling around with the data 
which may or may not be properly aligned for more structured access. 

It is ideal when you are getting down and really fiddling with hardware - 
although that is anything but a common task these days. Even a very clever 
person will most likely fail trying to outwit modern mainframe hardware, or out 
optimize a high level language. It isn’t good or bad, it just *is*. 

It’s like anything else, the right tool for some jobs. And it was written by 
very clever people indeed- it is awesome to see and use their work. 

However, insisting it is the best tool for every - or even most - jobs is just 
being pig headed. Same for implying that HLASM or z/OS is portable. They are 
not. 

 If all you have is a hammer, everything looks like a nail and you neat 
yourself silly trying to pound in that screw. 

Re: OOP in HLASM

[Tony Thigpen]

I think that Paul has forgotten that his favorite OOP still generates 
machine instructions. If C can do it, then it can be done in HLASM. OOP 
really boils down into a different type of 'calling' standard other than 
our nice and simple R1=>Parmlist, R14=return, R15=branch_to_address.


It's just that HLASM programmers are close enough to machine code that 
we 'see' those hundreds (or thousands) of instructions that are used to 
call an OOP routine and we are smart enough to know that we don't want 
that overhead on every single call. Why do you think that LE enabled 
HLASM code is so few and far between. It's the overhead.


The real definition of OOP should be:
"A programming method that 1) reduces code development time, 2) allows 
code to be shared with little or no documentation, and 3) allows the 
used of less-skilled programmers. This one time savings is then paid 
back many thousands of times over the life of the program due to the 
inefficiency of the generated code. OOPs promote the 'pay me later' part 
of 'pay me now or pay me later'."


Tony Thigpen

Paul Raulerson wrote on 02/06/2018 10:15 PM:

On Feb 6, 2018, at 7:09 PM, Jon Perryman  wrote:


Poster wrote: reflects the poster's lack of knowledge of OOP.




Poster wrote (Yes, many differences. The weakness of my example



kind of proves the larger point: HLASM is not an OOP language.)



This poster and several C programmers here believe OOP is difficult in HLASM. 
Very basic objects are extremely simple to implement (a few objects with 
methods and private attributes). It would take me less than 5 minutes to code.



Is there a C programmer here who knows assembler well enough to tell us how to 
create a few simple objects with methods and private attributes? If you can't 
easily do this, then you don't know HLASM as well as you think. Who (C 
programmers) knows how to create simple objects in HLASM?


OOP is not rocket science. Most system problems don't need full blown OOP. 
There are many examples in z/OS where this simple implementation is all that we 
need. It has the benefit that it is very low overhead. In C++, you either have 
objects or you don't. If you are writing a large applications in HLASM, then 
Inheritance, virtual functions, overloading and ... may become necessary. Each 
of these can be handled as needed without much difficulty.


[snip]

Clearly, this is getting silly.  Let’s be clear here, you can not write Object 
Oriented Programs (OOP) in HLASM. The language does not support Object Oriented 
Programming.

You *can* write programs that implement Object Oriented Design (OOD) in HLASM, 
but you can do that in just about *any* language. It is much more difficult in 
HLASM than other languages, mostly because of “old school” programmers who 
scoff at things like data typing. (“I can move any kind of data I want into 
that memory area…!”)   Well of course they can, but that is not objected 
oriented design or programming in HLASM. (shrug)

If you want to argue that, show me an example of an object you have designed in 
HLASM, defining the object, the class it defines and what inheritance it has, 
as well as the interface and package in whatever form you choose to implement. 
I purposely used the more generic terms here, rather than the terms from any 
specific language or implementation. Extra points, write a test hardness that 
shows us it actually works the way you designed it.

I do not believe you can do it satisfactorily. You can code an OOP language in 
HLASM, I will grant, but I hold serious doubts you can do what you claim there.

C - K&R C that is, does not support OOP either.  But like almost every other 
language, you can implement Object Oriented Design (OOD) in the language.

This is all pretty basic stuff and it is hard to argue with.

Please consider, HLASM is a fantastic platform for writing Bottom Up Design 
programs. It is fun to hack away in the weeds and see a really cool result pop 
out.

It is also really good for coding detailed low level logic in. Yes of course 
you an read a record from a file with HLASM, but it doesn’t really shine in 
doing so until you read files with variable length data and dozens of variable 
length trailers - all of which require intense fiddling around with the data 
which may or may not be properly aligned for more structured access.

It is ideal when you are getting down and really fiddling with hardware - 
although that is anything but a common task these days. Even a very clever 
person will most likely fail trying to outwit modern mainframe hardware, or out 
optimize a high level language. It isn’t good or bad, it just *is*.

It’s like anything else, the right tool for some jobs. And it was written by 
very clever people indeed- it is awesome to see and use their work.

However, insisting it is the best tool for every - or even most - jobs is just 
being pig headed

Re: OOP in HLASM

[Paul Raulerson]

Hi Tony -  I don’t think so, but anything is possible.  Of course, everything 
on every computer boils down to machine level instructions, but that isn’t 
relevant here, I think.  You can’t write an OOP program in machine language 
either. :) 

OOP is, I think, quite a bit more than a calling standard - it boils down to an 
abstracted thought process that you simply cannot do in Assembler. As noted 
however, you an certainly write a dynamite compiler in HLASM that compiles a 
OOP language. 

Even SmallTalk, which is my personal nemesis. :) 

I’m wiling to be proven wrong, and will buy the beer in that case. But I would 
honestly have to see a genuine full fledged OOP example in HLASM, including all 
the good stuff, to admit that. Hello World would do nicely. I just don’t 
believe it is possible. OOD, yes. OOP? Nope. 

Some small examples below. 

Smalltalk Hello World:   

 Transcript show: 'Hello, World!'; cr.      <- OOP. You cannot get 
much more OOP than this. Until you get into collections and recursive
blocks, which are 
mind bending to a HLASM, COBOL, or C Programmer. 

C++ Hello World:
#include<— Well, it uses objects, 
but is really rather procedural. Not really OOP IMNSHO. But then, I prefer
  Ada to C++. 
int main()
{
std::cout << "Hello, world!\n";
return 0;
}

-Paul


> On Feb 6, 2018, at 9:48 PM, Tony Thigpen  wrote:
> 
> I think that Paul has forgotten that his favorite OOP still generates machine 
> instructions. If C can do it, then it can be done in HLASM. OOP really boils 
> down into a different type of 'calling' standard other than our nice and 
> simple R1=>Parmlist, R14=return, R15=branch_to_address.
> 
> It's just that HLASM programmers are close enough to machine code that we 
> 'see' those hundreds (or thousands) of instructions that are used to call an 
> OOP routine and we are smart enough to know that we don't want that overhead 
> on every single call. Why do you think that LE enabled HLASM code is so few 
> and far between. It's the overhead.
> 
> The real definition of OOP should be:
> "A programming method that 1) reduces code development time, 2) allows code 
> to be shared with little or no documentation, and 3) allows the used of 
> less-skilled programmers. This one time savings is then paid back many 
> thousands of times over the life of the program due to the inefficiency of 
> the generated code. OOPs promote the 'pay me later' part of 'pay me now or 
> pay me later'."
> 
> Tony Thigpen
> 
> Paul Raulerson wrote on 02/06/2018 10:15 PM:
>>> On Feb 6, 2018, at 7:09 PM, Jon Perryman  wrote:
>>> 
>>>> Poster wrote: reflects the poster's lack of knowledge of OOP.
>>> 
>>> 
>>>> Poster wrote (Yes, many differences. The weakness of my example
>>> 
>>>> kind of proves the larger point: HLASM is not an OOP language.)
>>> 
>>> 
>>> This poster and several C programmers here believe OOP is difficult in 
>>> HLASM. Very basic objects are extremely simple to implement (a few objects 
>>> with methods and private attributes). It would take me less than 5 minutes 
>>> to code.
>>> 
>>> 
>>> 
>>> Is there a C programmer here who knows assembler well enough to tell us how 
>>> to create a few simple objects with methods and private attributes? If you 
>>> can't easily do this, then you don't know HLASM as well as you think. Who 
>>> (C programmers) knows how to create simple objects in HLASM?
>>> 
>>> 
>>> OOP is not rocket science. Most system problems don't need full blown OOP. 
>>> There are many examples in z/OS where this simple implementation is all 
>>> that we need. It has the benefit that it is very low overhead. In C++, you 
>>> either have objects or you don't. If you are writing a large applications 
>>> in HLASM, then Inheritance, virtual functions, overloading and ... may 
>>> become necessary. Each of these can be handled as needed without much 
>>> difficulty.
>>> 
>> [snip]
>> 
>> Clearly, this is getting silly.  Let’s be clear here, you can not write 
>> Object Oriented Programs (OOP) in HLASM. The language does not support 
>> Object Oriented Programming.
>> 
>> You *can* write programs that implement Object Oriented Design (OOD) in 
>> HLASM, but you can do that in just about *any* language. It is much more 
>> difficult in HLASM than other languages, mostly becaus

Re: OOP in HLASM

[Jon Perryman]

> Paul Raulerson wrote:
> Clearly, this is getting silly.

It's never silly to learn something new. Let's learn HLASM OOP.

It's a simple question. Show us you know enough HLASM to do simple OOP (not 
OOD). Your statements (not opinions) below are non-sense and you clearly aren't 
qualified to make them. Prove me wrong and show us you know basic HLASM 
techniques.

Regards, Jon.

Paul Raulerson wrote:

Let’s be clear here, you can not write Object Oriented Programs (OOP) in HLASM. 
The language does not support Object Oriented Programming.

You *can* write programs that implement Object Oriented Design (OOD) in HLASM,  
(shrug)

If you want to argue that, show me an example of an object you have designed in 
HLASM, defining the object, 

Please consider, HLASM is a fantastic platform for writing Bottom Up Design 
programs. It is fun to hack away in the weeds and see a really cool result pop 
out. 

It is also really good for coding detailed low level logic in. Yes of course 
you an read a record from a file with HLASM, but it doesn’t really shine 

It is ideal when you are getting down and really fiddling with hardware

However, insisting it is the best tool for every - or even most - jobs is just 
being pig headed. Same for implying that HLASM or z/OS is portable. They are 
not. 

Re: OOP in HLASM

[Jon Perryman]

Tony, this has nothing to do with machine instructions nor bits & bytes. 

Every programming language has specific techniques to solve problems in that 
language ( Python, PHP, C, assembler, HTML5, Cobol, ...). I'm talking about a 
technique most HLASM programmers would recognize (and probably used at least 
once in their life). No jumping thru hoops. Just standard every day HLASM. 

The biggest problem people have is they overthink it.
Thanks, Jon.

On Tuesday, February 6, 2018 7:48 PM, Tony Thigpen  wrote:

I think that Paul has forgotten that his favorite OOP still generates 
machine instructions. If C can do it, then it can be done in HLASM. OOP 
really boils down into a different type of 'calling' standard other than 
our nice and simple R1=>Parmlist, R14=return, R15=branch_to_address.

It's just that HLASM programmers are close enough to machine code that 
we 'see' those hundreds (or thousands) of instructions that are used to 
call an OOP routine and we are smart enough to know that we don't want 
that overhead on every single call. Why do you think that LE enabled 
HLASM code is so few and far between. It's the overhead.

The real definition of OOP should be:
"A programming method that 1) reduces code development time, 2) allows 
code to be shared with little or no documentation, and 3) allows the 
used of less-skilled programmers. This one time savings is then paid 
back many thousands of times over the life of the program due to the 
inefficiency of the generated code. OOPs promote the 'pay me later' part 
of 'pay me now or pay me later'."

Tony Thigpen


Paul Raulerson wrote on 02/06/2018 10:15 PM:
>> On Feb 6, 2018, at 7:09 PM, Jon Perryman  wrote:
>>
>>> Poster wrote: reflects the poster's lack of knowledge of OOP.
>>
>>
>>> Poster wrote (Yes, many differences. The weakness of my example
>>
>>> kind of proves the larger point: HLASM is not an OOP language.)
>>
>>
>> This poster and several C programmers here believe OOP is difficult in 
>> HLASM. Very basic objects are extremely simple to implement (a few objects 
>> with methods and private attributes). It would take me less than 5 minutes 
>> to code.
>>
>>
>>
>> Is there a C programmer here who knows assembler well enough to tell us how 
>> to create a few simple objects with methods and private attributes? If you 
>> can't easily do this, then you don't know HLASM as well as you think. Who (C 
>> programmers) knows how to create simple objects in HLASM?
>>
>>
>> OOP is not rocket science. Most system problems don't need full blown OOP. 
>> There are many examples in z/OS where this simple implementation is all that 
>> we need. It has the benefit that it is very low overhead. In C++, you either 
>> have objects or you don't. If you are writing a large applications in HLASM, 
>> then Inheritance, virtual functions, overloading and ... may become 
>> necessary. Each of these can be handled as needed without much difficulty.
>>
> [snip]
>
> Clearly, this is getting silly.  Let’s be clear here, you can not write 
> Object Oriented Programs (OOP) in HLASM. The language does not support Object 
> Oriented Programming.
>
> You *can* write programs that implement Object Oriented Design (OOD) in 
> HLASM, but you can do that in just about *any* language. It is much more 
> difficult in HLASM than other languages, mostly because of “old school” 
> programmers who scoff at things like data typing. (“I can move any kind of 
> data I want into that memory area…!”)   Well of course they can, but that is 
> not objected oriented design or programming in HLASM. (shrug)
>
> If you want to argue that, show me an example of an object you have designed 
> in HLASM, defining the object, the class it defines and what inheritance it 
> has, as well as the interface and package in whatever form you choose to 
> implement. I purposely used the more generic terms here, rather than the 
> terms from any specific language or implementation. Extra points, write a 
> test hardness that shows us it actually works the way you designed it.
>
> I do not believe you can do it satisfactorily. You can code an OOP language 
> in HLASM, I will grant, but I hold serious doubts you can do what you claim 
> there.
>
> C - K&R C that is, does not support OOP either.  But like almost every other 
> language, you can implement Object Oriented Design (OOD) in the language.
>
> This is all pretty basic stuff and it is hard to argue with.
>
> Please consider, HLASM is a fantastic platform for writing Bottom Up Design 
> programs. It is fun to hack away in the weeds and see a really cool result 
> pop

Re: OOP in HLASM

[Gary Weinhold]

Paul wrote (snipped):

Please consider, HLASM is a fantastic platform for writing Bottom Up Design 
programs. It is fun to hack away in the weeds and see a really cool result pop 
out.


It's also a fantastic language for writing top down design programs.  I've 
started many projects by writing all the modules and routines within the 
modules with calls or BAS (now JAS) to meaningful labels, localized comments 
for what would be done in the routines, perhaps a simple WTO to prove it got 
there and a BR to return.  Then I started coding from the top down, adding 
temporary code in lower levels where needed to return constant values so the 
design could be verified before I even considered what coding techniques I 
would use in the lower level routines.

Gary




Gary Weinhold
Senior Application Architect

DATAKINETICS | Data Performance & Optimization

Phone:  +1.613.523.5500 x216
Email:  weinh...@dkl.com

[http://www.dkl.com/wp-content/uploads/2015/07/dkl_logo.png]

Visit us online at www.DKL.com

[http://www.dkl.com/wp-content/uploads/2015/08/banner.png]

E-mail Notification: The information contained in this email and any 
attachments is confidential and may be subject to copyright or other 
intellectual property protection. If you are not the intended recipient, you 
are not authorized to use or disclose this information, and we request that you 
notify us by reply mail or telephone and delete the original message from your 
mail system.

Re: OOP in HLASM

[Paul Raulerson]

Yep, and that is the way I tend to code applications in HLASM or other 
assembler languages as well. That methodology doesn’t set well with everyone 
though, as it is “not efficient” or “wastes code” or “but why would I go to the 
trouble?” And of course, HLASM doesn’t enforce this practice, even if you use 
some of the structured macros. :)
 
I assume you also tend to use concepts like Data Typing where appropriate, and 
so on. These are all very good “best practices” in my opinion - practices of 
which I heartily approve of course.  

In fact, I contend that OOD (Object Oriented Development) is nothing less than 
a codification of all these kinds of best practices that programmers and 
engineers have learned and built up over the years. Given that, of course OOD 
applies to almost any possible project and can be applied to any  
implementation. 

OOP (Object Oriented Programming) however, is a much more specific instance, 
and is concerned much more with implementation than design. It is subject to 
endless arguments, stirs up religious fervor among the adherents of it’s 
various sects, and oftimes -  a practice that just gets in the way of doing the 
job. 

It’s a lot like Agile development that way.  And whatever you do, unless you 
want a really heated debate, don’t tell that to an Agile/SCRUM evangelist! :) 

-Paul 


> On Feb 7, 2018, at 9:44 AM, Gary Weinhold  wrote:
> 
> Paul wrote (snipped):
> 
> Please consider, HLASM is a fantastic platform for writing Bottom Up Design 
> programs. It is fun to hack away in the weeds and see a really cool result 
> pop out.
> 
> 
> It's also a fantastic language for writing top down design programs.  I've 
> started many projects by writing all the modules and routines within the 
> modules with calls or BAS (now JAS) to meaningful labels, localized comments 
> for what would be done in the routines, perhaps a simple WTO to prove it got 
> there and a BR to return.  Then I started coding from the top down, adding 
> temporary code in lower levels where needed to return constant values so the 
> design could be verified before I even considered what coding techniques I 
> would use in the lower level routines.
> 
> Gary
> 
> 
> 
> 
> Gary Weinhold
> Senior Application Architect
> 
> DATAKINETICS | Data Performance & Optimization
> 
> Phone:  +1.613.523.5500 x216
> Email:  weinh...@dkl.com<mailto:weinh...@dkl.com>
> 
> [http://www.dkl.com/wp-content/uploads/2015/07/dkl_logo.png]<http://www.dkl.com/>
> 
> Visit us online at www.DKL.com<http://www.dkl.com/>
> 
> [http://www.dkl.com/wp-content/uploads/2015/08/banner.png]<http://www.dkl.com/mailsig>
> 
> E-mail Notification: The information contained in this email and any 
> attachments is confidential and may be subject to copyright or other 
> intellectual property protection. If you are not the intended recipient, you 
> are not authorized to use or disclose this information, and we request that 
> you notify us by reply mail or telephone and delete the original message from 
> your mail system.

Re: OOP in HLASM

[Tom Marchant]

On Wed, 7 Feb 2018 05:05:44 +, Jon Perryman wrote:

>> Paul Raulerson wrote:
>> Clearly, this is getting silly.
>
>It's never silly to learn something new. Let's learn HLASM OOP.
>
>It's a simple question. Show us you know enough HLASM to do simple OOP (not 
>OOD). Your statements (not opinions) below are non-sense and you clearly 
>aren't qualified to make them. Prove me wrong and show us you know basic HLASM 
>techniques.

You asserted that you can do OOP in HLASM.

Paul said he didn't believe it, and asked you to demonstrate it.

You replied with "you clearly aren't qualified," and asked him to 
prove you wrong.

So, when you are asked to show that you can do what you say 
you can, you respond with ad hominem and a demand that he 
prove your assertion to be false.

This has grown beyond tiring. Now it is plain stupid.

-- 
Tom Marchant

>Paul Raulerson wrote:
>>
>>Let’s be clear here, you can not write Object Oriented Programs (OOP) in 
>>HLASM. The language does not support Object Oriented Programming.
>>
>>You *can* write programs that implement Object Oriented Design (OOD) in 
>>HLASM,  (shrug)
>>
>>If you want to argue that, show me an example of an object you have designed 
>>in HLASM, defining the object, 
>>
>>Please consider, HLASM is a fantastic platform for writing Bottom Up Design 
>>programs. It is fun to hack away in the weeds and see a really cool result 
>>pop out. 
>>
>>It is also really good for coding detailed low level logic in. Yes of course 
>>you an read a record from a file with HLASM, but it doesn’t really shine 
>>
>>It is ideal when you are getting down and really fiddling with hardware
>>
>>However, insisting it is the best tool for every - or even most - jobs is 
>>just being pig headed. Same for implying that HLASM or z/OS is portable. They 
>>are not. 

Re: AW: Re: OOP

[Paul Gilmartin]

On 2018-02-07, at 09:12:35, bernd.oppol...@t-online.de wrote:

> yes, I Had to do the Same, when I implemented Quicksort in REXX, because 
> the OS/2 Implementation of REXX only supported some 32 nesting Levels.
>  
Sigh.  z/OS Rexx does similarly, just with more levels.

So, it uses a static array for performance.  But when it reaches that limit,
instead of failing it should allocate another 32, chain it to the previous,
and continue in that fashion until resources are absolutely exhausted.

-- gil

Re: OOP in HLASM

[Jon Perryman]

>> Jon Perryman wrote: >>It's a simple question. Show us you know enough HLASM 
>> to do simple OOP (not OOD). 
> Tom Marchant wrote:> You asserted that you can do OOP in HLASM.

> Paul said he didn't believe it, and asked you to demonstrate it.

I'm waiting for Dr Ward to respond before I supply the answer. Here's a few 
more hints for the C programmers. Just like a C++ program (or several OOP 
languages), create a header and class definition but using HLASM techniques.  
There is a very well known Unix technique that mirrors this HLASM technique but 
in C doesn't qualify as OOP.
Most PHD's earn your respect instead of demanding it. Clearly Dr. Ward does not 
respect me as a C or HLASM programmer. Can he earn my respect by showing he 
understands HLASM basics? I don't think he knows HLASM as well as he wants us 
to believe.

Regards, Jon.   

Re: OOP in HLASM

[Jon Perryman]

>> Jon Perryman wrote:
>> Pick any non-trivial macro (e.g. not save or return)
> Peter Relson wrote:> FWIW, there might be others, but one 
> such language is PL/X.  Not that that 

> helps you any because PL/X is not available 
> in general.The functional language and its macro 
> language were created for exactly this purpose.

PL/X is good compared to C. It would take some getting used to because it does 
some strange things. The procedure caught me off guard because it can define a 
macro or actual code. 

Regards, Jon.

Re: OOP in HLASM

[Martin Ward]

On 08/02/18 01:29, Jon Perryman wrote:

Clearly Dr. Ward does not respect me as a C or HLASM programmer. Can
he earn my respect by showing he understands HLASM basics? I don't
think he knows HLASM as well as he wants us to believe.


I can't find any messages where I disrespect Jon as a C or HLASM
programmer. I have asked how certain things could be done
in assembler, because I genuinely want to know, for example:

On 05/02/18 17:32, Martin Ward wrote:

How do you define a function using assembler macros?
How do you define objects? In particular, how do you stop
the programmer from taking the address of an object
and examining/modifying the object's internals
without using the defined interface?


I would like to see an implementation of Knuth's
"man or boy test" in HLASM.

My claim to knowledge of HLASM is based on developing
an automated migration engine which transforms HLASM
to semantically equivalent C and COBOL. This has been
used commercially on millions of lines of assembler:
so I have seen many of the coding tricks used
by HLASM programmers in practice. I have written
some programs that generate simple HLASM programs
(autmated generation of test harnesses), but have
never actually implemented any large HLASM systems
and have never claimed to be able to do so.

--
Martin

Dr Martin Ward | Email: mar...@gkc.org.uk | http://www.gkc.org.uk
G.K.Chesterton site: http://www.gkc.org.uk/gkc | Erdos number: 4

Re: OOP in HLASM

[Tom Marchant]

On Thu, 8 Feb 2018 01:29:04 +, Jon Perryman wrote:

> Jon Perryman wrote:
>>It's a simple question. Show us you know enough HLASM to do simple OOP (not 
>>OOD). 
>> Tom Marchant wrote:
>>> You asserted that you can do OOP in HLASM.
>
>> Paul said he didn't believe it, and asked you to demonstrate it.
>
>I'm waiting for Dr Ward to respond before I supply the answer.

Why would you be waiting for Martin's response to your insult of Paul?

>Most PHD's earn your respect instead of demanding it. Clearly 
>Dr. Ward does not respect me as a C or HLASM programmer. Can 
>he earn my respect by showing he understands HLASM basics? 
>I don't think he knows HLASM as well as he wants us to believe.

And now you insult Martin, rather than demonstrate that you can do 
OOP in HLASM, as you claim you can. I assume that means that you 
are not able to.

-- 
Tom Marchant

Re: OOP in HLASM

[Gary Weinhold]

In one sense of implementing OOP in HLASM, it's trivial but onerous.  
Take an OOP language that has an open source compiler available for 
z/OS.  Using the object code if necessary, reverse engineer the entire 
compiler into assembler language and rebuild the compiler.  So you now 
have an OOP compiler written in assembler language.


Now write assembler macros to accept every statement written in the 
original language, possibly massaged to meet assembler coding 
restrictions, and pass that statement to the compiler you've written.  
When compiled, the OOP program will have been transformed from original 
format (assembler macros) to executable code entirely with assembler code.


That's probably not what anyone meant.

From this whole discussion, I think the challenge to add an HLASM 
routine to the list of languages in which the Knuth challenge, to 
correctly implement recursion and non-local references, is a more 
intriguing one.  That it can be done is obvious (just reverse engineer 
the object code of any existing z/OS solution), but that it can be done 
more efficiently and with more efficient use of memory than any other 
z/OS solution (and hence allow more iterations) would be the goal.


gary


Gary Weinhold 
Senior Application Architect 

DATAKINETICS | Data Performance & Optimization 


Phone   +1.613.523.5500 x216
Email:  weinh...@dkl.com

Visit us online at www.DKL.com 

E-mail Notification: The information contained in this email and any attachments is confidential and may be subject to copyright or other intellectual property protection. If you are not the intended recipient, you are not authorized to use or disclose this information, and we request that you notify us by reply mail or telephone and delete the original message from your mail system. 

Re: OOP in HLASM

[Seymour J Metz]

I can get down and dirty with machine code, but my standard coding practice is 
to use lots of macros to automate repetitive tasks, sometimes with different 
code paths depending on the target processor.

As to library overhead, I've certainly written code design to fir well in a 
PL/I environment and never found the overhead to be unreasonable. And, yes, 
there is other code where I sweat every cycle, but that's the exception.

I can't see using the full OO paradigm in HLASM, but I've certainly seen 
implementation of parts of it in assembler code.

That "definition" isn't a definition, it's simply a list of purport6ed 
benefits. There are theological arguments about the one true definition, but 
there is a broad consensus that it includes classes, methods, objects, messages 
and inheritance.


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3


From: IBM Mainframe Assembler List  on behalf 
of Tony Thigpen 
Sent: Tuesday, February 6, 2018 10:48 PM
To: ASSEMBLER-LIST@listserv.uga.edu
Subject: Re: OOP in HLASM

I think that Paul has forgotten that his favorite OOP still generates
machine instructions. If C can do it, then it can be done in HLASM. OOP
really boils down into a different type of 'calling' standard other than
our nice and simple R1=>Parmlist, R14=return, R15=branch_to_address.

It's just that HLASM programmers are close enough to machine code that
we 'see' those hundreds (or thousands) of instructions that are used to
call an OOP routine and we are smart enough to know that we don't want
that overhead on every single call. Why do you think that LE enabled
HLASM code is so few and far between. It's the overhead.

The real definition of OOP should be:
"A programming method that 1) reduces code development time, 2) allows
code to be shared with little or no documentation, and 3) allows the
used of less-skilled programmers. This one time savings is then paid
back many thousands of times over the life of the program due to the
inefficiency of the generated code. OOPs promote the 'pay me later' part
of 'pay me now or pay me later'."

Tony Thigpen

Paul Raulerson wrote on 02/06/2018 10:15 PM:
>> On Feb 6, 2018, at 7:09 PM, Jon Perryman  wrote:
>>
>>> Poster wrote: reflects the poster's lack of knowledge of OOP.
>>
>>
>>> Poster wrote (Yes, many differences. The weakness of my example
>>
>>> kind of proves the larger point: HLASM is not an OOP language.)
>>
>>
>> This poster and several C programmers here believe OOP is difficult in 
>> HLASM. Very basic objects are extremely simple to implement (a few objects 
>> with methods and private attributes). It would take me less than 5 minutes 
>> to code.
>>
>>
>>
>> Is there a C programmer here who knows assembler well enough to tell us how 
>> to create a few simple objects with methods and private attributes? If you 
>> can't easily do this, then you don't know HLASM as well as you think. Who (C 
>> programmers) knows how to create simple objects in HLASM?
>>
>>
>> OOP is not rocket science. Most system problems don't need full blown OOP. 
>> There are many examples in z/OS where this simple implementation is all that 
>> we need. It has the benefit that it is very low overhead. In C++, you either 
>> have objects or you don't. If you are writing a large applications in HLASM, 
>> then Inheritance, virtual functions, overloading and ... may become 
>> necessary. Each of these can be handled as needed without much difficulty.
>>
> [snip]
>
> Clearly, this is getting silly.  Let’s be clear here, you can not write 
> Object Oriented Programs (OOP) in HLASM. The language does not support Object 
> Oriented Programming.
>
> You *can* write programs that implement Object Oriented Design (OOD) in 
> HLASM, but you can do that in just about *any* language. It is much more 
> difficult in HLASM than other languages, mostly because of “old school” 
> programmers who scoff at things like data typing. (“I can move any kind of 
> data I want into that memory area…!”)   Well of course they can, but that is 
> not objected oriented design or programming in HLASM. (shrug)
>
> If you want to argue that, show me an example of an object you have designed 
> in HLASM, defining the object, the class it defines and what inheritance it 
> has, as well as the interface and package in whatever form you choose to 
> implement. I purposely used the more generic terms here, rather than the 
> terms from any specific language or implementation. Extra points, write a 
> test hardness that shows us it actually works the way you designed it.
>
> I do not beli

Re: OOP in HLASM

[Paul Raulerson]

> On Feb 8, 2018, at 4:22 PM, Paul Raulerson  wrote:
> 
> How about the? Object Oriented ASSEMBLER LANGUAGE - from 1990.  (grin)  Not 
> HLASM, but a fun read for language historians, amateur or otherwise! 
> 
> 
> The manual is out of copyright, and the entire book is available over at 
> Bitsavers, if anyone would like to read it. I reproduced a few pages here to 
> whet your appetites. :)  
> 
> Chapter 4 is the most interesting part to me, and provides an interesting 
> take on the subject I think. Caveat, I never used the OO parts of this 
> assembler, mostly because it just looked like “too much trouble.”   I wish I 
> had taken more time to study it back then.  In any event… enjoy!
> 
>  
> http://bitsavers.informatik.uni-stuttgart.de/pdf/borland/turbo_assembler/Turbo_Assembler_Version_5_Users_Guide.pdf
>  
> 
> 
> 
> 
> -Paul
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
>> On Feb 8, 2018, at 1:36 PM, Seymour J Metz > > wrote:
>> 
>> I can get down and dirty with machine code, but my standard coding practice 
>> is to use lots of macros to automate repetitive tasks, sometimes with 
>> different code paths depending on the target processor.
>> 
>> As to library overhead, I've certainly written code design to fir well in a 
>> PL/I environment and never found the overhead to be unreasonable. And, yes, 
>> there is other code where I sweat every cycle, but that's the exception.
>> 
>> I can't see using the full OO paradigm in HLASM, but I've certainly seen 
>> implementation of parts of it in assembler code.
>> 
>> That "definition" isn't a definition, it's simply a list of purport6ed 
>> benefits. There are theological arguments about the one true definition, but 
>> there is a broad consensus that it includes classes, methods, objects, 
>> messages and inheritance.
>> 
>> 
>> --
>> Shmuel (Seymour J.) Metz
>> http://mason.gmu.edu/~smetz3 
>> 
> 

Re: OOP in HLASM

[Steve Thompson]

I must challenge your statement about the copyright's expiration, 
or did the author put it in the public domain?


In what country was it originally copyrighted?

Has the author been dead more than 20 years? [and that death date 
may be different for the item to pass into the public domain as 
in the USofA the Mickey Mouse law keeps getting the date shoved 
further and further into the future.]


Regards,
Steve Thompson

On 02/08/2018 05:24 PM, Paul Raulerson wrote:

On Feb 8, 2018, at 4:22 PM, Paul Raulerson  wrote:

How about the? Object Oriented ASSEMBLER LANGUAGE - from 1990.  (grin)  Not 
HLASM, but a fun read for language historians, amateur or otherwise!


The manual is out of copyright, and the entire book is available over at 
Bitsavers, if anyone would like to read it. I reproduced a few pages here to 
whet your appetites. :)

Chapter 4 is the most interesting part to me, and provides an interesting take 
on the subject I think. Caveat, I never used the OO parts of this assembler, 
mostly because it just looked like “too much trouble.”   I wish I had taken 
more time to study it back then.  In any event… enjoy!

  
http://bitsavers.informatik.uni-stuttgart.de/pdf/borland/turbo_assembler/Turbo_Assembler_Version_5_Users_Guide.pdf
 




-Paul















On Feb 8, 2018, at 1:36 PM, Seymour J Metz mailto:sme...@gmu.edu>> wrote:

I can get down and dirty with machine code, but my standard coding practice is 
to use lots of macros to automate repetitive tasks, sometimes with different 
code paths depending on the target processor.

As to library overhead, I've certainly written code design to fir well in a 
PL/I environment and never found the overhead to be unreasonable. And, yes, 
there is other code where I sweat every cycle, but that's the exception.

I can't see using the full OO paradigm in HLASM, but I've certainly seen 
implementation of parts of it in assembler code.

That "definition" isn't a definition, it's simply a list of purport6ed 
benefits. There are theological arguments about the one true definition, but there is a 
broad consensus that it includes classes, methods, objects, messages and inheritance.


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3 

Re: OOP in HLASM

[Paul Raulerson]

Hi Steve - 

Borland, 1990, USA, and as far as I can tell, the copyright was not renewed 
after the product was abandoned. Copyright law in 1990 was still somewhat 
sane...

I am not a copyright lawyer though, so caveat emptor!

Typos courtesy of my iPhone and my fat fingers!

> On Feb 8, 2018, at 16:56, Steve Thompson  wrote:
> 
> I must challenge your statement about the copyright's expiration, or did the 
> author put it in the public domain?
> 
> In what country was it originally copyrighted?
> 
> Has the author been dead more than 20 years? [and that death date may be 
> different for the item to pass into the public domain as in the USofA the 
> Mickey Mouse law keeps getting the date shoved further and further into the 
> future.]
> 
> Regards,
> Steve Thompson
> 
> On 02/08/2018 05:24 PM, Paul Raulerson wrote:
>>> On Feb 8, 2018, at 4:22 PM, Paul Raulerson  wrote:
>>> 
>>> How about the? Object Oriented ASSEMBLER LANGUAGE - from 1990.  (grin)  Not 
>>> HLASM, but a fun read for language historians, amateur or otherwise!
>>> 
>>> 
>>> The manual is out of copyright, and the entire book is available over at 
>>> Bitsavers, if anyone would like to read it. I reproduced a few pages here 
>>> to whet your appetites. :)
>>> 
>>> Chapter 4 is the most interesting part to me, and provides an interesting 
>>> take on the subject I think. Caveat, I never used the OO parts of this 
>>> assembler, mostly because it just looked like “too much trouble.”   I wish 
>>> I had taken more time to study it back then.  In any event… enjoy!
>>> 
>>>  
>>> http://bitsavers.informatik.uni-stuttgart.de/pdf/borland/turbo_assembler/Turbo_Assembler_Version_5_Users_Guide.pdf
>>>  
>>> 
>>> 
>>> 
>>> 
>>> -Paul
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
 On Feb 8, 2018, at 1:36 PM, Seymour J Metz >>> > wrote:
 
 I can get down and dirty with machine code, but my standard coding 
 practice is to use lots of macros to automate repetitive tasks, sometimes 
 with different code paths depending on the target processor.
 
 As to library overhead, I've certainly written code design to fir well in 
 a PL/I environment and never found the overhead to be unreasonable. And, 
 yes, there is other code where I sweat every cycle, but that's the 
 exception.
 
 I can't see using the full OO paradigm in HLASM, but I've certainly seen 
 implementation of parts of it in assembler code.
 
 That "definition" isn't a definition, it's simply a list of purport6ed 
 benefits. There are theological arguments about the one true definition, 
 but there is a broad consensus that it includes classes, methods, objects, 
 messages and inheritance.
 
 
 --
 Shmuel (Seymour J.) Metz
 http://mason.gmu.edu/~smetz3 
 
>>> 

Re: OOP in HLASM

[Steve Thompson]

My understanding of US Copyright law is a bit different that 
yours. But, I'm not an attorney and I certainly haven't stayed at 
a H/I Express.


If M/F in acquiring Borland also by that purchase obtained the 
copyrights and other IP, then I seriously doubt that this is in 
the public domain. Which is why I asked them and am waiting for a 
response.


However, if Len Dorfman wrote this and was paid royalties by 
Borland, then Len still owns this (as opposed to Borland buying 
the "copyright").


Be careful in asserting that something has gone into the public 
domain in the area of copyright. You could get burned.


I have some interest in copyrights because of IP owned by my 
family. And to my knowledge the renewal of copyright was changed 
in the '60s to no longer needing to formally renew it. This is 
how certain music passed into the public domain because it 
expired before anyone realized that they still had to do a 
renewal to pass into the no renewals "zone", and copyright became 
the life of the author plus some number of years depending on how 
famous the author was (hence the nick-name for this law as the 
Mickey-Mouse law -- this was pursued by "Disney" to protect, you 
got it, Mickey Mouse and the rest).


Regards,
Steve Thompson

On 02/08/2018 06:09 PM, Paul Raulerson wrote:

Hi Steve -

Borland, 1990, USA, and as far as I can tell, the copyright was not renewed 
after the product was abandoned. Copyright law in 1990 was still somewhat 
sane...

I am not a copyright lawyer though, so caveat emptor!

Typos courtesy of my iPhone and my fat fingers!


On Feb 8, 2018, at 16:56, Steve Thompson  wrote:

I must challenge your statement about the copyright's expiration, or did the 
author put it in the public domain?

In what country was it originally copyrighted?

Has the author been dead more than 20 years? [and that death date may be 
different for the item to pass into the public domain as in the USofA the 
Mickey Mouse law keeps getting the date shoved further and further into the 
future.]

Regards,
Steve Thompson

On 02/08/2018 05:24 PM, Paul Raulerson wrote:

On Feb 8, 2018, at 4:22 PM, Paul Raulerson  wrote:

How about the? Object Oriented ASSEMBLER LANGUAGE - from 1990.  (grin)  Not 
HLASM, but a fun read for language historians, amateur or otherwise!


The manual is out of copyright, and the entire book is available over at 
Bitsavers, if anyone would like to read it. I reproduced a few pages here to 
whet your appetites. :)

Chapter 4 is the most interesting part to me, and provides an interesting take 
on the subject I think. Caveat, I never used the OO parts of this assembler, 
mostly because it just looked like “too much trouble.”   I wish I had taken 
more time to study it back then.  In any event… enjoy!

  
http://bitsavers.informatik.uni-stuttgart.de/pdf/borland/turbo_assembler/Turbo_Assembler_Version_5_Users_Guide.pdf
 




-Paul















On Feb 8, 2018, at 1:36 PM, Seymour J Metz mailto:sme...@gmu.edu>> wrote:

I can get down and dirty with machine code, but my standard coding practice is 
to use lots of macros to automate repetitive tasks, sometimes with different 
code paths depending on the target processor.

As to library overhead, I've certainly written code design to fir well in a 
PL/I environment and never found the overhead to be unreasonable. And, yes, 
there is other code where I sweat every cycle, but that's the exception.

I can't see using the full OO paradigm in HLASM, but I've certainly seen 
implementation of parts of it in assembler code.

That "definition" isn't a definition, it's simply a list of purport6ed 
benefits. There are theological arguments about the one true definition, but there is a 
broad consensus that it includes classes, methods, objects, messages and inheritance.


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3 

Re: OOP in HLASM

[Paul Raulerson]

Sent from my iPad

> On Feb 8, 2018, at 7:40 PM, Steve Thompson  wrote:
> 
> My understanding of US Copyright law is a bit different that yours. But, I'm 
> not an attorney and I certainly haven't stayed at a H/I Express.
> 
> If M/F in acquiring Borland also by that purchase obtained the copyrights and 
> other IP, then I seriously doubt that this is in the public domain. Which is 
> why I asked them and am waiting for a response.
> 
> However, if Len Dorfman wrote this and was paid royalties by Borland, then 
> Len still owns this (as opposed to Borland buying the "copyright").
> 
> Be careful in asserting that something has gone into the public domain in the 
> area of copyright. You could get burned.
> 
> I have some interest in copyrights because of IP owned by my family. And to 
> my knowledge the renewal of copyright was changed in the '60s to no longer 
> needing to formally renew it. This is how certain music passed into the 
> public domain because it expired before anyone realized that they still had 
> to do a renewal to pass into the no renewals "zone", and copyright became the 
> life of the author plus some number of years depending on how famous the 
> author was (hence the nick-name for this law as the Mickey-Mouse law -- this 
> was pursued by "Disney" to protect, you got it, Mickey Mouse and the rest).
> 
> Regards,
> Steve Thompson
> 
>> On 02/08/2018 06:09 PM, Paul Raulerson wrote:
>> Hi Steve -
>> Borland, 1990, USA, and as far as I can tell, the copyright was not renewed 
>> after the product was abandoned. Copyright law in 1990 was still somewhat 
>> sane...
>> I am not a copyright lawyer though, so caveat emptor!
>> Typos courtesy of my iPhone and my fat fingers!
>>> On Feb 8, 2018, at 16:56, Steve Thompson  wrote:
>>> 
>>> I must challenge your statement about the copyright's expiration, or did 
>>> the author put it in the public domain?
>>> 
>>> In what country was it originally copyrighted?
>>> 
>>> Has the author been dead more than 20 years? [and that death date may be 
>>> different for the item to pass into the public domain as in the USofA the 
>>> Mickey Mouse law keeps getting the date shoved further and further into the 
>>> future.]
>>> 
>>> Regards,
>>> Steve Thompson
>>> 
>>> On 02/08/2018 05:24 PM, Paul Raulerson wrote:
> On Feb 8, 2018, at 4:22 PM, Paul Raulerson  wrote:
> 
> How about the? Object Oriented ASSEMBLER LANGUAGE - from 1990.  (grin)  
> Not HLASM, but a fun read for language historians, amateur or otherwise!
> 
> 
> The manual is out of copyright, and the entire book is available over at 
> Bitsavers, if anyone would like to read it. I reproduced a few pages here 
> to whet your appetites. :)
> 
> Chapter 4 is the most interesting part to me, and provides an interesting 
> take on the subject I think. Caveat, I never used the OO parts of this 
> assembler, mostly because it just looked like “too much trouble.”   I 
> wish I had taken more time to study it back then.  In any event… enjoy!
> 
>  
> http://bitsavers.informatik.uni-stuttgart.de/pdf/borland/turbo_assembler/Turbo_Assembler_Version_5_Users_Guide.pdf
>  
> 
> 
> 
> 
> -Paul
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
>> On Feb 8, 2018, at 1:36 PM, Seymour J Metz > > wrote:
>> 
>> I can get down and dirty with machine code, but my standard coding 
>> practice is to use lots of macros to automate repetitive tasks, 
>> sometimes with different code paths depending on the target processor.
>> 
>> As to library overhead, I've certainly written code design to fir well 
>> in a PL/I environment and never found the overhead to be unreasonable. 
>> And, yes, there is other code where I sweat every cycle, but that's the 
>> exception.
>> 
>> I can't see using the full OO paradigm in HLASM, but I've certainly seen 
>> implementation of parts of it in assembler code.
>> 
>> That "definition" isn't a definition, it's simply a list of purport6ed 
>> benefits. There are theological arguments about the one true definition, 
>> but there is a broad consensus that it includes classes, methods, 
>> objects, messages and inheritance.
>> 
>> 
>> --
>> Shmuel (Seymour J.) Metz
>> http://mason.gmu.edu/~smetz3 
>> 
> 

Re: OOP in HLASM

[Peter Relson]

PL/X is good compared to C. It would take some getting used to because it 
does some strange things. The procedure caught me off guard because it can 
define a macro or actual code. 


A procedure in PL/X cannot define a macro. A procedure in PL/X is a code 
construct. 

Peter Relson
z/OS Core Technology Design

Solution OOP in HLASM

[Jon Perryman]

Part 1. This is the ASM code C OOP programmers expect to see. I'll send the 
actual OOP iplementation and comments in another posting. The terminology used 
here is understandable by an asm programmer and C programmers can easily figure 
out the OOP term (e.g. class and header files). 

I hope this sample is self explanatory on basic OOP.

NEVER use C++ style OOP in HLASM. HLASM OOP solutions are far better than the 
C++ implemention you see here. Shortly, I will send a full description of 
actual HLASM OOP.  

=== Main program =

To make this understandable and a little more fun, let's consider a hexapod 
(spider) robot.  6 legs and 18 servos (motors that can be positioned). This 
simple OOP program creates frontleft and frontRight legs, takes 1 step and stops

   LEG   DSECT    setup OOP for leg

wrkDSECT , 
frontLeft  DC   A(0)  leg object
frontRight DC   A(0)  leg object

MAIN_PGM   CSECT ,

   LEG  (frontLeft,CREATE)front left leg object now exists
   LEG  (frontRight,CREATE)   front right leg object now exists

   LEG  (frontLeft,UP)
   LEG  (frontLeft,FORWARD)
   LEG  (frontLeft,DOWN)

   LEG  (frontRight,UP)
   LEG  (frontRight,FORWARD)
   LEG  (frontRight,DOWN)

   LEG  (frontLeft,BACKWARD)

   LEG  (frontRight,BACKWARD)

   LEG  (frontLeft,DESTROY) front left leg object no longer 
exists
   LEG  (frontRight,DESTROY)front right leg object no 
longer exists


=== leg model =

This is the leg model that has the private data following the model statement. 
The functions are called from the program above. Create initializes the leg and 
makes sure it's not stuck under the spider. Destroy is called when finished. 
It's relaxes the motors so they don't drain the batteries. I think that UP, 
DOWN, FORWARD and BACKWARD are obvious. If not, let me know what is not clear.

LEG   OOP   MODEL
LOCATION  DCCL2' '   First character is F=front M=middle R=rear
*Second character is  L=left R=right
S_KNEEDCA(0) servo object for Knee
S_HIP DCA(0) servo object for hip 
S_HHIPDCA(0) servo object for horizontal hip movement

CREATEOOP   FUNCTION
  L R2,0(R1)  First parm
  MVC   LOCATION,0(R2)
* Create servos for this leg
  SERVO (S_KNEE,CREATE)
  SERVO (S_HIP,CREATE)
  IF   (CLI,SIDE+1,EQ,C'L')  Left side  
  SERVO (S_HHIP,CREATE)
  ELSE  ,
  SERVO (S_HHIP,CREATE),DIRECTION=REVERSEDmotor is opposite 
direction from left side
  END
* Make sure leg is not under spider
  SERVO (S_HIP,POSITION,50)
  SERVO (S_KNEE,POSITION,50)
      SERVO (S_HHIP,POSITION,0) 

DESTROY   OOP   FUNCTION
  SERVO (S_HIP,POSITION,FREE)   Turn power off
  SERVO (S_HIP,DESTROY)
  SERVO (S_KNEE,POSITION,FREE)  Turn power off
  SERVO (S_KNEE,DESTROY)
  SERVO (S_HHIP,POSITION,FREE)  Turn power off
  SERVO (S_HHIP,DESTROY)

UPOOP   FUNCTION
  SERVO (S_HIP,POSITION,50)
      SERVO (S_KNEE,POSITION,50)

DOWN  OOP   FUNCTION
  SERVO S_HIP,POSITION,-50)
      SERVO S_KNEE,POSITION,-50)

FORWARD   OOP   FUNCTION
      SERVO S_HHIP,POSITION,50)

BACKWARD  OOP   FUNCTION
      SERVO S_HHIP,POSITION,-50)
   
  OOP   END
  END

=== LEG macro =

This macro is the HLASM equivalent of the C++ header for the model above.  

   MACRO
   LEG,
   OOP   model=LEG,
 functions=(UP,DOWN,FORWARD,BACKWARD), callable functions
 CHILDREN=(aa,bb,cc),  inherited models
 &syslist(1)   action and action parms
   MEND ,

Re: Solution OOP in HLASM

[Jon Perryman]

Part 2 of the C++ style OOP in HLASM . Here is the OOP macro and program.

Don't use this code. It is for demonstation purposes that HLASM can easily 
implement the C++ style of OOP. Actual HLASM OOP is far better than using this.

C++ programmer works with the object by using funtions that come from the 
model. Unknown to the programmer, the object may have inherited objects 
(children). Any function names in the children not in the object will magically 
appear to the programmer as object functions. If the object already has that 
function name, then the children functions are ignored. These ignored children 
functions can be called by the function using call-child-function (OOP term is 
SUPER). 

   MACRO ,
   OOP &MODEL=, 
   &CHILDREN=, 
   &functions=,
   &sep= 

&object setc upper('&MODEL')
&function setc upper('&syslist(1)')
   aif ('&function' eq 'MODEL').l30mdl
   aif ('&function' eq 'FUNCTION').l20func
   aif ('&function' eq 'END').l10end
   aif ('&function' eq 'FUNCLIST').l40flst
   aif ('&function' eq 'FUNCLST2').l50fls2
   aif ('&function' eq 'DSECT').l70dsct
   aif ('&function' eq 'DATA').L80data
&object setc upper('&syslist(1,1)')
&function setc upper('&syslist(1,2)')
   aif ('&function' eq 'CHLDLIST').l60chdl
   aif ('&function' ne '').l90call

   mnote 8,'invalid function &work'
   mexit ,

.*** OOP END statement ***
.l10end  anop ,
LRr1,r13 return the object
return (14,12),r1=(1),rc=0
mexit ,

. OOP function statement - issue return from previous function and 
start this function **
.l20func anop ,
   lrr1,r13  return the object
   return (14,12),r1=(1),rc=0

&object  DS  0H
   mexit

.*** Model statement - start the csect 
.*** Note LOCTR is used to move functions & children lists outside the 
model definition
.l30mdl anop ,
&object CSECT ,  start of model

OOPFNC   LOCTR ,
OOPFNC   DS 0Aexternal functions
 &object funclist
 DS   X'00'   End of list
OOPCHILD DS 0AChildren objects 
 &object CHLDLIST
 DS   X'00'   endlist
&object  LOCTR ,

oop   data,sep='' data needs labels
mexit ,

.* generate list of public functions supported by this model
.l40flst anop ,
  gblc &mdl
&mdl  setc '&model'
  &model funclst2inherited functions 
&cnt  seta 1
.l40loop  aif  (&cnt gt n'&functions).l40end
  dc   cl16'&functions(&cnt)',a(&functions(&cnt)) public function
  ago  .l40loop
.l40end   anop ,
  dc   x'00'   end of public functions
   mexit ,


. validation list of functions available in this model and all 
children model's
.l50fls2 anop ,
  &model functlst2Inherited funtions  
&cnt  seta 1
.l50loop  aif  (&cnt gt n'&functions).l50end
  gblc &(&mdl)
      gblb &(f_&mdl._&function)
&(F_&mdl._&function) SETB 1   This function exists
  ago  .l50loop
.l50end   anop ,
      dc   x'00'   end of public functions
   mexit ,

.* generate list of children models to be defined
.l60chdl anop ,
&CNT SETA  1
.l60loop AIF   (&CNT GT N'&CHILDREN).l60done
 DCCL8'&CHILDREN(&CNT)',A(0)Child model
 AGO   .l60loop
.l60DONE ANOP ,
 mexit ,

.* OOP DSECT definition for user program
.l70dsct  anop ,
&s      setc  '0)   '  can't allow data
OOPDDSECT
AIF   ('&SYSECT' EQ 'OOP').L70END
oop   data,sep='0)'   disable addr labels
.L70END ANOP  ,
mexit ,

.* fields in the OOP DSECT (or in OOP MODEL)
.l80data   anop  ,
OOPSAVER DC  18A
OOPID   DC CL4'MDL'
OOPMODEL DC A(&s &object )  Address of this model
OOPCHILD DC A(&s OOPCHLD) Address of children list
OOPFUNC  DC A(&s OOPFNC)  Address of public functions
OOPWORK  DC XL8   Work area for OOP program
 mexit ,

.********* Call module OOP (OOP function call program
.l90call anop ,
 aif ('&object' eq '').l90ok
 mnote 8,'object required'
 mexit ,
.l90ok   anop , 
 aif ('&function' eq 'CREATE').l90cre
 gblb &(f_&model.

Re: Solution OOP in HLASM

[Jon Perryman]

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. 

Re: Solution OOP in HLASM

[Seymour J Metz]

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  on behalf 
of Jon Perryman 
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 differ

Re: Solution OOP in HLASM

[Jon Perryman]

 > Seymour Metz wrote:

> 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 have 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.
Stating opinions as fact? This is exactly what pissed me off with the C 
programmers and now you are towing their line. 
Give us a single fact other than the masses don't believe HLASM can't be OOP. 
Give a fact that I'm wrong. What did they say that convinced you HLASM is not 
OOP?  I thought you were better than this and did not blindly assume the masses 
are always right.
Are you saying C++ is not OOP? Are you saying my sample is unrecognizable as 
OOP by a C++ programmer when it nearly matches the C++ implementation? This 
sample was needed because C programmers believe there is only one way to do OOP 
and it can't possibly be different.
Are you saying I picked the wrong OOP terminology? What is the correct 
terminology?What convinced you that I can't possibly be right?
C programmers love terminology and these terms are the ones most OOP 
programmers agree upon. Are you saying I don't understand these terms?
Are you saying it's impossible to have an OOP OS? 
Tell me where I made a mistake and not that I can't possibly understand.
Please give us something other than I'm wrong.

Regards, Jon.
> From:  Jon Perryman - orignal post
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 pr

Re: Solution OOP in HLASM

[Jon Perryman]

-- reformatted message -- sorry I forgot to make it readable by this group.

> Seymour Metz wrote:

> 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 have 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.

Stating opinions as fact? This is exactly what pissed me off with the C 
programmers and now you are towing their line. 

Give us a single fact other than the masses don't believe HLASM can't be OOP. 
Give a fact that I'm wrong. What did they say that convinced you HLASM is not 
OOP?  I thought you were better than this and did not blindly assume the masses 
are always right.

Are you saying C++ is not OOP? Are you saying my sample is unrecognizable as 
OOP by a C++ programmer when it nearly matches the C++ implementation? This 
sample was needed because C programmers believe there is only one way to do OOP 
and it can't possibly be different.

Are you saying I picked the wrong OOP terminology? What is the correct 
terminology?What convinced you that I can't possibly be right?

C programmers love terminology and these terms are the ones most OOP 
programmers agree upon. Are you saying I don't understand these terms?

Are you saying it's impossible to have an OOP OS? 

Tell me where I made a mistake and not that I can't possibly understand.

Please give us something other than I'm wrong.

Regards, Jon.

> From:  Jon Perryman - orignal post

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

Re: Solution OOP in HLASM

[Ze'ev Atlas]

JonYou could create objects in HLASM, as the other gentleman demonstrated with 
a real life example of a session manager.  If we define objects as some entity 
that could be probed in runtime, then by all means you could do that in HLASM.  
I am not a great fan of oo languges as they tend to stand between you and what 
you wasnt to do.  As for this psedocode demonstrate, assuming you want to match 
some regex with a string
In a non oo langage you do
If string matches pattern then do something
In oo language you do
Declare a regex object
Instanciate the regex object
Apply the pattern to the object
Apply the object.match method to the string
If it matches then do something
However, if you so choose to go the oo rout, then the syntax of the language 
lend itself to the oo way.  HLASM and its macro languge are second to none.  
The syntax is not oo.  You could obviiusly build objects, instanciate them, 
apply values and use their methods, but the syntax of HLASM will never be oo.
ZA
Sent from Yahoo Mail on Android 
 
  On Thu, Feb 15, 2018 at 6:37 PM, Jon Perryman wrote:   
-- reformatted message -- sorry I forgot to make it readable by this group. 

Re: Solution OOP in HLASM

[Jon Perryman]

OOP is extremely easy to use. It's the unnecessary terminology that makes it 
difficult. I believe wholeheartedly that HLASM and MVS are OOP but simply never 
justified using the terminology C programmers so strongly need. There are 
several people in this group who believe the opposite. I would love to find out 
if I am wrong. Let's use DCB & ACB as the objects because everyone understands 
the basics of how it works in MVS. 

Sorry Seymour. You caught me off guard with your justification for disagreeing 
(60 years experience, OOP programmers would disagree with me and and an 
unsubstantiated "In fact"). This is a typical C programmer response to prove 
their point. For a time, I too believed C programmers until I realized they 
will say anything to prove their point. Some sort of relevant facts would have 
been greatly appreciated. 

I find that the important terminology is very consistent for all OOP languages 
(object, methods, encapsulation, polymorphism and inheritance). Did I leave out 
any important terms? Are these not commonly accepted by OOP programmers in all 
languages? 

In my original posting below, I listed these terms and how they are represented 
within an DCB & ACB environment. Please tell me how these do not fit the 
definition of the term being used? 

Seymour said that there is a lot of OOP disagreement in the OO camp. I believe 
that most of the disagreement is specific to how languages implemented those 
terms mentioned. Does anyone know of any non-language related disagreements?

Thanks, Jon.

> Seymour Metz wrote:

> 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 have 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.

> From:  Jon Perryman - orignal post

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 

Re: Solution OOP in HLASM

[Jon Perryman]

Ze'ev and Richard, These are certainly good examples of using OOP in HLASM but 
they are a little difficult to explain how they relate to the tenets of OOP. 

Remember that it's the language that supports OOP in a way it chooses to 
support it. E.g. methods in C++ are usually functions.

As a programmer using OOP, you are not required to use all OOP tenets in your 
program. Runtime is polymorphism but we have objects that do not morph (e.g. 
strings). I think the only requirements are object, methods and encapsulation.

Your help is greatly appreciated.


Thanks, Jon.

> Ze'ev wrote: 


Jon, You could create objects in HLASM, as the other gentleman demonstrated 
with a real life example of a session manager.  If we define objects as some 
entity that could be probed in runtime, then by all means you could do that in 
HLASM.  

Re: Solution OOP in HLASM

[Tobias Leicher]

Hello Jon,

you are right that one could code in Assembler consistent to the 
OO-programming style. But the big difference is, that in OO Languages the 
compiler is able to check all the things and understands what an object 
is. This is not the case in HLASM. So in the end Assembler is what is 
closest to the machine and by definition (as Java e.g. is translated to 
machine code as well) it can be used as OO, but so can everything be 
expressed in letters and you can look like the english language, but 
english consists of rules that are enforced (in this case by the compiler) 
and so HLASM is not an OO Language, even if you can do everything an OO 
Language can do with it. 

Just imagine, the compiler will know at compile time, if it is possible 
that the object you hand over to a method is not correctly typed, in HLASM 
you would notice that at runtime. In Java e.g. it is not even possible to 
get around that restriction. If you generally look at the development of 
languages, it is so that one tries to get more and more runtime issues 
into a compiler issue.

So you are maybe right with the requirements that you can fulfill, but 
these are not checked, neither enforced and as such not relevant to the 
definition. 

Cheers,
Tobias

Mit freundlichen Grüßen / Kind regards

Tobias Leicher

Senior IT Specialist for CICS and zAPI
zChampion for Modernization
IBM Software Group Technical Sales

IBM Mainframe Assembler List  wrote on 
16/02/2018 06:18:57:

> From: Jon Perryman 
> To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
> Date: 16/02/2018 06:21
> Subject: Re: Solution OOP in HLASM
> Sent by: IBM Mainframe Assembler List 
> 
> Ze'ev and Richard, These are certainly good examples of using OOP in
> HLASM but they are a little difficult to explain how they relate to 
> the tenets of OOP. 
> 
> Remember that it's the language that supports OOP in a way it 
> chooses to support it. E.g. methods in C++ are usually functions.
> 
> As a programmer using OOP, you are not required to use all OOP 
> tenets in your program. Runtime is polymorphism but we have objects 
> that do not morph (e.g. strings). I think the only requirements are 
> object, methods and encapsulation.
> 
> Your help is greatly appreciated.
> 
> 
> Thanks, Jon.
> 
> > Ze'ev wrote: 
> 
> 
> Jon, You could create objects in HLASM, as the other gentleman 
> demonstrated with a real life example of a session manager.  If we 
> define objects as some entity that could be probed in runtime, then 
> by all means you could do that in HLASM. 
> 

Re: Solution OOP in HLASM

[Tobias Leicher]

Hello Jon,

I do not, let me try once more I did not say, that you can't develop in 
HLASM in a OOP style, but the difference is, that you enforce these rules 
in OOP Languages. You mix C and C++ randomly. If you btw read my footer 
right you would realize I am not at all a C programmer. The only thing I 
am not, is being religious about things, if you use terms like "brain 
washing" I assume you have more emotions about different types of 
Languages then I have. HLSAM is a good tool and I really like it, but as 
it is a good tool for some stuff, it is not helpful for business stuff, 
there are high level and more "abstract" languages, like OOP languages in 
advantage. 

> When I say Type it is about classes, that is a lot different then 
halfwords. Classes are a assembly of data and function and the compiler 
makes sure you can't directly access hidden data in a class. This is a 
thing you can't enforce in HLASM, data can't be hidden, as there is no 
Compiler to stop you from using it anyway, it is all about style of 
programming.

You say: Compilers don't enforce OOP enough. That might be true, but 
saying something is not good enough is not a reason to say we need no 
checks at all. So it is by far more easy to make mistakes in HLASM then in 
C++. And as said, you can program in HLASM in a OOP fashion, but it is 
just your style, not the language that makes you do OOP...

You seem to always focus on C++, this is a OOP language, but not the 
general definition. Java is a OOP language as well and it is far stricter 
on the OOP rules then C++.

Actually you already found your peace when you say:  "HLASM OOP is not a 
strict OOP language. You can obey all OOP tenets or choose which tenets 
you obey." this is the only thing I say all the time, you can do a OOP 
style in your code, but it doesn't matter if you break it. If you try this 
at a high level OOP language, this will not work out as the compiler stops 
you in most of the cases. Is there a chance to work in an OOP language 
only functional: sure, but you never completely prevent misuse. HLASM just 
immitates the OOP paradigms, not really has the compiler functionality to 
support OOP paradigms

If you search for a OOP definition it is mostly said that Alan Kay was not 
to bad, even it is very general:
“1. Everything is an object, 2. Objects communicate by sending and 
receiving messages (in terms of objects), 3. Objects have their own memory 
(in terms of objects), 4. Every object is an instance of a class (which 
must be an object), 5. The class holds the shared behavior for its 
instances (in the form of objects in a program list), 6. To eval a program 
list, control is passed to the first object and the remainder is treated 
as its message”

It is not about definition, it is about functionality and the controls of 
the compiler. If it makes you happy, call HLASM OOP, but OOP languages 
rely heavily on a compiler that checks the rules. 

Cheers,
Tobias

Mit freundlichen Grüßen / Kind regards

Tobias Leicher

Senior IT Specialist for CICS and zAPI
zChampion for Modernization
IBM Software Group Technical Sales

Jon Perryman  wrote on 16/02/2018 20:37:47:

> From: Jon Perryman 
> To: Tobias Leicher 
> Date: 16/02/2018 20:38
> Subject: Re: Solution OOP in HLASM
> 
> Thanks Tobias. You bring up perception rather than reality. There 
> are several OOP languages and they all implement OOP so that it best
> fits into that language. Here are the points you bring up:
> 
> 1. "a method is not correctly typed, in HLASM you would notice that 
> at runtime." 
> 
> For HLASM programmers "types" are halfword, fullword, packed, 
> floating point, ...
> 
> This statement shows how skilled C programmers are good at brain 
> washing. There are many variations on this statement and they are 
> all full of holes.
> 
> 1A. Type validation is extremely important to C programmers for a 
> good reason. C is a heavy function call language where it's easy to 
> get arguments wrong E.g. xxx(arg1, arg3) missing an argument or 
> xxx(arg3, arg2, arg1) arguments out of sequence. When you have 
> hundreds of function calls in a program, then any type of checking 
> is greatly appreciated even if it's minimal. HLASM does not have 
> this problem because macros have keywords that clearly identify 
> where the argument belongs. 
> 
> 1B. Types is not an OOP requirement. Types only apply to specific 
> languages. I would hope that OOREXX is like REXX where it does not 
> have types. 
> 
> 1C. Every C & C++ program has a special file "header" that contains 
> the functions with argument types. This file is included in all 
> programs to very everything matches (types). In HLASM, functions 
> that are used in several programs (and well behaved) will have a 
&

Solution OOP in HLASM - try#3

[Richard Kuebbing]

I'm a newbie - I didn't start in IT until 1961 and not using computers until 
1964, but I have worked on an application (a session manager) which was OOP.

1) it was multi-tasking and worked by passing messages between tasks.  When an 
RU was received from VTAM, a copy was made and the address of the copy was sent 
via queues to the task to process it.  Very OO.  All time dependant code was 
implemented using a timing task and message(s).  Send a message telling the 
time manager when you want something done and send one or more messages to be 
sent at that time.

2) all files were objects.  Tasks could not read files.  They had to request a 
record.  Each field of each record and each field of any interesting opsys 
field had a method.  If you want a value, call a method.  I wrote the methods - 
about 1k of them.  During a following upgrade, I added about another 1k of them.

3) all screen were defines as ISPF like specifications, with imbedded method 
names.

4) there were stacks one for each user pluse one for each user for each 
internal app opened.  The zero level had the global methods and any global 
data.  When you read a record, you push the record onto the stack with a simple 
small id.  If you are doing an update, you might want to push a second copy 
onto the stack.  If the record was e.g. a user record, you would push the 
matching profile record onto the stack. etc.

5) screen display consisted of passing the current local stack pointer for the 
current thread to the display object.  When control was returned, R15= 0(enter) 
4(pf3) 8(return) 12(cancel) 16(the world is about to end).  If rc=4, you sent 
the appropriate record to the file object for update.  If rc=0 you redisplay.  
If rc=12, free updated record.

6) each internal app had its own stack built on the global stack.  Each user of 
each internal app had its own stack built on the app stack.

7) as for code reuseability and inheritance, I took the code and made slight 
modification and made it decide at startup whether it was a VTAM pgm or a batch 
pgm.  It then executed according to what startup built.

It had a c/s feature where it could have a "conversation" with an "intelligent 
terminal emulator".  At the time CA bought us, there was a proposal on the 
table to use the connection from real terminal and our code to do things today 
being done w/XML and other markup languages.

-Original Message-
From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On 
Behalf Of Seymour J Metz
Sent: Thursday, February 15, 2018 1:43 PM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: Solution OOP in HLASM

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



- The information contained in this 
communication (including any attachments hereto) is confidential and is 
intended solely for the personal and confidential use of the individual or 
entity to whom it is addressed. The information may also constitute a legally 
privileged confidential communication. If the reader of this message is not the 
intended recipient or an agent responsible for delivering it to the intended 
recipient, you are hereby notified that you have received this communication in 
error and that any review, dissemination, copying, or unauthorized use of this 
information, or the taking of any action in reliance on the contents of this 
information is strictly prohibited. If you have received this communication in 
error, please notify us immediately by e-mail, and delete the original message. 
Thank you