It is often not necessary to use ATTACH(X) DISP=NO and ATTACH(X) DISP=RESET to 
build the relevant information into a "task table", depending on your needs.
Imagine that you are trying to have the ETXR "do whatever cleanup is needed" 
for the attached task, and that there might be no such cleanup needed if the 
only thing the task did was return immediately.

For such a case, you could implement a protocol by which both the attacher 
(right after the attach) and the attachee (upon entry) both "fill in the table 
entry" with the tcb address according to whatever protocol you choose (probably 
including passing the address of the table entry as a parameter to the 
attachee). An ETXR getting control and finding no entry for the relevant tcb 
address might know that there was nothing to do. If there is an entry, the ETXR 
could indicate "done" if that was helpful to the attacher. This is all just to 
cover the case where the task runs to completion before the attachee runs 
further. The protocol could obtain serialization (ENQ, LOCAL lock, etc) if it 
felt important to do so.

Not knowing what the OP wants the ETXR to do, only generalities can be stated.

Regarding TCBFSA, be aware that you will not have a non-0 TCBFSA unless you 
have (the default) SVAREA=YES in effect.
So while Jim Mulder says he doesn't mind your using it, you should really be 
asking that it be designated as a programming interface before using it, where 
such designation would include a comment about when it was valid to use as an 
address and when it was not. The current comment says "Address of the first 
problem program save area". At a minimum, that would be clarified to "When not 
zero, address of the first problem program save area". Probably adding 
something like "when the task first gets control, register 13 is set to this 
value". Agreement to designate TCBFSA as PI would be plenty; no one would make 
you wait for a version of the macro or book to have that designation. Having a 
customer requirement asking for this would be nice.

Peter Relson
z/OS Core Technology Design

Reply via email to