Building upon Mark and Peter's replies... Having retired in 2005, I can’t be absolutely certain, but it is highly likely that it is still supported, as I am finding reference to Batch LSR when searching z/OS 2.5 manuals.
If you have MXG in your shop, potential candidates for batch LSR can be found by running the ANALBLSR program, referring to the documentation in member ADOCBLSR. In effect, this will find candidate jobs where the VSAM access is random instead of sequential. You do not want to use LSR when the VSAM file is accessed sequentially. To some extent, it can be argued that Batch LSR has been superseded by facilities within DFSMS. System Managed Buffering(SMB) will implement LSR if all the DFSMS constructs are in place and Direct Optimized has been chosen: https://www.lascon.co.uk/VSAM-System-Buffers.php For the non-DFSMS case, there are also 3rd party software products that can be used to alter batch programs to use LSR instead of the default NSR mode. I was in a shop that used the Data Optimizer component of the BMC Mainview Batch Optimizer for that purpose. Going this route was simpler than modifying a large number of catalogued procedures. Note that in the rare case that you are using LSR, rather than the more modern RLS, within CICS that you can choose specific buffer sizes for the index and data buffer pools using Resource Definition Online. Do not let your heavily accessed files default to buffer pool 1, where an inferior algorithm will be used to choose buffer assignments. There is a very interesting GTF trace, F61,that can give you additional insight into the random access pattern of your VSAM file accesses – both batch and CICS. There was a package from MKTTOOLS called VLBPAA, that was based on the F61 GTF trace which I used extensively for gaining insight into optimizing buffer assignments. No one seems to have been able to obtain this product from IBM for the past 20 years. The results did become slightly inaccurate with the introduction of extended format datasets which modified the meaning of one of the fields within the GTF trace. The use of VLBPAA and the layout of the F61 GTF trace was documented in a 1995 Redbook, SG24-2557 System/390 MVS Parallel Sysplex Batch Performance. Additionally, that manual shows an ICETOOL job stream that can perform a rudimentary analysis. That book has been removed from the Redbooks web site – fortunately I downloaded a copy before it was removed. I can send my copy to anyone who would like a copy. A couple of recommendations from my experience: (a) Always use separate pools for the data and index. This becomes especially important when the index and data components have the same CI size. For that case, the data buffers are likely to wash out the index buffers. (b) If it is practical to choose enough index buffers to hold the entire index component, then do so. Allan On Mon, May 16, 2022 at 10:36 AM Pommier, Rex <rpomm...@sfgmembers.com> 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 > > ---------------------------------------------------------------------- > 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
