|
> And finally, what's to stop IBM from making a change in the next > release of CFINT to close the performance loophole exploited by this > technique? As long as CFINT exists in its present form, the > "governor argument" is not out of date, but a real factor. Can somebody explain the nature of the problem to me? I'm really, really missing it. I worked for 17+ years in a small (2-3 person) MIS department. All software was home-grown. 1) 1974. Applications are card-based, batch processes. "Input" means keypunching and "output" means printed report. Requirements change, and management hear about "terminals." 2) 1978. Applications are slowly re-written to be able to use disk and terminals. Much of the processing is still batch, but "online" data entry and inquiry are making inroads. 3) 1982. All key applications are "online." We open a branch office in another city and need to use our online applications there. We buy modems. We start streamlining the online applications to reduce transmit time. We continue to bring new online apps up. All applications are now disk based. 4) 1988. Modem speeds are faster, but we have more branches. Total workstation I/O has jumped ten-fold. Every application has an online interface, even if it's just a stupid replacement for a keypunch machine. Most applications can print to the branches as well as the home office. That means that all branches can now do their own work without having to send anything back to the home office. I could go on, but this is enough to demonstrate several points. a) Every technology has a governor. Cards can be read only so fast, modems transmit at a fixed speed, disks serve sectors up only so fast, CFINT kicks in at a certain point. All of these limits can be "rectified" by spending money. We were small and cheap, so we didn't spend money, we spent programmer labour instead. b) Requirements mean that applications change even for a small company. It takes time, but a small group of programmers can indeed make wholesale changes to mission critical applications without destroying the business economically. c) Technology forces changes on applications. We didn't move to disk until card readers became prohibitively expensive to maintain. We kept 5250 terminals until 3196s were way cheap. Being a small company, we did everything ourselves. Being small, it took us a long time to get everything done, and yes, by the time we were done the requirements or technology forced changed again. That's business, isn't it? That's why I fail to understand why there's such vitriol about the interactive limit. You paid x amount for x horsepower and you did in fact get that horsepower, right? You don't complain to the modem manufacturer that you paid for a 2400 baud modem and you expect the performance of a 56k modem, do you? When I'm plodding along on my Wintel PC and it takes 25 seconds to open Word 97, I don't complain that my 64meg 266mHz Pentium II should be performing like a 256meg 1gHz Athlon. Am I just too simple to comprehend this? Buck +--- | This is the Midrange System Mailing List! | To submit a new message, send your mail to MIDRANGE-L@midrange.com. | To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com. | To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com. | Questions should be directed to the list owner/operator: david@midrange.com +---
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.