|
Steve, You wrote "When you add a layer ( in this case many layers ) to any software, you increase its complexity. That is bad." I can't agree more. Adding an extra layer of abstraction, using OO, in order to achieve maintainable programs, is also "bad". Rather than "bad".. I should say there are tradeoffs involved, in any approach. jt > -----Original Message----- > From: midrange-l-admin@midrange.com > [mailto:midrange-l-admin@midrange.com]On Behalf Of Steve Richter > Sent: Saturday, November 10, 2001 11:12 AM > To: midrange-l@midrange.com > Subject: Re: Fast400 Value to iSeries community is less than zero > > > > ----- Original Message ----- > From: <thomas@inorbit.com> > > >> To run a real c++ telnet accessed application that is code > bloat to some, > >> well abstracted functionality to others will need every bit of the 1000 > CPW > >> to service its 15 users. > > >If you mean that the full 1000CPW will be required as > interactive, this is > only true if the >application is written to do so. It's perfectly possible > to break the interactive presentation l>ayer out and run the rest in batch > as server functions. > >Tom Liotta > > Tom, > > Changing your appl design as a workaround to IBM's pricing of interactive > CPW is more proof of how CFINT hurts our platform. When you add a > layer ( in > this case many layers ) to any software, you increase its complexity. That > is bad. Instead of your "interactive presentation layer" calling a common > pgm to apply the dsply entry to the database, your approach is to fill a > data struct, write to a dtaq, hope the server job is running, wait for a > response from the server. And then you have to code and document > the server > job. Very complex. If you have a good appl design reason to do > this, fine. > But if it is done because of IBM's pricing of interactive CPW > then, that is > not fine. > > > James wrote: > > So I mean no offense, but it can't help but come across that way, I > > guess...: I think that explains why the idea of a 15-user > system needing > > 1000CPW seems pretty doggone funny, to some of us "old dogs". > > Tom said: > >Every once in a while, you get it extremely right. > > > Tom and James, > > I am asserting that computer applictions will always? expand to fill the > available dasd and cpu available to them. This is proven by computer > history. With that "fact" established, I then say that IBM should not be > concerned re: losing revenue if they remove CFINT because the new > interactive applications writen to run on the new 3x fast systems will use > 3x the cpu of software they replace or enhance. > > And this increased usage of the cpu is not wasted or bloated > code. It would > bring an excellent language like C++ to our platform. That alone is reason > enough to scrap CFINT. > > Here is an interactive feature that increases functionality, but > needs high > cpw to run: > Consider a subfile dsply. What if the user wants to see a few > more columns > of information today. Doable, but not realistic on a 50CPW multi user > system. But if the CPW is available, your pgm could call some api's to > build the display on the fly, maybe send html to a next generation telnet > client. > > etc, etc, etc > > Steve Richter > > > > _______________________________________________ > 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.