Share: |

Guest post by Nick Griffin and Kathy Klimpel


First in a series


You know that while new IMS database development is scarce, existing IMS databases continue to grow. Databases, like many things in life, tend to get bigger over time. If you have web-enabled legacy IMS databases, you have probably seen significant growth in them. Traditional full-function databases are limited to 4 GB (VSAM) or 8 GB (OSAM). Once you reach those size limits, you have just a few options:


  • Convert from VSAM to OSAM
  • Compress IMS data
  • Migrate databases to Fast Path
  • Partition databases with High Availability Large Database (HALDB) or vendor partitioning


Adding more data set groups (DSGs) and moving some segments to another DSG can provide short-term relief for space constraints, but this is not a recommended option because it will require more I/Os.


The way you use the database can help you determine which path to take. Over the next few weeks, we'll take a look at each of these options.


Convert from VSAM to OSAM

The simplest way to double the size of your IMS databases is to convert the access method from VSAM to OSAM. 


To complete the conversion, allocate OSAM data sets, unload the VSAM data set, implement a DBD change to indicate that the database now uses OSAM, and reload to the OSAM data sets.


No application changes are necessary because the data structures and management by IMS remains the same. You may see an online application performance improvement because of the differences in how IMS manages buffers for OSAM.


This method works until databases approach the OSAM 8 GB limit. When your database is that large, you must compress data or partition the database, or move to Fast Path.


Next week, we'll look at compression.

The postings in this blog are my own and don't necessarily represent BMC's opinion or position.