Well, that's a good point. A supervisor state or system key program could specify DISP=NO on ATTACH so that the attached task could not run and terminate until the attacher sets STCBUSER or storage pointed to by TCBFSA, and then does ATTACH DISP=RESET. For a problem program, the only thing that can set something in storage created by ATTACH before the attached task can run is ATTACH itself.
Jim Mulder -----Original Message----- From: IBM Mainframe Assembler List <[email protected]> On Behalf Of Charles Mills Sent: Friday, October 18, 2024 8:25 PM To: [email protected] Subject: Re: ATTACHX ETXR registers Is there a potential race condition with STCBUSER? It is not available to the ATTACHX issuer until the ATTACHX completes -- or am I missing something? -- and potentially the ETXR code could run before the ATTACHX returned to the caller. Am I correct? Charles -----Original Message----- From: IBM Mainframe Assembler List <[email protected]> On Behalf Of Peter Relson Sent: Friday, October 18, 2024 6:31 AM To: [email protected] Subject: Re: ATTACHX ETXR registers And I, on the other hand, would contribute a huge "minus one" to posting on this forum (it does seem to violate the tenets of this forum). This forum is not for questions about z/OS system services that you just happen to invoke in assembler language. If you want the best audience who can answer a question about an interface, then the assembler list is the wrong place. And surely you want the best audience when seeking help. Fortunately for the OP many of the same folks watch both and no one minds much answering from either place. I do agree that it would have been nice to be able to pass a "parameter" that the exit routine could be given. STIMER has this same flaw; it was done better with STIMERM. The suggestion of using a name/token is a good one, available for any authorization. If you're key 0 (or can get into key 0) STCBUSER is "for you" since you're the issuer of the ATTACH.
