On Jul 14, 2010, at 4:02 PM, Gary Weinhold wrote: > Paul Raulerson wrote: >> I pretty much agree, except there is not any "extreme" overhead in doing so. >> And there is not any issue with catching instructions >> executed out of the data section via an EX instruction. >> > I agree that this can be easily trapped if you're trapping every > instruction, all EX instructions, or all instruction executed from > within (or outside of) a specified virtual storage range). >> >> As a counter example, our production systems run with embedded debugger >> code, which does *not* affect execution speed at all. >> > I understand that you can run with embedded debugger code without > affecting execution speed (on MVS ESTAEX can do that, a z/XDC trap can > also do that). It would be able to produce diagnostic information if an > error was detected. But are you saying (within the context of this > discussion) that this embedded debugger code could be set up to trap, > for example, every MVC instruction or every EPSW instuction with no loss > of execution speed for all other instructions? > No, I think you will always take a measure of performance hit doing those kinds of traps. Just that the magnitude of the hit is not really all that bad. I suppose it depends upon the processor though.
> Gary Weinhold > Data Kinetics, Ltd. >
