Interesting. I've wanted to use the SUBSYS parm, but never had cause. However we must not have BLSR installed: IEFC746I SUBSYSTEM BLSR DOES NOT EXIST I'll look further into it. Thanks, Frank
>________________________________ > From: "Farley, Peter x23353" <peter.far...@broadridge.com> >To: IBM-MAIN@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=(BLSR,'DDNAME=MYKSDS#','RMODE31=ALL', >// 'MSG=I','BUFND=256','BUFNI=10') >//MYKSDS# DD DSN=HLQ.MY.KSDS,DISP=SHR > >Where HLQ.MY.KSDS has 3 index levels. The BUFND counts data CI's that can be >resident at the same time, adjust to suit your needs. The BUFNI is for index >buffers (again CI's). Don't forget to increase REGION to account for the >additional buffers in memory. > >Or you might try the new-fangled way, using SMB (system managed buffering). I >haven't yet found that to be more helpful to performance than BLSR, but it >might be worth your while to investigate it. See the JCL Reference manual for >the parameters to use. > >HTH > >Peter > >-----Original Message----- >From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of >Frank Swarbrick >Sent: Tuesday, April 03, 2012 5:24 PM >To: IBM-MAIN@bama.ua.edu >Subject: VSAM help wanted for random reads > >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 a >record on the KSDS file. The key is, essentially, a concatenation of a record >type code ('4' or '5') and an account number. If no record of type '4' is >found then it tries again for the same account, but with record type '5'. If >either the '4' or '5' type is found it updates it and rewrites the record >(assuming the data changed). > >This takes about 16 minutes to run. However if the 'type 5' logic is removed, >so that it only ever looks for type '4' records, it takes only about one >minute. > >Our resident VSAM expert says it has something to do with the VSAM "sequence >set" and the fact that only one is kept in memory at a time. Since the same >sequence set doesn't appear to be able to be used for both the 'type 4' >records and the 'type 5' records it's constantly going back and forth, loading >the "other" sequence set from disk. He says on VSE (which we were up until >May 2010) more than one sequence set can be in memory, but with MVS this >appears to not be the case. > > >Hopefully that reason is accurate. Is there a solution? We thought about >having two COBOL FDs pointing to two DDs, where both DDs pointed to the same >KSDS. This would probably(?) work, except for the fact of the update. > >Thanks, >Frank > > >---------------------------------------------------------------------- >For IBM-MAIN subscribe / signoff / archive access instructions, >send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN > >This message and any attachments are intended only for the use of the >addressee and may contain information that is privileged and confidential. If >the reader of the message is not the intended recipient or an authorized >representative of the intended recipient, you are hereby notified that any >dissemination of this communication is strictly prohibited. If you have >received this communication in error, please notify us immediately by e-mail >and delete the message and any attachments from your system. > >---------------------------------------------------------------------- >For IBM-MAIN subscribe / signoff / archive access instructions, >send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN > > > ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
