Re: Save areas (not XPLINK).

2017-06-16 Thread Tom Marchant
On Tue, 13 Jun 2017 14:19:13 -0700, Ed Jaffe wrote: >The IPCS save area trace seems to work just fine... What trace is that, Ed? The ones I know only seem to work with 72-byte save areas. -- Tom Marchant

Re: Save areas (not XPLINK).

2017-06-13 Thread Ed Jaffe
On 6/12/2017 7:14 PM, Paul Gilmartin wrote: Doesn't the multiplicity of linkage conventions severely erode the usefulness of tracebacks found in dumps? Or is there a one-fits-all dump formatter that can recognize the various save area formats found in a multi-language job step and make sense

Re: Save areas (not XPLINK).

2017-06-12 Thread Steve Smith
I do love that 36D format, but we ought to be sure 8-byte pointers are always fully supported. Plausible deniability is a thing, and it's a good thing. sas On Mon, Jun 12, 2017 at 9:14 PM, Paul Gilmartin < 0014e0e4a59b-dmarc-requ...@listserv.uga.edu> wrote: > On 2017-06-10, at 17:59,

Re: Save areas (not XPLINK).

2017-06-12 Thread Paul Gilmartin
On 2017-06-10, at 17:59, Charles Mills wrote: > And unfortunately there are now six or so variants of "standard" linkage, > hence this thread ... > Doesn't the multiplicity of linkage conventions severely erode the usefulness of tracebacks found in dumps? Or is there a one-fits-all dump

Re: Save areas (not XPLINK).

2017-06-12 Thread Tom Marchant
On Sat, 10 Jun 2017 16:59:22 -0700, Charles Mills wrote: >And unfortunately there are now six or so variants of "standard" linkage, >hence this thread ... Standard linkage was documented in 1966, in the IBM System/360 Operating System Control Program Services manual.

Re: Save areas (not XPLINK).

2017-06-12 Thread Mike Shaw
Me too. Makes me think of an old girlfriend... Mike Shaw MVS/QuickRef Support Group Chicago-Soft, Ltd. On Mon, Jun 12, 2017 at 10:07 AM, John McKown wrote: > On Mon, Jun 12, 2017 at 8:59 AM, Ed Jaffe > wrote: > > > On 6/12/2017 6:40

Re: Save areas (not XPLINK).

2017-06-12 Thread John McKown
On Mon, Jun 12, 2017 at 8:59 AM, Ed Jaffe wrote: > On 6/12/2017 6:40 AM, Steve Smith wrote: > >> Regardless of the meaning of "standard", IBM does provide the IHASAVER >> macro to assist with those choices. >> >> I routinely make save areas 18D (or update from 18F)

Re: Save areas (not XPLINK).

2017-06-12 Thread Ed Jaffe
On 6/12/2017 6:40 AM, Steve Smith wrote: Regardless of the meaning of "standard", IBM does provide the IHASAVER macro to assist with those choices. I routinely make save areas 18D (or update from 18F) these days. I make mine 36D to cover whatever format might be used now or in the future...

Re: Save areas (not XPLINK).

2017-06-12 Thread Steve Smith
Regardless of the meaning of "standard", IBM does provide the IHASAVER macro to assist with those choices. I routinely make save areas 18D (or update from 18F) these days. sas On Sun, Jun 11, 2017 at 1:05 PM, Peter Relson wrote: > >And unfortunately there are now six or so

Re: Save areas (not XPLINK).

2017-06-11 Thread Peter Relson
>And unfortunately there are now six or so variants >of "standard" linkage, hence this thread ... I might instead say that there is one and only one standard linkage and that it applies only when neither ARs nor 64-bit GRs (whether AMODE 64 or not) are involved. And we all know how that

Re: Save areas (not XPLINK).

2017-06-10 Thread Paul Gilmartin
On 2017-06-10, at 17:59, Charles Mills wrote: > And unfortunately there are now six or so variants of "standard" linkage, > hence this thread ... > > Kind of like "standard" UNIX ... > Well, there's POSIX. Given any "UNIX", an expert can find a POSIX violation beyond an extension. z/OS is

Re: Save areas (not XPLINK).

2017-06-10 Thread Charles Mills
Friday, June 9, 2017 1:23 PM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Save areas (not XPLINK). On Fri, 9 Jun 2017 11:50:39 -0700, Charles Mills wrote: >I know what XPLINK means. Is XPLINK a standard? Then is XPLINK linkage >non-standard? That was my "whatever that means.&

Re: Save areas (not XPLINK).

2017-06-09 Thread Tom Marchant
On Fri, 9 Jun 2017 11:50:39 -0700, Charles Mills wrote: >I know what XPLINK means. Is XPLINK a standard? Then is XPLINK linkage >non-standard? That was my "whatever that means." Is XPLINK a standard for >non-standard linkage? Well, I suppose you could say that XPLINK is a standard, but IMO

Re: Save areas (not XPLINK).

2017-06-09 Thread Gary Weinhold
---Original Message- From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On Behalf Of Tom Marchant Sent: Friday, June 9, 2017 11:38 AM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU<mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU> Subject: Re: Save areas (not XPLINK). On Fri, 9 Jun 2017 08

Re: Save areas (not XPLINK).

2017-06-09 Thread Charles Mills
On Behalf Of Tom Marchant Sent: Friday, June 9, 2017 11:38 AM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Save areas (not XPLINK). On Fri, 9 Jun 2017 08:59:02 -0700, Charles Mills wrote: >31-bit C can use non-standard (whatever that means) XPLINK linkage. Standard linkage uses regist

Re: Save areas (not XPLINK).

2017-06-09 Thread Tom Marchant
- >From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On >Behalf Of Swarbrick, Frank >Sent: Friday, June 9, 2017 8:54 AM >To: ASSEMBLER-LIST@LISTSERV.UGA.EDU >Subject: Re: Save areas (not XPLINK). > >>You say "COBOL, and other LE languages, us

Re: Save areas (not XPLINK).

2017-06-09 Thread Charles Mills
@LISTSERV.UGA.EDU Subject: Re: Save areas (not XPLINK). You say "COBOL, and other LE languages, use only standard linkage". Is this true for 64-bit C/C++ and PL/I? Isn't the pragma linkage in C and the extern "linkage specifier" used to specify alternative linkages? The

Re: Save areas (not XPLINK).

2017-06-09 Thread Swarbrick, Frank
DU] On Behalf Of Tom Marchant Sent: Tuesday, May 30, 2017 2:54 PM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Save areas (not XPLINK). On Tue, 30 May 2017 12:53:29 -0500, John McKown wrote: >​Around here, I have a "choice"(?) of either HLASM or COBOL. I don't >exactly _desp

Re: Save areas (not XPLINK).

2017-05-31 Thread M. Ray Mullins
I did run into F2SA over 10 years ago. I was looking at a dump that occurred when a product I worked on called Unicode services (it turned out to be an actual bug in the service). The fine gentleman Peter Relson answered my IBM-MAIN query here, along with a caveat that some components do not

Re: Save areas (not XPLINK).

2017-05-30 Thread Bernd Oppolzer
I recall that POSIX(ON) had to be speficied somewhere, maybe as an LE runtime option ... Am 30.05.2017 um 23:09 schrieb Bernd Oppolzer: Am 30.05.2017 um 22:53 schrieb Tom Marchant: Also, LE does not like LE-enabled standard linkage programs calling XPLINK programs or XPLINK programs calling

Re: Save areas (not XPLINK).

2017-05-30 Thread Bernd Oppolzer
Am 30.05.2017 um 22:53 schrieb Tom Marchant: Also, LE does not like LE-enabled standard linkage programs calling XPLINK programs or XPLINK programs calling LE-enabled standard linkage programs. I'm not clear on the mechanism, but I think that either of these requires that a new LE enclave be

Re: Save areas (not XPLINK).

2017-05-30 Thread Tom Marchant
On Tue, 30 May 2017 13:52:15 -0400, Gary Weinhold wrote: >We once ran into a product that abended when we saved the address of the next >save area at R13+8. So we stopped saving it. The product was no longer >supported, so we couldn't ask for a change. > >It appears that it is the

Re: Save areas (not XPLINK).

2017-05-30 Thread Tom Marchant
On Tue, 30 May 2017 12:42:38 -0400, Farley, Peter x23353 wrote: >Better link to the SHARE session page, from which the PDF may be obtained: > >https://share.confex.com/share/119/webprogram/Session11408.html > >Thank you Tom Marchant for an excellent and very helpful presentation! You're welcome.

Re: Save areas (not XPLINK).

2017-05-30 Thread Tom Marchant
On Tue, 30 May 2017 10:11:05 -0400, Gary Weinhold wrote: >I have notes that indicate there can be an F1SA, which means that this >savearea may be only 8 bytes long because the hardware linkage stack was used. > If R13 is non-zero, the F1SA savearea is a standard 72-byte save-area. > >F6SA is

Re: Save areas (not XPLINK).

2017-05-30 Thread Tom Marchant
On Tue, 30 May 2017 08:39:25 -0500, John McKown wrote: >As best as I can tell, there are 5 different Save Area formats. There is >the historic 72 byte format. This saves bits 32..63 of GPR 14-12. There is >an F4SA which is 144 bytes and contains bits 0..63 of GPRs 14-12. There is >a F5SA which

Re: Save areas (not XPLINK).

2017-05-30 Thread John McKown
On Tue, May 30, 2017 at 12:44 PM, Paul Gilmartin < 0014e0e4a59b-dmarc-requ...@listserv.uga.edu> wrote: > On 2017-05-30, at 09:47, Charles Mills wrote: > > > I don't know the answer to your question but I share your general > consternation. This used to be so simple: program, task or

Re: Save areas (not XPLINK).

2017-05-30 Thread Gary Weinhold
EMBLER-LIST@LISTSERV.UGA.EDU> Subject: Save areas (not XPLINK). As best as I can tell, there are 5 different Save Area formats. There is the historic 72 byte format. This saves bits 32..63 of GPR 14-12. There is an F4SA which is 144 bytes and contains bits 0..63 of GPRs 14-12. There is a F5SA which

Re: Save areas (not XPLINK).

2017-05-30 Thread Paul Gilmartin
On 2017-05-30, at 09:47, Charles Mills wrote: > I don't know the answer to your question but I share your general > consternation. This used to be so simple: program, task or subroutine, on > entry STM and chain. > > I've spent enough time on it to think there is no good general answer. I >

Re: Save areas (not XPLINK).

2017-05-30 Thread Farley, Peter x23353
[mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On Behalf Of Gary Weinhold Sent: Tuesday, May 30, 2017 11:26 AM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Save areas (not XPLINK). It was Tom Marchant: https://share.confex.com/share/119/webprogram/.../Save_area_Conventions.pdf Gary Weinhold Senior Application

Re: Save areas (not XPLINK).

2017-05-30 Thread Charles Mills
- From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On Behalf Of John McKown Sent: Tuesday, May 30, 2017 6:39 AM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Save areas (not XPLINK). As best as I can tell, there are 5 different Save Area formats. There is the historic

Re: Save areas (not XPLINK).

2017-05-30 Thread Gary Weinhold
It was Tom Marchant: https://share.confex.com/share/119/webprogram/.../Save_area_Conventions.pdf Gary Weinhold Senior Application Architect DATAKINETICS | Data Performance & Optimization Phone: +1.613.523.5500 x216 Email: weinh...@dkl.com

Re: Save areas (not XPLINK).

2017-05-30 Thread John McKown
On Tue, May 30, 2017 at 9:11 AM, Gary Weinhold wrote: > I have notes that indicate there can be an F1SA, which means that this > savearea may be only 8 bytes long because the hardware linkage stack was > used. If R13 is non-zero, the F1SA savearea is a standard 72-byte >

Re: Save areas (not XPLINK).

2017-05-30 Thread Jonathan Scott
Ref: Your note of 30 May 2017, 08:39:25 -0500 John McKown writes: > As best as I can tell, there are 5 different Save Area formats... Don't confuse the save area fields which a program is expected to provide for programs which it calls with fields that a program uses to save additional

Re: Save areas (not XPLINK).

2017-05-30 Thread Steve Smith
First answer: The high-halves portion of the save areas is used by the caller, not the callee. I suppose for the case when calling a program that doesn't save all 64 bits, yet uses some of them. The Assembler Services guide goes into great detail on linkage conventions and save area formats, but

Re: Save areas (not XPLINK).

2017-05-30 Thread Gary Weinhold
I have notes that indicate there can be an F1SA, which means that this savearea may be only 8 bytes long because the hardware linkage stack was used. If R13 is non-zero, the F1SA savearea is a standard 72-byte save-area. F6SA is supposed to mean the hardware linkage stack was used and the

Save areas (not XPLINK).

2017-05-30 Thread John McKown
As best as I can tell, there are 5 different Save Area formats. There is the historic 72 byte format. This saves bits 32..63 of GPR 14-12. There is an F4SA which is 144 bytes and contains bits 0..63 of GPRs 14-12. There is a F5SA which holds bits 0..63 of the GPRs 14-12 and bits 0..31 of GPRs