Using System Security (QSecurity) system value

You can choose how much security you want the system to enforce by setting the security level (QSECURITY) system value.


Specify level of security to be enforced on the system.
How To:
WRKSYSVAL *SEC (Work with System Values command) or Menu SETUP, option 1 (Change System Options)
Journal Entry:
Before changing on a production system, read appropriate section on migrating from one level to another.

Levels of security

The system offers five levels of security:
No system-enforced security
Note: You cannot set the system value QSECURITY to security level 10.
Sign-on security
Sign-on and resource security
Sign-on and resource security; integrity protection
Sign-on and resource security; enhanced integrity protection.

Your system is shipped at level 40, which provides sign-on and resource security and provides integrity protection. For more information, see Security level 40.

If you want to change the security level, use the Work with System Values (WRKSYSVAL) command. The minimum security level you should use is 40. Security level 40 and 50 provide the system integrity protection required to run a secure server. Security levels 30 and below do not provide the integrity protection required for a secure operating environment. The change takes effect the next time you perform an initial program load (IPL). Table 1 compares the levels of security on the system:

Table 1. Security levels: function comparison
Function Level 20 Level 30 Level 40 Level 50
User name required to sign on. Yes Yes Yes Yes
Password required to sign on. Yes Yes Yes Yes
Password security active. Yes Yes Yes Yes
Menu and initial program security active. Yes1 Yes1 Yes1 Yes1
Limit capabilities support active. Yes Yes Yes Yes
Resource security active. No Yes Yes Yes
Direct access to all objects using object address. Yes No No No
User profile created automatically. No No No No
Security auditing capabilities available. Yes Yes Yes Yes
Programs that contain restricted instructions cannot be created or recompiled. Yes Yes Yes Yes
Programs that use unsupported interfaces fail at run time. No No Yes Yes
Enhanced hardware storage protection is enforced for all storage. No No Yes Yes
Library QTEMP is a temporary object. No No No No
*USRSPC, *USRIDX, and *USRQ objects can be created only in libraries specified in the QALWUSRDMN system value. Yes Yes Yes Yes
Pointers used in parameters are validated for user domain programs running in system state. No No Yes Yes
Message handling rules are enforced between system and user state programs. No No No Yes
A program’s associated space cannot be directly modified. No No Yes Yes
Internal control blocks are protected. No No Yes Yes 2
When LMTCPB(*YES) is specified in the user profile.
At level 50, more protection of internal control blocks is enforced than at level 40. See Preventing modification of internal control blocks.

Default special authorities

The system security level determines what the default special authorities are for each user class. When you create a user profile, you can select special authorities based on the user class. Special authorities are also added and removed from user profiles when you change security levels.

These special authorities can be specified for a user:
All-object special authority gives a user authority to perform all operations on objects.
Audit special authority allows a user to define the auditing characteristics of the system, objects, and system users.
System configuration special authority allows a user to configure input and output devices on the system.
Job control special authority allows a user to control batch jobs and printing on the system.
Save system special authority allows a user to save and restore objects.
Security administrator special authority allows a user to work with user profiles on the system.
Service special authority allows a user to perform software service functions on the system.
Spool control special authority allows unrestricted control of batch jobs and output queues on the system.
You can also restrict users with *SECADM and *ALLOBJ authorities from changing this security related system value with the CHGSYSVAL command. You can specify this restriction in the System Service Tools (SST) with the "Work with system security" option.
Note: This restriction applies to several other system values.
For details on how to restrict changes to security system values and a complete list of the affected system values, see Security system values.

Table 2 shows the default special authorities for each user class. The entries indicate that the authority is given at security levels 10 and 20 only, at all security levels, or not at all.

Table 2. Default special authorities for user classes by security level
Special authority
User classes
*ALLOBJ All 10 or 20 10 or 20 10 or 20 10 or 20
*AUDIT All        
*IOSYSCFG All        
*JOBCTL All 10 or 20 10 or 20 All  
*SAVSYS All 10 or 20 10 or 20 All 10 or 20
*SECADM All All      
*SERVICE All        
*SPLCTL All        
Note: The topics User class and Special authority provide more information about user classes and special authorities.


At security level 30 the system does not automatically give users access to all resources. At lower security levels, all users are given *ALLOBJ special authority.

Security level 30 is not a secure level to run your production system. At security level 30 and below, users can directly call system level interfaces that are not intended to be directly called by user applications. In addition, user applications can access internal control blocks and object contents directly using an address. This is a security and integrity exposure. At security level 30, the integrity protection mechanisms are not activated to the same level as security level 40 and 50. Therefore, security level 40 or higher is strongly recommended.

Security level 40 and 50 provide significant integrity protection that is not available on security level 30 and below. To run a secure server, you must run at security level 40 or 50. Security level 40 and 50 are similar in capabilities. This was not always the case but, over time, the capabilities that were initially available in security level 50 have been moved into the security level 40 support. There are still some differences between 40 and 50. The differences are mostly internal processing of buffers and control blocks plus the restrictions on how messages can be sent within a job, see Restricting message handling. Running security level 50 provides the most secure level to run your server.