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

Paul,

I wear my ignorance on my sleeve sometimes...;-)  I had thought the
mainframe was all hardware advances, because it gets about as much exposure
in the press as the iSeries does.  I shoulda known...  Do you if there are
many on iSeries, that also understand the modern mainframe...?  I always
figured they were oil and water.

Thanks for the education...

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:40 PM
> To: midrange-l@midrange.com
> Subject: Re: Rochester's changing focus/CICS-CCP/iSeries
>
>
> Werll, by modern I meant within the past 5 years or so. ;) CICS
> is really 'TX Server" nowadays,
> and does not even support macro level calls. Within COBOL, it
> supports just about everything
> COBOL does, including string/unstring (though everyone tends to
> use referential modification
> these days...) calls, and accepts, and and so forth. Writing to
> sequential files is still a bit of a bother,
> since you have to use an external queue to do it, but it is
> hardly difficult.
>
> You even have calls like exec cics read form  - to read in HTML forms. ;)
>
> -Paul
>
> ----- Original Message -----
> From: "jt" <jt@ee.net>
> To: <midrange-l@midrange.com>
> Sent: Saturday, November 10, 2001 9:38 PM
> Subject: RE: Rochester's changing focus/CICS-CCP/iSeries
>
>
> > 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.
> > >
> >
> > _______________________________________________
> > 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.
>