RE: SQL Connect v DDM Files

You do not need to use a user id and password if the value is *VLDONLY.
You create a profile on each system with no password, *NONE. Run your
batch job under that profile and it will connect to the remote system
without supplying the user id and password.



Chris Bipes
Director of Information Services
CrossCheck, Inc.


-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx
[mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of DeLong, Eric
Sent: Tuesday, October 13, 2009 8:41 AM
To: Midrange Systems Technical Discussion
Subject: RE: SQL Connect v DDM Files

But this has no effect on the CONNECT TO statement in embedded SQL.
USERID/password is always required for this...

For interactive jobs, this is not such a big deal, since you can simply
prompt the user for the login credentials when opening the connection.
But in batch, you still need a secure repository for these service
profiles and passwords.

I guess this is the piece I'd like to find a solution for... I think
back over the years of all the FTP scripts where login data was embedded
in the script. Or DOS batch jobs running file transfer, or rpc calls to
launch a program remotely... All of these require user/pass details to
be embedded in the script.

PCI frowns on the notion of passwords in clear text, and it is easy to
understand why this is not considered good practice. So, what would be
a best-practice approach to eliminate hard coded credentials in source
code? Ideally, this could support DB2 ENCRYPT_RC2() passwords as well.

Just wondering how everyone else handles this...