Re: Modernizing applications (was: Explaining single level store to non ipeople)

Nathan,

Hey this is not about technology... You know that for some 20 years I have
been a very strong advocate of OS/400, i5/OS, etc. I'd be the first to
praise the technology, but this is not about technology its about economics
and a huge decline in revenue. It is not even about logic, but rather
marketing and perception.

As far as RPG, it has matured to be a very respectable language today, but
the issue is not the language but rather the fact that it is an IBM
proprietary language that runs only on IBM i today (it ran on the mainframe
for a short time vis a vis RPG II, but no more).

As far as your benchmarks go, compare apples to apples. Benchmark AIX or
Power LINUX (Redhat or SuSe) on the very same Power 6 machine that you are
using as a base for your IBM i testing. I'm sorry but AIX will beat IBM i
every time out.

What OS/400 and its successors did amazingly well was manage thousands of
interactive users and batch jobs with a ton of simple easy to use facilities
that were firsts in the computer industry. It is a wonderful system.

It is simply not selling and is rapidly declining in terms of a) net new
customers who have never used IBM i before, b) upgrades and replacement
machines, and more importantly, c) the number of customers with IBM i or
i5/OS software subscriptions. We are talking major declines here not
trivial numbers.

We are also talking about IBM's Software Group not creating software for the
IBM i OS while it is for AIX, LINUX, zOS, and even Windows. Often all they
must do is run a suite of certification tests and they will not spend the
money...

I cannot ethically tell you how many developers are on any team at IBM and I
will not, but ask other folks how many people are working on the RPG
development team, or the COBOL development team.

We should all be working together to figure out the best ways to salvage IBM
i customer investments in existing RPG or COBOL technology and how to move
within the next 5 to 7 years to a platform neutral environment. Maybe not
off the platform but at least to a platform neutral solution. Nathan, there
will be several steps for most companies in this process and a ton of
business considerations regarding cost and staffing.

Just like you can't throw away your RPG programs, you can't throw away your
people. Most companies can't hire a consulting company or outsource
conversions of migrations. They must modernize gradually over time. The
key is to plan and start now.




On Wed, Aug 19, 2009 at 11:23 AM, Nathan Andelin <nandelin@xxxxxxxxx> wrote:

From: Bob Cancilla
Read details in my blog: http://i-nsider.blogspot.com/

Well Bob, your rhetoric is elevated to a new level of hyperbole against
native IBM i languages and interfaces. Sorry, I won't be following your
advise to adopt platform-neutral languages & interfaces.

Maybe you should approach SAP. They're platform-neutral friendly. I've
been stress testing some of my RPG-based Web applications and comparing the
results to SAP benchmarks, among others.

http://www.sap.com/solutions/benchmark/sd2tier.epx

The benchmarks are similar in that each dialog step generates an HTML /
JavaScript response, and most dialog steps perform create, read, & update
operations on relational DBMS tables.

SAP's benchmark was run most recently against an HP Blade, 2-processor,
8-core, 16-thread, 48-GB RAM, using Microsoft Server 2008 EE & Microsoft SQL
Server 2008.

My most recent Web application benchmark was run against a 2006 ERA Power
5, 1-processor, 1-core, 1-thread, 1-GB RAM, under IBM i.

My comparisons are pretty rough because the applications are not precisely
the same, but it appears that my IBM i server is outputting about 50% more
dynamically generated web pages, and performing more database transactions.

IBM i often beats other platforms in TCO studies, but it appears to me that
in this case, an IBM i platform running native Web applications may be
significantly out-performing a WINTEL alternative that has an initial cost
of about 5-times more.

-Nathan.




--
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.