|
Hi, Let me reposition this discussion a bit. The good thing is that the iSeries-AS/400-System/38 is an awesome platform for interactive programming in a green screen environment. Now, that's both good news and bad news. IBM wants everybody to go client/server, and despite what they say have yet to deliver a good vehicle for doing this. (Yes, Toronto, I understand, whatever it is that you are delivering is the "right" vehicle for this, and that's the answer you have been consistently been providing for the last nine years. BTW, Toronto, I still don't believe you!) Having been unable to lure iSeries-AS/400-System/38 customers to client/server with the carrot approach, Rochester adopted the stick approach: charge a @#$%ing ridiculous amount for interactive, and that will get people to go to client/server. *WRONG. It is pushing much users to reduce interactive. Here's a good example. I have a client in the financial services industry. They were using the 400 (or whatever you want to call it) to print batch reports, and have users enter data from that. They searched for the most cost effective platform they could provide for interactive programming. This assumed that they threw out their 400 to make the process interactive and faster, and what did they pick? The 400! This application cost about $1M to write, and the ROI is FOUR days! Al Al Barsa, Jr. Barsa Consulting Group, LLC 400>390 914-251-1234 914-251-9406 fax http://www.barsaconsulting.com http://www.taatool.com "Phil" <sublime78ska@yahoo To: <MIDRANGE-L@midrange.com> .com> cc: Sent by: Subject: RE: AS/400 owner-midrange-l@mi drange.com 07/30/01 11:15 AM Please respond to MIDRANGE-L 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 +--- +--- | 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.
midrange.com
