Michael Berkowitz <[log in to unmask]> writes

<snip>

>
>Definitely possible.  The way we've done it is by using Berkeley sockets
>to pass a message from the HP9K to a listener process on the HP3K; the
>HP3K process executes some application code, performs all of the
>TurboIMAGE database access and sends a message back to the HP9K
>with the
>completion status.
>
>Response time is great -- especially because all of the database access
>are local to the HP3000 (i.e.; they don't flow across the network).
>---------------------------------------------------------------------------
----------
>What Evan writes probably works fine, however I suspect that a generic
>solution that doesn't require user written listeners and senders is what is
>wanted, probably similar to the way ODBC works.  I don't know diddely
>about it, but isn't the Remote Procedure Call part of DCE supposed to
>address this issue.  Perhaps those in the know could elaborate on this.
>
>Mike Berkowitz
>Guess? Inc.
>

I would have to guess that Evan's project works better than "fine." Remember
that a generic solution will give you at best generic performance. By
writing your own socket server you have total control over performance. (You
also have total control to shoot yourself in the foot :) You don't have to
wait for anybody to give you 32-bit drivers. You don't have deal with a
generic "function not supported" type of message. Just as with any project
you have to weigh the up front costs with the long term effects.

How many people are literally getting punished now because they bought a
certain third party 4GL reporting tool years ago to save programmers up
front time. Sure the programmers' productivity went way up. Now, however,
performance suffers and they cannot afford to upgrade the box because their
hands are tied by said 3rd party.

Doug Werth                                     Beechglen Development Inc.
[log in to unmask]                                       Cincinnati, Ohio

The opinions expressed do not necessarily represent the views or opinions
of Beechglen Development. They might, but not necessarily. They represent
solely the opinions of the author.