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.