Software Asset Management (SAM) requires reliable data. P-Tracker is the ultimate z/OS tool to provide the information to clearly answer the usual questions associated with Software Asset Management, for example:
- What applications/products are installed on our systems?
- Who is using them? How often? When?
- Which products are seldom/frequently used?
- Is the current license fee justified given the low utilization?
- Are different users using different versions of the same software product, or, using compatible products?
- How can we consolidate redundant or similar products (inherited from company mergers)? Which products should remain?
- How do load libraries, products, features, components and versions interrelate?
- Who would be impacted by an upgrade?
- Who would be impacted by a replacement (training)?
- Which products/libs/modules is a job using (error analysis)?
- What maintenance levels are deployed?
- What needs to be replicated in our Disaster Recovery Systems?
The need for Software Asset Management is well documented and every site has some process in place to manage its software portfolios. Most sites are content to manage their software contracts and costs by re-justifying the products during an annual review. In reality, the re-justification of the products occurs when maintenance falls due or an interim upgrade cost is thrown at them. The problem is that most sites do not have the capability to take a snapshot assessment of who’s using what, where and how often, so the benefit analysis may not be based on current data.
And of course, it’s not only about the software acquired from various vendors. Libraries of in-house developed applications are constantly growing as well, often to the detriment of performance and requiring the expansion of maintenance. It is estimated that production libraries increase by 5% of defunct software modules each year due to the fact that they must allow for back-out processes (don‘t delete, rename). That means that after five years, approximately 28% of the modules in a library are no longer being used, and yet, they are still contracted for maintenance by in-house or outsourced staff. P-Tracker identifies unused modules.
Time and time again mandates come down saying, “if you don’t need it get rid of it … or get rid of it anyway”. This can be initially caused by a global credit crisis, costs due to upgrades, extras as a result of mergers or acquisitions, or those sought after savings in outsourcing, insourcing, divestitures, down-sizing and consolidations.
Let‘s take the simple case of LPAR licenses where the LPAR size needs to increase due to higher demands of the core application. Concurrently, the product usage of another vendor‘s products running on the same LPAR will remain the same, but the license fees are due to increase. P-Tracker‘s usage stats will empower you, the user, during discussions with the vendor, because now you know precisely how much a product is actually being used. And, in situations where a replacement is the only option on the table, you know in advance which in-house users are affected, and, who needs to be retrained in using the new product.
P-Tracker is a z/OS system enhancement program that records program calls systemwide. Each invocation of a program will be recognized. The module name, along with the name of the load-library from which the module was loaded from, is recorded. Due to its low system load (overhead), P-Tracker is well suited to gather information for z/OS asset management, program inventory and license management. Using P-Tracker, you can easily determine whether specific program families are used. It can confirm the CPUs and sub-systems where programs are used. It identifies the users that need to be notified when you decide to change or drop the software. P-Tracker empowers you to cancel software that is no longer cost-justified.
P-Tracker consists of two basic components. The efficient P-Tracker monitor called Collector that steadily gathers program usage data, and the fast and efficient batch component P-Tracker Inventory that is used to scan the z/OS volumes and to detect libraries and to determine application, vendor and version.
Unlike other products, P-Tracker not only monitors batch program calls, it also offers the option to monitor program invocations under CICS, or other z/OS subsystems. Every dynamic program call is monitored. P-Tracker’s Collector is highly efficient. Which means P-Tracker can be smoothly deployed on all production and test LPARs due to the fact that its system overhead is very low, often it’s not even measurable.
P-Tracker’s Inventory searches the entire site for installed applications. This component has the ability to not only recognize load libraries, but also to identify what the application is and who made it (vendor/maker). It generates a comprehensive overview on libraries and load modules for the entire z/OS system. The reports contain information that is derived from copyright information found in the module text, from SMP/E and from other sources.
You can use the P-Tracker Reporter for selected summary and detail reports, or use your own report generator program to extract the relevant information from P-Tracker files to answer questions like: What program, application or module was never used within the observed time frame?
The output of the Inventory and Collector components can be conveniently loaded into DBMS tables, to allow for user specific SQL queries. In fact, P-Tracker enables you to load the Collector, Inventory and Report data into all types of DBMSs: DB2 z/OS, DB2 LUW, or to any other SQL machine, or to SAS and each other processing environment. Hence the whole world of open source graphics is also available for your SAM needs as standard office software.
Software Asset Management’s primary function is to answer commercial and financial questions, however, the data gathered for SAM can also be used to answer many technical questions as well, such as: Who would be impacted by an upgrade? What libraries is this JOB using (error analysis for lengthy jobs)? What different maintenance levels are deployed? What needs to be replicated in the Disaster Recovery Systems?
Version 2.1 of P-Tracker introduced additional functions: Recording was extended over REXX programs, CLIST execution and PROC usage. Unix System Services are also supported, i. e. execution of program are tracked and access to zFS datasets and directories is recorded.
Benefits & Savings
Immediate savings can be achieved through:
- Avoiding fees on unused or redundant products
- Redirecting manpower in maintaining in-house and external programs which are not used
- Analyzing product usage/redundancy prior to renewal/upgrade negotiations
You likely will also use P-Tracker to:
- Consolidate product machine/system coverage and to optimize sub-capacity licenses
- Prove to management that your budget is fully utilized in order to avoid funding cuts or to justify increases
- Become »audit ready« to avoid costly license compliance violations
- To conduct product inventory verification
- To conduct an audit trail of product use per LPAR