C H A P T E R 5 - Analyzing VSAM Files

C H A P T E R 5

Analyzing VSAM Files

You might need to analyze VSAM file contents to determine whether the contents are valid. You can use the Sun MTP kixvalfle utility to assist in the analysis. kixvalfle analyzes the physical block relationships and reports possible problems.

This chapter includes the following topics:

Data Corruption

VSAM Block Structure

It also explains how to locate records in VSAM datasets. Refer to the Sun Mainframe Transaction Processing Software Administrator's Guide for more information about file integrity.

Data Corruption

This section describes how to determine if a dataset is corrupted, how to salvage a corrupted dataset, and how to load a salvaged dataset.

To Identify a Corrupted Dataset

1. Shut down the region or close the suspected dataset for access.

2. Execute the kixvalfle -i command on the suspected dataset.

You should redirect the output to a file, which you can send to your authorized service provider for further analysis. For example:

$ kixvalfle -i dataset > techsupportfile

3. If the output reports a missing block, or if it does not indicate "no errors," you might have to salvage the dataset.

To Salvage a Corrupted Dataset

1. Shut down the region or close the corrupted dataset for access.

2. Execute the kixsalvage command on the corrupted dataset.

You can use the -c option to create a file in mfrcdv format that can be sorted by a COBOL sort utility, or the -2 option to create a file in recordv format that you can sort with another sort utility. For example:

$ kixsalvage -c dataset

3. Use a sort utility to sort the salvaged data.

The definition of the dataset, the record length, and the key attributes are required.

To Load the Salvaged Dataset

1. Start the region.

Make sure that you have read and write permissions to the dataset.

2. Perform one of the following tasks:

If you are using Sun MTP standard batch:

a. Use a text editor to create a batch shell script that contains these commands:

kixfile -lY dataset

unikixbld -i -d dataset

unikixbld -tv -d dataset -s salvagedfile -r recordformat

kixfile -lN dataset

The name of the salvaged file and the record format must match the values you specified when you executed the kixsalvage command.

b. Save the script.

If you are using Sun MBM, perform a delete define of the file from a JCL script, or use the unikixbld utility to initialize the file.

3. Load the sorted salvaged file into the dataset using unikixbld or a JCL IDCAMS REPRO procedure.

4. Submit the job script.

VSAM Block Structure

Every VSAM file in Sun MTP uses the block structure shown in TABLE 5-1.

TABLE 5-1 File Block Layout
Offset	Length (Bytes)	Field Name	Field Description
0	4	Activity count	Used for file validation. If the activity count of a data file does not equal the activity count of an index file, the file is not opened.
4	4	Next block number	Points to the next block in the file in key sequence. The last block in the file in key sequence contains a zero in this field. This field is not used for ESDS (entry-sequenced) and RRDS (relative record) datasets.
8	2	Data length	Number of bytes used on the block, not including the 20-byte header. For VSAM files using a 4-KB block size, this field can have a value from 0 to 4076. This field is not used for RRDS files.
10	1	Block type Block size	The high-order nibble (shown in bold) contains one of these values: 0x00 Points to a data block; only found in index files. 0x20 Points to an index block; only found in index files. 0x40 Data block; only found in data files. 0x60 Free block; can be present in both index and data files. The low-order nibble (shown in italics) indicates the block size: 0x00, where: 0=4 KB 1=8 KB 2=16 KB 3=32 KB
11	1	Segment indicator	Contains the segment total and segment number of the physical file. Can only be set for KSDS (key-sequenced) data files, which are the only files allowed to span. The segment total is the high-order nibble; the segment number is the low-order nibble. They can only take values of 0 to 7, representing from 1 to 8 files. For example, 0x73 means that this file is the fourth file in a spanned file set of 8.
12	4	Last block in the file	Points to the last physical block in the file. Only valid on the first block of a file or on the first block of the first segment of a spanned file.
16	4	First unused block	Block number of the first unused block. Each unused block is linked in a chain through the Next Block Number field.
20	4076, 8172, 16364 or 32748	Record data	One or more data records are contained in this area. The length is determined by the VSAM block size setting (`unikixmain -b` option).

Locating a Record in an ESDS File

ESDS files store their records in sequential order. In this type of file, you can calculate the physical position of a record from the record identification (RIDFLD) field.

To Calculate the Record Position for an ESDS File With Variable Length Records

1. Determine the block number by dividing the RIDFLD by the VSAM block size minus 20 and adding 1.

2. Locate the record header by taking the result from Step 1 and adding the block header length (20).

3. Locate the record data by adding the length of the record header (4).

To Calculate the Record Position for an ESDS File With Fixed Length Records

1. Calculate the record number relative to zero by dividing RIDFLD by the record length.

2. Calculate the number of records that can fit on a block by adding the record size plus the record header size and dividing by the space available on each block (4076, 8172, 16364, or 32748).

3. Calculate the block number by dividing the record number by the number of records on a block and adding one.

The result gives the record number on the block.

4. Locate the record header in the data area by multiplying the record number on the block by the record size and the record header size (4).

5. Locate the record header in the block by adding the block header length (20).

You can read an ESDS file using the Record Editor or view it with kixview. Refer to the Sun Mainframe Transaction Processing Software Administrator's Guide for information about the Record Editor and to the Sun Mainframe Transaction Processing Software Reference Guide for information about kixview.

Locating a Record in an RRDS File

RRDS files also store their records in sequential order. In this type of file, you can calculate the physical position of a record from the RIDFLD. The record number can be converted into a byte position by calculating the number of records that can fit on a block, determining which block should contain the record, and then calculating the record location inside of that block.

The VSAM block size can be 4, 8, 16, or 32 Kbytes. The following procedure uses the default 4-Kbyte block size, a record size of 80, and a RIDFLD of 410.

To Calculate the Offset in the File Where the Record Starts

1. The number of records per block is equal to the VSAM block size minus 20 bytes (4076) divided by 80 bytes per record, plus a 4-byte record header.

This equals 48 records per block with 44 bytes unused at the end of each block.

2. The block number is equal to the RIDFLD of 410 minus 1 (because RRDS RIDFLDs are relative to 1), divided by 48 records per block plus 1 (block numbers are also relative to 1).

This results in a block number of 9.

3. Each block is 4096 bytes.

Therefore, the ninth block starts at byte 32768 in the file (relative to zero).

4. To calculate the offset in a block, determine the record number in a block.

This is equal to the RIDFLD minus 1 (since it is relative to 1), minus the total of the records per block, times the block number (410 - 1 - (48 * (9-1))) for a record number of 25. The offset in the block is then equal to the block header size, plus the total of the block record number, times the record number on the block, plus the record header size (20 + (25*84) + 4), for an offset in the block of 2124.

5. The byte offset in the file is the offset in the file to the start of the block (32768), plus the offset in the block (2124) for a byte location in the file of 34892.

You can read an RRDS file using the Record Editor or view it with kixview. Refer to the Sun Mainframe Transaction Processing Software Administrator's Guide for information about the Record Editor and to the Sun Mainframe Transaction Processing Software Reference Guide for information about kixview.

Locating a Record in a KSDS File

KSDS files and alternate index files each have a data file and an index file.

Data file

One or more data blocks that contain records. In a data block, all records are sorted in primary key sequence. However, if the blocks are read sequentially, the records in one block would not necessarily have lower keys than the next sequential block.

The blocks are treated as a linked list when reading each block in key order; the first physical block in the file contains the lowest key.

Each block contains a next block number that points to the next block in primary key order. To find any specific record by key requires reading the index file.

Index file

Contains key pointers that are made up of the block number and the highest key on that block.

The index file starts with a single index block that contains key pointers to the data blocks in the data file. When the single index block is full of key pointers, it is split. The key pointers are moved with half going to one new index block and the remainder going to a second new block. The original block then has two key pointers pointing to these two new index blocks, thereby creating a two-level index.

When additional index blocks are required, they are added to the second index level, pointing to the data file until that index level fills up. When that happens, a third index level is created. This continues for as many index levels as required.

You can read a KSDS file using the Record Editor or view it with kixview. Refer to the Sun Mainframe Transaction Processing Software Administrator's Guide for information about the Record Editor and to the Sun Mainframe Transaction Processing Software Reference Guide for information about kixview.

VSAM Data and Index Formats

Each data record in Sun MTP files has the format shown in TABLE 5-2. This format is used for KSDS, ESDS, and RRDS files. Each record's data is preceded by a 4-byte record header. When the record is greater than the VSAM block size minus 24 bytes, the record is spanned; each segment of the spanned record has a 4-byte header. When spanned records are present, they always start at the beginning of the data portion of a block. Each segment of a spanned record uses the entire data portion of a block except for the last segment. The remaining space on the block is always unused.

Note - KSDS alternate index data files and KSDS index files do not use this spanned record format.

TABLE 5-2 Data Record Layout
Offset	Length (Bytes)	Field Name	Field Description
0	2	Record length	The record length of the record that follows, including the 4-byte header. If this is the first part of a spanned record, this field contains the entire record length. For the second or subsequent part of a spanned record, this value is zero. For RRDS files, if this value is zero, the record slot is empty.
2	2	Spanned record length	Used only for spanned records. It contains the amount of record data contained on this block.
4	1-4072, 1-8168, 1-16360 or 1-32744	Record data	Actual record data. The length depends on the VSAM block size. Using a 4096-byte block size, if the record is less than 4072 bytes, this is the entire record. If the record contains more than 4072 bytes, each part of the record contains exactly 4072 bytes except for the last part, which contains whatever is needed to complete the record.

Index files in Sun MTP contain entries that point to other index entries or to data blocks depending upon the number of index levels. You can determine where a specific index entry points from the block type field of the block header.

The format of index entries is shown in TABLE 5-3.

TABLE 5-3 Index Entry Format
Offset	Length (Bytes)	Field Name	Field Description
0	1-255	Record key	Highest key for the block to which this key points. The only exception to this rule is when the key points to the block containing the highest key in the file. In this situation, each character in the key contains 0xff.
Key Length	4	Block number	Block number in either the data file or a lower level index in this file.