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

Paul,

I wasn't aware of that about Modern CICS.  Interesting.

jt


> -----Original Message-----
> From: midrange-l-admin@midrange.com
> [mailto:midrange-l-admin@midrange.com]On Behalf Of Paul Raulerson
> Sent: Saturday, November 10, 2001 10:18 PM
> To: midrange-l@midrange.com
> Subject: Re: Rochester's changing focus/CICS-CCP/iSeries
>
>
> Won't happen - but the merging of the product lines will be rough indeed.
>
> BTW: Modern CICS is much easier to code, in assembler, COBOL, or
> even Fortran,
> than the original "macro" level CICS stuff was. It also leads
> very quickly to good program
> design and segmentation. The AS/400 gets around a lot of that
> with display formats and
> external file definitions and so forth.
>
> -Paul
>
> ----- Original Message -----
> From: "Reeve Fritchman" <reeve@ltl400.com>
> To: <midrange-l@midrange.com>
> Sent: Saturday, November 10, 2001 8:51 PM
> 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.
>