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.