CA/Platinum DB2 Utilities -Reply

John Bucaria

CA/Platinum DB2 Utilities -Reply
Greetings everyone!

While we're on the subject of the CA/Platinum tools and support, we've had a problem with RC/Migrator for many months. CA's tech support has been unable to help us resolve this. They keep telling us to rebind their plans which has no effect.

When attempting to create a "compare" type strategy in RC/Migrator to compare an object in 2 different subsystems, a -924 SQLCODE is returned from the "RC/M Create Compare Strategy" screen. Then you are returned to the "RC/M Strategy Services" screen without a strategy having been created. This has been a problem since we first applied the 97G maintenance and is still a problem under the 97H maintenance even though CA support told us the 97H would "probably" fix this.

Sound familiar to anyone? Any suggestions?
Being able to migrate changes from a test subsystem to production (without having to re-key the change) is probably the major reason for having RC/Migrator in my view. The compare function is essential to being able to accomplish this.

Thanks in advance for your ideas !

John



Rob Crane

Re: CA/Platinum DB2 Utilities -Reply
(in response to John Bucaria)
I have not seen this before at the sites where I support the products.
It sounds like you are doing a subsystem to subsystem compare. Are the
2 subsystems on the same LPAR or separate? Are the 2 subsystems part of
a data sharing group. Depending on the answers to these questions you
might have to look at the SETUP and MIGRATOR members of PARMLIB to
insure they are set up correctly. Assuming you have DDF between the two
subsystems give this a try. This will use DDF to connect to the target
and get the information it needs while running the compare on the source
side. Let me know what happens when you set it up this way. My example
uses primary object of DB, which is not really important, actually you
should be able to do the same compare since I am using the platinum
database in my example. Let me know if this works for you.


1) create a compare strategy
2) select option 1, subsystem to subsystem
3) Use following for RC/M Compare Strategy.

OBJECT ===> DB

Source Subsystem Specification:
SSID ===> DBTT LOCATION: LOCAL
Obj Name ===> PTDB Obj Creator: *
Where = N
Target Subsystem Specification:
SSID ===> DBTT LOCATION: DDF_DBPP
OBJ Name ===> PTDB Obj Creator: *
Where = N
--------------------------------------------------

This assumes:
DBTT = Test Subsystem (source)
DBPP = Prod Subsystem (target)
DDF_DBPP = DDF name for DBPP in SYSIBM.LOCATIONS column LOCATION

SETUP parmlib member would have:

SSID (DBTT)
LOCATION (LOCAL)
LOCSSID (DBTT)
LOCATION (DDF_DBPP)
LOCSSID (DBPP)

----------------------

Give this a try and let me know if it works for you.

-Rob



John Bucaria wrote:
>
> Greetings everyone!
>
> While we're on the subject of the CA/Platinum tools and support, we've had a problem with RC/Migrator for many months. CA's tech support has been unable to help us resolve this. They keep telling us to rebind their plans which has no effect.
>
> When attempting to create a "compare" type strategy in RC/Migrator to compare an object in 2 different subsystems, a -924 SQLCODE is returned from the "RC/M Create Compare Strategy" screen. Then you are returned to the "RC/M Strategy Services" screen without a strategy having been created. This has been a problem since we first applied the 97G maintenance and is still a problem under the 97H maintenance even though CA support told us the 97H would "probably" fix this.
>
> Sound familiar to anyone? Any suggestions?
> Being able to migrate changes from a test subsystem to production (without having to re-key the change) is probably the major reason for having RC/Migrator in my view. The compare function is essential to being able to accomplish this.
>
> Thanks in advance for your ideas !
>
> John
>
>
>



Rob Crane

Re: CA/Platinum DB2 Utilities -Reply
(in response to Rob Crane)
If you are in a rush and don't have time to monkey with the setup
member, etc., you could also do a compare without involving DB2, so you
won't get the connection error. Not a solution just a work around.

1) Use a Migration strategy on both source and target side. Migrate all
objects to a flat file.
2) Use a compare strategy that compares flat files instead of the db2
subsystems. If your test and production subsystem don't have shared
dasd, you will need to get the flat file that contains your Migrator
Production DDL over to the test site, etc.


Rob Crane wrote:
>
> I have not seen this before at the sites where I support the products.
> It sounds like you are doing a subsystem to subsystem compare. Are the
> 2 subsystems on the same LPAR or separate? Are the 2 subsystems part of
> a data sharing group. Depending on the answers to these questions you
> might have to look at the SETUP and MIGRATOR members of PARMLIB to
> insure they are set up correctly. Assuming you have DDF between the two
> subsystems give this a try. This will use DDF to connect to the target
> and get the information it needs while running the compare on the source
> side. Let me know what happens when you set it up this way. My example
> uses primary object of DB, which is not really important, actually you
> should be able to do the same compare since I am using the platinum
> database in my example. Let me know if this works for you.
>
> 1) create a compare strategy
> 2) select option 1, subsystem to subsystem
> 3) Use following for RC/M Compare Strategy.
>
> OBJECT ===> DB
>
> Source Subsystem Specification:
> SSID ===> DBTT LOCATION: LOCAL
> Obj Name ===> PTDB Obj Creator: *
> Where = N
> Target Subsystem Specification:
> SSID ===> DBTT LOCATION: DDF_DBPP
> OBJ Name ===> PTDB Obj Creator: *
> Where = N
> --------------------------------------------------
>
> This assumes:
> DBTT = Test Subsystem (source)
> DBPP = Prod Subsystem (target)
> DDF_DBPP = DDF name for DBPP in SYSIBM.LOCATIONS column LOCATION
>
> SETUP parmlib member would have:
>
> SSID (DBTT)
> LOCATION (LOCAL)
> LOCSSID (DBTT)
> LOCATION (DDF_DBPP)
> LOCSSID (DBPP)
>
> ----------------------
>
> Give this a try and let me know if it works for you.
>
> -Rob
>
> John Bucaria wrote:
> >
> > Greetings everyone!
> >
> > While we're on the subject of the CA/Platinum tools and support, we've had a problem with RC/Migrator for many months. CA's tech support has been unable to help us resolve this. They keep telling us to rebind their plans which has no effect.
> >
> > When attempting to create a "compare" type strategy in RC/Migrator to compare an object in 2 different subsystems, a -924 SQLCODE is returned from the "RC/M Create Compare Strategy" screen. Then you are returned to the "RC/M Strategy Services" screen without a strategy having been created. This has been a problem since we first applied the 97G maintenance and is still a problem under the 97H maintenance even though CA support told us the 97H would "probably" fix this.
> >
> > Sound familiar to anyone? Any suggestions?
> > Being able to migrate changes from a test subsystem to production (without having to re-key the change) is probably the major reason for having RC/Migrator in my view. The compare function is essential to being able to accomplish this.
> >
> > Thanks in advance for your ideas !
> >
> > John
> >
> >
> >
>
>
>



Carlos Olson

Re: CA/Platinum DB2 Utilities -Reply
(in response to Rob Crane)
My memory may be failing but I think I remember something like this where we
had to rebind a package with the REOPT(VARS) option. We are using P97G on
OS390 V2.6 with OS390 DB2 V6.1

Carlos Olson
Database Administrator
QRS Corporation

510.215.3873 voice
510.621.3873 fax
[login to unmask email]


-----Original Message-----
From: John Bucaria [mailto:[login to unmask email]
Sent: Thursday, December 14, 2000 8:26 AM
To: [login to unmask email]
Subject: CA/Platinum DB2 Utilities -Reply


Greetings everyone!

While we're on the subject of the CA/Platinum tools and support, we've had a
problem with RC/Migrator for many months. CA's tech support has been
unable to help us resolve this. They keep telling us to rebind their plans
which has no effect.

When attempting to create a "compare" type strategy in RC/Migrator to
compare an object in 2 different subsystems, a -924 SQLCODE is returned from
the "RC/M Create Compare Strategy" screen. Then you are returned to the
"RC/M Strategy Services" screen without a strategy having been created.
This has been a problem since we first applied the 97G maintenance and is
still a problem under the 97H maintenance even though CA support told us the
97H would "probably" fix this.

Sound familiar to anyone? Any suggestions?
Being able to migrate changes from a test subsystem to production (without
having to re-key the change) is probably the major reason for having
RC/Migrator in my view. The compare function is essential to being able to
accomplish this.

Thanks in advance for your ideas !

John



http://www.ryci.com/db2-l. The owners of the list can be reached at
[login to unmask email]