Previous topic |
Next topic |
Contents |
Contact z/OS |
Library |
PDF
Locking a Catalog z/OS DFSMS Managing Catalogs SC23-6853-00 |
|
You should restrict access to a catalog when you are recovering it or when you are performing other maintenance procedures which involve redefining the catalog. If you do not restrict access to the catalog (by locking it, by terminating user sessions, or by another method), users might be able to update the catalog during recovery or maintenance and create a data integrity exposure. Locking the catalog eliminates the need to terminate user sessions during catalog recovery or maintenance. You can only lock user catalogs. You cannot lock a master catalog. While the catalog is locked, unauthorized requests to access the catalog fail with a return code indicating that the catalog is temporarily unavailable. Jobs entered with JCL fail with a JCL error. You cannot make JCL jobs wait until the catalog is unlocked. The catalog is also unavailable to any system that shares the catalog. After you have completed the catalog recovery or maintenance, unlock the catalog so that normal operations can resume. To lock or unlock a catalog with a serialized close across the sysplex , you use the LOCK and UNLOCK parameters of the access method services ALTER, DEFINE, or IMPORT commands. You use the ALTER command to lock or unlock an existing catalog; the DEFINE command to lock a newly defined catalog (the default is to define an unlocked catalog); and the IMPORT command to lock or unlock a catalog that you are importing. In order to lock or unlock a catalog, you must have READ access to the IGG.CATLOCK profile in RACF®, and ALTER authority to the catalog. If the catalog is shared between systems, you may want to ensure you provide access to those users who may need to access the catalog while it is locked (such as VTAM®, described below). Another way to lock or unlock a catalog with a serialized
close across the sysplex is to use the following modify commands:
Exception: Catalogs are not unlocked
during a system IPL. If you lock a catalog, and there is a system
failure, the catalog is still locked after you IPL the system. This
can cause problems if a locked catalog contains entries for data sets
needed during IPL.
For example, if the catalog containing entries needed for VTAM is locked, VTAM cannot be started. Because VTAM is needed to start TSO, and TSO must be active to issue the ALTER command or submit a batch IDCAMS job, you cannot use ALTER UNLOCK to unlock the catalog. As long as TSO is available, you can simply use ALTER UNLOCK to unlock the catalog and allow the IPL to complete. However, you can also authorize VTAM to the IGG.CATLOCK profile. This allows VTAM to access a locked catalog. If you authorize VTAM to IGG.CATLOCK, you should also authorize any other components which are needed to start VTAM. Jobs such as VTAM and any other critical system resource should be given CATLOCK authority prior to locking any user catalog. If TSO is not available, and VTAM cannot be started because it does not have access to the IGG.CATLOCK profile, you must use a card reader to enter an IDCAMS ALTER UNLOCK job into the system to unlock the catalog. If the catalog is shared between systems, it may be unlocked from any of the shared systems. Thus the catalog does not need to be unlocked from the system that locked it. This provides an alternative way to recover when the system that locked the catalog cannot be used to unlock it. |
Copyright IBM Corporation 1990, 2014
|