The z/OS Operating System
Understand what z/OS is, how it manages thousands of workloads simultaneously, and learn essential terminology: LPAR and address space.
Introduction
You have looked at the hardware a mainframe is built from. Now it is time to look at the software layer that turns that hardware into something people and applications can actually use: z/OS. Everything else in this course — TSO, ISPF, datasets, JCL, CICS, DB2, RACF — is either part of z/OS or runs on top of it, so getting comfortable with its core concepts now will pay off in every lesson that follows.
What is z/OS?
z/OS is IBM's primary operating system for IBM Z mainframe hardware. Like any operating system, its job is to manage hardware resources — processors, memory, storage, and network — on behalf of the programs that run on top of it. What sets z/OS apart from most other operating systems is the scale and rigor of that job: it is expected to manage thousands of concurrent programs and users, enforce strict isolation and security between them, and keep doing so reliably for years without a restart.
- A 64-bit operating system built specifically for IBM Z hardware
- Descended from decades of mainframe operating system development (see the History lesson)
- Designed to run enormous numbers of workloads concurrently, safely isolated from one another
- Manages batch jobs, interactive TSO sessions, transaction systems like CICS, and databases like DB2, often all at the same time on the same machine
LPARs: Slicing One Machine into Many
An LPAR (Logical Partition) is a division of a single physical mainframe into what behaves like several independent machines, each with its own share of processors, memory, and I/O resources, and each capable of running its own separate copy of z/OS (or another supported operating system). LPARs are defined and managed by firmware built into the mainframe hardware itself, called PR/SM, which enforces strict isolation between them.
In practice, a single physical mainframe in a large enterprise is commonly divided into several LPARs — for example, separate LPARs for production, test, and development workloads, all running on the same physical box but fully isolated from each other, so that a problem in a test LPAR cannot affect production.
| Concept | What It Represents |
|---|---|
| Physical mainframe | The actual hardware box (a single IBM Z machine) |
| LPAR | A logical slice of that hardware, behaving like its own independent system |
| z/OS instance | A separate running copy of z/OS, one per LPAR that runs it |
| Typical use | Production LPAR, test LPAR, development LPAR — isolated from one another on the same physical machine |
Address Spaces: How z/OS Isolates Work
Within a single running z/OS system, an address space is the unit of isolation for an individual piece of work — a batch job, a user's TSO session, a started task, or a subsystem like CICS or DB2. Each address space gets its own private view of virtual memory, so a program running in one address space cannot accidentally (or maliciously) read or corrupt the memory belonging to another. z/OS can manage many thousands of address spaces simultaneously.
An LPAR is a division of the physical hardware, and typically runs one full instance of z/OS. An address space is a division within a single running z/OS instance, isolating one unit of work from another. A mainframe might have a handful of LPARs, each of which is in turn running thousands of address spaces.
How z/OS Manages Many Workloads at Once
With potentially thousands of address spaces active at once — batch jobs, interactive users, transaction processing, database engines — z/OS needs a disciplined way to decide who gets processor time, memory, and I/O priority, and when. This is handled by a component generally referred to as Workload Manager (WLM), which lets system administrators define service goals (for example, "online transactions must respond within half a second" or "this batch job can run at lower priority overnight") and then continuously adjusts resource allocation across all active address spaces to try to meet those goals.
D A,LRESPONSE=SY1IEE114I 09.21.05 2026.060 ACTIVITY 811 JOBS(1) NOSWAP(0) NOJOBS(0) -ACTIVE- -IN OUTPUT- -TSU(3)- -STC(58)- NAME ASID ... PAYRJOB 0043 BATCH: month-end payroll run CICSPRD 004A STC: production CICS region DB2MSTR 0051 STC: DB2 master address space STUDENT1 0067 TSU: interactive TSO sessionClick Run to see what this code prints.
A Simplified Picture
Putting the layers together: a physical mainframe can be divided into several LPARs; each LPAR runs its own z/OS instance; and within each z/OS instance, work is isolated into many concurrently running address spaces, with Workload Manager continuously arbitrating who gets resources and when. This layered isolation is a major reason mainframes can safely host so many different workloads on one machine without them interfering with each other.
Common Mistakes
- Confusing an LPAR with an address space — an LPAR divides physical hardware; an address space divides work within one z/OS instance.
- Assuming z/OS can only run one program at a time like older, simpler operating systems — in reality it is designed for massive concurrency.
- Thinking of Workload Manager as a fixed, static priority list — it dynamically adjusts resource allocation to meet defined service goals.
- Assuming all LPARs on a machine share memory or can directly access each other's data — they are strictly isolated by design.
Best Practices
- When troubleshooting or reading documentation, be precise about whether you are discussing the physical machine, an LPAR, a z/OS instance, or an address space — they are not interchangeable.
- Remember that your own work (a TSO session, a submitted batch job) will run inside its own address space, isolated from everyone else's.
- When performance issues come up in a real shop, understand that Workload Manager goals, not just raw hardware capacity, often explain why one job runs faster than another.
- Build the mental layering (machine → LPAR → z/OS instance → address spaces) early — later lessons on TSO, JCL, and CICS will all build on it.
Frequently Asked Questions
An LPAR (Logical Partition) is a division of the physical mainframe hardware, typically running its own full z/OS instance. An address space is a division of work within one running z/OS instance — isolating a single job, task, or user session from all the others.
z/OS is designed to support thousands of concurrent address spaces on a single system, each isolated from the others, which is part of what allows a mainframe to run so many different workloads simultaneously.
Workload Manager (WLM) continuously allocates processor, memory, and I/O resources across all active address spaces according to administrator-defined service goals, so that higher-priority work (like online transactions) gets the resources it needs even while lower-priority work (like overnight batch) runs alongside it.
No, not in normal operation. LPARs are strictly isolated by the PR/SM firmware built into the mainframe hardware, so a problem in one LPAR (such as a test system crashing) does not affect other LPARs, including production.
Key Takeaways
- z/OS is IBM's primary mainframe operating system, built to manage thousands of concurrent, isolated workloads reliably.
- An LPAR (Logical Partition) divides one physical mainframe into several independent, isolated logical machines, typically each running its own z/OS instance.
- An address space is the unit of isolation for a single piece of work (a job, task, or session) within one running z/OS instance.
- Workload Manager (WLM) dynamically allocates resources across address spaces to meet defined performance goals.
- The layering — machine, LPAR, z/OS instance, address space — is fundamental vocabulary for everything else in this course.
Summary
z/OS is the software layer that turns mainframe hardware into a platform capable of safely, reliably running thousands of workloads at once, using LPARs to divide physical hardware and address spaces to isolate individual units of work within each running system. With this vocabulary in place, you are ready to actually start interacting with a mainframe. In the next lesson, you will learn about TSO — the Time Sharing Option — and how it gives you an interactive, command-line way to log on and work with a mainframe system.