As far as I can remember (it's been a *long* time since I did this kind of programming), you should not (perhaps cannot?) exceed the NCP number of READ's at the same time using the same DCB. Your code would need to use the NCP value from the opened DCB to control how many READ's you may issue before you need a CHECK.
IIRC there is a default NCP value - perhaps 5? -- that also needs to be considered if no override is present in the JCL or the DCB. As I said, it's been a long time since I went that deep, so please RTFM for yourself. Peter -----Original Message----- From: IBM Mainframe Discussion List <[email protected]> On Behalf Of Joseph Reichman Sent: Monday, March 1, 2021 9:38 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
