Re: Fwd: Problems using a data area with DDM.

I have an update that just worked. Thanks to another unrelated query on
this forum, I realized that I had done a CONNECT in STRSQL to verify that
the connection worked. I did not realize that this had some affect on some
data stored inside the system. When I saw that thread, I went to the guy
with the problem and asked him to do a CONNECT to the target system and
then a CONNECT back to the source system.

Like magic, the problem went away.

I have no idea what the system stores, but by just doing the CONNECT, it
resolved the problem.

Thanks

On Tue, Oct 21, 2014 at 3:20 PM, CRPence <CRPbottle@xxxxxxxxx> wrote:

On 20-Oct-2014 14:19 -0500, Darryl Freinkel wrote:

Scenario:
We use a production and development system. I wrote a tool to promote
code from the development LPAR to the production LPAR. The process
uses DDM heavily. This process has worked without incident for the
past 3 years.

We moved data centers and as a result, we changed our IP addresses on
the system.

Problem:
The code (in a CL program) creates a DDM dataarea on the source
system to the target system (production). That data area stores a
sequential number. The program uses RTVDTAARA QTEMP/remote_dataarea
to retrieve the value.

We are now getting a CPF101A error for the RTVDTAARA and the process
thus fails. The second level text indicates that the error code is 17
which is the DDM user ID and passwords are required. We do use user
ID and password.

By any chance does that mean to imply that a _previously listed_
message, logged prior to the msg CPF101A had second level text with an
EC17? Perhaps the symptom msg CPF9190 RC17 describes the 2nd level text
from the previous message, rather than replacement text from the CPF101A
itself?

We made no changes here. The DDM setup uses a RDB connection over

TCPIP. All other DDM commands work like they should. I use SBMRMTCMD
successfully with the exception now of the RTVDTAARA which can only
be used in the local environment on the source system.

The output from the prompted Change DDM TCP/IP [Server] Attributes
(CHGDDMTCPA) are as expected?

Does any know what is causing the this error?

After whatever was the effective migration, might there exist a
requirement to update the Server Authorization Entry; i.e. issue new Add
Server Auth Entry (ADDSVRAUTE) requests for the user(s)?

--
Regards, Chuck

--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.