Unless things have changed, in order for RACF program-controlled dataset access to work, all programs loaded into the address space must be covered by a RACF PROGRAM profile. Typically one sets up a profile that will cover all modules in all system datasets that might be loaded in the TSO environment -- for example a PROGRAM ** profile with UACC(READ) with many group members of the form "datasetname//NOPADCHK" for each datasetname in the Linklist and each datasetname in the STEPLIB of installation-defined TSO logon PROCs from which a load module might be loaded into the TSO address space. These must all be libraries that the normal TSO users cannot modify, as you are implicitly saying all the programs in all these libraries can be trusted to not do anything nefarious, so that when PROG1 opens the WHEN-restricted dataset, you don't have to worry that you might also be allowing one of the other programs also in memory that shouldn't have access to that dataset to have access. Note that the PROGRAM ** profile must be appropriately modified whenever the names of datasets in link list or STEPLIBs in TSO logon procs change.
I think you may then have to also set up a specific PROGRAM profile for "PROG1" as well, but it would only need a group member for the actual dataset that contains PROG1 RACF PROGRAM profiles are kept in memory, so any changes to PROGRAM profiles requires a RACF REFRESH before changes take effect. If a TSO user explicitly loads a program from one of his own libraries so that it is not covered by a PROGRAM profile, that will break the program-controlled environment (and you want it to), and the user will have to logoff and logon to restore a program-controlled environment. Putting PROG1 in the AUTHPGM list for TSO says it may run "authorized" and use restricted and dangerous Operating System functions (is this something you really want for a COBOL program?) and has nothing to do with whether a program-controlled environment for RACF Program-Controlled dataset access is maintained. Joel C. Ewing On 2/17/19 10:05 AM, Steff Gladstone wrote: > Ok. We have been playing around with program control. If PROG1 (a COBOL > program incidentally) is to be allowed exclusively to update file MY.FILE, > then we: > > 1. introduced PROG1 into the list of programs in AUTHPGM in member IKJEFT00 > 2. Executed command RDEFINE for the file (and additionally for the LE > runtime libraries - not sure if necessary) and PERMIT 'MY.FILE' > WHEN(PROGRAM(PROG1)). > > The results were: > > 1. Executing PGM=PROG1 in batch -> good results > > 2. Executing a REXX procedure under PGM=IKJEFT01 in batch -> good results > (when invoked either by CALL 'lib(PROG1)' or SELECT PGM(PROG1) > > 3. Executing a REXX procedure in TSO foreground invoking program with > CALL 'lib(PROG1)' -> receives the following error: > > ISPS118L Service not invoked. A valid ISPF environment does not exist. > > > 4. Executing a REXX procedure in TSO foreground invoking program with > SELECT PGM(PROG1) -> receives the following error: > > IKJEFTSR interface error > Authorized program 'PROG1'. Return code=20 Reason code=40. > > Current dialog statement: > SELECT PGM(PROG1) > > We gather that we are running into the "dirty bit" problem that has been > documented in various forums. What can we do to get around this (we need > the program control feature under TSO foreground as well)? > > Thanks in advance, > Steff Gladstone > > On Thu, 7 Feb 2019 at 18:06, Seymour J Metz <[email protected]> wrote: > >> Program control, but pay close attention to the restrictions. >> >> >> -- >> Shmuel (Seymour J.) Metz >> http://mason.gmu.edu/~smetz3 >> >> ________________________________________ >> From: IBM Mainframe Discussion List <[email protected]> on behalf >> of Steff Gladstone <[email protected]> >> Sent: Thursday, February 7, 2019 6:37 AM >> To: [email protected] >> Subject: RACF: Limiting update-authorization of a file to a particular >> application >> >> Greetings, >> >> >> >> We have an TSO application for end-users that allows them to update certain >> VSAM and PDS files. In order for them to update these files we of course >> have to give their users update-authorization under RACF for those files. >> >> >> >> We want to limit their ability to update the files only via the particular >> TSO application (or via a particular I/O routine used by the application) >> and not via any other application program or IBM utility (e.g., IEBCOPY, >> ISPF on-line edit or utilities, etc.). >> >> >> >> How can we define the RACF authorizations in such a way as to limit the >> end-users' update capabilities to the application (or to a particular I/O >> routine) alone? Would the same (or similar) definitions work for a site >> using Top Secret instead of RACF? >> >> >> >> Thank you in advance, >> Steff Gladstone >> > -- Joel C. Ewing ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
