IBM i: A History in Numbers

IBM i May 21, 2019

While some of its roots can be traced back to the System/38 world of 1970’s and 1980’s, IBM POWER servers running IBM i started life as the AS/400 (Application System/400) in 1988, a fully integrated hardware and software platform.

At its heart, IBM i’s history is the story of each of its critical components. Like American baseball, IBM i has its own statistical history of how we got from where we were before (the AS/400 in 1988) to where we are now (IBM POWER9 servers running IBM i 7.4 in 2019).

Let’s break down the numbers on IBM i’s history and see what it tells us about our beloved platform.

IBM i: A History in Numbers

Here are the critical stats, since 1988, that led to today’s IBM i systems.

IBM i and its predecessors have had 3 different operating system names, 7 different versions of the operating system, and 21+ different revision, or dot (.) versions of the operating system.
The OS/400-i5 OS-IBM i operating system has run on 6 different named hardware platforms, all manufactured with the IBM name.
17 different CPUs from Cobra to POWER9 have run IBM i and its predecessors.
IBM has sold 57+ different hardware models running the IBM i product line since 1988 (we stopped counting at 57).
All IBM I customers are STILL able to run software and databases that have been created since 1988.

Here’s how each number affected the history of the IBM i.

OS, thy numbers are 3, 7, and 21ish

Since 1988, there have been three different names for what is now known as the IBM i operating system.

The AS/400 premiered with the OS/400 (Operating System/400) OS in 1988. In a short-lived rebranding effort, IBM changed the operating system name to i5/OS in 2005, and finally settled in on IBM i as its current operating system name in 2008.

In 30+ years, there have been seven different versions of the operating system from OS/400 V1 through IBM i 7.x. There have also been at least 21 different releases or dot (.) versions (V2R1, V5R4, 7.4) during that time.

With the IBM i operating system, IBM changed its nomenclature for numbering operating systems from its old VnRnMn numbering system (VersionReleaseModification ex., V5R4M3) to a V.R system (Version.Release ex., 7.4). The modification part of the OS version has been replaced with a Technology Refresh (TR) number. TRs are generally issued twice a year and they contain all the most recent Product Temporary Fixes (PTFs) and product updates.

IBM POWER hardware also runs three different operating systems: AIX, IBM i, and Linux. This is important to IBM i users since POWER hardware upgrades on most models are pretty much available for all three operating systems at the same time. When separate machines were manufactured for different operating systems, IBM i sometimes lagged in getting the same capabilities as AIX. Although some POWER models are not available to run IBM i, having each OS run on POWER means that IBM i won’t be left behind in hardware capabilities when a new machine comes available.

Hardware, 6 the hard way

IBM i and its predecessors have always been an integrated system. IBM i isn’t like Windows, in which the operating systems run on hardware platforms manufactured by many different manufacturers. IBM i is more like the MAC OS, in that IBM manufactures and controls all the hardware platforms its OS runs on.

However, that doesn’t mean the hardware has been static for the last 30+ years.

IBM i and its predecessor OSes have run on no fewer than six different hardware platforms, all manufactured under IBM’s name, including:

1988 – AS/400 (Application System/400) – Using Complex Instruction Set Computing (CISC) processors
1995 – AS/400e – The first models to use 64-bit Reduced Instruction Set Computer (RISC) processors
2000 – eServer iSeries – The hardware line that introduced Power Optimization with Enhanced RISC (POWER) chips to the platform
2004 – IBM eServer i5, which introduced POWER5 64-bit processing
2006 – System i, in another short-lived IBM system rebranding initiative
2008 – IBM POWER systems, where IBM i, AIX, and Linux OSes can all run on the same box

Although the AS/400 name has remained popular through the years, IBM has not produced an AS/400-branded machine since the year 2000. We expect that IBM will continue to manufacture IBM POWER systems running IBM i for the foreseeable future, but anything’s possible. Even another name change.

CPUs, On the edge of 17

By our count, there have been at least 17 different CPUs used over the six hardware platforms IBM supported over the years. These CPUs included a number of nostalgic names until IBM finally settled on using the POWER name for CPUs capable of running IBM I and other operating systems. A list of CPUs that ran IBM i and its predecessors over the years includes:

Cobra
IStar
Power5+
Power8
Muskie
SStar
Power6
Power9
Apache
Power4
Power6+
NorthStar
Power4+
Power7
Pulsar
Power5
Power7+

According to IBM’s Power Processor Roadmap, we can expect to see POWER10 processors in 2020. Which will bring our estimated CPU count up to 18 (the legal age to vote in America).

Over 50+ machine model numbers

Within the six hardware platforms and the 17 different CPUs IBM offered since 1988, there have been a wide variety of machines that ran IBM i and its predecessors over the years. We counted at least 50 different IBM branded models that have been offered since 1988. Starting with the alphabetic Bxx through Fxx models of the 80s and 90s (with a few P01, P02, and P03 models tossed in), continuing through the numeric models (models 150, 890, etc.) and ending with the Power systems, PureSystems, and Express systems that have been available since 2008.

Every year, IBM seems to bring out at least one (but often, five or more) different systems for sale, so that every shop, regardless of it’s size, can run their own POWER system with multiple Linux, AIX, or IBM i operating system partitions (but no Windows).  And it looks like this string of operating system successes will continue into the foreseeable future.

It’s gotta be the applications

At its introduction in 1988, there were over 2,500 software packages available for the AS/400. Many of these packages aren’t available today but their code lives on. Through the years, organizations purchased packages and then modified the source code to match their needs, kick-starting an organization’s application base. This continues to this day and you can still find many shops that are still growing their applications off source code that was originally part of another package, sometimes written years, or decades, ago.

Other shops write their own killer apps that take advantage of the IBM i database to provide green screen, PC, Web, and mobile app processing. Many shops use IBM i as a back-end database and run their front-end on another platform. IBM i also serves as a great hosting platform for SAP implementations (SAP for i), and its security is top-notch. And of course, you can run your applications in the cloud where you don’t even own the hardware.

Application development continues, and you can write IBM i code in several different languages using traditional stalwarts such as RPG, C, and CLP, as well as newer open source coding packages such as PHP, Perle, Python, Node.js, and Ruby. And there are many open source servers that run on IBM i. This allows shops to keep up with the next technological trends and use programmers with all levels of experience to develop IBM i applications.

Applications have always been the core of IBM i, its very reason for existing as the word applications was included in its very first name: Application System/400 (AS/400). It’s been an application server for 30+ years and it will continue to be an application system for a very long time.

The point of history

The point of this review is to show you through the power of numbers, the many different ways IBM i and its predecessors have survived and flourished throughout the years. It’s a platform that evolves and thrives and allows critical business applications to run almost unchanged year after year. It can run on multiple platforms (even in the cloud), you can run code for decades, add new capabilities to your systems through third-party vendors, and use open source to extend the platform in ways beyond what even IBM has intended.

As we’ve written before, IBM POWER systems running IBM i can keep pace with the exponentially increasing demand for business applications. It’s an incredible and flexible platform that will be used for business processing for years to come. The numbers won’t lie.

Debugging constants in RPG

There have been times when I am debugging a multi-thousand line program when I find a line of code that can look something like:

1414.00 dou (X = Const1) ;

I can see what value is in variable X. But my attempts to see what is in Const1 is met with:

EVAL Const1

Identifier does not exist.
Read more »

Protect Your Organization by Preventing Ransomware

Ransomware attacks have been prominent in the news lately, but for every such breach that is widely publicized, there are many others that go unreported in the press. Companies of all sizes are affected by the problem.

Unfortunately, many don’t take proactive steps to limit their exposure until they have been victimized. A single ransomware attack can cost hundreds of thousands (or even millions) of dollars and can frequently lead to the dismissal of senior IT personnel. To make matters worse, paying hackers a ransom to unlock your data and systems doesn’t necessarily provide a solution.  Even when you pay ransomware, the tools provided by the ransomware hacker may not immediately allow the recovery of your data.  You can run into issues like getting the wrong key, a bad decryption utility, compatibility issues and other challenges can delay the recovery of your data.

If your organization is running IBM i systems, you may think that your risk is limited by virtue of its history as a relatively secure platform. Hackers have traditionally sought out targets running Windows-based systems or Linux variants that are in more widespread use. In fact, there is currently no malware in existence that is known to target the IBM i operating system per se, but businesses running IBM i should not take that as an assurance that they’re not at risk.

Many IBM i systems are plagued by poor security practices that leave them exposed to potential attackers. Here’s a review of some of the common sources of security risk on the IBM i platform, along with the experts’ recommendations on protecting against intrusions and malware infection.

How IBM i Systems May be Infected

There are two fundamental ways in which malware might be introduced into an IBM i system. First, it may be stored on the integrated file system (IFS) by a hacker who gains direct access. Second, malware may be introduced through a workstation where there is a mapped drive to an IFS share. The worst possible scenario is to have a read-write share to Root, which exposes your entire system to hackers. In this scenario, anyone with a user profile can compromise your entire system.

Unlike Windows, IBM i systems do not apply permissions to a shared directory. Instead, all shares are defined as being read-write or read-only, and users are granted authority to either access the directory or not and are granted authorities on specific objects within the directory.

Watch our Webcast

Configuration Tips to Reduce the Risk of IBM i Malware Infection

To learn more about securing your IBM i systems against ransomware and other malware attacks, watch our free on-demand webcast.

Controlling Access Via File Shares

To reduce risk, system administrators should remove unused shares and restrict existing shares to read-only status wherever possible. In addition, they should restrict user access to the objects within those shares, being careful to limit access on an as-needed basis. Very often, we see systems in which shares were created at some point in the past, but are not currently needed, and, in fact, have not been used for quite a long time.

As a first step, system administrators should perform an audit of existing file shares (either by using the IBM Navigator, or with the SQL tool (QSYS2.server_share_info service) to return a list of existing shares. Remove any unused shares, and wherever possible, set existing shares to read-only status. To the extent that shares must allow write access, limit authorities to those users who absolutely require it. This limits exposure to only those users who have access to the path, including users with *ALLOBJ permissions.

It’s also a good practice to set up shares so that they do not automatically reconnect at logon, unless they are used very frequently by the users at the workstation in question. It is common to find users who have not accessed such shares in a very long time, including those who have changed jobs and no longer require access to it.

Whenever possible, it is also a good practice to set up file shares to be hidden. By appending the sharing with the “$” character, the share will be invisible to attackers (or anyone else) who is simply browsing the system looking for open directories. This is commonly known as “security through obscurity.” Hackers cannot get information if they do not know that it even exists. While this does not prevent someone from connecting to the share per se, it does require that they be aware of its existence, know its exact name, and enter that information to connect.

Likewise, it’s good practice to turn off broadcasting of the NetServer. Again, this provides some protection by making it difficult for hackers to discover and navigate your systems. If a Guest profile is assigned to the NetServer, remove it.

The Risk of Read-Only Shares

Although much of the attention is focused on preventing hackers from gaining read-write access, system administrators should not neglect security with respect to read-only directories. In ransomware attacks, it is common practice for hackers to download information and retain a copy before they encrypt your data. Furthermore, attackers can do considerable damage to your organization simply by reading and exposing information in your IBM i system. If customer names and personally identifiable information are revealed, for example, your organization may suffer severe reputational damage and is likely to experience legal consequences as well.

Other Security Measures

A critically important security measure is to secure Root, which is open by default when IBM i systems ship. New directories created under Root inherit those permissions, which creates a security risk.

Experts also recommend securing your QPWFSERVER authorization list to restrict access to “QSYS.lib” from Windows Explorer and Navigator in cases where a share to Root is absolutely required.

It’s also good practice to segment your network, making it difficult for hackers to navigate and gain access to all of your systems.

Finally, educating your users is critical. Everyone in your organization should understand what a phishing email looks like, should know to avoid opening links within those emails, and should know who to call in the event that they receive potentially malicious messages.

A Proactive Approach to Security

Precisely has been working with IBM i systems for years. Our Assure security solution provides comprehensive malware defense, monitoring and reporting, data privacy, and access control capabilities for IBM i. If you are concerned about ransomware specifically, as every system administrator should be, then our Assure Security products can help you proactively manage security and establish confidence that your organization can operate with multiple layers of defense and minimal risk.

To learn more about securing your IBM i systems against ransomware and other malware attacks, watch our free on-demand webcast, Configuration Tips to Reduce the Risk of IBM i Malware Infection.

The post Protect Your Organization by Preventing Ransomware appeared first on Precisely.

Verified by MonsterInsights