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.
>
>