Norma, In terms of the buffering algorithm Hiperbatch and BLSR are really chalk and cheese.
Hiperbatch is designed for buffering sequential access from multiple, concurrent jobs where the buffering is designed to have trailing jobs catch up to the leading job, and then have the leading job prime the Hiperbatch buffer where the trailing jobs just read from Hyperspace buffer. It is a very unique buffering methodology, and when implemented along with job scheduling and WLM changes it can make enormous improvements to performance by reducing and even eliminating sibling pend and IOS queue time. There is a second method used with Hiperbatch where the whole data set is retained in the buffer after it has been read. While I'm sure this has been used successfully, I have never seen it used this way and the sequential buffering I mentioned above is much more efficient, especially when you have many jobs (30-50) accessing many data sets sequentially. Retain also introduces a data integrity exposure where the dataset is shared across multiple LPARs. BLSR, or System Managed buffering is designed around random access buffering, using a Least Recently Used (LRU) block replacement algorithm. The success of the buffering really depends on the locality of reference within the data set. Assuming your KSDS does not have decent NSR buffering, LSR usually speeds up random access by buffering the index after each index CI is read just once. Even with good NSR buffering you can only buffer all of the index set - the sequence set CI still have to compete with only one buffer for each string, and good old COBOL usually uses only one string. When you configure BLSR or SMB always make the index buffer large enough to hold the whole index. With LSR and the data component, getting it right is just like getting cache on the storage right - YMMV. There are data sets that will never get a good buffer hit rate unless you load the whole data set into the LSR buffer. Just being a few CI short can make the whole thing perform like there is no buffering, especially where it is accessed sequentially. I suggest starting the buffer for the data component at least 10% of the size of the data component, and fine tune from there. For BLSR and SMB the thing I see most forgotten most often is to specify the VSAM deferred write option. Without this, every time you update a record in a CI the CI will be written to disk. Update 100 records in a CI and you will write it 100 times. With the VAM deferred write option the CI will be written (a) when the LRU algorithm decides to cast it out and free the buffer slot, or (b) when the file is closed. For BLSR specify DEFERW=YES in the SUBSYS parameter. For SMB you specify SMBDFR=Y in the AMP parameter. There is some material to read on using deferred writes in the BLSR manual, basically that sharing a KSDS while it is being updated requires correct sharing by all addresses sharing the dataset. Don't fudge or bypass the share options. As a last resort, HDS and EMC also have options that allow you to lock a dataset into cache, eliminating any sibling pend when you want to have 300 jobs reading one or two files at the same time. You still have to do the IO on the channels, but this is better than SSD performance. On HDS it is also faster than a normal cache hit. Ron > -----Original Message----- > From: IBM Mainframe Discussion List [mailto:[email protected]] > On Behalf Of Mowry, Norma E CIV DISA ESB (US) > Sent: Monday, June 17, 2013 5:04 AM > To: [email protected] > Subject: [IBM-MAIN] Question about LSR vs HiperBatch > > We are looking into using either Batch LSR (local shared resources) or > HiperBatch for batch jobs that use the same resources (VSAM files...) What > (if any) are the recommendations, pitfalls of each or is the another option to > do this? We are running z/OS V1.13. > > Thanks > > Norma Mowry > DECC-Mechanicsburg > Operating Systems Support (ESB11) > (717)-605-7865 DSN:430 > e-mail address: [email protected] > > ---------------------------------------------------------------------- > 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
