In what way was your subtask authorized? Supervisor state? System key?
Did you avoid saving your registers in the save area provided in R13 when your attached program first got control, and restoring them from there and doing a BR 14 if you were terminating? Did you avoid all use of subpools 0-127 (which would be key 8)? Did you avoid invoking any programs or system services that might use subpools 0-127? These are just a few of the more obvious integrity pitfalls when trying to use an authorized subtask in an unauthorized address space. z/OS is not designed with the intention to easily allow safe coexistence of a mix of authorized and unauthorized subtasks below the initiator or STC task. So it can be a rather difficult thing to do without creating exposures that would allow the untrusted CICS application programs to gain authorization. Jim Mulder z/OS Diagnosis, Design, Development, Test IBM Corp. Poughkeepsie NY > From: "Anthony Thompson" <anthony.thomp...@nt.gov.au> > To: IBM-MAIN@LISTSERV.UA.EDU > Date: 10/19/2018 01:54 AM > Subject: Re: get ECSA key 7 storage under CICS > Sent by: "IBM Mainframe Discussion List" <IBM-MAIN@LISTSERV.UA.EDU> > > The SDSF SVC ran under SVC 109, one of those ESR (extended SVC > routing) routines. > > I once wrote a bunch of programs/menus that did RACF processing > under CICS, essentially duplicating the RACF ISPF panels, but > instead of using a magic SVC to authorise CICS application code, I > established an authorised CICS sub-task at CICS initialization (when > CICS code was still authorised). All the authorised processing > happened on the sub-task side, under the usual RACF rules. > > Ant. ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
