On Thu, 15 Aug 2019 at 23:33, Jim Mulder <d10j...@us.ibm.com> wrote: >> Is there a design reason the service takes a pointer rather than the STOKEN >> itself?
> The LOCASCB service originated in MVS/ESA SP3.1.0, around 1987. An > STOKEN is 64 bits, and we did not have 64-bit registers until 13 years later. Ah, makes sense... The first thing the PC routine does is SPKA <caller’s key> LM R14,R15,0(R1) SPKA 0 so I suppose a pair of 32-bit registers could have been used. But I agree that's not a very standard interface style. On Fri, 16 Aug 2019 at 05:51, Binyamin Dissen <bdis...@dissensoftware.com> wrote: > One wonders how the ability to pass the STOKEN in a 64bit register would help, > as the API to your routine passes it in storage - and your code would S0C4 > fetching it. No... I should elaborate. I have a routine that I'm updating, and there are both legacy and new callers of it. A legacy caller passes R1 -> an area of known size containing a fixed number of 31-bit pointers; standard OS-style arg list, but without a VL flag. There is spare, uninitialized space after the pointers. The new caller will somehow pass an STOKEN in addition to the existing arguments. I had thought to put a pointer to the STOKEN after the last legacy argument, and then pass that pointer to LOCASCB in the hopes that it would tell me if this really is a pointer to an STOKEN or is just uninitialized junk from a legacy caller. I won't S0C4 fetching the putative pointer, but anyone (my code or IBM's) who loads from where it points, may. So I can safely pass the actual STOKEN in the list, then pass its address to LOCASCB, and (assuming the chance of a random 8 bytes being a valid STOKEN is tiny) I'll know if this is a new or legacy caller. (I need to use the STOKEN in any case to find the ASCB, so there's no additional overhead.) Another approach would be to pass the STOKEN in a non-volatile 64-bit register. So if LOCASCB accepted the STOKEN in a register, I could just pass that in directly. As it is I have to store it somewhere and pass the address of that doubleword. Well many tricks are possible to manage this; having never had cause to use LOCASCB before I was just slightly surprised that one can't pass the STOKEN in a register. > If you were supervisor state and did not want to return an abend in such a > case, an FRR would work wonders. > > As you have a problem state requirement, you could use VSMLOC against the > address to avoid an 0C4. Yup - and it's not an integrity issue (TOCTTOU between VSMLOC and LOCASCB, because LOCASCB *is* checking correctly. I just wish *it* would do the VSMLOC if it won't take the STOKEN directly. Yeah, that's not free either... On Fri, 16 Aug 2019 at 10:21, Seymour J Metz <sme...@gmu.edu> wrote: > On Fri, 16 Aug 2019 at 09:16, Steve Smith <sasd...@gmail.com> wrote: > > I'm a bit puzzled about the original question. Using addresses of things > > is fundamental to how computers work. > > Using addresses of addresses is not. The OP's question was why the parameter > was an address of a word containing another address, rather than just taking > that other address directly as a parameter. Uh, no. You've imagined a level of indirection that I didn't suggest. Thanks for all the suggestions. Tony H. ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
