You can add a routine that compares the executable portions of your csects against a pre-execution copy and call it periodically. This could be done from within your task or from another if you're not allowed to modify the program in question.
Also, if IBM makes available some diagnostics about instruction cache flushes, like cause and location, this might be another option. HTH, Mike ________________________________ From: IBM Mainframe Assembler List <[email protected]> on behalf of Tony Harminc <[email protected]> Sent: Wednesday, May 15, 2019 3:39 PM To: [email protected] Subject: Re: Sysadata symbol and literal cross reference record type x’44’ re-post from IBMMAIN On Tue, 23 Apr 2019 at 10:36, Martin Ward <[email protected]> wrote: > (Note that the thoretical problem of determining whether a particular > program is self-modifying or not is, like the Halting Problem, > non-computable. But in practice, all examples of self-modifying code > we have encountered can be detected and translated.) > Very interesting. The Halting Problem and its nifty proof of non-computability is something everyone learns in the first CompSci course, but I have never given computability of self-modification any thought. Is there a similar nifty proof for this one? Surely the problem is fundamentally architecture and/or language specific. Many languages and indeed some architectures simply do not allow self modification. I suppose at a high level one could consider generating code during execution to be self modification (of the program as a whole), and then it begins to sound familiar... Tony H.
