Choosing a VSAM data set type - VSAM

During the application development process, the application programmer needs to make decisions about the data model. Among these decisions, we have data organization, function, type of access, performance, and recovery tools you need. VSAM has several organizations and different ways for accessing your data. How to choose the one for your application is discussed here.

Before you select a particular VSAM organization, you need answer the following questions:

  • What is the main purpose of your data set? Does it look more like a log, a database, or an inventory?
  • Do you need to access data by a key field in sequential or direct mode?
  • Do you need to access the records in sequence, skip sequential, randomly, or all of them?
  • Are all the logical records the same length?
  • Does the logical record length change?
  • Do you need to have insertions and deletions?
  • Is the data set going to be extended?
  • How often do you need to delete records?
  • Do you use spanned records?
  • Do you want to keep the data in order by the contents of the key field?
  • Do you want to access the data by an alternate index?
  • Do you want to exploit DIV?
  • Do you want to use data compression?
  • Do you need the utility functions provided by IDCAMS?

When you have answered these questions, you can use them to choose the best organization for your data set. Remember that VSAM data sets cannot be processed using non-VSAM applications. Similarly, non-VSAM data sets cannot be processed using the VSAM access method.

Following are our recommendations for choosing a data set organization.

  • Use QSAM or BSAM if:
  • – You use no direct processing.
    – There are no insertions or deletions, and no change in the logical record length.
    – Record additions are only at the end of the data set.
    – You are not concerned about IDCAMS functions.
    – You want to have data compression.
    – Performance and easy recovery are main issues.
  • Use KSDS if:
  • – The data access is sequential, skip sequential, or direct access by a key field.
    – You would prefer easy programming for direct data processing.
    – There will be many record insertions, deletions, and logical record length variations.
    – You may optionally access records by an alternate index.
    – Complex recovery (due to index and data components) is not a problem.
    – You want to use data compression.
  • Use VRRDS if:
  • – You have the same requirements as for a KSDS, but will use record number instead of a key field as argument.
  • Use RRDS if:
  • – The record processing is sequential, skip sequential, or direct processing.
    – Easy programming for direct processing is not a requirement.
    – The argument for accessing data in direct mode is a relative record number, not the contents of a data field (key). RRDS is suitable for the type of logical records identified by a continuous and dense pattern of numbers (such as 1,2,3,4...).
    – All records are fixed length.
    – There are a small number of record insertions and deletions, and all the space for insertions must be pre-allocated in advance.
    – Performance is an issue. RRDS performance is better than KSDS, but worse than QSAM or BSAM.
  • Use ESDS if:
  • – You are adding logical records only at the end of the data set and reading them sequentially (in the application control).
    – The logical record is variable length
    – You seldom need direct record processing by key (using AIX).
    – You are using a batch processing application.
  • Use LDS if:
  • – You want to exploit DIV.
    – Your application manages logical records.
    – Performance is an issue.

Many times, you will be using a specific VSAM organization depending on the software product you are running — for example, DB2 uses LDS data sets. In this case you do not have the option to chose the VSAM organization.


All rights reserved © 2018 Wisdom IT Services India Pvt. Ltd DMCA.com Protection Status

VSAM Topics