Peter Relson wrote on 10/18/2024 6:31 AM:
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.
Well, excuse me. Now I see why this list is almost dead. But since
at least some people don't have a problem with this being here, I'll
try to wind it up here because it's always difficult to move a thread
to a different list without it getting split up.
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.
Ok, point taken for future reference.
Charles Mills wrote on 10/17/2024 6:42 PM:
Oh, and yes, ETXR does seem to be poorly designed. A "user word"
that could be 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.
Right.
Although you only mention reentrance. Do you just want to give it a
work area? Why then not GETMAIN?
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.
Yeah, it's overhead, but surely ATTACHX already implies at least one
GETMAIN. How many times in a day do your subtasks end? If fewer than
a few thousand times a day then I don't think one more GETMAIN is
worth worrying about.
Not frequently enough to care about the execution overhead; more
concerned about lines of code and therefore understandability to the
next programmer.
Jim Mulder wrote on 10/17/2024 9:21 PM:
Although it is not current listed in the IKJTCB macro as a PI field,
there is TCBFSA, which contains the address of the save area that is
passed in register 13 to the ATTACHed program. You can use that save
area however you want. An ATTACHed program does not really need to
save and restore all of the registers. R14 to return is the only one
that you need, and even that just points to the SVC 3 instruction in
the CVT. So if you want to use some of that save area for
communicating with your ETXR by using TCBFSA in your ETXR to locate
it, that's OK with me.
OK, proofreading leads me back here to totally rewrite this part. 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?
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.
If only there were an "R" / "get locate" form of N/T... It only has
"get move".
If you're key 0 (or can get into key 0)
I only write APF code, so no problem there. ;-)
STCBUSER is "for you" since you're the issuer of the ATTACH.
Same problem as I mentioned above -- need DISP=NO / STATUS START to
make this work. Oh, are you saying the main task would put its
workarea address in its own STCBUSER? Ok, that would work and seems
simple enough. Thanks.
Many applications accomplish the goal by creating a table that has
information about each/every/all the tasks that they have attached
(identified by TCB address), including whatever data the ETXR needs
to do its thing. The ETXR looks through the table to find the TCB
address (which is input to the ETXR) and then continues. The ETXR
might locate this table based on some address space level name/token
or some other protocol that the application used.
The table exists. The problem is how to find it in the ETXR, using
only documented PI other than N/T. I have had to fix too many obscure
programming errors due to incorrect usage of N/T. I take heat from
the product principal developer when doing non-PI things.
Jon Perryman wrote on 10/18/2024 8:26 AM:
On Thursday, October 17, 2024 at 05:54:46 PM PDT, Leonard Woren
<[email protected]> wrote:
Reviewing it, it seems that ETXR is in the running for the>
worst-designed interface in z/OS. No possible way to pass a parm
to> the 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. 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.
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.
That makes no sense. The ETXR by definition is main task (IRB), so
any storage owned by the main task is easily still there when the ETXR
runs, or the program design is in error.
Of the possible designs, the most straight forward is to create a CB
for the attached task (retained for the life of the task) and pass
it through the ATTACH parm. If at the start of your task, you
properly saved your registers, then the task can always access it
through TCBFSA (first save area for the TCB) => R1 => attach parm.
How exactly does the ETXR get the attached task's parm? Oh, a non-PI
method. Got it.
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. ;-)
Oh, wait. I had to back and revise my response to Peter Relson's
suggestion of STCBUSER. The main task could put its main workarea
address in its _own_ STCBUSER? If that's correct, then I can do that
and it's all very simple, which is my objective. But the TCBFSA
approach is more general, and can be used if I ever accidentally have
to write some non-authorized program.
An MVT systems programmer, one of my role models as a student at UCLA
in the 1970s, said that "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 hope nobody says this is off-topic for ASSEMBLER-LIST -- as far
as I remember, he only wrote in assembler.
Charles Mills wrote on 10/18/2024 5:25 PM:
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?
Ok, you initially got the same misunderstanding regarding the STCBUSER
suggestion as I did. Yes, you are correct if you're considering the
subtask's STCBUSER. That's why I mentioned that DISP=NO would be
required. But upon further thought, I realized that the suggestion
was probably to use the main task's STCBUSER, which would not have
this problem.
/Leonard
