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. > It never occurred to me that one might do "two FREEMAINS in one" but of > course it makes sense as a corollary. It would be unwise to do that, but it would happen to work in the current implementation. There is no commitment that it would continue to work in the future. It does not work for common storage when common storage tracking is enabled. > -----Original Message----- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of Jim Mulder > Sent: Sunday, January 27, 2019 8:47 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: IARV64 - why ABEND rather than return with reason code? > > > For the past ten years I have been developing z/OS "system" software > > primarily in C++. I have become a big believer. I like the > > productivity -- I think I can write more end-user functionality in a > > day than an assembler programmer. I like the avoidance of low-level > > errors -- "oh crap, I forgot that routine needed R2." I like the > > incredibly optimized object code produced by the compiler. I like > > the design that emerges from object-oriented thinking. > > > > One of the side effects of developing in C++ is an end to reliance > > on dumps as a primary debugging tool. One, the machine code produced > > by the C++ compiler is often inscrutable. > > 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". > We have spend a lot of effort with the PL/S-PL/AS-PL/X > family of compilers to make the assembler (not machine) code > code produced by the compiler as understandable as possible, > because we know that we are going to have to debug a lot > of low-level operating system problems from dumps. > Also, since the compiler generates an assembler source > file which is subsequently assembled, the facilities > for including inline assembler code are far better than > in C. Also, interoperability with assembler code was one > of the primary design objectives from the beginning, so of > course it is going to far better than in other languages > where that was not the case. > > It is unfortunate that IBM does not make PL/X (which > has object-oriented capabilities) available > to ISVs. I have often wondered why the large ISVs did > not have their executives constantly hammering IBM > executives over this issue. Of course, in the older > days when IBM viewed ISVs as evil competitors and PL/xxx > as a competitive advantage, this would have been a > nonstarter. In later years when IBM started to see ISVs > as an important part of the mainframe ecosystem, things > might have been different (and almost were - we came > pretty close to making PL/X available one time years > ago, before some IBM executive squelched it). > > > To your point about EXECUTABLE=YES, I have always thought that > > FREEMAIN required too many details. If MVS is to free the storage, > > what difference does it make if it is executable or not? The address > > is unique -- why must the subpool be specified? > > You can blame me for that EXECUTABLE requirement on > FREEMAIN. Internally, we implement EXECUTABLE=YES/NO > like two separate subpools (for each subpool, there > are separate SPQEs for EXECUTABLE=YES and > EXECUTABLE=NO). In the interest of minimizing the > implementation costs for a project that was being done > on a tight schedule, I recommended the requiring a correct > EXECUTABLE specification when freeing storage. It > would still be possible enhance this in the future > by treating the EXECUTABLE specification as a performance > hint which says which SPQE's DQE chains to search first, > and then do the other SPQE next if not found in the first. > As always, if you feel strongly about that, > submitting an RFE may help your chances. > > > If I were designing > > FREEMAIN from scratch, I would drop the LENGTH and just always free > > the entire block. Yes, you would lose the ability to free half of a > > buffer -- but gain some simplicity of design, and eliminate the > > nasty bug where you free all but 8 bytes of some repeatedly-obtained > > area, and never notice it until some customer runs out of (contiguous) > memory. > > 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. Two > separate GETMAINs which end up being adjacent are > indistinguishable from one GETMAIN for the sum of the > sizes. ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
