Discussion:
Problems using a data area with DDM.
(too old to reply)
Darryl Freinkel
2014-10-20 19:19:53 UTC
Permalink
Raw Message
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-Zwy7GipZuJhWk0Htik3J/***@public.gmane.org
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request-Zwy7GipZuJhWk0Htik3J/***@public.gmane.org
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.
r***@public.gmane.org
2014-10-20 19:30:28 UTC
Permalink
Raw Message
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-***@public.gmane.org>
To: midrange-l-Zwy7GipZuJhWk0Htik3J/***@public.gmane.org
Date: 10/20/2014 03:20 PM
Subject: Fwd: Problems using a data area with DDM.
Sent by: "MIDRANGE-L" <midrange-l-bounces-Zwy7GipZuJhWk0Htik3J/***@public.gmane.org>



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-Zwy7GipZuJhWk0Htik3J/***@public.gmane.org
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request-Zwy7GipZuJhWk0Htik3J/***@public.gmane.org
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-Zwy7GipZuJhWk0Htik3J/***@public.gmane.org
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request-Zwy7GipZuJhWk0Htik3J/***@public.gmane.org
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.
Darryl Freinkel
2014-10-20 19:39:04 UTC
Permalink
Raw Message
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
Post by r***@public.gmane.org
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
Date: 10/20/2014 03:20 PM
Subject: Fwd: Problems using a data area with DDM.
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.
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 subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
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 subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
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-Zwy7GipZuJhWk0Htik3J/***@public.gmane.org
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request-Zwy7GipZuJhWk0Htik3J/***@public.gmane.org
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.
Chris Bipes
2014-10-20 19:51:14 UTC
Permalink
Raw Message
It takes more than just changing the IP address on the Ethernet lines. Did you update DNS servers? Default Gateway?
what about Work with RDB Directory Entry - WRKRDBDIRE

Chris Bipes
Director of Information Services
CrossCheck, Inc.


-----Original Message-----
From: MIDRANGE-L [mailto:midrange-l-bounces-Zwy7GipZuJhWk0Htik3J/***@public.gmane.org] On Behalf Of Darryl Freinkel
Sent: Monday, October 20, 2014 12:39 PM
To: Midrange Systems Technical Discussion
Subject: 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.
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L-Zwy7GipZuJhWk0Htik3J/***@public.gmane.org
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request-Zwy7GipZuJhWk0Htik3J/***@public.gmane.org
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.
r***@public.gmane.org
2014-10-20 19:54:27 UTC
Permalink
Raw Message
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-***@public.gmane.org>
To: Midrange Systems Technical Discussion <midrange-l-Zwy7GipZuJhWk0Htik3J/***@public.gmane.org>
Date: 10/20/2014 03:39 PM
Subject: Re: Fwd: Problems using a data area with DDM.
Sent by: "MIDRANGE-L" <midrange-l-bounces-Zwy7GipZuJhWk0Htik3J/***@public.gmane.org>



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
Post by r***@public.gmane.org
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
Date: 10/20/2014 03:20 PM
Subject: Fwd: Problems using a data area with DDM.
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.
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
Post by r***@public.gmane.org
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 subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
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 subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
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-Zwy7GipZuJhWk0Htik3J/***@public.gmane.org
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request-Zwy7GipZuJhWk0Htik3J/***@public.gmane.org
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-Zwy7GipZuJhWk0Htik3J/***@public.gmane.org
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request-Zwy7GipZuJhWk0Htik3J/***@public.gmane.org
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.
Darryl Freinkel
2014-10-20 20:01:35 UTC
Permalink
Raw Message
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.
Post by r***@public.gmane.org
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
Date: 10/20/2014 03:39 PM
Subject: 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
Post by r***@public.gmane.org
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
Post by r***@public.gmane.org
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
Post by r***@public.gmane.org
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
Date: 10/20/2014 03:20 PM
Subject: Fwd: Problems using a data area with DDM.
We use a production and development system. I wrote a tool to promote
code
Post by r***@public.gmane.org
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
Post by r***@public.gmane.org
system.
The code (in a CL program) creates a DDM dataarea on the source system
to
Post by r***@public.gmane.org
the target system (production). That data area stores a sequential
number.
Post by r***@public.gmane.org
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
Post by r***@public.gmane.org
fails. The second level text indicates that the error code is 17 which
is
Post by r***@public.gmane.org
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
Post by r***@public.gmane.org
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 subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
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
Post by r***@public.gmane.org
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
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 subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
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 subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
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-Zwy7GipZuJhWk0Htik3J/***@public.gmane.org
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request-Zwy7GipZuJhWk0Htik3J/***@public.gmane.org
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.
CRPence
2014-10-21 19:20:01 UTC
Permalink
Raw Message
Post by Darryl Freinkel
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.
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?
Post by Darryl Freinkel
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?
Post by Darryl Freinkel
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-Zwy7GipZuJhWk0Htik3J/***@public.gmane.org
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request-Zwy7GipZuJhWk0Htik3J/***@public.gmane.org
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.
Darryl Freinkel
2014-10-21 21:50:56 UTC
Permalink
Raw Message
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
Post by CRPence
Post by Darryl Freinkel
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.
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
Post by Darryl Freinkel
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 subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
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-Zwy7GipZuJhWk0Htik3J/***@public.gmane.org
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request-Zwy7GipZuJhWk0Htik3J/***@public.gmane.org
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.
Loading...