Dave, What are you expecting changes to REUSE to change?
You can open a data set with the REUSE attribute as empty, by setting the HURBA to 0. I think that would be the last thing the OP wants to do. Ron -----Original Message----- From: IBM Mainframe Discussion List [mailto:[email protected]] On Behalf Of David Mingee Sent: Sunday, February 4, 2018 9:49 PM To: [email protected] Subject: Re: [IBM-MAIN] VSAM Performance - CPU reduction I agree. Just curious if the file needs to be defined as REUSE or could it be ALTERED to NOREUSE and tested? -----Original Message----- From: IBM Mainframe Discussion List [mailto:[email protected]] On Behalf Of Ron hawkins Sent: Friday, January 26, 2018 6:02 PM To: [email protected] Subject: Re: VSAM Performance - CPU reduction Arun, I think you are very close to having this running as optimally as you can unless you start including the COBOL parsing with Strobe and looking for changes to the program that can improve the access, Thanks for trying the reduction of BUFND from 240 to 2, and sharing the increased IO and CPU usage you observed. I still have a gut feeling that BUFND=240 is excessive, and you are reading Cis into storage that the program never processes. If that is the case, then there may be the potential to reduce CPU by reducing the chain length. I'd like to suggest that you try a binary search or bracket test of sorts to see if there is an optimal value for BUFND that reduces the CPU time. I'd suggest starting with one cylinder or BUFND=30 as a starting point for a binary search. For example, if CPU is reduced at 30, see if it reduces at 15. If it does reduce, try 8 to see if it reduces further. Alternatively, if 30 increases CPU and IO try BUFND=120, then 60, etc, etc, etc. Ron -----Original Message----- From: IBM Mainframe Discussion List [mailto:[email protected]] On Behalf Of Ron hawkins Sent: Thursday, January 25, 2018 2:51 AM To: [email protected] Subject: Re: [IBM-MAIN] VSAM Performance - CPU reduction Clark, it is a 15GB KSDS, with 564,000 Cis, and 32,448,318 records. It is very optimistic to think that after he verified increased IO when reading one CI, it will be more than offset LRU buffer hits when there is bursts of sequential IO walking the buffer pool a cylinder at a time. NSR behavior will not let the random hit that you describe occur outside of one CI in the chain as COBOL only uses one string. The program can read all the other CI's in, but the program only looks at them in sequential mode. In skip (random) it only looks at the CI currently pointed to by the string, and ignores everything else in memory. What sort of buffers were you thinking of? 5GB worth? Ron -----Original Message----- From: IBM Mainframe Discussion List [mailto:[email protected]] On Behalf Of Clark Morris Sent: Wednesday, January 24, 2018 5:46 PM To: [email protected] Subject: Re: [IBM-MAIN] VSAM Performance - CPU reduction [Default] On 24 Jan 2018 09:53:39 -0800, in bit.listserv.ibm-main [email protected] (Ron hawkins) wrote: >Clark, > >It's not that the process is reading a 2nd record in the same CI. That >would result in a buffer hit irrespective of whether it is LSR or NSR. > >The empirical evidence of his test with BUFND=2 reduced from BUFND=240 >is that the program reads more than one CI sequentially for each skip. >That alone makes the file a poor candidate for LSR. The original poster also said that under certain circumstances after reading a record skip sequential on the second file by finding a match, under x conditions another record was retrieved from the same file. Depending on the frequency of this condition occurring and the access pattern LSR might help for that condition. Program caching of hits and misses may be more appropriate depending on circumstance. I had a case in one shop where thousand of read not found conditions occurred for about 12 records. This was a table file and around 20 years ago so the exact details escape me but the point is that much depends on the overall processing. Clark Morris > >Ron > > > >-----Original Message----- >From: IBM Mainframe Discussion List [mailto:[email protected]] >On Behalf Of Clark Morris >Sent: Wednesday, January 24, 2018 4:50 AM >To: [email protected] >Subject: Re: [IBM-MAIN] VSAM Performance - CPU reduction > >[Default] On 23 Jan 2018 17:35:50 -0800, in bit.listserv.ibm-main >[email protected] (Ron hawkins) wrote: > >>Clark, >> >>If you had time to read through this lengthy thread you will find that >>the 2nd file uses skip-sequential access. LSR is usually not an >>appropriate strategy for this access pattern. > >I realize he was using skip sequential. My point was that random >access looks like it could be a better fit for this file than skip >sequential especially since a second record may have to be read after >the first record is found on the second file. > >Clark Morris >> >>The OP has tried reducing BUFND on the second file, and observed a >>reduction in throughput, which verifies the extent to which the >>sequential access is taking advantage of chained Cis. >> >>Ron >> >>-----Original Message----- >>From: IBM Mainframe Discussion List [mailto:[email protected]] >>On Behalf Of Clark Morris >>Sent: Tuesday, January 23, 2018 4:57 PM >>To: [email protected] >>Subject: Re: [IBM-MAIN] VSAM Performance - CPU reduction >> >>[Default] On 5 Jan 2018 16:28:48 -0800, in bit.listserv.ibm-main >>[email protected] (Arun Venkatratnam) wrote: >> >>>Hi All, >>> >>>We are looking to improve the performance of a COBOL program that >>>processes >>2 VSAM files. The first file is the I/P file and every record read >>from the input VSAM file is searched for a matching record in the >>other file and a report is written. The program also applies some >>business rules while comparing each matching record. >>> >>>The I/P file is read sequentially while the other file is read in a >>>skip >>sequential basis. The test files that were used had 32M records each >>while production files have 110M records each. >> >>I assume using random access for the second file was tried with >>adequate buffering for index and data. BLSR or the more current means >>of doing random access buffering should have been used. It may also >>help to save any randomly read record that were read based on >>information in records from the second file based on the match with a >>record from the first file. Knowing access patterns can help in >determining the best solution. >> >>Clark Morris >>> >>>Attached is the strobe report from the execution of the test job. The >>>test >>job takes nearly 7 CPU minutes and was profiled to capture about 1 CPU >>minute of execution time. >>> >>>We are attempting to optimize the VSAM access to these files as it is >>>seen >>to take more than 50% of the CPU consumed by this job. >>> >>>In the 'Attribution of CPU execution time' section, we see that the >>>major >>contributors are the components 'QSAM INIT I/O & EXITS' (Module >>IGZEQBL) and PARTITION COMMUNICATION. >>> >>>Could you please help us understand: >>> >>>1.What these components are >>>2.Why is QSAM access used instead of VSAM I/O access. >>>3.What needs to be done to reduce the CPU consumption by these components. >>> >>>Thank you >>> >>>Arun >>> >>> >>>----------------------------------------------------------------- ---- >>>- >>>- >>>----------------------------------------------------------------- ---- >>>- >>>- >>>-------------------- >>> >>>1Strobe* PERFORMANCE PROFILE PROGRAMA >>01/02/2018 PAGE 42 >>> >> >>>- #ACE ** ATTRIBUTION OF CPU EXECUTION >>TIME ** >>>-.COBLIB IGZCPCO IGZEVIO VSAM INPUT/OUTPUT >> >>> ---------------------------WAS INVOKED BY--------------------- >>-----------------VIA----------------------- CPU TIME % >>> XACTION MODULE SECTION DESCRIPTION MODULE >>SECTION DESCRIPTION SOLO TOTAL >>> >> >>> .LELIB CEEBINIT LE/370 BATCH INIT/TERM >>.32 32 >>> .LELIB CEEBINIT LE/370 BATCH INIT/TERM IGZEQBL >>QSAM INIT I/O & EXITS 1.93 1.93 >>> >> >>> XACTION MODULE SECTION LOCATION LINE SOURCE TEXT MODULE >>SECTION DESCRIPTION >>> >> >>> PROGRAMA PROGRAMA 003522 >>1.30 1.30 >>> >>----- ----- >>> >>3.55 3.55 >>>-.VSAM IDA019L1 VSAM RECORD MANAGEMENT >> >>> ---------------------------WAS INVOKED BY--------------------- >>-----------------VIA----------------------- CPU TIME % >>> XACTION MODULE SECTION DESCRIPTION MODULE >>SECTION DESCRIPTION SOLO TOTAL >>> >> >>> .LELIB CEEBINIT LE/370 BATCH INIT/TERM IGZEQBL >>QSAM INIT I/O & EXITS 1.84 1.84 >>> .LELIB CEEBINIT LE/370 BATCH INIT/TERM IGZEQBL >>CURRMEM QSAM INIT I/O & EXITS 4.34 4.38 >>> .LELIB CEEBINIT LE/370 BATCH INIT/TERM IGZEQBL >>DVFILE QSAM INIT I/O & EXITS .03 .03 >>> .LELIB CEEBINIT LE/370 BATCH INIT/TERM IGZEQBL >>PREVMEM QSAM INIT I/O & EXITS 22.48 22.51 >>> >> >>> XACTION MODULE SECTION LOCATION LINE SOURCE TEXT MODULE >>SECTION DESCRIPTION >>> >> >>> PROGRAMA PROGRAMA 003522 IGZCPCO >>CURRMEM PARTITION COMMUNICATION 4.15 4.19 >>> PROGRAMA PROGRAMA 003522 IGZCPCO >>IGZEVIO VSAM INPUT/OUTPUT .57 .57 >>> PROGRAMA PROGRAMA 003522 IGZCPCO >>PREVMEM PARTITION COMMUNICATION 16.80 16.80 >>> >>----- ----- >>> >> >>> 50.22 50.32 >>> >>>----------------------------------------------------------------- ---- >>>- For IBM-MAIN subscribe / signoff / archive access instructions, >>>send email to [email protected] with the message: INFO >>>IBM-MAIN >> >>------------------------------------------------------------------ ---- >>For IBM-MAIN subscribe / signoff / archive access instructions, send >>email to [email protected] with the message: INFO IBM-MAIN >> >>------------------------------------------------------------------ ---- >>For IBM-MAIN subscribe / signoff / archive access instructions, send >>email to [email protected] with the message: INFO IBM-MAIN > >------------------------------------------------------------------- --- >For IBM-MAIN subscribe / signoff / archive access instructions, send >email to [email protected] with the message: INFO IBM-MAIN > >------------------------------------------------------------------- --- >For IBM-MAIN subscribe / signoff / archive access instructions, send >email to [email protected] with the message: INFO IBM-MAIN -------------------------------------------------------------------- -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN -------------------------------------------------------------------- -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN -------------------------------------------------------------------- -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
