× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



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

Follow-Ups:
Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

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.