That’s the way I’m doing it Thanks
> On Mar 2, 2021, at 11:36 AM, Seymour J Metz <[email protected]> wrote: > > For best performance, NCP should match the number of DECBs you allocate and > you should do a READ on each of them. If real storage is an issue, reduce > that number appropriately. When you hit EOF (EODAD is entered), stop issuing > READ. > > > -- > Shmuel (Seymour J.) Metz > http://mason.gmu.edu/~smetz3 > > ________________________________________ > From: IBM Mainframe Discussion List [[email protected]] on behalf of > Joseph Reichman [[email protected]] > Sent: Monday, March 1, 2021 9:37 PM > To: [email protected] > Subject: Re: Large block interface for VB > > For NCP do you have to have a counter of the number of reads you do till you > do a check > > >> On Mar 1, 2021, at 7:34 PM, Joseph Reichman <[email protected]> wrote: >> >> Thanks I’ll look Into it >> >>>> On Mar 1, 2021, at 7:16 PM, Farley, Peter x23353 >>>> <[email protected]> wrote: >>> >>> Joseph, >>> >>> Apologies, I mis-remembered what SMB can do. SMB is available only for >>> VSAM files, not for concatenated QSAM files. BLSR is one of two options >>> for many-buffered QSAM input. >>> >>> The other option is to use the regular DD parameters NCP=nn,BUFNO=nn (max >>> of 99 for each one) that may or may not help with I/.O performance. I have >>> run some work with NCP=99,BUFNO=99 with some helpful effects, though not >>> dramatic. >>> >>> To really take advantage of NCP/BUFNO you probably would need to code to >>> juggle "NCP" different READ's at a time using BSAM and your own de-blocking >>> subroutine. Lots of bookkeeping to keep track of them all and only CHECK >>> in the correct order. Robust recovery from I/O errors in such code is also >>> a thorny problem. Solvable, but thorny. >>> >>> Peter >>> >>> -----Original Message----- >>> From: IBM Mainframe Discussion List <[email protected]> On Behalf Of >>> Farley, Peter x23353 >>> Sent: Monday, March 1, 2021 1:43 PM >>> To: [email protected] >>> Subject: Re: Large block interface for VB >>> >>> EXTERNAL EMAIL >>> >>> You assume correctly, it does. In my experience both BLSR and SMB will >>> handle concatenations of any size without any issue. >>> >>> When using BLSR your primary DD (the one your program reads) is coded with >>> he BLSR parameters and nothing else, that DD then points (via a BLSR >>> parameter) to a second DD where you put your large concatenation. >>> >>> SMB is applied directly to your primary DD name, specify the SMB parameters >>> on only the first of the concatenated DD's. >>> >>> Peter >>> >>> -----Original Message----- >>> From: IBM Mainframe Discussion List <[email protected]> On Behalf Of >>> Joseph Reichman >>> Sent: Monday, March 1, 2021 1:36 PM >>> To: [email protected] >>> Subject: Re: Large block interface for VB >>> >>> Thank you I’m doing searches for files so I have over 100 concatenated >>> files does the access matters I mean I assume QSAM reads a block under the >>> covers >>> >>> >>> >>>>> On Mar 1, 2021, at 1:26 PM, Farley, Peter x23353 >>>>> <[email protected]> wrote: >>>> >>>> Joseph, >>>> >>>> I believe that LBI is only for tape inputs and outputs. You can speed up >>>> your processing easier by using either the older BLSR buffering subsystem >>>> or better the newer SMB buffering system. See the JCL reference manual >>>> for SMB parameters. >>>> >>>> Allocate as much REGION as your installation will allow (some >>>> installations limit the maximum any job without special authorization may >>>> use, even sometimes production jobs). >>>> >>>> Use BLSR or SMB to allocate as many buffers as will fit in the REGION size >>>> you can allocate. >>>> >>>> I have seen substantial decreases in run time using these techniques with >>>> very large sequential files. >>>> >>>> I would also recommend using at least software compression or better >>>> hardware compression (if your CPU has it) for your large sequential files. >>>> The CPU time used for compression and decompression will sometimes be >>>> offset by decreases in elapsed time due to reduced I/O burdens for the >>>> compressed data, especially if you have hardware compression available. >>>> >>>> HTH >>>> >>>> Peter >>>> >>>> -----Original Message----- >>>> From: IBM Mainframe Discussion List <[email protected]> On >>>> Behalf Of Joseph Reichman >>>> Sent: Monday, March 1, 2021 1:14 PM >>>> To: [email protected] >>>> Subject: Re: Large block interface for VB >>>> >>>> Who uses tape >>>> >>>> I went to bsam trying to speed up my application wonder if going to >>>> bsam >>>> >>>> Does anything positive for me >>>> >>>>>>> On Mar 1, 2021, at 1:10 PM, Paul Gilmartin >>>>>>> <[email protected]> wrote: >>>>>>> >>>>>>> On Mon, 1 Mar 2021 11:24:57 -0500, Joseph Reichman wrote: >>>>>>> >>>>>>> It disk then documentation says the system only supports tape at this >>>>>>> time is That true ? >>>>>>> >>>>> Have you any reason to doubt it? >>>>> >>>>> I suspect it's a hardware limitation. >>>>> >>>>>>>> On Mar 1, 2021, at 11:22 AM, Paul Gilmartin wrote: >>>>>>> >>>>>>> On Mon, 1 Mar 2021 09:12:59 -0500, Joseph Reichman wrote: >>>>>>> >>>>>>>> I have 100 files concatenated that are normally processed by qsam >>>>>>>> with a lrecl 31996 and blksize 32000 >>>>>>>> >>>>>>>> Since processing takes a long time I was looking to speed things >>>>>>>> up by specifying a blksize of 320000 in the DCBE >>>>>>>> >>>>>>> What device type? >>>>>>> >>>>>>>> After the first read using bsam read macro I looked at the first 4 >>>>>>>> bytes ( Block descriptor word ) and it was x’7C4A’ which is 31,888 >>>>>>>> which seemed to me that it was still processing blksize of 32,000 >>>>> >>>>> -- gil >>>>> >>> -- >>> >>> 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 [email protected] 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 [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
