Catalogs
Knowing where your data is stored is vital to perform any data-related tasks, from a simple open for I/O, to providing backups for availability management. Whether you are a small shop with a single LPAR and a few data sets, or a large system with dozens LPARs and millions of data sets to manage, catalogs provide you a simple, easy, and efficient way to organize information about your data sets.
In z/OS, catalogs are controlled by an embedded DFSMSdfp component that is called Catalog Management. Catalog Management has one address space for itself named catalog address space (CAS).This control allows a good catalog performance, while managing multiple requests to catalogs, and ensure catalog integrity. This chapter introduces you to z/OS catalogs structures, usage, and considerations.
This chapter includes the following sections:
6.1 The integrated catalog facility structure
Catalogs are data sets containing information about other data sets. They provide users with the ability to locate a data set by name, without knowing the volume where the data set resides. This feature means that data sets can be moved from one device to another, without requiring a change in job control language (JCL) DD statements that refer to an existing data set.
Cataloging data sets also simplifies backup and recovery procedures. Catalogs are the central information point for VSAM data sets, so all VSAM data sets must be cataloged. In addition, all SMS-managed data sets must be cataloged. Activity towards the catalog is much more intense in a batch/TSO workload than in a CICS/Db2 workload, where most data sets are allocated at CICS/Db2 initialization time.
An integrated catalog facility (ICF) catalog is a structure that replaced the former MVS CVOL catalog. As a catalog, it describes data set attributes and indicates the volumes on which a data set is located. ICF catalogs are allocated by the CAS, a system address space for the DFSMSdfp catalog function.
A catalog consists of two separate kinds of data sets:
•A basic catalog structure (BCS). The BCS can be considered the catalog.
•A VSAM volume data set (VVDS). The VVDS can be considered an extension of the volume table of contents (VTOC).
Figure 6-1 shows how BCS and VVDS work together to create the ICF catalogs structure.
Figure 6-1 The ICF catalog structure
6.1.1 Basic catalog structure
The BCS is a VSAM key-sequenced data set that contains the information about where a data set resides. That can be a DASD volume, tape, or other storage medium. Related information in the BCS is grouped into logical, variable-length, spanned records related by key. The BCS uses keys that are the data set names (plus one character for extensions).
One control interval can contain multiple BCS records. To reduce the number of I/Os necessary for catalog processing, logically-related data is consolidated in the BCS.
A catalog can have data sets cataloged on any number of volumes. The BCS can have as many as 123 extents on one volume. One volume can have multiple catalogs on it. All the necessary control information is recorded in the VVDS on that volume.
The catalogs (BCSs) can be classified as master catalogs and user catalogs. A particular case of a user catalog is the volume catalog, which is a user catalog that contains only the tape library and tape volume entries.
There is no structural difference between a master catalog and a user catalog. What sets a master catalog apart is how it is used, and what data sets are cataloged in it. For example, the same catalog can be master in one z/OS and user in the other z/OS. They are described in more detail in the following sections.
The master catalog
Each system has one active master catalog. One master catalog can be shared between various MVS images. It does not have to be on the system residence volume (the one that is restarted).
The master catalog for a system must contain entries for all user catalogs and their aliases that the system uses. Also, all SYS1 data sets must be cataloged in the master catalog for proper system initialization.
 
Important: To minimize update activity to the master catalog, and to reduce the exposure to breakage, plan to place only SYS1 data sets, user catalog connector records, and the aliases pointing to those connectors in the master catalog.
During a system initialization, the master catalog is read so that system data sets and catalogs can be located. You can identify the master catalog in a system by performing one of the following tasks:
•Check SYS1.NUCLEUS member SYSCATxx (default is SYSCATLG).
•Check SYS1.PARMLIB/SYSn.IPLPARM member LOADxx.
•Issue a LISTCAT command against a SYS1 data set, and verify the catalog name.
User catalogs
The difference between the master catalog and the user catalogs is in the function. User catalogs are to be used to contain information about your installation cataloged data sets other than SYS1 data sets. There are no set rules as to how many or what size to have. The configuration depends entirely on your environment.
Cataloging data sets for two unrelated applications in the same catalog might increase the impact to your business during a failure. Assessing the impact of outage of a specific catalog can help to determine whether it is too large or can affect too many applications.
Volume catalog
A volume catalog (VOLCAT) is a catalog that contains only tape library and tape volume entries. A general VOLCAT contains all tape library entries and any tape volume entries that do not point to a specific VOLCAT. A specific VOLCAT cannot contain tape library entries. It contains a specific group of tape volume entries based on the tape volume serial numbers (tape volsers).
6.1.2 VSAM volume data set
The VVDS is a data set that describes the characteristics of VSAM and system-managed data sets on a DASD volume. It is part of an ICF catalog structure.
The VVDS contains VSAM volume records (VVRs) that hold information about VSAM data sets on the volume. The VVDS also contains non-VSAM volume records (NVRs) for SMS-managed non-VSAM data sets on the volume. If an SMS-managed non-VSAM data set spans volumes, then only the first volume contains an NVR for that data set.
If not previously defined, the system automatically defines a VVDS to your volume when the first VSAM or SMS-managed data set is allocated into the device. If not changed by the user, the default size for VVDS data sets is 10 tracks primary and 10 tracks secondary space.
There are three types of entries in a VVDS:
•VSAM volume control records (VVCR)
 – First logical record in a VVDS
 – Contain information for management of DASD space and the names of the BCSs that have data sets on the volume
•VSAM volume records (VVR)
 – Contain information about a VSAM data set on the volume
 – Number of VVRs varies according to the type of data set and the options specified for the data set
 – Also includes data set characteristics, SMS data, and extent information
 – There is one VVR describing the VVDS itself
•Non-VSAM volume record (NVR)
 – Equivalent to a VVR for SMS-managed non-VSAM data sets
 – Contains SMS-related information
VVDS characteristics
The VVDS is a VSAM entry-sequenced data set (ESDS) that has a 4 KB control interval size. The hexadecimal RBA of a record is used as its key or identifier.
A VVDS is recognized by the restricted data set name:
SYS1.VVDS.Vvolser
Volser is the volume serial number of the volume on which the VVDS resides.
You can explicitly define the VVDS using IDCAMS, or it is implicitly created after you define the first VSAM or SMS-managed data set on the volume. Generally, plan allocating your VVDS before any data sets are allocated to reduce volume fragmentation.
An explicitly defined VVDS is not related to any BCS until a data set or catalog object is defined on the volume. Because data sets are allocated on the VVDS volume, each BCS with VSAM data sets or SMS-managed data sets on that volume is related to the VVDS.
Although VVDS data sets start with SYS1 high-level qualifier, they are not necessarily cataloged to the system master catalog. Instead, each catalog having at least one VSAM or SMS-managed data set in a volume will also have a pointer to the volume VVDS. Plan to remove these VVDS entries when the volumes are formatted with a new name.
6.2 Aliases
Aliases are used to tell catalog management which user catalog your data set is cataloged in. First, you place a pointer to a user catalog in the master catalog through the IDCAMS DEFINE UCAT command. Next, you define an appropriate alias name for a user catalog in the master catalog. Then, match the high-level qualifier (HLQ) of your data set with the alias. This qualifier identifies the appropriate user catalog to be used to satisfy the request.
In Figure 6-2, all data sets with an HLQ of PAY have their information in the user catalog UCAT1 because in the master catalog there is an alias PAY that points to UCAT1.
The data sets with an HLQ of DEPT1 and DEPT2 have their information in the user catalog UCAT2 because in the master catalog, there are aliases DEPT1 and DEPT2 pointing to UCAT2.
Figure 6-2 Sample alias processing
 
 
Note: Aliases can also be used with non-VSAM data sets to create alternate names to the same data set. Those aliases are not related to a user catalog.
6.2.1 Multilevel aliases
You can augment the standard catalog search order by defining multilevel catalog aliases. A multilevel catalog alias is an alias of two or more high-level qualifiers. You can define aliases of up to four high-level qualifiers.
However, the multilevel alias facility is only to be used when a better solution cannot be found. The need for the multilevel alias facility can indicate data set naming conventions problems.
For more information about the multilevel alias facility, see z/OS DFSMS: Managing Catalogs, SC26-7409.
6.3 Catalog search order
Whenever you reference a data set and do not provide the data set volume name, the system performs a catalog search to locate your data set within the system devices. Performing a catalog search to locate and access a data set is the most common way to reference data in z/OS because manually specifying the volume name for each request is impractical today.
When a search for a data set is performed, a LOCATE SVC calls the catalog management asking for a data set name search. Most catalog searches are based on catalog aliases.
These searches are performed when you are either trying to allocate a new data set, or access an existing data set for read, write, update, or delete. You can also explicitly code the catalog name to force the search against a specific catalog using the IDCAMS CATALOG keyword. Figure 6-3 is a diagram with standard search order for a LOCATE request.
Figure 6-3 Catalog search order for a LOCATE request
6.3.1 Search order for catalogs for a data set define request
For the system to determine where a data set is to be cataloged, the following search order is used to find the catalog:
1. Use the catalog named in the IDCAMS CATALOG parameter, if coded.
2. If the high-level qualifier is a catalog alias, use the catalog identified by the alias or the catalog whose name is the same as the high-level qualifier of the data set.
3. If no catalog has been identified yet, use the master catalog.
6.3.2 Search order for locating a data set
Base catalog searches on the catalog aliases. When appropriate aliases are defined for catalogs, the high-level qualifier of a data set name is identical to a catalog alias and identifies the appropriate catalog to be used to satisfy the request.
However, alternatives to catalog aliases are available for directing a catalog request, specifically the CATALOG parameter of access method services and the name of the catalog.
The following search order is used to locate the catalog for an already cataloged data set:
1. Use the catalog named in IDCAMS CATALOG parameter, if coded. If the data set is not found, fail the job.
2. If the CATALOG statement is not found, and the high-level qualifier is an alias for a catalog, search the catalog. If the data set is not found, fail the job.
3. Otherwise, search the master catalog.
To use an alias to identify the catalog to be searched, the data set must have more than one data set qualifier. For information about the catalog standard search order, see z/OS DFSMS: Managing Catalogs, SC26-7409.
6.4 Using multiple catalogs
Multiple catalogs on multiple volumes can perform better than fewer catalogs on fewer volumes. This difference is because of the interference between requests to the same catalog, such as a single shared catalog being locked out by another system in the sysplex. This situation can occur if another application issues a RESERVE against the volume that has nothing to do with catalog processing. Another reason can be that there is more competition to use the available volumes, and thus more I/O can be in progress concurrently.
 
Tip: Convert all intra-sysplex RESERVES in global ENQs through the conversion RNL.
Multiple catalogs can reduce the impact of the loss of a catalog for these reasons:
•Reducing the time necessary to re-create any catalog
•Allowing multiple catalog recovery jobs to be in process at the same time
Recovery from a pack failure depends on the total amount of catalog information about a volume, regardless of whether this information is stored in one catalog or in many catalogs.
When using multiple user catalogs, consider grouping data sets under different high-level qualifiers. Independent of the number of catalogs, use the available caching options to increase your catalog search performance. The caching options are discussed in more detail in 6.6, “Catalog caching” on page 111.
Based on your current system usage, you might find that some catalogs are growing at a large pace, while other catalogs are underutilized. You can analyze your catalog utilization and split or merge catalogs to achieve your performance and maintenance requirements.
6.4.1 Splitting catalogs
You can split a catalog to create two catalogs or to move a group of catalog entries if you determine that a catalog is either unacceptably large or that it contains too many entries for critical data sets.
If the catalog is unacceptably large (that is, a catalog failure would leave too many entries inaccessible), then you can split the catalog into two catalogs. If the catalog is of an acceptable size but contains entries for too many critical data sets, then you can simply move entries from one catalog to another. For more information about splitting catalogs, including step-by-step instructions for splitting catalogs, see z/OS DFSMS: Managing Catalogs, SC26-7409.
6.4.2 Merging catalogs
You might find it beneficial to merge catalogs if you have many small or seldom-used catalogs. An excessive number of catalogs can complicate recovery procedures and waste resources such as CAS storage, tape mounts for backups, and system time performing backups.
Merging catalogs is accomplished in much the same way as splitting catalogs. The only difference between splitting catalogs and merging them is that in merging, you want all the entries in a catalog to be moved to another catalog, so that you can delete the obsolete catalog. For more information about merging catalogs, including step-by-step instructions for merging catalogs, see z/OS DFSMS: Managing Catalogs, SC26-7409.
6.5 Sharing catalogs across systems
A shared catalog is a BCS that is eligible to be used by more than one system. It must be defined with SHAREOPTIONS(3 4), and be on a shared volume. A DASD volume is initialized as shared using the MVS hardware configuration definition (HCD) facility.
 
Note: The device must be defined as shared to all systems that access it.
If several systems have the device defined as shared and other systems do not, then catalog corruption will occur. Check with your system programmer to determine shared volumes. Tape volume catalogs can be shared in the same way as other catalogs.
By default, catalogs are defined with SHAREOPTIONS(3 4). You can specify that a catalog is not to be shared by defining the catalog with SHAREOPTIONS(3 3). Only define a catalog as unshared if you are certain it will not be shared. Preferably place unshared catalogs on volumes that have been initialized as unshared. Catalogs that are defined as unshared and that reside on shared volumes will become damaged if referred to by another system.
If you need to share data sets across systems, it is advisable that you share the catalogs that contain these data sets. A BCS catalog is considered shared when both of the following are true:
•It is defined with SHAREOPTIONS (3 4).
•It resides on a shared device, as defined at HCD.
 
Attention: To avoid catalog corruption, define a catalog volume on a shared UCB and set catalog SHAREOPTIONS to (3 4) on all systems that share a catalog.
Note that CAS considers a catalog shared when both values mentioned are true, regardless if the catalog is actually accessed by other systems or not.
Using SHAREOPTIONS 3 means that VSAM does not issue the ENQ SYSVSAM SYSTEMS for the catalog. SHAREOPTIONS 4 means that the VSAM buffers need to be refreshed.
You can check whether a catalog is shared by running the operator command:
MODIFY CATALOG,ALLOCATED
A flag in the catalog indicates whether the catalog is shared.
The VVR entry for a shared catalog is used as a log by all the catalog management that accesses such a catalog. This log is used to help ensure the coherency of each catalog buffer in each z/OS system.
 
Note: Checking VVR entry for a catalog can increase the I/O ratio for the volume and impact catalog performance. Plan on using the caching options to prevent I/Os and check catalog coherency. For more information about caching, see 6.6, “Catalog caching” on page 111
6.6 Catalog caching
Most data set allocations by jobs, users, and applications are performed by catalog searches. This fact causes catalogs to be highly accessed, and any performance issues with a specific catalog can affect all applications that access data sets within that catalog. For that reason, careful planning must be done to ensure good catalog performance.
Caching catalogs can assist you in providing good catalog response times, and even keep the CAS CPU utilization down. There are several caching options that can be used for catalogs. These cache options are explained in more detail in the following sections.
6.6.1 In-storage cache
In-storage cache (ISC) is the virtual memory in CAS reserved for caching. The amount of memory that is used is fixed. When the cache fills, entries are removed from the cache based on a least recently used (LRU) basis. This caching is used (performance-wise) by MCAT control intervals.
This caching option does not deal with data buffer modifications. If these modifications occur, the catalog management flushes the cache in memory, and performs I/Os to retrieve the new information from catalog. For that reason, use ISC only when other caching options are not available.
6.6.2 Catalog data space caching
Catalog data space caching (CDSC), or virtual lookaside facility (VLF) caching, is based in a data space that is owned by the VLF, which is a z/OS component. It is defined through the COFVLFxx member in SYS1.PARMLIB. Catalog entries are not limited by a piece of the data space storage size at a catalog level, but use whatever storage is assigned to the data space in total. At the point when the storage becomes saturated, an LRU algorithm starts removing entries from the VLF cache.
6.6.3 Enhanced Catalog Sharing
Enhanced Catalog Sharing (ECS) differs from other cachings by not caching catalog entries. Instead, it uses Coupling Facility (CF) structure resources to keep the VVR for the catalog on memory. By doing that, CAS does not need to perform an I/O operation to check VVR, accessing the CF structure for coherency checking. ECS can be used along with ISC and VLF caching to improve performance.
6.6.4 VSAM record-level sharing
VSAM record-level sharing (RLS) allows data sharing at record level. This fesature reduces the chances of delays related to one CAS trying to access records locked by other CAS in another logical partition (LPAR). It also uses the SMSVSAM data space to store records, and removes the need to check VVR records for catalog updates. The master catalog cannot use RLS.
To learn more about catalog caching and implementation steps, check z/OS DFSMS: Managing Catalogs, SC26-7409.
6.7 Catalog address space
Catalog functions are performed in the CAS. The jobname of the catalog address space is CATALOG.
As soon as a user requests a catalog function (for example, to locate or define a data set), the CAS gets control to handle the request. When it has finished, it returns the requested data to the user. A catalog task that handles a single user request is called a service task. A service task is assigned to each user request. The minimum number of available service tasks is specified in the SYSCATxx member of SYS1.NUCLEUS (or the LOADxx member of SYS1.PARMLIB). A table called the CRT tracks these service tasks.
The CAS contains all information necessary to handle a catalog request, like control block information about all open catalogs, alias tables, and buffered BCS records.
During the initialization of an MVS system, all user catalog names identified in the master catalog, their aliases, and their associated volume serial numbers are placed in tables in CAS.
You can use the MODIFY CATALOG operator command to work with the catalog address space. For more information, see 6.8.6, “Working with the catalog address space” on page 118.
6.8 Maintaining your catalogs
After your catalogs are defined, you need to perform periodic tasks to ensure that the catalogs are being properly used, response times are good, and the catalogs are recoverable during a failure.
This section describes some activities that can assist you in maintaining your catalog environment. For a deeper view on catalogs maintenance and activities, see A Practical Guide to ICF Catalogs, SG24-8262 and z/OS DFSMS: Managing Catalogs, SC26-7409.
6.8.1 Listing a catalog
You can list catalog records by using the IDCAMS LISTCAT command, or the ISMF line operator command CATLIST. CATLIST produces the same output as LISTCAT.
You can use the LISTCAT output to monitor VSAM data sets including catalogs. The statistics and attributes listed can be used to help determine whether you reorganize, re-create, or otherwise alter a VSAM data set, including catalogs, to improve performance or avoid problems.
The LISTCAT command can be used in many variations to extract information about a particular entry in the catalog. It extracts the data from the BCS and VVDS.
The following are some examples of using LISTCAT for monitoring catalogs:
•List all ALIAS entries in the master catalog:
LISTCAT ALIAS CAT(master.catalog.name)
This command provides a list of all aliases that are currently defined in your master catalog. If you need information only about one specific alias, use the keyword ENTRY(aliasname) and specify ALL to get detailed information.
•List a user catalog connector in the master catalog:
LISTCAT ENT(user.catalog.name) ALL
You can use this command to display the volser and the alias associations of a user catalog as it is defined in the master catalog.
•List the catalog’s self-describing record:
LISTCAT ENT(user.catalog.name) CAT(user.catalog.name) ALL
This command provides detailed information about a user catalog, such as attributes, statistics, extent information, and so on. Because the self-describing record is in the user catalog, you must specify the name of the user catalog in the CAT statement. If you do not use the CAT keyword, only the user catalog connector information from the master catalog is listed as in the previous example.
•Listing a VSAM or non-VSAM data set:
LISTCAT ENT(data.set.name) ALL
The output for a VSAM data set looks the same as the catalog’s LISTCAT output. For a non-VSAM data set, the output is much shorter.
You can use the LISTCAT command to list information for other catalog entries as well. For information about LISTCAT, see z/OS DFSMS Access Method Services for Catalogs, SC26-7394.
6.8.2 Backup procedures
The two parts of an ICF catalog, the BCS and the VVDS, require separate backup techniques. The BCS can be backed up like any other data set. Only back up the VVDS as part of a volume dump. The entries in the VVDS and VTOC are backed up when the data sets they describe are acted upon in these ways:
•Exported with IDCAMS
•Logically dumped with DFSMSdss
•Backed up with DFSMShsm
 
Important: Because catalogs are essential system data sets, it is important that you maintain backup copies. The more recent and accurate a backup copy, the less effect a catalog outage will have on your installation.
To back up a BCS, use one of the following methods:
•The access method services EXPORT command
•The DFSMSdss logical DUMP command
•The DFSMShsm BACKDS command
You can later recover the backup copies using the same utility used to create the backup:
•The access method services IMPORT command for exported copies
•The DFSMSdss RESTORE command for logical dump copies
•The DFSMShsm RECOVER command for DFSMShsm backups
The copy created by these utilities is a portable sequential data set that can be stored on a tape or direct access device, which can be of another device type than the one containing the source catalog.
When these commands are used to back up a BCS, the aliases of the catalog are saved in the backup copy. The source catalog is not deleted, and remains as a fully functional catalog. The relationships between the BCS and VVDSs are unchanged.
You cannot permanently export a catalog by using the PERMANENT parameter of EXPORT. The TEMPORARY option is used even if you specify PERMANENT or allow it to default. Figure 6-4 shows you an example for an IDCAMS EXPORT.
//EXPRTCAT JOB ...
//STEP1 EXEC PGM=IDCAMS
//RECEIVE DD DSNAME=CATBACK,UNIT=(TAPE,,DEFER),
// DISP=(NEW,KEEP),VOL=SER=327409,LABEL=(1,SL)
//SYSPRINT DD SYSOUT=A
//SYSIN DD *
EXPORT -
USER.CATALOG -
OUTFILE(RECEIVE) -
TEMPORARY
/*
Figure 6-4 JCL to create a backup of a BCS using IDCAMS EXPORT
 
Note: You cannot use IDCAMS REPRO or other copying commands to create and recover BCS backups.
You can also make periodic volume dumps of the master catalog's volume. This dump can later be used by the stand-alone version of DFSMSdss to restore the master catalog if you cannot access the volume from another system.
For information about defining and using catalog back-up options, see z/OS DFSMS: Managing Catalogs, SC26-7409.
Backing up a VVDS
Do not back up the VVDS as a data set to provide for recovery. To back up the VVDS, back up the volume containing the VVDS, or back up all data sets described in the VVDS (all VSAM and SMS-managed data sets). If the VVDS ever needs to be recovered, recover the entire volume, or all the data sets described in the VVDS.
You can use either DFSMSdss or DFSMShsm to back up and recover a volume or individual data sets on the volume.
6.8.3 Recovery procedures
Normally, a BCS is recovered separately from a VVDS. A VVDS usually does not need to be recovered, even if an associated BCS is recovered. However, if you need to recover a VVDS, and a BCS is on the VVDS’s volume, you must recover the BCS as well. If possible, export the BCS before recovering the volume, and then recover the BCS from the exported copy. This process ensures a current BCS.
Before recovering a BCS or VVDS, try to recover single damaged records. If damaged records can be rebuilt, you can avoid a full recovery.
The way that you recover a BCS depends on how it was saved (see 6.8.2, “Backup procedures” on page 114). When you recover a BCS, you do not need to delete and redefine the target catalog unless you want to change the catalog's size or other characteristics, or unless the BCS is damaged in such a way as to prevent the usual recovery.
Aliases to the catalog can be defined if you use DFSMSdss, DFSMShsm, or if you specify ALIAS on the IMPORT command. If you have not deleted and redefined the catalog, all existing aliases are maintained, and any aliases defined in the backup copy are redefined if they are not already defined.
Lock the BCS before you start recovery so that no one else has access to it while you recover the BCS. If you do not restrict access to the catalog, users might be able to update the catalog during recovery or maintenance and create a data integrity exposure. The catalog also will be unavailable to any system that shares the catalog. You cannot lock a master catalog.
After you recover the catalog, update the BCS with any changes that have occurred since the last backup. You can use the access method services DIAGNOSE command to identify certain unsynchronized entries.
The Integrated Catalog Forward Recovery Utility
You also can use the Integrated Catalog Forward Recovery Utility (ICFRU) to recover a damaged catalog to a correct and current status. This utility uses SMF records that record changes to the catalog, updating the catalog with changes made since the BCS was backed up. The SMF records are used by ICFRU as a log database. Use ICFRU to avoid the loss of catalog data even after recovery.
For further information about recovery procedures, see z/OS DFSMS: Managing Catalogs, SC26-7409. For information about the IDCAMS facility, see z/OS DFSMS Access Method Services for Catalogs, SC26-7394.
6.8.4 Checking the integrity on an ICF structure
An error in the ICF structure can be caused either by a structural integrity error or a data structure error. A structural integrity error usually means that the data set is broken (logically or physically). The data set no longer has a valid structure that the VSAM component can handle.
Alternatively, an error within the data structure of a BCS or VVDS means that the VSAM structure of the BCS or VVDS is still valid. VSAM has no problems accessing the data set. However, the content of each of the single records in the BCS or VVDS does not conform to catalog standards. The information in the BCS and VVDS for a single data set can be unsynchronized, making the data set inaccessible.
Two kinds of VSAM errors can occur with your BCS or VVDS:
•Logical errors
The records on the DASD volume still have valid physical characteristics like record size or CI size. The VSAM information in those records is wrong, like pointers from one record to another or the end-of-file information.
•Physical errors
The records on the DASD volume are invalid. For example, they might be a wrong length. Reasons can be an overlay of physical DASD space or wrong extent information for the data set in the VTOC or VVDS.
When errors in the VSAM structure occur, they are in most cases logical errors for the BCS. Because the VVDS is an ESDS, it has no index component. Logical errors of an ESDS are unlikely.
You can use the IDCAMS EXAMINE command to analyze the structure of the BCS. As explained previously, the BCS is a VSAM key-sequenced data set (KSDS). Before running the EXAMINE, run an IDCAMS VERIFY to make sure that the VSAM information is current, and ALTER LOCK the catalog to prevent update by others while you are inspecting it.
With the parameter INDEXTEST, you analyze the integrity of the index. With parameter DATATEST, you analyze the data component. After you have the results of INDEXTEST and DATATEST, you can take the necessary steps to successfully recover your catalog. For more information about the steps to fix a catalog error, see z/OS DFSMS: Managing Catalogs, SC26-7409.
Additionally, you can use the IDCAMS DIAGNOSE command to validate the contents of a BCS or VVDS. You can use this command to check a single BCS or VVDS and to compare the information between a BCS and multiple VVDSs.
For various DIAGNOSE examples, see z/OS DFSMS Access Method Services for Catalogs, SC26-7394.
6.8.5 Catalog performance
The main factors affecting catalog performance are the amount of I/O required for the catalog and the subsequent amount of time it takes to perform the I/O. These factors can be reduced by buffering catalogs in special buffer pools, or applying RLS to your catalogs. Other factors are the size and usage of the master catalog, options that were used to define a catalog, and the way you share catalogs between systems.
The simplest method of improving catalog performance is to use caching to maintain catalog records in memory and prevent physical I/O. Three types of buffer are available for catalogs:
•The ISC buffer is contained within the CAS.
•The CDSC is separate from CAS and uses the z/OS VLF component, which stores the buffered records in a data space.
•The RLS uses the SMSVSAM address space and coupling facility structures to control and share data between LPARs.
All types of buffer are optional, and each can be canceled and restarted without an IPL.
The three types of buffer are used to keep catalog records in the storage. This technique avoids I/Os that are necessary to read the records from DASD. There are several things that you need to take into considerations to decide what kind of buffer to use for which catalog. See z/OS DFSMS: Managing Catalogs, SC26-7409, for more information about buffering.
Another kind of caching is using enhanced catalog sharing to avoid I/Os to read the catalog VVR. Refer to 6.6.3, “Enhanced Catalog Sharing” on page 112 for more information about this topic.
Master catalog
If the master catalog only contains entries for catalogs, catalog aliases, and system data sets, the entire master catalog is read into main storage during system initialization. Because the master catalog, if properly used, is rarely updated, the performance of the master catalog is not appreciably affected by I/O requirements. For that reason, keep the master catalog small and do not define user data sets into it.
For more information about these values, see z/OS DFSMS Access Method Services for Catalogs, SC26-7394.
Convert SYSIGGV2 resource
If the catalog does not use RLS, catalog management uses the SYSIGGV2 reserve when serializing access to catalogs. The SYSIGGV2 reserve is used to serialize the entire catalog BCS component across all I/O and to serialize access to specific catalog entries.
If the catalog is shared only within one GRSplex, convert the SYSIGGV2 resource to a global enqueue to avoid reserves on the volume on which the catalog resides. If you are not converting SYSIGGV2, you can have ENQ contentions on those volumes and even run into deadlock situations.
 
Important: If you share a catalog with a system that is not in the same GRS complex, do not convert the SYSIGGV2 resource for this catalog. Sharing a catalog outside the complex requires reserves for the volume on which the catalog resides. Otherwise, you will break the catalog. For more information, see z/OS MVS Planning: Global Resource Serialization, SA22-7600.
6.8.6 Working with the catalog address space
You can use the command MODIFY CATALOG to extract information from the CAS and to interact with the CAS. This command can be used in many variations. This section provides an overview of parameters to be aware of when maintaining your catalog environment.
For a discussion about the entire functionality of the MODIFY CATALOG command, see z/OS DFSMS: Managing Catalogs, SC26-7409.
Examples of the MODIFY CATALOG command:
•MODIFY CATALOG,REPORT
The catalog report lists information about the CAS, like the service level, the catalog address space ID, service tasks limits, and so on. Since z/OS 1.7, this command generates the IEC392I that identifies the top three holders of the CATALOG service tasks, possibly indicating a lockup.
•MODIFY CATALOG,OPEN
This command lists all catalogs that are currently open in the CAS. It shows whether the catalog is locked or shared, and the type of buffer used for the catalog. A catalog is opened after an IPL or catalog restart when it is referenced for the first time. It remains open until it is manually closed by the MODIFY CATALOG command or it is closed because the maximum number of open catalogs has been reached.
•MODIFY CATALOG,LIST
The LIST command shows you all service tasks that are currently active handling a user request. Normally the active phase of a service task is only of a short duration, so no tasks are listed. This command helps you to identify tasks that might be the reason for catalog problems if performance slows down.
•MODIFY CATALOG,REPORT,PERFORMANCE
The output of this command shows you significant catalog performance numbers about number and duration of ENQs and DEQs for the BCS and VVDS and more. Use the command to identify performance problems.
•MODIFY CATALOG,REPORT,CACHE
The cache report lists cache type and statistics for the single catalogs that are open in the CAS.
Restarting the catalog address space
Consider restarting the CAS only as a final option before restarting a system. Never try restarting CAS unless an IPL is your only other option. A system failure that is caused by catalogs, or a CAS storage shortage due to FREEMAIN failures, might require you to use MODIFY CATALOG,RESTART to restart CAS in a new address space.
Never use RESTART to refresh catalog or VVDS control blocks, or to change catalog characteristics. Restarting CAS is a drastic procedure, and if CAS cannot restart, you must IPL the system.
When you issue MODIFY CATALOG,RESTART, the CAS mother task is abended with abend code 81A, and any catalog requests that in process at that time are redriven.
The restart of CAS in a new address space is transparent to all users. However, even when all requests are redriven successfully and receive a return code of zero (0), the system might produce indicative dumps. There is no way to suppress these indicative dumps.
..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset
3.17.162.26