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. 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
