|
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. > >
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.
midrange.com
