Learn how Robot can be deployed to maximize business objectives.
Back in the day of AS/400, when a server was a server and a disk was a disk, things were easier to understand.
Today’s modern IBM i environments are increasingly virtualized, mirrored, switched, clustered, externalized, and partitioned. This makes them more capable of reacting to ever-changing business cycles, but arguably harder to understand.
Robot systems management solutions have been helping customers manage IBM i operations for over 30 years. This paper is intended primarily for IT management and attempts to explain, in plain English, the components of modern IBM i environments and how Robot can be deployed to maximize business objectives.
IBM i Virtualization
Virtualization refers to the act of creating a virtual version of a computer, its processor, memory, disk, and network. A virtual computer behaves like an actual computer except that it’s easier to modify if business requirements change. You can increase or decrease a virtual computer’s resources without buying hardware or involving hardware engineers. If one virtual computer has spare capacity and another computer needs it, you can reallocate it.
The move toward virtualization has not happened overnight. Virtualization features have been continually added to IBM i since its launch, and they have now come to a point where many large enterprises and SMEs are finding these capabilities functional, complete, and robust enough for widespread adoption.
So, let’s look at the features currently available that enable virtual IBM i computers.
Operating System (IBM i)
When the AS/400 was launched in 1988, the operating system was called OS/400 Release 1. It became i5/OS V4R5 in 2000 and then IBM i version 6.1 in 2008. Major releases to the operating system continue today with a roadmap for the technology extending well into the future. And while new virtualization features have been added over the years, the base architecture has remained the same.
Figure 1: IBM i Operating System
Unlike most other operating systems, IBM i has always had hardware virtualization capabilities. For example, single-level storage gives us the ability to view all storage—memory, solid state, and spinning disk—as a single name space so that operators and programmers don’t need to worry where data is physically stored.
Virtualization capabilities link IBM i closely to the hardware on which it runs with self-diagnosis and self-healing capabilities. As a result, it’s not advised to transplant IBM i from one hardware environment to another. If you save IBM i (SAVSYS) and restore it to another server, for example, it will typically go into shock and spend hours diagnosing and self-healing until it makes sense of its new environment.
Note the following about IBM i:
• It’s a best practice not to try to move your instance of IBM i to different hardware.*
• It’s a best practice not to mirror IBM i (library QSYS) to a backup server.*
• IBM i must run from an internal disk pool closest to the processor known as ASP1. More often, it’s called SYSBAS (short for system base ASP).
* There is an exception. See live partition mobility.
Want to Know More?