Migrating from BASIC to ENHANCED program security mode

With ENHANCED-WARNING mode, RACF® ensures that programs accessing data sets through PADS, accessing SERVAUTH resources by programs, or running execute-controlled programs meet the added restrictions of ENHANCED mode. However, if they do not meet the added restrictions, RACF still allows the access if it would have worked in BASIC mode. This allows you to test your setup to make sure it is suitable for ENHANCED mode while continuing to operate like BASIC mode while you adjust your profiles.

Guideline: Use ENHANCED-WARNING program security mode as part of your implementation of ENHANCED program security mode.

When you start this migration, you will have some profiles defined in the PROGRAM class but probably none of them specify APPLDATA('MAIN') or APPLDATA('BASIC') as those specifications do not mean anything in BASIC program security mode. You probably do not have the IRR.PGMSECURITY profile defined in the FACILITY class, or else you have it defined but specified APPLDATA('BASIC').

To begin your migration:

Begin figuring out which programs you must define as MAIN or BASIC. You can do this by examining your DATASET and SERVAUTH profiles to see which ones have conditional access lists that specify WHEN(PROGRAM(program-name)). To simplify this task, consider using database unload (IRRDBU00) and looking for the type 0402 and 0507 records. (Refer to z/OS Security Server RACF Macros and Interfaces for the description of these records).
From the type 0402 records for DATASET profiles, select the ones that have DSACC_CATYPE=PROGRAM and find the program name in DSACC_CANAME. These programs are candidates for the MAIN or BASIC attribute.
From the type 0507 records for SERVAUTH profiles, select the ones that have GRCACC_CATYPE=PROGRAM and find the program name in GRCACC_CANAME. These programs are candidates for the MAIN or BASIC attribute.
For each program (for example, program Y) that you find, determine if users execute program Y, or if they execute some other program (for example, program X) that in turn executes Y. In the first case, you probably only have Y in the conditional access list, and you would define Y as a MAIN or BASIC program. In the second case, both X and Y are in the conditional access list, so you should define X as a MAIN or BASIC program.
For each of those programs, determine whether the program needs to be run in batch, TSO, or both. If the program only needs to be run in batch, you can define the program as MAIN. If program needs to be run in TSO or in both batch and TSO, you must consider how the users run the programs in TSO. If the users use the TSO/E TSOEXEC command to run the programs, or run them from another program that uses IKJEFTSR to invoke them, you can define the programs as MAIN. If this is not the case, you must define the program as BASIC or find a way for the users to invoke them through TSOEXEC or IKJEFTSR. If these are not possible, you might need to consider the more difficult option of redesigning the programs to work with IKJEFTSR.
After you gather your list of programs that you will define with the MAIN or BASIC attribute, use the RLIST command to determine whether you have the programs defined with specific profiles (such as PROGRAM XYZ) or if you have them defined with nonspecific profiles (such as PROGRAM XY* or PROGRAM **). If the programs have specific profiles, the profiles can be modified using the RALTER command to specify APPLDATA('MAIN') or APPLDATA('BASIC'). However, if you have protected the programs with nonspecific profiles, you must use the RDEFINE command to define a new specific profile for each of the programs you need to define as MAIN or BASIC.

Once these steps are complete you should:

Make a similar examination of IRRDBU00 output, looking at the records that indicate execute-controlled libraries:
- Type 0400 records with a DSBD_UACC value of EXECUTE
- Type 0402 records with a DSCACC_ACCESS value of EXECUTE
- Type 0404 records with a DSACC_ACCESS value of EXECUTE
Examine the programs in those libraries to see which you need to define as MAIN or BASIC, using similar criteria as used for PADS.
Look at the records that indicate execute-controlled programs,
- Type 0500 records with GRBD_CLASS_NAME of PROGRAM that have GRBD_UACC of EXECUTE
- Type 0505 records with GRACC_CLASS_NAME of PROGRAM that have GRACC_ACCESS of EXECUTE
Examine the programs in those libraries to see which you need to define as MAIN or BASIC.

When this is complete, you can switch to ENHANCED-WARNING mode to find out if you have any other changes that must be made. To switch to ENHANCED-WARNING mode:

Use the RDEFINE command to define IRR.PGMSECURITY profile in the FACILITY class, and specify an APPLDATA value other than ENHANCED or BASIC. For example:
```
RDEFINE FACILITY IRR.PGMSECURITY APPLDATA('ENHWARN')
```
Issue the SETROPTS REFRESH command to change modes.
```
SETROPTS WHEN(PROGRAM) REFRESH
```

To ease migration from BASIC to ENHANCED program security mode, the mode switch does not affect systems running any release earlier than z/OS® V1R4. It also does not affect jobs, started tasks, or TSO sessions that are already running. For this reason, you should IPL the system at least once while in ENHANCED-WARNING mode to ensure that you test any jobs, started tasks, and TSO users that started before you migrated from BASIC to ENHANCED program security mode.

While running in ENHANCED-WARNING mode, you might receive messages ICH427I or ICH430I to indicate the need for further necessary changes. After receiving the messages, making the relevant changes, and allowing a sufficient test period of running in ENHANCED-WARNING mode without getting further messages, you can switch to ENHANCED program security mode. To do this:

Modify the APPLDATA value for the IRR.PGMSECURITY profile by issuing:
```
RALTER FACILITY IRR.PGMSECURITY APPLDATA('ENHANCED')
```
Change modes by issuing:
```
SETROPTS WHEN(PROGRAM) REFRESH
```

Again, the mode switch does not affect systems running a release earlier than z/OS V1R4. It also does not affect any jobs, started tasks, or TSO sessions that are already running. So, again, you must IPL the system to fully implement the change. You should not have any problems as a result of this IPL, because you have already IPLed once in ENHANCED-WARNING mode and subsequently fixed any problems that caused RACF messages.

Guideline: If you have several systems, consider having a SPECIAL user logged on to TSO on one of them while you IPL to fix any unexpected problem that might arise.