The file catagog (this is the file TSOSCAT) is only accessed from CMS (Catalog Management System) routines. The PAM blocks in this file contain:
file entries or
job variable entries or
global management data
(MRS catalog and entries describing the current state of TSOSCAT)
The file is accessed in blocks. The system parameter BMTNUM (see "BMTNUM and CATBUFR") or /IMPORT-PUBSET or /ADD- and /MODIFY-MASTER-CATALOG-ENTRY are used to specify how much I/O buffer is available to the CMS. Simultaneous user requests to the same catalog block are synchronized with the aid of a Buffer Management Table (BMT) and a bourse (one BMT and one bourse per catalog I/O buffer).
The catalog file can be divided into several extents. For technical reasons, the first extent of the file must be on the volume xxxx.0. If there are several pubsets, there is a catalog on each pubset. Placing parts of TSOSCAT on heavily used disk drives must be avoided. All volumes with paging areas and SYSEAM area fall into this category.
Catalog formats
There are three catalog formats:
NORMAL and LARGE (implicitly for pubsets with "large" objects) and EXTRA LARGE.
TSOSCAT type | Max. size | Max. size |
NORMAL | 8,192 | 16,384 |
LARGE | 16,184 | 32,368 |
EXTRA LARGE | 32,008 | 64,016 |
The catalog format EXTRA LARGE is incompatible to the older formats: However, with BS2000/OSD V11.0, NORMAL and LARGE are only supperted for shared pubsets, which are imported as slave. For all other pubsets, catalogs in the format EXTRA LARGE are always used. Possibly existing catalogs in other formats are automatically converted when importing the pubset.
Up to 100 subcatalogs each with 64,016 PAM pages can be created for SM pubsets with catalogs in EXTRA LARGE type for each of the special catalogs #MIN, #JVC and #PTV (/ADD-CATALOG-FILE).
CMS recognizes when a catalog is 90% full and automatically extends it. If none of the existing subcatalogs can be extended, a new subcatalog is then created.
The file can also be expanded manually using the /MODIFY-FILE-ATTRIBUTES command (SPACE operand). The change becomes effective immediately and not only after the next time the pubset has been imported.
Creating TSOSCAT
The size of TSOSCAT is determined by
the number of users permitted to use it
(represented by the user IDs entered by means of /ADD-USER)the number of files and job variables in the system
the size of the catalog entries; with files this is dependent on the number of extents they have, and with job variables on the size of the JV value.
the splintering of catalog entries, which is caused by selective deletionThe space which becomes free by deleting “individual” entries is available for creating new entries, but is not used for anything else. Only after all entries have been deleted is a catalog block released.
The entries in TSOSCAT are stored in catalog blocks (each 4 KB in size):
A catalog block for files, the so-called “primary block”, is reserved for each user even if a user creates no files.
A catalog block contains either only file entries of one user or only JV entries of one user.
1 to 11 file entries fit into a catalog block.
An average of 10 file entries per catalog block can be expected on a pubset which is sufficiently large and maintained using SPACEOPT.8 to 18 JV entries fit into a catalog block.
It is difficult to specify an average because the size of the JV values can be freely selected by the user. For example, in the case of MONJVs with a standard size of 128 bytes, 11 JV entries fit into a catalog block.
The average number of the catalog blocks which are occupied by “primary blocks” and file entries can be estimated using the following formula:
Number of catalog blocks + Number of user IDs + (Total number of files / 10)
The formula takes into account the splitting up of catalog entries and the decreasing capacity as the size of the entries increases. Additional catalog blocks are required for job variables.
Example
Calculation of the catalog size for 150 user IDs with 65 files per user ID:
TSOSCAT = 150 + (150 * 65 / 10) = 1125 catalog blocks
If the software product SCA (Speed Catalog Access) is not used, no more than 65 files or job variables should be cataloged per user ID . If SCA is used, then a greater number of files or job variables is possible.
Location of TSOSCAT
A TSOSCAT file of 2000 PAM blocks is automatically created on volume xxxx.0 at system generation.
Assuming that the paging area created on the system residence (xxxx.0) is not used during subsequent operation, TSOSCAT should be stored on volume xxxx.0 in its required size (in the case of installation using SIR).
If the load on volume xxxx.0 essentially consists only of user activities (max. 15% capacity utilization) and catalog accesses on the part of the system (also max. 15% capacity utilization), it will manage 50 catalog I/O operations per second at a 70% read hit rate. It would be advantageous to reduce this by increasing the number of CMS input/output buffers and using SCA.
If several pubsets are used, a copy of TSOSCAT is automatically placed on each pubset. The recommendations are then true for volume xxxx.0 for each pubset.
Once normal operation has been started, it is advisable to monitor the number of catalog I/O operations per second using the software monitor SM2 (reports “CMS Queues”, “CMS IO'S” in the report group CATALOG-MANAGEMENT).
As well as the frequency of catalog I/O operations, it is also necessary to consider the address space requirements for tables and buffers and delays resulting from synchronization when calculating CMS performance for productive operation. If multiple pubsets are used, catalog I/O buffers and their management tables (BMT) are created for each pubset. If there is a large number of pubsets, then the address space required by CMS can increase considerably.
It is possible to define the number of CMS buffers for each pubset with /ADD-, /MODIFY-MASTER-CATALOG-ENTRY or /IMPORT-PUBSET.
Example
The system parameters BMTNUM=32 and CATBUFR=N were specified in the startup parameter service. For 2 pubsets CMS needs the following amount of work area:
|
An additional I/O buffer for the static MRS catalog (approx. 4 KB) is required for pubsets with EXTRA LARGE catalogs.
To protect simultaneous requests, one bourse is created per catalog buffer. In addition, further bourses are used as protection against competing calls from CMS routines.
From time to time, it is necessary to revise the organization of files on disks and of file entries and job variable entries in catalog blocks. This is done in order to keep path lengths as short as possible when searching for file entries and job variable entries, and to ensure that as few catalog buffers as possible are locked for simultaneous requests from other users during this search. During this process, all files and job variables must be saved, deleted and recreated. When recreating, two requirements - which may possibly be contradictory - must be fulfilled as far as possible.
On the one hand, large files should be transferred into the system first, then this allows them to be distributed according to considerations of practicability. Small files can be placed in gaps.
On the other hand, CMS capacity is used efficiently if file entries for heavily used files are as near as possible to the beginning of the series of catalog blocks for each user ID. CMS starts searching for file entries or job variable entries in the first block of the series of user catalog blocks in each case.
The second requirement should be given priority.
If there are too many user IDs and file and job variable entries per user ID, SCA should be used (for details, see section "Accelerating catalog accesses with SCA").