Have you recently adopted an IBM server running IBM i and don’t know where to begin with system operations? You are not alone. With all the acquisitions, retirements, outsourcing, and insourcing going in today’s data centers, those reliable systems known as IBM i or iSeries (even “the 400” in some quarters) are chugging away running the business. Often they are ignored or improperly configured, yet they still get the job done.
Fortra has been teaching our IBM i Operations 101 class for many years. While the information is still very relevant, IT staff usually has too much to do and not enough time to get it done, so training has taken a back burner. Let’s change that trend.
Where to Begin
There are six areas that staff new to IBM i should start with:
- Architecture
- Commands
- Subsystems, jobs, and memory (a.k.a. work management)
- Security
- Message management
- Spooled file (report) management
We’ll take a look at the first three areas in this article. But don’t worry—we’ll point you in the right direction for more information.
Architecture
The basis of IBM i architecture is single-level storage, which means your programmers don’t need to account for programs and data moving from spinning (or solid state) disk (called auxiliary storage) to internal RAM (main storage). It’s all one huge address space. The operating system manages the task of moving programs and data into main storage. Why is this important? It directly affects system performance, especially if there’s not enough memory assigned to a task. More on this later.
The second piece of the architecture to understand is the library structure versus directory structure. The traditional library structure is a logical grouping of objects—files, programs, commands, etc.—that are needed for your applications. Libraries are grouped into a library list (see Figure 1) and assigned to a task to use. Library and library objects have a special naming convention as well.
Figure 1: Display a library list using the DSPLIBL command.
By comparison, the directory database structure allows a hierarchical structure (e.g., directories within directories or folders within folders) to account for applications that run in a Windows or Linux/UNIX environment that require a hierarchical structure. The naming convention depends upon the hierarchical directory structure you are working in (see Figure 2).
Figure 2: Work with object links in the directory structure using the WRKLNK command.
Commands
Back in the early 1990s, commands were often considered the most challenging part of learning the operating system. This is where the IBM i operating system stands out. Through the use of menus (GO CMDSAV, GO CMDUSRPRF, “GO” takes you to a menu), IBM has created a list of lists that help you find what you’re looking for. Plus, if you type DSP* on the command line, you’ll be presented a list of all commands (in your library list) that start with DSP.
Commands are formed using abbreviations of verbs and nouns. For example, the DSPUSRPRF command will display the contents of a user profile. DLTLIB will delete a library.
Command syntax? Press the F4 key after typing or selecting a command and you’ll be presented with parameters containing the correct fields and field lengths (see Figure 3). Don’t know what goes in the fields? Press F1 for help…and all this before Google was around to give you even more help!
On top of that, IBM did a wonderful thing by creating work commands such as WRKUSRPRF, WRKOBJ, and WRKSBS, which are multi-function (display, add, change, delete) and can be found by typing WRK* or GO CMDWRK in a command line.
Figure 3: Prompt command syntax using the CPYF command then F4.
Work Management (Subsystems, Jobs, and Memory)
We like to boast that OS/400, the name of the operating system on the original AS/400, allowed virtual environments long before partitioning and VMware. The latest IBM i operating system still uses this technology, and it’s a critical part of its functionality.
A subsystem is where memory and processor is allocated to tasks on the system. Whether it is remote access from a webpage accessing the DB2 database, a green screen interactive session, or a batch job creating a report, it all enters the system through a subsystem. Similar activities such as batch jobs or interactive sessions are directed to subsystems that have memory pools devoted to those similar types of activity. Work can be divided by region, such as multiple municipalities sharing a single partition system. This is stuff Windows can only dream of, and it doesn’t require multiple servers to handle the workload!
Jobs can be assigned priorities and classes, which determine when and how much system CPU resources they get when it’s their turn to run. You can view this activity by watching the DSPSYSSTS, WRKSYSACT, and WRKACTJOB commands.
DSPSYSSTS shows you how much memory is devoted to each of the separate memory pools that process user and system activity. Pool 1 (*MACHINE) is devoted to operating system activity and Pool 2 (*BASE) is where all other memory is placed unless it is divided between other pools. Other memory pools are typically allocated for interactive, spooled, and batch work (see Figure 4).
Figure 4: Display system status and memory pools using the DSPSYSSTS command.
Certain subsystems are shipped to start automatically when you receive your system from IBM, but you can create your own and learn how to separate and direct workload appropriately. It’s not possible to completely describe the process in this short article, but it’s not difficult and just takes a bit of experimentation and education.
Next Steps
To complete your education as the new keeper of your IBM i system, you should have an understanding of the security features of the system and message and log management, as well as spooled file management.
