RE: Rochester's changing focus/CICS-CCP/iSeries -- MIDRANGE-L

Reeve,

Could happen like you say.  But my uneducated guess is that, currently,
iSeries profits rival those of the mainframe.  And my hope is that IBM will
create a follow-on to the iSeries, and if not (which I think doubtful), some
company would have the sense to develop OS/400 compatible hardware.  IBM
decides if it will kill the iSeries.  But the market, ultimately, determines
whether OS/400 survives or not, IMHO.

BTW, how you mean PRUF?  I see the acronym, but still don't get it.

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 10:36 PM
> To: midrange-l@midrange.com
> Subject: RE: Rochester's changing focus/CICS-CCP/iSeries
>
>
> 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.
>
> _______________________________________________
> 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.
>