Post your code - in entirety. On Thu, 28 Aug 2014 08:05:23 -0400 Micheal Butz <michealb...@comcast.net> wrote:
:>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 -- Binyamin Dissen <bdis...@dissensoftware.com> http://www.dissensoftware.com Director, Dissen Software, Bar & Grill - Israel Should you use the mailblocks package and expect a response from me, you should preauthorize the dissensoftware.com domain. I very rarely bother responding to challenge/response systems, especially those from irresponsible companies. ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
