You are currently on IBM Systems Media’s archival website. Click here to view our new website.


Exploring Common Software Asset Management Issues

As a performance/capacity analyst, starting when hardware was expensive and software was free, I have seen many changes over the last 24 years regarding the management of the latter. Ever since tiered pricing was introduced, the cost of software has become a major line item in any IT budget, while hardware has become a low cost item. Software Asset Management (SAM) issues exist for all platforms, but for the purposes of this article, Im going to focus on the mainframe, specifically z/OS (or OS/390).

Many companies, including some I have worked for, do not always know:

        Which software packages are installed.

        Which packages are in use.

        Which packages are resource consumers.

        Which packages are unsupported.

        Which packages duplicate function.

        How to manage the cost of their software portfolio.

Installed Packages

There are many tools in the industry that can track software installation and usage, but I have always been a firm believer that the installers and supporters should be aware of what is installed. Unfortunately, I have seen many instances where that is not the case. A simple spreadsheet, Access database, or even a Word document should be enough to track what is installed. Of course, its always easier to track from the beginning than to introduce a process in shops that "just grew".

Used Packages

Many shops have software installed that hasn't been used since mainframes were post-Jurassic. But, the issue is how to determine if they are still in use. I have seen many sites that are afraid to remove something in case some high priority process is using it. There are simple methods for determining this, such as using SMF data for checking out program names and mapping them to products. But, without a trace facility of some sort, you cannot determine the lower level routines that are being called. This issue begs for some sort of tracing package to audit all routines/products that are in use (always available for a fee).

Resource Consumers

This issue is similar to used software. If you don't know what is in use, there is no way you can figure out which packages consume resources. In the past, I have been mandated to determine consumption by packages called from within an online application, such as CICS. I could determine the transaction name, along with all resources. If one transaction called a package based on certain criteria, the answer was/is not directly available from system measurement facility (SMF), resource measurement facility (RMF), or CICS measurement facility (CMF). A finer granularity is required, either by changing the application to report on when the package called, or tracing at a finer level of detail which can become resource intensive in itself.

Unsupported Packages

Many times, a site will be running with software that is no longer supported by the vendor. Most of the time, this may not be an issue, but if there are bugs, it can become a problem. You will find that the vendors response is to upgrade, and if the problem persists then they will examine it. Sometimes they may be willing to investigate, but that is usually on a fee basis. The best practice is to stay current.

Ted MacNeil is a capacity/performance analyst with more than 25 years in the IBM mainframe environment. Ted can be reached at



2019 Solutions Edition

A Comprehensive Online Buyer's Guide to Solutions, Services and Education.


Your Input Needed: IBM Systems Media Reader Survey

Educated for Success

Marist College students benefit from school's partnership with IBM

IBM Systems Magazine Subscribe Box Read Now Link Subscribe Now Link iPad App Google Play Store
Mainframe News Sign Up Today! Past News Letters