Prof. Appleby's Blog

In my previous post for project managers working on mainframe upgrade projects, I recommended that you have your vendor (IBM, Mainline Information Systems, etc.) provide you with a list of your current mainframe configuration and the proposed mainframe configuration so you can:

• Review the current and the new configurations for accuracy
• Question any apparent discrepancies
• See what features are being “carried forward” to the new mainframe and verify that they should be carried forward and that the required quantities are correct
• See what features are not being “carried forward” and verify that this is part of the plan, not an omission
• See what new features have been added (i.e., features on the proposed mainframe that are not part of the current mainframe)

The next step I suggest is to check on (or review again) possible price changes for your software.  IBM or Mainline can provide you with an estimate of your IBM software charges on the new machine.  This is done using a tool called the Workload Pricer (WLP).

The best approach is to have your vendor pull the latest software inventory for your machine and input the data into WLP.  Then, your vendor will model that software against your current machine.  The results should match what you are paying today.  It’s important to get this step right, because you are creating a baseline against which to compare other options.

Once the baseline is right, then the vendor can add a new machine to the model and tell WLP to estimate software costs on that machine.  (You can also model various hardware alternatives that way, too, which probably has already been done during the marketing phase).

Three key things to keep in mind:

1. You will have some products that carry a monthly license charge (usually called “mlc” products).
2. You may have some products that have a one time charge (OTC) plus an annual subscription and service charge (S&S).
3. You may have third party products that will also be affected by an upgrade.

The WLP model will estimate your IBM MLC and OTC/S&S charges for the new mainframe.  It will not estimate third party prices; you will need to contact those vendors directly.

From a PM standpoint, you mainly want to know that you have a complete list of the software products running on the machine and that potential price changes have been explored.

One of the great things about an IBM mainframe upgrade is the “technology dividend” which basically says that a new machine of comparable power will have lower maintenance and software costs than the machine it is replacing.  Combined with a year’s warranty on the new machine, these dollar savings go a long way toward financially justifying the purchase of the most current technology.

Quick recap – at this point:

• You know all of the hardware features on your current and proposed machines and you’ve reviewed them for accuracy
• You know all of the software running on your current machine, along with price estimates for how the upgrade may increase or decrease your software costs

The key is risk mitigation – avoid any surprises.

If you are a project manager leading a mainframe project, I’d like to share with you some general action items to include in your project plan.  My first suggestion is that you request from your mainframe vendor a current list of the features on your mainframe today and review the list together.  This report is sometimes called a detail report.

This report will show you the machine type you have, the model, the capacity setting, the capacity marker, the amount of memory, and how many and what types of adapter cards are installed.

It’s a good starting place to see where you are today.

You can learn some helpful things from this report – things that might prompt follow-on questions and potentially save you some money.

For example, you might see that you have many more ESCON adapters than you need today.  At one time, ESCON was leading edge technology, replacing the slow, bulky parallel channels.  But ESCON is now old (and fading) technology and many mainframe users have lots of unused ESCON ports because they have either eliminated older ESCON-attached I/O devices or migrated from ESCON to the far superior FICON technology.

So, for example, you might discover that you have 48 ESCON ports, but you’re only using 12 of them.

When your vendor proposes a new mainframe, they may initially assume that you still need all 48 ESCON ports.  The number of ports you need drives the number of cards you get.  ESCON ports are “enabled” in groups of four ports.  The cards themselves have sixteen ports, of which one is a spare.  And, the System z will always have at least two cards for the sake of redundancy and availability.

Let’s explore this a bit.  If I have 48 ESCON ports available for use, then I’ll have four 16-port ESCON cards.  Why not three cards instead of four?  After all 3 x 16=48.  Because one port on each card is reserved as a spare.  So, three cards give me 45 available ports.  To get 48 ports, then, I need four cards.

Four cards actually give you 60 ports (ignoring spares), but ports are “enabled” (think $$$) in groups of four.  Doing that gives you better granularity, so you don’t have to buy many more ports than you need.  So you paid for 48 ports.

If I now only require 12 ESCON ports, then I only need two ESCON cards (remember, that’s the minimum for the sake of redundancy).  So I can go from four ESCON cards down to two ESCON cards.  That frees up two slots for other uses – OSA or FICON, for example – so, even though I already paid for 48 ESCON, I may save myself some money down the road (or even immediately) by freeing up a couple of slots for use by other cards, thus potentially avoiding having to purchase another I/O cage or drawer.

As you go through your detail report, you may see other things you can eliminate: older OSA technology (e.g., Fast Ethernet), etc.

One word of caution: In the case of ESCON, be sure that you get accurate data as to what’s being used and what isn’t.  You don’t want to scale back and then discover that you actually need more than you thought.  Check the adapters to see if a cable is plugged in.  If there is a cable, but you think it’s not connected to anything on the other end, you can always unplug it (within your change management guidelines) to verify that it’s no longer in use.

But my primary suggestion is simply to get the detail report and look it over.  If it prompts questions, ask them.  If there’s something on the current machine that’s missing from the newly proposed machine, ask why.  Check the features and check the quantities on everything, just to be sure.

Continuing with our thread on mainframes for project managers:

In addition to the general purpose (GP) engines on the mainframe, you can also add specialty engines.  Specialty engines, as the name implies, are intended to provide very specific processing capabilities in contrast to the generalized processing capabilities of the general purpose engines.

There are four main types of specialty engines: IFLs, zIIPs, zAAPs, and ICFs.

IFL stands for Integrated Facility for Linux. With an IFL, you can run either native zLinux or zLinux under zVM.  You could also run them in a GP engine, but adding a GP tends to raise your overall software costs on a mainframe, whereas running them in an IFL does not.  For that reason, adding IFLs is an effective strategy for reducing the total cost of ownership (TCO) on a mainframe.

zIIP engines support certain DB2 functions.  A zIIP then becomes a way of offloading some workload from the GP engines – another effective strategy for TCO.

zAAP engines support Java.  Like the zIIP, the zAAP allows certain workloads to be offloaded from the GP engines.  (Note: Some zAAP functionality is now available in the zIIP, so you may hear the phrase “zAAP on zIIP.”   It’s possible that a zIIP may handle both your zIIP and zAAP eligible workloads.

ICF stands for Integrated Coupling Facility.  ICFs run something called CFCC (Coupling Facility Control Code) and are used in what is known as a parallel sysplex environment.  Think of the ICF as a key element in a design that requires data sharing.

There are two noteworthy things at work here:

1. As you increase the number and speed of GP engines, the “rated capacity” on your mainframe increases, resulting in higher software costs.  For that reason, using specialty engines (which don’t count toward “rated capacity” ) to offload the GP engines may help you reduce your GP capacity requirements.   For example, suppose my aggregate workload would require four GP engines – but, if I offload some of that workload to specialty engines, then perhaps I only need three GP engines.  That ultimately translates into software savings.

2. Note also that the specialty engines are (to a great extent) intended for DB2, Java, and Linux workloads.  You cannot run zOS or zVSE in a specialty engine.  You can run zVM in an IFL, but it’s there to provide virtualization capability for zLinux (RedHat or SUSE).  The strengths of the mainframe (resiliency, reliability, I/O bandwidth, to name a few) can be matched to new workloads – not just to the traditional mainframe operating systems.