It's incredible how much CPU (and clock time) can be expended if access
to file is doing "unnecessary" IO operations. One would hope these
days there aren't still any large, poor-blocksize sequential files
around, but if default buffering is used on such a file this can cost a
lot of Operating System resources to initiate many reads per logical
track even if emulated DASD is caching tracks to minimize physical reads
to some media
VSAM file performance can vary even more widely because the number of
blocks read can literally vary by three or more orders of magnitude
depending on access pattern and buffer tuning. A badly tuned, random
accessed VSAM file may be required to re-read multiple Index CI blocks
and a Data CI block for each record accessed. This can result in
millions of Index block reads, even if there are only a 100 Index
CIs. I have seen cases where proper tuning of a high-usage VSAM with
better buffering or BLSR cut the clock run time and CPU usage of a batch
job by a factor of 10 or more.
So, yes, this makes sense. An older shop that hasn't taken the time to
revisit old job streams and tune file access that was designed decades
ago when real memory was constrained and expensive should definitely
re-tune. It may now be practical to buffer all Index CI's in memory,
or in some cases it even makes sense to change a heavily used VSAM file
to a in-memory data structure.
JC Ewing
On 1/19/25 9:06 AM, Robert Prins wrote:
From LinkedIn:
<quote>
2 weeks ago I received the analysis data from a new client that wanted to
reduce their CPU consumption and improve their performance. They sent me
the statistical data from their z16 10 LPARS. Information about 89,000+
files. I analyzed their data and found 2,000+ files *that could be improved*
and would save CPU when improved. *I pulled out 1 file to demonstrate a
Proof of Concept (POC) for the client. I had the client run the POC and it
showed a 29% reduction in CPU every time that file will be used. The 29%
did not include 3 other major adjustments that would save an addition 14%
CPU and cut the I/O by 75%.* This is just 1 file. The other files can save
3% to 52% of their CPU every time they are used in BATCH or ONLINE.
</quote>
I've been a programmer on IBM since 1985, and the above doesn't make any
sense to me, how can changing just one file result in a 43% reduction in
CPU usage?
I've only ever been using PL/I, and using that I did manage to make some
improvements to code, including reducing the CPU usage of a CRC routine by
an even larger amount, 99.7% (Yes, ninety-nine-point-seven percent), but
that was because the old V2.3.0 PL/I Optimizing compiler was absolute shite
at handling unaligned bit-strings, but WTH can you change about a file to
get the above reduction in CPU?
Robert
--
Joel C Ewing
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
