AS400 System Administration Training Blog

System Values

System values (*SYSVAL) are AS/400 attributes that let each installation customize the machine to the organization's needs and specifications. Some system values control system performance; others define security levels; yet others simply provide defaults to command options that are unspecified.

**Note : There are total 150 system values as following in the iSeries machine.

Below are the few system values
QMODEL - Holds the system model number and can't be modified.
QSRLNBR - Contains the preloaded serial number.
QMAXSIGN  - Specifies how many invalid sign-on attempts are allowed.
QMAXSGNACN - Specifies the action to take when the QMAXSIGN limit is reached.
QSECURITY  - Indicates the security level; valid levels are 10, 20, 30, 40, and 50.

The system value QTIME contains the system time of day. It comprises three other system values, QHOUR (based on a 24-hour clock), QMINUTE, and QSECOND

The system value QCURSYM determines the currency symbol, which is country dependent; for example, the yen, lira, franc, and dollar use different symbols.

The following are complete list of system values
Click on the image to zoom

Click on the image to zoom

Click on the image to zoom

Click on the image to zoom

AS400 System Security Levels

Level 10: There is no user authentication, or resource protection. No password is required to sign on. This is no longer supported. (Discontinued in OS/400 Version 4, Release 2)

Level 20: Password - User authentication through user profile and password checking; no resource protection. 

(Resource security means object security that provides protection for system objects like programs, files, and libraries, and the data within these objects.)

Level 30: Password and Resource - User authentication and resource protection. Users require authority to access objects.

Level 40: Password, Resource and Operating System Integrity - User authentication, resource protection, and machine interface protection.

Level 50: Password, Resource and enhanced Operating System Integrity - User authentication, resource protection,and machine interface protection. Security level 50 is intended for AS/400 systems with high security requirements and to meet C2 security requirements.

The iSeries are shipped with a default setting of 40. The system can only be set to one level for all users at any given time. The recommended setting for a secure iSeries machine is 40. This level of security is highly recommended for those locations that have complex processing that includes non-IBM system interfaces, network connectivity and processing of external tapes. One may think using 50 would be even better because it would be even more secure. This statement is true, however, there is a 5 to 15 percent performance decrease in going from level 40 to 50 and also a level of 40 provides an adequate level of security for typical companies.

User Classes

There are five user classes which are hierarchical in authority. The classes represent different roles in the AS400 environment. These are convenient ways to assign the special authorities listed above to different types of users. A higher class can perform all the functions of a lower class; for example, *SECOFR includes the privileges of *SECADM by default. The following are the five user classes.

1. *SECOFR     Security Officer
2. *SECADM     Security Administrator
3. *PGMR     Programmer
4. *SYSOPR     System Operator
5. *USER    End User


In AS/400 terminology, an authority is the permission to access an object. The object owner and the security officer (or other *ALLOBJ users) can grant or revoke authority to an object. 

 Special Authorities
All security systems have special user privileges for certain security and system administration functions. Special authorities allow certain users to administer AS/400 security and system tasks. There are eight special authorities. These special authorities are not hierarchical.

*ALLOBJ     All object authority is granted for accessing any system resource

*AUDIT     Allows the user to perform auditing functions

*JOBCTL     Allows manipulation of job and output

*SAVSYS     Used for saving and restoring the system and data without having explicit authority to objects queues and subsystems

*SECADM     Allows administration of User Profiles and Office

*SERVICE     Allows access to special service functions for problem diagnosis

*SPLCTL     Allows control of spool functions

*IOSYSCFG Allows change of system configuration

Specific authorities     
Specific authorities are further divided into 2 types.   
1.    Object Authorities
2.    Data Authorities

It is important to understand the difference between authority to an object and authority to the data in the object. Operations such as moving, renaming, saving, or deleting apply to the object as such. It is possible to have authority for these operations without having access to the data stored in the object. Likewise, one can have full access (read, write, update, delete, execute) to the data in an object without having full authority to manipulate the whole object.

1.    Object Authorities :
There are 6 object authorities used in AS/400.Those are as follows.
a.    *OBJOPR        ( Object Operational )
b.    *OBJEXIST        ( Object  Existence )
c.    *OBJMGT        ( Object Management )
d.    *OBJALTER        ( Object Alteration )
e.    *AUTLMGT        ( Authorization List Authority )
f.    *OBJREF        ( Object Reference )

2.    Data Authorities :
There are 5 data authorities used in AS/400.Those are as follows.
a.    *READ        ( Read Data )
b.    *ADD            ( Add Data )
c.    *DLT            ( Delete Data )
d.    *UPD            ( Change Data )
e.    *EXECUTE        ( Run a Program )

The following authorities are independent (not hierarchical). For some operations a combination of authorities is required:

*OBJOPR:     The object operational authority controls the use of an object and the capability to look at the description of the object. It is needed to open a file andtherefore usually assigned in combination with the desired data rights.

*OBJMGT:     The object management authority controls the move, rename, and change attribute functions for object, and the grant and revoke authority
functions for other users or groups.

*OBJEXIST: The object existence authority controls the delete, save, restore, or transfer ownership operations of an object.

*AUTLMGT: This authority is needed to manage the contents of an authorization list associated with the object. This is a specialized security authorization that is not usually grouped with the other seven object authorities.

*OBJALTER: This authority is needed to alter the attributes of data base files
 and change the attributes of SQL packages.

*OBJREF:     This authority is needed to specify a data base file as the first level in a referential constraint.

*READ:     Controls the ability to read data from the object.

*ADD:     Controls the ability to insert a new entry (such as a new record in a file)
into the object.

*UPDATE:     Controls the ability to modify existing entries in the object.

*DELETE:     Controls the ability to remove existing entries (for example, records) in the object. To delete the whole object requires *OBJEXIST authority.

*EXECUTE:     Controls the ability to run a program, service program, or SQL package, and to locate an object in a library or a directory. Some common
combinations of authorities have been given special names as an
abbreviated form. For example, *USE is the combination of *OBJOPR, *READ, and *EXECUTE.

*ALL         Allows unlimited access to the object and its data

*CHANGE     Allows unlimited access to the data in the object

*USE         Allows data in the object to be read

*EXCLUDE     Allows no access to the object or its data

*PUBLIC Authority 
Public authority is the default authority for an object. It is used if users do not have any specific (private) authority to an object, are not on the authorization list (if one is specified) for the object, or their group(s) has no specific authority to the object.


User Profiles

User Profiles
A user profile is an object that identifies a particular user or a group of user to the AS/400 system. The user is known in the system by user profile name. When a workstation signs on, the user id is used to find the user profile setting. The password is defined in the user profile. All AS/400 system security functions rely on the user profile to describe each user. The user profile identifies the authorities to that user.

User Profiles contain information describing a system user, that user's privileges and limitations when using the system, and lists of objects the user owns or is authorized to use. For objects owned by a user, the profile also contains lists of other users' authorizations to those objects.

Group Profiles
A group profile is used to provide the same profile for a group of users. This eliminates the need to assign the authority to each user individually.

A User Profile may be linked to a group profile. This allows all the members of the  group to share common attributes, common access to selected objects, and common ownership of objects.
A group profile is implemented as a user profile; that is, it is created just like a user profile, and when granting authority, the AS/400 does not treat groups any differently than user profiles. The two uses may be intermixed. For easy management it is better that user and group profiles be used as separate entities. One way to enforce this is to set the group profile password to *NONE. This prevents any sign on to the profile.

User Profile Management:
Create User Profile :

The create User Profile (CRTUSRPRF) command identifies a user to the system and allows you to customize the way the system appears.

Delete User Profile

The Delete User Profile (DLTUSRPRF) command allows a user to delete a user profile from the system. The User Profile cannot be deleted if a user is currently running under the profile
The Change User Profile (CHGUSRPRF) command changes the values specified in a user profile.  The password validation rules are not verified by the system when a password is changed by this command. 

The Work with User Profiles (WRKUSRPRF) display shows you a list of user profiles that you have authority to use. Only someone with either system security officer or security administrator authority can set up these user profiles which determine what system displays and functions each person is authorized to use.  If you do not have proper authority, only your user profile will be displayed.            
You can do the following with WRKUSRPRF command
  1. Create a user profile
  2. Change a user profile
  3. Copy a user profile
  4. Delete a user profile
  5. Display a user profile
Note: You must have one or more special authorities (such as *SECADM) to perform above operations.

Managing OUTQ`s and SPOOL Files

All the spool files created by the user as well as system goes into a OUTQ. QPRINT is the default outq of the system. Administrator can set default outq for each user so that the spool files created by that users goes to that outq only.

To work with all the outq use following command,

The Work with Output Queues (WRKOUTQ) command allows the user to display and work with either the overall status of all output queues or all output queues that match the qualified generic name specified and to which the user is authorized, or the detailed status of a specific output queue. The status of the queues may change while the command is being run.

To clear the outq use the following command  ,
CLROUTQ  < outq name >

The Clear Output Queue (CLROUTQ) command removes spooled files from the specified queue. The Clear Output Queue (CLROUTQ) command removes all spooled files on the specified output queue if they are waiting to be written on an output device, including files that are in the hold state. Spooled files that are currently being produced by programs or that are being written to an output device are not removed from the queue.

To work with spool files created by particular user use following  command,
WRKSPLF  < user id >

The Work with Spooled Files (WRKSPLF) command displays a list of all the spooled files on the system or a selected list from them. You can choose to change, hold, delete, display, or release any or all of the entries that are displayed. 

You can do following activities with the spool file,

User can change the outq of the spool file.Spool file is assign to a printer to print.User can print the spool file pagewise as per the the requirement.

Message Handling

Message is a means of communication between system and user. These are system messages & User Message. 

In User Messages users can send their own messages.
System Messages and Users Messages are put in the user’s message queue. Messages may be
a) Informational (No reply Needed)
b) Inquiry (Reply Needed)

Even users can send messages to each other using following commands,

By default every message given to the administrator goes into QSYSOPR message queue. Administrator can change this default message queue.

To see the messages of any message queue use following command,

To check system operators message queue use,

System Operations

An administrator continuously requires to Monitor following on the system.

To find out the Percentage ASP utilized use following command:

Use following command to check active jobs as well as CPU utilization,

Use the following command to check all the active subsystems,

Use following command to find out the log on the system.
You can use same command to find log of a fixed time span.

Use following commands to find status of Lines, Devices and Controllers respectively,

Use following command to check the disk status,


A subsystem is a single, predefined operating environment through which the system coordinates the work flow and resource use. The system can contain several subsystems, all operating independently of each other. Subsystems manage resources. The run-time characteristics of a subsystem are defined in an object called a subsystem description. Subsystem enable better performance tuning.

A subsystem description is a system object that includes general definitions and storage pool definitions.

The general definitions includes subsystem name, description and maximum number of jobs to run in the subsystem.

Storage pool attributes determine how the subsystem uses memory for work, where work can enter the subsystem, how much work the subsystem can handle, how much main storage (memory) will be used, and how quickly jobs in the subsystem can run.

 To create a simple subsystem, we need four elements:
    * A subsystem description that describes the overall working environment of the subsystem, including the number of jobs it can run at one time and the OS/400 storage pools the subsystem uses
    * A job queue, where OS/400 submits jobs that are meant to run in the subsystem
    * A class object that describes the runtime attributes of jobs entering this subsystem
    * One or more routing entries that tell the subsystem how to process incoming requests

To perform the first step for our own  subsystem, creating the subsystem description, use CRTSBSD command. To create a MTHEND subsystem, the CRTSBSD command might look like this:

The second subsystem creation task is to make a unique OS/400 job queue where jobs can be queued up waiting to be processed in your new subsystem. Job queues are created by using the Create Job Queue (CRTJOBQ) command. To create a MTHEND job queue, the CRTJOBQ command might look like this:

Once the job queue is created, it's a simple matter to attach it to your subsystem by using the Add Job Queue Entry (ADDJOBQE) command, as follows:

Our third step is to use the Create Class (CRTCLS) command to create a class object that describes the run priority, time slice, or purge attributes for jobs running in this subsystem. Use the following command:

Our fourth step is to create a routing entry that tells OS/400 what to do with incoming requests for subsystem MTHEND (through a Submit Job, or SBMJOB, command for batch processing). In our case, we merely want the subsystem to invoke the command processor (QCMD) to run any command contained in incoming jobs. To do this, we use the Add Routing Entry (ADDRTGE) command, as follows:

  • To start a subsystem, use the Start Subsystem (STRSBS) command.
  • To end a subsystem, use the End Subsystem (ENDSBS) command.
  • To delete a subsystem description, use the Delete Subsystem Description (DLTSBSD) command. To use the DLTSBSD command, the subsystem cannot be active.
  • To change subsystem description, use Change Subsystem Description (CHGSBSD)  command.
  • To display subsystem description, use Display Subsystem Description (DSPSBSD) command.
  • To start a subsystem using BRMS, use STRSBSBRM command.
  • To work with subsystems, use WRKSBS command.
  • To work with subsystem description, use WRKSBSD command.
  • To work with subsystem jobs, use WRKSBSJOB command  

The default subsystems are
1. QCTL - Controlling Subsytem, this subsystem will always be up as soon as the system is started.
2. QINTER - All interactive jobs will run in QINTER subsytem.
3. QBATCH - All batch jobs will run in QBATCH subsystem.
4. QCMN - All communication jobs will run in QCMN subsystem.
5. QSPL - QSPL handles spooled file jobs, including placing files or jobs into disk storage for later processing or printing.
6. QSYSWRK - QSYSWRK coordinates system functions that are started automatically at system startup and when the system comes out of restricted state.
7. QSERVER - This is the file server subsystem. All server jobs will run in this subsystem.
8. QUSRWRK - This is the user work subsystem. It executes prestart jobs and jobs that are started by servers to do work on behalf of a user.


The menu allows users to select the task they would like to perform without having to use the system commands. This task menus provides users with a more defined group of choices regarding tasks or objects available.

Blog Archive

Search Engine Optimization and SEO Tools