Permit me please to add a +1 to the defense of posting this question on the Assembler list. I am a huge opponent of calls for religious purity on mailing lists and fora. Sure, keep posts generally on-topic -- no national politics or general rants -- but if it is generally technically relevant, then welcome the discussion. The list is here to serve its members, not to be an exercise in technical purity.
I mean, if you want to be a religious purist, then a question about the operation of TRT has no place here. It's a machine instruction, not an assembler instruction. TRT behaves the same whether generated by HLASM or by keying hex into a debugger, so it is not assembler-language-specific. The assembler language is EJECT and LOCTR and USING. If I were interviewing an assembler language programmer I might expect the candidate to be fluent in ATTACHX. 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. Although you only mention reentrance. Do you just want to give it a work area? Why then not GETMAIN? 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. Charles -----Original Message----- From: IBM Mainframe Assembler List <[email protected]> On Behalf Of Leonard Woren Sent: Thursday, October 17, 2024 5:54 PM To: [email protected] Subject: Re: ATTACHX ETXR registers Tom Harper wrote on 10/17/2024 3:18 AM: > Leonard, > > This is likely posted to a list you didn’t intend, the assembler list. Since > the question isn’t about assembler but a z/OS macro, you might try posting to > IBM-MAIN. A distinction without much of a difference. I figured I'd try here first since everyone here is likely an assembler programmer, which is far from the situation with IBM-MAIN. > When I look at the doc for ATTACHX, it lists the contents of all registers > under the ETXR parameter. OK, thanks, I missed that this time around due to the discombobulated way that IBM presents standard, execute, and list forms completely separately, along with listing keywords in two different places. 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. > Since you have to change the code anyway, why not use a name/token to pass > your parm then you won’t need a hack? Because that would require the ETXR to obtain its own workarea and with the three N/T calls (create/retrieve/delete), we're looking at 5x as many lines of code. So I'll just have to split it out to another small dynamic area as I said. And BTW, N/T has always been primarily a way to circumvent poorly designed architecture. Keven Hall wrote on 10/17/2024 5:06 PM: > a Google search probably would have answered this one. Tried that first. No hits other than discussions of R13 and R14. Nothing at all regarding a re-entrant ETXR. /Leonard
