RE: DDM over TCP/IP password problem.

AS/400 as TCP/IP DDM client does not currently support sending password to
TCP/IP DDM server.
However, DB2/400 does support sending  passwords to remote SQL database.
Since they use the same underlying connection you may do the following:
- ADDRDBDIRE on a target system to define *LOCAL database
- ADDRDBDIRE on a client system to define remote database with *IP protocol
- Issue SQL statement from a client job:
     CONNECT TO <remote database name> USER <user> USING <password>
- connection will be authenticated and scoped to activation group
- now you may use record level DDM access (DDM file) to remote system - you
may also use SQL, they will use the same already authenticated connection
- connection will be closed when activation group ends, or is reclaimed, or
you may use RCLDDMCNV to end it.

There is also another way to do it - more information is in AS/400
Information Center:
http://publib.boulder.ibm.com/pubs/html/as400/v4r4/ic2924/info/db2/rbal1mst55.htm

Best regards
    Alexei Pytel


"Art Tostaine, Jr." <Art@link400.com> on 11/15/99 08:44:55 AM

Please respond to MIDRANGE-L@midrange.com

To:   MIDRANGE-L@midrange.com
cc:
Subject:  RE: DDM over TCP/IP password problem.




I have everything setup with directory entries and user profiles.  I've
double checked this thank to
your message.

Any other ideas will be appreciated.

Art Tostaine, Jr.
CCA, Inc.
Jackson, NJ 08527

=====================
Your Message ~I started experimenting with DDM over TCP/IP.  I can
Your Message ~only get it to work if I set the remote system
Your Message ~to require password(*NO).
Your Message ~
Your Message ~I want to leave it as *YES.  How do I specify a
Your Message ~password when I try to access the remote file on the
Your Message ~local system?
=====================
My guess: The remote system at *YES really means (to me) require the DDM
guest to be an enrolled user at this system also.

I am going on memory so please check into this for errors.
My DDM experience is with AS/400 to AS/400 only.
I used DDM to simplify establishing connections in batch and a few other
*basic* things.
The secret to this for me was having one authorized user enrolled in the
distribution directory at all locations.
Without explicit remote enrollment, etc,etc. there are defaults and default
users.
In our case, DDM worked at V2R3? and it has worked fine up to V4R3 (Which
is
my excuse for the fuzziness).
Our remote system controllers are a mix of dial-up and Frame Relay without
TCP.
I am *expecting* for each TCP connected system we bring up that the other
"tried-N-true" connectivity options continue to work. (because we will
never
migrate overnight)
I will want to start a DDM conversation with Remote location STORE100 and
with destination 192.168.??.?? at any given time from any two jobs.
The defaults may have changed from older releases. I remember QUSER on a
few
systems being assigned the remote job.

My global work-at-all-locations "user name" and "route to Remote Location
(REMLOC)" is all I care about when thinking "application" layer.
Markvilla@home.com

+---
| This is the Midrange System Mailing List!
| To submit a new message, send your mail to MIDRANGE-L@midrange.com.
| To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com.
| To unsubscribe from this list send email to
MIDRANGE-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator:
david@midrange.com
+---



+---
| This is the Midrange System Mailing List!
| To submit a new message, send your mail to MIDRANGE-L@midrange.com.
| To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com.
| To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---