From original post, the job in question "is only reading the file".
Any updates are done elsewhere, which at this point haven't yet been
described as a performance issue. BLSR Deferred writes could be useful
in other cases (not here) when a large number of updates are being done
in a batch job, but also generally requires knowledge that others don't
need access to the file during this process.
Joel C. Ewing
On 07/19/2012 10:45 AM, Yifat Oren wrote:
Hi,
Like others have suggested BLSR or SMB ACCBIAS=DO is the way to go if the
VSAM is accessed in a non-sequential manner (which seems to be the case,
giving the IAM vs. VSAM performance difference you've encountered).
Also, from the "LISTCAT", if I read it correctly, many records seem to be
updated so a DEFER WRITE (DFR) should be considered (and may or may not be
enabled by default).
Take a look at
http://publib.boulder.ibm.com/infocenter/zos/v1r12/index.jsp?topic=%2Fcom.ib
m.zos.r12.idad400%2Fsmbt.htm.
Best Regards,
Yifat
-----Original Message-----
From: IBM Mainframe Discussion List [mailto:[email protected]] On
Behalf Of Brown, Larry - RD, St. Louis, MO
Sent: Thursday, July 19, 2012 3:22 PM
To: [email protected]
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 reduction in 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 [email protected]
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
