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
