 |
 |
WHITE PAPER |
 |
Preventing VSAM End-of-Volume Errors with BMC MAINVIEW SRM StopX37/II |
Overview
End-of-volume service routine
How VSAM allocates additional space during EOV
Lack of available space at time of extend
Catalog updates to shared VSAM
VSAM size restrictions
Summary and recommendations
For more information
Glossary
Helping you maintain advantage
Overview
Much of today's mainframe data is stored in VSAM data sets and requires high availability. As a business grows, so does the demand for data access. A VSAM data set that fails to access additional space can have a real impact on the bottom line of a business. This paper takes a look at some of the different VSAM end-of-volume (EOV) scenarios, the controlling factors, and the various ways BMC MAINVIEW® SRM StopX37/II can help the bottom line of a business.
Some knowledge of VSAM is assumed for this paper. VSAM is just one of several access methods that are shipped with DFSMSdfp in z/OS. VSAM data sets reside on Direct-Access-Storage-Device (DASD). Catalog management and record management are the two primary functions of VSAM.
MAINVIEW SRM StopX37/II
By proactively preventing or recovering errors, MAINVIEW SRM StopX37/II allows tasks to be completed successfully the first time. MAINVIEW SRM StopX37/II works dynamically at the data set level. It operates only when needed, efficiently maintaining continuous availability. Functionality at the operating system level intercepts error conditions, providing recovery without interruption of service.
MAINVIEW SRM StopX37/II includes the following functions for handling VSAM end-of-volume (EOV) conditions:
- SPACSECA adds a secondary amount when none was defined.
- SPACSECB reduces secondary amount to fit in one physical extent on current volume (the best fit on the single largest extent).
- SPACSECR reduces secondary amount to fit in available space on current volume (may require more than one extent).
- SPACVOLA adds a volume when the current volume becomes full.
- SPACSWIR reduces the requested allocation amount (primary or secondary) on a candidate volume.
What's new for VSAM data sets
MAINVIEW SRM StopX37/II version 7.4 contains several enhancements, including
- use of extended storage groups by SPACVOLA
- SPACSECR and SPACSWIR processing for DB2 data sets
- volume recovery for shared VSAM data sets
- SPACVOLA for multistripe VSAM data sets
End-of-volume service routine
IBM provides many SVC routines for system services and functions. In addition, IBM provides the capability for users to develop their own SVC routines. SVC routines are given ID numbers 0-255 and are invoked by the SVC machine instruction. One of the IBM service routines is SVC 55, which is more commonly referred to as end-of-volume (EOV).
The origins of EOV date back to the early IBM days of working with tape volumes. Only sequential data sets could be stored on tape volumes, and the EOV routine was generally called when a task encountered a tape mark (input) or end-of-reel (output). A sequential data set was stored in one contiguous block of storage on a volume.
Today, the term end-of-volume can be a little misleading. With the introduction of DASD came the ability to store different types of data sets. Each block (physical extent) of data on a DASD volume is given a unique address (location) that permits direct access. Data set access on a DASD volume is accomplished by chaining the addresses of the physical extents. When a non-VSAM DASD data set is allocated to a task, z/OS builds a chain of data extent blocks (DEBs) for each physical extent on a volume. Similar processing is performed for a VSAM data set. The VSAM extent blocks are known as extent definition blocks (EDBs), and a VSAM data set is permitted to have up to 123 extents per volume.
In general terms, VSAM passes control to the data management EOV routine under the following conditions:
- file mark or end of last extent (input direct access volume)
- end of last allocated extent (output direct access volume)
EOV failures
EOV failures can occur for a number of different reasons. Excluding errors caused by hardware or other system problems, VSAM EOV failures fall into the following basic categories:
- a lack of available space when making a request for more space (output processing)
- internal errors for an allocated data set (shared VSAM) caused by another task altering its catalog entry (input or output processing)
Note: CICS, DB2, and IMS are some typical examples of environments that use shared VSAM data sets.
- A VSAM data set has reached an architectural restriction for the maximum size allowed when requesting more space (output processing)
While this paper will present the MAINVIEW SRM StopX37/II functions that are available to recover VSAM EOV failures, it will assume that the required StopX37/II rules are in place to allow the specified function to successful completion in the following EOV scenarios. MAINVIEW SRM StopX37/II rules are flexible and easy to define. See the MAINVIEW SRM StopX37/II User Guide for specific information about setting up the different function rules.
How VSAM allocates additional space during EOV
A VSAM data set is considered full when the high-used-relative-byte-address (HI-U-RBA) reaches the high-allocated-relative-byte-address (HI-A-RBA). When additional space is needed to write more records, EOV is invoked to increase the HI-A-RBA. The amount of space added is usually determined by the defined primary or secondary amounts in the catalog entry for the VSAM data set. The Media Manager programming interface allows a program to request a target relative block address (RBA) or relative block number (RBN). The requested target is used to calculate the primary and secondary amounts that are used by VSAM EOV. This paper focuses on the more widely used allocation amounts that are defined in a VSAM data set catalog entry.
The rule of thumb is that the primary amount is used when acquiring the initial extents on any volume. The secondary amount is used when allocating additional extents on the current volume. There are some exceptions, as is the case with multistripe or DB2 linear data sets, where the secondary amount is also used when allocating the initial extents on additional volumes. For these data sets, the primary amount is only used for the initial allocation on the first volume(s).
Note: The Additional Volume Amount field in a DFSMS Dataclass also allows you to specify which amount (primary or secondary) is used when extending to an additional volume.
Lack of available space at time of extend
One of the primary functions of EOV is to acquire more space when a data set becomes full. If VSAM is unable to obtain additional space, MAINVIEW SRM StopX37/II can alter the primary or secondary amounts that are used by VSAM EOV to fit in the available space. In addition, MAINVIEW SRM StopX37/II can add candidate volumes when no more candidates exist for the data set.
It should be noted that MAINVIEW SRM StopX37/II does not alter the primary and secondary amounts in the catalog during EOV. MAINVIEW SRM StopX37/II also ensures that any adjusted amounts are a full increment of the VSAM data set control area (CA) size.
This paper uses a nonstriped ESDS VSAM data set to show how EOV extends a typical VSAM data set. The EOV process is essentially the same for any VSAM component.
The CYL (cylinder) parameter in the DEFINE CLUSTER statement shown in Figure 1 specifies the primary and secondary allocation amounts for SAMPLE.STOPX.NONSMS.DATA. The VOL (volume) parameter specifies TSG331 is the only volume allocated to this data set. At the time of definition, an initial primary amount of 400 cylinders is acquired on volser TSG331.
DEFINE CLUSTER (NAME(SAMPLE.STOPX.NONSMS) -
CYL(400 50) -
VOL(TSG331) -
FREESPACE(0 ) -
NONINDEXED -
RECORDSIZE(4160 4160) -
SHAREOPTIONS(2 3) -
)
|
The excerpt from a subsequent LISTCAT (see Figure 2) shows the results of the DEFINE CLUSTER statement. The ALLOCATION and VOLUME sections hold much of the essential catalog information that is used by the VSAM EOV process.
LISTCAT notes
- VSAM allocates extents in TRACKS, whether SPACE-TYPE is defined as CYLINDER or TRACK. A cylinder allocation amount is multiplied by 15 to determine the number of tracks because all DASD is configured as 15 tracks per cylinder today.
- The first allocated extent in a VSAM data set always starts the LOW-RBA field at relative zero, which makes the HIGH-RBA field of the last allocated extent 1 byte less than the total bytes allocated to the data set.
- A volume with allocated extents will be flagged (VOLFLAG) as PRIME.
The HI-A-RBA indicates 319488000 bytes are now available for storing records, and the HI-U-RBA is 0. Also, note the 400 cylinders of primary space were actually allocated in 5 extents. This indicates that volume TSG331 was nearly full at the time the data set was defined and 400 cylinders were not available in one contiguous extent. When SAMPLE.STOPX.NONSMS.DATA is allocated to a task, a chain of 5 EDBs are built to indicate the location of the allocated space for the VSAM data set. The LOW-CCHH and HIGH-CCHH addresses indicate the location of each extent on volume TSG331.
EOV scenario 1
After the HI-U-RBA meets the HI-A-RBA and there is a request to write additional records to the data set, EOV will be invoked to acquire more space. Because the sample data set is defined with a secondary amount greater than 0, VSAM EOV will attempt to allocate 50 cylinders on current volume TSG331. If space is available and the extend is successful, VSAM EOV adds the additional extent information to the task's EDB chain and the catalog entry for the data set. The following sample LISTCAT shows another 50 cylinders (750 tracks) were allocated on volume TSG331 and the
HI-A-RBA is now 359424000 bytes.
SPACSECB
SPACSECB is the one VSAM EOV function in MAINVIEW StopX37/II that is not invoked for error recovery. SPACSECB makes better use of the existing extents on the current volume by selecting the size of the largest single extent when more than one is required to satisfy the secondary request.
In this scenario, 50 cylinders were allocated in two physical extents. One extent is 720 tracks and the other is 30 tracks. If SAMPLE.STOPX.NONSMS.DATA qualified for SPACSECB processing, MAINVIEW SRM StopX37/II would have changed the secondary request to 48 cylinders (720 tracks) and only allocated one additional extent. The SPACSECB function can serve two purposes:
- It can reduce the extent fragmentation for the data set.
- It helps keep the total extent count from reaching the 123 maximum allowed on an individual volume for a VSAM data set.
EOV scenario 2
As we saw in "EOV scenario 1.", VSAM EOV was able to allocate the secondary amount (50 cylinders) on the current volume. However, if volume TSG331 did not have 50 cylinders available, the extend would fail and VSAM EOV would issue an IEC070I 104-204 error message. (If this was a SMS-managed data set, VSAM EOV would issue an IEC070I 209-220 error message.)
SPACSECR
SPACSECR reduces the secondary amount when EOV is unable to obtain the requested space seen in EOV scenario 2. If SAMPLE.STOPX.NONSMS.DATA qualified for SPACSECR processing and space was available on volume TSG331, MAINVIEW SRM StopX37/II would lower the secondary request to fit in the available space.
SPACVOLA
If no space was available on the current volume in EOV scenario 2, SPACSECR would be unable to recover the error. Under these conditions, MAINVIEW SRM StopX37/II can add a candidate volume with the SPACVOLA function to prevent the error. If SAMPLE.STOPX.NONSMS.DATA qualified for SPACVOLA processing, MAINVIEW SRM StopX37/II would add a candidate volume to its catalog entry and rebuild the task's internal control blocks to indicate the additional volume. This feature allows VSAM EOV to acquire additional space on the new volume, by using the primary amount defined for the data set.
The two primary functions of VSAM are record management and catalog management. One example of catalog management is how VSAM EOV updates the catalog with new extent information after extending the EDB chain (seen in "EOV scenario 1."). If this new extent information is to be placed on a volume that is added by SPACVOLA, MAINVIEW SRM StopX37/II must first alter the catalog entry for the data set with the new volume so that VSAM EOV can insert the new extent information. MAINVIEW SRM StopX37/II is also required to rebuild some additional z/OS internal control blocks, including the task input/output table (TIOT), job file control block (JFCB), and SMF timing control table input/output measurement table (TCTTIOT) to indicate the additional volume in the active task. The end result is these task control blocks remain in-sync with the catalog entry for the VSAM data set. This concept is important and will be seen again in the discussion on shared VSAM data sets.
DFSMS Dynamic Volume Count
The Dynamic Volume Count (DVC) parameter that is supplied in a DFSMS data class can be used to specify the total number of volumes a data set can span, without actually placing an entry in the catalog until needed by EOV to extend the data set. Consider the following when using DVC:
- The value that is specified in Dynamic Volume Count is used to determine the size of the TIOT, TCTTIOT, and JFCB control blocks when allocating a data set.
Example: A data set exists on only one primary and no candidate volumes.
If the data set was defined with a DVC of 20, an additional 684 bytes of unused storage (19 volumes x 36 bytes) is obtained during allocation. When the data set needs to extend to a new volume, EOV just places the new volume information in the already obtained z/OS control block storage and adds another volume entry in the catalog with the new volser.
In contrast, SPACVOLA obtains an additional 36 bytes of control block storage and updates the catalog entry only when the data set needs to extend to a new volume.
In both methods, the data set was successfully extended to a new volume and now exists on two volumes. However, using Dynamic Volume Count still leaves 648 bytes of unused storage in the task.
The use of Dynamic Volume Count can have an impact on tasks that are allocating a large number of data sets. Refer to IBM APAR OA04179 (HIPER) for further information about maintaining data classes with Dynamic Volume Count.
Notes:
- In most circumstances, 36 bytes of storage is all that is required to hold information about a volume in an active task (4 bytes for each device entry in the TIOT and 32 bytes for each TCTDDENT in the TCTTIOT).
- When adding the 21st, 36th, or 51st volume to a VSAM data set, an additional 176 bytes of storage will be obtained for another JFCB extension (JFCBX control block).
- The DVC value must be large enough to prevent EOV errors. In other words, a DVC value of 20 will lead to an EOV error if a 21st volume is needed to extend the data set. However, MAINVIEW SRM StopX37/II can add volumes as needed with the SPACVOLA function.
- The personnel hours required to define, monitor, and maintain the various DFSMS data classes using Dynamic Volume Count will incur additional costs and overhead.
EOV scenario 3
The following sample DEFINE CLUSTER has more than one VOLSER specified in the VOL parameter.
A LISTCAT following the DEFINE CLUSTER shows an additional VOLUME section for volser TSG337. The VOLUME entry for TSG337 is flagged as a candidate volume, because no space has been allocated on the volume for the data set.
The essential difference with predefined candidate volumes is that the TIOT, JFCB, and TCTTIOT control blocks will be built with the candidate volume information during data set allocation. This method allows EOV to use the volume and build an EDB chain for any extents if the current volume (TSG331) becomes full. As you saw with Dynamic Volume Count, predefined candidate volumes have the same disadvantage of obtaining additional unused storage in these z/OS control blocks.
Candidate volumes do have an impact on how EOV handles VSAM extends. The presence of a candidate volume allows VSAM EOV to find the primary space on the new volume when it cannot find the secondary amount on the current volume.
In "EOV scenario 2.", the IEC070I 104-204 error message was issued when the available space on the current volume was less than the requested secondary. If the same conditions exist with an available candidate volume, VSAM EOV would not issue the IEC070I 104-204 message. Instead, VSAM EOV would attempt to allocate the primary amount on the next available candidate volume. If the primary amount of 400 cylinders was available, VSAM EOV would build an EDB chain for volume TSG337 and update the TSG337 VOLUME section with this new extent information in the catalog entry. In addition, the VOLFLAG for TSG337 would be changed to PRIME to indicate that allocated extents are on the volume.
A note about SPACSECR with candidate volumes
SPACSECR will not be invoked to reduce the secondary amount on the current volume if a candidate volume is available. For instance, if TSG331 had 49 cylinders available at the time of extend, VSAM EOV would look for 400 cylinders on TSG337 for our sample data set. Without the candidate, SPACSECR could have reduced the secondary to 49 cylinders and made better use of the space on TSG331 before allocating extents on VOLSER TSG337. In other words, SPACSECR can help reduce data set fragmentation across multiple volumes.
EOV scenario 4
What happens when VSAM EOV cannot find enough space on a candidate volume to allocate the primary amount? If volume TSG337 did not have 400 cylinders available in "EOV scenario 3.", VSAM EOV would issue an IEC070I 209-211 error message. (For SMS-managed VSAM data sets, the IEC070I return-reason codes would be 209-220.)
SPACSWIR
MAINVIEW SRM StopX37/II can invoke the SPACSWIR function when not enough space is available on a candidate volume. SPACSWIR is similar to SPACSECR, except that it reduces the allocation amount on a candidate volume instead of the current volume.
If SAMPLE.STOPX.NONSMS.DATA qualified for SPACSWIR processing and space was available on candidate TSG337, MAINVIEW SRM StopX37/II would attempt to reduce the primary amount to fit in the available space.
Note: SPACSWIR can also recover errors after SPACVOLA adds a candidate volume.
VSAMPRIM global parameter
The MAINVIEW SRM StopX37/II VSAMPRIM global parameter determines whether the secondary or primary amount will be used when extending to a new candidate volume. Setting VSAMPRIM=NO (the default) directs MAINVIEW SRM StopX37/II to use the secondary amount when extending to another volume. Because VSAM data sets are generally defined with a smaller secondary than primary amount, VSAMPRIM=NO reduces the need for SPACSWIR recoveries and makes better use of available space. Consider a VSAM data set that is defined with CYL(1000 20). If a candidate volume is required, do you really want to allocate another 1000 cylinders to add a few more records? In most cases, allocating another 20 cylinders is sufficient and reduces waste of DASD storage. Unlike the Additional Volume Amount field in a DFSMS Dataclass, the VSAMPRIM global setting affects all VSAM data sets.
Note: The VSAMPRIM global parameter is ignored for multistripe and DB2 (linear) data sets.
EOV scenario 5
Consider a VSAM data set that is defined with no secondary amount.
This example indicates a primary of 400 cylinders and no secondary. In addition, no candidate volumes are available. When the HI-U-RBA meets the HI-A-RBA and more space is requested, VSAM EOV will generally issue the IEC070I 203-204 message. (The IEC070I return-reason codes would generally be 209-220 for a SMS-managed VSAM data set.)
SPACSECA
When no secondary is defined, MAINVIEW SRM StopX37/II can prevent EOV errors by inserting a secondary amount based as a percentage of the defined primary. If the sample data set qualified for SPACSECA processing with a rule to use 10% of the defined primary, MAINVIEW SRM StopX37/II would insert a secondary amount of 40 cylinders. If the 40 cylinders was available, the extend would succeed. If only 25 cylinders were available on volume TSG331, SPACSECR could be invoked to reduce the added secondary.
VSAMZSEC global parameter
The VSAMZSEC global parameter determines whether MAINVIEW SRM StopX37/II should invoke the SPACSECA or SPACVOLA functions for VSAM EOV errors that were due to no defined secondary. VSAMZSEC=YES indicates that the SPACSECA function controls recovery for this error condition. SPACVOLA controls recovery when there is no secondary amount and VSAMZSEC=NO.
Note: The VSAMZSEC global parameter does not apply to multistripe data sets, because a multistripe data set will extend with the primary amount when no secondary amount is defined.
Other EOV scenarios
Although the examples shown in this document were for a data set that was not SMS-managed, the VSAM EOV process is essentially the same for SMS and non-SMS-managed data sets. Notable differences are the use of asterisk (*) as a placeholder for candidate volumes and the different VSAM EOV error codes that were seen with DFSMS data sets. DFSMS also allows you to define VSAM data sets with multiple stripes or guaranteed space. Both present EOV with some different requirements.
Multistripe VSAM
A VSAM data set can be defined with multiple stripes where the primary amount is allocated to a number of volumes equal to the stripe count. For example, a VSAM data set defined with 5 stripes and a primary of 150 tracks can have 150 tracks allocated on 5 volumes. When a multistripe VSAM data set needs more space, VSAM EOV uses the secondary amount to extend each stripe (or volume). If the multistripe data set was defined with no secondary, the primary amount would be used to extend the data set. However, unlike the initial primary allocation, the amount used to extend the data set is evenly distributed among the number of stripes. If a multistripe data set with 5 stripes is defined with a secondary of 25 tracks, VSAM EOV would allocate 5 tracks on each volume.
In addition, an individual stripe can extend to another volume when the original volume runs out of space. This method is referred to as adding another layer to the stripe, or multilayering. Refer to the topic on “VSAM Data Striping” in the DFSMS: Using Data Sets manual for more information about stripe layering.
If VSAM EOV is unable to obtain the secondary request for a multistripe VSAM data set, MAINVIEW SRM StopX37/II can reduce the secondary amount with the SPACSECR function. Any SPACSECR reduction affects all stripes, because any new extend amount requires it be equally divided among the number of defined stripes (volumes). SPACSECR reduction works a little differently for multistripe data sets, because the available space in each volume needs to be considered. SPACSECR reduces the secondary allocation amount by a defined percentage in the qualifying SPACSECR rule and attempts the extend again. If the extend should fail again, the secondary is reduced further by the same percentage until VSAM EOV can obtain the space for all stripes.
MAINVIEW SRM StopX37/II version 7.4 can also perform a SPACVOLA to add a volume to an individual stripe when a volume becomes full or SPACSECR is unable to recover.
MAINVIEW SRM StopX37/II function SPACSECB is not invoked for multistripe VSAM data sets.
Guaranteed space
Defining a data set with guaranteed space allocates the primary amount to the number of volumes that are defined. If a VSAM data set is defined with 5 volumes, nonstriped, guaranteed space, and a primary of 150 tracks, all 5 volumes would have extents for 150 tracks.
Although all 5 volumes have set aside 150 tracks for the data set, VSAM EOV will exhaust the available space on the first volume before writing data to the second volume. This process includes allocating additional extents using the secondary amount (if defined) on the first volume. After space is exhausted on the first volume, VSAM EOV will use the 150 tracks allocated to the second volume. This same process is repeated for each volume until all space is exhausted and all 5 volumes are used. At that point, additional volumes can be allocated as needed.
All MAINVIEW SRM StopX37/II VSAM EOV functions work on data sets that are defined with guaranteed space.
Catalog updates to shared VSAM
VSAM data sets can be shared between different address spaces and different LPARs as long as access to the catalog entry is available. A discussion about sharing VSAM data sets goes beyond the scope of this paper. However, it is important to mention shared VSAM data sets are not that uncommon and they can lead to some additional EOV issues.
If the same sample data set that is defined in "EOV scenario 1." is allocated to more than one address space (ASID) with the original 400 cylinders defined to the data set, both ASIDs would build TIOT, JFCB, and TCTTIOT for only one volume (TSG331). In addition, both ASIDs would build an EDB chain for the original 5 physical extents on volume TSG331. For simplicity, the separate ASIDs will be referred to as JOB1 and JOB2.
While adding more records to the data set, JOB1 causes VSAM EOV to be called to acquire more space. Another 50 cylinders is successfully added to volume TSG331. This causes VSAM EOV to update the EDB chain in JOB1 and record the new extent information in the catalog entry. However, JOB2 knows nothing about the new extents until it attempts to read past the original HI-A-RBA or add more records. At that point, VSAM EOV will obtain the updated catalog information for the volume and update the EDB chain in JOB2.
The real problem with shared VSAM is when candidate volumes are added to the catalog entry for a data set after the data set has been allocated to a task. In "EOV scenario 2." no more space was available on the current volume and MAINVIEW SRM StopX37/II added a candidate volume with SPACVOLA. If JOB1 performed the SPACVOLA, it would update its internal control blocks (TIOT, JFCB, and TCTTIOT) with the new volume and alter the catalog entry for the data set. When JOB2 needed to add or access data on the new volume, it would encounter VSAM EOV error IEC070I 210-212. If this was an SMS-managed VSAM data set, an IGD306I RC24 error would be issued, followed by IEC070I 210(8,17241)-220. Unlike the EDB, the TIOT/JFCB/TCTTIOT control blocks are not the property of VSAM. Therefore, VSAM EOV is forced to issue an error when a job encounters a volume mismatch between its z/OS control blocks and the catalog entry.
It is also important to note that anyone, not just SPACVOLA, can perform an ALTER ADDVOLUME to a shared VSAM data set catalog entry. The EOV failure outcome is still the same. Adding candidate volumes to a shared VSAM data set has actually been a problem for many years. Fortunately, MAINVIEW SRM StopX37/II now has a solution.
SPACVOLA Recovery
MAINVIEW SRM StopX37/II version 7.4 introduces SPACVOLA Recovery, which updates the TIOT, JFCB, and TCTTIOT control blocks with the new volume information found in the catalog entry. If a data set qualifies for SPACVOLA, it also qualifies for SPACVOLA Recovery. If you think about it, SPACVOLA Recovery is just SPACVOLA without the update to the catalog with the new volume information (it's already been put there by some other task).
Note: In earlier releases, MAINVIEW SRM StopX37/II recovered new volumes for shared RLS data sets in CICS environments only.
VSAM size restrictions
Early architecture limited a VSAM data set to 4 gigabytes (GB) of data, 123 extents per volume, 255 total extents, and a maximum of 59 volumes. Over the years, IBM has responded to customer needs by allowing VSAM data sets to grow larger.
Notes:
- Prior to z/OS 1.7, the total extent limit for a nonstriped VSAM data set was 255.
- Prior to z/OS 1.7, a multistripe VSAM data set could have up to 4080 extents. An individual stripe was permitted to have 255 extents.
When a VSAM data set reaches the maximum size limit, little can be done to prevent unwanted outages. The only solution is to monitor the space usage of your VSAM data sets to avoid any unexpected problems. A reporting tool such as MAINVIEW SRM Reporting can quickly identify any VSAM data sets that are nearing the maximum limits.
VSAMLIMWARN global parameter
Because MAINVIEW SRM StopX37/II hooks the VSAM EOV service routine, it provides an additional opportunity to monitor the current size of a non-EA data set as it nears the 4 GB limit. The VSAMLIMWARN global parameter can be set to issue warning messages when a non-EA VSAM data sets reaches 50-99 percent of the 4 GB limit.
Setting global VSAMLIMWARN=80 directs MAINVIEW SRM StopX37/II to issue a SVM4157I informational message when a non-EA VSAM data set extends successfully and 80% or more of the 4 GB limit has been allocated. As a non-EA data set approaches the 4 GB maximum allowed, this setting could produce the following messages when there has been a successful extend during EOV:
SVM4157I dsname,stepname,ddname, USING 82% OF 4GB VSAM LIMIT SVM4157I dsname,stepname,ddname, USING 88% OF 4GB VSAM LIMIT …and so on SVM4157I dsname,stepname,ddname, USING 100% OF 4GB VSAM LIMIT |
Note: The SVM4157I message is issued once for each successful extend. The above example shows how MAINVIEW SRM StopX37/II continues to issue the message after each extend until the data set reaches the 4 GB maximum limit.
VSAM_ADJ4GB global parameter
In addition to monitoring the size of a non-EA VSAM data set, MAINVIEW SRM StopX37/II can also modify the current primary and secondary amounts to ensure that the data set extends by using the maximum 4 GB limit allowed. This feature is controlled by the VSAM_ADJ4GB global parameter.
For example, SAMPLE.STOPX.VSAM.DATA is defined with 400 cylinders primary, 50 cylinders secondary, and an extend amount greater than 32 cylinders will exceed the 4GB maximum limit. If VSAM_ADJ4GB=YES, the next time SAMPLE.STOPX.VSAM.DATA enters EOV to acquire more space, MAINVIEW SRM StopX37/II will adjust the primary and secondary values to 32 cylinders to prevent a failure. MAINVIEW SRM StopX37/II will issue the following SVM4060I informational message for both the primary and secondary amounts;
SVM4060I SAMPLE.STOPX.VSAM.DATA ADJUSTED TO FIT WITHIN 4GB LIMIT, PRIMARY SET TO 32 CYLS |
SVM4060I SAMPLE.STOPX.VSAM.DATA ADJUSTED TO FIT WITHIN 4GB LIMIT, SECONDARY SET TO 32 CYLS |
Looking at a similar example where an extend amount greater than 73 cylinders would exceed the 4 GB limit, MAINVIEW SRM StopX37/II would only adjust the primary amount. (The defined secondary of 50 cylinders would not exceed the 4GB limit.)
Because a VSAM data set has the potential to extend with either the primary or the secondary amount, MAINVIEW SRM StopX37/II ensures that neither amount will exceed the 4 GB limit when VSAM_ADJ4GB is set to YES.
Additional MAINVIEW SRM StopX37/II messages during EOV
When a VSAM data set reaches one of the architectural restrictions on size, VSAM EOV will generate an IEC070I message with return/status codes to indicate why the extend failed. Although more experienced personnel might be able to quickly interpret the different IEC070I return codes, MAINVIEW SRMStopX37/II can assist further with error diagnosis by providing more meaningful messages, such as those shown in Figure 8.
Summary and recommendations
This overview of VSAM EOV should provide a better understanding of what to consider when maximizing the potential growth of your VSAM data sets and minimizing the waste of your DASD storage. The EOV scenarios illustrated here show how the original primary and secondary amounts might be insufficient at the time when space is needed. In addition, you have seen how candidate volumes and the use of DFSMS Dynamic Volume Count cause additional unused storage to be obtained within an address space.
Although each VSAM data set should be considered individually, the following is a good rule of thumb when using MAINVIEW SRM StopX37/II to assist with managing your VSAM storage:
- Qualify your VSAM data sets for SPACSECR.
- Qualify your VSAM data sets for SPACVOLA.
- Qualify your VSAM data sets for SPACSWIR.
- Do not use DFSMS Dynamic Volume Count.
- Do not predefine candidate volumes.
You can specify specific volumes, or a pool of volumes, in your MAINVIEW SRM StopX37/II rules for selection by SPACVOLA.
- Keep the global parameter VSAMPRIM default set to NO.
- Keep the global parameter VSAM_ADJ4GB default set to YES.
- When sharing VSAM data sets, keep the global parameter SHARED_VSAM default set to YES.
- (optional) Qualify your VSAM data sets for SPACSECB.
SPACSECB can reduce extent fragmentation on the current volume.
- (optional) Qualify your VSAM data sets for SPACSECA and set VSAMZSEC=YES.
SPACSECA allows your VSAM data sets with no defined secondary amount to grow on a current volume, reducing data set fragmentation across multiple volumes.
For more information
For further questions about how MAINVIEW SRM StopX37/II can assist with your storage needs, contact BMC Software at 1-800-841-2031 or see www.bmc.com.
For more detailed information about MAINVIEW SRM StopX37/II, see the MAINVIEW SRM StopX37/II User Guide and Reference manual.
For more information about VSAM and z/OS, see the following documents:
- z/OS V1R5.0 DFSMS Using Data Sets, IBM manual
- VSAM Demystified, IBM Redbook
- VSAM: A Comprehensive Guide, Constantine Kaniklidis
Glossary
Helping you maintain advantage
BMC Software Education Services offers a strategic investment for your business, maximizing the value for your employees and Business Service Management initiatives. Education ensures successful product implementation, promoting mastery of all product capabilities and highest productivity with your BMC Software solutions. To explore our education offerings, visit our web page at http://www.bmc.com/bmceducation, or contact BMC Software Education Services by telephone or e-mail:
- North America
Telephone: 800 574 4262
E-mail: education@bmc.com - Asia Pacific
Telephone: +61 3 9657 4404
E-mail: ISD_AP@bmc.com - Europe, Middle East, and Africa (EMEA)
Telephone: 00800 26233822
E-mail: emea_education@bmc.com
Copyright 2005 BMC Software, Inc., as an unpublished work. All rights reserved.
BMC Software, the BMC Software logos, and all other BMC Software product or service names are registered trademarks or trademarks of BMC Software, Inc.
IBM is a registered trademark of International Business Machines Corporation.
All other trademarks belong to their respective companies.
November 2005
About BMC Software
BMC Software, Inc. [NYSE:BMC], is a leading provider of enterprise management solutions that empower companies to manage their IT infrastructure from a business perspective. Delivering Business Service Management, BMC Software solutions span enterprise systems, applications, databases, and service management. Founded in 1980, BMC Software has offices worldwide and fiscal 2004 revenues of more than $1.4 billion. For more information about BMC Software, visit www.bmc.com.