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

[Darryl Freinkel <dhfreinkel@xxxxxxxxx>]

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.