Yes you are right,debuggers use redirection techs.. 
We can't change the way we get the caller's name because it is part of security 
system.
 
Anyway, thank you all !

Alexandre Franke


 
> Date: Thu, 30 May 2013 09:48:01 -0500
> From: [email protected]
> Subject: Re: Xpediter debugger tool  Vs.  CSVQUERY Macro
> To: [email protected]
> 
> If you are using the return address (R14) in your code to determine the name
> of the calling module, I believe it could frequently be something you did
> not expect when your code is running under a debugger.  Debuggers often use
> redirection technology of one sort or another to maintain control over the
> code being debugged.  It is a required part of the job.
> 
> Your expectation needs a change.  When running under a debugger you should
> expect that the return point could be to the debugger's code rather than
> your own code.  I don't know anything about Xpediter or the techniques that
> it employs, but this would apply to most debuggers including ours.  If your
> code needs to know the name of your program that called it, the only
> accurate way would be to pass it rather than try and discover it.
> 
> Chuck Arney
> Arney Computer Systems
> zosdebug.com
> 
> -----Original Message-----
> From: IBM Mainframe Assembler List [mailto:[email protected]]
> On Behalf Of Alexandre Franke
> Sent: Wednesday, May 29, 2013 10:31 PM
> To: [email protected]
> Subject: Xpediter debugger tool Vs. CSVQUERY Macro
> 
> 
> 
> 
> Hello ! We have an assembler subroutine that invokes CSVQUERY macro in order
> to get its caller program name, but when running it under Xpediter, it
> doesn't work. It seems the addresses CSVQUERY look for are messed up...
> Does anyone know how CSVQUERY results could be changed when testing under
> Xpediter debugging session? Thank you, Alexandre Franke
                                          

Reply via email to