Initializing VSAM Files


VSAM files have always presented a rather annoying problem of requiring that at least one data record be initially loaded into the file before the file could be opened for input or update processing. This is because VSAM issues a VERIFY command upon opening a file to reset the end-of-file pointer. If the file has never been loaded, the VERIFY fails because the high used RBA (Relative Byte Address) (HI-USEDRBA) is still zero. Therefore, VSAM files must be initially "loaded" to set the HI-USED-RBA to a value other than zero. This is done by writing a record to the VSAM file in "load" mode and optionally deleting the record to empty the file while leaving the HI-USED-RBA at a non-zero value.


Load processing requires opening the VSAM file for OUTPUT in SEQUENTIAL processing mode and writing at least one record to the file. (COBOL-II does implement a direct mode load facility but the initialization of the VSAM file is done behind the scenes by code invoked by COBOL-II.) The common COBOL solution is to code a separate initialization program. The problem with using COBOL as the initialization mechanism is that the information in the FD (File Description) must always match the physical
attributes of the file from the DEFINE CLUSTER command. Therefore, there is usually a separate initialization program for each VSAM file and it must be changed when the VSAM file attributes are modified. This is another maintenance issue which can go wrong. Although it may not be very complicated, it is a nuisance to initialize VSAM files every time they are DEFINEd and to have separate programs for each file.

VSAM FILE MAINTENANCE

Many times, the process of VSAM file maintenance, which uses IDCAMS to reorganize the VSAM file, is also used to perform the task of initially loading the file. The reorganization process consists of unloading (to a sequential file) the data records, DELETEing the VSAM file, DEFINEing the VSAM file again, and reloading the file's data records from the unloaded sequential file. This process reorganizes the VSAM file for                                                            
more optimal processing by redistributing the free space throughout the file and eliminating "split" data blocks. However, if there are no records in the file at the time of the reorganization, this process will produce a reorganized VSAM file that can't be opened for normal input or update processing because the HIUSED-

RBA will still be zero. Loading the file with the IDCAMS REPRO command will not reset the HI-USED-RBA if the input file is empty. The usual error, which results when the VSAM file is subsequently used for input or update processing, is "IEC161I 072-053 jobname, stepname,ddname,,,vsam-dataset-name".
The solution is to create a small program to OPEN the file, WRITE a record, optionally DELETE that record, and then CLOSE the file. This initial record is usually referred to as the "seed" record. This record can also be used as an EOF (End of File) indicator for sequential processing by using a key which is larger than other keys in the file, i.e., HIGH-VALUES. Then again, using the FILE-STATUS-CODE to determine when End of File occurs is more general and less prone to errors or confusion. Sometimes this seed record is used as a COUNTER record at the start of the file, key of LOW-VALUES. Other times, the seed record is deleted because it does not contain valid data. In a few instances, the record is ignored but remains because of the effort required to delete it. Initializing the file does not prevent the reorganization process from being run. You can simply insert the initialization step between the DEFINE and reload steps so even if there are no records in the unloaded file, the VSAM file will be initialized.


VSAM FILE TYPES
Th e re are four types of VSAM fi l e s : KSDS, RRDS, ESDS and Linear.E a ch type has a diffe re n t structure and use. The initialization process is diffe rent for the KSDS, RRDS and ESDS files , which are commonly used in application systems.

KSDS:
Keyed VSAM file for direct access by KEY or sequential processing — KSDSes have a data and index component. The data portion contains the actual data records. The index contains the KEYs and pointers to the records (RBAs [Relative Byte Address]). The index is arranged in a tree structure to allow relatively
quick direct access to specific records. The lowest level of the index, the INDEX SET, contains all of the keys and the RBAs. Sequential processing by key sequence uses the sequence set of the index to maintain record order.

RRDS :
R e l at ive Record file for direct access by RECORD NUMBER or sequential processing — RRDSes have a data component which contains the data re c o rds. Va ri able length RRDSes also have an
i n d ex component which contains the RBAs for records based on the record number, or SLOT. Random access uses the record number to access the desired record. For variable length records, the index is accessed to get the RBA for the desired record.

ESDS:
Entry Sequenced file for sequential access — ESDSes have a data component wh i ch contains the data re c o rds. Access is usually sequential and all data is added to the end of the file.

Linear:
Usually not used in application systems; used by IBM for DB2 databases — KSDS and RRDS files can be initialized and then the re c o rds can be deleted to leave the file initialized but empty. ESDS records can't be deleted. The ESDS convention is to delete s o f t wa re re c o rds by "fl agging" them as deleted with a X'FF', H I G H -VA L U E S, in the fi rst by t e.




No comments :

Post a Comment

Note: Only a member of this blog may post a comment.