Changing to security level 40
Before migrating to level 40, make sure that all of your applications run successfully at security level 30. Security level 30 gives you the opportunity to test resource security for all of your applications.
Follow these steps to migrate to security level 40:
- Activate the security auditing function, if you have not already done so. The topic Setting up security auditing gives complete instructions for setting up the auditing function.
- Make sure that the QAUDLVL system value includes *AUTFAIL and *PGMFAIL. *PGMFAIL logs journal entries for any access attempts that violate the integrity protection at security level 40.
- Monitor the audit journal for *AUTFAIL and *PGMFAIL entries
while running all of your applications at security level 30. Pay particular
attention to the following detailed entries in AF type
- Object validation failure
- Unsupported interface (domain) violation
- Job-description and user-profile authorization failure
- Attempt to access protected area of disk (enhanced hardware storage protection)
- Default sign-on attempt
These codes indicate the presence of integrity exposures in your applications. At security level 40, these programs fail.
- If you have any programs that were created before Version
1 Release 3, use the CHGPGM command with the FRCCRT parameter to create
validation values for those programs. At security level 40, the system
translates any program that is restored without a validation value.
This can add considerable time to the restore process. See the topic Validation of programs being restored for more information about
program validation. Note: Restore program libraries as part of your application test. Check the audit journal for validation failures.
- Based on the entries in the audit journal, take steps to correct your applications and prevent program failures.
- Change the QSECURITY system value to 40 and perform an IPL.