Understanding VSAM SHAREOPTIONs

SHAREOPTIONs are settings that provide various levels of shared access to VSAM files. This capability has been available for decades, and on initial review, it appears to be an easy way to provide file sharing. Let's take a closer look at the SHAREOPTIONs and exactly what it takes to implement this approach.

SHAREOPTION 1 is the most restrictive of all SHAREOPTIONs, disallowing any file sharing if updates occur. This SHAREOPTION permits a single region to write to a VSAM data set or enables many regions to read a data set. If a region is updating the file, all access to the file is denied to any region seeking to perform a read, so this option is often deemed unacceptable. Yet, performance wise, this is the most effective SHAREOPTION to use.

SHAREOPTION 2 also prohibits concurrent data set updates, but provides for multiple reads during an update process. This function is typically used where CICS is the updating application with infrequent data reading from batch. A major drawback of SHAREOPTION 2 occurs when a reading region attempts to access data that an update region has modified. It is possible that the reading region will not receive the most recent updates and could terminate abnormally if substantial data changes have occurred.

SHAREOPTION 3 on the surface, appears to solve the limitations of SHAREOPTION 2 by enabling multiple, concurrent updates. Because SHAREOPTION 3 permits multiple regions to both read and write to a single data set, it would also permit multiple regions to concurrently update identical blocks of records, causing a loss of physical data. Using SHAREOPTION 3 could lead to VSAM data integrity issues and increased overhead.

SHAREOPTION 4 requires extensive and complex programming modifications to your application. These modifications will increase I/O overhead to ensure data integrity. Use of SHAREOPTION 4 will not enable a single CICS region to lock onto its required records. An environment using SHAREOPTION 4 and enabling concurrent updates by both CICS and batch could experience a severe data integrity problem in the event of a CICS transaction abend. The CICS dynamic transaction backout will replace all the transaction-updated records with initial values, even if a batch job updated the records.

Practical implications: Employment of a higher VSAM SHAREOPTION translates into increased overhead. Additionally, the risk of error increases when there is less data-integrity protection. Employing VSAM SHAREOPTIONs for concurrent update access between CICS regions and batch jobs is rarely a suitable solution for companies striving to ensure processing efficiency and data integrity.

VSAM file handling

This tutorial explains how file operations are performed on ESDS, KSDS, RRDS files of VSAM access method.

This tutorial is organized by the following topics.

• VSAM File Organization  
• File Access Modes  
• In the ENVIRONMENT Division
• In the PROCEDURE Division

1. ·  The OPEN Statement
2. ·  The READ Statement
3. ·  The START Statement
4. ·  The WRITE Statement
5. ·  The REWRITE Statement
6. ·  The DELETE Statement
7. ·  The CLOSE Statement  

VSAM File Organisation

There are three types of file organisation you can use with VSAM.

VSAM sequential file organisation -

Also referred to as VSAM ESDS (Entry Sequenced Data Set) organisation. In such a data set the records are stored in the order in which they were entered. The order of the records is fixed. Records in sequential files can only be accessed (read or written) sequentially.

VSAM indexed file organisation –

Also referred to as VSAM KSDS (Key Sequence Data Set) organisation. In a KSDS the records are ordered according to the collating sequence of a prime key field defined in each record. This key field consists of one or more consecutive characters within the records and uniquely identifies each record. A prime key for a record might be, for example, an employee number or an invoice number. In your COBOL program, you specify this key through the clause:

RECORD KEY IS data-name

where data-name is the name of the key field as you defined it in the record description entry in the Data Division. The data set can be accessed sequentially, i.e. in primary key sequence, or directly by specifying the key of the record required.

You can also specify one or more alternate keys to use for retrieving records. Using alternate keys you can access the file to read records in some sequence other than the prime key sequence. For example, you could access the file through employee department rather than through employee number. Alternate keys need not be unique, more than one record will be accessed, given a department number as a key. This is permitted if alternate keys are specified as allowing duplicates

.

VSAM relative-record file organisation -

Also referred to as VSAM RRDS (Relative-Record Data Set) organisation. A RRDS is a series of fixed length slots in storage into which you place records. The relative key identifies the record - the relative key being the relative record number of the slot that the record occupies.

File Access Modes

You can access records in VSAM KSDS and RRDS files in three ways, sequentially, randomly or dynamically. (Records in an ESDS file can be accessed sequentially).

1. Sequential Access -

For indexed files, records are accessed in the order of the key field selected (either primary or

alternate). For relative files, records are accessed in the order of the relative record numbers.

2. Random Access -

For indexed files, records are accessed according to the value that you place in the key field.

For relative files, records are accessed according to the value that you place in the relative key.

3. Dynamic Access

Dynamic access is a mixture of sequential and random access within the same program. Using

dynamic access, you can write one program to perform both sequential and random processing,

accessing some records in sequential orders and others by their keys. As this method allows the

greatest flexibility it is usually coded.

Example

Suppose you had a KSDS of employee records and the hourly wage formed the record key. Also

suppose your program was interested in those employees earning £7 and £9 per hour and those

earning £15 per hour and above.

To do this, retrieve the first record randomly based on the key of 0700. Then begin reading

sequentially until the wage field exceeds 0990. Then switch back to random read, this time based

on a key of 1500 and then switch back to reading sequentially until you reach the end of the file.

In the ENVIRONMENT Division

For an ESDS:

SELECT file-name

ASSIGN TO UT-AS-ddname

ORGANIZATION IS SEQUENTIAL

ACCESS MODE IS SEQUENTIAL

FILE-STATUS IS data-name-1 data-name-2.

Notes:

(1) The ORGANIZATION and ACCESS clauses are optional as the default is SEQUENTIAL.

(2) The PASSWORD clause is not used within Boots.

(3) The FILE STATUS clause monitors the execution of each input-output request for the file. This clause is optional but when it is specified, the system moves a value into data-name-1 after each input-output request that explicitly or implicitly refers to this file. This field is defined in the Data Division (although not on the File Section) as a two-byte alphanumeric item and must not be the object of an OCCURS DEPENDING ON clause.

(4) Data-name-2 can be coded in VS COBOL II programs to access native VSAM return code

information to the COBOL program. This field must be defined as a group item of 6 bytes in the

Working-Storage Section or Linkage Section of the Data Division.

The first 2 bytes of data-name-2 contain the VSAM return code in binary notation.

It can take a value of 0, 8, or 12.

The next 2 bytes contain the VSAM function code in binary notation. The value for this

code is defined as 1, 2, 3, 4, or 5.

The last 2 bytes of data-name-2 contain the VSAM feedback code again in binary. The

code value is 0 through to 255.

The Function Code and Feedback Code are set only if the Return Code is set to non-zero. If they

are set when the Return Code is zero, the contents of the fields are not reliable.

Example

SELECT VSAM-MASTER ASSIGN TO UT-AS-VSMAST

FILE STATUS IS STATUS-CODE VSAM-RETURN-CODE.

WORKING-STORAGE SECTION.

01 STATUS-CODE PIC XX.

01 VSAM-RETURN-CODE.

05 VSAM-R15-RETURN-CODE PIC S99 COMP.

05 VSAM-FUNCTION-CODE PIC S9 COMP.

05 VSAM-FEEDBACK-CODE PIC S999 COMP.

In the ENVIRONMENT Division

For a KSDS:

SELECT file-name

ASSIGN TO UT-ddname

ORGANIZATION IS INDEXED

ACCESS MODE IS SEQUENTIAL / RANDOM / DYNAMIC

RECORD KEY IS data-name-1

ALTERNATIVE RECORD KEY IS data-name-2

WITH DUPLICATES

FILE-STATUS IS data-name-3 data-name-4

Notes:

(1) The RECORD KEY clause specifies the data item within the record that is the prime record key for the indexed file. The value contained in this data item must be unique among records in the file. Data-name-1 must be described as an alphanumeric item within the record description. An IBM extension allows data-name-1 to be defined to be numeric, numeric-edited, alphanumeric-edited or alphabetical though the key is still treated as an alphanumeric item for the input and output statements for the named file.

(2) The same rules apply to the ALTERNATE RECORD KEY clause as in note 1. Data-name-2

must not be at the same position on the record as the primary index key or any other alternate

record key field.

(3) If the DUPLICATE clause is specified, the values contained in the ALTERNATE RECORD

KEY data item may be duplicated within any records in the file. In sequential access, the records

with duplicate keys are retrieved in the order in which they were placed in the file. In random

access, only the first record written of a series of records with duplicate keys can be retrieved.

Example

SELECT MASTER-FILE ASSIGN TO UT-KSDSMAST

ORGANIZATION IS INDEXED

ACCESS MODE IS DYNAMIC

RECORD KEY IS MAT-EMP-NO

ALTERNATE RECORD KEY IS MAST-EMP-DEPT

WITH DUPLICATES

FILE STATUS IS STATE-CODE VSAM-RETURN-CODE.

In the ENVIRONMENT Division

For RRDS:

SELECT file-name

ASSIGN TO UT-ddname

ORGANIZATION IS RELATIVE

ACCESS MODE IS SEQUENTIAL / RANDOM / DYNAMIC

RELATIVE KEY IS data-name-1

FILE-STATUS IS data-name-2 data-name-3.

Notes :

(1) The RELATIVE KEY clause identifies a data-name that specifies the relative record number for a specific logical record within the relative file. Data-name-1 must be defined as an unsigned integer data item and must not be included in the record description entry for the data set. That is the relative key is not part of the record.

(2) When ACCESS MODE IS SEQUENTIAL the Relative Key data field need not be specified

unless the START statement (see page 10) is to be used. When the START statement is used the

contents of data-name-1 are used to determine where processing of the data set is to begin. If a

value is put into the Relative Key field, and a START statement is not used, then the value is ignored and processing begins with the first record in the file.

(3) For RANDOM or DYNAMIC access the Relative Key field must be specified and a value

inserted as it is used to obtain the record with that relative record number.

In the Procedure Division

1. The OPEN Statement:

OPEN INPUT / OUTPUT / I-O / EXTEND file-name-1 file-name-2 ...

Notes:

(1) INPUT permits opening the file for input operations.

(2) OUTPUT permits opening the file for output operations. This is specified when a file is being

created. If OUTPUT is specified for a file that contains records, the file will be replaced by the new data.

(3) I-O permits opening the file for input and output operations. The I-O option may be specified

only for the files assigned to direct access devices.

(4) EXTEND permits opening the file for output operations. The EXTEND phrase is only allowed for sequential access files. When an OPEN EXTEND statement is executed, the file is prepared for the addition of records immediately following the last record in the file. (The record with the highest prime record key value is considered the last record.) Subsequent WRITE statements add records as if the file were opened OUTPUT.

(5) After the OPEN statement you should check the "Status Code" for successful completion of the OPEN. If it has successfully executed then the Current Record Pointer is set to the first record in the data set. In the case of KSDS this will be the record with the lowest primary index key and for a RRDS it is set to 1. If the data set is empty then the Current Record Pointer will be set to indicate end of file in the case of a sequential read being executed.

2. The READ Statement

For a sequential READ

READ file-name NEXT RECORD

INTO identifier-1

AT END statement-1

END-READ

Notes:

(1) The sequential READ must be used for all data sets in sequential access mode.

(2) The NEXT RECORD is the next in the logical sequence of records. For a KSDS this is the

ascending value of the current Key of Reference (i.e. the primary index key or the alternate index

key being used). For RRDS the sequence is the ascending value of the Relative Record numbers

for the records that exist in the data set. The word NEXT can be omitted for files that have

sequential access mode.

(3) Before the READ statement is executed, the Current Record Pointer must be set by a successful OPEN, START, or READ statement.

(4) If the Current Record Pointer indicates that no next logical record exists, the following occur in the order specified:

(a) The value '10' is placed into the "Status-Code" associated with the file-name to indicate the AT END condition.

(b) If the AT END clause has been specified control is transferred to statement-1 in the

clause.

(5) If the FILE STATUS clause has been used for the data set then the "Status-Code" field is

updated when the READ statement has been executed.

For a Direct READ:

READ file-name RECORD

INTO identifier-1

KEY IS data-name-1

INVALID KEY statement-1

END-READ

Notes:

(1) Direct retrieval is used for KSDS and RRDS with ACCESS MODE specified as RANDOM or DYNAMIC. As stated previously, DYNAMIC access allows both direct access and sequential

access to the data set and because of this greater flexibility this is used at Boots.

(2) The KEY IS clause is specified only for a KSDS. Data-name-1 must identify a record key

associated with file-name - either the prime record key or any alternate record key.

(3) The value of the key of the KSDS record required must be moved to the key field before the

READ statement is issued. Then when the READ statement is executed it causes this value to be

compared with the value of the corresponding key data item in the file records, until the first record having an equal value is found. The Current Record Pointer is then positioned to this record, which is then made available. If no match is found then the INVALID KEY condition exists. In this case a value of '23' is returned to the "Status CODE" field and control passes to statement-1.

(4) If the KEY IS phrase is not specified, the prime RECORD KEY or the last key field that was

used by a READ becomes the key of reference for this request.

(5) For the RRDS, execution of the direct READ statement sets the Current Record Pointer to the

record whose relative record number is contained in the RELATIVE KEY data item specified in the SELECT clause, and makes the record available. If the file does not contain such a record, the INVALID KEY condition exists. The KEY IS clause may not be specified for a RRDS.

3. The START Statement:

This statement provides a means of positioning the Current Record Pointer within a KSDS or

RRDS for subsequent sequential record retrieval.

START file-name

KEY IS operand data-name-1

INVALID KEY statement-1

END START

where operand is: =,>,<,NOT<,>=,etc

Notes:

(1) When the KEY IS clause is specified, the Current Record Pointer is positioned at the logical

record in the file whose key field satisfies the comparison. When the KEY IS clause is not

specified, KEY IS EQUAL (to the prime record key or relative key) is implied.

(2) The comparison made during the execution of a START statement is between the current value in data-name-1 and the corresponding key field in the file's records.

(3) For a KSDS, data-name-1 can be any of the following:

- The prime RECORD KEY

- Any ALTERNATE RECORD KEY

- An alphanumeric data item which re-defines the record key for the file.

(4) When the START statement is successful, the RECORD KEY with which data-name-1 is

associated becomes the key of reference for subsequent READ statements.

(5) For a RRDS, when the KEY IS clause is specified, data-name-1 must be the relative key.

(6) If the FILE STATUS clause is specified in the FILE-CONTROL entry then the associated

"Status Code" is updated when the START statement is executed.

(7) If the comparison is not satisfied by any record in the file, an INVALID KEY condition exists and if specified statement-1 is executed.

4. The WRITE Statement

For an ESDS

WRITE record-name

FROM identifier-1

END-WRITE

For a KSDS and a RRDS

WRITE record-name

FROM identifier-1

INVALID KEY statement-1

END-WRITE

Notes:

(1) For the WRITE statement to be successful the data set must have been OPENED for

OUTPUT, I-O, or EXTEND.

(2) For a KSDS, before the WRITE statement is executed, the required value must be placed in the prime record key or alternate record key field. When ACCESS IS SEQUENTIAL, records must be released in ascending order of the record key values. When ACCESS IS RANDOM or

ACCESS IS DYNAMIC, records may be released in any programmer-specified order.

(3) For a KSDS, an INVALID KEY condition is caused by any of the following:

- ACCESS IS SEQUENTIAL and the file is opened for OUTPUT, and the value of the

prime record key is not greater than that of the previous record.

- The file is opened I-O and the value of the prime record key equals that of an already

existing record.

- An attempt is made to write beyond the externally defined boundaries of the file.

When an INVALID KEY condition is recognised, WRITE statement execution is unsuccessful and the contents of the record are unaffected.

(4) For a RRDS, when ACCESS IS SEQUENTIAL, the first record released has relative record

number 1, the second record released has a relative record number of 2 and so on. If ACCESS IS

RANDOM or ACCESS IS DYNAMIC the RELATIVE KEY must contain the desired relative

record number for the record before the WRITE statement is issued..

(5) The Current Record Pointer is not affected by the execution of a WRITE statement.

5. The REWRITE Statement:

This statement logically replaces an existing record in a direct-access file.

REWRITE record-name-1

FROM identifier-1

INVALID KEY statement-1

END-REWRITE

Notes:

(a) To use the REWRITE statement the data set must have been opened for I-O.

(b) For files in the sequential access mode, the input/output statement executed for this file must be a successfully executed READ statement. When the REWRITE statement is executed, the record retrieved by the READ statement is replaced.

(c) For a KSDS:

- when the access mode is sequential, the record to be replaced is specified by the value

contained in the prime record key. When the REWRITE statement is executed, this value

must equal the value of the prime record key data item in the last record READ from this

file.

- when the access mode is random or dynamic, the record to be replaced is specified by the value contained in the prime record key.

- values of alternate record keys in the rewritten record may differ form those in the record being replaced.

- an INVALID KEY condition exists when:

·  the access mode is sequential and the value contained in the prime record key of the record to be replaced does not equal the value of the prime record key data item of the last retrieved record from the file, or

·  the value contained in the prime record key does not equal that of any record in the file, or

·  the value of an alternative record key data item for which "duplicates" is not specified is

·  equal to that of a record already in the file.

(d) For a RRDS

- when the mode is sequential, the INVALID KEY clause may not be specified.

- when the access mode is random of dynamic, the record to be replaced is specified on in

the RELATIVE KEY data item. If the file does not contain the record specified, an invalid key condition exists and, if specified, statement-1 is executed.

(e) The Current Record Pointer is not affected by the execution of the REWRITE statement.

6. The DELETE Statement:

This statement removes a record from a KSDS or RRDS file. For indexed files, the space is then

immediately available for a new record. For relative files, the space is then available for new record with the same relative key value.

DELETE file-name RECORD

INVALID KEY statement-1

END-DELETE

Notes:

(a) To use the DELETE statement the data set must be opened in I-O mode.

(b) After successful execution of a DELETE statement, the record is removed from the file and can no longer be accessed.

(c) The Current Pointer Record is not affected by execution of the DELETE statement.

(d) For a file in sequential access mode, the last previous input/output statement must be a

successfully executed READ statement. When the DELETE statement is executed the system

removes the record retrieved by the read statement. The INVALID KEY clause must not be

specified for a file in this access mode.

(e) For a file in random or dynamic access mode, when the DELETE statement is executed, the

system removes the record identified by the contents of the prime record key for a KSDS, or the

relative key field for a RRDS. If the file does not contain such a record, an INVALID key

condition exists.

7. The CLOSE Statement

CLOSE file-name-1 WITH LOCK

Notes:

(a) If the WITH LOCK clause is specified the compiler ensures that this file cannot be opened again during this execution of the object program.

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.

What does that VSAM Status Code Mean?

 Every operation you carry out to access a VSAM file in COBOL will return a file status code to indicate whether the operation completed successfully or not. It is good practice when programming to check the VSAM status code after any operation carried out on a VSAM file to check that the OPEN, READ, etc completed successfully. To use the status code you must define a working storage field that will contain the file status, and use the clause "FILE STATUS IS status" on the SELECT statement.

The codes returned are listed in the table below.

 File Status Cause
00 Operation completed successfully
02 Duplicate Key was found
04 Invalid fixed length record
05 The file was created when opened - Successful Completion
07 CLOSE with REEL or NO REWIND executed for non tape dataset.
10 End of File encountered
14 Attempted to READ a relative record outside file boundary
21 Invalid Key - Sequence error
22 Invalid Key - Duplicate Key found
23 Invalid key - No record found
24 Invalid Key - key outside boundary of file.
30 Permanent I/O Error
34 Permanent I/O Error - Record outside file boundary
35 OPEN, but file not found
37 OPEN with wrong mode
38 Tried to OPEN a LOCKed file
39 OPEN failed, conflicting file attributes
41 Tried to OPEN a file that is already open
42 Tried to CLOSE a file that is not OPEN
43 Tried to REWRITE without READing a record first
44 Tried to REWRITE a record of a different length
46 Tried to READ beyond End-of-file
47 Tried to READ from a file that was not opened I-O or INPUT
48 Tried to WRITE to a file that was not opened I-O or OUTPUT
49 Tried to DELETE or REWRITE to a file that was not opened I-O
91 Password or authorization failed
92 Logic Error
93 Resource was not available (may be allocated to CICS or another user)
94 Sequential record unavailable or concurrent OPEN error
95 File Information invalid or incomplete
96 No DD statement for the file
97 OPEN successful and file integrity verified
98 File is Locked - OPEN failed
99 Record Locked - record access failed.

VSAM buffering tips

Tuning Sequential Access


Default data buffers for KSDS is 2

• one reserved for splits
• #of I/O equal number of data CI’s that contain data 

Determining Optimal Data Buffers for Input Data Set

Best performance is achieved when data component is read in full tracks

CI/Track=(PHYRECS/TRK) x (PHYREC-SIZE)

                     CISZD

PHYRECS/TRK = physical records per track  - from LISTCAT  

PHYREC-SIZE = physical record size  - from LISTCAT  

CISZD= data control interval size - from LISTCAT  

Optimum value of BUFND is =CIs per track +1

Example:

From IDCAMS LISTCAT..

CISIZE--------------4096

PHYRECS/TRK-----------12

PHYREC-SIZE---------4096

CI/Track=12 x 4096 = 12

              12

BUFND (for input dataset)=CI/TRK+1     = 13

BUFND (for output dataset)=CI/TRK+2    = 14

Random Access - Batch

Default index buffers for KSDS is 1

Best performance is achieved when enough buffers are allocated to keep all index CI’s in memory, plus one for the sequence set reads.

Index Buffers for Input Data Set

BUFNI=HURBAI -      HURBAD      + 1

      CISZI    CISZD X (CI/CA)

HURBAI = High Used RBA of index component   - from LISTCAT 

HURBAD = High Used RBA of data component   - from LISTCAT  

CI/CA = number of data CI in each data CA  - from LISTCAT  

CISZI= index control interval size - from LISTCAT  

CISZD= data control interval size - from LISTCAT  

Example:

From IDCAMS LISTCAT..

HI-U-RBA (index)-----------12288 

CISIZE (data)--------------4096

HI-U-RBA (data)----------540672

CI/CA--------------------12

BUFNI = 12288 - 540672  + 1

        1024   4096 X 12

BUFNI = 12 - 11 + 1 = 2

VSAM : Calculating ALT INDEX record length

The definition looks like this :

   RECORDSIZE (x1 x2), where x1 is the average record length and  
                             x2 is the maximum record length.     
                                                                  
Record size is computed as follows :                               
------------------------------------                               
For a KSDS :                                                       
RECORD SIZE = 5 + ALTERNATE KEY LENGTH + ( n * PRIME KEY LENGTH )  
   where 'n' is the number of NONUNIQUE PRIME KEYs                
For an ESDS :                                                      
RECORD SIZE = 5 + ALTERNATE KEY LENGTH + ( n * 4 )                 
   where 'n' is the number of NONUNIQUE POINTERs                  
                                                                  
{ The 5 is for 5 bytes in the beginning with the following info :  
 Byte 1 : Housekeeping, the least significant bit of which is used to indicate if it is for KSDS or ESDS - 0 for ESDS, 1 for KSDS            
 Byte 2 : Length of Pointer/Prime Key                             
 Bytes 3-4 : Number of Pointers/Prime keys (ie. no of duplicates) 
 Byte 5 : Length of Alternate Key                                 
}                                                                  

Now, how do we compute the average and Maximum record lengths :      
---------------------------------------------------------------      
    This depends on the number of duplicates we expect the ALT KEY to have. Hence if we don't expect any duplicates the AVG and MAX record length would be the same.
(Usually the AVG record length is computed, assuming there are no duplicates - i.e. n=1. It doesn't make a big difference anyway, since the MAX record length is more important).
                                                                    
eg1) Let us assume the Prime key for a KSDS is defined as KEYS (10 0) and 
   ALT key is defined as KEYS (20 30) in definition for ALT INDEX      

   Assuming there can be a maximum of 50 duplicates, RECORDSIZE should be defined as RECORDSIZE (35 525).                
  i.e. as per the formula :                                         
  AVG rec length = 5 + 20 + (1  * 10) = 35  (assuming no duplicates)  
  MAX rec length = 5 + 20 + (50 * 10) = 525 (assuming 50 duplicates)
   since Prime Key length = 10 and
         ALT Key length   = 20.
                                                                    
eg2) For the same example, if the ALT INDEX was defined with the option UNIQUEKEY (i.e. no duplicates), then AVG and MAX record lengths would have been 35.