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
