Understanding AS/400 System Operations

by Mike Dawson, Marge Hohly

Overview

Coverage includes learning key day-to-day operations on an AS/400 computer system including IPL, stopping the system, backup and recovery, and system cleanup; creating and maintaining user environments, device configuration and management, job management, security implementation, work and data management, and TCP/IP configuration; working with console operations including jobs, message handling, spool files, and devices; accessing the AS/400 through Operations Navigator and traditional methods; and learning the material for two IBM AS/400 certification exams (Associate and Professional system operators). Dawson is a programmer and author of several books on AS/400 topics; Hohly is IBM AS/400 certified in both operations and system administration.

Product Details

ISBN-13:	9781583476987
Publisher:	Mc Press
Publication date:	05/01/2012
Sold by:	Barnes & Noble
Format:	eBook
Pages:	816
File size:	11 MB
Note:	This product may take a few minutes to download.

About the Author

Mike Dawson has been programming on mainframe and midrange computers since 1974. He is the author of four books on AS/400 topics ranging from performance to operations, including The AS/400 Owner's Manual for V4. He lives in Phoenix, Arizona.

Read an Excerpt

Understanding AS/400 System Operations

---

By Mike Dawson

MC Press

Copyright © 2003 MC Press, LLC
All rights reserved.
ISBN: 978-1-58347-698-7

---

CHAPTER 1

BACKGROUND OF THE AS/400

CHAPTER OBJECTIVES

Upon completion of this chapter, you should be able to:

• Describe the history of the AS/400.

• Describe the basic architecture of the AS/400 computer system.

• Describe the various parts of an AS/400 menu screen.

• Explain the purpose of the command line.

AN INTRODUCTION TO THE AS/400 ENVIRONMENT

The AS/400 computer system consists of a family of IBM "midrange" computers based on a single hardware/software architecture. From the beginning, it has represented a milestone in reliability, ease of use, and system integration not found in any other computer system.

The AS/400 is also a linch pin in IBM's System Application Architecture (SAA) connectivity scheme between mainframe, midrange, and personal computers. SAA is a unified approach to software design and interplatform communications. The SAA solution is based on a set of software interfaces, conventions, and protocols that provide a framework for designing and developing applications. Ultimately, the goal of SAA is an environment that is transparent to the user.

THE EVOLUTION OF IBM MIDRANGE COMPUTERS

The evolution of IBM minicomputers, now referred to as midrange computers, began with the announcement of the System/3 minicomputer system in June 1969. The System/3, which was the first computer system totally developed at the IBM plant in Rochester, Minnesota, was designed as a punched card-oriented computer system. Because mainframe computers controlled the high-end segment of the market, the System/3 was aimed at low-end commercial users running small-size batch applications.

Although the System/3 seems laughable by today's computer standards, its impact on the computer industry, like other Rochester efforts, cannot be overemphasized. It represented significant advances in the technology of its time. Before the System/3, computer architecture design took place in New York City and New England. All computers followed the same model for hardware design originally developed at MIT.

Rochester is located in cold, southern Minnesota, remote enough that its designers were free to rethink how computers should work. The System/3 was the first, the Adam or Eve, of the IBM midrange line, and it represented two new concepts in computing:

• A small, efficient computer would sell as well as the huge, expensive behemoths that the mainframes had become.

• The single computer model that had been the industry standard was not the only option.

The System/32 was the System/3's offspring. Announced in January 1975, it was still card-based, but it also touted direct keyboard data entry and a screen display that could present up to six rows of text 40 characters long. The System/32 was primarily single-user, although toward the end of its life cycle, IBM offered a model that supported five data-entry terminals simultaneously.

In April 1977, IBM announced the System/34 — the first multiuser minicomputer system in the world. The system was designed to meet the demand for a low-cost computer system that provided interactive multiuser facilities and managed multiple local and remote workstations, each being up to 5,000 feet away from the computer. The System/34 quickly became the most installed computer system in the world, boasting more installations than the mighty mainframe. IBM began to see that the minicomputer was not going away.

The IBM Rochester facility was never one to rest on its successes, however. While the other midrange computers were enjoying such popularity, IBM began a secret project in 1975. They again threw away all computer architecture models, even their own, and started a new design. This became the System/38 that was announced in 1978. When the first models shipped, it turned out they were very slow. IBM did not want the System/38 to be known for anything negative, so they did the unheard of and pulled the System/38 off the market until performance was achieved. It was not until 1980 that System/38s started to be installed.

This System/38 architectural design represented a divergence from its S/3X predecessors, offering several innovative concepts. One concept was machine independence. Prior to this, when a computer company came out with a new processor chip, customers had no choice but to replace their existing hardware with new. This implied converting existing data and programs. So every couple of years, customers had a major replacement and conversion project. The System/38 was designed so that the hardware could be changed at any time in the future with no impact to the customer.

Another concept pioneered in the System/38 was the large amount of built-in functions. For the first time, customers received a computer that already contained a relational database, superior security system, extensive backup/recovery tools, performance, journaling, and other functions. Other concepts unique to the System/38 were an advanced operating system and object-based architecture. Object-based architecture is very similar to object-oriented architecture. The difference between them is IBM disabled the object-oriented functions that caused problems. The cost was relatively small, but that is why the machine is referred to as object-based. We will discuss objects more in this chapter but, for now, think about how advanced the System/38 was. It took the rest of the industry until 1990 before the idea of object-orientation even caught on, and then it was years before it found its way into anything commercial. But, starting with the System/38, IBM midrange customers had an object-based architecture.

For its time, the System/38 was fairly pricey for midrange computer customers, so IBM developed the original System/3-based computer line as a low-end offering. In May 1983, while the System/38 was getting all the headlines, IBM announced the System/36, the successor to the System/34. Surprising to IBM, most System/34 customers elected to upgrade to the System/36 rather than the System/38. The migration was much easier and cheaper. System/38 customers tended to be new customers to IBM's midrange computers.

The System/38 was a giant leap in the evolution of computer genealogy, and it had some unforeseen limitations that affected its upward growth. While the System/38 had been touted as hardware independent, it only was to a point. In 1985, IBM started, under code name "Silverlake," development of the successor to the System/38. Silverlake would be the computer that would carry IBM midrange customers into the next millennium and beyond.

In June 1988, IBM announced the first Application System/400 (AS/400), the B-series that began shipping in September 1988. The first AS/400s did not seem as radical a change from the System/38 at first, but customers did notice dramatic speed and capacity improvements immediately. Over the years, speed and capacity increased once a year, at a rate of about 10 percent per year. The advantage was that any IBM AS/400 that was upgraded to the latest release could expect a 10 percent growth in its computing power without having to change equipment. That growth matched typical business growth. The claim, though, that the AS/400 was hardware-independent remained untested until 1995.

One aspect of the original AS/400 computer architecture was that the instruction set that its processor used was complex — the computer was known as a complex instruction set computer (CISC). That meant that a single instruction carried with it as much detail as was needed to execute. The alternative was a reduced instruction set or reduced instruction set computer (RISC).

Actually, there is nothing reduced about a RISC machine; it has as much functionality as a CISC computer. The instruction lengths on a RISC machine are all equal, where the instruction lengths on a CISC machine are variable and can be quite large. A computer designed to process a known instruction length can be many times more efficient than one designed to handle variable length instructions. For instance: When taking a taxi across town; using the CISC method, you would say, "Take me to the airport," and sit back and enjoy the ride. Using the RISC method, you would issue continual instructions, "Turn left at the next light." "Slow down here." "Now turn right." CISC is easier, but RISC may get you where you are going faster and more directly. Besides, with CISC, you need a driver who knows his way around, while with RISC, you can use any driver.

The CISC-to-RISC migration was the biggest undertaking of the AS/400 since its birth. Remember that one of the major promises of the System/38 was hardware independence? Some people in the computer world were critical that System/38 customers were forced to sell their old equipment and purchase a new AS/400. The 38-to-400 change did not show customers true machine independence, but the CISC-to-RISC change did. Changing the processor architecture was an undertaking unparalleled in the history of computers, and it proved AS/400's claim to machine independence. There was more to the change than the instruction set; the new processor was going from a basic 48-byte word (that is bytes, not bits) to 64-byte basic addressing. This was more than a processor upgrade; this was a complete architecture change.

The AS/400's capacity to handle this change without requiring its customers to go through either a program or database conversion proved the AS/400 to be a true hardware-independent computer. Customers only had to replace a board, and in some cases, increase disk capacity and memory slightly; and they had the next generation of AS/400 installed. They did not have to sell one computer and buy another; they did not have to copy programs off and recompile them; and they did not have to take large database files to flat files and reload them on another machine. Except in very unusual circumstances, all AS/400 customers made the migration over a weekend.

The AS/400 was not just basking in glory — IBM renewed it every year with a rich set of new features and functions. It also broadened its market to the point that the AS/400 range of current models went from a low price of $7,000 to somewhere around $2 million. Except for storage and speed differences, every AS/400 is identical in how it executes its programs and operates on the data it supports. Any size business can get into an AS/400 at any level and grow to any level.

While all this was going on, there was a large group of customers fiercely loyal to the System/36 that came out in 1983. Not a database machine, the System/36 still boasted very low cost of ownership, reliability, and ease of use. Even though the System/38 (and the AS/400) could support System/36 customers' applications and the machine's operating system directly, many refused to make the jump to AS/400.

With the continued popularity of and demand for the System/36 in the user community, IBM developed an AS/400-based alternative. It announced the AS/400 Advanced 36 in 1994. Available today for those customers, the Advanced 36 uses state-of-the-art 64-bit RISC technology just like its big brother.

Just to add a few more sprinkles on the AS/400 cake — in 1994, IBM Rochester foresaw the tremendous business potential that the Internet would offer. To meet the growth ahead of the rest, IBM developed a new series of AS/400s known as the Enhanced series, or e-series. This line was formally announced in August 1997. The new Enhanced series offers high performance through models equipped with up to twelve individual processors. For example, the top-of-the-line AS/400 e-server has a twelve-way processor. Multiple processor computers are referred to as n-way.

Every major announcement from IBM breaks new ground. This was the first time IBM offered packages of software and hardware preconfigured and preloaded. With this approach, the customer literally unpacked and plugged in the AS/400, and they had a powerful Internet server.

Collectively, the System/3, System/32, System/34, System/36, and System/38 are known as the System/3X family of midrange computers.

AS/400 ARCHITECTURE

LAYERED DESIGN CONCEPT

The key to the AS/400's uniqueness starts with its architecture. It boasts a layered design concept that is one factor that distinguishes it from traditional computers. This concept isolates machine hardware and system software through a series of horizontal interfaces as shown in Figure 1-1. This layering is the key to the AS/400's machine independence. The layered design allows low-level functions to be replaced by improved technology at any time, yet causes minimal disruption to the high-level software.

When you refer to items at or near the top (application software) layer, you are at the high level of the architecture. Conversely, the bottom layers are referred to as low-level architecture. LIC means licensed internal code. The vertical licensed internal code (VLIC), horizontal licensed internal code (HLIC), and system licensed internal code (SLIC) layers are collectively referred to as the machine interface (MI). Generally, AS/400 items are referred to as being above or below the MI layer.

In plain language, VLIC translates instructions passed to the MI. It hands the translated instructions to the HLIC that deals directly with the hardware. When IBM was coming out with the RISC architecture, it rewrote millions of lines of the MI layer and, in the process, combined VLIC and HLIC into a single layer, SLIC. By the way, the SLIC layer is written in C++ and makes heavy use of objects. This layer is sometimes referred to as the kernel of the machine.

DATA STORAGE AND AS/400 OBJECTS

The AS/400 is an object-based computer, meaning that everything is stored as an object. An object can best be described as an entity that exists on the AS/400 upon which procedures can be performed by the AS/400. There are many types of objects that can be stored on the AS/400. Some of the more common objects discussed in this book include programs, data files (databases), and libraries. Object names consist of the given name concatenated with the object type. For example, a file object (file type *FILE) could be named OBJ1. A program has an object type *PGM associated with it. Because each object name is a concatenation of the name and the type, you could have a file named OBJ1 and a program named OBJ1, and the AS/400 would not get confused — it would know one is a file and one is a program.

This object type and name association is implicit; AS/400 professionals are not often aware of it. More commonly, objects on an AS/400 can be grouped into libraries. A library can be anything the user wants it to be, but it is usually a group of related objects. ARLIB could be the name of the library that contains all the programs and files that make up the Accounts Receivable (AR) application. Another organization may elect to only keep the programs in ARLIB and have another library named ARDATA for the application's database files.

When an AS/400 developer refers to a program or file, he often concatenates the library and file together to identify the object and its location. If the developer wanted the master file named MASTFILE in the ARDATA library, ARDATA/MASTFILE would be entered. Doing this explicitly is optional — many people get by with using the object name without a library qualifier. This works because the AS/400 will assign a default library to that name. We are getting ahead of ourselves, though; we will discuss libraries more extensively later. For now, just remember that objects are implicitly associated with an object type and explicitly or implicitly associated with a library.

Internally, data in the AS/400 objects database is stored in the form called the Extended Binary Coded Decimal Interchange Code (EBCDIC). This is different from the internal form used in PCs, called the American Standard Code for Information Interchange (ASCII). The two forms were defined by separate organizations in the 1950s to represent alphanumeric characters (letters and numbers). When transferring data between the AS/400 and PCs, data conversion must be done.

SINGLE-LEVEL STORAGE

Another distinguishing factor between traditional computer systems and the AS/400 is the AS/400's single-level storage. With single-level storage, the AS/400 makes no distinction between disk storage and main memory and, thus, treats main memory and disk storage as if they are one vast region in main memory. Files stored on disk are treated as addressable memory. Therefore, all disk and main storage appear as one seamless linear address space and the system accesses all data in the same way.

Single-level storage is unique to AS/400s. Other computers first identify the region in memory or disk storage, then the address within the region before attempting to access an object.

(Continues...)

---

Excerpted from Understanding AS/400 System Operations by Mike Dawson. Copyright © 2003 MC Press, LLC. Excerpted by permission of MC Press.
All rights reserved. No part of this excerpt may be reproduced or reprinted without permission in writing from the publisher.
Excerpts are provided by Dial-A-Book Inc. solely for the personal use of visitors to this web site.

---

Table of Contents

Contents

Title Page,
Copyright Page,
Dedication,
ACKNOWLEDGMENTS,
PREFACE,
1 - BACKGROUND OF THE AS/400,
2 - NAVIGATING AROUND THE AS/400,
3 - OS/400 COMMAND STRUCTURE AND CONTROL LANGUAGE,
4 - OBJECTS, LIBRARIES, AND LIBRARY LISTS,
5 - MESSAGE HANDLING,
6 - HANDLING SPOOLED FILES AND PRINTING FUNCTIONS,
7 - MANAGING DEVICES,
8 - STARTING AND STOPPING THE AS/400,
9 - OPERATING SYSTEM, LICENSED PROGRAM PRODUCTS, AND PTFs,
10 - BACKUP AND RECOVERY,
11 - SECURITY AND SECURITY SYSTEM VALUES,
12 - WORKING WITH JOBS,
13 - SUBSYSTEMS,
14 - WORK MANAGEMENT AND PERFORMANCE,
15 - MESSAGES, LOGS, AND CLEANUP,
16 - BASIC TROUBLESHOOTING, PROBLEM SOLVING, AND USING ELECTRONIC CUSTOMER SUPPORT,
17 - JOURNALING,
18 - COMMUNICATIONS: SNA, APPC, AND APPN,
19 - COMMUNICATIONS: LANS AND TCP/IP,
20 - OPERATIONS NAVIGATOR,
APPENDIX A - AS/400 KEYBOARD,
APPENDIX B - SYSTEM VALUES (ALPHABETICAL ORDER),
APPENDIX C - SYSTEM VALUES (FUNCTIONAL ORDER),
APPENDIX D - ANSWERS TO CHAPTER SELF-TEST QUESTIONS,
GLOSSARY,