[mailto:IBM-MAIN@bama.ua.edu] On Behalf
Of Joel C. Ewing
Sent: Wednesday, April 04, 2012 9:13 PM
To: IBM-MAIN@bama.ua.edu
Subject: Re: VSAM help wanted for random reads
On 04/04/2012 10:37 AM, Chip Grantham wrote:
We have an application like this, that is multiple record types in the
same KSDS. We
[mailto:IBM-MAIN@bama.ua.edu] On
Behalf Of Ron Hawkins
Sent: Wednesday, April 04, 2012 12:35 AM
To: IBM-MAIN@bama.ua.edu
Subject: Re: VSAM help wanted for random reads
Frank,
It is terrific that you are getting an improvement with BLSR.
I suspect you are using a vanilla copy
Last time I looked, AIX with upgrade (required for the OP's described
conditions) was a *VERY POOR* performer.
However, with the small proportion of updates later described, this does
not seem like it would have a disproportionate impact.
snip
Create an AIX pointing at the file with the AIX key
/2012 05:34
Subject:
Re: VSAM help wanted for random reads
Sent by:
IBM Mainframe Discussion List IBM-MAIN@bama.ua.edu
Frank,
It is terrific that you are getting an improvement with BLSR.
I suspect you are using a vanilla copy of an example in the BLSR manual
similar to Peter Farley's
: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of
Ron Hawkins
Sent: Wednesday, April 04, 2012 12:35 AM
To: IBM-MAIN@bama.ua.edu
Subject: Re: VSAM help wanted for random reads
Frank,
It is terrific that you are getting an improvement with BLSR.
I suspect you are using
Gould edgould1...@comcast.net
To: IBM-MAIN@bama.ua.edu
Sent: Tuesday, April 3, 2012 6:24 PM
Subject: Re: VSAM help wanted for random reads
Frank,
Thanks for reporting back.
One request is there somehow to paste the results so they match up with the
headers ?
Ed
On Apr 3, 2012, at 6:33 PM
We have an application like this, that is multiple record types in the
same KSDS. We found that if we had a FD for the type '4' records and a FD
for the type '5' records (that is two DDs pointing to the same file), that
each kept a separate sequence set in storage and it ran faster. You might
: Re: VSAM help wanted for random reads
We have an application like this, that is multiple record types in the
same KSDS. We found that if we had a FD for the type '4' records and a
FD
for the type '5' records (that is two DDs pointing to the same file),
that
each kept a separate
x23353 peter.far...@broadridge.com
To: IBM-MAIN@bama.ua.edu
Cc:
Sent: Wednesday, April 4, 2012 7:00 AM
Subject: Re: VSAM help wanted for random reads
Be very cautious using DEFERW with BLSR unless you already have a good backup
of
the KSDS immediately before the program starts. Recovery
On 04/04/2012 10:37 AM, Chip Grantham wrote:
We have an application like this, that is multiple record types in the
same KSDS. We found that if we had a FD for the type '4' records and a FD
for the type '5' records (that is two DDs pointing to the same file), that
each kept a separate sequence
for everyone's help!
Frank
- Original Message -
From: Farley, Peter x23353 peter.far...@broadridge.com
To: IBM-MAIN@bama.ua.edu
Cc:
Sent: Wednesday, April 4, 2012 7:00 AM
Subject: Re: VSAM help wanted for random reads
Be very cautious using DEFERW with BLSR unless you already have
, 2012 1:34 PM
Subject: Re: VSAM help wanted for random reads
Not to suggest YOU should've done this but you can get useful statistics
out of SMF 62 and 64 that would've told you how much write
activity you
had - and a lot else besides.
Cheers, Martin
Martin Packer,
Mainframe
VSAM keeps up with this stuff too. Wouldn't hurt to do a reorg every once
in blue moon too!
In a message dated 4/4/2012 6:12:16 P.M. Central Daylight Time,
martin_pac...@uk.ibm.com writes:
out of SMF 62 and 64 that would've told you how much write activity you
had - and a lot else
At 16:33 -0700 on 04/03/2012, Frank Swarbrick wrote about Re: VSAM
help wanted for random reads:
The idea of putting the record type at the end rather than the
beginning is an interesting idea.Ý Unless there's some way of doing
that without having to change any programs I don't think we'd
Frank,
Try using batch local shared resources (SUBSYS=BLSR) for the file, and specify
at least twice as many index buffers for it as you have levels in the KSDS.
For example:
//MYKSDS DD SUBSYS=(BLSR,'DDNAME=MYKSDS#','RMODE31=ALL',
// 'MSG=I','BUFND=256','BUFNI=10')
Run the 4's then run the 5's. It can't be that simple.
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of
Frank Swarbrick
Sent: Tuesday, April 03, 2012 4:24 PM
To: IBM-MAIN@bama.ua.edu
Subject: VSAM help wanted for random reads
Current
One (of many) possible explanations is that there are more hits on the type 5
and more rewrites. Depending on your VSAM options, a rewrite can be -very-
expensive.
Try a comparison run without the type 4 logic.
Also try BLSR and DISP=OLD. That makes the best use of VSAM buffering.
@bama.ua.edu
Sent: Tuesday, April 3, 2012 3:33 PM
Subject: Re: VSAM help wanted for random reads
Frank,
Try using batch local shared resources (SUBSYS=BLSR) for the file, and specify
at least twice as many index buffers for it as you have levels in the KSDS.
For example:
//MYKSDS DD SUBSYS
Should have mentioned, that is a thought we've considered. And we may end up
doing. Just wanted a better way, if there is one.
Frank
From: Fred Hoffman fhoff...@tad.org
To: IBM-MAIN@bama.ua.edu
Sent: Tuesday, April 3, 2012 3:34 PM
Subject: Re: VSAM help
On 4/3/2012 3:23 PM, Frank Swarbrick wrote:
Current program does the following (in COBOL!).
- Opens KSDS for I-O
- Sequentially processes another file (non-VSAM).
- For each record in the non-VSAM file it attempts a random (keyed) read of
arecord on the KSDS file. The key is, essentially, a
Have you looked at adding BUFNI
and/or BUFND to the JCL DD ?
Do you have any vendor products doing VSAM tuning ? possibly doing buffer
tuning..
Regards,
Doug
Sent from my iPhone
On Apr 3, 2012, at 17:55, Steve Comstock st...@trainersfriend.com wrote:
On 4/3/2012 3:23 PM, Frank Swarbrick
For right now, apply to '4' accounts, save misses to a file, then
close and open for input and process the '5' account and report the
misses.
I assume the input is sorted into ascending order for the fast
results. How about changing the key definition so the account number
is in front and the
Several good ideas given.
My sysprog installed BLSR and I got very good results:
Without BLSR:
-
-TIMINGS
(MINS.)--
-PAGING COUNTS
-STEPNAME
PROCSTEP RC EXCP
CONN
TCB SRB
CLOCK SERV
Frank,
Thanks for reporting back.
One request is there somehow to paste the results so they match up
with the headers ?
Ed
On Apr 3, 2012, at 6:33 PM, Frank Swarbrick wrote:
Several good ideas given.
My sysprog installed BLSR and I got very good results:
Without BLSR:
-
Frank,
It is terrific that you are getting an improvement with BLSR.
I suspect you are using a vanilla copy of an example in the BLSR manual
similar to Peter Farley's example in his post. The problem is these parms do
not get the best performance from BLSR.
The missing value is
25 matches
Mail list logo
