The CA Disk FILES Data Set

Transcription

1 The CA Disk FILES Data Set General Information The FILES Data Set can be of two different organizations. BDAM file called the FILES Data Set (FDS) CA Datacom/AD database called the Files Database (FDB) This paper will be about the BDAM FILES Data Set. The FILES data set contains multiple subfiles of records. The term subfile refers to a group of logically related records kept within the FILES. Most subfiles do not have any relationship to records in other subfiles. The exception is that the DSNINDEX records do contain the ARCHVOLS key where that data set is located. The subfile DSNINDEX or, data set index, has a record of each data set backup or archive image (copy) currently in the CA Disk archives. When a data set is restored, the DSNINDEX record is read to get the volser of the tape or disk containing the version of the data set and its location within that volume. These records remain in the subfile until they are expired and deleted by the IXMAINT (index maintenance) routine. The subfile ARCHVOLS has a record for each archive volume (tape or disk) to which one or more data sets were backed up or archived. The DSNINDEX and ARCHVOLS subfiles are both used in most CA Disk processes. These records are deleted by the IXMAINT or MERGE routines when there are no more DSNINDEX records on the ARCHVOL. The FILES data set is very easy to maintain and several utilities are provided to manage it. The following topics will be covered: Pg. 2 FILES Status Report Pg. 3 Capacity of the FILES Pg. 4 FILEDEFN Define the Logical Capacity of the SUBFILES Pg. 5 Allocate the FILES Data Set Pg. 6 The UNLOAD Utility Pg. 7 The RELOAD Utility Pg. 8 The REORG Utility Pg. 9 The REORG Proc This paper developed by: Donald Bell Principal Support Engineer CA Technologies, Inc. The CA Disk FILES Data Set Page 1 of 9

2 FILES Status Report To get an understanding about your FILES data set, how large it is, how much space is used and the number of records it can hold, a FILES Status Report should be run. This is the JCL to get this report. There is no command input. //FILESTAT EXEC PGM=ADSMI002,PARM=ADSDM107,REGION=0M //STEPLIB DD DISP=SHR,DSN=CA.DISK.LOADLIB //ABNLDUMP DD DUMMY //FILES DD DISP=SHR,DSN=CA.DISK.FILES //MSGPRINT DD SYSOUT=A //PARMLIB DD DISP=SHR,DSN=CA.DISK.PARMLIB //SYSPRINT DD SYSOUT=* //SYSUDUMP DD SYSOUT=* The FILES Status report is produced when any of the FILES utilities are executed FILEINIT, UNLOAD, RELOAD, REORG. This is an example of the FILES Status Report showing just the DSNINDEX and ARCHVOLS subfiles statistics. This report shows that the DSNINDEX subfile has Overflow Blocks, discussed in the next topic. The capacity of the FILES Data Set and the importance of several of the fields in this report are also discussed. The CA Disk FILES Data Set Page 2 of 9

3 Capacity of the FILES There are two capacities of the FILES and subfiles that need to be understood. I - Logical Capacity The records in the subfiles are indexed and kept sequentially in data blocks. These data blocks may be split as new records are inserted. The block splits do reduce the total possible capacity, but this is normal and not to be concerned about. Check these fields in the Status Report: Record Count The number of real records in the subfile. Maximum Records The maximum number of records that can be indexed. This value is specified in the FILEDEFN member in Parmlib (see pg. 4). The Basic Rule: The Maximum Records should be more than double, or three times if possible, the number of real records. Corrective Action: If the Record Count is close to half the value of Maximum Records, increase the logical capacity by updating the FILEDEFN member in Parmlib. Then run the REORG proc or the UNLOAD and RELOAD utilities. Overflow Blocks This field should always be zero. If this field is a non-zero value, the logical capacity of the subfiles has been exceeded. Performance of the FILES data set will be greatly reduced because the overflow blocks must be sequentially searched during every access of the FILES. But, you will not lose any data. Corrective Action: If a subfile is in Overflow, do the following: 1. Update the capacity field in the FILEDEFN member. (This increases the Maximum Records value the number of records that can be indexed.) 2. Run the REORG proc or the UNLOAD and RELOAD. II - Physical Capacity The BDAM structure of the FILES data set can not take extents. So, there is a limit of the number of data blocks that are available until no more records can be added. If the FILES does fill up, CA Disk jobs will abend, but no data will be lost. Check these fields in the Status Report: Total Blocks The number of blocks allocated for the FILES Data Set. (Divide this number by 30 to see the number of CYLs that are allocated.) Blocks Remaining The number of blocks remaining that can hold records. The Basic Rule: The Blocks Remaining should be 20% or more of the Total Blocks. Corrective Action: If the Blocks Remaining drops to 10% of the Total Blocks, you need to start planning when you can increase the size of the FILES: 1. Update member FILEDEFN, if needed (see pg. 4). 2. Insure that there is no access to the FILES data set during this process: a. Run the UNLOAD utility on the old FILES data set (see pg. 6). b. Allocate a new larger FILES data set (see pg. 5). c. Run the RELOAD utility into the new FILES data set (see pg. 7). The CA Disk FILES Data Set Page 3 of 9

4 FILEDEFN Define the Logical Capacity of the SUBFILES The logical capacity of the subfiles in the FILES data set is specified in member FILEDEFN in the CA Disk Parmlib. Here is an example of Parmlib member FDSAMPLE which is used to create member FILEDEFN which is read by the FILES utilities: DSNINDEX256044C YNNY ARCHVOLS110006C YYNY DMSPOOLS090026C YYNY RETEXCLD082044C YNNN MIGRECAT252030C YNNN ARCHCMDS164045C YYNN RESTCMDS164044C YYNN DMSPARMS100008C YNNN DASDSPCB084050C NNYN RACFENCD090049C YYNY As mentioned earlier, the capacity of a subfile must be more than double (or triple if possible) the real record count. The capacity value is shown highlighted, following the letter C. The Maximum Records value in the FILES Status Report will be greater than the value you specify in FILEDEFN. This is because a number of blocks are defined to index the number of records you specified in FILEDEFN. However, those index blocks will hold more than your value of records so the total capacity is what is listed. When a RELOAD or REORG has been run, the data blocks are packed tight with records so the percentage of Blocks Remaining vs. Total Blocks will be quite high. But, after a few days of backup/archive jobs, many records will have been added and block splits occurred so the percentage of Blocks Remaining will drop. This is normal and not a problem as long as you have well over 50% Blocks Remaining after several days of processing. The FILES Status Report should be checked periodically and update the FILEDEFN member in Parmlib when needed, but especially when: 1. A new larger FILES data set needs to be allocated 2. The REORG job needs to be run. The FILEDEFN member is used to initialize the directory blocks in the FILEINIT, REORG and the RELOAD jobs. The CA Disk FILES Data Set Page 4 of 9

5 Allocate the FILES Data Set The job to allocate and initialize the FILES data set is very simple and uses no command input. //FILEINIT EXEC PGM=ADSMI002,PARM=ADSDM100,REGION=0M //STEPLIB DD DISP=SHR,DSN=CA.DISK.LOADLIB //ABNLDUMP DD DUMMY //FILES DD DSN=CA.DISK.FILES, // DISP=(,CATLG,DELETE), // UNIT=SYSDA, // SPACE=(CYL,1000,,CONTIG), // DCB=(DSORG=DA) //MSGPRINT DD SYSOUT=A //PARMLIB DD DISP=SHR,DSN=CA.DISK.PARMLIB //SYSPRINT DD SYSOUT=* //SYSUDUMP DD SYSOUT=* The FILES data set can not go into secondary extents. So, the SPACE must be CONTIG and only a primary allocation amount can be specified. Insure that an allocation control product does not add a secondary quantity. The FILES can be allocated on an SMS volume but the Mgmt. Class must do no actions to the FILES. A FILES Status Report should be reviewed before allocating a new FILES Data Set. If the logical capacity of a subfile needs to be changed, the FILEDEFN member in the CA Disk Parmlib should be updated before the FILES is allocated. The maximum size of the FILES data set is 4,369 CYLs. There are two ways to factor the real physical capacity that you need to allocate: 1,000 CYLs will hold over 1.6 million DSNINDEX records, which includes the space to allow for block splits. 1,000,000 real DSNINDEX records would need 612 CYLs which includes the space to allow for block splits. For a FILES size of 4,369 CYLs, the practical limit is 7 million DSNINDEX records. The CA Disk FILES Data Set Page 5 of 9

6 The UNLOAD Utility The unload utility is used to make a backup of the FILES data set, which should be done at least once per day. Even though the BDAM file appears as a PS data set, you can not use IEBGENER to copy the FILES. The IEBGENER will appear to run correctly with CondCode=0, but the FILES will be corrupt. The word unload for the command is not literal. The records are simply copied from the FILES to the output file. The output of the unload can be to tape or to DASD. Making the output file a GDG can be very beneficial. The following is the JCL for the unload process: //FILEUNLD EXEC PGM=ADSMI000,PARM=ADSDM177,REGION=0M //STEPLIB DD DISP=SHR,DSN=CA.DISK.LOADLIB //ABNLDUMP DD SYSOUT=* //CMDPRINT DD SYSOUT=* //FILES DD DISP=SHR,DSN=CA.DISK.FILES //MSGPRINT DD SYSOUT=* //PARMLIB DD DISP=SHR,DSN=CA.DISK.PARMLIB //SYSPRINT DD SYSOUT=* //SYSUDUMP DD SYSOUT=* //SEQFILES DD DSN=CA.DISK.SEQFILES.UNLOAD, // DISP=(NEW,CATLG,DELETE), // SPACE=(CYL,(300,100),RLSE), <== Adjust as needed // UNIT=SYSDA, // DCB=(BLKSIZE=0,DSORG=PS,RECFM=VB) //SYSIN DD * UNLOAD ALL UNLOAD ALL is the typical command to have all records in the FILES to be written to the output file. A few other parameters are available if FILES LOGGING is used. If you use this feature, then please refer to the Systems Guide, about pg. 42, the section UNLOAD Command and Parameters. The CA Disk FILES Data Set Page 6 of 9

7 The RELOAD Utility This utility is used to reload all the records from an Unload into the FILES data set. The Reload process would be done if a new FILES has to be allocated because: A new larger FILES data set had to be allocated Some catastrophic event has occurred to the FILES and it has to be re-allocated. The JCL follows: //FILERELD EXEC PGM=ADSMI002,PARM=ADSDM192,REGION=0M //STEPLIB DD DISP=SHR,DSN=CA.DISK.LOADLIB //ABNLDUMP DD SYSOUT=* //CMDPRINT DD SYSOUT=* //FILES DD DISP=OLD,DSN=CA.DISK.FILES //MSGPRINT DD SYSOUT=* //PARMLIB DD DISP=SHR,DSN=CA.DISK.PARMLIB //SYSPRINT DD SYSOUT=* //SYSUDUMP DD SYSOUT=* //SEQFILES DD DISP=OLD,DSN=CA.DISK.SEQFILES.UNLOAD //SYSIN DD * RELOAD ALL,FORMAT,FREESP=20 Specify the backup file (from the UNLOAD) to be input with the SEQFILES DD. RELOAD ALL,FORMAT is the typical command to have all records from the backup copy to be written to the FILES data set. The optional FREESP= parameter will leave a percentage of free space in the data blocks, just for DSNINDEX records. Without the FREESP= parameter, a RELOAD or REORG will load the DSNINDEX records in sequence and fill the data blocks 100%. So, every new DSNINDEX record to be inserted by an Archive or Backup into a 100% filled block will cause a block split. With FREESP=20, a RELOAD or REORG will leave 20% free space in every block so there is room to insert some new DSNINDEX records. This will keep the number of "Blocks Remaining" more constant over a period of time and lessen the likelihood of going into Overflow Blocks. So, you are urged to specify this parameter as shown in the RELOAD example. On pg. 2 is a FILES Status report showing Overflow blocks. The following report is of the same FILES data set after changing only FILEDEFN to increase the logical capacity by one million records and running a REORG using the FREESP=20 parm: Note that the BLOCKS REMAINING is 4495, vs. the 987 from the FILES Status report on pg. 2. A report 8 days later shows this value has dropped only 60, to So, the FREESP=20 parm did stabilize the number of blocks that are used. (Your results may vary.) The CA Disk FILES Data Set Page 7 of 9

8 The REORG Utility As records are added to the subfiles, the capacity could reach a point where records will be in Overflow Blocks. No records will be lost, but the condition will cause a performance impact to any CA Disk jobs. If this condition occurs, the REORG utility can be used to reorder all subfile records into their correct sequence. The JCL is simply this //REORG EXEC REORG The REORG proc executes a single-step process to: 1. Unload all the subfiles to temporary data sets 2. Sort the records into the proper sequence 3. Read FILEDEFN and re-define the directory blocks (reinitialize) 4. Reload all the records Before running the REORG, the FILEDEFN member of Parmlib should be updated with the Capacity field specified as needed. The UNLOAD and RELOAD jobs described earlier can be run to REORG the FILES. But, it is imperative that no other user can get to the FILES data set until the REORG or the UNLOAD and RELOAD processes are complete. Renaming the FILES to get and keep control during these jobs is suggested. The CA Disk FILES Data Set Page 8 of 9

9 The REORG Proc As described earlier, the REORG proc executes a single-step process to: Unload all records; Sort; Re-initialize; Reload all records. The REORG proc needs to be modified because, as it is shipped, it will handle only a very small number of records. Here is the REORG proc with some comments added and suggested changes. The values shown will handle one million DSNINDEX records. Adjust accordingly. Be sure to modify the SYSIN statement to this: RELOAD ALL,FORMAT,FREESP=20 //REORG PROC MI=002, // P='%%FILE_PREFIX..INSTALL', // Q='%%FILE_PREFIX', // S='*', // W=SYSDA //REORG EXEC PGM=ADSMI&MI,PARM=ADSDM444,REGION=0M //* ********************************************************** //* * CA-DISK FILES DATA SET REORGANIZATION * //* ********************************************************** //STEPLIB DD DISP=SHR,DSNAME=&Q..LOADLIB //ABNLDUMP DD DUMMY //CMDPRINT DD SYSOUT=&S //* These DDs for DSNINDEX records //DSNIIN DD UNIT=&W, // SPACE=(CYL,(300,20)),DCB=(LRECL=268,BLKSIZE=0) //DSNIOUT DD UNIT=&W, // SPACE=(CYL,(300,20)),DCB=(LRECL=268,BLKSIZE=0) //DSNIWK01 DD SPACE=(CYL,100,,CONTIG),UNIT=&W //DSNIWK02 DD SPACE=(CYL,100,,CONTIG),UNIT=&W //DSNIWK03 DD SPACE=(CYL,100,,CONTIG),UNIT=&W //* These DDs for all other subfiles records //FILEIN DD SPACE=(CYL,(10,2)),UNIT=&W, // DCB=(LRECL=268,BLKSIZE=0) //FILEOUT DD SPACE=(CYL,(10,2)),UNIT=&W, // DCB=(LRECL=268,BLKSIZE=0) //FILES DD DISP=OLD,DSNAME=&Q..FILES //FILEWK01 DD SPACE=(CYL,10,,CONTIG),UNIT=&W //FILEWK02 DD SPACE=(CYL,10,,CONTIG),UNIT=&W //FILEWK03 DD SPACE=(CYL,10,,CONTIG),UNIT=&W //* //FILPRINT DD SYSOUT=&S //MSGPRINT DD SYSOUT=&S,DCB=BUFNO=0 //PARMLIB DD DISP=SHR,DSNAME=&Q..PARMLIB //SEQFILES DD DSN=&Q..SEQFILES,DISP=(,CATLG,CATLG), // SPACE=(CYL,(300,20),RLSE),UNIT=&W, // DCB=(LRECL=268,BLKSIZE=0,RECFM=VB) //SYSIN DD DISP=SHR,DSN=&P(RELOAD) //* RELOAD ALL,FORMAT //SYSOUT DD SYSOUT=&S //SYSPRINT DD SYSOUT=&S //SYSUDUMP DD SYSOUT=&S The CA Disk FILES Data Set Page 9 of 9