>> Interesting. A reference to _gtca() also in LE Vendor Interfaces. Hints here
>> and there in the C/C++ docs.
> I suspect _gtca() does something similar to what is described in "Chapter 14.
> Anchor support" in the LE Vendor Interfaces manual.
Out of curiosity, I had a look at CEEARLU. Th
On Thu, 11 May 2017 17:08:41 -0500, John McKown wrote:
> STM R0,RF,12(RD) SAVE ALL REGS.
> L R3,0(,R1) POINT TO RETURN AREA
> MVC 0(64,R3),12(RD) MOVE REGS AT ENTRY
> SLR RF,RF
> BR RE
>
>This does not use standard linkage, but is that really necessary?
You are going to store
> Interesting. A reference to _gtca() also in LE Vendor Interfaces. Hints here
> and there in the C/C++ docs.
I suspect _gtca() does something similar to what is described in "Chapter 14.
Anchor support" in the LE Vendor Interfaces manual.
--
Peter Hunkeler
-
@LISTSERV.UA.EDU
Subject: Re: How to find Cobol (and C) Working Storage variables in an SVCDUMP
Bernd's assembler technique will work.
I have no idea why I can't find a description of this (taken from
/usr/include/stdio.h)
#ifndef __gtca
#define __gtca() _gtca()
#ifdef _
Bernd's assembler technique will work.
I have no idea why I can't find a description of this (taken from
/usr/include/stdio.h)
#ifndef __gtca
#define __gtca() _gtca()
#ifdef __cplusplus
extern "builtin"
#else
#pragma linkage(_gtca,builtin)
#endif
const void *_gtc
ing.
Charles
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf
Of Bernd Oppolzer
Sent: Thursday, May 11, 2017 3:24 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: How to find Cobol (and C) Working Storage variables in an SVCDUMP
Am 12.05.2017 um
Am 12.05.2017 um 00:08 schrieb John McKown:
On Thu, May 11, 2017 at 4:55 PM, Bernd Oppolzer
wrote:
Yes, of course. I detected the error when I looked at
my piece of software from last year which examined the different LE heaps.
and: thank you, Allan Kielstra, for the clarification regarding R
On Thu, May 11, 2017 at 4:55 PM, Bernd Oppolzer
wrote:
> Yes, of course. I detected the error when I looked at
> my piece of software from last year which examined the different LE heaps.
>
> and: thank you, Allan Kielstra, for the clarification regarding Reg 12;
> so my call to the ASSEMBLER fun
Yes, of course. I detected the error when I looked at
my piece of software from last year which examined the different LE heaps.
and: thank you, Allan Kielstra, for the clarification regarding Reg 12;
so my call to the ASSEMBLER function to get the address of the CEECAA
will work?
Here is the
If a C or PL/I or COBOL (or any LE high level language) program calls an
assembler program, it will have set GPR12 to the CEE Anchor correctly before
making the call. Assuming that you are completely lost in space in LE and you
need the CEE anchor, there is a service called CEEARLU. It is docu
On Thu, 11 May 2017 15:27:38 -0500, Allan Kielstra wrote:
>This statement:
>
>>>CEECSA is always address by reg 12, while inside a LE module.
>
>is not strictly true. GPR12 is only required to point to CEECSA on entry to
>and exit from a procedure. Compilers are free to use GPR12 for whatever o
oh oh ...
I did not take this into account ...
I wrote a C program to get the HPCB addresses for Belowheap and Anyheap,
and to get them, I needed the CEECAA, and I did this by looking at reg
12 using
an ASSEMBLER subprogram:
memset (rbuffer, 0x00, sizeof (rbuffer));
MDV9970 (rbuffer);
This statement:
>>CEECSA is always address by reg 12, while inside a LE module.
is not strictly true. GPR12 is only required to point to CEECSA on entry to
and exit from a procedure. Compilers are free to use GPR12 for whatever other
purpose they chose at other program points.
That means tha
> And I forgot to mention:
>
> CEECSA is always address by reg 12, while inside a LE module.
... and I forgot to thank you as well, Bernd
--
Peter Hunkeler
--
For IBM-MAIN subscribe / signoff / archive access instructions
Many thanks for the details. Much appreciated. This information might be in the
manuals, but it is a bit scattered.
-- Peter Hunkeler
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@li
Bernd has already started the reply, but I would like to add a little bit.
(First, I should say that most of this stuff IS documented in the PG and MG,
but...)
To find a specific W-S variable, you will need a listing.
If you start with a dump, you will find a stack frame for your COBOL progra
Bernd and Peter,
What Bernd shows you is the way I have found it in COBOL V5.1.1. I am
putting up V6 next month and will revisit it again. I also did the ASM
map in V5.1.1 and discovered that Working Storage seems to be based on
Reg. 8. I do not have V5.2, but I would imagine it would be the
Two minor errors below:
"addressed by register 13 (aka save area aka dynamic save area aka
dynamic save area)"
should read
"addressed by register 13 (aka save area aka dynamic save area aka
dynamic STORAGE area)"
And I forgot to mention:
CEECSA is always address by reg 12, while inside a
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 a
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
20 matches
Mail list logo
