AS400 System Administration Training Blog

Program Temporary Fixes (PTFs)

A program temporary fix (PTF) is a temporary solution to a bug on AS400. A PTF is temporary only in the sense that it disappears with the next release of the product, when the code patch is integrated into the base product code. PTFs are recommended to keep the system up to date and current. 

Types of Fixes or PTFs: Many different kinds of fixes exist, and each fix has its own purpose. 
  1. Single fixes: Single PTFs are applied to correct specific reported problems. The following are descriptions of the different types of single fixes that exist: 
    • High-impact pervasive (HIPER) PTF: A HIPER PTF resolves a severe problem that can have a high impact on IBM OS/400 or IBM i5/OS operations, or it can resolve a low-impact but pervasive problem that affects most IBM iSeries family of servers. The following are examples of these types of situations:
      •  Your system crashes or hangs, and it requires a restart or IPL (initial program load) to recover.
      •  Your system is stuck in a looping condition.
      •  Your system's data integrity is threatened.
      •  Your system experiences a severe performance degradation, or the problem involves the usability of a product's major function.
    • Pre-requisite fix: A pre-requisite fix is a fix that must be installed on your server before or at the same time as the fix that you want to install. The system will prevent you from installing your fixes if you do not have the prerequisite fixes. Your fix cover letter or PSP information can identify other fixes that must be installed before or at the same time as the fix that you want to install.
    • Co-requisite fix: A co-requisite fix must be installed at the same time as the fix that you are requesting to install. Your fix cover letter or PSP information can identify other fixes that must be installed before or at the same time as the fix that you want to install. In addition, system error messages can notify you that the fix that you are attempting to install has requisite fixes. The system checks that the co-requisite fixes are installed at the same time. In this case, you must verify that your fixes installed successfully.
    • Technical Refresh requisite fix: The technical refresh PTF is required to be permanently applied to the system before you can load this fix.
    • Distribution requisite fix: A distribution requisite fix is required for distribution purposes only. A distribution requisite fix is sent and installed only if it is named by a fix listed in a fix group and you are using that fix group to send or install fixes. If you are sending only a fix, then the distribution requisite fix is not sent and installed. The system does not require you to apply distribution requisites.
    • Delayed fixes: Some fixes cannot be applied immediately because the licensed programs they affect are active. These fixes are called delayed fixes and can be applied only at the next IPL. Delayed fixes that affect the Licensed Internal Code can be applied immediately when running on the A storage area. The cover letter tells you if the PTF is immediate or delayed.
    • Immediate fixes: Immediate fixes can be applied without doing an IPL if the objects that they affect are not in use, or they can be applied when you do the next IPL. The cover letter tells you if the PTF is immediate or delayed.
    2. Cumulative PTF packages: Cumulative PTF packages contain fixes for a given release of the OS/400 or i5/OS operating system and associated licensed programs. As the name implies, each package is cumulative; that is, it contains all of the fixes from the previous package plus additional fixes released since the previous package. Many, but not all, new fixes are included in cumulative packages.

    The fixes that are not included are typically applicable only to a specific user's situation or application. These fixes are not included for general availability to avoid introducing unwanted change and potential programming errors into a cumulative package where code quality has the highest priority. When you order the cumulative PTF package, you also receive the most recent Database PTF group and the HIPER PTF group.
    3. Fix groups (Group PTFs): A PTF group, or fix group in iSeries Navigator terminology, is a name that is used to order and manage a group of logically related PTFs. It consists of a list of PTFs that are defined for the purpose of managing those PTFs as one entity. A PTF group can identify other PTF groups, called related PTF groups. 

    The cumulative PTF package is shown as a PTF group on the Work with PTF Groups ( WRKPTFGRP) screen and in the Management Central fix group inventory.
    4. Service packs: Service packs are different from group PTFs. A service pack is a collection of code fixes (not PTFs) for iSeries Access for Windows products that are contained in a single OS/400 or i5/OS PTF. 

Initial Program Load (Reboot)

Initial program load (IPL) means load the initial (first) programs into main storage so that the processor can use them to do work for you. An IPL resets system storage (cleans out what was there and replaces it with new data). In other words, IPL means start your system. The following situations typically require an IPL:

  • Starting local or remote operations when the system power is off
  • Applying certain program temporary fixes (PTFs)
  • Installing new system hardware
  • Starting a system after a problem prevents all jobs from working
  • Main storage dumps 
AS/400 has a variety of modes, speeds, and types of initial program loads to fit a variety of needs.

Operating mode: You use the operating mode to determine the number of options that are presented to the operator for consideration during and after the initial program load (IPL). It can also secure (lock) the control panel to prevent an unauthorized or inadvertent IPL from the control panel. There are four operating modes:

Normal (unattended)
After the power-on, operating the system in Normal (unattended) mode requires no operator intervention during the IPL. When you power on the system in normal mode, it performs the IPL and presents the Sign On screen on all available display stations. The operator cannot change the system during the IPL. Dedicated Service Tools (DST) and the operating system do not present any displays during this IPL.
Use a normal mode (unattended) IPL to do this:

  • Perform an IPL and run the system for most routine work
  • Perform a remote IPL
  • Power on and perform an IPL by date and time
Manual (attended)
After power-on, operating the system in Manual (attended) mode means that an operator uses the control panel to direct the system for special needs. During manual mode IPL, DST and the operating system present menus and prompts that allow you to make changes to the internal system environment. This can include entering debug mode for service representatives to diagnose difficult problems.
Use manual mode to IPL and run the system to perform the following actions:

  • Change IPL options (including system values)
  • Install the operating system
  • Load program temporary fixes (PTFs)
  • Make some types of system hardware upgrades
  • Use DST (for advanced users and service only)
  • Problem diagnosis (for advanced users and service only)
Auto (automatic)
Use Auto mode for an automatic remote IPL, automatic IPL by Date and Time, and an automatic IPL after a power failure.

Use Secure mode to prevent use of the control panel to perform an IPL. This mode is not a form of IPL; it is a means to prevent an unauthorized or inadvertent IPL from the control panel. 

IPL type: The IPL type determines which copy of programs your system uses during the initial program load (IPL).
There are four IPL types:

IPL type A
Use IPL type A when directed for special work, such as applying program temporary fixes (PTFs) and diagnostic work. For example, use IPL type A in the following circumstances:

  • When IPL type B fails
  • When the procedures direct you to use IPL type A
  • When you suspect problems with temporary Licensed Internal Code PTFs 
IPL type A uses the A copy of Licensed Internal Code during and after the IPL. This copy of Licensed Internal Code is the permanent copy. It is said to reside in System Storage Area A. It contains no temporarily applied PTFs.

IPL type B:
Use IPL type B for routine work and when directed by a PTF procedure. This type of IPL runs the newest copy of Licensed Internal Code and is necessary when you permanently apply certain PTFs. IPL type B uses the B copy of Licensed Internal Code during and after the IPL. This copy is said to reside in System Storage Area B. This copy contains temporarily applied PTFs. 

IPL type C
This type of IPL is reserved for hardware service representative use under the direction of Rochester development support. Attention! Do not use this function! Severe data loss can occur with improper use of this function.

IPL type D
Use IPL type D when directed for special work, such as installing and reloading programs. IPL type D loads the system programs from an alternate IPL load source, such as a tape drive or CD-ROM.
Usually an IPL uses programs stored on the primary IPL load source (usually a disk drive). Sometimes it is necessary to perform an IPL from another source, such as programs stored on tape. To do this, you must use IPL type D to IPL from the alternate IPL load source.
Use IPL type D only during one of the following situations:

  • When install or restore procedures direct you to use IPL type D
  • When IPL type B and IPL type A fail (when the primary IPL load source cannot IPL the system properly) and only when directed by your support personnel
  • When service directs you to perform an alternate install

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,

Search Engine Optimization and SEO Tools