Silicon Investor (SI) -- The First Internet Community

STOCKTALK

We've detected that you're using an ad content blocking browser plug-in or feature. Ads provide a critical source of revenue to the continued operation of Silicon Investor. We ask that you disable ad blocking while on Silicon Investor in the best interests of our community. If you are not using an ad blocker but are still receiving this message, make sure your browser's tracking protection is set to the 'standard' level.

Technology Stocks : CheckFree (CKFR) -- Ignore unavailable to you. Want to Upgrade?

To: King David who wrote (1479)	2/3/1998 10:11:00 AM
From: Spots	Respond to of 8545

I'm not ignoring this post, just don't have time to respond right now. Will do so, however. Regards

To: King David who wrote (1479)	2/9/1998 8:51:00 AM
From: Spots	Respond to of 8545

>> what do you think will be replacing them for mainframe applications, or do you think mainframes are going away? Sorry to be so long answering, and this question deserves more time than I can give it now, but I'll make a start. There were three issues raised (no particular order): mainframes, DB2, and COBOL. Mainframe applications are being supplanted by large numbers of cooperating servers arranged in loosely-coupled but coherent networks. Such configurations provide scalability and total size far greater than can be achieved by mainframes, and the servers themselves are rapidly outstripping "mainframes" in raw speed. A case in point: Not a single one of the world's major stock exchanges are run on traditional mainframes. Mainframes don't scale well to support large coherent databases for transaction processing. The reason for this is architecture of mainframe operating systems and databases, and the cost of adding incremental processing power. An important point is that the large-scale transaction processing systems process against a single database image. The database is scaled over many semi-independent and partially redundant servers. Mainframe OS and database software does not support this type of loosely coupled organization, and scaling beyond the capability of a single mainframe processor is expensive, the incremental cost is very high, and there are sever upper limits on the results. Up until a few years ago, large-scale transaction processing systems did not support large-scale queries very effectively. Typically the roles were that front-end transaction systems provided rapid transaction response followed by a more or less batch update of the back-end mainframe database. Business reporting, decision support queries, datamining, etc, were performed on the back end mainframe. If you maintain a database strictly for reporting (I include in this highly sophisticate reporting and DSS queries), then you can PARTITION it across several more-or-less independent mainframes, because the results you want out are statistical in nature. It's feasible and practical to compute sub expressions for each partition of the database then combine the (now vastly reduced) components into a single result. This is just the opposite of transaction processing in which the results are highly specific to a particular set of records in the entire database. As an example, as a corporate manager you want to know performance data for the whole country. It really doesn't matter to you that your queries are processed independently against the separate east coast and west coast databases and the (now vastly reduced) results combined for your performance. However an ATM customer in California making a withdrawal from an account in Maine cares very much that the specific account records are available to process the transaction are available from California. Historically, mainframes have been cost effective in the former environment. Recently, though, (past three years) tranasction processing servers have attained the processing power and the parallel database technology to make cost-effective use of coherent front-end databases for decision support and data mining type queries. It is feasible to merge what have traditionally been front-end "transactional" databases and back end corporate databases, and that is starting to occur. I believe the trend will accelerate. It's difficult for traditional mainframes to compete cost effectively. Well, I must stop due to time. I haven't even touched on COBOL and have mentioned DB2 only tangentially. Maybe another day. I apologize for what appears to be a long list of categorical statements. Many of the things I've stated here require much more discussion to be supported in any reasonable way. And of course there's a good deal of my own opinion mixed in, which always demands support. Also, I have only touched on ONE direction from which the traditional mainframe is under attack, the attack from the "front end" you might say. There are other inroads being made on the mainframe market, such as from specialized database processors (Oracle, Sybase) that can provide highly cost-effective query/reporting/data mining processing as well (attack from the back end), or such as the increase in consumer power that moves records OUT of corporate databases and onto consumer desktops (flank attack). All of these things make for major discussions in their own right.