Re: Dump in 64 bit mode "Storage around GPR2 is invalid."

[Tom Marchant]

On Tue, 30 Aug 2016 08:49:12 -0700, Charles Mills wrote:

>> You cannot call a 31-bit LE program (XPLINK or non-XPLINK) from XPLINK-64 
>> unless you establish a new LE environment.
>
>FWIW in my (by definition limited) experience many (all of mine, for example) 
>assembler modules are essentially non-LE. They actually run in an LE enclave, 
>but they don't know that, other than the fact that they begin with EDCPRLG.

I'm not certain, but I think that means that the assembler program is LE 
enabled, and depends upon the 31-bit LE environment being set up for it.

-- 
Tom Marchant

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Dump in 64 bit mode "Storage around GPR2 is invalid."

[Charles Mills]

> You cannot call a 31-bit LE program (XPLINK or non-XPLINK) from XPLINK-64 
> unless you establish a new LE environment.

FWIW in my (by definition limited) experience many (all of mine, for example) 
assembler modules are essentially non-LE. They actually run in an LE enclave, 
but they don't know that, other than the fact that they begin with EDCPRLG.

Whatever. My second bullet may be impractical. I said "possibly." I said I had 
no real experience with this. I based my second bullet on what @Don Poitras 
said: "You can call non-XPLINK non-LE 31-bit code from assembler ..."

Perhaps one could put all of one's "business logic" in a common LE-agnostic 
module and build three bridges (non-XPLINK, XPLINK and XPLINK 64) to it. My 
central points are that what @Janet is seeing is not a trivial "bug" and that 
you need to consider three environments in addressing it.

Charles

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Tom Marchant
Sent: Tuesday, August 30, 2016 8:31 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Dump in 64 bit mode "Storage around GPR2 is invalid."

On Tue, 30 Aug 2016 06:33:14 -0700, Charles Mills <charl...@mcn.org> wrote:

>@Janet, I have no personal experience with this exact problem, but from what I 
>do know and what others have written here, if you wish to market a 
>C/C++-callable API-type product in object or assembler source code form, you 
>will have to at least consider shipping not two but THREE implementations:
>
>1. Non-XPLINK (31-bit)
>2. XPLINK (31-bit)
>3. XPLINK-64
>
>Note I say "consider." You could possibly shortcut the above a little:
>
>- If the routine is not called frequently (an initialization routine, for 
>example) you could combine 1 and 2 above and use a #pragma to tell C/C++ what 
>you have done. It should not be called frequently because there is said to be 
>a significant performance penalty.
>- You might be able to solve 3 with a bridge routine rather than a full API 
>implementation, depending on the characteristics of the function. The bridge 
>routine would have to set up the proper linkage including a save area below 
>the bar, copy any above-the-bar parameters below the bar, issue SAM31, and 
>call either 1 or 2. On return it would have to issue SAM64, unwind the 
>linkage, and return.

You cannot call a 31-bit LE program (XPLINK or non-XPLINK) from XPLINK-64 
unless you establish a new LE environment. I've never done it, but I think that 
it means establishing a new LE enclave and tearing it down when you are 
finished. You could potentially implement your API as a non-LE 31-bit program 
and include additional stub modules to call it.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Dump in 64 bit mode "Storage around GPR2 is invalid."

[Tom Marchant]

On Tue, 30 Aug 2016 06:33:14 -0700, Charles Mills  wrote:

>@Janet, I have no personal experience with this exact problem, but from what I 
>do know and what others have written here, if you wish to market a 
>C/C++-callable API-type product in object or assembler source code form, you 
>will have to at least consider shipping not two but THREE implementations:
>
>1. Non-XPLINK (31-bit)
>2. XPLINK (31-bit)
>3. XPLINK-64
>
>Note I say "consider." You could possibly shortcut the above a little:
>
>- If the routine is not called frequently (an initialization routine, for 
>example) you could combine 1 and 2 above and use a #pragma to tell C/C++ what 
>you have done. It should not be called frequently because there is said to be 
>a significant performance penalty.
>- You might be able to solve 3 with a bridge routine rather than a full API 
>implementation, depending on the characteristics of the function. The bridge 
>routine would have to set up the proper linkage including a save area below 
>the bar, copy any above-the-bar parameters below the bar, issue SAM31, and 
>call either 1 or 2. On return it would have to issue SAM64, unwind the 
>linkage, and return.

You cannot call a 31-bit LE program (XPLINK or non-XPLINK) from XPLINK-64 
unless you establish a new LE environment. I've never done it, but I think that 
it means establishing a new LE enclave and tearing it down when you are 
finished. You could potentially implement your API as a non-LE 31-bit program 
and include additional stub modules to call it.

-- 
Tom Marchant

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Dump in 64 bit mode "Storage around GPR2 is invalid."

[Charles Mills]

@Janet, I have no personal experience with this exact problem, but from what I 
do know and what others have written here, if you wish to market a 
C/C++-callable API-type product in object or assembler source code form, you 
will have to at least consider shipping not two but THREE implementations:

1. Non-XPLINK (31-bit)
2. XPLINK (31-bit)
3. XPLINK-64

Note I say "consider." You could possibly shortcut the above a little:

- If the routine is not called frequently (an initialization routine, for 
example) you could combine 1 and 2 above and use a #pragma to tell C/C++ what 
you have done. It should not be called frequently because there is said to be a 
significant performance penalty.
- You might be able to solve 3 with a bridge routine rather than a full API 
implementation, depending on the characteristics of the function. The bridge 
routine would have to set up the proper linkage including a save area below the 
bar, copy any above-the-bar parameters below the bar, issue SAM31, and call 
either 1 or 2. On return it would have to issue SAM64, unwind the linkage, and 
return.

Charles

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Janet Graff
Sent: Monday, August 29, 2016 8:46 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Dump in 64 bit mode "Storage around GPR2 is invalid."

Charles,

It doesn't appear that the register conventions for XPLINK and non-XPLINK are 
compatible.  If one were marketing an Assembler API would you have to deliver 
two versions?  One XPLINK and one non-XPLINK?

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Dump in 64 bit mode "Storage around GPR2 is invalid."

[Don Poitras]

In article <9374213960550353.wa.m42tomibmmainyahoo@listserv.ua.edu> you 
wrote:
> On Mon, 29 Aug 2016 07:51:19 -0700, Charles Mills  wrote:

> >Hmmm. To me, that strategy seems appropriate for a report program ("this
> >field is not relevant to this type of transaction so print blanks or
> >asterisks") but not for a dump program. Isn't a dump -- consider the name --
> >supposed to be "here it all is, as it all is, you figure out what is
> >relevant"?

> In XPLINK, a program does not necessarily save all of the registers, so the 
> contents of the location in the save area that is designated for that 
> register 
> doesn't necessarily have any meaning. In any case, registers 0-3 are not 
> saved, 
> so it would have no meaning to display contents for those registers in the 
> XPLINK (downstack) save area.

> Indeed, if a given XPLINK program were to save only registers 6-10, the 
> contents 
> of registers 4, 5, and 11-15 are meaningless. The unused parts of the save 
> areas 
> are not zeroed, and the residual data does not have any value. In particular, 
> you 
> cannot assume that the doubleword that is allocated for R11 contained an R11 
> value from a previous call because of the way the stack frames are allocated.

> The reference for this information is the LE Vendor Interfaces manual. 

> Yes, it is XPLINK-64. The only linkage that LE supports in AMODE 64 is 
> XPLINK-64.

> And XPLINK is not anything like standard linkage. It is possible for an 
> XPLINK-64 
> program to call a non-XPLINK program that is not LE enabled, but AFAIK it can 
> only call an AMODE 64 non-XPLINK program because the save area that is passed 
> is a 144-byte save area within the XPLINK stack, and is above the bar. An 
> assembler program would typically use F4SA format to save its caller's 
> registers.

You can call non-XPLINK non-LE 31-bit code from assembler. Just make sure to 
allocate
(if needed) a 72 byte save area below the bar and point R13 at it. Construct a
normal parm list below the bar as well and point R1 at that. All the storage 
that
the 31-bit program is expected to access must also be below the bar. Make sure
to SAM31 before calling and SAM64 when you come back.


> For XPLINK-64 to call XPLINK may be possible, but it would require that a new 
> enclave be established. Here I am at (or beyond) the limits of my knowledge.

> XPLINK and XPLINK-64 are not compatible. Part of the reason is that the 
> Common Anchor Area (CAA) is a different format and the mappings for the two 
> formats are not compatible. Just as one example, in in a 24/31-bit CAA the 
> field 
> CEECAAPCB is a 4-byte field at offset X'2F4'. In an XPLINK-64 CAA, CEECAAPCB 
> is at offset X'390'.  At offset X'390' in a 24/31-bit CAA is CEECAASIGNGPTR. 
> One 
> would have thought that they would have at least used different names, and 
> locations that are unused in the older CAA. They didn't.

> And so, when Cobol and PL/I support AMODE 64, it will be only XPLINK-64, and 
> you will only be able to use it if you don't need to mix AMODE 64 and AMODE 
> 31 
> Cobol and/or PL/I programs.

> And, by the way, the main reason for XPLINK is to save a few instructions on 
> program linkage. But making a call to a non-XPLINK program requires rather 
> more 
> instructions than just using standard linkage. And one of the things that 
> Cobol 
> and PL/I programs typically do a lot of is I/O. Those I/O calls are standard 
> linkage 
> calls to, for example, GET and PUT. So the benefits of XPLINK evaporate.

> 

> -- 
> Tom Marchant

-- 
Don Poitras - SAS Development  -  SAS Institute Inc. - SAS Campus Drive
sas...@sas.com   (919) 531-5637Cary, NC 27513

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Dump in 64 bit mode "Storage around GPR2 is invalid."

[Charles Mills]

@Ed, this certainly goes to @Tony's point that CEEDUMP is great except when
it isn't.

It's not my pig and it's not my farm but if @Janet wanted to submit a
requirement I would support it.

Charles

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Edward Gould
Sent: Monday, August 29, 2016 12:39 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Dump in 64 bit mode "Storage around GPR2 is invalid."

> On Aug 29, 2016, at 9:51 AM, Charles Mills <charl...@mcn.org> wrote:
> 
> Hmmm. To me, that strategy seems appropriate for a report program 
> ("this field is not relevant to this type of transaction so print 
> blanks or
> asterisks") but not for a dump program. Isn't a dump -- consider the 
> name -- supposed to be "here it all is, as it all is, you figure out 
> what is relevant"?
> 
> Is not the contents of an "irrelevant" register save area sometimes 
> the very clue you need? "Look at that -- it looks like part of one of 
> my error diagnostics -- I must be overlaying storage with the message" 
> or "look, R2 is pointing to my widget table. I must have come through 
> the widget lookup routine after all."
> 
> I know, my comment is fundamentally irrelevant. LE's dump program 
> works the way it works, and they are not going to change it because of 
> a comment on IBM-MAIN, at least not in time to help @Janet.
> 
> Charles

Charles:

Try a SHARE requirement. LE (as usual IMO) is being arrogant , They really
need to be slapped down a few notches.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Dump in 64 bit mode "Storage around GPR2 is invalid."

[Tom Marchant]

On Mon, 29 Aug 2016 07:51:19 -0700, Charles Mills  wrote:

>Hmmm. To me, that strategy seems appropriate for a report program ("this
>field is not relevant to this type of transaction so print blanks or
>asterisks") but not for a dump program. Isn't a dump -- consider the name --
>supposed to be "here it all is, as it all is, you figure out what is
>relevant"?

In XPLINK, a program does not necessarily save all of the registers, so the 
contents of the location in the save area that is designated for that register 
doesn't necessarily have any meaning. In any case, registers 0-3 are not saved, 
so it would have no meaning to display contents for those registers in the 
XPLINK (downstack) save area.

Indeed, if a given XPLINK program were to save only registers 6-10, the 
contents 
of registers 4, 5, and 11-15 are meaningless. The unused parts of the save 
areas 
are not zeroed, and the residual data does not have any value. In particular, 
you 
cannot assume that the doubleword that is allocated for R11 contained an R11 
value from a previous call because of the way the stack frames are allocated.

The reference for this information is the LE Vendor Interfaces manual. 

Yes, it is XPLINK-64. The only linkage that LE supports in AMODE 64 is 
XPLINK-64.

And XPLINK is not anything like standard linkage. It is possible for an 
XPLINK-64 
program to call a non-XPLINK program that is not LE enabled, but AFAIK it can 
only call an AMODE 64 non-XPLINK program because the save area that is passed 
is a 144-byte save area within the XPLINK stack, and is above the bar. An 
assembler program would typically use F4SA format to save its caller's 
registers.

For XPLINK-64 to call XPLINK may be possible, but it would require that a new 
enclave be established. Here I am at (or beyond) the limits of my knowledge.

XPLINK and XPLINK-64 are not compatible. Part of the reason is that the 
Common Anchor Area (CAA) is a different format and the mappings for the two 
formats are not compatible. Just as one example, in in a 24/31-bit CAA the 
field 
CEECAAPCB is a 4-byte field at offset X'2F4'. In an XPLINK-64 CAA, CEECAAPCB 
is at offset X'390'.  At offset X'390' in a 24/31-bit CAA is CEECAASIGNGPTR. 
One 
would have thought that they would have at least used different names, and 
locations that are unused in the older CAA. They didn't.

And so, when Cobol and PL/I support AMODE 64, it will be only XPLINK-64, and 
you will only be able to use it if you don't need to mix AMODE 64 and AMODE 31 
Cobol and/or PL/I programs.

And, by the way, the main reason for XPLINK is to save a few instructions on 
program linkage. But making a call to a non-XPLINK program requires rather more 
instructions than just using standard linkage. And one of the things that Cobol 
and PL/I programs typically do a lot of is I/O. Those I/O calls are standard 
linkage 
calls to, for example, GET and PUT. So the benefits of XPLINK evaporate.



-- 
Tom Marchant

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Dump in 64 bit mode "Storage around GPR2 is invalid."

[Edward Gould]

> On Aug 29, 2016, at 9:51 AM, Charles Mills  wrote:
> 
> Hmmm. To me, that strategy seems appropriate for a report program ("this
> field is not relevant to this type of transaction so print blanks or
> asterisks") but not for a dump program. Isn't a dump -- consider the name --
> supposed to be "here it all is, as it all is, you figure out what is
> relevant"?
> 
> Is not the contents of an "irrelevant" register save area sometimes the very
> clue you need? "Look at that -- it looks like part of one of my error
> diagnostics -- I must be overlaying storage with the message" or "look, R2
> is pointing to my widget table. I must have come through the widget lookup
> routine after all."
> 
> I know, my comment is fundamentally irrelevant. LE's dump program works the
> way it works, and they are not going to change it because of a comment on
> IBM-MAIN, at least not in time to help @Janet.
> 
> Charles

Charles:

Try a SHARE requirement. LE (as usual IMO) is being arrogant , They really need 
to be slapped down a few notches.

Ed

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Dump in 64 bit mode "Storage around GPR2 is invalid."

[Charles Mills]

@Janet, your observation is correct and yes, if one were marketing assembler 
code (or for that matter, code in any language) for integration with LE C/C++, 
yes, one might well want to ship two versions. One would not "have to" but one 
might want to in order to sell a complete solution.

You can with a #pragma tell C/C++ "This program is XPLINK in general but call 
this one routine using non-XPLINK conventions" (and perhaps vice versa) but 
there is said to be a significant performance penalty, so if your API is 
intended to be called "a lot" you would need to consider that.

Charles

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Janet Graff
Sent: Monday, August 29, 2016 8:46 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Dump in 64 bit mode "Storage around GPR2 is invalid."

Charles,

It doesn't appear that the register conventions for XPLINK and non-XPLINK are 
compatible.  If one were marketing an Assembler API would you have to deliver 
two versions?  One XPLINK and one non-XPLINK?

>Charles

--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Dump in 64 bit mode "Storage around GPR2 is invalid."

[Janet Graff]

Charles,

It doesn't appear that the register conventions for XPLINK and non-XPLINK are 
compatible.  If one were marketing an Assembler API would you have to deliver 
two versions?  One XPLINK and one non-XPLINK?

Janet

>@Janet, it occurred to me that you are talking about both C and "XGR." That to 
>me implies that you are calling assembler from C (or perhaps vice >versa) -- 
>is that right?

>If so, do you know that XPLINK (which I believe is implied by AMODE 64) is 
>something you *do* have to know about? It's another brave new world: >you 
>can't just do STM R14,R12,12(R13) any more.

>Search the KC for EDCXPRLG.

>Charles

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Dump in 64 bit mode "Storage around GPR2 is invalid."

[Charles Mills]

Hmmm. To me, that strategy seems appropriate for a report program ("this
field is not relevant to this type of transaction so print blanks or
asterisks") but not for a dump program. Isn't a dump -- consider the name --
supposed to be "here it all is, as it all is, you figure out what is
relevant"?

Is not the contents of an "irrelevant" register save area sometimes the very
clue you need? "Look at that -- it looks like part of one of my error
diagnostics -- I must be overlaying storage with the message" or "look, R2
is pointing to my widget table. I must have come through the widget lookup
routine after all."

I know, my comment is fundamentally irrelevant. LE's dump program works the
way it works, and they are not going to change it because of a comment on
IBM-MAIN, at least not in time to help @Janet.

Charles

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Peter Relson
Sent: Sunday, August 28, 2016 5:27 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Dump in 64 bit mode "Storage around GPR2 is invalid."

The LE folks indicate that the message really does not have much to do with
the display of asterisks for that register.

For performance reasons, the C/C++ compiler may choose not to save specific
registers. If register contents were not saved, then the data for that
register is residual information that CEEDUMP considers not to be meaningful
to the owning routine. CEEDUMP suppresses that residual information,
replacing it with the asterisks. 

I do not know why they would both do that and also attempt to dump storage
around that register and display a message when that storage is not
available to be dumped.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Dump in 64 bit mode "Storage around GPR2 is invalid."

[Peter Relson]

The LE folks indicate that the message really does not have much to do 
with the display of asterisks for that register.

For performance reasons, the C/C++ compiler may choose not to save 
specific registers. If register contents were not saved, then the data for 
that register is residual information that CEEDUMP considers not to be 
meaningful to the owning routine. CEEDUMP suppresses that residual 
information, replacing it with the asterisks. 

I do not know why they would both do that and also attempt to dump storage 
around that register and display a message when that storage is not 
available to be dumped.

Regardless it sounds like the message is not worth worrying about if the 
display shows asterisks.

Peter Relson
z/OS Core Technology Design


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Dump in 64 bit mode "Storage around GPR2 is invalid."

[Charles Mills]

@Janet, it occurred to me that you are talking about both C and "XGR." That to 
me implies that you are calling assembler from C (or perhaps vice versa) -- is 
that right?

If so, do you know that XPLINK (which I believe is implied by AMODE 64) is 
something you *do* have to know about? It's another brave new world: you can't 
just do STM R14,R12,12(R13) any more.

Search the KC for EDCXPRLG.

Charles

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Tony Harminc
Sent: Thursday, August 25, 2016 7:58 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Dump in 64 bit mode "Storage around GPR2 is invalid."

On 25 August 2016 at 17:52, Janet Graff
<004dc9e91b6d-dmarc-requ...@listserv.ua.edu> wrote:
> I don't know if I'm XPLINK or standard linkage.

The fact that your dump says DOWNSTACK DSA almost certainly implies XPLINK.  In 
the LE Debugging guide where I went to verify this, there is this interesting 
note under "Finding XPLINK information in a Language Environment dump":

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Dump in 64 bit mode "Storage around GPR2 is invalid."

[Tony Harminc]

On 25 August 2016 at 17:52, Janet Graff
<004dc9e91b6d-dmarc-requ...@listserv.ua.edu> wrote:
> I don't know if I'm XPLINK or standard linkage.

The fact that your dump says DOWNSTACK DSA almost certainly implies
XPLINK.  In the LE Debugging guide where I went to verify this, there
is this interesting note under "Finding XPLINK information in a
Language Environment dump":

"It is important to understand that the registers saved in an upstack
DSA are those
saved by a routine that the DSA-owning routine called. Typically
register 15 is the
entry point of the routine that was called, and register 14 is the
return address into
the DSA-owning routine. In contrast, the registers saved in an downstack DSA are
those saved by the DSA-owning routine on entry. Register 7 is the return address
back to the caller of the DSA-owning routine. Register 6 may be the
entry point of
the DSA-owning routine."

Regardless, I don't think these are *your* registers at time of failure.

> Regarding overlays, anything is possible but it's highly unlikely.  I've been 
> forcing dumps every couple of instructions to make sure things are clean. The 
> registers in the downstack area don't all reflect the actual state of things 
> when I force the abends.  Can do a LA R5,186 and the dump will still show R5 
> containing all Beees.

>  I wish I could use TSO TEST but I don't know how to get it to run on a USS 
> executable.

If you don't know TEST, I wouldn't start now... For one thing, the
support for anything 64-bit is somewhere between none and minimal. But
if you know TEST, then it should be possible to copy your executable
(program object in a UNIX file) into a PDSE member and then run it
under TEST. But then you won't have a UNIX shell, and who knows what
else may be missing; it may take you down a rathole. But I *have* done
this copy of a program that was written by non-MVS C programmers into
a PDSE and run it under TSO successfully, so at least that part can
work.

Good luck.

Tony H.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Dump in 64 bit mode "Storage around GPR2 is invalid."

[Janet Graff]

Thanks Charles!

>Why are you using the AIX compiler reference? There is a z/OS compiler 
>reference manual, you know. Covers USS as well as legacy MVS.
>http://www-01.ibm.com/support/docview.wss?uid=swg27036892 

>Charles

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Dump in 64 bit mode "Storage around GPR2 is invalid."

[Charles Mills]

http://www.ibm.com/support/knowledgecenter/SSLTBW_2.1.0/com.ibm.zos.v2r1.ceea300/xplnk5.htm
 

Ah! You know what? I am 95% sure that AMODE 64 implies XPLINK. 

Why are you using the AIX compiler reference? There is a z/OS compiler 
reference manual, you know. Covers USS as well as legacy MVS.
http://www-01.ibm.com/support/docview.wss?uid=swg27036892 

Charles

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Janet Graff
Sent: Thursday, August 25, 2016 5:52 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Dump in 64 bit mode "Storage around GPR2 is invalid."

I don't know if I'm XPLINK or standard linkage.
I'm using the following command to link

xlc -o MY64.exe -q64 VSHVOLTG.o VSHVOLT.o VSHMSG.o MY64.o

where would I look to see if XPLINK is turned on?  How would I turn it off?  I 
can't find XPLINK mentioned in the Compiler Reference V10.1 IBM XL C for AIX, 
V10.1 http://www-01.ibm.com/support/docview.wss?uid=swg27012874=1.

Regarding overlays, anything is possible but it's highly unlikely.  I've been 
forcing dumps every couple of instructions to make sure things are clean. The 
registers in the downstack area don't all reflect the actual state of things 
when I force the abends.  Can do a LA R5,186 and the dump will still show R5 
containing all Beees.

 I wish I could use TSO TEST but I don't know how to get it to run on a USS 
executable.

Janet

>Are you XPLINK or standard linkage?

>Any *possibility* that you have overlaid the stacked save areas in your code? 
>R12:R15 = 404040... looks mighty suspicious to me.

>Charles

--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Dump in 64 bit mode "Storage around GPR2 is invalid."

[Janet Graff]

I don't know if I'm XPLINK or standard linkage.
I'm using the following command to link

xlc -o MY64.exe -q64 VSHVOLTG.o VSHVOLT.o VSHMSG.o MY64.o

where would I look to see if XPLINK is turned on?  How would I turn it off?  I 
can't find XPLINK mentioned in the Compiler Reference V10.1 IBM XL C for AIX, 
V10.1 http://www-01.ibm.com/support/docview.wss?uid=swg27012874=1.

Regarding overlays, anything is possible but it's highly unlikely.  I've been 
forcing dumps every couple of instructions to make sure things are clean. The 
registers in the downstack area don't all reflect the actual state of things 
when I force the abends.  Can do a LA R5,186 and the dump will still show R5 
containing all Beees.

 I wish I could use TSO TEST but I don't know how to get it to run on a USS 
executable.

Janet

>Are you XPLINK or standard linkage?

>Any *possibility* that you have overlaid the stacked save areas in your code? 
>R12:R15 = 404040... looks mighty suspicious to me.

>Charles

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Dump in 64 bit mode "Storage around GPR2 is invalid."

[Charles Mills]

At the risk of topic drift, BTW I believe LGHI Rx,0 is now preferred to XGR 
Rx,Rx. Why?

- On older processors, XGR makes the poor CPU get a stable copy of the register 
and tie up the fixed point arithmetic unit, a long hard way of solving the 
simple problem of "slam a zero into Rx."
- Newer processors recognize XR/SR/SLR Rx,Rx and just treat it as "slam a zero 
into Rx" but it still sets the condition code, which is an unnecessary 
complication for the pipeline logic. Don't mess with the condition code if you 
don't need to.

(Source: 
https://www.ibm.com/developerworks/community/files/form/anonymous/api/library/ff4563be-756e-49bf-9de9-6a04a08026f1/document/3dff8d34-fcf9-4939-9efc-11f15a3ce0f8/media/IBM%20z%20Systems%20Processor%20Optimization%20Primer.pdf)
 

It's a brave new processor world out there. Many things you learned in 1996 are 
no longer true.

Charles

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Tony Harminc
Sent: Thursday, August 25, 2016 2:16 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Dump in 64 bit mode "Storage around GPR2 is invalid."

On 25 August 2016 at 12:11, Janet Graff
<004dc9e91b6d-dmarc-requ...@listserv.ua.edu> wrote:

> I have XGR'd GPR2 and GPR3 before the abend and GPR5 definitely does not 
> contain a bunch Beees.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Dump in 64 bit mode "Storage around GPR2 is invalid."

[Charles Mills]

Yeah, no disagreement there. Like any of these tools that "do the work for you" 
they are great until they guess wrong.

Many years ago I learned to really dislike Abend-Aid. I'm sure it is a 
wonderful help to the average application programmer but it seemed to always 
obfuscate the kind of more complex ABENDs that I was shooting. (No 
disparagement intended to my friends at Compuware. I'm sure it's a wonderful 
product, and //ABNLIGN DD DUMMY solved my problem.)

Charles

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Tony Harminc
Sent: Thursday, August 25, 2016 1:54 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Dump in 64 bit mode "Storage around GPR2 is invalid."

On 25 August 2016 at 12:47, Charles Mills <charl...@mcn.org> wrote:
> I am generally very happy with the CEEDUMP and find it quite satisfactory.

My experience with CEEDUMP is that it's all just fine until it isn't.
It seems not to cope at all well with anything other than a simple failure 
within your own code. If anything the least bit subtle happens
- a stack overlay, a failure in a library routine, abend in a UNIX kernel or 
other z/OS system routine - it just can't be relied on to give you the 
information needed to find the root cause. Then you have to disable all LE 
exception handling, set a SLIP trap, and go back to debugging with a "real" 
dump.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Dump in 64 bit mode "Storage around GPR2 is invalid."

[Tony Harminc]

On 25 August 2016 at 12:11, Janet Graff
<004dc9e91b6d-dmarc-requ...@listserv.ua.edu> wrote:

> I have XGR'd GPR2 and GPR3 before the abend and GPR5 definitely does not 
> contain a bunch Beees.

I'm not sure quite what you mean by this. Your own code (that you know
has run not long before the abend?) XGR'd both G2 and G3 with
themselves, i.e. zeroed them? Or XGR'd with each other? Or...?

Perhaps interesting that X'B' is the inverse of X'4'. But I don't see
any convenient X'BF's in any of those regs to go with the X'40's.

Tony H.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Dump in 64 bit mode "Storage around GPR2 is invalid."

[Tony Harminc]

On 25 August 2016 at 12:47, Charles Mills  wrote:
> I am generally very happy with the CEEDUMP and find it quite satisfactory.

My experience with CEEDUMP is that it's all just fine until it isn't.
It seems not to cope at all well with anything other than a simple
failure within your own code. If anything the least bit subtle happens
- a stack overlay, a failure in a library routine, abend in a UNIX
kernel or other z/OS system routine - it just can't be relied on to
give you the information needed to find the root cause. Then you have
to disable all LE exception handling, set a SLIP trap, and go back to
debugging with a "real" dump.

> Are you XPLINK or standard linkage?

I believe DOWNSTACK implies XPLINK.

Tony H.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Dump in 64 bit mode "Storage around GPR2 is invalid."

[Charles Mills]

I don't have an example in front of me (not enough S0C4's lately ) so I 
can't talk specifics but I am generally very happy with the CEEDUMP and find it 
quite satisfactory. My C++ is exclusively AMODE 31 (with some assembler 
subroutines using SAM64) so I suspect your problems are due to the somewhat 
"tiptoeing into the water" nature of the AMODE 64 support. I would open a 
ticket with IBM. Even if the storage pointed to by Rx is invalid the contents 
of Rx is always valid and potentially extremely useful, even necessary, in 
problem resolution. I think you have a reportable problem on its face value 
never mind what underlying problems there may be: "GPR's not formatted 
correctly in dump."

Are you XPLINK or standard linkage?

Any *possibility* that you have overlaid the stacked save areas in your code? 
R12:R15 = 404040... looks mighty suspicious to me.

Charles

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Janet Graff
Sent: Thursday, August 25, 2016 12:12 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Dump in 64 bit mode "Storage around GPR2 is invalid."

Here's an example

  Parameters, Registers, and Variables for Active Routines: 
main (DSA address 0048082FEA20):
  DOWNSTACK DSA 
  Saved Registers:  
GPR0.   GPR1.   GPR2. 
*  GPR3. 
GPR4. 0048082FEA20  GPR5.   GPR6. 
1AC0E618  GPR7. 0048082FF2C8
GPR8. 0005  GPR9.   GPR10 
0001  GPR11 0004
GPR12 4040404040404040  GPR13 4040404040404040  GPR14 
4040404040404040  GPR15 4040404040404040

...

GPREG STORAGE:  
  Storage around GPR0  is invalid.  
  Storage around GPR1  is invalid.  
  Storage around GPR2  is invalid.  
  Storage around GPR3  is invalid.  
  Storage around GPR4 (0048082FEA20)
+0800 0048082FF220  0048 082FF260 0048 08600060  |..2-..

I have XGR'd GPR2 and GPR3 before the abend and GPR5 definitely does not 
contain a bunch Beees.

The program was compiled using xlc on the USS side.

The other issue I have is that the top of stack is not my main() so the PSW and 
"Storage dump near condition, beginning at location" is of CEEHDSP instead of 
main so I can't see what instruction in my program caused the abend.

I assume the registers are modified up stack which is why I can't see them.  
Can I get the dump at the actual abend location?

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Dump in 64 bit mode "Storage around GPR2 is invalid."

[Janet Graff]

Here's an example

  Parameters, Registers, and Variables for Active Routines: 
main (DSA address 0048082FEA20):
  DOWNSTACK DSA 
  Saved Registers:  
GPR0.   GPR1.   GPR2. 
*  GPR3. 
GPR4. 0048082FEA20  GPR5.   GPR6. 
1AC0E618  GPR7. 0048082FF2C8
GPR8. 0005  GPR9.   GPR10 
0001  GPR11 0004
GPR12 4040404040404040  GPR13 4040404040404040  GPR14 
4040404040404040  GPR15 4040404040404040

...

GPREG STORAGE:  
  Storage around GPR0  is invalid.  
  Storage around GPR1  is invalid.  
  Storage around GPR2  is invalid.  
  Storage around GPR3  is invalid.  
  Storage around GPR4 (0048082FEA20)
+0800 0048082FF220  0048 082FF260 0048 08600060  |..2-..

I have XGR'd GPR2 and GPR3 before the abend and GPR5 definitely does not 
contain a bunch Beees.

The program was compiled using xlc on the USS side.

The other issue I have is that the top of stack is not my main() so the PSW and 
"Storage dump near condition, beginning at location" is of CEEHDSP instead of 
main so I can't see what instruction in my program caused the abend.

I assume the registers are modified up stack which is why I can't see them.  
Can I get the dump at the actual abend location?

Janet

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Dump in 64 bit mode "Storage around GPR2 is invalid."

[Janet Graff]

When I get a CEEDUMP while running in 64 bit mode some of the register summary 
shows things like  "GPR2. ".  Why does this happen and how 
do I get the value of the register?

Janet

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN