- VSAM structures
- VSAM commands
- Performance tuning
- JCL Buffers
- LSR Buffers
- System Buffers
- VSAM parameters
- IAM, a VSAM alternative
- VSAM Recovery
- VSAM RLS, DFSMStvs
One way to retain data in storage is to use LSR buffers. They are a bit difficult to set up, but can defined to be automatically invoked by named programs. This makes them easy to use.
STROBE is an excellent product for checking buffer usage. The following is a tailored example of Strobe output, which illustrates LSR buffers in action. Basically, the output was simplified to make it suitable for the Web, the full output stretches to about 15 columns. Non I-O means the process got its data from buffers. I-O means the operation had to go out to disk.
|BUF||BUFNO||I-O / NON I-O||I-O / NON I-O|
|1024||5||3 / 39928||0 / 0|
|2048||200||228 / 599066||343 / 0|
|4096||1000||34146 / 321715||2639 / 435|
You can see that the 2K buffers are performing exceptionally well, with almost all the data requests coming from buffers.
LSR cannot be used on data which has alternate indices. If the program does both sequential processing and direct updates, the updates sometimes hang, because the sequential read request is holding the buffer.
Batch LSR is easier to set up than LSR, and it appears to use buffers more intelligently. If records are written out using multiple PUT statements, VSAM normally does an I-O for every PUT, but with BLSR, these become deferred writes, so we get one write per CI. BLSR also uses a different algorithm for swapping out buffers. It uses least recently used (LRU), rather than oldest, so there is more chance of getting the next record you need in a buffer.
BLSR runs as an z/OS subsystem, and needs a change to the IEFSSNxx member in SYS1.PARMLIB to define it. Typically, this would be a line looking like
Once the subsystem is activated, all that is needed is an extra JCL DD statement which allocates the file to be buffered :
//ddold DD SUBSYS=(BLSR,'DDNAME=ddnew','HBUFND=100','HBUFNI=20')
//ddnew DD DSN=aa.bb.cc,DISP=SHR etc.
Where 'ddold' is the ddname the program is expecting to find, which points to 'ddnew', the original ddname.
Software products exist which automate all this buffering seamlessly.
One such product is Performance Essential (currently supplied by Rocket Software under exclusive license from EMC) which has been known to cut batch run times down by 25%, and in exceptional cases individual batch job run times have reduced by 95%
Performance Essential runs as a Started Task, and has a central control repository which contains generic, or specific lists of jobs which are eligible for management. Once the product 'learns' about a job, it can then adjust buffers automatically, to cope with regular changes, such as month end runs.