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

First, a defn of terms. There is client server where the server is on a
remote system. There is CS where access is provided to a shared system
resource such as a printer or tcp/ip server. There is CS where an appl
implements a "background" processor". And last, there is CS where
interactive display work is offloaded to a background html
translator/router.

Within this broad CS tent there is the issue of the transport mechanism
used. How does the client transmit its request to the server. How is the
response sent back to the client. I define two methods:  the queue and the
pgm call.

My argument focuses on whether the queue or the pgm call should be used to
implement the background processor and the html translator. The reason this
came up in the first place is because I think IBM's historic underpowering
of our system and its current day CFINT practice skew the decision in favor
of the queue, leaving the architecturally superior pgm call under used.

The pgm call has the following advantages over the queue:
- system mgmt of transactions ( pgm call stack shows current state of the
transaction)
- debug ( can trace, step the transaction from begin to end )
- User level security ( access to each transaction ( chg credit limit of
customer ) can be secured by GrtObjAut to the pgm that performs the
transaction )
- Exception handling ( build into the pgm call model )
- system logic flow documentation ( dsppgmref, probe/abstract show
transaction frow from begin to end )
- Pgm parameter support ( simple way to pass data between client and
server )

The queue has advantages also. It is more efficient to centralize the heavy
hitting updates of an appl in a central background job.

The queue enables good operations mgmt features:  hold the queue, shut down
the server, monitor how much activity is flowing thru the server.   ( but is
also provides the negative potential of a server job crashing and impacting
your entire system. Ever have a time when no pick tickets are being printed
and hours later discover that the background job has a level check ? )

Another good argument is that if you are going to queue intersystem,  you
should queue intrasystem also, since this gives maximum flexibility over how
the application is deployed over time and at each installation. My response:
I state/guess that a low pct of CS appl need this flexibility, that RPC
might be able to be used, and that the pgm call interface seen by the client
should still be used, just that the called server would be rewritten to
queue ( or RPC ) when needed.

The performance advantage of the queue is what I am focused on. The historic
underpowering of the system forced appl designers to queue when it was
better, for appl logic simplicity,  to call, resulting in appl that are more
complex and harder to maintain than they have to be.

And now, I think, we have the queue being chosen as the means to decouple
"dynamic dspf to html translation and delivery to the end browser" from the
CFINT crippled interactive job to a CPW galore batch job.  My only product
unseen objection with this is that if the pgm call would work better than
the queue, this is more evidence that CFINT causes appl on our system to be
more complex and functional than they need to be.

A few direct responses to this post that I am responding to:

You have to program to the requirement. If the rqr calls for a list of info
on a terminal, you code a subfile, if access to info is needed from a
browser, you code for that. The methods and skills the pgmr uses to
implement the rqr make a big difference in how complex the resulting appl
is.

I see client pgm A calling business logic pgm B as an example of
client/server.


Steve Richter



----- Original Message -----
From: "Joe Pluta" <joepluta@PlutaBrothers.com>
To: <midrange-l@midrange.com>
Sent: Tuesday, November 13, 2001 12:58 AM
Subject: RE: OO benefits? (was Re: Fast400 Value to iSeries community is
less than zero )


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