According to a 2013 report based on a study with the readers of Enterprise Tech Journal, 91 percent of respondents say that some part of their business-critical data was in VSAM (New mainframe application availability report: Survey facts and insights available here). These organizations can benefit from optimizing the performance of VSAM batch, a process that starts with knowing the data. As Michael Friske pointed out in his February 2013 SHARE presentation titled “Buffering, Record Level Sharing and Performance Basics for VSAM Data Sets” (available here), “What makes one data set perform really well may cause another data set to perform poorly.” Friske listed the following considerations for understanding your data before you start:
• Is the data set being processed sequentially or randomly (directly)?
• Will the insert activity be light or heavy?
• Are records being inserted evenly throughout the data set, or are inserts concentrated in one area of the data set?
• Will records increase in size when they’re updated?
Once you know the answers to these questions about your data, spend time testing, tweaking and testing again for performance in your environment. Small changes can have a big impact, both in the right direction and the wrong one.
One of the best ways to optimize the performance of batch is to ensure you’re setting the buffers correctly for your environment. You can do this through system-managed buffering (SMB), the batch local shared resources (LSR) subsystem or VSAM buffering.
Note that for applications written in COBOL—like most batch ones are—you can only set the type of access (sequential, direct or dynamic). You can’t set the type of resources (non-shared resources or local shared resources). Therefore, SMB or batch LSR is your best option to use with COBOL applications.
Option 1: System-Managed Buffering
SMB is the method recommended for the best results for optimizing buffering because it saves you the time of manually working out how many buffers you need. (Some third-party tools for optimizing buffering also exist.)
In order to use SMB, the VSAM data sets must be managed by the storage management subsystem (SMS) and defined as extended format, as specified in the Interactive Storage Management Facility (ISMF) with DSNTYPE=EXT. Note that if the data sets aren’t specified as extended format, you get no warning; you will just see poor performance with your batch jobs. So, if you’re planning on using SMB, it’s worth double-checking that the data sets are specified as extended format.
SMB allocates buffers, depending on how the file is opened: sequential access, direct (random) access or dynamic access. SMB also determines the buffering technique: nonshared resources (NSR) or local shared resources (LSR), depending on how the file is opened. (See “Option 3: Manual Buffer Allocation” for more information about buffering techniques):