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


  • Subject: RE: AS/400
  • From: "Phil" <sublime78ska@xxxxxxxxx>
  • Date: Mon, 30 Jul 2001 11:15:56 -0400
  • Importance: Normal

I'm trying to follow along, and may be mistaken.

Isn't the issue of this thread not the overall capacity of a given iSeries
but the inability, due to CFINT, to shift capacity from batch to interactive
by tuning the system?  My impression is that iSeries owners would prefer
there to be **ONE** CPW, and then leave it up to the owner to tune it for
batch, for interactive, for a mix, etc.

I don't think anyone is saying they want a 840 12-way at a 820 price.
They're saying not to put in any artificial bottlenecks.

This is a big issue for me as well.  Can you reliably pitch a solution, such
as Joe Pluta's, when IBM may decide later that such a solution still
requires the interactive feature?  (Joe's solution may make economic sense
if you're able to upgrade to an iSeries without the interactive feature.
The price of an interactive feature will give you a huge budget to implement
Joe's technique)  But what would happen to you, the employee or consultant,
who successfully pitches the idea only to tell the company they have to
purchase the interactive feature anyway at a later date?  CLM comes to mind.

Phil


> -----Original Message-----
> From: owner-midrange-l@midrange.com
> [mailto:owner-midrange-l@midrange.com]On Behalf Of Buck Calabro
> Sent: Monday, July 30, 2001 10:13 AM
> To: MIDRANGE-L@midrange.com
> Subject: RE: AS/400
>
>
> >     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
> +---
>


_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com

+---
| 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:
Replies:

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.