I worked on a project in Assembler H that was influenced by OO ideas and used "late bound calls" (function tables).
-- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 ________________________________________ From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of David Crayford [dcrayf...@gmail.com] Sent: Tuesday, September 20, 2022 3:09 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Assembler courses On 19/09/2022 7:59 am, Charles Mills wrote: >> I've never had occasion to try write OO programs on the mainframe. >> to me it seems that the chief value of classes and class methods is a >> way of organizing my subroutines and functions and limiting their >> scope to particular uses which seems to me would be useful in some >> mainframe programs >> I gather some OO languages are available to OMVS users here > Let me jump in here with a very personal note and say I *have* written a very > successful* mainframe program in a totally OO paradigm. So yes, OO is totally > relevant to mainframe software. And kudos to you because not everybody could make the jump from HLASM to C++. I have been coding in C++ and Java for so long OOP is second nature to me now. Well, in C++ I prefer the interfaces using templates. Java has morphed into into a hybrid OO/FP language since the introduction of the Streams API in Java 8. It's common now not to code imperative loop statements at all. One can use object based programming in any language that supports function pointers. I have seen a lot of HLASM code that would benefit from such a design. One of the key principles of OO was to replace conditional logic with polymorphic types. An example in C is the z/OS stdio library. fopen() is a factory function that returns an opaque handle with read/write/close functions pointers set that can handle many different access methods using the same abstract functions. This is a clean design that unfortunately isn't as common as it should be. > > To me, yes, it is a method of organization of data and subroutines. It is a > totally different way of thinking about things. Let me see if I can express > this. You have a program. You want to add some functionality to it. Rather > than thinking separately "I will need some new data fields" and "I will need > some new subroutines" instead you think "I will need a 'package' of new data > fields and subroutines that operate on those fields." It is a way of > organizing the effort that I found to work extremely well for me. I cannot > picture writing a large program any other way: not as a hodgepodge of fields > and subroutines, but rather as a collection of smallish 'packages' of data > and their attendant subroutines. > > Utterly industry-standard C++ is available for developing both "legacy" and > UNIX programs on z/OS. The program I refer to above is run with JCL as an > STC; nothing external about it screams "C" or "OO" or "OMVS." > > *Licensed by quite a few "name" companies and then acquired by a big-name > software company for fairly big bucks. > > Charles > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
