RE: DDM and SQL

Matt:

The first step is to read the second-level text of the message (position the 
cursor somewhere on the error message text and press <F1>). Note that it 
references the CHGDDMTCPA command values.

One possibility could be to do the following:

1. Open two sessions to the system.
2. Prompt the CHGDDMTCPA command in session 1.
3. Remove/recreate the RDBE *LOCAL entry in session 2.
4. Press <Enter> in session 1.

As it is, CHGDDMTCPA stores a trivial amount of info, so that's more than what 
you'll probably need; you could just remember the values and type them in 
later. But be aware that every remote system that is using SQL to CONNECT to 
the current *LOCAL database name _might_ need to be changed. I haven't dug into 
the possibility of somehow creating an "alias" or secondary name.

What I was saying was that (AFAIK) both ends, source and target, should have 
appropriate RDBEs that can be matched up. Each system should have its own 
*LOCAL entry. And systems that want to reach remote databases should also have 
RDBEs that point to the remote databases.

Tom Liotta

midrange-l-request@midrange.com wrote:

>   8. RE: DDM and SQL (Tyler, Matt)
>
>    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
The PowerTech Group, Inc.
19426 68th Avenue South
Kent, WA 98032
Phone  253-872-7788 x313
Fax    253-872-7904
http://www.powertechgroup.com


__________________________________________________________________
The NEW Netscape 7.0 browser is now available. Upgrade now! 
http://channels.netscape.com/ns/browsers/download.jsp

Get your own FREE, personal Netscape Mail account today at 
http://webmail.netscape.com/