Realities of z/OS SRM Tools – Part 1 continued…
This ensures it can correctly obtain the information needed; for example, if CA1 Tape is active, it might need to know the name of the CA1 Tape Catalog.
In most cases, this information is provided via startup parameters which the user customizes on each system where the engine is running.
This parameter customization substantially increases the installation time. Also, if the environment ever changes, it adds another level of complication, whereby it must be ensured that the SRM tool is always modified accordingly.
An ideal SRM tool should be able to automatically detect the resources it requires, thereby reducing the impact of environmental changes and customization timelines.
Software Versioning Considerations
Having gone through the initial workload of installing the SRM product, at some point, a new version will be available consisting of Host and/or GUI changes. What, however, if the new GUI cannot talk to old versions of the Host component?
In a large Enterprise, the opportunity to upgrade the Host component on all the z/OS systems at the same time does not exist, and a staged upgrade process will occur.
Having differing Host Levels might mean the GUI can only talk to certain hosts. In those cases, the solution is to have multiple GUI versions, each talking to the hosts whose software version they support.
For an SRM tool to be usable and manageable, it must allow for disparate host software versions and simply ignore features if they are not available.
Resource Consumption Considerations
Most z/OS SRM solutions will, at some point, submit background processes to scan the environment and create databases of information about the environment which the GUI can then analyze.
These processes are infamous for eating up all the available resources when they run, often to the detriment of other processes.
The tools usually provide the ability to reduce the frequency at which these processes run, but then the accuracy of the information is reduced because the data is aged and often bears no relevance to the environment at the time the query was run.
The best solution is resource efficient data collection processes and giving the user the ability to clearly and quickly specify whether to use historic information or current information, i.e., a dynamic scan of the environment.
Go to 10 different z/OS sites, and it is likely that they have the same requirements for Storage audits, Storage reporting, etc. Sadly, z/OS SRM tools don’t seem to be delivered with these requirements. The catalogs need backing up, the catalogs need auditing, admins need to know who is using the most space, and they need to audit the DFSMShsm environment. So why does the SRM tool not do this automatically? In the end, someone needs to customize each and every LPAR where the SRM tool is running to ensure the tool is performing these tasks.
There are two issues here: the first is that it needs to be done at all, and the second is that it must be done on each LPAR/Sysplex individually, rather than providing the option to select a process to be run daily on all Systems/Sysplexes.
This customization is not a simple task; it is a major project in itself. Very often, the time and expense of this is not factored into the overall costs of the SRM tool.
An ideal SRM tool will remove the need for lengthy and sometimes redundant customization projects. It will give the user the power to define things once and apply it across the enterprise.
Part 1 Conclusion
Evaluating SRM tools can be an exhausting task. The best tool becomes an asset to the business by helping streamline processes, ensure consistency, and proactively protect business continuity and resiliency.
The second part of this article will take a closer look at ways an SRM tool should help alleviate headaches for users and improve their productivity through some essential usability characteristics.
The author is a seasoned storage management professional, getting his roots as a systems programmer and storage administrator. He has been in the industry for over 30 years and has broad expertise with IBM mainframe storage. He is currently a Senior Technical Advisor for Universal Data Manager (UDM) with Dino-Software Corporation.
Learn how UDM simplifies z/OS storage management…keep it simple!
• Easy installation – no distributed servers
• Instant Enterprise View & management
• Effortlessly create policy-based automation & alerts
• Explorer Interfaces – Command, JCL, Reporting, Automation, Monitoring
• Unique architecture preserves CPU, storage, and human resources
• Leverages existing z/OS security architecture
Dino-Software Corporation develops enterprise-wide solutions for the management, analysis, protection, and repair of complex z/OS mainframe environments. Dino-Software has long been acknowledged for its superiority in ICF catalog management and technical support, helping organizations ensure their business-critical assets remain online and recoverable in a disaster. Learn more about Dino-Software and its z/OS mainframe storage solutions at https://www.dino-software.com.