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)