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

That should be the least disruptive.


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 Systems Technical Discussion <midrange-l@xxxxxxxxxxxx>
Date: 10/20/2014 03:39 PM
Subject: Re: Fwd: Problems using a data area with DDM.
Sent by: "MIDRANGE-L" <midrange-l-bounces@xxxxxxxxxxxx>



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.

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