IMS Performance Tuning and Monitoring

IMS performance tuning requires understanding where time is spent in the DL/I call path and what adjustments reduce that time. Unlike SQL query tuning, IMS tuning focuses on physical I/O reduction through buffer pool sizing, database reorganisation to reduce pointer chain lengths, and PSB optimisation to minimise segment sensitivity overhead.

Understanding IMS Response Time Components

An IMS DL/I call spends time in these phases:

1. Language interface overhead: Small fixed cost for CALL 'CBLTDLI' setup
2. Buffer pool lookup: Checking whether the target block is already in memory
3. Physical I/O: Reading the block from disk if not buffered (the dominant cost)
4. Segment navigation: Following pointers through the block
5. PCB update: Updating status codes and key feedback

Physical I/O is by far the most expensive component. Any tuning strategy focuses on eliminating unnecessary physical I/O.

Buffer Pool Tuning

IMS uses buffer pools to cache database blocks in memory. A properly sized buffer pool means most DL/I calls find their data in memory — no physical I/O.

OSAM buffer pools (for HDAM/HIDAM databases):

POOLID=DBPOOL1,SIZE=4096,NUM=5000

This allocates 5,000 buffers of 4096 bytes each = ~20 MB for this pool.

Monitoring buffer pool effectiveness: Use IMS statistics (IMSSTAT utility or IBM Health Checker) to check the buffer pool hit ratio:

• Hit ratio > 95%: Buffer pool is adequate
• Hit ratio 80–95%: Consider increasing buffer pool size
• Hit ratio < 80%: Buffer pool is undersized — significant I/O overhead

Calculating buffer pool size: The ideal buffer pool holds the "working set" — the set of blocks touched by active transactions. For HIDAM databases, the root index and first-level root blocks are hot; allocate enough buffers to keep these permanently cached.

HDAM Randomiser Tuning

For HDAM databases, poor randomiser performance causes clustering — many root segments hashing to the same RAP (Root Anchor Point) location, creating overflow chains that require multiple block reads.

Signs of poor HDAM randomisation:

• Average root retrievals require more than 1.0 block reads
• Long overflow chains in the HDAM RAP area
• IMS statistics showing high GETBLKIO counts relative to root GU calls

Fix: Recalculate the RAP count (RMNAME parameter) and block size to achieve a load factor near 0.7 (70% utilisation) for the randomiser area. This minimises overflow while not wasting space.

Database Reorganisation for Performance

Over time, HIDAM/HDAM databases develop physical fragmentation:

• Deleted segments leave gaps; IMS uses free space pointers but fragmentation builds up
• Inserts to full blocks cause overflow, requiring extra block reads
• Twin pointer chains lengthen as segments insert and delete at non-sequential positions

Signs that reorganisation is needed:

• Average block reads per segment retrieval increasing
• IMS statistics showing increased overflow block reads
• Elapsed time for batch sequential scans increasing

Most sites schedule quarterly reorganisation for moderate-update databases and monthly for high-update databases.

Secondary Index Performance

Secondary indexes dramatically improve retrieval by alternate key but have a high update cost. Every insert, delete, or update of an indexed field requires:

1. Update the primary segment
2. Update (or delete+insert) the corresponding index entry

For high-update databases with multiple secondary indexes, the update overhead can be significant.

Tuning strategy: Remove secondary indexes that are rarely used for retrieval. If an index is used less than 1% of the time, the update overhead exceeds the retrieval benefit. Use IMS statistics to identify which indexes are actually accessed.

PSB and PCB Optimisation

PROCOPT=G vs PROCOPT=A: Programs that only read data should use PROCOPT=G (Get) rather than PROCOPT=A (All). Get-only PCBs avoid IMS hold call processing overhead and reduce lock management cost.

Segment sensitivity: Programs sensitive to only the segments they actually use are faster than programs sensitive to all segments. Fewer sensitive segments means IMS can skip non-sensitive segments during navigation with less overhead.

KEYLEN accuracy: The KEYLEN parameter in the PCB must be at least the actual concatenated key length to the deepest sensitive segment. Oversized KEYLEN wastes memory and slightly increases PCB update time.

IMS Statistics and Monitoring Tools

IMS Statistics (DFSSTATS): Collects buffer pool statistics, call counts by type, and I/O counts. Essential for identifying buffer pool hit ratios and comparing before/after tuning changes.

IBM Health Checker for IMS: Automatically checks common IMS configuration issues — buffer pool sizes, DBRC settings, log archival — and flags recommendations.

IBM IMS Explorer: Graphical tool for analysing IMS databases, ACBs, DBDs, and monitoring data without raw JCL.

SMF Records: z/OS System Management Facilities (SMF) records (type 30 and type 110) capture IMS performance data for long-term trending analysis.

Frequently Asked Questions

Q: What is the single most impactful IMS performance tuning action for most databases? Increasing buffer pool size is usually the single most impactful change. Many production IMS systems have buffer pools sized for the hardware of 10–15 years ago; modern z/OS systems have far more real memory available. Doubling or tripling buffer pool size for hot databases often reduces I/O by 50–80% with no other changes.

Q: How does OSAM compare to VSAM for IMS performance? OSAM (IMS's own access method) generally outperforms VSAM for IMS random access because OSAM's I/O path is shorter — it bypasses some VSAM overhead. For sequential access, the difference is smaller. IMS databases on HDAM/HIDAM should use OSAM by default unless there is a specific reason for VSAM (such as integration with non-IMS utilities that require VSAM).

Q: Can IMS performance be improved by spreading the database across multiple volumes? Yes — distributing HIDAM databases across multiple volumes (or striped DASD) allows parallel I/O for sequential scans. For random access, spreading the data across volumes can reduce I/O contention if multiple programs are accessing different parts of the database simultaneously. Modern IBM DS8000 storage controllers with cache largely eliminate volume-level I/O bottlenecks for hot data.

Part of the IMS Mastery Course — Module 21 of 22.