Hi Jim, You said: "... It is unfortunate that IBM does not make PL/X (which has object-oriented capabilities) available to ISVs. ..."
It is also unfortunate that PL/X was not made available to customers, just like there is no free z/OS (and z/VM, z/VSE) Download for students and other non-commercial users. It seems to be counter-intuitive that in a market where mainframe assembler programming and SMP/E skills are becoming extinct, that IBM would not be wanting to be more flexible to attract the younger crowd (a la LInux). This is especially astounding, given that z/OS is such a large IBM investment (in both hardware and software). Regards, David On 2019-01-27 23:47, Jim Mulder wrote: >> 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 > . > ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
