RE: Fast400 Value to iSeries community is less than zero

["Joe Pluta" <joepluta@xxxxxxxxxxxxxxxxx>]

> -----Original Message-----
> From: Steve Richter
>
> 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?

This is your client/server infrastructure, which you design once.  You have
a request broker that handles these details.  It determines whether a given
service is running, and if not, initiates it.  It can create multiple
instances, adjust priorities, and all kinds of nice things.  It's work, but
not that much, especially for a relatively simple environment.  And most
importantly, you only write this code once!


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

This is application design, for which you need to have a corporate standard.
I mean, really, if a transaction fails, it returns an error, and your client
program notifies the user.  This is no different than checking for a CHAIN
failing.  If your corporate standard is to allow your users to get hard halt
messages as opposed to gracefully handling errors, then yes, you may have
some more work.


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

Nope.  You have to do that yourself.  Of course, does Probe/Abstract work
for SQL statements?  Called procedures?  VB clients?  Java?  Heck, does it
even work when you call a program whose name is in a variable?  In a
distributed programming environment, you have to keep track of your
application design yourself.


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

Why go to the bother of using a better, more robust architecture for your
application development?  Well, that's an interesting question.  If you
don't need it, don't do it.  My clients prefer robust, flexible
applications, and client/server provides them.

Joe Pluta
www.plutabrothers.com