IBM Bob can uncover access patterns and support new mainframer learning. Here’s why every tuning recommendation still needs a reality check.
No, this is not the thousandth article about how IBM Bob can convert code from one language to another. What interests me much more is how Bob can support programmers and systems programmers in their day-to-day work and, above all, help them work more effectively.
A good example is a problem almost as old as many mainframe applications themselves: a file is slow, the programs have been running for years, nothing significant appears to have changed in the business logic, and yet access times are no longer where they should be.
That is usually when the traditional search for the root cause begins. You look at dataset definitions, programs, buffering, I/O behavior, CICS statistics, and try to determine where performance is being lost.
Slow Master File Example
In one real customer case, the issue involved a central customer master file. Direct access times had been noticeably high for quite some time. The problem was not limited to CICS. Several batch programs showed the same behavior. That made one thing clear fairly quickly: focusing only on the CICS configuration or on a single access routine would have been too narrow.
This is where Bob may help most: before the tuning begins, by showing how the application actually uses the file.
The customer master file was defined as a classic KSDS:
DEFINE CLUSTER - (NAME(HLQ.KUNDENSTAMM.KSDS) - INDEXED - KEYS(5 0) - RECORDSIZE(475 475) - FREESPACE(20 10) - SHAREOPTIONS(2 3) - VOLUMES(SYSDA) - CYL(5 2) - ) - DATA - (NAME(HLQ.KUNDENSTAMM.KSDS.DATA) - CISZ(4096) - ) - INDEX - (NAME(HLQ.KUNDENSTAMM.KSDS.INDEX) - CISZ(4096) - )
At first glance, there is nothing dramatically wrong with this definition. A 4 KB data control interval is not unusual for a KSDS with direct access, the key is relatively short at five bytes, and the share options do not immediately stand out as problematic.
Cases like this are often the more interesting ones in practice. There is no single parameter you can point to and say, “That is the cause.”
Understand the Access Pattern
This is where IBM Bob was brought into the analysis. Bob was not given only the VSAM definition. The CICS access routine and the relevant batch programs were analyzed as well.
That changes the question completely.
LISTCAT can tell us what the KSDS looks like today. CICS Statistics can show how often records are read, how effective buffer lookasides are, or whether buffer and string waits occur. RMF and other performance tools can show what the I/O is costing.
What those tools cannot answer on their own is perhaps the most important question:
Why is the application accessing the file this way in the first place?
A Different Approach with Bob
This is where Bob can open a different approach.
The analysis can, for example, show which programs access the customer master file, where individual READs occur inside large processing loops, whether the same record is fetched multiple times, how new customer keys are generated, and whether consecutive accesses tend to target similar or neighboring key values.
That matters for performance optimization because even a perfectly defined VSAM cluster can only do so much to compensate for an inefficient access pattern.
This customer case illustrates that point. Bob can help explain how the application actually uses the file. Traditional tools can then show what that behavior costs at runtime. The mainframe specialist connects both sides and decides which technical change actually makes sense.
Bob’s Proposed VSAM Changes
After analyzing the programs, Bob suggested the following revised definition:
DEFINE CLUSTER -
(NAME(HLQ.KUNDENSTAMM.KSDS) -
INDEXED -
KEYS(5 0) -
RECORDSIZE(475 475) -
FREESPACE(10 5) -
SHAREOPTIONS(2 3) -
VOLUMES(SYSDA) -
CYL(5 2) -
) -
DATA -
(NAME(HLQ.KUNDENSTAMM.KSDS.DATA) -
CISZ(8192) -
BUFFERSPACE(28672) -
) -
INDEX -
(NAME(HLQ.KUNDENSTAMM.KSDS.INDEX) -
CISZ(2048) -
)
Bob changed several tuning parameters at once. Freespace was reduced, the data control interval was increased, the index control interval was reduced, and additional buffer space was added.
Examine the Reasoning
The general direction was interesting. Some of the reasoning, however, needed a closer technical review. And that is an important part of this example.
Freespace: a very reasonable question to ask. Bob’s first proposal was to reduce:
FREESPACE(20 10) -
to
FREESPACE(10 5) -
That is fundamentally plausible.
The customer master file contains fixed-length records of 475 bytes. A REWRITE therefore does not suddenly make an existing record larger and require additional room inside the control interval. In this case, freespace is primarily relevant for newly inserted records.
That makes one question critical: How are new customers added?
If customer numbers are assigned sequentially and new records are therefore inserted mainly at the end of the file, a large amount of freespace distributed across the entire KSDS may be unnecessary.
If new keys are regularly inserted between existing customer numbers, that free space can be valuable because it helps reduce CI and CA splits. The scale of the difference is worth looking at.
As an illustrative estimate, a 4 KB CI with 20 percent freespace provides approximately:
4096 bytes
- approx. 10 bytes VSAM control information
- 819 bytes FREESPACE
--------------------------------
approx. 3267 bytes
With a fixed record length of 475 bytes:
3267 / 475 ≈ 6.87
On these approximate assumptions, that means roughly six complete records per CI during the initial load. If freespace is reduced to 10% while keeping the same CI size, the calculation changes:
4096 bytes - approx. 10 bytes VSAM control information - 409 bytes FREESPACE -------------------------------- approx. 3677 bytes
That gives us:
3677 / 475 ≈ 7.74
So roughly seven complete records per CI can be stored under the same assumptions. Actual capacity depends on VSAM overhead and the file’s characteristics.
That may sound like a small difference, but across a large customer master file it can translate into noticeably higher data density. Fewer required control intervals can in turn affect the overall file size and, indirectly, the index structure.
The decisive question is still not whether 10% is better than 20%. The real question is: How are new customer records actually inserted?
And that information lives in application logic, not in the IDCAMS definition.
Data CISIZE: Test the I/O Assumption
Bob’s proposal to increase the data CI from 4 KB to 8 KB deserves more scrutiny.
The reasoning was essentially that a 475-byte record size allows significantly more records to fit into a single control interval, which would therefore reduce I/O by roughly half.
That sounds convincing at first. On closer inspection, however, it does not hold up. Even the arithmetic is too optimistic because the proposed definition still reserves 10% freespace.
With an 8 KB CI, the calculation looks approximately like this:
8192 bytes
- approx. 10 bytes VSAM control information
- 819 bytes FREESPACE
--------------------------------
approx. 7363 bytes
With 475 bytes per record:
7363 / 475 ≈ 15.5
So during the initial load, roughly 15 complete records fit into the CI, not 17.
The more important issue, however, is not the arithmetic. With true random direct access, a larger CI does not automatically mean fewer I/Os.
If an application reads customer 47117, VSAM has to retrieve the control interval containing that record. If the next access is customer 93582 and that record is located in a different CI, another control interval must be retrieved.
Whether the first CI contains six, eight, or 15 other customers does not matter if none of those records are needed next. The number of records per CI therefore cannot simply be translated into a proportional reduction in I/O.
The statement “twice as many records per CI means roughly half as many I/Os” is too broad for random direct access.
Don't miss these other great articles
Why the 8 KB proposal Is Interesting
That does not automatically make Bob’s recommendation wrong. Suppose the program analysis shows that the accesses are technically individual direct reads, but that the keys are often close to one another.
For example:
READ customer 47110
READ customer 47112
READ customer 47117
READ customer 47119
Now the assessment changes.
If the first access brings a larger 8 KB CI into a buffer and several of the subsequent customer records happen to be in the same control interval, those reads may be satisfied from the buffer. That can reduce physical I/O.
But the professional justification is no longer: “More records per CI means less I/O.”
It becomes: The actual access pattern shows a high degree of key or data locality. A larger data CI may therefore increase the probability that subsequent reads can be satisfied from a control interval that is already resident in memory.
That is a more defensible statement. And this is exactly where the combination of Bob and traditional performance analysis becomes interesting.
Bob can analyze the programs and determine whether this kind of access locality exists in the first place. CICS Statistics or other runtime data can then show whether the change actually improves lookaside rates and reduces physical reads.
Index CISIZE and Buffering Matter
Bob also proposed reducing the index CI from 4 KB to 2 KB.
With a key length of only five bytes, that sounds reasonable at first. A smaller index CI can be more compact and consume less buffer space. But again, it would be too simplistic to turn that into a general rule that “smaller is faster.”
For a KSDS with frequent direct access, the more important questions are how the index is actually structured, how many index levels exist, how large the index set is, and how much of it can remain buffered.
With direct access, VSAM has to resolve the relevant index path before retrieving the data record. If the important high-level index CIs remain resident, physical index I/Os can be avoided.
That leads to another important tuning question: Does a larger data CI really give us more benefit than better index buffering?
For truly random reads, that would be one of the first questions I would ask.
Once again, this shows why VSAM performance cannot be optimized by focusing on a single parameter. Data CISIZE, index CISIZE, buffering, and the actual access pattern must be considered together.
BUFFERSPACE(28672) — good direction, overly simple explanation.
Bob also proposed:
BUFFERSPACE(28672)
The apparent calculation behind that value was:
3 × 8192 bytes DATA
+
2 × 2048 bytes INDEX
=
28672 bytes
Mathematically, that is correct. Technically, however, BUFFERSPACE does not simply mean that VSAM will now use exactly three data buffers and two index buffers.
BUFFERSPACE defines the amount of buffer space that is available or required. How VSAM uses additional memory depends, among other things, on the access method.
For direct access, additional index buffers are particularly important. For sequential processing, additional data buffers tend to matter more.
Under CICS, the picture becomes even more complex when LSR is involved because buffers and strings are managed in shared pools. In that environment, the buffer configuration is not determined solely by the BUFFERSPACE value in the cluster definition.
So Bob identified a relevant tuning area, but the actual implementation still has to be based on the real batch and CICS environment.
What Bob Did Not Change
It’s also worth looking at what Bob did not change. An interesting point is the allocation:
CYL(5 2)
Bob left it unchanged.
For a customer master file that may have existed and grown for many years, I would want additional information before accepting that as irrelevant.
- How large is the file today?
- How many extents does it have?
- How often has it been extended?
- How many CI and CA splits have occurred?
- How many index levels exist now?
- What does actual space utilization look like?
With long-lived VSAM files, the current physical structure can evolve significantly from what was originally envisioned when the DEFINE was written. Program code alone cannot tell us that.
This reveals an important limitation of Bob without making it a weakness of the overall approach: Bob can only analyze the context it is given.
Source code explains the application. LISTCAT describes the file. CICS Statistics show runtime behavior. RMF and other performance tools show the actual cost. Only together do they provide a complete picture.
Professional Optimization Process
A sensible process could therefore look like this.
First, Bob analyzes the application and determines which programs access the file, how they access it, and which patterns can be identified. This can already reveal redundant reads, inefficient loops, repeated access to the same records, or clear key locality.
Those findings become hypotheses. Perhaps freespace is too generous. Perhaps a larger data CI makes sense. Perhaps the index CI is unnecessarily large. Perhaps the buffering strategy does not fit the actual access pattern.
Then add the deterministic facts.
- LISTCAT shows splits, index structure, extents, and current file size.
- CICS Statistics show reads, lookasides, buffer waits, and string waits.
- Batch statistics show I/O counts and elapsed time.
Only then should anything be changed. And preferably not everything at once.
If freespace, data CISIZE, index CISIZE, and buffering are changed in a single step, performance may improve, but you still will not know which change actually caused the improvement.
A clean test could look like this:
| Variant | DATA CISIZE | INDEX CISIZE | FREESPACE | Buffering |
|---|---|---|---|---|
| Baseline | 4096 | 4096 | 20/10 | Existing |
| Variant 1 | 4096 | 4096 | 10/5 | Existing |
| Variant 2 | 8192 | 2048 | 10/5 | Existing |
| Variant 3 | 4096 | Appropriate/automatic | 10/5 | Optimized for direct access |
| Variant 4 | Based on measurements | Based on measurements | Appropriate | Targeting tuning |
For batch processing, I would not look only at elapsed time. Physical I/O counts, CPU consumption, data reads, and index reads also matter.
Under CICS, I would additionally focus on data lookasides, index lookasides, buffer waits, and string waits.
Only when those measurements improve has a tuning hypothesis become a real optimization.
Where Bob Saves Time
In many performance investigations, changing a parameter is not the time-consuming part. Understanding the relationships is.
- Which batch program accesses which file?
- Which CICS routine uses the same data?
- How is the key generated?
- Which READs occur inside large loops?
- Are there redundant accesses?
- Are records fetched again even though the data is already available in the processing context?
- Is there a pattern that would be better suited to START and READ NEXT than to a long series of individual direct reads?
An experienced mainframe specialist can answer those questions. But doing so often means working through large amounts of code, JCL, and technical definitions. Bob can accelerate a significant part of that preparatory work.
That shifts the specialist’s role away from pure information gathering and toward technical evaluation. That’s where I see the real productivity gain. This becomes especially valuable for new team members.
How It All Fits Together
The same approach has another effect that should not be underestimated in mainframe environments.
For an experienced systems programmer, the relationship between CISIZE, freespace, index levels, buffering, lookaside behavior, and access patterns is often second nature.
For someone new to the platform, those are initially just separate terms. The hard part is understanding how they fit together. A case like this therefore becomes an excellent onboarding scenario.
Bob can first make visible which programs are involved and how the customer master file is actually used. An experienced colleague can then explain why some recommendations are plausible, why others need to be challenged, and why a mathematically convincing statement is not automatically a reliable performance prediction.
Performance optimization is always a combination of application behavior, system behavior, and measurement.
That turns a real performance problem into a learning environment. A new team member does not simply learn that FREESPACE(10 5) might be better. They learn why freespace exists, when it is useful, and when it simply consumes space.
They do not simply learn that an 8 KB CI is larger. They learn why a larger CI may help with sequential or locally clustered access patterns, but may provide no automatic advantage at all for truly random reads.
Most importantly, they learn that performance optimization is always a combination of application behavior, system behavior, and measurement. It is difficult to teach that more effectively than through a real problem.
Test Bob’s Recommendations
This customer case illustrates how generative AI can support mainframe work: Bob analyzes code, identifies relationships, and generates hypotheses.
Those proposals still require a technical review and measured tests. Then the traditional tools come into play.
- LISTCAT answers: What does the file actually look like?
- CICS Statistics and other runtime data answer: What does this access pattern actually cost?
- Bob can help answer: Why is the application accessing the file this way in the first place?
And the mainframe specialist ultimately answers the most important question: Which change actually makes technical sense?
This is a practical use of AI on the mainframe: less time searching for relationships, more time evaluating what the evidence supports. It can also help new team members see how application logic, VSAM structure, and runtime behavior fit together.
AI Bob in Sum
IBM Bob does not replace LISTCAT, CICS Statistics, RMF, or an experienced systems programmer. It can, however, help show why an application accesses a file the way it does. The human specialist must still decide what to change, and measure whether it worked.
Up Next
If you made it this far, there’s plenty more AI on Planet Mainframe!
0 Comments