ATTACH by an unprivileged application cannot change the authority and privileges of the address space. TSOEXEC passes the request to the Terminal Monitor Program (TMP), which sets the unauthorized tasks nondispatchable before attaching the authorized task. There is no provision for running authorized and unauthorized code in parallel.
Have you considered a solution involving two address spaces? -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 ________________________________________ From: IBM Mainframe Discussion List <[email protected]> on behalf of Steff Gladstone <[email protected]> Sent: Wednesday, March 6, 2019 12:01 PM To: [email protected] Subject: Re: RACF: Limiting update-authorization of a file to a particular application Although we have progressed with creating an program-controlled environment, we are still experiencing problems in this area. We have a COBOL routine whose purpose is to open a VSAM data set on the first call, perform I/O (read and write) on subsequent calls, and finally close the dataset on the final call. We want to force most users to update the VSAM dataset only via this COBOL program, allowing only privileged users (= system programmers) the option of updating the dataset using other programs or utilities. For this reason we opted to implement RACF program-control, as per Shmuel Metz's suggestion. The COBOL I/O routine is called by a fairly complex TSO/ISPF application. So we decided to communicate to the I/O routine via a subtask in order to simplify the environment (as per Walt Farrell's claim that a new TCB creates a parallel isolated environment for RACF). First we tried implementing it the "stupid" way, with COBOL calling REXX calling the COBOL I/O routine (via TSOEXEC, CALL, or LINKPGM - it didn't matter). We expected the call to REXX to create a new subtask. The RACF program control in fact worked well in this scenario, but (as expected) the COBOL I/O routine (with its working storage and DCB's) is reinitialized on each call and so we have to re-OPEN on each call and there is no continuity between read and write calls. Then we did the following: we wrote an LE-enabled assembler routine that attaches a subtask (also LE-enabled) on the first call. The subtask loads the COBOL I/O routine then waits for work. On every subsequent call to the assembler routine the subtask is posted and it calls the COBOL I/O routine and returns the results to the assembler routine and re-enters a wait till the next call. And so on, until the final call when the subtask terminates and is detached. This works ok for privileged users (i.e., the subtasking and I/O logic works fine, the COBOL I/O routine is not reintiaiized on each call, and of course there are no RACF issues). But for non-privileged users RACF issues the following error message just after the COBOL I/O routine is called by the subtask:: ICH418I CONDITIONAL ACCESS LIST FOR DATA SET output.dataset DID NOT GRANT AUTHORITY TO PROGRAM(S): EXEC CALL EXEC CALL This despite the fact that the COBOL I/O routine is executing under a separate subtask. Can anyone help us out here? Thanks in advance, Steff Gladstone On Thu, 21 Feb 2019 at 23:33, Walt Farrell <[email protected]> wrote: > On Thu, 21 Feb 2019 15:22:33 +0000, Seymour J Metz <[email protected]> wrote: > > >AFAIK it won't reset the dirty bit. It does isolate AC(0) from AC(1). > > Yes, it will, for that isolated parallel environment. > > -- > Walt > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to [email protected] with the message: INFO IBM-MAIN > ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
