Aaron Walker wrote:
Retorts from the peanut gallery:
http://linux.slashdot.org/linux/07/01/05/0538224.shtml
Year of the Mainframe? Not Quite, Say Linux Grids

This reference describes their prior system as "an aging mainframe", which suggests that their management had made a [questionable] decision several years prior to stop maintaining their mainframe system.

Considering that every mainframe processor generational change that has occurred in the last decade or so (S-390, ES/9000, 9672, z900, z990, z9) has resulted in significant improvements in processor hardware cost/performance, that similar improvements have been occurring in mainframe DASD, and that upgrades to the operating system have been required to exploit and take advantages of newer hardware and some of the changes in software licensing, I can certainly believe they may have saved a bundle by moving from old technology to current generation Linux boxen. But, if they moved from a several-generation-old mainframe hardware and Operating System to current mainframe technology, they would also have saved a bundle and improved performance as well.

There is not enough information given to know all the facts, but there is a hint of a management predilection for alternative platforms, and perhaps the use of mainframe neglect to make their prophecy self-fulfilling. Some of the other articles on the Internet (search for r.l. polk mainframe) about the conversion indicate that as early as 2004 they had tried twice unsuccessfully to move off the mainframe. It sounds like their real problem was that they hadn't done any major redesign of their main data-base aggregation processing for 30 years and that they were still using batch processing with many manual steps for maintaining a huge database, with only two update cycles per month. There is no mention of a database product on the mainframe, but if the software design was that old, it probably would not have been anything with the current sophistication and tuning capabilities of DB2.

They were predicting insufficient resources to continue running their existing processes and desperately needed a process redesign and database redesign to remove manual steps from the process and handle real time updates -- and chose to do this redesign and reimplementation on another platform. It's not clear whether they really made any serious attempt to evaluate the possibilities or costs of re-implementation on the mainframe. The cost savings and performance gains of going to the Linux grid appear to be a comparison of the new completely redesigned, interactive application, including personnel savings from eliminating the manual steps, compared with performance and costs associated with the old batch and manual process on the mainframe - not even an apples to oranges comparison. For their $20M re-deployment cost, I suspect a successful re-implementation on the mainframe would have been possible as well.
--
Joel C. Ewing, Fort Smith, AR        [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