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