> 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. Jim Mulder z/OS Diagnosis, Design, Development, Test IBM Corp. Poughkeepsie NY ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
