Oh I wonder why Infinidat isn't brought up here. If only they also developed an alternative to CFCC with their neural cache tech, IBM Z would be boosted to hell and back.
- KB ------- Original Message ------- On Tuesday, May 17th, 2022 at 5:39 AM, Michael Watkins <0000032966e74d0f-dmarc-requ...@listserv.ua.edu> wrote: > BLSR is referenced on page 305 of 'Batch Modernization on z/OS' (July, 2012; > z/OS V1R9): > > Implementing data in memory (DIM) techniques is a complex task, but one > likely to yield good results. It means exploiting appropriately the various > software facilities available to eliminate unnecessary I/Os. These I/Os > include repeated reads of the same data, such as: > > * DB2 buffer pools > * Virtual I/O (VIO) in Central Storage > * Queued Sequential Access Method (QSAM) buffering > * Batch LSR Subsystem (BLSR) exploiting VSAM Local Shared Resources buffering > * DFSORT Large Memory Object sorting > > To be able to implement DIM techniques, you need spare memory, spare CPU > capacity, and a batch workload that is I/O-intensive > > > I can find no 'guide' for BLSR except the 1994 reference. Some z/OS features > don't change very fast. A JCL reference from 1994 would be adequate for 99% > of all inquires. > > > -----Original Message----- > From: IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU On Behalf Of > Mark Jacobs > > Sent: Monday, May 16, 2022 11:46 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: IBM BLSR subsystem > > CAUTION: This email originated from outside of the Texas Comptroller's email > system. > DO NOT click links or open attachments unless you expect them from the sender > and know the content is safe. > > The subsysten initialization module is still in SYS1.LINKLIB for z/OS 2.5. > There's an eyecatcher with 17259 and HBB77C0 in it. > > Mark Jacobs > > Sent from ProtonMail, Swiss-based encrypted email. > > GPG Public Key - > https://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fapi.protonmail.ch%2Fpks%2Flookup%3Fop%3Dget%26search%3Dmarkjacobs%40protonmail.com&data=05|01|michael.watkins%40CPA.TEXAS.GOV|2b813d3f29024dd1dc1c08da375ba3b6|2055feba299d4d0daa5a73b8b42fef08|0|0|637883163979035974|Unknown|TWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D|3000|||&sdata=8z0medXxVEs2B7XfBWdd9Qw%2BlI4J%2F25TcY4BhSW1V2Q%3D&reserved=0 > > > ------- Original Message ------- > On Monday, May 16th, 2022 at 12:00 PM, allan winston jaw191...@gmail.com > wrote: > > > > > 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://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww. > > lascon.co.uk%2FVSAM-System-Buffers.php&data=05%7C01%7Cmichael.watk > > ins%40CPA.TEXAS.GOV%7C2b813d3f29024dd1dc1c08da375ba3b6%7C2055feba299d4 > > d0daa5a73b8b42fef08%7C0%7C0%7C637883163979035974%7CUnknown%7CTWFpbGZsb > > 3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D% > > 7C3000%7C%7C%7C&sdata=xDE8FUDazw6nILBx%2Fih3G1AKakOSecCzmpaKUP4Cpd > > s%3D&reserved=0 > > > > 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 > > > ---------------------------------------------------------------------- > 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 ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
