Catalog entries

Mike (M.) Polley

Catalog entries
We're using 'Change Man' by Serena (a migration package - if you haven't
heard of it, no problem.) You may know the answer to my question without
being a Change Man expert. However, if you use it, you may better
understand this dilemma. This is OS/390 DB2 Version 6.
Using 'Change Man' (usually) when you move a DB2 program to prod,
you would have bound it in test first. Wherein 'Change Man' just moves this
to prod without recompiling. Thereby keeping the test and prod in sync.
However, because of urgency (prod abends) an application group moved a bunch
of DB2 programs to prod, without binding them to test. Now prod and test
are out of sync. So, the groups ideal is to move the programs to prod again
to fix test. Which it would, but it's quite a few programs.

My Question is whether or not I could just update the catalog tables
syspackage, sysdbrm, sysplan, with the same entries from prod, to put them
back in sync? Or are there just too many catalog entries that I would miss
(i.e. in other tables I didn't mention) to remedy this. Because from what I
can see is that all the programs they are now getting -805 on are the ones
that don't have an entry in test to match prod. As do the other programs.
Am I missing a lot here, or is there something else I need to clarify?
Thanks in advance for any help or suggestion.



Jim Tonchick

Re: Catalog entries
(in response to Rob Crane)
My advice... NEVER manually update the DB2 Catalog tables except possiblly
for Runstats information. Otherwise you'll be more likely to create more
problems that what you are trying to fix.

Use the ChangeMan facilities and recompile in test. After all, it is just
test.

Jim Tonchick
Fiserv, Inc.



Rob Crane

Re: Catalog entries
(in response to Mike (M.) Polley)
You could use BIND PACKAGE COPY feature to assist you. Only get
packages that have a timestamp equal to the timestamp of the programs
they hit during their fixing activity.

"Polley, Mike (M.)" wrote:
>
> We're using 'Change Man' by Serena (a migration package - if you haven't
> heard of it, no problem.) You may know the answer to my question without
> being a Change Man expert. However, if you use it, you may better
> understand this dilemma. This is OS/390 DB2 Version 6.
> Using 'Change Man' (usually) when you move a DB2 program to prod,
> you would have bound it in test first. Wherein 'Change Man' just moves this
> to prod without recompiling. Thereby keeping the test and prod in sync.
> However, because of urgency (prod abends) an application group moved a bunch
> of DB2 programs to prod, without binding them to test. Now prod and test
> are out of sync. So, the groups ideal is to move the programs to prod again
> to fix test. Which it would, but it's quite a few programs.
>
> My Question is whether or not I could just update the catalog tables
> syspackage, sysdbrm, sysplan, with the same entries from prod, to put them
> back in sync? Or are there just too many catalog entries that I would miss
> (i.e. in other tables I didn't mention) to remedy this. Because from what I
> can see is that all the programs they are now getting -805 on are the ones
> that don't have an entry in test to match prod. As do the other programs.
> Am I missing a lot here, or is there something else I need to clarify?
> Thanks in advance for any help or suggestion.
>
>
>



James Campbell

Re: Catalog entries
(in response to Jim Tonchick)
The reason why one _cannot_ do what you are suggesting is that there is two
halves to DB2's internal picture, and the catalog is one half. The other
half is the the directory - which you have no way of updating except through
the standard methods (BIND, CREATE/ALTER etc SQL). In the case of programs,
DB2 uses the stuff in the directory to actually do its work - not the
contents of the catalog. So, yes, if you got really tricky you could copy
stuff around in the catalog: but DB2 would happily continue to use the
directory.

By "really tricky" I mean "use undocumented and unsupported facilities to
bypass DB2's internal integrity and hence, possibly, corrupt DB2's catalog".

/* standard disclaimer */
James Campbell
DBA
Hansen Corporation, Doncaster
+61 3 9843 8442
[login to unmask email]
-----Original Message-----
From: Polley, Mike (M.) [mailto:[login to unmask email]
Sent: Saturday, December 16, 2000 4:21 AM
To: [login to unmask email]
Subject: [DB2-L] Catalog entries


We're using 'Change Man' by Serena (a migration package - if you haven't
heard of it, no problem.) You may know the answer to my question without
being a Change Man expert. However, if you use it, you may better
understand this dilemma. This is OS/390 DB2 Version 6.
Using 'Change Man' (usually) when you move a DB2 program to prod,
you would have bound it in test first. Wherein 'Change Man' just moves this
to prod without recompiling. Thereby keeping the test and prod in sync.
However, because of urgency (prod abends) an application group moved a bunch
of DB2 programs to prod, without binding them to test. Now prod and test
are out of sync. So, the groups ideal is to move the programs to prod again
to fix test. Which it would, but it's quite a few programs.

My Question is whether or not I could just update the catalog tables
syspackage, sysdbrm, sysplan, with the same entries from prod, to put them
back in sync? Or are there just too many catalog entries that I would miss
(i.e. in other tables I didn't mention) to remedy this. Because from what I
can see is that all the programs they are now getting -805 on are the ones
that don't have an entry in test to match prod. As do the other programs.
Am I missing a lot here, or is there something else I need to clarify?
Thanks in advance for any help or suggestion.







**********************************************************************
This email and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom they
are addressed. If you have received this email in error please notify
the system manager.

This footnote also confirms that this email message has been swept by
MIMEsweeper for the presence of computer viruses.

www.mimesweeper.com
**********************************************************************



Sanjeev (CTS) S

Re: Catalog entries
(in response to James Campbell)
First of all it is never advisable to update the catalog unless until we
need to give some special hint to the optimizer which ofcourse are going to
help us. Another thing which i feel in your case is, you can't get away with
updating the catalog tables only. What about the directory where
plans/packages are kept. Infact nothing more would have changed in the
catalog tables other than timestamp. The executable is still not possible to
be changed.

I think you should get it recompiled in test.

HTH
Regards,
Sanjeev

> -----Original Message-----
> From: Polley, Mike (M.) [SMTP:[login to unmask email]
> Sent: Friday, December 15, 2000 10:51 PM
> To: [login to unmask email]
> Subject: Catalog entries
>
> We're using 'Change Man' by Serena (a migration package - if you haven't
> heard of it, no problem.) You may know the answer to my question without
> being a Change Man expert. However, if you use it, you may better
> understand this dilemma. This is OS/390 DB2 Version 6.
> Using 'Change Man' (usually) when you move a DB2 program to prod,
> you would have bound it in test first. Wherein 'Change Man' just moves
> this
> to prod without recompiling. Thereby keeping the test and prod in sync.
> However, because of urgency (prod abends) an application group moved a
> bunch
> of DB2 programs to prod, without binding them to test. Now prod and test
> are out of sync. So, the groups ideal is to move the programs to prod
> again
> to fix test. Which it would, but it's quite a few programs.
>
> My Question is whether or not I could just update the catalog tables
> syspackage, sysdbrm, sysplan, with the same entries from prod, to put them
> back in sync? Or are there just too many catalog entries that I would
> miss
> (i.e. in other tables I didn't mention) to remedy this. Because from what
> I
> can see is that all the programs they are now getting -805 on are the ones
> that don't have an entry in test to match prod. As do the other programs.
> Am I missing a lot here, or is there something else I need to clarify?
> Thanks in advance for any help or suggestion.
>
>
>
>
>
-----------------------------------------------------------------------------------------------------------------------------------------
-----------------------------------------------------------------------------------------------------------------------------------------
This e-mail and any files transmitted with it are for the sole use
of the intended recipient(s) and may contain confidential and privileged information.
If you are not the intended recipient, please contact the sender by reply e-mail and
destroy all copies of the original message. Any unauthorised review, use, disclosure,
dissemination, forwarding, printing or copying of this email or any action taken in
reliance on this e-mail is strictly prohibited and may be unlawful.

Visit us at http://www.cognizant.com
----------------------------------------------------------------------------------------------------------------------------------------
----------------------------------------------------------------------------------------------------------------------------------------



Tim R - CNF Ohling

Re: Catalog entries
(in response to Sanjeev (CTS) S)
We have ChangeMan as well, but for implementation take an approach
which is similar to what you need to do:

Each development project has it's own test database/owner. New and
updated modules are only compiled and bound into the library and package
collection associated with the assigned database/owner (managed via
ChangeMan promotion levels).

When modules move to production, we have to bind the DBRM's into
every test environment as now the executables are available everywhere.

So, we build BIND statements for all packages in production and not
in test (which we do by comparing the SYSPACKAGE tables in the two
catalogs), and execute them in test using the production DBRM library(ies).
You shouldn't need to recompile anything if you can identify the packages
that need to be bound and build a list of the necessary bind commands.

HTH,
Tim

> > -----Original Message-----
> > From: Polley, Mike (M.) [SMTP:[login to unmask email]
> > Sent: Friday, December 15, 2000 10:51 PM
> > To: [login to unmask email]
> > Subject: Catalog entries
> >
> > We're using 'Change Man' by Serena (a migration package - if you haven't
> > heard of it, no problem.) You may know the answer to my question
> without
> > being a Change Man expert. However, if you use it, you may better
> > understand this dilemma. This is OS/390 DB2 Version 6.
> > Using 'Change Man' (usually) when you move a DB2 program to
> prod,
> > you would have bound it in test first. Wherein 'Change Man' just moves
> > this
> > to prod without recompiling. Thereby keeping the test and prod in sync.
> > However, because of urgency (prod abends) an application group moved a
> > bunch
> > of DB2 programs to prod, without binding them to test. Now prod and
> test
> > are out of sync. So, the groups ideal is to move the programs to prod
> > again
> > to fix test. Which it would, but it's quite a few programs.
> >
> > My Question is whether or not I could just update the catalog tables
> > syspackage, sysdbrm, sysplan, with the same entries from prod, to put
> them
> > back in sync? Or are there just too many catalog entries that I would
> > miss
> > (i.e. in other tables I didn't mention) to remedy this. Because from
> what
> > I
> > can see is that all the programs they are now getting -805 on are the
> ones
> > that don't have an entry in test to match prod. As do the other
> programs.
> > Am I missing a lot here, or is there something else I need to clarify?
> > Thanks in advance for any help or suggestion.
> >
> >
> >
> > the DB2-L webpage at http://www.ryci.com/db2-l. The owners of the list
> can
> >
> --------------------------------------------------------------------------
> ---------------------------------------------------------------
> --------------------------------------------------------------------------
> ---------------------------------------------------------------
> This e-mail and any files transmitted with it are for the sole use
> of the intended recipient(s) and may contain confidential and privileged
> information.
> If you are not the intended recipient, please contact the sender by reply
> e-mail and
> destroy all copies of the original message. Any unauthorised review, use,
> disclosure,
> dissemination, forwarding, printing or copying of this email or any action
> taken in
> reliance on this e-mail is strictly prohibited and may be unlawful.
>
> Visit us at http://www.cognizant.com
> --------------------------------------------------------------------------
> --------------------------------------------------------------
> --------------------------------------------------------------------------
> --------------------------------------------------------------
>
>
>
>
>



Tony Provenzola

Re: Catalog entries
(in response to Tim R - CNF Ohling)
Is there any reason that you can't just BIND them in Test?

Some people have suggested recompiling, but that just creates another Test
version. Then your Test and Prod timestamps don't match, so you've got to
keep the Test Load Module around, even though it's identical to Prod except
for the Precompile time.

If you're JOBLIB concatenation is such that you run the Prod Load when there
is no Test version, just BIND/REBIND from the Prod DBRM. Or is there
something about Change Man that doesn't permit this?

Tony Provenzola
Nike Database Services
BEST Consulting
* Phone: 503-532-0772
* Fax: 503-532-2618
* Email: [login to unmask email]


-----Original Message-----
From: Polley, Mike (M.) [mailto:[login to unmask email]
Sent: Friday, December 15, 2000 9:21 AM
To: [login to unmask email]
Subject: Catalog entries


We're using 'Change Man' by Serena (a migration package - if you haven't
heard of it, no problem.) You may know the answer to my question without
being a Change Man expert. However, if you use it, you may better
understand this dilemma. This is OS/390 DB2 Version 6.
Using 'Change Man' (usually) when you move a DB2 program to prod,
you would have bound it in test first. Wherein 'Change Man' just moves this
to prod without recompiling. Thereby keeping the test and prod in sync.
However, because of urgency (prod abends) an application group moved a bunch
of DB2 programs to prod, without binding them to test. Now prod and test
are out of sync. So, the groups ideal is to move the programs to prod again
to fix test. Which it would, but it's quite a few programs.

My Question is whether or not I could just update the catalog tables
syspackage, sysdbrm, sysplan, with the same entries from prod, to put them
back in sync? Or are there just too many catalog entries that I would miss
(i.e. in other tables I didn't mention) to remedy this. Because from what I
can see is that all the programs they are now getting -805 on are the ones
that don't have an entry in test to match prod. As do the other programs.
Am I missing a lot here, or is there something else I need to clarify?
Thanks in advance for any help or suggestion.








Mike (M.) Polley

Re: Catalog entries
(in response to Tony Provenzola)
Actually, I don't know why my question took so long to reach the listserv,
but nevertheless, I appreciate all the feed back, suggestions, and
clarifications. The group has just been correcting the -805s as they
happen.



-----Original Message-----
From: Provenzola, Tony [mailto:[login to unmask email]
Sent: Tuesday, January 09, 2001 2:10 PM
To: [login to unmask email]
Subject: Re: Catalog entries


Is there any reason that you can't just BIND them in Test?



Some people have suggested recompiling, but that just creates another Test

version. Then your Test and Prod timestamps don't match, so you've got to

keep the Test Load Module around, even though it's identical to Prod except

for the Precompile time.



If you're JOBLIB concatenation is such that you run the Prod Load when there

is no Test version, just BIND/REBIND from the Prod DBRM. Or is there

something about Change Man that doesn't permit this?



Tony Provenzola

Nike Database Services

BEST Consulting

* Phone: 503-532-0772

* Fax: 503-532-2618

* Email: [login to unmask email]





-----Original Message-----

From: Polley, Mike (M.) [mailto:[login to unmask email]

Sent: Friday, December 15, 2000 9:21 AM

To: [login to unmask email]

Subject: Catalog entries





We're using 'Change Man' by Serena (a migration package - if you haven't

heard of it, no problem.) You may know the answer to my question without

being a Change Man expert. However, if you use it, you may better

understand this dilemma. This is OS/390 DB2 Version 6.

Using 'Change Man' (usually) when you move a DB2 program to prod,

you would have bound it in test first. Wherein 'Change Man' just moves this

to prod without recompiling. Thereby keeping the test and prod in sync.

However, because of urgency (prod abends) an application group moved a bunch

of DB2 programs to prod, without binding them to test. Now prod and test

are out of sync. So, the groups ideal is to move the programs to prod again

to fix test. Which it would, but it's quite a few programs.



My Question is whether or not I could just update the catalog tables

syspackage, sysdbrm, sysplan, with the same entries from prod, to put them

back in sync? Or are there just too many catalog entries that I would miss

(i.e. in other tables I didn't mention) to remedy this. Because from what I

can see is that all the programs they are now getting -805 on are the ones

that don't have an entry in test to match prod. As do the other programs.

Am I missing a lot here, or is there something else I need to clarify?

Thanks in advance for any help or suggestion.





















Dallas Focht

Re: Catalog entries
(in response to Mike (M.) Polley)
Is there a reason you can not bind the test programs pointing to the appropriate DBRM member?

"Polley, Mike (M.)" wrote:

> We're using 'Change Man' by Serena (a migration package - if you haven't
> heard of it, no problem.) You may know the answer to my question without
> being a Change Man expert. However, if you use it, you may better
> understand this dilemma. This is OS/390 DB2 Version 6.
> Using 'Change Man' (usually) when you move a DB2 program to prod,
> you would have bound it in test first. Wherein 'Change Man' just moves this
> to prod without recompiling. Thereby keeping the test and prod in sync.
> However, because of urgency (prod abends) an application group moved a bunch
> of DB2 programs to prod, without binding them to test. Now prod and test
> are out of sync. So, the groups ideal is to move the programs to prod again
> to fix test. Which it would, but it's quite a few programs.
>
> My Question is whether or not I could just update the catalog tables
> syspackage, sysdbrm, sysplan, with the same entries from prod, to put them
> back in sync? Or are there just too many catalog entries that I would miss
> (i.e. in other tables I didn't mention) to remedy this. Because from what I
> can see is that all the programs they are now getting -805 on are the ones
> that don't have an entry in test to match prod. As do the other programs.
> Am I missing a lot here, or is there something else I need to clarify?
> Thanks in advance for any help or suggestion.
>
>
>



Mike (M.) Polley

Re: Catalog entries
(in response to Dallas Focht)
Yes, In order to bind application programs, they must exists within what is
called a package. Then the collection id would be named from that
particular package, and still be out of sync with prod because of the
collection id. So, the only way to get them in sync is to move the test
package to prod. Thanks for the help.



-----Original Message-----
From: Dallas Focht [mailto:[login to unmask email]
Sent: Tuesday, January 09, 2001 6:39 PM
To: [login to unmask email]
Subject: Re: Catalog entries


Is there a reason you can not bind the test programs pointing to the
appropriate DBRM member?



"Polley, Mike (M.)" wrote:



> We're using 'Change Man' by Serena (a migration package - if you haven't

> heard of it, no problem.) You may know the answer to my question without

> being a Change Man expert. However, if you use it, you may better

> understand this dilemma. This is OS/390 DB2 Version 6.

> Using 'Change Man' (usually) when you move a DB2 program to prod,

> you would have bound it in test first. Wherein 'Change Man' just moves
this

> to prod without recompiling. Thereby keeping the test and prod in sync.

> However, because of urgency (prod abends) an application group moved a
bunch

> of DB2 programs to prod, without binding them to test. Now prod and test

> are out of sync. So, the groups ideal is to move the programs to prod
again

> to fix test. Which it would, but it's quite a few programs.

>

> My Question is whether or not I could just update the catalog tables

> syspackage, sysdbrm, sysplan, with the same entries from prod, to put them

> back in sync? Or are there just too many catalog entries that I would
miss

> (i.e. in other tables I didn't mention) to remedy this. Because from what
I

> can see is that all the programs they are now getting -805 on are the ones

> that don't have an entry in test to match prod. As do the other programs.

> Am I missing a lot here, or is there something else I need to clarify?

> Thanks in advance for any help or suggestion.

>

>

>













Scott Trometer

Re: Catalog entries
(in response to Mike (M.) Polley)
I think what Dallas is saying is that once you move your programs to
production you can bind them to your production DB2 subsystem(using your
PROD bind parameters/collections) AND subsequently to your test DB2
subsystem(s) (using TEST bind parms/collections) all while using the same
DBRM.

Example:

//DBRMLIB DD DSN=PROD.DBRMLIB
//SYSTSIN DD *

BIND PACKAGE(PROD_COL) +
QUALIFIER (P) +
OWNER (Powner) +
MEMBER (ProgramA) +
ETC.

BIND PACKAGE(TEST_COL) +
QUALIFIER (T1) +
OWNER (Towner) +
MEMBER (ProgramA) +
ETC.



-----Original Message-----
From: Polley, Mike (M.) [mailto:[login to unmask email]
Sent: Wednesday, January 10, 2001 7:50 AM
To: [login to unmask email]
Subject: Re: Catalog entries


Yes, In order to bind application programs, they must exists within what is
called a package. Then the collection id would be named from that
particular package, and still be out of sync with prod because of the
collection id. So, the only way to get them in sync is to move the test
package to prod. Thanks for the help.



-----Original Message-----
From: Dallas Focht [mailto:[login to unmask email]
Sent: Tuesday, January 09, 2001 6:39 PM
To: [login to unmask email]
Subject: Re: Catalog entries


Is there a reason you can not bind the test programs pointing to the
appropriate DBRM member?



Scott Trometer

Re: Catalog entries
(in response to Scott Trometer)
Original example may have been misleading...see below for clarification

-----Original Message-----
From: Trometer, Scott
Sent: Wednesday, January 10, 2001 8:16 AM
To: 'DB2 Data Base Discussion List'
Subject: RE: Catalog entries


I think what Dallas is saying is that once you move your programs to
production you can bind them to your production DB2 subsystem(using your
PROD bind parameters/collections) AND subsequently to your test DB2
subsystem(s) (using TEST bind parms/collections) all while using the same
DBRM.

Example:

//DBRMLIB DD DSN=PROD.DBRMLIB
//SYSTSIN DD *

DSN SYSTEM (DB2P)
BIND PACKAGE(PROD_COL) +
QUALIFIER (P1) +
OWNER (Powner) +
MEMBER (ProgramA) +
ETC.

FOLLOWED BY...

//DBRMLIB DD DSN=PROD.DBRMLIB
//SYSTSIN DD *

DSN SYSTEM (DB2T)
BIND PACKAGE(TEST_COL) +
QUALIFIER (T1) +
OWNER (Towner) +
MEMBER (ProgramA) +
ETC.



-----Original Message-----
From: Polley, Mike (M.) [mailto:[login to unmask email]
Sent: Wednesday, January 10, 2001 7:50 AM
To: [login to unmask email]
Subject: Re: Catalog entries


Yes, In order to bind application programs, they must exists within what is
called a package. Then the collection id would be named from that
particular package, and still be out of sync with prod because of the
collection id. So, the only way to get them in sync is to move the test
package to prod. Thanks for the help.



-----Original Message-----
From: Dallas Focht [mailto:[login to unmask email]
Sent: Tuesday, January 09, 2001 6:39 PM
To: [login to unmask email]
Subject: Re: Catalog entries


Is there a reason you can not bind the test programs pointing to the
appropriate DBRM member?



Mike (M.) Polley

Re: Catalog entries
(in response to Scott Trometer)
Ok thanks, however, no binds are run outside of Change Man in prod or test
for applications. To bind in test the program must be in a package. Then
the collection id is named from this package name. Change Man is set to use
this package name. Once the package has moved to prod it's gone and cannot
be recreated in test. We're long past this problem now, but thanks for your
good suggestions, and clarifications. Hold the others for our next problem.
thanks
-----Original Message-----
From: Scott Trometer [mailto:[login to unmask email]
Sent: Wednesday, January 10, 2001 8:16 AM
To: [login to unmask email]
Subject: Re: Catalog entries



I think what Dallas is saying is that once you move your programs to
production you can bind them to your production DB2 subsystem(using your
PROD bind parameters/collections) AND subsequently to your test DB2
subsystem(s) (using TEST bind parms/collections) all while using the same
DBRM.

Example:

//DBRMLIB DD DSN=PROD.DBRMLIB
//SYSTSIN DD *

BIND PACKAGE(PROD_COL) +
QUALIFIER (P) +
OWNER (Powner) +
MEMBER (ProgramA) +
ETC.

BIND PACKAGE(TEST_COL) +
QUALIFIER (T1) +
OWNER (Towner) +
MEMBER (ProgramA) +
ETC.



-----Original Message-----
From: Polley, Mike (M.) [ mailto:[login to unmask email] <mailto:[login to unmask email]>
]
Sent: Wednesday, January 10, 2001 7:50 AM
To: [login to unmask email]
Subject: Re: Catalog entries


Yes, In order to bind application programs, they must exists within what is
called a package. Then the collection id would be named from that
particular package, and still be out of sync with prod because of the
collection id. So, the only way to get them in sync is to move the test
package to prod. Thanks for the help.



-----Original Message-----
From: Dallas Focht [ mailto:[login to unmask email]
<mailto:[login to unmask email]> ]
Sent: Tuesday, January 09, 2001 6:39 PM
To: [login to unmask email]
Subject: Re: Catalog entries


Is there a reason you can not bind the test programs pointing to the
appropriate DBRM member?