Michael, Reading the JCL manual, it almost seems to me like ACCBIAS=DO is calling BLSR under the covers. If I specify DO, I can also specify a SMBDFR which defers writes until the dataset gets closed or the buffers are needed.
If doing DEFERW, what happens if the job abends. Does the VSAM get closed thereby flushing the buffers or do the changes simply disappear? Long ago when disks were slow (think 3380s behind non-cached controllers) I used BLSR with DEFERW in a specific situation to shave 85-90% off wall clock and I/O counts for a VSAM update job. BLSR by itself was responsible for about half the savings but DEFERW did the rest. Rex -----Original Message----- From: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> On Behalf Of Michael Oujesky Sent: Monday, May 16, 2022 3:30 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: [EXTERNAL] Re: IBM BLSR subsystem AMP will be fine for setting BUFNI or BUFMD, but won't tell VSAM to look-aside the data buffers. So, without a program product, either the program needs to establish a LSR pool or use BLSR via JCL to get look-aside. I would urge caution in using deferred writes. Just be sure you understand the implications to your application from lost updates due to a failure. I have used deferred writes where I have a temporary VSAM used to hold large arrays where the array is initially empty and all records deleted before closing the VSAM file. Michael At 02:51 PM 5/16/2022, Pommier, Rex wrote: >Thanks, all responders. > >Michael, so I'm not stuck in the mid '90s, just the BLSR documentation >is. :-) "First Edition, June 1994" > >I have seen the references to BLSR in other documents, like a crypto >manual and some SMP/E references to it, but until I found the 1994 >document, I couldn't find anything that actually explained it. That's >where I was getting confused. I'll also need to check the AMP parm to >see if that does the same thing. The DEFERW=YES option looks >interesting (again). > >Rex > >-----Original Message----- >From: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> On >Behalf Of Michael Oujesky >Sent: Monday, May 16, 2022 2:23 PM >To: IBM-MAIN@LISTSERV.UA.EDU >Subject: [EXTERNAL] Re: IBM BLSR subsystem > >PDF - >https://urldefense.com/v3/__http://publibz.boulder.ibm.com/epubs/pdf/ie >a5j600.pdf__;!!KjMRP1Ixj6eLE0Fj!qkxYWCkBfDGHDC7oenAm5D9KqrxkJrY3t_3JVFd >CVrbQCkmMcgu-pyPE7GDVRGTH5pXjbNntD-my9ikgUcff1KGO$ > > >BLSR will help principally if the access is random and the locality of >reference of the data component is good. Otherwise, just increasing >the BUFNI and/or BUFND will suffice. Note that for sequential access a >BUFND of twice the CIs per CA plus two and just a few BUFNI five or so) >usually provides about the best you can get (incudes over-lapping read >I/O to the data component). > >I still see BLSR in the 2.5 IEFSSN00 member. > >Michael > >At 09:36 AM 5/16/2022, Pommier, Rex wrote: > >Hi list, > > > >Is the BLSR subsystem (batch local shared resources) still a > >viable/valuable thing or has it been replaced by something > >bigger/better/faster? I seem to be stuck in the mid-90s because the > >most current documentation I can find on it is from MVS/ESA 5.1 dated > >1994. Is there more current documentation on how to use it and how > >it works? Has it been replaced and deprecated? I just had a > >developer use it last week and experienced a 40+ reduction in I/Os > >but I wanted to read up on its limitations - especially around using > >it on a shared VSAM dataset. However I can't find anything newer > >than 25+ years old. I did multiple internet searches which is > >where I found the ESA manual. I checked the knowledge center and my > >own z/OS 2.2 and 2.4 collections all to no avail. > > > >Thanks, > > > >Rex > >---------------------------------------------------------------------- >For IBM-MAIN subscribe / signoff / archive access instructions, send >email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > >---------------------------------------------------------------------- >The information contained in this message is confidential, protected >from disclosure and may be legally privileged. If the reader of this >message is not the intended recipient or an employee or agent >responsible for delivering this message to the intended recipient, you >are hereby notified that any disclosure, distribution, copying, or any >action taken or action omitted in reliance on it, is strictly >prohibited and may be unlawful. If you have received this communication >in error, please notify us immediately by replying to this message and >destroy the material in its entirety, whether in electronic or hard >copy format. Thank you. > >---------------------------------------------------------------------- >For IBM-MAIN subscribe / signoff / archive access instructions, send >email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN ---------------------------------------------------------------------- The information contained in this message is confidential, protected from disclosure and may be legally privileged. If the reader of this message is not the intended recipient or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any disclosure, distribution, copying, or any action taken or action omitted in reliance on it, is strictly prohibited and may be unlawful. If you have received this communication in error, please notify us immediately by replying to this message and destroy the material in its entirety, whether in electronic or hard copy format. Thank you. ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
