Yes I’m trying to trace every instruction on a 14 CSECT load module with a great number of self modified code instructions a breakpoint on an instruction that’s self modified blows up debug tool or test
Test gives you the option of calling a program at a breakpoint using Call subcommand In that program I issue an Estae I can get the original first 2 bytes that was overlaid by test from the sysadata Since I will be using the sysadata more extensively I would ( for efficiency purpose move it to a data space ) From: Peter Relson <[email protected]> Sent: Thursday, April 11, 2019 3:14 PM To: Joseph Reichman <[email protected]> Subject: Re: Address of CSECTs within a load module Joseph, Again I ask: what is the requirement? And what are the answers to my questions? Is the requirement to produce output showing the execution of every instruction on some specific invocation of this specific module? I choose not to get into further discussion without the answers. TSO TEST is SVC 61 (decimal), thus 0A3D not 0A61 If you happen to be right that the modification is via an OI of x'F0' you would land with x'0AFD', not x'0AF1'.. What this would do is unknowable without examining the system to see whether SVC 253 is defined. And if it is defined, then you are potentially doing serious harm to the system. <snip> So I look at program name if it’s not there then that field is the address of the RB in this case since it’s SVC chain the SVRB chain back the PRB I am able to get the RBOPSW and regs to do a retry write the proper info to systsprt via PUTX however to do the retry I have to get the original object most of the time it’s a nop some times it’s a CLC To get the original opcode I have to read the sysadata But as I said the load module is composed of 14 CSECT I do a CSVQUERY before the the Estae to get the entry and length </snip> What is it that you are looking at when you write "I look at program name"? Which "field" are you talking about that is the address of the RB? Any of the techniques mentioned in the posts can be used to provide/gather the CSECT mapping before you do any of this. I think what you're saying is that you need that mapping in order to know within which CSECT the blow-up occurred so that you can locate the original opcode of the instruction. But couldn't you just load and save the entire load module before you set the TSO TEST break points? If you're going to read the SYSADATA, you can copy it wherever you want, whether that be an address space, storage above 2G, or leaving it where it is, if there is enough room. Perhaps your site has available z/OS running under z/VM. Tracing a storage range with z/OS running under z/VM is trivial. Did you consider using a SLIP IF trap for this module, with ACTION=TRACE to record the path via GTF? Peter From: Joseph Reichman <[email protected] <mailto:[email protected]> > To: Peter Relson <[email protected] <mailto:[email protected]> > Date: 04/10/2019 04:12 PM Subject: Re: Address of CSECTs within a load module _____ At the IRS we have very old huge Assembler programs we are trying to trace as they are trying to re-write them in Java One of the programs is a 14 CSECT load module it is filled with nops and other self modified instructions So typically the code is BYPASS NOP AROUND I have Rexx exec the generates st every sysadata type x’36’ ( machine instruction) The following AT +disp. So AT +1036 (where;go) this writes out to systsprt when executed doing a trace I have coded a call subcommand on the very first AT in the program I issue an ESTAE At the nop the code would when the breakpoint is generated 0A61 6044 ( just an example ) when the code does OI BYPASS+1,X’F0’ this results rather then a call to test SVC 240 resulting in abend The PSW in SDWA is that of SVC 240 So I look at program name if it’s not there then that field is the address of the RB in this case since it’s SVC chain the SVRB chain back the PRB I am able to get the RBOPSW and regs to do a retry write the proper info to systsprt via PUTX however to do the retry I have to get the original object most of the time it’s a nop some times it’s a CLC To get the original opcode I have to read the sysadata But as I said the load module is composed of 14 CSECT I do a CSVQUERY before the the Estae to get the entry and length Also since I may have to dump variable via sysadata I had thought of moving the sysadata to a dataspace to make for an easier lookup access of the sysadata Was interested in your thoughts Thanks On Apr 10, 2019, at 3:03 PM, Peter Relson < <mailto:[email protected]> [email protected]> wrote: Joe, I'm still trying to understand better. I thought perhaps I would see you today. I understand that you have a load module with 14 CSECTs and apparently you have ADATA for each of those 14 CSECTs. Can you start over, describing the problem that you are trying to solve (not jumping down towards the problems you were having with the solution you envisioned)? At the minimum, it is important to describe what you are or are not allowed to do. For example, are you allowed to change any of the CSECTs? Are you allowed to change the load module itself (such as to add a 15th CSECT)? Are you allowed to re-bind to add an alias? The readers of your post have no idea of extent to which this module is not under your control. Peter <mailto:[email protected]> [email protected] ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
