|
IBM /will/ kill the iSeries when Corporate decides the total Company profits are increased by eliminating the iSeries. Of course, they can raise the price...HEY! They've already done that, right? It's called CFINT. IBM is a hardware development and manufacturing company. They'll never give up the mainframes (still way too much $ there), but once a migration path is in place to get everything off the iSeries, everything else could be pSeries. Wouldn't it be funny if the Compaq/Dell/HP server farms IBM wants to replace with a single iSeries ended up being replaced by an IBM server farm? I don't hear much about the RS/6000 these days...one more product torpedoed. Re S/38: I think IBM realized there would be great improvements in memory and disk technology, since it was being designed in the era of expensive hardware. Question: why would IBM announce a revolutionary system and ignore PRUF (program-request-under-format) software technology? -----Original Message----- From: midrange-l-admin@midrange.com [mailto:midrange-l-admin@midrange.com]On Behalf Of jt Sent: Saturday, November 10, 2001 10:24 PM To: midrange-l@midrange.com Subject: RE: Rochester's changing focus/CICS-CCP/iSeries Reeve, Leif, Paul Interesting. But, Reeve, I don't necessarily agree that "Somebody in IBM has a Post-It with a notation: 'Kill the iSeries'." That would be assuming that IBM has some aversion to profits. And by all indications, the iSeries is racking up profits. They need those to subsidize other products. So I don't think IBM has any aversion to iSeries profits. Also, I think the designers of the 38 projected hardware trends, and decided to trade-off the absolute optimal performance of hardware in order to, like you said, optimizing "developing a program for a complex transaction". Complex transactions are the nature of business, and programmer productivity is still the bottle-neck. I'm not sure where the advantage is supposed to be, in returning to an environment anything resembling CICS. Is complex coding coming back in style...? If you measure the quality of a system by either: a) how many users are supported per dollar of computer, or b) how many interactive programs can a coder turn out per day, c) how many users are supported per dollar of IT payroll... Well.. CICS and that style of programming lost that battle, AFAIK, a while back. May still be in fashion, though. I don't see it's return as anything to herald, Leif, particularly. jt > -----Original Message----- > From: midrange-l-admin@midrange.com > [mailto:midrange-l-admin@midrange.com]On Behalf Of Reeve Fritchman > Sent: Saturday, November 10, 2001 9:51 PM > To: midrange-l@midrange.com > Subject: Rochester's changing focus/CICS-CCP/iSeries > > > I think it's more likely Rochester's changing because of the influx of > younger folks with heavy exposure to PC architecture and little, if any, > exposure to mainframes. > > Back in the 70's, I coded CCP (CICS on the System/3) and rejoiced when the > System/38 was announced (fortunately I avoided the False Prophet of the > System/34). While CICS and CCP are efficient for simple transactions, > developing a program for a complex transaction is much more difficult in > that environment. And those techniques were developed at a time when > hardware and communications resources were extremely slow and extremely > expensive. Yes, they're efficient from a hardware standpoint because they > had to be...back then, CFINT was really hardware: core memory and small, > slow disks. Today CFINT is software. > > The issues today are application flexibility and programmer > skills/resources. Notwithstanding a variety of tools available today, I > don't see application development, particularly when using > PRUF-type coding, > getting any easier and I don't see a lot of iSeries programmers boosting > their professional skills to meet the challenge. Maybe I need more > education and it's likely I need to find the right development > tools. But, > if application redesign is required, the big question is if the > iSeries, or > OS/400, is the right target platform. > > There's no question in my mind that the Karmic wheel is turning on the > iSeries. Somebody in IBM has a Post-It with a notation: "Kill > the iSeries". > Those of us, er, those of /you/, with modern application designs (UI > separated from business logic, etc.) will survive. For everybody > else, Y2K > will seem like a picnic. > > -----Original Message----- > From: midrange-l-admin@midrange.com > [mailto:midrange-l-admin@midrange.com]On > Behalf Of Paul Raulerson > Sent: Saturday, November 10, 2001 8:37 PM > To: midrange-l@midrange.com > Subject: Re: CFINT: I understand it now... > > I don't agree with this chain of thought. In fact, server > applications when > well designed, > are very efficient. Interactive programs can be very efficient, but in an > AS/400 environment, > they are nowhere near as efficient as say, CICS applications. (Even given > that AS/400 > interactive applications are probably more efficient that > anything else out > there except for > old Wang VS programs.... ;) > > I was talking to someone yesterday who mentioned this debate going on, and > after reading the > past 400 or so messages on the subject, I think we are all missing some > crucial point of logic. > I *think* it may be that the people in Rochester are slowing > being replaced > by people from > mainframe backgrounds, who just have a really different train of thought > than pure midrange > people. Batch processing is a different animal entirely on a > mainframe than > an interactive > application. In fact, programs like TSO and CICS on a mainframe are a > single 'batch' > application that just happens to provide interactive services. > > The CFINT thing, well, it sort of makes sense from a mainframe point of > view - and there is > no doubt at all that IBM is in a STRONG push to unify their product line. > > > -Paul > > ----- Original Message ----- > From: "Leif Svalgaard" <leif@leif.org> > To: <midrange-l@midrange.com> > Sent: Saturday, November 10, 2001 12:13 PM > Subject: Re: CFINT: I understand it now... > > > > From: Joe Pluta <joepluta@PlutaBrothers.com> > > > From: Reeve Fritchman > > > It's simple: compared to 5250 applications, server applications > > > are grossly inefficient. > > > > In what way? In fact, a well written server program is far > MORE efficient > > than a traditional monolithic green screen application. > > > > ===> I think you are overstating the point here. They are about the > > same when talking processing efficiency. The server approach is > > far MORE efficient when it comes to maintenance, but that is not > > the issue here. > > > > Let us assume for a moment that everybody went where 'IBM > > wants them to go' and converted everything to run client/server. > > That would remove the CFINT revenue and if as some (e.g. > > Jon Pais) have claimed that revenue is essential to the viability > > of the platform, then the platform will die when everybody is > > doing client/server. The only saving grace is that doing client/ > > server may require a lot more processing power forcing people > > to buy bigger boxes thus enhancing IBM's revenue to offset the > > CFINT tax, > > > > If as you say, server programs are far MORE efficient, people > > can get by with smaller boxes further eroding IBM's revenue > > and thus the viability of the platform. I think I may be missing > > something here, but I can't see what. > > > > > > > > _______________________________________________ > > 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. > > > > > > _______________________________________________ > 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. > > _______________________________________________ > 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. > _______________________________________________ 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.
midrange.com
