Re: Sysadata symbol and literal cross reference record type x’44’ re-post from IBMMAIN
<*Doh!*> Sorry, never mind. I see other entries in the thread in this forum. Apologies. Peter -Original Message- From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On Behalf Of Farley, Peter x23353 Sent: Thursday, May 16, 2019 10:23 AM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Sysadata symbol and literal cross reference record type x’44’ re-post from IBMMAIN PMFJI here, but can you tell us where the rest of this conversation may be located? I found only one message on IBM-MAIN with this subject, from April 22, author Joe Reichmann. I would be interested to read the whole thread if I could find it. Peter -Original Message- From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On Behalf Of Mike Hochee Sent: Thursday, May 16, 2019 9:56 AM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Sysadata symbol and literal cross reference record type x’44’ re-post from IBMMAIN Hi Martin, No, I cannot elaborate as I have no additional information, just a presumption. Thank you for the E163 reference. Mike From: IBM Mainframe Assembler List on behalf of Martin Truebner Sent: Thursday, May 16, 2019 2:22 AM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Sysadata symbol and literal cross reference record type x’44’ re-post from IBMMAIN Mike, >> Also, if IBM makes available some diagnostics about instruction cache >> flushes, like cause and location, this might be another option. Can you elaborate on that "if"? Are you saying that there are ways to get more from the hardware than just the counter E163 (*). I do agree that that counter (even in relation to counter B2) does not say much- but typical numbers for your load (i.e. heavy night load when certain programs run) vs. daily online load or numbers from other installations before and after attempts to eliminate the cause of E163. Martin (*) definition of that counter from the book: Counter 163 – A directory write to the Level-1 Instruction cache directory where the returned cache line was sourced from an On-Chip Level-3 cache with intervention. -- This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail and delete the message and any attachments from your system.
Re: Sysadata symbol and literal cross reference record type x’44’ re-post from IBMMAIN
Unless you can ensure all executions will also be under those conditions, you will also need to exercise all possible code paths in the program with every possible variation of input(s). On 2019-05-15 5:57 p.m., Paul Gilmartin wrote: More practical, mark your module REFR and run with REFRPROT in effect. -- gil Gary Weinhold Senior Application Architect DATAKINETICS | Data Performance & Optimization Phone +1.613.523.5500 x216 Email: weinh...@dkl.com Visit us online at www.DKL.com E-mail Notification: The information contained in this email and any attachments is confidential and may be subject to copyright or other intellectual property protection. If you are not the intended recipient, you are not authorized to use or disclose this information, and we request that you notify us by reply mail or telephone and delete the original message from your mail system.
Re: Sysadata symbol and literal cross reference record type x’44’ re-post from IBMMAIN
PMFJI here, but can you tell us where the rest of this conversation may be located? I found only one message on IBM-MAIN with this subject, from April 22, author Joe Reichmann. I would be interested to read the whole thread if I could find it. Peter -Original Message- From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On Behalf Of Mike Hochee Sent: Thursday, May 16, 2019 9:56 AM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Sysadata symbol and literal cross reference record type x’44’ re-post from IBMMAIN Hi Martin, No, I cannot elaborate as I have no additional information, just a presumption. Thank you for the E163 reference. Mike From: IBM Mainframe Assembler List on behalf of Martin Truebner Sent: Thursday, May 16, 2019 2:22 AM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Sysadata symbol and literal cross reference record type x’44’ re-post from IBMMAIN Mike, >> Also, if IBM makes available some diagnostics about instruction cache >> flushes, like cause and location, this might be another option. Can you elaborate on that "if"? Are you saying that there are ways to get more from the hardware than just the counter E163 (*). I do agree that that counter (even in relation to counter B2) does not say much- but typical numbers for your load (i.e. heavy night load when certain programs run) vs. daily online load or numbers from other installations before and after attempts to eliminate the cause of E163. Martin (*) definition of that counter from the book: Counter 163 – A directory write to the Level-1 Instruction cache directory where the returned cache line was sourced from an On-Chip Level-3 cache with intervention. -- This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail and delete the message and any attachments from your system.
Re: Sysadata symbol and literal cross reference record type x’44’ re-post from IBMMAIN
Hi Martin, No, I cannot elaborate as I have no additional information, just a presumption. Thank you for the E163 reference. Mike From: IBM Mainframe Assembler List on behalf of Martin Truebner Sent: Thursday, May 16, 2019 2:22 AM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Sysadata symbol and literal cross reference record type x’44’ re-post from IBMMAIN Mike, >> Also, if IBM makes available some diagnostics about instruction >> cache flushes, like cause and location, this might be another option. Can you elaborate on that "if"? Are you saying that there are ways to get more from the hardware than just the counter E163 (*). I do agree that that counter (even in relation to counter B2) does not say much- but typical numbers for your load (i.e. heavy night load when certain programs run) vs. daily online load or numbers from other installations before and after attempts to eliminate the cause of E163. Martin (*) definition of that counter from the book: Counter 163 – A directory write to the Level-1 Instruction cache directory where the returned cache line was sourced from an On-Chip Level-3 cache with intervention. -- Martin Trübner; everything around "PoOps of z/arch" Teichstraße 39E D-63225 Langen F: +49 6103 71254 M: +49 171 850 7132 E: mar...@pi-sysprog.de
Re: Sysadata symbol and literal cross reference record type x’44’ re-post from IBMMAIN
Mike, >> Also, if IBM makes available some diagnostics about instruction >> cache flushes, like cause and location, this might be another option. Can you elaborate on that "if"? Are you saying that there are ways to get more from the hardware than just the counter E163 (*). I do agree that that counter (even in relation to counter B2) does not say much- but typical numbers for your load (i.e. heavy night load when certain programs run) vs. daily online load or numbers from other installations before and after attempts to eliminate the cause of E163. Martin (*) definition of that counter from the book: Counter 163 – A directory write to the Level-1 Instruction cache directory where the returned cache line was sourced from an On-Chip Level-3 cache with intervention. -- Martin Trübner; everything around "PoOps of z/arch" Teichstraße 39E D-63225 Langen F: +49 6103 71254 M: +49 171 850 7132 E: mar...@pi-sysprog.de
Re: Sysadata symbol and literal cross reference record type x’44’ re-post from IBMMAIN
On 2019-05-15, at 13:39:11, Tony Harminc wrote: > > 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? ... > Make your program a subroutine of a main program that stores into itself if that subroutine halts. This makes self-modification equivalent to the halting problem. More practical, mark your module REFR and run with REFRPROT in effect. -- gil
Re: Sysadata symbol and literal cross reference record type x’44’ re-post from IBMMAIN
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 on behalf of Tony Harminc Sent: Wednesday, May 15, 2019 3:39 PM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU 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 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.
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 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.
Re: Sysadata symbol and literal cross reference record type x’44’ re-post from IBMMAIN
On 22/04/19 22:38, Joseph Reichman wrote: To be more clear this goes back to the original problem of tracing a 14 cesct huge piece of code I am wondering if I can identify what instructions are modified Software Migrations Ltd. (the company I work for) offers a migration service to convert assembler code into functionally equivalent, structured, efficient and maintainable C or COBOL code. The process is totally automated but custimisable for each project. Therefore we have to be able to detect and translate any self-modifying code in the listing, wherever possible. We have seen some quite dramatic improvements in performance when migrating assembler code which does a lot of instruction modification! (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.) Let me know if you would like to pursue this option. -- Martin Dr Martin Ward | Email: mar...@gkc.org.uk | http://www.gkc.org.uk G.K.Chesterton site: http://www.gkc.org.uk/gkc | Erdos number: 4
Re: Sysadata symbol and literal cross reference record type x’44’ re-post from IBMMAIN
Joseph, if you want a 99 percent method- try removing the base for the code (only have base registers for the data areas) --- and have IEABRC in the very beginning. That way you will catch most modifications to code, but not the indirect refs as shown by Keven. PS: you do not need to make the code really run able, just doing as above to identify most of the cases where the hardware counter E163 would increase. -- Martin Trübner; everything around "PoOps of z/arch" Teichstraße 39E D-63225 Langen F: +49 6103 71254 M: +49 171 850 7132 E: mar...@pi-sysprog.de
Re: Sysadata symbol and literal cross reference record type x’44’ re-post from IBMMAIN
Sysadata type 44 will catch most > On Apr 22, 2019, at 5:54 PM, Paul Gilmartin > <0014e0e4a59b-dmarc-requ...@listserv.uga.edu> wrote: > >> On 2019-04-22, at 15:38:03, Joseph Reichman wrote: >> >> To be more clear this goes back to the original problem of tracing a 14 >> cesct huge piece of code I am wondering if I can identify what instructions >> are modified >> > There's the empirical approach: Save a copy as REFR; run it; see what breaks. > (Not 100% effective.) > (Can you turn REFRPROT on?) > > -- gil
Re: Sysadata symbol and literal cross reference record type x’44’ re-post from IBMMAIN
On 2019-04-22, at 15:38:03, Joseph Reichman wrote: > To be more clear this goes back to the original problem of tracing a 14 cesct > huge piece of code I am wondering if I can identify what instructions are > modified > There's the empirical approach: Save a copy as REFR; run it; see what breaks. (Not 100% effective.) (Can you turn REFRPROT on?) -- gil
Re: Sysadata symbol and literal cross reference record type x’44’ re-post from IBMMAIN
Yes > On Apr 22, 2019, at 5:25 PM, Robert Netzlof wrote: > >> On 4/22/19, Keven wrote: >> >> There’s almost no >> reason to use self-modifying code that makes sense anymore... > > My impression was that the original poster was hoping to use the > assembler's facilities to root out instances of self-modifying code in > existing programs. > > -- > Bob Netzlof a/k/a Sweet Old Bob
Re: Sysadata symbol and literal cross reference record type x’44’ re-post from IBMMAIN
To be more clear this goes back to the original problem of tracing a 14 cesct huge piece of code I am wondering if I can identify what instructions are modified Thanks -Original Message- From: IBM Mainframe Assembler List On Behalf Of Keven Sent: Monday, April 22, 2019 5:18 PM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Sysadata symbol and literal cross reference record type x’44’ re-post from IBMMAIN Using RSECT instead of CSECT would result in your example being flagged as non-reentrant (self modifying) but it wouldn’t catch any indirect modification such as:LAR5,LABELMVI 0(R5),0LABEL DS 0H B. THERE The example would also cause the instruction cache line to be flushed which isn’t great.There’s almost no reason to use self-modifying code that makes sense anymore... Keven On Mon, Apr 22, 2019 at 10:06 AM -0500, "Joseph Reichman" wrote: Had second thoughts and thought this forum to be more appropriate Thanks J Begin forwarded message: > From: Joseph Reichman > Date: April 22, 2019 at 9:25:10 AM EDT > To: ibm-m...@listserv.ua.edu > Subject: Sysadata symbol and literal cross reference record type x’44’ > > Hi > > For programs that have self modifying code Adata record type 44 can > prove to be a valuable tool in identifying them as the reference flag has a > ‘M’ > > However I wonder if there is a easy way to identify code that is being > modified by location counter I.E MVI *+5,X’00’ and the following instruction > is for example B AROUND > > > Thanks
Re: Sysadata symbol and literal cross reference record type x’44’ re-post from IBMMAIN
I am trying to determine what instructions are self modifying using sysadata wondering if there is any way to determine that -Original Message- From: IBM Mainframe Assembler List On Behalf Of Keven Sent: Monday, April 22, 2019 5:18 PM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Sysadata symbol and literal cross reference record type x’44’ re-post from IBMMAIN Using RSECT instead of CSECT would result in your example being flagged as non-reentrant (self modifying) but it wouldn’t catch any indirect modification such as:LAR5,LABELMVI 0(R5),0LABEL DS 0H B. THERE The example would also cause the instruction cache line to be flushed which isn’t great.There’s almost no reason to use self-modifying code that makes sense anymore... Keven On Mon, Apr 22, 2019 at 10:06 AM -0500, "Joseph Reichman" wrote: Had second thoughts and thought this forum to be more appropriate Thanks J Begin forwarded message: > From: Joseph Reichman > Date: April 22, 2019 at 9:25:10 AM EDT > To: ibm-m...@listserv.ua.edu > Subject: Sysadata symbol and literal cross reference record type x’44’ > > Hi > > For programs that have self modifying code Adata record type 44 can > prove to be a valuable tool in identifying them as the reference flag has a > ‘M’ > > However I wonder if there is a easy way to identify code that is being > modified by location counter I.E MVI *+5,X’00’ and the following instruction > is for example B AROUND > > > Thanks
Re: Sysadata symbol and literal cross reference record type x’44’ re-post from IBMMAIN
On 4/22/19, Keven wrote: > There’s almost no > reason to use self-modifying code that makes sense anymore... My impression was that the original poster was hoping to use the assembler's facilities to root out instances of self-modifying code in existing programs. -- Bob Netzlof a/k/a Sweet Old Bob
Re: Sysadata symbol and literal cross reference record type x’44’ re-post from IBMMAIN
Using RSECT instead of CSECT would result in your example being flagged as non-reentrant (self modifying) but it wouldn’t catch any indirect modification such as: LA R5,LABEL MVI 0(R5),0LABEL DS 0H B. THERE The example would also cause the instruction cache line to be flushed which isn’t great.There’s almost no reason to use self-modifying code that makes sense anymore... Keven On Mon, Apr 22, 2019 at 10:06 AM -0500, "Joseph Reichman" wrote: Had second thoughts and thought this forum to be more appropriate Thanks J Begin forwarded message: > From: Joseph Reichman > Date: April 22, 2019 at 9:25:10 AM EDT > To: ibm-m...@listserv.ua.edu > Subject: Sysadata symbol and literal cross reference record type x’44’ > > Hi > > For programs that have self modifying code > Adata record type 44 can prove to be a valuable tool in identifying them as > the reference flag has a ‘M’ > > However I wonder if there is a easy way to identify code that is being > modified by location counter I.E MVI *+5,X’00’ and the following instruction > is for example B AROUND > > > Thanks
