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.

This thread ...

Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.