I'm going to quote a couple different people for some comments...

>Linux may be "free", but try and get IBM to support their software on
>the "free" Linux.  IBM's software lists SUSE, United Linux, or RH as
>requirments, all of these charge you per ILF for the right to run their
>"free" software on your box.   IIRC SUSE is $18K per processor.

Not exactly. The software is indeed free -- it's open source, after all,
governed by the GPL. Unless you're installing non-GPL software you are
expressly permitted to install as much Linux as you want on as many
processors as you want. SuSE, Red Hat, IBM, and others will charge you for
a *support contract*.  You are perfectly free to choose your support
provider.  Or none at all, though I wouldn't recommend that in an
enterprise environment.

>IIRC the $25,000 for z/VM is per month.  I'm fairly sure we are paying
>$300,000 per year for it.

Probably not, unless you're *really* big. z/VM is now priced per engine
with a declining price curve (e.g. you pay less for your 10th engine than
you do for your 2nd). The first engine, new license, is indeed
approximately $25,000. (For some reason $22,500 sticks in my brain, but
close enough.) The per-engine price does not vary according to the size of
the engine, so if you move from a 9672 IFL to a z890 or System z9 IFL,
enjoy the extra juice at no extra charge.  And it's IPLA not MLC, with an
annual subscription charge only if you want new versions and support. (Most
people do.) You only have to license the engines that z/VM touches (CPs
and/or IFLs) at peak, so if you use some IFLs only for non-z/VM Linux LPARs
then they don't count.  (Note that if you're running "traditional" z/VM
apps then you have to run those on CPs.  You are only eligible to run z/VM
on IFLs if z/VM is solely used to support Linux.  z/VM itself does not
change price, however.)

In other words, it's a bargain for most customers when compared to what it
can do to reduce costs.

>The price of a ZAP is also $125,000.  So, in theory, if you are already
>running WAS on z/OS, running Java under CICS, or plan to run Java under
>CICS, a ZAP makes more sense and is less expensive that setting up a
>z/VM and zLinux farm.  You get a processor for the Java stuff and you do
>not increase your z/OS software costs.

I would tend to agree with this, but of course your mileage may vary.
Frankly I think just about every mainframe shop should be doing both (zAAPs
for WebSphere z/OS and other z/OS Java, and IFLs for Linux).  Otherwise
they're wasting money elsewhere in the IT organization, quite simply.

>We tried WebSphere on the mainframe and it is too slow and
>complex.. WebSphere on the distributed platform is like IMS on the
Mainframe
>: Too many pieces that makes it complex because IBM build all these extra
>add-on's/shells and then the mainframe shops go into their mode of many
>different environments ex. Development, Test, Staging, Production. Causing
>one huge piece of burocracy with Change Control etc.

So you're suggesting you shouldn't do any change control? :-)

I would point to my earlier comments on this subject. The mainframe folks
need to make sure that developers have largely unfettered access to a
WebSphere LPAR (or in the case of Linux, WebSphere Linux guests) in order
to get their jobs done during development and initial testing. But if it's
a remotely important application, yes, change control procedures are
important. Otherwise it's not an important application, is it?

ComAir's crew scheduling system (apparently) didn't go through a proper
change control procedure. It failed. ComAir's CEO was fired. Certain apps
need to follow appropriate change control procedures. Yeah, it's a pain in
the butt, but it's better than CEOs losing their jobs.  I think. :-)

As far as "too slow and complex," zAAPs (and IFLs) neatly address the
former -- the cost studies prove it -- and, though it can be complex, it
keeps getting easier. It's one of the "big three" enterprise transaction
managers (the others being CICS and IMS). Once you get WebSphere in place,
though, you've got a key piece of infrastructure that you can keep
leveraging over and over, like you do CICS regions. (Adding more WebSphere
servants is no big deal.)

>And Big Blue refuses to subject its mainframes to the industry-standard
>TPC-C....
>My Comment : Maybe it's the only way IBM can hide the cost per transaction
?

Quite the opposite, actually.  IBM would love comparisons based on costs
per transaction.  That's not what TPC-C is about, though.  In fact, vendors
go out of their way to make sure their TPC-C figures are as far removed
from total costs as possible.  And they certainly don't measure anything
having to do with qualities of service.

It's like drag racing a VM Golf and a tractor trailer. The VW Golf will
probably win the drag race. Except there's a problem: the business
objective is to restock Wal-Mart. Still astonishes me that some IT people
can't figure out economies of scale, because you can bet Wal-Mart's
logistics people understand it.

Arcati thinks that, once you hit a minimum economy of scale, mainframes
have a much lower cost per transaction than other platforms.  They also
think that cost advantage is *widening* over time (because labor keeps
getting more expensive).  I think they're exactly right.

It's amazing, though, how there are still organizations that don't
understand their total costs.  But that's OK, because one of two things
will happen if they aren't efficient: they'll go out of business (due to
smarter competition) or they'll outsource their IT to someone who can
achieve those efficiences.

>"We continue to believe that the mainframe is a declining hardware
>platform, limited by applications availability and lack of competitive
>hardware offerings," "We estimate that in fiscal 2002, about a quarter of
>IBM's revenues and 45 percent of its operating profits were somehow linked
>to the mainframe,"

Surprise! :-)  Kudos to the fine people in Poughkeepsie who keep widening
the lead.

>My Comment: My experience is shrinking quantity of mainframe computer
>center's caused by consolidation, outsourcing, conversions etc. which is
>causing shrinking profits for the Mainframe Software Companies and there
is
>still a lot of pressure on the CIO to shrink the IT budget.

What shrinking profits for mainframe software companies?  BMC, to pick an
example, just reported higher profits and higher sales -- and did so
despite new and fierce competition.  IBM-MAIN carried the news.

Mainframe software is large percentage of total mainframe costs, to be
sure. But have you priced distributed software lately? Whoa! Expensive! And
the mainframe software vendors are much more sensible in their pricing
policies which are increasingly based on workload. It's not perfect yet,
but it's much more fair.  Distributed software pricing simply is not. And
Windows is a completely closed and proprietary platform, with tremendous
vendor lock-in and diminished competition, while the mainframe has
affordable and open Linux products that scale up and down.

By the way, you probably already own tons of Linux on zSeries software
licenses.  Most vendors -- IBM and Oracle, to pick two examples -- have
sold you cross-platform licenses.  That means you can take that dual
processor Windows server running Oracle (for example), retire it, and move
those Oracle licenses up to a pair of IFLs.  No charge.  You can't do squat
with one Oracle server except maybe one level of testing or development.
With two IFLs?  Wow, you're doing all kinds of real work: development,
test, QA, production, and lots of it, all at once, in any mix at any time,
super reliably.  And you can "procure" an Oracle IFL server in about 60
seconds.

Honestly, I think CFOs would understand this. :-)

- - - - -
Timothy F. Sipples
Consulting Enterprise Software Architect
IBM Americas zSeries/z9 Software
Phone: +1 312 529 1612
E-Mail: [EMAIL PROTECTED]
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Reply via email to