I guess that this is the same case as finding C and PL/1 static variables
when the C and PL/1 procedures or functions are compiled using the RENT
compiler switch.
Because:
a) auto variables are always part of the "stack" which is addressed by
register 13
(aka save area aka dynamic save area aka dynamic save area)
b) in the NORENT case the STATIC variables are part of the STATIC CSECT,
which is located inside the load module ... this is, what classical
COBOL did,
and which is still present in C and PL/1 in the NORENT case ... NORENT is
recommended by IBM for PL/1, today :-)
So, let's go:
the static variables in the RENT case are part of the WSA. To locate
them in
the dump (SYSUDUMP, CEEDUMP, ...), you have several choices:
a) when you are inside the function where the variable is defined,
CEECSA+500 (X'1F4) should point to the WSA, so you have the base
address of the WSA. From the prelinker listing, you can see where the
static section of your particular function starts (Q(@STATIC)), add this
to the
base address, and then add the offset of the variable from the compiler
listing ..
voila the address of the variable
b) to speed up the addressing of the variables at run time, a certain
register
is loaded just after the function prologue with the value CEECSA+500 +
Q(@STATIC).
Look for this register (may be R4, R5, R6, R7, ...). Then add the offset
of the
variable to that register.
Sorry, no easier way. In prior releases, the base register of the static
area
always was register 3 (in PL/1).
The compiler builders could make the jobs of dump readers easier, if they
want, but they normally don't have dump readers in mind.
I'm trying to do it differently with my Stanford Pascal compiler:
http://bernd-oppolzer.de/job9.htm
HTH,
have a nice day
Bernd
Am 10.05.2017 um 21:02 schrieb Peter Hunkeler:
Reposting under a different subject, since the topic has changed
That's actually a trickier question than you might imagine!
I imagine it is! In my current job, I'm getting involved when standard application debugging techniques don't help anymore. I usually work with IPCS, so SYSMDUMPs and SVCDUMPs. We moved to Cobol V5.2 earlier this year, but I still need to find the content of Cobol variables in those dumps. The changes to how Working Storage is implemented, and the fact that this is mostly undocumented, makes it difficult. This is the real reason I'm trying to understand all this.
Your comments are most welcome!
There are a number of cases: the case where your module consists of COBOL,
PL/I and assembler only and all other cases. All other cases include cases
where the COBOL run time support is implemented in a language other than the
above. These cases include OO COBOL, XML support and a few others.
In the second case (not pure COBOL), the C_WSA is loaded in exactly the same way as it is for a C program. Basically, first the program is loaded and then the C run time gets control. It determines that you want to start new instance of this program (C_WSA is only used for RENT.) So it calls CEEPPOS which is the actual routine that gets a WSA and initializes it.
This all happens before main is run. (Or, in the case of C++, before any file
scope statics are constructed.)
Yes, this is well understood.
In the first case, your program starts and the COBOL bootstrap routine gets
control. That routine is called at the start of every PROGRAM. In most cases,
it checks a few things and returns. But for the first program in the run unit,
it does some work including ensuring that LE is up. Part of that work is
getting storage for the WSA.
All of this happens before the first user statement in the PROCEDURE DIVISION
is executed.
So, no matter how the C_WSA is loaded (by and LE routine or by the COBOL run
time) it is present before the first user written statement in the program is
executed.
Yes, again well understood.
Which means that unless you're getting some sort of a trap during the COBOL
start up, you should always see the C_WSA somewhere in your storage.
Yep, somewhere. But somewhere is not specific enough if you need to find the value of a variable at the time of the dump.
By the way, WORKING STORAGE is another area of complexity. In the case of
NOWSOPT (the default for V5) W-S items are directly in the C_WSA. In the case
of WSOPT (V6) W-S is separately allocated and the WSA contains a pointer to
that allocation. (Again, this is all done before the first user statement is
executed.)
I really which there was a document describing all the variants in detail and how to find variables in a dump in each case. Lack of that document, I'm trying to find out step by step.
You would seem to be able to be of great help for me on this quest.
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
