> 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
