Roy,
There are timing questions, etc, involved.  For example, if you are 
running backups, or other locks on the data, at different times on the 
differing machines then querying across all machines against live data 
should be done cautiously.  If this is a concern then perhaps using a 
trigger on the remote systems to send the changes to the machine doing the 
querying is a good idea.  By the way, this kind of a trigger should not 
affect your existing applications.  I think the other respondents concern 
about triggers is only valid if you are doing additional error checking or 
something in that trigger and trying to flag that up to the existing 
application.  False concerns like this inspire paranoia that can take 
years to dispel.  There are still people who won't put a key on a physical 
file because of some concern that -may- have existed on a early version of 
S/38.
But if you want to query live, then there are a couple of ways to do this.
With traditional "Record Level Access" or RLA (like RPG's CHAIN) you can 
use:
CRTDDMF FILE(DATALIB/SWEDE) RMTFILE(CRMLIB/CRMMASTER) RMTLOCNAME(SWEDEN 
*IP)
Then you can easily chain against that file.
See also:
http://publib.boulder.ibm.com/infocenter/iseries/v5r4/topic/ddm/rbae5connauth.htm
http://publib.boulder.ibm.com/infocenter/iseries/v5r4/topic/ddp/rbal1setddm.htm
With SQL you can issue a 
CONNECT TO remoteServerName
Providing you've already done the setup with WRKRDBDIRE
http://publib.boulder.ibm.com/infocenter/iseries/v5r4/topic/db2/rbafzmstconj1.htm#conj1
The problem with SQL's approach is that it doesn't allow you to be 
connected to multiple machines at once.  Some people mix and match to get 
around that by using RLA for local data and CONNECT for the remote data.
Rob Berendt
As an Amazon Associate we earn from qualifying purchases.