RE: SQLing across machines

<smith5646>
All of the machines that I refer to below are IBM I and running V7.3.
</smith5646>

all things really needed are running since V5

<smith5646>
I have some software that I am writing for a client that will run on
multiple "client" machines and needs to update data on a "host" machine. I
have created SQL statements that "select * from system.library.file" and
"update system.library.file" but now I have found out that they want to
install this on several different host machines and each will have its own
set of clients. For example client1 and client2 will talk to host1 and
client 3 and client 4 will talk to host2. So, the system name needs to be
changed to a variable.
</smith5646>

three part naming is a nice gimmick, you would have to use real world tools. simply use connect statement, doing it this way, server user and password come from variables.

<smith5646>
Also, we need to make the library name variable so
we can create a test environment using a different library name.
</smith5646>

thinking in sql (and using naming *SQL), the schemaname is part of the programm and the client programm knows what schema is used for unqualified names (set by dftrdbcol).
(BTW: a database with referential constraints and using naming sys and libl??? think about this!!!)

Using static sql in this environment could be clumsy, but possible. All combinations of client to server relations have to be compatible versions. You can't break compatibility during programm changes. For instance: adding a column to a table, you would have to do the rollout of the new version has to be at the same time for all clients and servers. (BTW: adding a column should be unviable for all programms!!! Simply use only views to access a database and a view is never (never ever!!!) changed. Adding a column to a table? add a new view!!!)

D*B