Re: SQL Connect v DDM Files

I can not claim to understand what of the files, programs, & systems described by the OP, but one thing seemed clear, that "all three files are on the EDI box and the programs are run from the main production box." That means all of the work can presumably be done against those three files using the SQL at\on the CONNECTed system. The local programs could even just call stored procedures [which need not even be SQL] that do their work at\on the remote system rather than bringing any of the data to the /local/ system from where the application is invoked. The DB2 Multisystem feature is more useful for partitioning data [within a table] rather than dealing with separate tables across different systems. A product once named DataJoiner [or similar] now under the WebSphere naming [or a similar product] would be more appropriate for SQL against tables on multiple systems.

Regards, Chuck

DeLong, Eric wrote:

While what you say is true, there is the limitation that the data
must be copied to the local system before it can be used in
joins to local tables. Also, when using CONNECT TO in SQLRPGLE,
you have to specify userid and password. That either means hardcoding these into the program source (SOX/PCI - not allowed here) or some sort of encrypted storage (perhaps db2 ENCRYPT()). But, then you get into encryption key or passphrase management, which is similar to the original problem of securely storing login data....

I think DB2 Multisystem would be useful for this, but I've never seen it installed, and have no idea how much it costs.

Vern Hamberg wrote:

All you really need is to set up a relational database entry -
to it and

use the CONNECT SQL statement, then run your SELECT directly
over to it.

WRKRDBDIRE is your ticket. Their might be security issues - I think you have to put in a user and password on the CONNECT.

It's really pretty cool - you can even do it in STRSQL.

RWMunday wrote:

I recently had to modify one selection and one file
generation program to use a "different file" than the one in
the original design (in programs which have been running
great since being implemented). The new file resides on an
EDI dedicated system and is accessed via DDM. Problem is
that the programs are using this "different file" in SQL
statements. Two other files on this system are output files
for EDI and use overrides in the CL successfully. All
three files are on the EDI box and the programs are run from
the main production box. SQL and DDM don't mix.

My options are to modify the SQL select statements not to use
this file, then chain to it to determine if the other file
should be used or bypassed. Or I can use SQL Connect which
will require me to take the overrides for the output EDI
files out of the CL and to clear them and output to them within the RPG program.

I would prefer to use SQL Connect. There are no examples on the system at present but I know what to code and where. Is
there anything I must be aware of to use SQL Connect
successfully?