Prompted a quick look in manual which reveals "A valid BUFSP
specification generally overrides any BUFND or BUFNI specification", and
then of course the default rules for how buffers are apportioned to
Index and Data from BUFSP space is rarely what you want, as VSAM may not
have enough info at the time buffers are allocated to understand how the
program will really be accessing the file. I knew there was a good
reason I avoided BUFSP.
Joel C. Ewing
On 07/19/2012 01:49 PM, Brown, Larry - RD, St. Louis, MO wrote:
Wow, the programmer dropped the bufsp parm, and his run time actually was
better than before with IAM - under an hour. Again, many thanks to all who
replied. If any of you are ever in St. Louis, let me know, and I'll buy you a
cold adult beverage.
Larry Brown
Rural Development
U.S. Department of Agriculture
4300 Goodfellow Blvd.
St. Louis, MO 63120
Phone: 314.457.4939
-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf
Of O'Brien, David W. (NIH/CIT) [C]
Sent: Thursday, July 19, 2012 7:42 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Problem Going to VSAM from IAM
Larry,
Your dd statement specifies space for 100 data buffers (4096 x 100 =409600) but
you then specify bufnd=181, which is one cyl for a 4096 CI size, plus Bufni=9.
I would lose the bufsp parameter and let VSAM allocate buffers according to the
Bufnd and Bufni parameters.
You might also code Rmode31=buff to allocate the buffers above the line. You
didn't mention whether you were paging during the job execution.
Regards,
Dave O'Brien
-----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
