On Sun, 1 Mar 2026 00:32:45 +0000, Farley, Peter wrote: >Sure, as long as the called program Is prepared to access the Rexx variable >argument in which to read or return the address value. Alternatively, I >suppose you could try to set the return code to the address of the obtained >storage, but I am not sure the whole value would survive unless Rexx NUMERIC >DIGITS was high enough. Might be worth a try though. > Pass it as hex using REXX conventions and return it as a function result.
But better, since neither REXX nor HLASM uses null-terminated strings and all EBCCDIC characters are valid, imply pass the binary values. C2X(), C2D(), STORAGE(), etc. may be your friends here. There are ICSF examples in SAMPLIB interesting because they rely on the called program modifying the passed arguments. The CALL macro has no rule against this. Alas, BPXWDYN <https://www.ibm.com/docs/en/zos/3.2.0?topic=conventions-conventional-mvs-parameter-list> reserves NUL. I believe this is not generally true of REXX. I would *never* rely on the persistent address of a REXX string because the undocumented behavior of REXX storage management night move it during garbage collection. >Using ADDRESS MVS or ADDRESS LINKMVS doesn’t keep the executed program loaded. > Ideally you would like to have something like ADDRESS KEEPMVS in place of >LINKMVS or MVSKEEP in place of MVS (or any better naming convention you >prefer, I just made those names up in the moment). > I've also wished for a truly concurrent ATTACH, but never coded it. It would need to copy the parameters before return, again because ofREXX storage management. -- gil ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
