RE: OO benefits? (was Re: Fast400 Value to iSeries community is less than zero )

I think about 10-12 years ago I remember reading something from ?Mel
Beckman? about Client/Server.  He was comparing people fighting that to
people who fought going from the key to diskette machines to interactive
terminals.  Many of the arguments were EXACTLY the same.

Rob Berendt

==================
"They that can give up essential liberty to obtain a little temporary
safety deserve neither liberty nor safety."
Benjamin Franklin



                    "Joe Pluta"
                    <joepluta@PlutaBrot       To:     <midrange-l@midrange.com>
                    hers.com>                 cc:
                    Sent by:                  Fax to:
                    midrange-l-admin@mi       Subject:     RE: OO benefits? 
(was Re: Fast400 Value to iSeries community
                    drange.com                 is less    than zero )


                    11/13/2001 12:58 AM
                    Please respond to
                    midrange-l






Subfiles require more steps than simple screens.  You need to know many
more
keywords, and you have to write to the subfile and then to the subfile
control, setting indicators and so on.  It is much simpler to fill an array
with data and output the array on a standard record format.

So from your argument, I surmise that you don't use subfiles.

That of course, is a bit tongue in cheek, but I hope you see my point.
There are times when a little added complexity on the front end justifies
the costs over the long run in terms of maintainability, scalability, and a
whole host of other areas.

Client/server is more complex, certainly.  So is web development.  If
you're
the only programmer in a one-person IS department, either one may require
more development resources than you can provide.  In that case, by all
means
stick with monolithic green screen programs as long as you can justify the
"it's too much work" excuse to your users and management.

But if there's just one person available to write the API code for the C/S
infrastructure, then the application programmers don't even need to know
about the queueing details.  I'm sure you realize that all the C/S
infrastructure can easily be encapsulated in APIs in such a way that the
application programmer never sees it.  Then it's sort of like arguing that
it's better to use the single record rather than a subfile, because a
subfile does so much more under the covers that the programmer has to be
aware of.  That's not a justifiable argument, nor is the argument of not
using a C/S API because it does queueing under the covers.

But, hey, I'm unlikely to convince you.  It seems your mind is set that an
API that calls a queueing mechanism is just too much complexity to add to a
program.  If that's your opinion then, no, client/server architecture is
definitely not for you.

Joe Pluta
www.plutabrothers.com


> -----Original Message-----
> From: Steve Richter
>
> So I am suspicious of client/server increasing complexity because
> their are
> more steps the pgmr needs to know about in a cs tran than a pgm call
tran.

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