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