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
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 responsibility of the called program to indicate (with 'FnSA') the

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
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! Peter -Original Message- From: IBM Mainframe Assembler List

Re: Save areas (not XPLINK).

2017-05-30 Thread Charles Mills
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 could be/hope I am wrong. Charles -Original

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