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’ve probably seen significant growth in them. Traditional, full-function databases are limited to 4GB (VSAM) or 8GB (OSAM). Once you reach those size limits, you have a few options:
- Convert from VSAM to OSAM
- Compress IMS data
- Partition databases with High Availability Large Database (HALDB) or vendor partitioning
- Migrate databases to Fast Path.
You can implement Database Design (DBD) changes, implement compression, or complete a database restructure project by moving to partitioned databases or Fast Path. The way you use the database can help you determine which path to take. This article examines these options and relevant considerations.
Note: Adding more Data Set Groups (DSGs) and moving some segments to another DSG can provide short-term relief for space constraints, but this isn’t a recommended option because it will require more I/Os.
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 (4GB vs. 8GB). 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; the data structures and IMS management remain the same. You may also obtain an online application performance improvement due to the differences in how IMS manages buffers for OSAM. This method works until databases approach the OSAM 8GB limit. When your database is that large, you must compress data or partition the database.
Another option you can use to manage large amounts of IMS data is to compress it. Compression reduces costs by requiring less DASD for storing compressed data and reducing the load placed on I/O processing. If you need to improve online application performance, maintain high data availability and reduce batch application elapsed times, software compression may be a viable option.
Compression provides these benefits:
- Better buffer hit ratios for online transactions
- Smaller logs, which lead to smaller log volume, fewer log switches, fewer archive executions, and shorter change accumulation run times
- Dramatically lower costs for image copy space and storage; recoveries can be completed faster because compressed image copies can be applied quickly.
- Improved utility maintenance times. If it takes 60 minutes to reorganize a database with no compression, implementing a compression percentage of 50 percent can potentially shorten the reorganization to 30 minutes.
- Lower I/O costs. With compression, segments and data in buffers are smaller. Because the data being read into the buffer is compressed, you can allocate smaller buffers or a smaller number of buffers.
- Non-displayable data. Compressed data is non-displayable, which may meet some security standards.
- Improved online IMS application response time through efficient use of IMS buffers and virtual storage
- Reduced segment splits and related I/O
- Efficient free space utilization
- Reduced elapsed time and I/O activity for sequential batch IMS applications.
When implementing compression, choose a technique that yields the best compression percentage for your data. Several vendor compression tools are available, and the various compression techniques (algorithms) will yield different compression percentages for your data.
Test your data to determine which compression technique works best with your data. For example, the Huffman algorithm tends to provide the highest compression percentage for short, hierarchical data. On the other hand, the Ziv-Lempel algorithm, used for hardware compression, works best with relational data and long segments. The software you choose will offer many compression options, and you can see which one works best in your environment.
Hardware vs. Software Compression
For IMS, accessing and using native hardware compression isn’t a viable option. IBM implemented hardware compression using a software compression product. Even if you choose hardware compression, you must implement software for IMS to communicate with the hardware.