A variable which is listed in the storage offset listing as 0(r13)
actually never is held in storage, but it resides in a register all the time.
0(r13) simply means that no storage is allocated for this variable (this
is not very nice, I asked the compiler people several times to fix this.
Some compiler versions simply give no offset at all in these cases, only
a line with the variable name and a comma instead of an offset.)
A variable without allocated storage must be a simple local variable
which fits into a register (that is, a pointer, long, int, double etc.).
This is never the case for parameters (they are addressed with r1 and
never transferred by registers, always storage), or parts of a struct,
or variables which need to be addressed by pointer. And, of course,
not for char arrays, decimal values and so on, because they must reside
in storage.
The only way to determine the actual register number is to look at the
assembly code around the error place. If you have something like
x = 0;
*** la r6,0
you know, for example, that r6 is used to hold the value of x.
Kind regards
Bernd
Am Mittwoch, 8. Oktober 2008 23:45 schrieb Adam Johanson:
> I am trying to locate some variables in a C++ dump. The dump is an SVC dump
> of an IMS MPR for a completion code U0240. The variables are defined inside
> the function for the class.
>
> For example:
>
> ClassA::functionB (parm1, parm2, parm3)
> {
> // some variables
> int l_iRetColLoc;
> // some more variables
> ...
> }
>
> When I look at the storage offset listing for l_iRetColLoc, it says that
> its location is at 0(r13). Looks like this means the offset into the
> class that it's part of. But since it's not part of a class, it's at
> offset 0 into itself.
>
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
