IBM Supplied User Profiles

The following are the few user profiles shipped with the operating system

QSECOFR   - Security Officer
QPGMR      - Programmer
QBRMS      - BRMS profile
QSPL         - Spool profile
QSRV        - Service profile
QSYS        - System profile
QSYSOPR  - System Operator profile
QTCP        - Transmission Control Protocol (TCP) profile
QDFTOWN - For ownership purposes

Printers in AS400

Printer: Hardware device that prints the spool file

Writer: A writer is an IBM program that reads a spool file from an output queue and sends it to a printer

Each printer must have a printer device description. The printer device description contains a configuration description of the printer. Printers can be attached by a variety of attachment methods.

AS/400 supports 2 types of printer objects
1. Print Devices
2. Remote outqs

Print Devices are used to define local printers that are directly attached to or are controlled from AS/400. A print device contains an associated outq for printing spool files

Remote Outqs are spooling writers that send OS/400 spooled file output to a printer that is located on and controlled by remote system (AIX, Linux, Windows box). A remote outq is not associated with any AS400 device. A remote outq is an outq object that contains configuration parameters for sending spooled files to another system for processing. 

Printer files describe how the system operates on the data as it passes between your application program and a printer.

Printing Process Overview

1. The printing process starts when an application program runs. The application program creates output data. The output data is based on the application program and information contained in the printer file. 
2. If print spooling is selected, the output data is placed in a spooled file and the spooled file is placed in an output queue. If direct printing is selected, the output data is sent directly to the printer.

WRKWTR *ALL – Display all writers 

• Printer writers (PRT)
• Remote printer writer (RMT)
• 2=Change   3=Hold   4=End   5=Work with   6=Release   7=Display messages   8=Work with output queue 

WRKWTR – Display printer writers only

STRPRTWTR – Start printer writer

STRRMTPRT – Start remote writer

Difference between SST and DST

SST is available when the OS is started. The OS is required for accessing SST. SST is used to manage firmware & hardware. It is not used to manage OS.

DST is available even when the system has limited capabilities. DST is available even if OS is not installed. LIC is required for accessing DST.  

Accessing SST

To access service tools using SST, complete the following steps:

1. Enter STRSST (Start SST) on an IBM i command line. The Start SST Sign On display is shown.
2. Enter the following information:
   • Service Tools User ID: The service tools user ID you sign on with.
   • Password: The password associated with this user ID.
3. Press Enter.

Note: To login to SST, the user ID must have Service (*SERVICE) special authority 

Accessing DST

We can access DST in 2 different ways
1. From Control Panel
2. Through manual IPL

Accessing DST from the control panel:
To access service tools using DST from the control panel, complete the following steps:

• Put the control panel in manual mode.
• Use the control panel to select function 21 and press Enter. The DST Sign On display appears on the console.
• Sign on to DST using your service tools user ID and password. The Use dedicated service tools (DST) display appears.
• Select the appropriate option from the list and press Enter.
• Select option 5 (Work with DST environment) to get to additional options for working with service tools user IDs.
• Select option 7 (Start a service tool) to start any of the service tools available from DST.
• Select any of the other options, as appropriate.

Accessing service tools using DST from a manual IPL:
To access service tools using DST from a manual initial program load (IPL), complete the following steps:

• Put the control panel in manual mode.
• Take either of the following actions:
• If the system is powered off, turn the system on.
• If the system is powered on, enter the Power Down System (PWRDWNSYS) command, PWRDWNSYS *IMMED RESTART(*YES), on a command line to turn off the system and restart it.
• Sign on to DST using your service tools user ID and password. The Use dedicated service tools (DST) display is shown.
• Select the appropriate option from the list and press Enter.
• Select option 5 (Work with DST environment) to get additional options for working with service tools user IDs.
• Select option 7 (Start a service tool) to start any of the service tools available from DST.
• Select any of the other options, as appropriate.

Service Tools

Service tools are used to perform various system functions including diagnosing system problems, managing disk units, and managing system security. 

Dedicated Service Tools (DST) or System Service Tools (SST) are used to access service tools functions.  The following are the few functions we can perform with DST or SST.

• Add hardware resources to the system.
• Diagnose system problems.
• Manage disk units.
• Manage logical partition (LPAR) activities, including memory.
• Manage or view main storage dumps.
• Manage other service tools user IDs.
• Manage system security.
• Review the Licensed Internal Code and product activity logs.

Service tools user IDs are user IDs that are required for accessing service functions through DST, SST, i series navigator (for disk unit management), and Operations Console. 

Service tools user IDs are created through DST or SST and are separate from IBM i (OS/400) user profiles. It is possible to have a service tools user ID and operating system user profile with the same name.

You can create a maximum of 100 service tools user IDs (including the four IBM-supplied user IDs).

Authorization Lists

Authorization lists are a powerful tool for the management of security. Authorization list is a list of 2 or more user IDs & their authorities for system resources.  Authorization list grant users (or groups) the same authority to multiple objects.  

Authorization list reduces the number of private authorities stored in *usrprf object. The system identifies it as an object type *autl.

Note: The only drawback in authorization list is that they are only restored when restoring all profiles. 

Authorization List Commands

CRTAUTL command creates the authorization list 
Eg: CRTAUTL AUTL(List1)  

GRTOBJAUT command allows to associate the authorization list with the files (i.e, to determine which objects should be secured with authorization list)
Eg: GRTOBJAUT OBJ(Lib1/*ALL) OBJTYPE(*FILE) AUTL(List1)
By running above example, you are adding all files in library Lib1 to authorization list List1

ADDAUTLE command allows you to grant users the authority to the lists.
Eg: ADDAUTLE AUTL(List1) USER(Rahsin) AUT(*USE) 
By running above example, you are giving USE authority to the user Rahsin for the authorization list List1

EDTAUTL command allows you to add and remove users from the list, and specify their authority to the list. 

DLTAUTL command allows you to delete an authorization list.

DSPAUTL command allows you to display an authorization list.

WRKAUTL (Work with Authorization Lists) Command allows you to work with authorization lists. With this command, you can display, edit, delete, display the list's objects, or change the text for an authorization list.
Eg: WRKAUTL  AUTL(*all) -  It lists of all the authorization lists that you either own or have authority to see is shown.

Difference between HMC Upgrade & Update

It’s important to distinguish between updating and upgrading a system. The terms are not synonymous. 

Upgrade
To upgrade is to bring the system to a higher version or release of HMC code. When the HMC’s version number is incremented, such as going from Version 6 to Version 7, the upgrade method must be used in order to apply the new version of HMC code.

Update (Corrective Service)
In between HMC releases, or between upgrades, there will be times when interim fixes or cumulative service packs need to be applied. Interim fixes consist of security fixes or fixes that are considered critical to be released immediately to customers. Service packs are generally larger in contents. Both can be installed on the HMC by using the Install Corrective Service task under HMC Code Update, or by using the updhmc command on the HMC.

HMC Roles for User IDs

HMC comes with two predefined users: hscroot and root and cannot be deleted. They come with default passwords, but it is strongly recommended that they be changed during HMC setup and configuration. The default passwords are:

Username: hscroot
Password: abc123

Username: root
Password: passw0rd

Note: Make sure you change them!

hscroot & root have all the access to HMC and can manage & modify almost everything in HMC. Logging in as root is disabled. Note that while you will not be using the root password for daily administration, you may need it from time to time when performing problem determination, usually with the assistance of IBM support or product engineering.

Apart from these accounts, additional user IDs should be created on the HMC so that not every user is accessing the system with the same user ID and password, and not necessarily with the same level of authority.

Each HMC user IDs can be a member of a different role. A task role in HMC defines the access level for a user to do tasks on the managed object or group of objects, such as a managed system or logical partition. HMC roles are either predefined or customized. 

When you create an HMC user, you must assign that user a task role. There are 5 system defined task roles:

•hmcsuperadmin - The super administrator acts as the root user, or manager, of the HMC system. The super administrator has unrestricted authority to access and modify most of the HMC system. This should not be confused with user root.

•hmcservicerep - A service representative is generally someone (from IBM) physically at the managed system location to install, configure or repair managed systems.

•hmcoperator - An operator is responsible for daily system operations, but do not have authority to add new users or modify the roles.

•hmcpe - A product engineer assists in support situations (for both the managed system and the HMC), but cannot access HMC user management functions. To provide support with access for your system, you must create and administer user IDs with the product engineer role. PE can additionally shutdown HMC & close virtual terminal windows which service rep can't do.

•hmcviewer - A viewer can view HMC information, but cannot change any configuration information.

Hardware Management Console (HMC)

A Hardware Management Console (HMC) is an Linux based appliance used to manage IBM Power Systems servers. HMC is used to:

• Add / Remove LPARs
• Manage logical partitions and partition profiles
• Perform Dynamic LPAR (DLPAR) operations. (DLPAR operations that change the resource allocation (such as processor, memory, physical I/O, and virtual I/O) dynamically for the specified partition)
• Activate and manage Capacity on Demand resources

We can perform above functions without rebooting the operating system running in the LPAR.

A single HMC can control multiple Power Systems servers and multiple HMCs can manage a single Power System. An HMC can be used via either an X-Windows graphical user interface (GUI) or an SSH command line interface (CLI).

An HMC is necessary only to manage Power Systems servers. Once configured, Power Systems servers continue to operate normally even if the HMC is shut down. But please note that larger Power Systems servers (Power 760 and above) require an HMC to successfully power up. Once a server is powered up, the HMC is no longer required for the server to continue to operate normally. An HMC also provides access to the console of every virtual machine (LPAR) on every managed server. 

As of July 2016, the latest version of HMC is V8R8.4.0 

Note: LPAR (Logical Partitioning) is a way of subdividing all of a computer’s resources, including the memory, storage, and processors, and splitting them up into smaller logical units that can each be run as a separate part of the operating system (OS)

Library List

A list that indicates libraries used for the process and the order in which it has to be searched. There can be 40 libraries in library list (15 System & 25 application). 

A library list is identified by the type *LIBL. A default library list is automatically created by  IBM i (previously known as i5/OS or OS/400) for each job started by a user. Your default library, that is the library that has the same name as that as your user profile, is automatically included in your library list.

Add a Library to Library list: To add a library to the library list, type the “Add Library List Entry” (ADDLIBLE) command, followed by the library name (or prompt on the command) Eg: ADDLIBLE XXXXXX

Edit Library List & Change Current Lib: You can edit your library list using the EDTLIBL command and remove a library list entry using the RMVLIBLE command. “XXXXXX” can be made the current library by typing CHGCURLIB Yourlib.

Display Library List (DSPLIBL): When you display your library list. Your library list should look like

PS: You may not have all the libraries in the above list.

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.

• Defective PTF: A PTF that does not do what it was intended to do or has damaging effects. It’s a PTF that when applied may work for a vast majority of it’s customers but not you. There may be a unique situation at your installation that the PTF will not resolve. This makes it defective. 

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.

Secure

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 types: 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

Command: PWRDWNSYS (F4) 
                       Restart *YES / *No