Is it worth using VSAM over Sequential files in COBOL ?

Swathi Javvaji
5 min readMay 6, 2020

Who might have thought I would blog one day! I want my first blog to be a special one. So why not choose the most favorite thing in the world. It is mainframes, yeah !

During the short span of me being a mainframes developer, I always had this tendency to seek a happy path to accomplish things. Then I changed my career path to a QA, then to BA and then to Systems Programmer working on distributed systems and became a stranger to mainframes . I thrive on learning new things and accepting new challenges. When I got a chance to work on Mainframes recently as part of some research in my project, being a great fan of mainframes, in spite of not knowing much about COBOL and VSAM , I gladly accepted the challenge.

My experience with VSAM :

I have coded small JCLs for creating VSAM files during my mainframe training without giving much thought about advantages and disadvantages of VSAM.

Definitely not like this

How did the need arise ?

Our team is working on a batch application and we wanted to try if it would be possible to make the application robust without changing the functionality. The application was entirely coded using sequential datasets.The suggestion to introduce VSAM in the application popped up.

What did the QA in me advise ?

Since it was mainframes, I (the developer side)came forward to take the research . But he QA in me is always pessimistic. So I find ways to first prove why that might be a bad idea. Started researching for disadvantages.

To my surprise, there are very few disadvantages when compared to advantages.

Disadvantages of VSAM :

• VSAM Datasets require more storage space compared to other type of
datasets due to Control Information (CI) present in them.
• VSAM can’t be stored in TAPE Volume i.e., VSAM Stored only in DASD
• We can’t browse, view, edit the VSAM datasets in ISPF.
• VSAM is not a database like DB2, IMS DB & IDMS.

Then started my actual research for the change.

What is a sequential dataset ?

In a sequential data set, records are data items that are stored consecutively.

Creation of sequential dataset is pretty simple and straight forward.

In JCL :

In COBOL :

What is a VSAM dataset and VSAM access method ?

VSAM datasets are described as four datatypes : KSDS, ESDS, RRDS and LDS

Key Sequence Data Set (KSDS):This type is the most common use for VSAM. Each record has one or more key fields and a record can be retrieved (or inserted) by key value. This provides random access to data. Records are of variable length.

Entry Sequence Data Set (ESDS):This form of VSAM keeps records in sequential order. Records can be accessed sequentially.

Relative Record Data Set (RRDS):This VSAM format allows retrieval of records by number; record 1, record 2, and so forth. This provides random access and assumes the application program has a way to derive the desired record numbers.

Linear Data Set (LDS):This type is, in effect, a byte-stream data set and is the only form of a byte-stream data set in traditional z/OS files .

Why use VSAM instead of sequential ?

  • VSAM improves efficiency.
  • Supports more dataset types and variety of I/O techniques.
  • Records can be retrieved using VSAM access method (without having to process the preceding records).
  • Inserting data is faster and easier due to embedded free space in the cluster.
  • Records can be sequentially and randomly.
  • Supports online and batch.
  • Deletion of records results in them physically removed from DASD.

My changes :

I did minor changes in JCLs and COBOL programs wherever needed .

In JCL : The cluster creation of VSAM was tricky.

IDCAMS utility :

Utility programs are pre-written programs, widely used in mainframes by system programmers and application developers to achieve day-to-day requirements, organizing and maintaining data. IDCAMS utility is used to create, modify and delete the VSAM datasets.

In COBOL : We have to declare the file inside the COBOL program as INDEXED for VSAM.

File Extended Status :

Extended file status codes use the second byte as a binary (COMP-X) item. Extended file status codes have the character “9” in the first byte. The second byte is a binary (COMP-X) number, which is equivalent to a run-time error number.

Some observations :

Tip 1 : It is a wise idea to delete the cluster in JCL before creating it (if you run the JCL second time, it might throw a JCL error indicating the existence of dataset).

Tip 2 : Do not forget to add the extended status of file in the file section.

The Enhancements :

Once the application is changed to using VSAM datasets, we have faster access to the datasets and we could store the data in an organized and structured way. At the end , it was worth experimenting new changes in our application and blogging about it.

--

--