Re: Fast400 Value to iSeries community is less than zero -- MIDRANGE-L

For what it is worth, I have written two client server pc to as400 type
applications. One linked a visual basic graphics type pgm on a pc to the
as400 enabling the as400 user to visually see cuts that had been made in
plates of steel inventory.  The other faxes splf's from the as400 thru fax
modems on the pc. Both make extensive use of data queues, sockets, appc
carrying all sorts of messages and data between the components.

Rather than thrill you will all the boring details, I can state my doubts
with the client/server approach to programming with a few design type
questions:

How does the client know that the server is not running?

How does the client know that the server has a pgm halt?

When the client needs a response from the server, is there a wait for
response time out? If so, how long is the wait?  And what does the client do
when time out occurs:  tell the user that we dont know if their tran went
thru or not, retry, call MIS or just punt?

When the server finds an error in the transaction, how does it communicate
this back to the client in a forcefull, you must monitor for this exception
msg way?

Do the abstract/probe type cross reference packages show the linkage of
client to server like they do of a calling pgm to called pgm?

In the call a common pgm paradigm, issues like this dont need to be
addressed. Common pgm exception handling is used.

Now a framework could be designed that would handle the issues I have
described. If you were coding in C++ it could even work transparently to the
end pgmr, abstracting the interface I think is the term.  I am not some much
challenging the method, I am more asking why the effort and using it as a
way to illustrate how CFINT causes problems.

Steve Richter



----- Original Message -----
From: "Joe Pluta" <joepluta@PlutaBrothers.com>
To: <midrange-l@midrange.com>
Sent: Saturday, November 10, 2001 1:15 PM
Subject: RE: Fast400 Value to iSeries community is less than zero


> > -----Original Message-----
> > From: Steve Richter
> >
> > Changing your appl design as a workaround to IBM's pricing of
interactive
> > CPW is more proof of how CFINT hurts our platform.
>
> While I don't much like the CFINT issue, I still think everyone should be
> thinking client/server anyway.  If all of our systems were client/server,
we
> wouldn't be worried about CFINT.
>
> I design the infrastructure once, and now I have all the benefits of
> client/server design.  A single point of entry (and change!) for my
business
> logic, a single place for auditing and security, the ability to change my
> database layout independent of my applications, and the ability to move my
> database and business logic to other machines, even other platforms.
> Client/server design provides unparalleled flexibility for what is really
a
> very small cost.  Let's review your objections:
>
>
> > When you add a  layer ( in
> > this case many layers ) to any software, you increase its complexity.
That
> > is bad.
>
> By separating out the business logic into a called program, you've done
> almost all the work necessary for a client/server design.
>
>
> > 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,
>
> And how to you send the data to your common program?  Unless you either
are
> passing a trivial amount of data, or you like maintaining huge parameter
> lists, you pass a data structure.  No difference.
>
>
> > write to a dtaq,
>
> You call a the server API rather than calling the update API.  Not a lot
of
> difference there.
>
>
> > hope the server job is running, wait for a
> > response from the server.
>
> This is all part of your server API.  Write it once, and forget about it.
> If you've never written a client/server architecture, it's challenging,
but
> once you've done it, you're done.  And this is the bulk of the difference
> between the two approaches.
>
>
> > And then you have to code and document
> > the server job.
>
> As opposed to coding and documenting the update API.  No difference.
>
>
> > 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.
>
> So, in essence, the difference between calling an update API and using a
> client/server design is that you have to write the client/server
> infrastructure.
>
> Once.
>
> Do that, and you have all the benefits of client/server, plus the added
> benefit of reducing your interactive CPW requirements.
>
> So the only thing stopping you is the fact the work involved in designing
a
> solid, robust client/server API.  I know it sounds a bit daunting, but
I'll
> be honest with you, it's not that difficult.  I teach one in a week that's
> pretty much usable for any sort of iSeries application; it's currently in
> heavy use in of all things a COBOL implementation.
>
> Joe Pluta
> www.plutabrothers.com
>
> _______________________________________________
> 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.
>
>