z/OS orientation: address spaces, datasets, catalogs, JES2, and what SSH into USS can see

What it is

A z/OS system runs many independent address spaces rather than one shared process table: each batch job, each started task (like a subsystem or a server), each TSO user session, and z/OS UNIX System Services (USS, the POSIX-conformant subsystem) itself occupies its own address space or set of them. There is no single ps-equivalent view across the whole system from inside one address space; z/OS UNIX shell commands like ps show only z/OS UNIX processes (and, without superuser authority, only your own), not JES-managed batch jobs or started tasks unless those happen to use UNIX services.

Persistent data lives in datasets, not in one filesystem tree. A dataset has a name such as HLQ.PAYROLL.INPUT, a record format and record length (RECFM/LRECL, covered in the next article), and is located through a catalog rather than a directory path — "where is this dataset" is a catalog lookup, not a path traversal. z/OS UNIX files (HFS or zFS-backed) do form a Unix-like hierarchy under /, and that hierarchy is itself typically anchored inside a dataset, but classic datasets referenced as HLQ.NAME are outside that tree and need their own access syntax from a shell (see the next article).

Batch work is scheduled and tracked by JES2 (IBM's JES3 was dropped after z/OS 2.3; the few remaining JES3 sites use a third-party successor): submitting, queueing, running, and holding job output (spool). TSO/E is the interactive command environment, most often used through ISPF, a menu- and panel-driven interface for editing datasets, browsing spool output, and running utilities; USS is a peer environment to TSO, not a replacement for it. z/OSMF (z/OS Management Facility) is IBM's task-oriented, browser-based interface layered over many of these functions, and it exposes REST APIs that are the most agent-friendly way to interact with jobs and datasets (a separate article covers those).

Why it matters

An agent that lands in a USS shell over SSH is one participant among many independent address spaces, with visibility into USS processes and the parts of the dataset/catalog namespace it has access to — not an operator's view of the whole LPAR. Assuming ps, top, or file listings under / show "everything running" or "everything stored" on the system will produce a badly incomplete picture.

How to apply

• Distinguish "not visible from my USS shell" from "not running/not existing" — batch jobs and started tasks need JES/SDSF or z/OSMF to see, not ps.
• Treat a dataset name as a catalog lookup key, not a filesystem path, even when a //'...' shell notation makes it look path-like.
• Reach for TSO/ISPF, SDSF, or the z/OSMF REST APIs (not USS shell tools alone) for anything involving batch jobs, spool output, or classic (non-USS) datasets.

Pitfalls

• Assuming file permissions inside USS govern access to classic datasets; dataset access is governed separately (see the RACF article).
• Assuming a single IPL (system start) event and a single address-space lifetime line up with "system uptime" the way a Linux boot does; individual address spaces start and end far more often than the LPAR itself IPLs.