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.
Jim Mulder z/OS Diagnosis, Design, Development, Test IBM Corp. Poughkeepsie NY > I'm a bit puzzled. This service takes a pointer to an STOKEN, and returns > an ASCB address. Or a return code indicating that the STOKEN is invalid or > obsolete. So if I am passed an STOKEN pointer by my caller, this seems like > the right service to tell me if this is pointing to a valid and current > STOKEN, which it does. But if I pass in a bogus *pointer*, e.g. to some > random address that is fetch protected from me (I'm running user key, > problem state) then the PC routine code abends, because it's done the right > thing and assumed my key before trying to reference the supposed STOKEN. > > So... Although the description says "Abend codes: none", in fact it can > S0C4. (Yeah, I know this means that LOCASCB itself generates no abend > codes.) So it seems I have to check the validity of the pointer before I > pass it in. I agree such a requirement makes sense in most cases, but here > I am in a constrained environment with no work area, so I have no obvious > way of passing in the STOKEN itself for checking without having a pointer > to it. Is there a design reason the service takes a pointer rather than the > STOKEN itself? ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
