My fault I had inadvertently left Both EXTR and ECB on the attach My code as documented with just ECB= on the attach worked just fine
Thanks to Tony Hameric who helped me with This apologies to others On Nov 2, 2018, at 12:48 PM, Michael Stein <m...@zlvfc.com> wrote: >> Joseph Reichman <reichman...@gmail.com> >> I know system 23E is for invalid TCB it seems to me that TCB is valid >> could any confirm that the following is the correct sequence of step to >> terminate a TASK. > > A TCB is destroyed when the task terminates unless it was attached with > EXTR or ECB in which case it is destroyed when the DETACH is issued. > > Looking up the S23E > > https://www.ibm.com/support/knowledgecenter/SSLTBW_2.1.0/com.ibm.zos.v2r1.ieah700/m015090.htm > > During processing of a DETACH macro, the system found an error in the > input parameters. > > Register 15 contains a hexadecimal reason code that explains the error: > > Code Explanation > > 00 The protection key of the address does not match the key of the issuer > of the DETACH. > > 04 Access register 1 was nonzero for a caller in access register address > space control (ASC) mode. > > 08 The task control block (TCB) specified in the input parameter list > is not a subtask of the caller's TCB. > > I don't know which case you have as I don't know the value in R15 at > the time of the abend, but perhaps the above might give you some ideas. > > One possible reason for the R15 = 8 case other than just a bad TCB > address is that you've already issued the DETACH before and that TCB > has already been destroyed. > >> I have 4 tasks I do an ATTACH with ECB =, SYSECB is the ECB, I am >> using END_ECB I use to tell the subtask to return via BR 14 >> >> DETACH_LOOP DS 0H >> L R1,END_ECB >> POST (R1) Post it >> WAIT ECB=SYSECB >> MVI TASK_ADDR,X'00' >> DETACH TASK_ADDR >> LA R7,THREAD_LEN(,R7) Next >> BCT R6,DETACH_LOOP > > So END_ECB is for main to subtask notification (to terminate) and SYSECB > is the ECB specified in the ATTACH ECB= parm. > > And you stored the value in R1 from the ATTACH in TASK_ADDR. > > And you are not running AR mode (or at least AR1 is zero?). > >> In my code running under TESTAUTH I made a breakpoint after the wait >> ECB=SYSECB and I go directly to my recovery routine with a 23E makes me >> think it’s not the DETACH > > Is that the first time around the loop? > > Does TASK_ADDR point to a TCB? > > Look at the code generated by the assembler. Is it using R7 to base > your reference to TASK_ADDR or some other register (and thus always > using the same address...) > >> Not sure more so I posted the code if anyone code confirm the logic >> is right ? > > You didn't post enough (all?) of the code nor the R15 value at the S23E > abend point so it's not enough. The ATTACH along with the construction > of the R7 based storage areas are likely to be critical. If it's too > long for an email you could post it somewhere on the web and send a link > to the list. > >> Is your suggestion to use EXTR as opposed to ECB because you suspect >> the validity of the TCB and the TCB is passed to the exit in R1 > > The abend indicates a problem with the code. This needs to be fixed, > just changing to EXTR isn't fixing it. > > Also I wouldn't rush to use EXTR. The EXTR routine is asynchronous to > your main task (which it runs on and interupts) so the EXTR routine would > need a way to communicate with your main task too. I'd just use ECB on > the ATTACH. > >> More so the EXTR will get control after the subtask does a BR R14 > > Yes, but the EXTR routine then needs to communicate with the main routine. > Your main routine is NOT running while the EXTR routine is running but > but you don't know where the main routine is stopped. > > You would need to notify the main routine somehow that the EXTR had > happened. When the asynchronous exit routine (EXTR) exits your main > routine will then run (or continue waiting, or whatever it was doing). > > Unless you do something in the EXTR routine the main routine will never > know the EXTR routine ran... > >> Back to the EXTR when the exit (EXTR) does a BR 14 to z/os, z/os >> will resume executing my code in my clean up routine as besides task >> termination I have to release CSA storage among other things > > Your main routine will become dispatchable again however if it > was waiting it will remain waiting... > >> I still think I am going to need a ECB or actually 4 to say I’m >> done or else the main task might finish first looking at the registers > > Yes, with ATTACH ECB you need an end of task ECB for each task. > >> None have any info from main task or subtask Rob I’m not trying to >> complicate things >> >> But as I said the main task needs to know when things are done may have >> to store ECB Address in TCBUSER and have to go key 0 > > Your R7 workarea should be enough. Besides TCBUSER doesn't belong to you. > USER in this context means "not IBM use", so it's the site or organization > not a single programmer. There's only one TCBUSER (in each TCB). > >> If there was an easier way.... > > There is... > > We haven't seen your attach code, but you should be passing a > parm value in R1 to the subtask your are attaching. > > This could be your R7 area address. > > As Rob Scott <rsc...@rocketsoftware.com> said: > > r> (1) Design your own structure that describes your subtask so that > r> you can anchor your own control blocks, ECBs, pointers and flags in. > r> > r> (2) Mother task builds this structure for each and every subtask that > r> it ATTACHs and keeps a list of them. > r> > r> (3) Mother will then ATTACH daughter and wait for the daughter to > r> signal that it has started ok (maybe WAIT on a "started ECB") > r> > r> (4) After posting the "I am started" ECB the daughter waits for mother > r> to say "GO" > r> > r> (5) When mother is posted on the "I am started" ECB, it creates a > r> HOME level nametoken for the TCB, keyed on some known prefix and the > r> TCB address > > The nametoken is unneeded as you have an area both the parent and subtask > can address. This can hold additional ECBs as needed as well as other > information needed to communicate between the tasks. > > r> (6) Mother then posts the "GO" ECB for the daughter > r> > r> When the daughter terminates, the ETXR routine can lookup the > r> name/token to retrieve the address of the structure in (1). > > When the daughter terminates the termination ECB for that task in the R7 > area will be posted by z/OS end of task. The parent needs to be waiting > on all the end of task ECBs (plus possibly other ECBs). > > When the parent wakes it needs to figure out which ECB(s) are posted > and take appropriate action (DETACH for and end of task ECB). > > Keep in mind that once a subtask has terminated the parent task shouldn't > wait on the end of task ECB nor issue DETACH for it again. > > r> Mother can always supervise daughters thru the list of structures it > r> maintains in (1). > > exactly... > > ---------------------------------------------------------------------- > 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
