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

The entire box was moved.

The only configuration change was the IP address on the ethernet lines. The
IP did not change on the virtual ethernet lines.

It was backed up, powered down, suitably package and shipped. At the
destination, it was unwrapped, hardware tests done and then the LPARS were
started. The IP addresses on the Ethernet lines were changed.

Darryl

On Mon, Oct 20, 2014 at 3:30 PM, <rob@xxxxxxxxx> wrote:

When you moved data centers did anything else change other than just IP
address? Are you leaving anything out like 'when we moved from chicago to
detroit we did a save of a library or two from our chicago system and
restored it on to a different system in detroit'? Because this is rather
significant. This opens up things like
QRETSVRSEC *SEC Retain server security data
QRMTSIGN *SEC Remote sign-on control
unload/reloads are a whole different ball game than 'we loaded the old
machine into the truck, drove it over, unloaded it, changed a few IP
addresses and went live'. Especially HOW an unload/reload was done.


Rob Berendt
--
IBM Certified System Administrator - IBM i 6.1
Group Dekko
Dept 1600
Mail to: 2505 Dekko Drive
Garrett, IN 46738
Ship to: Dock 108
6928N 400E
Kendallville, IN 46755
http://www.dekko.com





From: Darryl Freinkel <dhfreinkel@xxxxxxxxx>
To: midrange-l@xxxxxxxxxxxx
Date: 10/20/2014 03:20 PM
Subject: Fwd: Problems using a data area with DDM.
Sent by: "MIDRANGE-L" <midrange-l-bounces@xxxxxxxxxxxx>



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.

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.

Does any know what is causing the this error?
--
Darryl Freinkel



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


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