RE: Using two boxes to share the load via ddm files

Thanks Michael and Nathan!

        That gives me food for thought.  Is there a difference in the
performance impact on the machines depending on their role?  That is if Box
A accesses DataBase files on Box B with ddm, what would be the impact on Box
B compared to the impact of running the data access locally?  Does that make
sense? <smile>  I'm still cogitating about this - it has many ups and
downs...

Regards,

Rick DuVall
Systems Manager
Dealer's Auto Auction of Okc
1028 S. Portland
Oklahoma City, OK 73108
(405) 947-2886
rick@xxxxxxxxxx 
http://www.nothingisreal.com/dfki/no-word

Nathan M. Andelin Wrote:

I wrote an application that used DDM data queues.  A program that performed
database I/O was hosted on one AS/400 while a program that performed browser
I/O was hosted on another.  The programs communicated via DDM data queues.
Performance and reliability was okay, but not optimal.  There's latency
associated with intersystem communication, and you're adding an extra point
of failure to the architecture, and extra configuration steps, even though
DDM makes it appear fairly seamless during runtime.
 
Distributed architecture has become so prevalent in the Wintel and J2EE
worlds that people just assume it must be good.  It isn't, really.
 



Michael Ryan Wrote:

I've used and am using a fair amount of DDM - more than I'd like actually.
I'm currently using DDM over SNA (AnyNet). The performance is adequate - not
quite as good as being there, but acceptable. Once thing to be careful of is
how you make and break DDM connections. For instance, you have a client
program on system A communicating with a server program on system B.
Accessing data from remote system B is going to be pretty fast - as fast as
DDM and Anynet allow. Now take 300 client programs accessing system B.
Things will slow down appreciably, because basically you have two ways of
handling conversations - keep the conversation going, even if there's no
session; or drop the conversation when the session is done. The first way
causes the number of available modes to be used up, causing timeout errors
The second way is slower because of the dropping. We had a problem with the
first method and moved to the second. It's slower, but it works.

You might also look into data queues between the systems or remote SQL using
CONNECT TO. These will impact the system, but not as much as several client
programs accessing a remote system.