This message is primarily intended for those of you out there that know
me professionally, but all are welcome, obviously, to read further.I’m
currently looking for work and would ask any of you so inclined to contact me
off-list for a copy of my resume that you might
On 2019-04-23, at 06:08:17, Jonathan Scott wrote:
> Ref: Your note of Mon, 22 Apr 2019 11:06:34 -0400
>
> One way of detecting and preventing the use of self-modifying
> code is to use RSECT instead of CSECT for any section which is
> intended to be read-only, in which case HLASM will flag a
>
Well, those will catch some refreshabilty violations, but there are other
types of reenterability violations than unserialized self modifying code, and
the assembler can't catch those.
--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3
From: IBM
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 HUGE and OLD Assembler
>
>
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
Ref: Your note of Mon, 22 Apr 2019 11:06:34 -0400
One way of detecting and preventing the use of self-modifying
code is to use RSECT instead of CSECT for any section which is
intended to be read-only, in which case HLASM will flag a
reentrancy violation if it detects an attempt to store into
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
