Explain The z/OS Catalog Structure in IBM Mainframes

51 / 60

z/OSintermediate

The z/OS Catalog Structure

Understand how the z/OS catalog maps dataset names to their physical volume locations and why catalog integrity matters operationally.

A DD statement names a dataset and not a volume:

The master catalog is a building directory in a lobby that doesn't list every single employee, just which floor's department directory (the user catalog) to check next — you never need to know someone's exact office number in advance, you just follow the lobby sign to the right floor's directory, which then gives you the precise room.

Key Concepts

    //CUSTFILE DD DSN=PROD.CUSTOMER.MASTER,DISP=SHR

The catalog is what turns that name into a physical location. Without it you would specify the volume on every reference, and moving a dataset would mean editing every job that reads it.

Two levels: master and user catalogs.

    master catalog
      alias PROD  -> user catalog UCAT.PROD
      alias TEST  -> user catalog UCAT.TEST
      alias SYS1  -> (entries held directly)

The master catalog is found at IPL and is deliberately small. It holds aliases rather than every dataset — putting millions of entries in one catalog would make it a bottleneck and a single point of failure.

How a lookup works. Take the high-level qualifier, find the matching alias, go to that user catalog, find the entry there.

    PROD.CUSTOMER.MASTER
      -> HLQ is PROD
      -> alias PROD points at UCAT.PROD
      -> UCAT.PROD says volume PRD001

Which is why the high-level qualifier is not cosmetic. It selects the catalog. A new HLQ with no alias defined produces "dataset not found" for a dataset that exists perfectly well on disk — the system simply has nowhere to look.

The failure mode worth understanding: an uncatalogued dataset. The data is on a volume and the catalog entry is gone or was never made.

    DISP=SHR, DSN=PROD.OLD.FILE   -> not found
    the file is on PRD007, intact

It can still be read by specifying the volume explicitly, and it is invisible to anything that goes by name. That is what DISP=(NEW,KEEP) produces — kept, not catalogued — and why KEEP without CATLG is almost always wrong on a modern system.

DISP=(NEW,KEEP)KEEPCATLG

The reverse is worse. A catalog entry pointing at a dataset that no longer exists gives "not found" at OPEN despite the catalog saying it is there. Both directions are repaired with IDCAMS DEFINE RECATALOG or DELETE NOSCRATCH.

DEFINE RECATALOGDELETE NOSCRATCH

LISTCAT is how you ask.

    LISTCAT ENTRIES(PROD.CUSTOMER.MASTER) ALL

LISTCAT

It shows the volume, the allocation, and for VSAM the split counts and high-used RBA. It is the first step whenever a dataset is not where a job expects it.

What the interviewer is probing.1. "What does the catalog do?" Probing: the purpose. Stalls: "Lists files." Moves up: maps a dataset name to the volume holding it, so JCL does not need to state where anything lives.

2. "What is the relationship between the master and user catalogs?" Probing: the structure. Stalls: "One catalog." Moves up: the master catalog holds system datasets and an alias per high-level qualifier pointing at the user catalog that owns it.

3. "What happens if an alias is missing?" Probing: the failure mode. Stalls: "Nothing." Moves up: the dataset is looked for in the master catalog and not found, so jobs fail with a not-cataloged condition.

4. "What is an uncataloged dataset?" Probing: the detail. Stalls: "A deleted file." *Moves up:* one that exists on a volume but has no catalog entry, so JCL must supply UNIT and VOL=SER explicitly.