Re: Why IBMi research effort

I believe this is a case of a little bit of A and a little bit of B,
without a way to familiarize young programmers and future decision
makers with the platform, there is no way they wont say "IBM i? wasn't
that that old green screen stuff?" and of course the bean counters
will see 10 as the initial turnkey cost but wont see that the
bladecenter will have 1 as the initial cost but recurring costs...

Also i understand why, for IBM, an 820 is still a viable machine. Less
than a year ago our company found and brokered a sale of an 820 for a
company, they had a 720 and really needed an upgrade, but the erp they
used was so old that they could not upgrade in OS level, so it had to
be at v4r5. For that client the 8k you mention would not be expensive
at all. So if IBM started giving away licences for old hardware they
would end up losing some sales, at least in countries where 1dollar =
a lot of local money. I would love to be in a company that uses IBM i,
i have lots of playing around with the hardware but, lacking licenses
for most of them, i cant exactly put anything production on them. On
the other hand i have a bladecenter full of vms with various
linux/windows and in a few days AIX (got an old power blade)....

Best Regards

On Sat, Sep 1, 2012 at 11:51 AM, Joe Pluta <lists@xxxxxxxxxxxxxxxxx> wrote:

I'm seeing more and more of that in the field, Larry. Back in the day,
you could conceivably replace a smaller AS/400 or iSeries with much
cheaper hardware and get comparable performance. I'm not saying it was
a good decision, but it was at least understandable. But today even the
smaller IBM i boxes have a price/performance ratio that makes it nearly
impossible to match with commodity hardware.

I'm dealing with a similar situation where just a tiny piece of the LOB
is being replaced a Unix/Oracle combination. The requirements? Seven
virtual servers on two physical boxes to provide redundancy that isn't
even at the reliability level of the original box. Two servers for
Oracle, two servers for the application, two servers for the
communications infrastructure, and a 7th server for MQ Series to
communicate with the host. Note that with all that we STILL have a
single point of failure in the MQ Series server.

And this, by the way, doesn't include the additional hardware and
software costs for a separate QA machine, because you don't want to roll
changes out to your production server.

And with all this, the system is exceedingly fragile. Oracle just got
back to us because the (redundant) production server went belly up with
zero load. (Luckily, we're only in setup phase not actual production.)
They found a bug in their failover code. It took nearly a week to
isolate it.

If ever the phrase penny wise and pound foolish applied, this would be it.

Joe

Mark,

What seems to be missing through the thread here is how few servers
you need when running POWER especially with IBM i. Applications
integrate so much more easily when running on the same platform than
when there is a little here and a little there. Recently one of my
customers was told by a vendor that a piece of their application which
formerly ran right next to their primary LOB application was now going
to be running on two windows servers and an AIX server. It would now
need to extract data from their LOB app, move mash process manipulate
exchange convert translate and finally return it to the LOB app in the
form where it could be imported. The argument was that those three
additional pieces were each 'Best of Breed' and had been integrated to
provide the best possible solution. Even assuming that's a true
statement how much better is it than the previous solution and how much
money will that either save for the customer or how much additional
sales will it enable? Will it pay for the three servers? Three operating
system licenses? A copy of Oracle? Far more complicated backups?
Increased power and cooling required? And the 800 lb gorilla, managing
and troubleshooting of this far more complicated solution. Tightly
integrated the original application was just 'there' and worked. Now
when something doesn't work it's hunting around for what's broken, what
server has an error, low disk space, a service that didn't start, a
thousand things. Worse neither of the two new operating systems were
ones the customer had skills with so even more cost is incurred for
those skills.

--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.