z/OS concepts
Previous topic | Next topic | Contents | Glossary | Contact z/OS | PDF

What is a catalog?

z/OS concepts

A catalog describes data set attributes and indicates the volumes on which a data set is located.

When a data set is cataloged, it can be referred to by name without the user needing to specify where the data set is stored. Data sets can be cataloged, uncataloged, or recataloged. All system-managed DASD data sets are cataloged automatically in a catalog. Cataloging of data sets on magnetic tape is not required, but doing so can simplify users' jobs.

In z/OS®, the master catalog and user catalogs store the locations of data sets. Both disk and tape data sets can be cataloged.

To find a data set that you have requested, z/OS must know three pieces of information:
  • Data set name
  • Volume name
  • Unit (the volume device type, such as a 3390 disk or 3590 tape)

You can specify all three values on ISPF panels or in JCL. However, the unit device type and the volume are often not relevant to an end user or application program. A system catalog is used to store and retrieve UNIT and VOLUME location of a data set. In its most basic form, a catalog can provide the unit device type and volume name for any data set that is cataloged. A system catalog provides a simple look-up function. With this facility the user need only provide a data set name.

A z/OS system always has at least one master catalog. If it has a single catalog, this catalog would be the master catalog and the location entries for all data sets would be stored in it. A single catalog, however, would be neither efficient nor flexible, so a typical z/OS system uses a master catalog and numerous user catalogs connected to it as shown in Figure 1.

A user catalog stores the name and location of a data set (dsn/volume/unit). The master catalog usually stores only a data set high-level qualifier (HLQ) with the name of the user catalog, which contains the location of all data sets prefixed by this HLQ. The HLQ is called an alias.

In Figure 1, SYSTEM.MASTER.CATALOG is the data set name of the master catalog. This master catalog stores the full data set name and location of all data sets with a SYS1 prefix such as SYS1.A1. Two HLQ (alias) entries were defined to the master catalog, IBMUSER and USER. The statement that defined IBMUSER included the data set name of the user catalog containing all the fully qualified IBMUSER data sets with their respective location. The same is true for USER HLQ (alias).

When SYS1.A1 is requested, the master catalog returns the location information, volume(WRK001) and unit(3390), to the requestor. When IBMUSER.A1 is requested, the master catalog redirects the request to USERCAT.IBM, then USERCAT.IBM returns the location information to the requestor.

Figure 1. Catalog concept
Take, as a further example, the following DEFINE statements:
These statements are used to place IBMUSER and USER alias names in the master catalog with the name of the user catalog that will store the fully qualified data set names and location information. If IBMUSER.A1 is cataloged, a JCL statement to allocate it to the job would be:
If IBMUSER.A1 is not cataloged, a JCL statement to allocate it to the job would be:

As a general rule, all user data sets in a z/OS installation are cataloged. Uncataloged data sets are rarely needed and their use is often related to recovery problems or installation of new software. Data sets created through ISPF are automatically cataloged.

So, what happens if an installation loses its master catalog, or the master catalog somehow becomes corrupted? Such an occurrence would pose a serious problem and require swift recovery actions. To save this potential headache, most system programmers define a back-up for the master catalog. The system programmer specifies this alternate master catalog during system start-up. In this case, it's recommended that the system programmer keep the alternate on a volume separate from that of the master catalog (to protect against a situation in which the volume becomes unavailable).

Copyright IBM Corporation 1990, 2010