× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



We did change the DNS servers as well and this was updated in CFGTCP option
12.

No changes were made to the RDBDIRE entries as they use the DNS names.

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

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.





As an Amazon Associate we earn from qualifying purchases.

This thread ...

Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.