|
Steve, You wrote "To run a real c++ telnet accessed application that is code bloat to some, well abstracted functionality to others will need every bit of the 1000 CPW to service its 15 users." My former employer ran it's business on an old 400. There were roughly 75 users, ran J.D.E. financials and a in-house merchandising system. It was a retail business that operated 50 standalone stores that had their own PC/cash register systems. The 400 polled and processed this store data, along with accumulating data from about 100 lease departments. It worked unattended, basically 24 hours a day. After the company suffered layoffs of 25% of the office, the last 5 years I was there the staff consisted of between 1.5 to 4 developers and a part-time high-school kid to work the equipment and bust reports down over the weekend. There were generally 2 core developers, and myself, to constantly enhance the applications. It was not a "maintenance shop", and the coders also doubled as the help desk. The company was about $200M when I left. The in-house merchandising system (and merchandising is the life-blood of retail) was all tightly-designed RPG and DDS, with a little spaghetti Cobol hanging around since the early 80's. Very maintainable (other than that Cobol) because, if you've never worked in retail, you'd never believe how often and how quickly they can change their business. After the entire shop quit (and those were good times back in '95, when all 4 of us got jobs within 2 weeks) I was consulting back part-time and there were 2 so-called consultants supporting the shop. (I hate to be uncharitable, but one of the users commented that they always saw these consultants working all day long side-by-side... And they also stated it must have been because they shared ONE BRAIN...! ROLFMAO... Whew...!) Anyhoo... it essentially ran with no programming staff for a year, before my Wife started consulting back to them. The company grew from $200M to about $500M or $600M during the 6 years they worked on converting over to a NEC 'nix box. I don't know how many users they supported by that time, maybe 150; about a hundred standalone stores. The 400 merchandising system was designed extremely well (if I do say so myself) and went through few to no changes during that time, and very few hardware upgrades. (Didn't want to put cash money into a system that was "going to be turned off, imminently.") That system certainly was scalable... Shortly prior to converting to the 'nix Merchandising package (stage 1 of turning off the 400, back on Feb 1, 2000) they upgraded their 400 system to a used F95 (IIRC) to handle the extra processing needed to test the conversions, and finally give the users a little more speed. ===> The users thought they were in heaven when the 400 jumped from 20 CPW to 60 CPW. Now, I would NEVER recommend .1 CPW per $1M sales, or .4 CPW per user... But shows it can be done...! Of course, that was about half the CPW of my own tiny little 170 that I'd had for a year, but I never rubbed it in...;-) So I mean no offense, but it can't help but come across that way, I guess...: I think that explains why the idea of a 15-user system needing 1000CPW seems pretty doggone funny, to some of us "old dogs". My current client (actually a sister-company of my former employer) has a more enlightened approach. They stuck with the 400, and just upgraded to an 830, IIRC around 2000 CPW. I don't know how many users.. maybe a couple thousand active jobs. Development staff of maybe a dozen, or so... They have between 50 and 100 stores, but they're much higher volume: sales between $500M and $1B maybe, I don't really know... All that to say... What I'm talking about is not, at all, unusual. At least, not in the retail industry (where they do tend to try to save a buck). jt > -----Original Message----- > From: midrange-l-admin@midrange.com > [mailto:midrange-l-admin@midrange.com]On Behalf Of Steve Richter > Sent: Friday, November 09, 2001 5:58 PM > To: midrange-l@midrange.com > Subject: Re: Fast400 Value to iSeries community is less than zero > > > From: "Chris Rehm" <javadisciple@earthlink.net> > > > > My point is that this is not a CFINT issue, it is a pricing > issue. If IBM > > needs to receive a certain amount of revenue to justify marketing the > > iSeries, it doesn't matter if they use a CPW interactive governor or if > > they manufacture dual CPU systems with variant degrees of power for 5250 > > and non 5250 data streams. > > Chris, > > The high end 270 has a cpw of 1000 and a base price of 30k. Add on the > extras needed to support 15 active telneting users and the price is $50k. > To run a real c++ telnet accessed application that is code bloat to some, > well abstracted functionality to others will need every bit of > the 1000 CPW > to service its 15 users. > > Current ibm pricing for 1000 cpw of interactive processing is what $200k ? > That is way overpriced for the 15 user system that I am describing. The > casualty is the c++ application, the C++ way of coding an application. > > And the foolish part of this is that if the high ungoverned, reasonably > priced cpw is sold by IBM for interactive jobs, then pgms will be > written to > use it ( waste it some will say ), the 200K 820 will support just as many > users as it supports now and IBM will make just as much money as before. > ( more actually since they will sell more systems ) > > -Steve Richter > > > _______________________________________________ > This is the Midrange Systems Technical Discussion (MIDRANGE-L) > mailing list > To post a message email: MIDRANGE-L@midrange.com > To subscribe, unsubscribe, or change list options, > visit: http://lists.midrange.com/cgi-bin/listinfo/midrange-l > or email: MIDRANGE-L-request@midrange.com > Before posting, please take a moment to review the archives > at http://archive.midrange.com/midrange-l. >
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.