Things have been relatively quiet in the Red Alert area until this week when three problems surfaced. Most installations have at least one person who subscribes to Red Alerts, but we think it’s important for more people to be aware of these. You can subscribe yourself at https://www14.software.ibm.com/webapp/set2/sas/f/redAlerts/home.html.
Red Alert 2016.11.02 – HIPER APARs for z/OS 2.2 Users
IBM has issued Red Alert 2016.11.02 – Two Important Recommendations for z/OS V2R2 Users. This Red Alert identifies two situations identified by HIPER APARs:
- Potential for z/OS V2R2 JES2 members unable to WARM start. If you have a JES2 Checkpoint on DASD and running in DUAL mode (CKPTDEF MODEL=DUAL), JES2 could abend or have I/O errors when trying to read a large CHLOG (Change Log). The local fix is to switch the checkpoint back to DUPLEX mode until the fix for Hiper APAR OA51558 can be applied. If you experience the problem, you might be required to perform a COLD start on JES2.
- Potential for loss of access to data on a volume due to erroneous ‘End of File’ written to the VTOC or VTOCIX on z/OS V2R2 DFSMS (HDZ2220). If you have enabled Second Space Reduction (SSR) and DFSMS receives an AbendE37 when no storage space is available for secondary extents, the VTOC or VTOCIX could be overlaid, rendering other data on the volume inaccessible. The fix for this HIPER APAR OA51499 is not available yet, but the APAR shows two ways of disabling the SSR feature. For more information on SSR, see the last item below.
Red Alert 2016.11.04 – Update to 2016.11.02 z/OS V2R2 VTOC Alert
But there was a problem with the VTOC issue that was discovered two days later, so another Red Alert that was issued to add the following information:
Please note: If recent PTF UA82730 is applied then you must remove this PE PTF or apply ++APAR for OA51474 prior to disabling SSR. Please see APAR OA51499 Local Fix for additional details.
Caution: An IPL is required if you need to remove the PTF!
What is Secondary Space Reduction (SSR)?
z/OS 2.2 introduced a feature called Secondary Space Reduction (SSR), which we described in our 2015 No 3 Tuning Letter in describing changes in the DEVSUPxx Parmlib member:
A value of SSR was added to the ENABLE and DISABLE parameters to enable or disable the secondary space reduction support of the Device Manager. To understand this parameter, you need to understand a new z/OS 2.2 access method enhancement called ‘Secondary Space Reduction’ (SSR).
Prior to z/OS 2.2, if a data set needs a secondary extent and there isn’t enough room on the current volume, EAV calls SMS to switch volumes. SSR allows an installation to specify an attribute ‘Reduce Space Up To (%)’ in the ISMF data class definition (under ‘Space Constraint Relief’). If DEVSUPxx specifies ENABLE(SSR), then DADSM will attempt to allocate the largest free space on the volume before going to another volume. This provides support for SMS-managed non-striped VSAM data sets and non-VSAM data sets.
As an example, you could have a secondary allocation of 100 CYL and a ‘Reduce Space Up To (25%)’ on the data class. With SSR disabled, if 100 cylinders weren’t available on the current volume, the space would be allocated on another volume. This method tends to leave a lot of unused disk space. With SSR enabled (the default), if the current volume had between 75 and 99 cylinders available, the maximum size available on the volume would be allocated as the secondary extent.
RECOMMENDATION: There are several installations that could benefit from this feature that improves disk space utilization. Before implementing it, however, you should confirm that allocating a smaller amount than specified as a secondary extent will not impact the application. Try it on one data class at a time in cooperation with the application developers and batch schedulers.
We thought this explanation would be a help in understanding the second part of the first Red Alert described above.