What Is AS400 (IBM i)? A Complete Beginner’s Guide

AS400 usually means a business application running on IBM i, an operating system, on top of IBM Power, the server hardware it runs on. AS/400 was IBM’s original name for this platform, introduced in 1988. The operating system and hardware have both been renamed and modernized several times since then. The term AS400 survives today as an informal, widely searched shorthand for the whole lineage, even though it has not been the platform’s official product name for decades.

This guide keeps three things separate throughout: the historical product names, the current operating system, and the current server hardware. Once those three are untangled, the rest of the platform – its database, its programming languages, and the reasons organizations still run it – becomes much easier to understand.

Quick Summary

• AS400 – The common informal name people still use today.
• AS/400 – IBM’s original business computer introduced in 1988.
• IBM i – The current operating system.
• IBM Power – The current server hardware that runs IBM i.

Throughout this guide, AS400 is used as the common search term, while IBM i and IBM Power are used when referring to the modern platform.

What Is AS400?

A Simple Definition

AS400 is the common, informal name for a family of IBM business computing systems that began with the AS/400 in 1988 and continues today as IBM i running on IBM Power hardware. When someone says an application “runs on the AS400,” they typically mean it runs on a current IBM i system, not on decades-old equipment.

Is AS400 Hardware, Software, or Both?

The honest answer depends on which era you mean. The original AS/400 was sold as a single integrated product that bundled hardware and an operating environment together, so at the time the term reasonably meant both. Today the two halves have separate names: IBM i is the operating system, and IBM Power is the server hardware family it runs on. Referring to “the AS400” as a single object still works in casual conversation, but a precise answer separates the software from the hardware.

What Does AS/400 Stand For?

AS/400 stands for Application System/400. IBM used the name to describe an integrated business application system, and “400” identified the specific product line within IBM’s broader midrange computing history.

Is AS400 the Same as IBM i?

Why People Still Call It AS400

AS/400 was the platform’s name for over a decade, and it earned a strong reputation during that time for dependable, low-maintenance business computing. That reputation is part of why “AS400” persisted in everyday conversation and in search behavior long after IBM renamed the product several times. People are not wrong to use the term informally; they are simply using a historical name for a platform that has since evolved.

The Difference Between AS400, IBM i, and IBM Power

AS400 is not a single, precise technical term; it functions more like an umbrella phrase. AS/400 was a specific historical product, IBM i is the current operating system in that product lineage, and IBM Power is the current server hardware family that IBM i runs on. None of these three terms are interchangeable: IBM i is never the hardware, and IBM Power is never the operating system.

A Simple Terminology Table

Keep this table in mind while reading the rest of this guide: whenever you see “AS400” used loosely, you can usually substitute “IBM i on IBM Power” and be accurate.

How the AS400 Platform Evolved

AS/400 and OS/400

IBM introduced the Application System/400 in 1988 as an integrated midrange computer. The operating system that shipped with it was called OS/400. Being integrated meant the system combined an operating environment, a database, security, and development tools that were designed to work together. Teams did not have to assemble those infrastructure components separately by hand.

iSeries and System i

As IBM reorganized its server product lines, the platform was rebranded more than once. It became known as iSeries in the early 2000s, as part of a wider effort to align IBM’s server brands under a common naming scheme. It was later rebranded again as System i when IBM simplified its hardware branding further. Neither rebrand changed the underlying platform’s core design philosophy; they changed how IBM marketed and packaged it.

IBM i on IBM Power

The platform’s current names reflect a cleaner split than its historical ones: IBM i is the operating system, and IBM Power is the server hardware family. A single physical Power server can run IBM i in a logical partition, or LPAR. An LPAR is an isolated slice of the server’s processors, memory, storage, and network resources, and a server can run several of them side by side alongside other supported operating environments.

Why the Older Name Survived

Product names changed several times, but the people who worked with the platform did not update their habits as quickly. The term AS400 had already become common usage by the time IBM moved on to iSeries, System i, and finally IBM i. That is why an accurate explanation of the platform still has to start by acknowledging the name most people actually use.

How IBM i Works

IBM Power Server Hardware

IBM Power is the physical server hardware family that runs IBM i today. A Power server provides the processors, memory, storage, and network resources that everything else in the platform depends on. IBM i is not a hardware product; it is one of the operating environments that can run on Power hardware.

IBM i Operating System

IBM i manages applications, users, jobs, and system resources on top of that hardware. Compared with assembling a database, a security layer, and job-scheduling tools as separate products, IBM i bundles these as integrated services with consistent administration conventions. That integration reduces the number of moving parts an administrator has to coordinate, though it does not remove the need for skilled administration altogether.

One of IBM i’s defining characteristics is its object-based architecture. Programs, databases, libraries, user profiles, printers, queues, and many other resources are managed as typed objects with well-defined attributes and authorities. This consistent object model simplifies administration while providing strong security and system integrity.

Another unique architectural feature is single-level storage. IBM i presents memory and disk storage through a unified addressing model, allowing applications to work with data without needing to manage separate memory and disk structures directly. Although most administrators rarely think about this feature day to day, it is one of the technologies that has contributed to the platform’s long-term stability.

Db2 for i Integrated Database

Db2 for i is the relational database built into IBM i rather than installed as a separate product. Applications can use traditional externally described files as well as standard SQL tables, views, and stored procedures, and most modern development on the platform uses SQL directly. Because the database is part of the operating system rather than a bolt-on product, it shares IBM i’s security and object model instead of maintaining a separate one.

Applications, Jobs, and Users

Work on IBM i is organized as jobs running under user profiles with defined authorities, giving administrators fine-grained control over who can do what. People interact with IBM i applications in more than one way. Character-based 5250 screens – navigated with fields, function keys, and menus – remain common for internal, high-volume data entry because they are fast for trained staff. The same applications, or newer ones built alongside them, can also expose web interfaces and APIs for customers, mobile apps, or other systems. A 5250 screen and a modern web interface can both be talking to the same underlying IBM i application.

A Simplified Platform Architecture

Put together, the platform looks like a set of layers, with business processes and applications at the top and IBM Power hardware providing the foundation at the bottom.

Consider a wholesale distributor as an example. A customer-service employee enters an order through a 5250 screen or a web form. An application service validates the customer and calculates pricing. Db2 for i stores the order. A batch process later allocates inventory and produces shipping documents. Every layer in the diagram above plays a part in that one transaction.

What Is AS400 Used For?

IBM i is used across industries that depend on predictable, high-volume transaction processing and long-lived business logic. The following patterns are common, though the exact mix varies by organization.

Banking and Financial Services

Core account, transaction, and back-office processing are common workloads, where predictable performance and data integrity matter more than a flashy interface.

Retail and Distribution

Order entry, inventory management, and distribution logistics are common uses, often built up over years to reflect an organization’s specific pricing, promotions, and fulfillment rules.

Manufacturing

Production planning, materials management, and supply-chain coordination frequently run on IBM i, particularly where the same application has tracked a manufacturer’s operations for a long time.

Healthcare and Insurance

Claims processing, policy administration, and patient or member record systems are common, where reliability and controlled access to sensitive data are priorities.

Logistics and Other Transaction-Heavy Industries

Any business with a steady, high volume of structured transactions – shipping, warehousing, wholesale distribution – is a plausible fit for the kind of workload IBM i was designed to run well.

Which Programming Languages Are Used on IBM i?

RPG

RPG is the programming language most closely associated with the platform. Older applications may use its original fixed-format syntax, while current RPG supports free-form syntax, procedures, and direct SQL access, and is still actively used for new development as well as maintenance of existing applications.

COBOL

COBOL also has a long history on the platform and remains in use in some environments, particularly for applications built before RPG became the more common choice for new IBM i development.

Control Language

Control Language, or CL, is used to run commands, submit batch jobs, and coordinate operational work rather than to build user-facing application logic. It functions more like a scripting and job-control language than an application language.

SQL and Db2 for i Development

Standard SQL is fully supported against Db2 for i. Most current development queries and updates data with SQL rather than older file-access techniques, whether that SQL is embedded in RPG, called from another language, or run directly.

Java, Python, JavaScript, and Modern Integration

IBM i also supports Java, and open-source languages including Python and Node.js can run on the platform as well, alongside tools for building and consuming web services. This means a single IBM i system can run decades-old RPG next to a recently written Java or Python service, which is often the reality inside a mature IBM i environment rather than the exception.

Why Do Companies Still Use IBM i?

Reliability and Workload Continuity

Organizations that depend on IBM i for core operations generally do so because the platform has supported those workloads reliably over a long period, and replacing a working system carries its own risk.

Integrated Platform Design

Because the database, security model, and job management share one consistent design, administrators work with fewer separately maintained products than on a stack assembled from many independent components.

Long-Lived Business Applications

Many IBM i applications encode years or decades of accumulated business rules, such as pricing logic, regulatory requirements, and exception handling. Rebuilding all of that from scratch would be costly and risky without a clear business reason to do so.

Security and Controlled Operations

IBM i provides object-level authority controls and a security model that many organizations have built compliance and audit processes around over time. That does not mean every IBM i environment is automatically well secured; like any platform, its safety depends on how it is configured, patched, and administered.

Compatibility and Incremental Modernization

The platform has historically emphasized protecting existing applications across hardware and operating-system generations, subject to normal release and dependency requirements. That compatibility lets teams add SQL access, web services, and newer development practices incrementally, without having to replace an entire application at once.

What Are the Limitations of AS400 and IBM i?

A fair picture of the platform has to include its real limitations alongside its strengths.

Skills Availability

Experienced IBM i developers and administrators can be harder to find than generalist skills for more commonly taught platforms, which is a genuine planning consideration for organizations that rely on the platform.

Legacy Application Complexity

Applications maintained over many years can accumulate undocumented logic, inconsistent coding styles, and dependencies that are not obvious from the outside, regardless of which platform they run on. IBM i applications are not immune to this, and long tenure alone does not guarantee well-organized code.

User-Interface Perception

Character-based 5250 screens are still associated with the platform in many people’s minds, even though a given IBM i application may also expose a modern web or mobile interface. That perception gap can make the platform look more dated than the actual application architecture underneath it.

Modernization Cost and Planning

Modernizing an IBM i environment – whether that means new interfaces, refactored code, or new integration points – takes real planning, budget, and testing, the same as modernizing any mature system on any platform.

Integration Challenges in Older Environments

Older IBM i environments that were never updated to use SQL, web services, or current security practices can be genuinely harder to integrate with modern tools than a system that has been kept current. This is a property of how well a specific environment has been maintained, not an inherent property of the platform itself.

Is AS400 Obsolete?

The Original AS/400 Name Versus the Current Platform

The AS/400 product name is historical, but the platform lineage it started is not frozen in time. Current IBM i releases run on current IBM Power hardware and continue to receive updates. Calling the AS/400 obsolete is really a claim about a 1988 product name, not an accurate description of what a current IBM i environment actually runs on.

Legacy Applications Are Not Necessarily Unsupported Systems

An application that has run for many years is not automatically an unsupported or unsafe system. Some long-lived IBM i applications run on current, supported releases with active maintenance; others run on outdated releases with real technical debt. The application’s age tells you very little on its own – what matters is its current release level, support status, and how well it has been maintained.

When Modernization May Still Be Necessary

Modernization becomes genuinely necessary when an environment runs unsupported software releases, depends on undocumented logic that nobody currently understands, or can no longer meet integration, security, or compliance requirements. None of those conditions are unique to IBM i; they can affect a poorly maintained system on any platform.

AS400 Compared with Other Enterprise Platforms

These comparisons are intentionally conceptual. They are not benchmark results, pricing comparisons, or claims that one platform is universally better than another.

AS400 Versus Mainframe

IBM i and mainframe systems (such as IBM Z) are both enterprise platforms associated with reliable, high-volume transaction processing, and the two are sometimes confused with each other. They are different product families with different architectures, operating systems, and typical use cases, even though both are often described – loosely and sometimes inaccurately – as “legacy” systems.

IBM i Versus Windows or Linux Servers

A Windows or Linux environment is typically assembled from separately chosen and configured components: an operating system, a database product, an application server, and security tooling. IBM i takes a different approach, bundling the operating system, database, and core services together as one integrated product. Each approach has real trade-offs in flexibility, tooling ecosystem, and administrative model. Neither is a universally superior choice for every workload.

Integrated Platform Versus Assembled Technology Stack

The most useful way to think about this comparison is integration versus assembly, not old versus new. An integrated platform like IBM i can simplify operations for the workloads it fits well, while an assembled stack can offer more flexibility to mix and match individual components. Which approach fits a given organization depends on its specific workloads, existing skills, and operational priorities.

Can IBM i Integrate with Cloud and Modern Applications?

APIs and Web Services

IBM i applications can expose and consume web services and APIs, which allows existing business logic to be reused by new front ends or by other systems instead of being rewritten from scratch.

Data Integration

Because Db2 for i supports standard SQL, IBM i data can be queried and integrated with reporting tools, analytics platforms, and other systems using familiar SQL-based approaches rather than platform-specific techniques alone.

Modern User Interfaces

Existing IBM i business logic can sit behind new web or mobile interfaces, letting an organization modernize what users see without necessarily rewriting the underlying application logic in the same project.

Hybrid-Cloud and Modernization Patterns

Organizations commonly take an incremental approach. Core IBM i workloads stay in place while connecting to cloud-based services, analytics platforms, or newer applications through APIs and data integration, rather than attempting a single, all-at-once migration.

Modernization rarely means replacing everything at once. Many organizations keep proven RPG applications while exposing them through REST APIs, building modern web or mobile interfaces, adopting Git-based development workflows, introducing DevOps automation, and integrating IBM i with cloud platforms. This incremental approach allows organizations to modernize business capabilities while preserving valuable business logic.

Is AS400 a Good Career Skill?

Common IBM i Roles

IBM i work spans several roles, including RPG and COBOL developers, system administrators, and database or SQL specialists who work with Db2 for i. Other roles combine IBM i knowledge with modern integration or web development skills.

Legacy and Modern Skills to Learn Together

Many IBM i environments mix decades-old RPG with recently added SQL, web services, and open-source languages. The most versatile skill combination pairs core platform knowledge, such as objects, libraries, jobs, and authorities, with current development practices like SQL, APIs, and source control, rather than choosing one side exclusively.

A Beginner Learning Path

A practical starting point is learning how IBM i organizes libraries, objects, jobs, and user authorities. From there, practice basic SQL against Db2 for i, and learn to read RPG in both its older fixed-format and current free-form styles. Working in a non-production environment while learning is the safest way to experiment with commands and code.

Frequently Asked Questions

Is AS400 still used?

Yes. Many organizations continue to run IBM i, the current operating system in the AS400 lineage, on IBM Power hardware for core business applications. Being still used is not the same thing as being unchanged since 1988: the platform that runs today is not the same hardware or software as the original AS/400.

Is AS400 a mainframe?

No. AS400 (IBM i on IBM Power) and mainframe systems such as IBM Z are different product families with different architectures. People sometimes group them together loosely as “legacy enterprise systems,” but they are not the same platform.

Is IBM i an operating system?

Yes. IBM i is the operating system in the AS400 lineage. It is not a piece of hardware; it runs on IBM Power server hardware, typically inside a logical partition.

What database does AS400 use?

The integrated database is Db2 for i. It ships as part of IBM i rather than as a separate product, and it supports standard SQL alongside the platform’s traditional file-access methods.

Which language is used in AS400?

There is no single language. RPG and COBOL are the most historically associated languages, CL handles commands and job control, SQL is used for most current database work, and Java, Python, and Node.js are also supported for newer development.

Can AS400 connect to cloud services?

Yes, through APIs, web services, and standard data-integration techniques. IBM i applications are not limited to running in isolation; they can expose and consume services the same way applications on other platforms do.

Is AS400 difficult to learn?

It has its own vocabulary and conventions – libraries, objects, jobs, authorities – that take some initial orientation, similar to learning any platform’s core concepts. Beyond that initial learning curve, the core skills of reading RPG, writing SQL, and understanding job and security basics are approachable for a motivated beginner.

What is the modern replacement for AS400?

There isn’t one, in the sense of a separate successor product: IBM i on IBM Power is the current, actively maintained continuation of the same platform lineage, not something a different product has replaced.

What to Learn Next

This guide intentionally stays at the fundamentals level. Once the terminology and platform basics here feel solid, a natural next step is a deeper look at IBM i’s architecture: how libraries, objects, and jobs actually fit together. Focused introductions to RPG and Control Language, a closer look at developing against Db2 for i, and a more detailed treatment of modernization approaches are natural follow-ups after that. A conceptual comparison between IBM i and mainframe systems, and a more structured career roadmap for IBM i skills, round out the same cluster of topics.

References

• IBM Documentation – IBM i
• IBM Documentation – Db2 for i
• IBM Documentation – IBM Power
• IBM Redbooks – IBM i Technical Publications

Conclusion

AS400 is the informal, enduring name for a platform lineage that started with the AS/400 in 1988 and continues today as IBM i running on IBM Power hardware. Its ecosystem includes an integrated database in Db2 for i, established languages like RPG and COBOL alongside SQL and modern languages, and both traditional and web-based interfaces. Organizations keep using it where it reliably supports valuable business applications, and the platform continues to receive updates rather than standing still. The most accurate way to evaluate any specific IBM i environment is to look at its current release, its application architecture, and how well it has been maintained. The decades-old nickname people still use to refer to it says very little on its own.