R-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
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
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
@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 &
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
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
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 prac
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
Begin forwarded message:
> From: Joseph Reichman
> Date: April 23, 2019 at 10:48:07 AM EDT
> To: Martin Ward
> Subject: Re: Sysadata symbol and literal cross reference record type x’44’
> re-post from IBMMAIN
>
> I work for the IRS and the tax processing code is H
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
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
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
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
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
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
: 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,LABEL
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
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
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
19 matches
Mail list logo
