@LISTSERV.UA.EDU] On
Behalf Of David Mingee
Sent: Sunday, February 4, 2018 9:49 PM
To: IBM-MAIN@LISTSERV.UA.EDU
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
@LISTSERV.UA.EDU
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
ubject: 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 w
t: Re: [IBM-MAIN] VSAM Performance - CPU reduction
[Default] On 24 Jan 2018 09:53:39 -0800, in bit.listserv.ibm-main
ronjhawk...@sbcglobal.net (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 irre
-Original Message-
>From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
>Behalf Of Clark Morris
>Sent: Wednesday, January 24, 2018 4:50 AM
>To: IBM-MAIN@LISTSERV.UA.EDU
>Subject: Re: [IBM-MAIN] VSAM Performance - CPU reduction
>
>[Defaul
mailto:IBM-MAIN@LISTSERV.UA.EDU]
>On Behalf Of Clark Morris
>Sent: Tuesday, January 23, 2018 4:57 PM
>To: IBM-MAIN@LISTSERV.UA.EDU
>Subject: Re: [IBM-MAIN] VSAM Performance - CPU reduction
>
>[Default] On 5 Jan 2018 16:28:48 -0800, in bit.listserv.ibm-main
>arun.venkatrat...@cogn
ISTSERV.UA.EDU] On
>Behalf Of Clark Morris
>Sent: Tuesday, January 23, 2018 4:57 PM
>To: IBM-MAIN@LISTSERV.UA.EDU
>Subject: Re: [IBM-MAIN] VSAM Performance - CPU reduction
>
>[Default] On 5 Jan 2018 16:28:48 -0800, in bit.listserv.ibm-main
>arun.venkatrat...@cognizant.com (Arun
] VSAM Performance - CPU reduction
[Default] On 5 Jan 2018 16:28:48 -0800, in bit.listserv.ibm-main
arun.venkatrat...@cognizant.com (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
[Default] On 5 Jan 2018 16:28:48 -0800, in bit.listserv.ibm-main
arun.venkatrat...@cognizant.com (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
Great detective work.
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf
Of Tom Marchant
Sent: Friday, January 19, 2018 7:11 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [IBM-MAIN] VSAM Performance - CPU reduction
On Fri, 19 Jan 2018 14:37
On Fri, 19 Jan 2018 14:37:31 +0100, R.S. wrote:
>IMHO the CISZ was up to 32kB for a veeery long time (since VSAM
>beginning perhaps).
>The most important is one could use any CISZ on any disk geometry,
>including 3380 or 3350, or older.
>Of course PB (Physical Block) could be different, as well as
Sent: Wednesday, January 17, 2018 6:43 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [IBM-MAIN] VSAM Performance - CPU reduction
Arun,
In the IDCAMS listing, I see that the files are defined NONSPANNED. With the
records being variable length, you could have as few as 2 records per ci, since
the
er/en/SSLTBW_2.1.0/com.ibm.zos.v2r1.idad400/d4222.htm
Ron
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf
Of Mike Schwab
Sent: Tuesday, January 16, 2018 3:08 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [IBM-MAIN] VSAM Performance
W dniu 2018-01-19 o 14:27, Ron hawkins pisze:
Clark,
I don't know where it is written up, but it has been this way as long as I
can remember, which is 5 minutes when I go to the shop, and a bit longer for
IDCAMS.
Following example look at the CISZ(32768) versus the physical record size
(16384).
ion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Clark Morris
Sent: Tuesday, January 16, 2018 9:01 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [IBM-MAIN] VSAM Performance - CPU reduction
[Default] On 16 Jan 2018 06:54:52 -0800, in bit.listserv.ibm-main
ronjhawk...@sbcglobal.net (Ron hawkins)
Arun,
In the IDCAMS listing, I see that the files are defined NONSPANNED. With the
records being variable length, you could have as few as 2 records per ci, since
the max is around 11000. if all the records are the minimum of 170, then you
would have around 156 records per ci.
Have you looke
Vignesh
Mainframe Infrastructure
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf
Of Ron hawkins
Sent: 16 January 2018 14:52
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: [EXTERNAL] Re: VSAM Performance - CPU reduction
Arun,
Don't bother, m
https://www.ibm.com/support/knowledgecenter/SSLTBW_2.1.0/com.ibm.zos.v2r1.idad400/ciopt.htm
Physical blocks in a CI is multiple of 512 up to 4096 bytes.
On Tue, Jan 16, 2018 at 11:00 AM, Clark Morris
wrote:
> [Default] On 16 Jan 2018 06:54:52 -0800, in bit.listserv.ibm-main
> ronjhawk...@sbcgloba
Performance - CPU reduction
Tim,
Things changed a couple of decades ago.
VSAM physical block is not always the same as the CISZ.
32K CISZ does not waste any space on the track.
Ron
--
For IBM-MAIN subscribe / signoff / archive
[Default] On 16 Jan 2018 06:54:52 -0800, in bit.listserv.ibm-main
ronjhawk...@sbcglobal.net (Ron hawkins) wrote:
>Tim,
>
>Things changed a couple of decades ago.
>
>VSAM physical block is not always the same as the CISZ.
>
>32K CISZ does not waste any space on the track.
Where is this written u
, January 16, 2018 11:28 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: VSAM Performance - CPU reduction
Arun,
in my recent experiences I've got bif improvement using SMB (System Managed
Buffer).
If I'm not wrong both DS are EXTENDED so you could.
Try coding into the DD "AMP=(&#x
Arun,
in my recent experiences I've got bif improvement using SMB (System Managed
Buffer).
If I'm not wrong both DS are EXTENDED so you could.
Try coding into the DD "AMP=('ACCBIAS=SO')" for the main sequentially read
file and "AMP=('ACCBIAS=DO')" for the second one. At the same time enlarge
the
Tim,
Things changed a couple of decades ago.
VSAM physical block is not always the same as the CISZ.
32K CISZ does not waste any space on the track.
Ron
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send
Arun,
Don't bother, mate. I kind of give up.
People can't help when you keep the kimono shut.
I recommend you engage someone that works with Strobe, or the vendor directly.
Ron
--
For IBM-MAIN subscribe / signoff / archive acc
Unless things have changed, a 26K CI size is better than 32K because two CIs
fit on a track. If I'm understanding this application it:
1. reads everything from the first file
2. for each record in the first file, it attempts to do a random read to find a
match in the second file
3. IF it finds
Hi Ron and all,
I have captured the strobe report for the full run of the job. I will try to
send it to later. In addition to strobe, i snapped the below statistics of the
job from Mainview. The report shows that the EXCP and the SSCH counts are
almost equal. I am of the understanding that if
Ron,
The job was not profiled for its entire run. All 32M records are read from the
1st file and 80% will qualify from the 2nd file. The job was profiled to
capture 4000 samples in an elapsed time of 3 minutes. As I had mentioned in my
initial post, the job takes nearly 7 minutes of CPU. The pr
t; To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: VSAM Performance - CPU reduction
>
> Quote
> Apologies. I missed to mention that depending on a record that matches in the
> 2nd file, there are some random reads that refer back to a previous record as
> per the business logic. Hence, the se
ISTSERV.UA.EDU] On Behalf
Of Chris Hoelscher
Sent: Sunday, January 7, 2018 8:57 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [IBM-MAIN] VSAM Performance - CPU reduction
How 'bout .
Flagging the matches that currently require the random read - and instead pass
those records thru the 2nd
frame Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf
Of Wayne Bickerdike
Sent: Sunday, January 7, 2018 4:18 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [IBM-MAIN] VSAM Performance - CPU reduction
Quote
Apologies. I missed to mention that depending on a record that matches in the
2nd file,
Thanks Ron for the CI calculation, I have sent you the strobe report.
Thanks
Arun
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
, 2018 10:22 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [IBM-MAIN] VSAM Performance - CPU reduction
Ron,
About 80% of the records qualify from the second file. I tried running the job
with BUFND of 2 for the second file. It increased the EXCPs significantly (from
strobe report) on the data
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Gerhard Adam
Sent: Sunday, January 7, 2018 11:04 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [IBM-MAIN] VSAM Performance - CPU reduction
To me it still looks like you don't have enough index buffers. My
c
.
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf
Of Arun Venkatratnam
Sent: Sunday, January 7, 2018 10:22 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [IBM-MAIN] VSAM Performance - CPU reduction
Ron,
About 80% of the records qualify from the
Quote
Apologies. I missed to mention that depending on a record that matches in
the 2nd file, there are some random reads that refer back to a previous
record as per the business logic. Hence, the second file has to be VSAM. We
also see a similar behavior with few other programs that do skip sequen
To me it still looks like you don't have enough index buffers. My calculation
suggests you need at least 137 buffers to keep the index set in memory.
Sent from my iPhone
> On Jan 7, 2018, at 10:21 AM, Arun Venkatratnam
> wrote:
>
> Ron,
>
> About 80% of the records qualify from the second
Ron,
About 80% of the records qualify from the second file. I tried running the job
with BUFND of 2 for the second file. It increased the EXCPs significantly (from
strobe report) on the data records for the 2nd file and the CPU time went over
the other runs and the elapsed time also increased.
A.EDU
Subject: Re: [IBM-MAIN] VSAM Performance - CPU reduction
On Sat, Jan 6, 2018 at 11:32 AM, Arun Venkatratnam
wrote:
> Resp: Reading through the entire file by sequential access took 90 CPU
> seconds while skip-sequential took nearly 230 CPU seconds.
>
Doing the skip sequentia
On Sat, Jan 6, 2018 at 11:32 AM, Arun Venkatratnam
wrote:
> Resp: Reading through the entire file by sequential access took 90 CPU
> seconds while skip-sequential took nearly 230 CPU seconds.
>
Doing the skip sequential (read by key) requires accessing the index
to find the next record. Just sk
1. Have you looked at adding STRNO on the VSAM definition or using RLS to
provide the records to be instorage?
No, STRNO is not provided explicitly in the VSAM file definition.Strobe
apparently shows the number of Strings is 48. RLS is also not used.
2. In your JCL for the job, have you coded B
DATASET-OWNER-(NULL) CREATION2018.005
RELEASE2 EXPIRATION--.000
SMSDATA
STORAGECLASS -SCTEST MANAGEMENTCLASS---M
Subject: Re: VSAM Performance - CPU reduction
>
> Just to be clear. The similar behavior i am referring to is the strobe report
> listing QSAM INIT I/O & EXITS and PARTITION COMMUNICATION as the top CPU
> contributors.
>
> ---
Just to be clear. The similar behavior i am referring to is the strobe report
listing QSAM INIT I/O & EXITS and PARTITION COMMUNICATION as the top CPU
contributors.
--
For IBM-MAIN subscribe / signoff / archive access instructi
Apologies. I missed to mention that depending on a record that matches in the
2nd file, there are some random reads that refer back to a previous record as
per the business logic. Hence, the second file has to be VSAM. We also see a
similar behavior with few other programs that do skip sequentia
Classic two file match. Sort the two and produce the report. Not a good use
of VSAM...
On Sat, Jan 6, 2018 at 2:15 PM, Gerhard Adam wrote:
> Seems a bit round-about.
>
> Why not REPRO them to a sequential file, sort by key, and then produce
> your output.
>
>
>
> Sent from my iPhone
>
> > On Jan
Seems a bit round-about.
Why not REPRO them to a sequential file, sort by key, and then produce your
output.
Sent from my iPhone
> On Jan 5, 2018, at 4:20 PM, Arun Venkatratnam
> wrote:
>
> Hi All,
>
> We are looking to improve the performance of a COBOL program that processes 2
> VSAM f
@LISTSERV.UA.EDU] On Behalf
Of Arun Venkatratnam
Sent: Friday, January 5, 2018 4:20 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: [IBM-MAIN] VSAM Performance - CPU reduction
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
DU] On
> Behalf Of Arun Venkatratnam
> Sent: Friday, January 05, 2018 5:20 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: VSAM Performance - CPU reduction
>
> Hi All,
>
> We are looking to improve the performance of a COBOL program that processes 2
> VSAM files. The first file
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 rul
49 matches
Mail list logo
