|
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 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.