No. Please see my other message. For security purposes, an application running under ISPF is ISPF, and the various mechanisms for running authorized TSO code will make ISPF nondispatchable for the duration.
-- 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:29 PM To: [email protected] Subject: Re: RACF: Limiting update-authorization of a file to a particular application One further question: Would use of IKJEFTSI/IKJEFTSR/IKJEFTST work here? I.e., provide an isolated eenvironment for RACF while maintaining continuity within the I/O routine without re-initializing its working storage on each call? On Wed, 6 Mar 2019 at 19:01, Steff Gladstone <[email protected]> wrote: > 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
