longpelaexpertise.com.au/ezine/RemoveSoftware.php?ezinemode=printfriend

LongEx Mainframe Quarterly - November 2011

management: How to Get Rid of that Mainframe Software Product

The invoice arrives as it always does, working its way through the normal channels until it lands on your desk. You give it a quick review, and as you send the email approving payment, you think to yourself "I wish I could get rid of this software." And you're not alone.

You may have other software that does the same thing. Or maybe the software is only used by a couple of people. But the chances are that you want it to go for one reason: money. Mainframe software is constantly the largest cost of running a mainframe. With pressures to reduce costs, mainframe software is an inviting target for easy savings. But it's rarely easy.

There are three categories of mainframe software products:
  • No longer needed.
  • Easily replaced.
  • Replaced with difficulty.

Software That is No Longer Needed

Many mainframe sites continue to use software that is really no longer needed. z/OS and associated software and hardware has come a long way in the last decade. Third party software that used to fill a function is sometimes no longer required. For example, z/OS monitors are no longer needed to add a module to the APF or LPA lists. Similarly, software to compress 3270 data streams over small network lines is rarely needed for today's network connections. In these cases, removing the software can be achieved with little effort.

In some cases, moving to z/OS facilities may take some technical expertise. For example, care must be taken when moving from CA-PMO or CA-QuickFetch to z/OS LLA/VLF. Moving between sorting products (CA-Sort, Syncsort and DFSORT) should not be done without careful planning and preparation.

Other sites will have expensive software that is used only by a handful of users. In fact, there are many that have software that is no longer required by anyone. z/OS systems programmers can track who uses a module, and how often. Tivoli License Compliance Manager can provide more details about software product use.

In some cases, only a very small part of the software may be used. In this case it may be possible to find a cheaper solution

Freeware or custom-written software may also be an alternative for software products. For example, users needing to browse VSAM files in ISPF do not need to buy IBM FileManager or Compuware FileAid. Gilbert St-Flour's BR utility does this for free.

Software That is Easily Replaced

Some software products are easily replaced. For example it is easy to convert between IBM RMF and BMC CMF. Swapping between software monitors is usually straightforward, as few systems or applications will rely on their features. So moving between ASG TMON, BMC MAINVIEW, CA SYSVIEW and IBM Tivoli Omegamon is easily achieved. Moving between Compuware STROBE, Macro 4 FreezeFrame and IBM APA is another example.

Some software products will also provide a migration path, with migration tools. For example, BMC CONTROL-M provides utilities to migrate from most other job scheduling packages, including Tivoli Workload Scheduler, CA-7 and ASG ZEKE.

Software replacement may not just be on the mainframe. For example replacing mainframe-based software development platforms with Eclipse-like tools may be a smart option.

Difficult to Replace

Unfortunately, the majority of mainframe software falls into this final category: difficult to replace. For example, to swap between security products such as CA-Top Secret, CA-ACF2 and IBM RACF is a very large task.

But even in these cases, there are options. Many software vendors offer services to assist in migrating to their product. For example, ISI offers software and services to migrate from CA-Datacom to DB2.

IBM goes one step further. It has a Software Migration Project Office. According to their website, their Tivoli Migration Team have performed more than 3500 systems management migrations.

Migration Issues

Any software removal/replacement project should not be done lightly. Issues to think of include:

  • Training - training support staff and users in the replacement software product.
  • History -migrating archival/historical data to the new product.
  • Use -understanding all users of a product, and what they require. Often users may use a product in ways that are unexpected.
  • Requisite - a software product may be needed by another. For example the SMF processing software products MXG and CA-MICS require SAS, and Tivoli Decision Support requires DB2.
  • Disaster Recovery - any Disaster Recovery plans need to be updated and tested for the new products. DR sites may need additional software license codes.

Removing a software product is never something to be done lightly. However there are always options available. In some cases it may be easier than you think.


David Stephens