Tom/Vern,

        It was the DDM TCP server was not started. Configuration setting was
not set to auto start..  I ran STRTCPSVR SERVER(*DDM) and tried the
connection again.  Tom, are you stating that one can only connect to a
remote system entry that has *LOCAL on the target's RDBE  "..._as well as_
on the target system for *LOCAL."?

Example:
        RDBE Source - WFICYBIL 10.21.10.5             <--will work
        RDBE Target - WFICYBIL *LOCAL

        RDBE Source - PRODSYS 10.21.10.5              <-- will not work
        RDBE Target - PRODSYS 10.21.10.5

My _assumption_ from previous posts on this subject was that since I could
access DDM files from the source I could also connect via SQL.  However, I
did not take into account the fact of that for TCP, separate servers are
required to host TCP functions, even though I have been exposed to this
situation for Netserver and ftp.

Now, I want to change the name on the RDBE to something different (it
actually has been there for several years and refers to a system that we
upgrade from a long time ago).   I get the message stating "Removing the
*LOCAL directory entry may cause loss of configuration data." when I try to
delete that entry in order to add an entry with a more meaningful name
(since I can only have one entry per remote location).  Anyway, what (if
any) other areas are affect besides DDM or RDB?  Will it be as simple as
stop server, delete current *LOCAL entry, add new *LOCAL entry and start
server?

Thank you,
Matt Tyler
Mattt@wincofoods.com

-----Original Message-----
From: qsrvbas@netscape.net [mailto:qsrvbas@netscape.net]
Sent: Tuesday, October 15, 2002 20:51
To: midrange-l@midrange.com
Subject: RE: DDM and SQL

Vern:

Don't pull too much hair out yet. Matt's situation doesn't seem fully stated
yet. In this last statement that you replied to, he said "The system that is
my target is also the system we use DDM files from. The DDM files are using
*SNA, however."

Okay, target and source are maybe the same. And we're maybe currently
speaking about "DDM file" and "*SNA". So, we don't care much about RDBEs
except maybe for rmtlocname(*LOCAL). And if the access is against an actual
DDMF rather than a 'remote database', we probably aren't talking SQL.

However, if we do mean SQL and *IP and remote, then an RDBE must be entered
on the source system to determine the route to the remote database (i.e.,
the IP address or host.domain name) _as well as_ on the target system for
*LOCAL. Then, it must be determined whether DDM security matches between the
two systems (i.e., what does a prompted CHGDDMTCPA show on both systems?)
And if passwords are required, has a proper server authentication entry been
added on the source system (i.e., does it specify the correct server name in
the correct format and reference a valid profile and password on the target
system?) Then, maybe check items such as exit programs to see if any are
active and what might be allowed/rejected. Then...

IOW, we probably need to know exactly what's been set up and what error
messages are generated from what operations.

There's probably an answer in there somewhere.

Maybe Matt can comment...

Tom Liotta


As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.