× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



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

Follow-Ups:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

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.