If the record count given is accurate (6.7M) and if the average record
length given (80) is realistic, then on the average a full data CI
should be able to hold around 51 records, a 3390 track around 612
records, and the full data portion fit in as few as 11,062 tracks, which
is 5.6% of the current file size. That means if the file is relatively
stable and will not immediately be hit by another massive set of
updates, reorganizing it might reduce the size, number of data CIs,
number of CAs (and hence number of index CIs) by almost a factor of 20.
This certainly could potentially improve things by reducing the total
number of CIs that might have to be read to get the same number of data
records (only true if there is good locality of reference and sufficient
buffers with random reads), but since IAM had to deal with update
activity as well I suspect this would not explain the large difference
in performance from IAM to VSAM so much as perhaps the default buffering
techniques used by IAM. Now if IAM does some kind of default
reorganization under the covers periodically, or if it uses a totally
different data structure and update strategy that somehow eliminates
partially used physical blocks without formal reorganization, that could
be another matter. If this file was converted to VSAM some time ago and
is never reorganized and somehow the equivalent reorganization was done
under the covers by IAM, that could cause efficiency of the VSAM
replacement compared to IAM to degrade over time.
Another thing that could affect my estimates would be if the 4096 Index
CI size was manually forced rather than allowing VSAM to choose the
Index CI size based on Data CI and key length. If that were the case,
the Index CI could be too small, potentially making a significant
portion of each CA unusable for data; and that rather than just Data CI
fragmentation may be contributing to the excessive size of the file
based on number of records. Another possibility of course is that the
average record length (which is definer-specified and not verified or
calculated by VSAM) may be grossly inaccurate, making my estimates of
average records per CI equally inaccurate.
Joel C. Ewing
On 07/19/2012 10:53 AM, Sambataro, Anthony (NIH/NBS) [E] wrote:
In addition to more buffers, would a re-org help? Any CI/CA splits?
-----Original Message-----
From: Brown, Larry - RD, St. Louis, MO [mailto:larry.bro...@stl.usda.gov]
Sent: Thursday, July 19, 2012 8:22 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Problem Going to VSAM from IAM
Hello, we have a job that was previously using Innovation's IAM file access
method. The file is over 6 million records. The job runs twice yearly and
usually takes an hour or less to complete. The product was removed to save on
SW costs, and the file was converted to VSAM. The programmer did not make any
other changes, and the job now takes over 10 hours to complete. I know the IAM
product is supposed to improve performance, but can't imagine it making the
difference between 1 and 14 hours run time. I'm suspecting there may have been
some JCL changes to blksize, buffers, and things like that required, but the
programmer is unaware of any of those changes he should have made. The job is
only reading the file. Does anybody have any ideas on where to start looking
for other changes that should have been made after converting from IAM to VSAM?
The programmer is reviewing his source code. Our performance support has not
suggested anything. Innovation claims %50-%80 re
duction i
n processing time, so maybe it is just a matter of IAM vs VSAM.(?)
Here are the JCL and VSAM definitions:
//MISC DD DSN=ASLP00.FT.MISC,DISP=SHR,
// AMP='BUFSP=409600,BUFND=181,BUFNI=9'
Cluster: 'ASLP00.FT.MISC' +
multi-volume
Data: 'ASLP00.FT.MISC.DATA' Data Volume:
PEST06 +
Index: 'ASLP00.FT.MISC.INDEX' Index Volume:
PEST06 +
Data Component Information: Current Allocation Options:
Device type: 3390 Load option:
SPEED
Organization: KSDS EXT-ADDR Write
check: NO
KSDS key length: 27 Buffer space:
10752
KSDS key location: 1 Erase on delete:
NO
Average record size: 80 Imbedded index:
NO
Maximum record size: 4084 Replicated index:
NO
Allocated Space: Unit Primary Secondary Reuse option:
YES
Data: CYLINDERS 2000 2000 Share
option: 2-3
Index: CYLINDERS 300 30 Spanned
records: NO
Dataset Date Information: Key ranges present:
NO
CLUSTER - ASLP00.FT.MISC Storage:
PESTBU
Data:
X4GB
Management:
MGTPSF
Owner ID:
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Current Allocations in Tracks: Current Utilization in Tracks:
Allocated space: 240000 Used data space: 198827
( 83 %)
Allocated extents: 2 Used extents:
2 ( 100 %)
Allocation type: UNIQUE Prime records:
6,770,095
KSDS Index Allocation in Tracks: Deleted records:
3134
Allocated space: 4500 Inserted records:
8700
Number of records: 14795 Updated records:
706460
- - - - - - - - - - - Current Reorganization Information - - - - - - - - - - -
Data - Control Area Information: Control Interval Information:
Physical record size: 4096 Size-data: 4096
Index: 2560
Thanks,
Larry Brown
...
.
--
Joel C. Ewing, Bentonville, AR jcew...@acm.org
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
