Your AUTHxxx cmdproc runs under the parallel authorized TMP whilst all other tasks in the address space are STATUS STOPed.
The ESTAE environment established by the caller will NOT be invoked for any abends in the cmdproc running on the parallel task structure. To handle abends in the AUTHxxx cmdproc - it must establish its own recovery environment. You can read the documentation about IKJEFTSR in the TSO/E Programming Services manual for more information in this area. Rob Scott Lead Developer Rocket Software 77 Fourth Avenue . Suite 100 . Waltham . MA 02451-1468 . USA Tel: +1.781.684.2305 Email: rsc...@rs.com Web: www.rocketsoftware.com -----Original Message----- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Micheal Butz Sent: 28 August 2014 13:05 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Recovery routines ISPF is not part of the equation Is plain vanilla TSO The second program is loaded and balr'ed to The library is APF authorized My question is the abend occurs in a different environment then from where the estae(x) was established E.g XMEM authorized etc does the recovery rtn get control Thanks Sent from my iPhone > On Aug 28, 2014, at 1:27 AM, Jon Perryman <jperr...@pacbell.net> wrote: > > TSO CMDPGM is how your program was invoked from the ISPF display. How did > your program call the next program? Was it thru ISPEXEC SELECT PGM or > assembler LINK or ??? If it was ISPEXEC, then your problem is that ISPF is > setting an ESTAE. If it's thru LINK then maybe ISPF is intercepting the SVC. > > If the problem is ISPF setting the ESTAE then calling ISPEXEC CONTROL SUBTASK > CLEAR from the second program may resolve your problem. > > TSO is complicating your question and causing your confusion. TSO violates > the restriction when you run authorized programs when unauthorized libraries > are in the steplib/joblib/calllib concatenations. To ensure unauthorized > programs never have access to an authorized environment, TSO must take > extraordinary measures to make sure these programs never have access to an > authorized environment. You see this by the use of authpgm and authcmd. > > I bring this up as a WARNING because you somehow call another program from > under AUTHCMD authorized program. You must take extreme care not to allow a > program from an UNAUTHORIZED library otherwise you expose your entire system. > If you don't use standard call methods (e.g. LINK), then you have an exposure > that must be fixed. > > In TSO, authorized programs are executed under a special authorized task. > This will cause programs to run authorized to execute in another TCB. But for > your ESTAE, this is not specifically important. What's important is where the > called program executes versus your program. Set a slip for the abend to take > a dump. In the trace table, you estae and the the abend should have the same > TCB. If not, then TSO is probably at fault. If not, you can see who sets an > estae after your ESTAE. If ISPF is setting it, then You can look where your > both programs are running. If they are under the same TCB then maybe you can > see if which ISPF function is somehow setting the ESTAE.. > > Jon Perryman > > > > On Wednesday, August 27, 2014 3:02 PM, Micheal Butz <michealb...@comcast.net> > wrote: > > I want to accomplish to have complete coverage for my program >> By that I mean anytime I get an abend in any state I want my recovery >> routine to get control >> >> Sent from my iPhone >> >>>> On Aug 27, 2014, at 5:56 PM, Tony Harminc <t...@harminc.net> wrote: >>>> >>>> On 27 August 2014 16:48, Micheal Butz <michealb...@comcast.net> wrote: >>>> I have question I understand that an authorized command run under a >>>> different tmp >>> >>> Well, a different task structure. >>> >>>> Is that always meaning the same program while in problem state runs >>>> Under one tmp and when I switch to Supervisor under another >>> >>> No - it doesn't work that way at all. Once it's been decided that a >>> command will run APF authorized, it is dispatched under a different >>> task structure, while the unauthorized stuff is all status stopped. >>> If you are able to switch to supervisor state, you were authorized >>> by definition (or IBM will fix it PDQ!), so you won't be running >>> under the unauthorized branch. >>> >>>> If so I established my estae(x) In Problems state and I abended in >>>> supervisor state my recovery rtn wouldn't get control >>> >>> Well, sort-of. But it's both stronger and more subtle than that. > > ---------------------------------------------------------------------- > 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 ================================ Rocket Software, Inc. and subsidiaries ■ 77 Fourth Avenue, Waltham MA 02451 ■ +1 800.966.3270 ■ +1 781.577.4321 Unsubscribe From Commercial Email – unsubscr...@rocketsoftware.com Manage Your Subscription Preferences - http://info.rocketsoftware.com/GlobalSubscriptionManagementEmailFooter_SubscriptionCenter.html Privacy Policy - http://www.rocketsoftware.com/company/legal/privacy-policy ================================ ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
