Paul D wrote <snip> "To run an SRB routine in a different address space from the scheduling code, the SRB routine must be either in a different program that is accessible from the target address space, or in the common storage together with the scheduling code." </snip>
This is nothing more than a statement that you cannot have the SRB routine be in the private storage of the address space of the scheduler in such a case. The SRB routine has to be addressable in the target address space and thus can be in the private storage of the target address space or can be in common storage. If you want it in private storage, it is up to you go get it loaded there. Steve B wrote <snip> I have the code to turn on the JSCBAUTH however it is a SVC </snip> I sure hope no one lets you install that SVC on a system that anyone cares much about. Except in a vanishingly small percentage of cases, this is an extreme system integrity violation. Binyamin wrote <snip> What is a "non-authorized" address space? </snip> Everyone I know would consider that to be an address space for which the jobstep program is not both linkedited AC=1 and gotten from an APF-authorized concatenation, and is not a system key address space (as could be defined in such places as the program properties table). Starting (and even running) in problem state and user key is not enough for the characterization. The user program in a non-authorized address space cannot switch itself to an authorized state. Of course within a non-authorized address space at various points code runs authorized (such as after an SVC or a non-space-switching PC that is defined to execute in supervisor state and/or a system key). Peter Relson z/OS Core Technology Design ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
