Walt:
Thank you for the explanation. Regards, Scott From: Walt Farrell Sent: Tuesday, April 29, 2014 1:42 PM To: IBM Mainframe Discussion List On Tue, 29 Apr 2014 15:13:49 +0000, Scott Ford <[email protected]> wrote: >Its surprising that IBM hasn't thought about using C in exits , like RACF or >other components. > >Considering Linux has been writing their Kernel in it for a few years. Not >bashing IBM, curious why they haven't embraced C in the >systems arena. I see >it in some of the system type tools. I can only speak as an ex-IBMer, of course, but one issue I see for exits comes from the need to account for different environments, with their different execution characteristics and restrictions. So, basically, it's an issue of complexity. I know of RACF exits, for example, that might be invoked in various combinations of locked/unlocked, various system keys, cross-memory mode or not, TCB or SRB mode, and AMODE. Think of an exit as having two aspects. First, there's the basic core code of the exit that implements the function you need. Next, there's an infrastructure around that code that is required for the core code to run. With something like LE C, the "core" code could involve use of run-time library routines, which may make use of system services. Will those system services work in all the environments that the exit might run in? Maybe, or maybe not. Does the run-time documentation even tell you what the services are, so you can do some research and figure it out? Or do they document whether they work in SRB mode, or cross-memory mode? (Answer: probably not.) If they don't work, will they fail all the time? (Answer: if you're lucky, yes; but probably they'll fail only under some set of less common circumstances that you'll never see in testing, or only several years from now after you make some seeminly innocuous change to your code.) Even if you can write your C code in such a way that the run-time routines are "safe" for all the exit environments, you still need to do the setup of the C infrastructure (the LE environment, for example). Will the LE initialization run properly in all those exit environments? If either of those run-time aspects (library routines, infrastructure setup) fails in some environment, what part of your system is going to fail along with it? If you discover, eventually, that it won't work in some specific set of circumstances, how much redesign, recode, and retest will be necessary to fix it? And then there's the efficiency question, especially for infrastructure setup and tear-down, especially if it needs to happen multiple times. Or the possibility that something the infrastructure does might conflict with other aspects of the system function that invokes the exit, especially if you setup the infrastructure once and leave it around when returning from the exit back to the system function that invoked it. Or, conversely, if you leave the infrastructure setup, that something the system does after you return from the exit will interfere with (undo) something the infrastructure depends on, and will only do during setup. Or that the infrastructure you save for later use might not work in the environment the exit is next called in (different storage key, for example). Basically, if you try to throw a large, complex, piece of code that you don't control and for which you don't have full information, into the middle of another large, complex piece of code then you're likely to have some unpredictable results. -- Walt ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
