RATE THIS ANSWER
0
Click to Vote:
- 0
0
You've raised a really good question, particularly for sites with sub-capacity licensing (meaning extra CPU seconds can raise software licensing costs across the board).
I'm unfamiliar with the these three products. Mind you, I don't think I've ever seen CPU overhead data published on the web.
However for many monitoring products, there is cpu usage an other performance data available. You just need to ask your software provider (and don't be afraid to be persistent).
When you get the stats, take some time to look at the fine print - there's no doubt that they'll all want to present their product in the best light.
Hope this helps.
For the benefit of any other Users going through this process I include here the criteria we established. Note that this is purely for the IBM ZoS environment.
DASD Quota Software Evaluation
Core requirements and capabilities have been identified as:
The ability to Monitor and Control DASD capacity usage in real-time, for individual Programmes, projects or other areas, i.e a set and sub-set structure controllable at each level.
Each set or sub-set should allow for pre-arranged or default capacity values to be assigned, and these must be dynamically adjustable.
An ability to pre-warn any ‘account’ Users, if approaching their capacity limit.
Ability for account names to be dynamically generated based on either literals or generic variables such as dataset names (including part names or combined parts), RACF Users or Groups, program, job or DDnames, storage group name masks, volume masks, or SMS classes for example, or a combination of both.
Allow de-centralised control of ‘accounts’ controllable via RACF or similar mechanism.
For example, a Programme may be assigned capacity over which it may control usage by sub-projects to the programme.
Real-time Reporting of accounts and sub-accounts should be available, with access to these controllable via RACF or similar mechanism.
Ability to build a historical view of each account or sub-account usage, with reporting of selected periods as required.
The ‘accounts’ in the database should be re-nameable without rebuilding the entire database.
The database build process should have some sort of restart capability to avoid excessively long DASD scanning processes.
There should be a backup or ‘shadow’ database maintained concurrently to provide resilience to failure and avoid a database rebuild.
The database should be a non-proprietary access method and allow standard utility backups etc.
The product should not present a significant overhead to allocation during normal operation or during initial database build.
Any product license should be Enterprise Wide to allow it to be used on any Sysplex..
The ability to associate DFHSM Migrated data as part of the main accounts or sub-accounts, if possible.
An ISPF panel or GUI based interface to the product for set up, maintenance and reporting, with caapbility to export to spreadsheets.
Support for product Install with possible overview presentation of the product capabilities.
Evaluation Approach:
• Test installation and maintenance.
• Verify the basic functionality and operability of the product meets the defined requirements including database build and volume scanning functions.
• Test recoverability and resilience to failure.
• Define rule sets for accounts as expected for productioned running and run test allocations to confirm expected results.
• Test Reporting functions including historical data capture.
• Test securability of the product and its database.
• Have Capacity or Performance teams measure operational overheads.
• Carry out performance profiling in a high use environment.
Conclusion of Testing and Decision Point
Following testing of the various products there would be an evaluation of the capabilities of each product vs the cost of initial purchase and ongoing maintenance costs. A projection of likely savings achieved through introduction of the product would be included in the conclusions to provide a balance to the figures. Savings will be mainly from allowing greater sharing of DASD resources, more accurate and timely reporting including projected vs actuals, control over ‘rogue, unauthorised allocation’ that may affect multiple testing environments and advance warning of capacity issues to prevent down time for recovery etc.
Any supplementary functions or products included in the package would also be considered and balanced against the other factors. It is accepted that some functionality could be foregone if this results in a significantly reduced cost and this may ultimately affect the choice of vendor.
Last Answered:
Jun 17 2009 9:35 AM GMT by PeteW 
65 pts.
Latest Contributors: Dzs 235 pts.
