Securing files against overrides

On occasion, you may want to prevent the person or program that calls your program from changing the file names or attributes you have specified. You can prevent additional file overrides by coding the SECURE(*YES) parameter on a file override command for each file that needs protection. This protects your file from overrides at lower call levels, the activation group level, and the job level.

The following shows an example of a protected file:

Override 1 OVRPRTF FILE(PRINT1) SPOOL(*NO) Override 2 OVRDBF FILE(NEWEMP) TOFILE(OLDEMP) + MBR(N67) CALL PGM(CHECK) Program CHECK Override 3 OVRDBF FILE(INPUT) + TOFILE(NEWEMP) MBR(N77) + SECURE(*YES) CALL PGM(EREPORT) Program EREPORT (NEWEMP and PRINT1 are opened.) Override 4 OVRDBF FILE(INPUT) + TOFILE(NEWEMP) MBR(N77) CALL PGM(ELIST) Program ELIST (OLDEMP and PRINT1 are opened.)

When the example calls program EREPORT, it attempts to open the files INPUT and PRINT1. EREPORT actually opens file NEWEMP, member N77. Because override 3 specifies SECURE(*YES), the system does not apply override 2. When the example calls program ELIST, it also attempts to open the files INPUT and PRINT1. ELIST actually opens files OLDEMP, member N67. Because override 4 has the same name as override 3 and is at the same call level as override 3, it replaces override 3. Thus, the file is no longer protected from overrides at lower call levels, and the system applies override 2 for program ELIST.

PRINT1 is affected only by override 1, which is in effect for both programs EREPORT and ELIST.