Re: SQL Connect v DDM Files

[CRPence <CRPbottle@xxxxxxxxx>]

  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?