On Fri, 18 Oct 2024 23:41:23 -0700, Leonard Woren <[email protected]> wrote:
>>Jon Perryman wrote on 10/18/2024 8:26 AM: >> Task exit is the last thing performed by your task and it has no way >> of knowing if the parm has been freed or overlayed. > >any storage owned by the main task is easily still there when the ETXR runs, A pointer to storage doesn't magically keep that storage available in assembler and all storage has a life expectancy. Constants in a program that's use count reaches 0. A workarea that is freed before the task terminates. Using the inappropriate subpool. Multi-tasking requires you verify the method that guarantees storage availability for the time is will be used. > or the program design is in error. More often, people don't fully understand that storage lifecycle. It's surprising how many customer dumps involve storage lifecycle problems. >That makes no sense. The ETXR by definition is main task (IRB), so OK, I got the task wrong but regardless of the task, storage lifecycle is important even if the storage was managed and used from the same task. I've always relied upon abend recovery instead of ETXR. >> To call this a poor design tells me you need a refresher on >> multi-tasking because this is the only possible design for ETXR. > >Wow -- two incorrect claims in one simple sentence. No mention how I'm incorrect! All functionality within a task (including ETXR) should be controlled by a single passed parm. IBM could easily pass PARAM= pointer to ETXR but I believe they intentionally chose not to do so because of storage lifecycle problems. > I wrote my first >(re-entrant?) ATTACH in 1973. Other than IBM z/OS developers, there >aren't likely many people who understand all this better than I do. I'm sorry you felt insulted but not sorry I said it. You're the one not passing PARAM= when most ISV solved this type of problem long ago. To ask if you fully understand multi-tasking is a fair question. >How exactly does the ETXR get the attached task's parm? Oh, a non-PI >method. Got it. Most ISV's consider TCBFSA an undocumented Programming interface which is use in multiple products. Fully documented Programming Interfaces. are available (store R1 param= address from task startup into STCBUSER, use name token or ATTACH DISP=NO storing address into daughter STCBUSER) but you don't like these options which is your prerogative. >That said, since Jim Mulder suggested (non-PI) TCBFSA, I guess I'll go >with that approach. I'll put a comment in the source that if it >breaks, blame Jim. ;-) If TCBFSA breaks, you won't be the only one complaining. TCBFSA contains the first R13 pointer (18 fullwords). It's strongly recommended to use this as a standard savearea but as Jim said, it's your 72 bytes and do with it as you will. As for IBM documenting it, it may not actually be a savearea > Peter Relson's suggestion of STCBUSER. The main task could put its main > workarea >address in its _own_ STCBUSER? main workarea is ambiguous. I'm guessing you are referring to the workarea getmained for the top running CSECT's working storage. Certainly one way to approach this but most ISV's will have a CB specifically for the attached task. As for "in its_own_STCBUSER, storing in the parent STCBUSER avoids DISP=NO but only allows for 1 attached task. Alternatively, you could pass the address with other values in the PARAM= area and avoid DISP=NO by storing it during task init into the attached task's STCBUSER. The 3rd alternative involves using DISP=NO and storing from the parent into the child STCBUSER. > "A good systems programmer will sit around for > an hour trying to figure out how to write 1 line of code instead of 2." I suspect that for most, those days are long gone due to products like INTUNE where you optimize heavy use. >Charles Mills wrote on 10/17/2024 6:42 PM: >> A "user word" passed from the issuer of ATTACHX to the exit routine >> would have been a huge help. I don't see any elegant way of >> parametrizing ETXR. The elegant & flexible solution is a CB containing everything about that specific task and is easily accessible from various interfaces. You want parms for ETXR but isn't this task information equally useful to PRB's, SRB's, IRB's, CSECTS, AR mode and other interfaces. This is where R1 in the first savearea (as pointed to by TCBFSA) is important. is the elegant solution. R1-save by default contains the PARAM= specified in the parent through the attach macro. Alternatively, task init can easily allocate the CB and replace R1-save with the CB's address. R1-save should be sufficient but if you're greedy, you can R0, R2, R3 & more in the first savearea. >Not "a" workarea. Since it runs on the main task, and has to fiddle >with the main task's data if the subtask abended, I need to pass it >the main task's main workarea for multiple reasons. That workarea address can be included in the PARAM= area. > more concerned about lines of code and therefore understandability to the >next programmer. Any product that has a large number of TCB's will have implemented some form of this framework. You may call it process management, task management or ???. The concept is always somewhat similar. You have a task and access it through the task management data which contains information specific to the task. In this case, workarea that may only be needed for ETXR. >Jim Mulder wrote on 10/17/2024 9:21 PM: >> R14 to return is the only one that you need, and even that just points to >> the SVC 3 instruction in the CVT. Even if you don't read dumps, someone has to read the dump will thank you. For debugging purposes, you will want to retain registers with documented known values from attach. R1-save is the PARAM= address. R13-prev should be 0 so you know you reached the end of the savearea chain. R13-next should point to the next savearea or 0. R14-save is return address. R15-save is the entry point. > If I now understand this suggestion, the subtask parm through ATTACHX would >include the main task's workarea address, which would then be saved by >the subtask in its (system-provided) FSA, which the ETXR can easily >locate? "saved" should be "is automatically saved" because standard register save. Also remember that as you pointed out, ETXR runs in the parrent task and must use the TCB passed instead of PSATOLD. >Peter Relson wrote on 10/18/2024 6:31 AM: >> The suggestion of using a name/token is a good one, available for >> any authorization. There is a caveat. As pointed out, ETXR runs in the parent TCB. If name/token is created from attached task, then the name/token must be for the address space and the name must include the TCB address.
