Ah! That clarifies your "debug it yourself." I was wondering what language I could write in where I would NOT have to debug it myself.
I'm not *asking* for a "simple FREEMAIN"; just pointing out what my blue sky preference OS-design would be. It would be easy enough for a developer to front-end GETMAIN and then for FREEMAIN to provide "everything else" based on the origin address. Also, note that while C++ appears very similar to C and is 99.9% a proper superset of C, it is a very different language conceptually, at least if used properly. I am not advocating for C (which IMHO offers few design advantages over the structured HLASM macros) but specifically for C++. I'm not planning to do any Siamese twin FREEMAINs in the near future. Charles -----Original Message----- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Jim Mulder Sent: Monday, January 28, 2019 11:33 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: IARV64 - why ABEND rather than return with reason code? Jim Mulder z/OS Diagnosis, Design, Development, Test IBM Corp. Poughkeepsie NY > > That's why I have been heard to say in IBM, "If you wrote it in C, you > must have wanted to debug the problems yourself". > > I guess it depends on your point of view. I would say that if you wrote it > in HLASM you must have wanted to be able to debug it yourself. I guess I should more accurately say "If you want me to debug your problem from a dump (which is one of my jobs at IBM), use a compiler which facilitates that. The current IBM C compiler does not fall into that category." I view that as an issue with the IBM C compiler, not the C language. I don't know nearly enough about the C or C++ languages to be qualified to cast aspersions onto them, or compare their usability or functionality to PL/X, except in the areas of debugging from dumps, inclusion of inline assembler code, and interoperability with z/OS services and assembler programs. > > It is unfortunate that IBM does not make PL/X (which > > has object-oriented capabilities) available > > to ISVs. > > I seem to recall that IBM offered an unsupported version of PL/S to ISVs in > whatever the predecessor to PartnerWorld was back in the 90's. We passed -- > did not want to commit to an unsupported, non-mainstream language. And that was a wise choice. Without an IBM commitment to provide support, and pride future releases, it was a lousy offering. > > For private storage (and also for common storage when > > common storage tracking is not turned on), VSM does not > > keep track of the size of the original request. > > I pretty much intuited that. Obviously what I am fantasizing about would be > a different approach. And yes, as @Gil points out, that different approach > is how most HLL's do it, I think. You simply delete the block of storage at > x'xxxxx' and the library knows how big it is. There is no provision to split > or combine blocks. I understood what you were asking for. I was just pointing out that it would not be possible in the current implementation, and that is unlikely to change in the future. ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
