Re: Estae and the Linkage Stack

[Peter Relson]

ESTAE is not associated with the "task"; it is more granular than that. 
It is associated with an RB and a linkage stack level.

When the RB ends, any ESTAE associated with the RB is removed by the 
system.
When the linkage stack level with which the ESTAE is associated "goes 
away", any ESTAE associated with that linkage stack level goes away (where 
z/OS gets control to do this processing due to the unstack suppression bit 
that Greg mentioned).

As you can surmise, when you create an ESTAE(X), the system records "which 
RB" and "what is the linkage stack level".
For an ARR or IEAARR ESTAE-type recovery routine, RTM figures out based on 
the linkage stack entry's PC-number information (so it does not apply to a 
BAKR-created linkage stack entry) whether there is an ARR or whether it is 
one of the PC numbers for IEAARR.

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: Estae and the Linkage Stack

[David Cole]

At 6/13/2017 09:07 AM, Joseph Reichman wrote:

So PC inst will also un-define an ESTAE


No... Only the PR will "un-define" an ESTAE.

PC is more similar in functionality to a BAKR than to a PR.
Both PCs and BAKRs create stack entries.
Only the PR removes them.

When a PR removes a stack entry, all ESTAE[X] routines that are newer 
than the stack entry will also be removed.


All ESTAE[X] routines that are older than the stack entry will survive.


Dave Cole
ColeSoft Marketing
414 Third Street, NE
Charlottesville, VA 22902
EADDRESS:dbc...@colesoft.com

Home page:   www.colesoft.com
LinkedIn:www.xdc.com
Facebook:www.facebook.com/colesoftware
YouTube: www.youtube.com/user/colesoftware

Dave Cole
ColeSoft Marketing
414 Third Street, NE
Charlottesville, VA 22902
EADDRESS:dbc...@colesoft.com

Home page:   www.colesoft.com
LinkedIn:www.xdc.com
Facebook:www.facebook.com/colesoftware
YouTube: www.youtube.com/user/colesoftware  


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

Re: Estae and the Linkage Stack

[Joseph Reichman]

So PC inst will also un-define an ESTAE



> On Jun 13, 2017, at 9:05 AM, Greg Dyck  wrote:
> 
>> On 6/13/2017 2:55 AM, David Cole wrote:
>> PRs do automagically cancel all ESTAEs created since the matching BAKR. 
>> There is a bit (in the BAKR's stack entry I think. I forget which and 
>> where.) that, when set on, causes an interrupt to occur when the PR is 
>> issued. This is how z/OS gains control so that it can do the purge of the 
>> appropriate SCB[s].
> 
> You are referring to the unstack-suppression bit in the linkage stack entry 
> descriptor.  It it used to trigger several different types of processing 
> within z/OS when an entry is removed from the linkage stack, either explicity 
> by a PR or implicitly by a RB being dequeued from a TCB after terminating 
> (normally or abnormally).
> 
> Regards,
> Greg
> 
> --
> 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: Estae and the Linkage Stack

[Greg Dyck]

On 6/13/2017 2:55 AM, David Cole wrote:
PRs do automagically cancel all ESTAEs created since the matching BAKR. 
There is a bit (in the BAKR's stack entry I think. I forget which and 
where.) that, when set on, causes an interrupt to occur when the PR is 
issued. This is how z/OS gains control so that it can do the purge of 
the appropriate SCB[s].


You are referring to the unstack-suppression bit in the linkage stack 
entry descriptor.  It it used to trigger several different types of 
processing within z/OS when an entry is removed from the linkage stack, 
either explicity by a PR or implicitly by a RB being dequeued from a TCB 
after terminating (normally or abnormally).


Regards,
Greg

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

Re: Estae and the Linkage Stack

[Blaicher, Christopher Y.]

Yes they will stay defined.  If you define an ESTAE at the beginning of a 
program, outside of a linkage stack entry, you can create and delete all the 
linkage stack entries you want and it will still be there.

You could create a linkage stack entry on entry to your program rather than 
chaining save areas, create an ESTAE, and have stack entries below it and the 
ESTAE will be there until you do your final PC back to the system, not that I 
would recommend doing that.

Chris Blaicher
Technical Architect
Mainframe Development
P: 201-930-8234  |  M: 512-627-3803
E: cblaic...@syncsort.com

Syncsort Incorporated
2 Blue Hill Plaza #1563
Pearl River, NY 10965
www.syncsort.com

Data quality leader Trillium Software is now a part of Syncsort.


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Joseph Reichman
Sent: Tuesday, June 13, 2017 8:50 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Estae and the Linkage Stack

Will the ESTAE remain active if declared outside of the BAKR/PR pair

David from you description it should



> On Jun 13, 2017, at 3:55 AM, David Cole <dbc...@colesoft.com> wrote:
>
> BAKRs do not create or cancel ESTAEs.
>
> PRs do automagically cancel all ESTAEs created since the matching BAKR. There 
> is a bit (in the BAKR's stack entry I think. I forget which and where.) that, 
> when set on, causes an interrupt to occur when the PR is issued. This is how 
> z/OS gains control so that it can do the purge of the appropriate SCB[s].
>
> I remember how surprised I was to discover this some years ago when I was 
> writing z/XDC's linkage stack support.
>
> Dave Cole
> ColeSoft Marketing
> 414 Third Street, NE
> Charlottesville, VA 22902
> EADDRESS:dbc...@colesoft.com
>
> Home page:   www.colesoft.com
> LinkedIn:www.xdc.com
> Facebook:www.facebook.com/colesoftware
> YouTube: www.youtube.com/user/colesoftware
>
>
>
>
>
>
> At 6/12/2017 06:24 PM, Joseph Reichman wrote:
>> Hi
>>
>> I thought for the longest time that an ESTAE was associated with a Task.
>> Then I saw a thread with Chris Blaicher where the upshot as that a
>> BAKR would deactivate it
>>
>> I did a search on the archives but didn't come up with anything.
>
> --
> 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





ATTENTION: -

The information contained in this message (including any files transmitted with 
this message) may contain proprietary, trade secret or other confidential 
and/or legally privileged information. Any pricing information contained in 
this message or in any files transmitted with this message is always 
confidential and cannot be shared with any third parties without prior written 
approval from Syncsort. This message is intended to be read only by the 
individual or entity to whom it is addressed or by their designee. If the 
reader of this message is not the intended recipient, you are on notice that 
any use, disclosure, copying or distribution of this message, in any form, is 
strictly prohibited. If you have received this message in error, please 
immediately notify the sender and/or Syncsort and destroy all copies of this 
message in your possession, custody or control.

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

Re: Estae and the Linkage Stack

[Joseph Reichman]

Will the ESTAE remain active if declared outside of the BAKR/PR pair 

David from you description it should



> On Jun 13, 2017, at 3:55 AM, David Cole  wrote:
> 
> BAKRs do not create or cancel ESTAEs.
> 
> PRs do automagically cancel all ESTAEs created since the matching BAKR. There 
> is a bit (in the BAKR's stack entry I think. I forget which and where.) that, 
> when set on, causes an interrupt to occur when the PR is issued. This is how 
> z/OS gains control so that it can do the purge of the appropriate SCB[s].
> 
> I remember how surprised I was to discover this some years ago when I was 
> writing z/XDC's linkage stack support.
> 
> Dave Cole
> ColeSoft Marketing
> 414 Third Street, NE
> Charlottesville, VA 22902
> EADDRESS:dbc...@colesoft.com
> 
> Home page:   www.colesoft.com
> LinkedIn:www.xdc.com
> Facebook:www.facebook.com/colesoftware
> YouTube: www.youtube.com/user/colesoftware
> 
> 
> 
> 
> 
> 
> At 6/12/2017 06:24 PM, Joseph Reichman wrote:
>> Hi
>> 
>> I thought for the longest time that an ESTAE was associated with a Task.
>> Then I saw a thread with Chris Blaicher where the upshot as that a BAKR
>> would deactivate it
>> 
>> I did a search on the archives but didn't come up with anything.
> 
> --
> 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: Estae and the Linkage Stack

[David Cole]

BAKRs do not create or cancel ESTAEs.

PRs do automagically cancel all ESTAEs created since the matching 
BAKR. There is a bit (in the BAKR's stack entry I think. I forget 
which and where.) that, when set on, causes an interrupt to occur 
when the PR is issued. This is how z/OS gains control so that it can 
do the purge of the appropriate SCB[s].


I remember how surprised I was to discover this some years ago when I 
was writing z/XDC's linkage stack support.


Dave Cole
ColeSoft Marketing
414 Third Street, NE
Charlottesville, VA 22902
EADDRESS:dbc...@colesoft.com

Home page:   www.colesoft.com
LinkedIn:www.xdc.com
Facebook:www.facebook.com/colesoftware
YouTube: www.youtube.com/user/colesoftware






At 6/12/2017 06:24 PM, Joseph Reichman wrote:

Hi

I thought for the longest time that an ESTAE was associated with a Task.
Then I saw a thread with Chris Blaicher where the upshot as that a BAKR
would deactivate it

I did a search on the archives but didn't come up with anything.


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

Re: Estae and the Linkage Stack

[Joseph Reichman]

Thanks for getting back to me I see it now

I had recovery routine and abended in a subroutine which had a BAKR it
apparently deactivated it the documentation below is very unclear

Thanks 

 
 DeactivatinganESTAE-TypeRecoveryRoutine: A program may deactivate an
ESTAE-type recovery routine only under the same linkage stack level as the
level that existed when the program activated the recovery routine. This
rule affects programs that add entries to the linkage stack either through
the BAKR or PC instruction. Failure to follow this rule results in an error
return code of 36 from the ESTAE or ESTAEX macro. 
 When you issue a PR, the system automatically deactivates all ESTAE-type
recovery routines that were previously activated under that current linkage
stack entry.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Blaicher, Christopher Y.
Sent: Monday, June 12, 2017 6:52 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Estae and the Linkage Stack

It is a little tricky.  In the Assembler Services Guide there is a section
called Linkage Stack Considerations in chapter 8, the last paragraph of
which says:

When you issue a PR, the system automatically deactivates all ESTAE-type
recovery routines that were previously activated under that current linkage
stack entry.

What I was writing about was, being lazy and not wanting to allocate a save
area, I used BAKR/PR to save and restore the registers when I called a
subroutine to do some initialization including a setup of the ESTAE, and the
ESTAE was not there when the program later abended. (I thought I knew
everything and hadn't read the previous paragraph.)

So, what happened was the system very nicely setup my ESTAE in the
subroutine, and very nicely deactivated it when I exited the subroutine.
Now, if I hadn't use BAKR/PR and done a real subroutine call, all would have
been fine.

Chris Blaicher
Technical Architect
Mainframe Development
P: 201-930-8234  |  M: 512-627-3803
E: cblaic...@syncsort.com <mailto:cblaic...@syncsort.com> 

Syncsort Incorporated
2 Blue Hill Plaza #1563
Pearl River, NY 10965
www.syncsort.com <http://www.syncsort.com> 

Data quality leader Trillium Software is now a part of Syncsort.


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Joseph Reichman
Sent: Monday, June 12, 2017 6:24 PM
To: IBM-MAIN@LISTSERV.UA.EDU <mailto:IBM-MAIN@LISTSERV.UA.EDU> 
Subject: Estae and the Linkage Stack

Hi



I thought for the longest time that an ESTAE was associated with a Task.
Then I saw a thread with Chris Blaicher where the upshot as that a BAKR
would deactivate it



I did a search on the archives but didn't come up with anything


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





ATTENTION: -

The information contained in this message (including any files transmitted
with this message) may contain proprietary, trade secret or other
confidential and/or legally privileged information. Any pricing information
contained in this message or in any files transmitted with this message is
always confidential and cannot be shared with any third parties without
prior written approval from Syncsort. This message is intended to be read
only by the individual or entity to whom it is addressed or by their
designee. If the reader of this message is not the intended recipient, you
are on notice that any use, disclosure, copying or distribution of this
message, in any form, is strictly prohibited. If you have received this
message in error, please immediately notify the sender and/or Syncsort and
destroy all copies of this message in your possession, custody or control.

--
For IBM-MAIN subscribe / signoff / archive access instructions, send email
to lists...@listserv.ua.edu <mailto: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: Estae and the Linkage Stack

[Blaicher, Christopher Y.]

It is a little tricky.  In the Assembler Services Guide there is a section 
called Linkage Stack Considerations in chapter 8, the last paragraph of which 
says:

When you issue a PR, the system automatically deactivates all ESTAE-type
recovery routines that were previously activated under that current linkage 
stack
entry.

What I was writing about was, being lazy and not wanting to allocate a save 
area, I used BAKR/PR to save and restore the registers when I called a 
subroutine to do some initialization including a setup of the ESTAE, and the 
ESTAE was not there when the program later abended. (I thought I knew 
everything and hadn't read the previous paragraph.)

So, what happened was the system very nicely setup my ESTAE in the subroutine, 
and very nicely deactivated it when I exited the subroutine.  Now, if I hadn't 
use BAKR/PR and done a real subroutine call, all would have been fine.

Chris Blaicher
Technical Architect
Mainframe Development
P: 201-930-8234  |  M: 512-627-3803
E: cblaic...@syncsort.com

Syncsort Incorporated
2 Blue Hill Plaza #1563
Pearl River, NY 10965
www.syncsort.com

Data quality leader Trillium Software is now a part of Syncsort.


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Joseph Reichman
Sent: Monday, June 12, 2017 6:24 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Estae and the Linkage Stack

Hi



I thought for the longest time that an ESTAE was associated with a Task.
Then I saw a thread with Chris Blaicher where the upshot as that a BAKR would 
deactivate it



I did a search on the archives but didn't come up with anything


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





ATTENTION: -

The information contained in this message (including any files transmitted with 
this message) may contain proprietary, trade secret or other confidential 
and/or legally privileged information. Any pricing information contained in 
this message or in any files transmitted with this message is always 
confidential and cannot be shared with any third parties without prior written 
approval from Syncsort. This message is intended to be read only by the 
individual or entity to whom it is addressed or by their designee. If the 
reader of this message is not the intended recipient, you are on notice that 
any use, disclosure, copying or distribution of this message, in any form, is 
strictly prohibited. If you have received this message in error, please 
immediately notify the sender and/or Syncsort and destroy all copies of this 
message in your possession, custody or control.

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