[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
