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
entries:
- B
- Restricted (blocked) instruction violation
- C
- Object validation failure
- D
- Unsupported interface (domain) violation
- J
- Job-description and user-profile authorization failure
- R
- Attempt to access protected area of disk (enhanced hardware storage
protection)
- S
- 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.