In VSAM terminology, a sphere is the logical grouping of a base cluster and all its associated alternate indexes (AIXs). The base cluster is the main dataset (KSDS, ESDS, RRDS, or LDS) that holds the data. The associated clusters are the alternate index clusters built over that base—each AIX lets you access the same data by an alternate key. Together, the base and its AIXs form one "sphere" for operations such as backup, recovery, migration, or deletion. Understanding the sphere helps you know what to include when you export, import, or reorganize a VSAM file that has alternate indexes. This page explains what a sphere is, how it relates to clusters and paths, and why it matters.
A sphere is the set of all VSAM objects that belong together logically: one base cluster and every alternate index cluster that references it. The base cluster is the primary dataset—for example a KSDS that holds customer data with a primary key of customer ID. An alternate index might be built over that same data with an alternate key such as last name or account number. Each alternate index is a separate cluster (with its own data and index components), but it is "associated" with the base because it points to records in the base. The sphere is the base plus all those associated AIX clusters. So you can think of the sphere as "the base cluster and everything that depends on it."
If a base cluster has no alternate indexes defined (or none built), its sphere contains only that one base cluster. Many VSAM files have no AIXs, so for those the sphere is just the cluster itself. The concept becomes important when you have one or more alternate indexes: backup, recovery, and migration tools often work at the sphere level so that the base and all AIXs are handled together and stay consistent.
The base cluster is the VSAM dataset that holds the actual application data. For a KSDS it has a data component and an index component. For an ESDS or RRDS it has only a data component. Applications typically open the base cluster (or a path to it) and read or write by primary key, RBA, or RRN. The base is what you define with DEFINE CLUSTER and load with REPRO or application writes.
Associated clusters are the alternate index clusters. Each alternate index is defined with DEFINE ALTERNATEINDEX (or DEFINE AIX) and is built over the base with BLDINDEX. The AIX has its own data and index components; its data component holds alternate key values and pointers (e.g. primary keys or RBAs) into the base. A path (DEFINE PATH) links the base and the AIX so that an application can open the base by alternate key. Those AIX clusters are "associated" with the base—they reference it and are part of its sphere.
| Part | Description |
|---|---|
| Base cluster | The main VSAM dataset (KSDS, ESDS, RRDS, or LDS). Contains the data component and, for KSDS, the index component. This is what applications usually access by primary key or RBA/RRN. |
| Associated clusters (AIXs) | Alternate index clusters that are built over the base cluster. Each AIX provides an alternate key and points to the base. Paths define the logical connection between the base and each AIX. |
When you back up or migrate a VSAM file, you usually want to preserve not only the base cluster but also every alternate index that points to it. If you restore only the base and not the AIXs, the alternate indexes are missing or out of date. If you restore the AIXs from an older backup than the base, they may point to wrong or deleted records. So backup and recovery procedures often treat the sphere as the unit of work: export the base and all its AIXs together, and import them together so that base and AIXs stay in sync.
Similarly, when you delete a base cluster, you typically need to delete or at least uncatalog its alternate indexes and paths first (or use a utility that deletes the whole sphere). If you delete only the base, the AIX clusters and paths would be left pointing at a dataset that no longer exists. So the sphere is the natural boundary for "this whole logical file."
A path is the logical connection that lets an application access the base cluster by an alternate key. When you define a path, you associate an AIX with the base. The path is not a separate dataset; it is a catalog entry that ties the two together. So the sphere includes the base cluster and all AIX clusters; the paths are the way those AIXs are used with the base. When listing or backing up a sphere, you may see the base, the AIX clusters, and the path names that reference them.
Suppose you have a KSDS named MY.USER.CUSTOMER (base cluster) with two alternate indexes: one by last name (MY.USER.CUSTOMER.BYLNAME) and one by account number (MY.USER.CUSTOMER.BYACCT). The sphere for this file is:
Paths might be MY.USER.CUSTOMER.LNAME and MY.USER.CUSTOMER.ACCT. When you export or back up the sphere, you include the base and both AIX clusters so that after a restore, all three are consistent.
Imagine the base cluster as the main book (your data). The alternate indexes are like the index at the back that says "find by last name" or "find by account number." The sphere is the book plus all those indexes together. When you put the book in a safe (backup), you put the book and all its indexes so that when you take them out again, everything still matches.
1. What does a VSAM sphere consist of?
2. If a KSDS has no alternate indexes, what is its sphere?
3. Why is the sphere concept useful for backup?