The combination of lower prices for storage devices and increasing government compliance regulations leads to more data being stored for longer periods of time. Today, storage administrators manage increasingly larger amounts of data.

– Storage administrators are vital to IT departments because they protect and maintain a company’s most valuable asset-its data.

Examining the thrashing report and who or what is recalling the data sets will help you set better management class policies. Recall thrashing: Migrating and then immediately (or in a short period of time) recalling the same set of data sets wastes valuable HSM resources and CPU cycles and can be quite costly.

Understanding what is being migrated and quickly recalled requires a thrashing report. You can also code batch JCL to be more efficient in how it handles GDG bases or sequential files.

Because HSM is so powerful and performs so many tasks, it has the potential to have problems. The areas of HSM that lead to problems are high CPU usage because of unneeded or wasteful actions, failures in space management or the recycle process, internal control data set errors, and problems with the aggregate backup and recovery support (ABARS) and/or auto dump processes. This article provides best practices for optimizing the HSM environment, specifically in lessening high CPU usage and improving space management, as well as providing tips for proactively managing HSM.

Using an SRM tool, you can correct some of the most common causes of high CPU usage associated with storage movements:

High CPU usage generally raises red flags in IT shops.

It is best to run it during low tape drive usage, such as early in the morning just before normal business hours, or just before the nightly batch cycle runs. Recycle should be part of an automated solution.

How the recycle is run–and when it is run–can also lead to wasteful recycles. Wasteful tape recycle Wasteful tape recycle usually results when the percent full setting is set too low or not: high enough.

SRM tools can help reduce or eliminate unnecessary HSM activity by tracking activity and thrashing and by tying the data sets to the DFSMS constructs.

Migrating unnecessary data sets: An easy way to reduce CPU usage is to reduce or eliminate unnecessary HSM activity that is caused by ineffective management class policies or application JCL.

One of the critical roles of the storage administrator is to understand and manage DFSMShsm, the hierarchical storage management (HSM) environment shipped with IBM z/OS systems. HSM provides backup, recovery, migration, and space management functions and enables storage administrators to manage storage at the data set level and device pool level. To optimize the HSM environment, storage administrators can set and apply rules in HSM.

Lessening CPU Usage

Return code 99 is caused by an undefined DSORG, which can cause errors during backup and migration. SRM tools enable you to quickly see which return codes you received and how to correct them. Return code 37 is issued when there is not enough contiguous space to migrate the data set.

Errors in space management: You can correct errors in space management by changing management class policies, removing undefined DSORG data sets, removing uncataloged data sets, and halting any other unnecessary HSM recall/migration/backup activity. For example, dealing with return code 99, 19, 82 and 37 will buy back quite a bit of productivity. If you receive a return code 37, you can either change the management class to prevent the large data set from going to ML1, or you could increase the amount of space available in the ML1 pool.

Space Management Cycles

, All of these situations create unnecessary overhead, headaches for users and possible legal issues. Review the SMS constructs to determine if the data has the correct management class assigned to the data sets.

If the data sets have incorrect management classes, the data could be deleted before its useful life span is used, it could be retained for too long, or it could be in the wrong location for use (such as always on ML2 tape every time the data is needed). In terms of DFSMS constructs, storage administrators should determine if the data sets are actually going to the proper storage groups to receive the proper HSM management.

Small data sets are the nemesis of HSM. Changing the management class policies for these data sets to let them “live and die” on primary disk is a good idea. Even when using small data set packing (SDSP) files, the constant migration of small data sets to ML1 and then to ML2 tape only to be expired in a short period of time is useless. The process of compacting files when migrating is minimal when compared to the cost of DASD.

For SDSP data sets, take a closer look at when the data migrates and when it expires. It reduces unnecessary migrations and expires, and the recycle of tape volumes.

With increasing pressures to reduce costs, it is important to manage space efficiently and migrate unnecessary data off of the primary DASD. SRM solutions can use application definitions for these user-defined groupings. For example, storage occupancy should be viewed from the perspective of logical groupings, such as departments or applications. DADSM exits (pre- and post-processing exits as well as user-defined exits) enable SRM solutions to monitor space at allocation and deallocation to provide an accurate evaluation of an application’s storage use versus its quota. User-defined search engines can rapidly locate information required for daily space management. SRM solutions gather historical information on pools, volumes, data sets, and VTOCs and display the results.