DB2 "upgrade"

Marc Matulis

DB2 "upgrade"
I need to bring our DB2 v.7.1 up-to-date on OS/390. I initially installed
our current DB2 v.7.1, but we have fallen behind considerably on
maintenance and I am now back to supporting DB2.

I have the choice of either applying 240+ PTFs or installing a new DB2
ServerPac.

Two questions.

First, which option makes more sense?

Second, having only done the one original install, what would be involved
if I install a newer v.7.1? How do I get the current Directory and
Catalog "migrated" over from current v.7.1 to new v.7.1?

Thanks in advance for any advice.



Christina S. Maldonado

Re: DB2 "upgrade"
(in response to Marc Matulis)
I would apply the PTF's and go through the normal process of maintenance.
270+ PTFs isn't too bad, just make sure you get your hold items.

Why do you say you have to update the catalog for DB2 V7? When you
installed DB2 V7 the first time, this would have been done already.


Thanks Christina.
480-391-4802





MAM
<[login to unmask email] To: [login to unmask email]
THCARE.ORG> cc:
Sent by: DB2 Data Subject: DB2 "upgrade"
Base Discussion List
<[login to unmask email]
OC.COM>


12/20/2002 03:04 PM
Please respond to DB2
Data Base Discussion
List






I need to bring our DB2 v.7.1 up-to-date on OS/390. I initially installed
our current DB2 v.7.1, but we have fallen behind considerably on
maintenance and I am now back to supporting DB2.

I have the choice of either applying 240+ PTFs or installing a new DB2
ServerPac.

Two questions.

First, which option makes more sense?

Second, having only done the one original install, what would be involved
if I install a newer v.7.1? How do I get the current Directory and
Catalog "migrated" over from current v.7.1 to new v.7.1?

Thanks in advance for any advice.



the DB2-L webpage at http://listserv.ylassoc.com. The owners of the list
can



Edward Long

Re: DB2 "upgrade"
(in response to Christina S. Maldonado)
I'd vote for the Server Pak approach since your notion
of 240 PTF's is merely the tip of the Titanic iceberg.
To put on 1 fix yesterday I ended up with 15 PTF's. At
that rate you could be in the 1000's easily.

With the ServerPak someone at IBM not paid by the Lab
has built a running DB2 system from what has been
shipped to you. With the maintenance approach, that
someone is completely you.

Since your already on V7 all your really doing is
updating libraries, including SDSNSAMP!! Its rare that
maintenance directly affects the catalog requiring
CATMAINT or other heroic measures.

The tricky part is with the 'activation' bit otherwise
known as the Hold Data, also known as the Roger Miller
full employment act,AKA, death by SPE.

A lot of the maintenance you are applying only becomes
active after a rebind, an IPL, a DB2 restart or a
ZPARM rebuild.

So, if you build your new DB2 in a sandbox; prove it
comes up and down and the samples work, then , on a
Saturday night, you bring down your test system,
replace the libraries with the ones from the sandbox,
rebind, rebuild your ZPARM, and IPL. The heathens in
the crowd will suggest avoiding these steps instead
suggesting that you delay the activation until the
next time you do each of the above. I'd rather find
out now whats not good.

After a suitable period of abuse from your application
folks, you repeat the process for the production
system. During this interval you glue yourself to
IBMLINK looking for HIPERs etc. and add them to your
mix.

Good luck and let us know what you decide and how you
do.


--- MAM <[login to unmask email]> wrote:
> I need to bring our DB2 v.7.1 up-to-date on OS/390.
> I initially installed
> our current DB2 v.7.1, but we have fallen behind
> considerably on
> maintenance and I am now back to supporting DB2.
>
> I have the choice of either applying 240+ PTFs or
> installing a new DB2
> ServerPac.
>
> Two questions.
>
> First, which option makes more sense?
>
> Second, having only done the one original install,
> what would be involved
> if I install a newer v.7.1? How do I get the
> current Directory and
> Catalog "migrated" over from current v.7.1 to new
> v.7.1?
>
> Thanks in advance for any advice.
>
>
> To change your subscription options or to cancel
> your subscription visit the DB2-L webpage at
> http://listserv.ylassoc.com. The owners of the list
> can be reached at
[login to unmask email]


=====
Edward Long



Tina Hilton

Re: DB2 "upgrade"
(in response to Edward Long)
It's not just holds that have you do a bind or something like that to
activate the request. There are sometimes holds that require you to change
things or you'll have problems or miss out on enhancements. Sometimes there
are new stored procedures or changes to stored procedures that require you
to drop and recreate them. If you use distributed processing between DB2s
or use data sharing, sometimes you need to upgrade all systems at the same
time or have some PTFs on the other systems first. All sorts of information
in the HOLD data that can prevent problems, and you wouldn't know anything
about them. I would put the maintenance on the regular way.

Tina Hilton

-----Original Message-----
From: Ed Long [mailto:[login to unmask email]
Sent: December 22, 2002 12:33 AM
To: [login to unmask email]
Subject: Re: DB2 "upgrade"


I'd vote for the Server Pak approach since your notion
of 240 PTF's is merely the tip of the Titanic iceberg.
To put on 1 fix yesterday I ended up with 15 PTF's. At
that rate you could be in the 1000's easily.

With the ServerPak someone at IBM not paid by the Lab
has built a running DB2 system from what has been
shipped to you. With the maintenance approach, that
someone is completely you.

Since your already on V7 all your really doing is
updating libraries, including SDSNSAMP!! Its rare that
maintenance directly affects the catalog requiring
CATMAINT or other heroic measures.

The tricky part is with the 'activation' bit otherwise
known as the Hold Data, also known as the Roger Miller
full employment act,AKA, death by SPE.

A lot of the maintenance you are applying only becomes
active after a rebind, an IPL, a DB2 restart or a
ZPARM rebuild.

So, if you build your new DB2 in a sandbox; prove it
comes up and down and the samples work, then , on a
Saturday night, you bring down your test system,
replace the libraries with the ones from the sandbox,
rebind, rebuild your ZPARM, and IPL. The heathens in
the crowd will suggest avoiding these steps instead
suggesting that you delay the activation until the
next time you do each of the above. I'd rather find
out now whats not good.

After a suitable period of abuse from your application
folks, you repeat the process for the production
system. During this interval you glue yourself to
IBMLINK looking for HIPERs etc. and add them to your
mix.

Good luck and let us know what you decide and how you
do.


--- MAM <[login to unmask email]> wrote:
> I need to bring our DB2 v.7.1 up-to-date on OS/390.
> I initially installed
> our current DB2 v.7.1, but we have fallen behind
> considerably on
> maintenance and I am now back to supporting DB2.
>
> I have the choice of either applying 240+ PTFs or
> installing a new DB2
> ServerPac.
>
> Two questions.
>
> First, which option makes more sense?
>
> Second, having only done the one original install,
> what would be involved
> if I install a newer v.7.1? How do I get the
> current Directory and
> Catalog "migrated" over from current v.7.1 to new
> v.7.1?
>
> Thanks in advance for any advice.
>



Cathy Taddei

Re: DB2 "upgrade"
(in response to Tina Hilton)
I would not attempt to use a ServerPac installation as a substitute for
maintenance, precisely for the reason implied by your question "How do I get
the current Directory and Catalog "migrated" over from current v.7.1 to new
v.7.1?" When you migrate a subsystem from one version to another, the
migration steps in the Install Manual will help you perform any needed
catalog changes, such as new columns, tables, stored procedures, or updated
plans. But if one of these elements was introduced by a later PTF, how
would you know which steps of which installation job you would need to
rerun, if you installed the PTF via ServerPac (where the assumption is that
you will follow the entire migration process)? On the other hand, by
applying mass maintenance you will get a neat list of holddata, which will
bore you to tears after reading a hundred "rebind to activate this change"
holds, but then you will find a "run this SPUFI" or "rerun step X of
installation job Y" that will make reading all the holds worthwhile. Two or
three hundred PTF's are nothing, and even a thousand PTF's aren't that big
compared to a botched installation.

HTH,
Cathy Taddei

-----Original Message-----
From: MAM [mailto:[login to unmask email]
Sent: Friday, December 20, 2002 2:04 PM
To: [login to unmask email]
Subject: DB2 "upgrade"


I need to bring our DB2 v.7.1 up-to-date on OS/390. I initially installed
our current DB2 v.7.1, but we have fallen behind considerably on
maintenance and I am now back to supporting DB2.

I have the choice of either applying 240+ PTFs or installing a new DB2
ServerPac.

Two questions.

First, which option makes more sense?

Second, having only done the one original install, what would be involved
if I install a newer v.7.1? How do I get the current Directory and
Catalog "migrated" over from current v.7.1 to new v.7.1?

Thanks in advance for any advice.






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

This email is confidential and may be legally privileged.

It is intended solely for the addressee. Access to this email by anyone else, unless expressly approved by the sender or an authorized addressee, is unauthorized.

If you are not the intended recipient, any disclosure, copying, distribution or any action omitted or taken in reliance on it, is prohibited and may be unlawful. If you believe that you have received this email in error, please contact the sender, delete this e-mail and destroy all copies.


=====

Edward Long

Re: DB2 "upgrade"
(in response to Cathy Taddei)
The judgement part of our job comes into play here.
The key decision points are, how back level is the
starting point? How much maintenance is missing?

I interpreted the initial email as saying that they
were very backlevel but on the same release. In that
instance, an RSU or full replacement, would be easier
and ultimately safer since the new system would have
been tested by IBM before release.

The reason I mentioned SDSNSAMP in my response was to
point out that rerunning ZPARMS and rebuilding the WZP
type SP's is now (v7) a pretty common bit of HoldData.
It perhaps wasn't as clear as it could have been.

The heart of the matter remains testing the upgraded
system before exposing production to it, regardless of
how you get there.


--- "Taddei, Cathy" <[login to unmask email]>
wrote:
> I would not attempt to use a ServerPac installation
> as a substitute for
> maintenance, precisely for the reason implied by
> your question "How do I get
> the current Directory and Catalog "migrated" over
> from current v.7.1 to new
> v.7.1?" When you migrate a subsystem from one
> version to another, the
> migration steps in the Install Manual will help you
> perform any needed
> catalog changes, such as new columns, tables, stored
> procedures, or updated
> plans. But if one of these elements was introduced
> by a later PTF, how
> would you know which steps of which installation job
> you would need to
> rerun, if you installed the PTF via ServerPac (where
> the assumption is that
> you will follow the entire migration process)? On
> the other hand, by
> applying mass maintenance you will get a neat list
> of holddata, which will
> bore you to tears after reading a hundred "rebind to
> activate this change"
> holds, but then you will find a "run this SPUFI" or
> "rerun step X of
> installation job Y" that will make reading all the
> holds worthwhile. Two or
> three hundred PTF's are nothing, and even a thousand
> PTF's aren't that big
> compared to a botched installation.
>
> HTH,
> Cathy Taddei
>
> -----Original Message-----
> From: MAM [mailto:[login to unmask email]
> Sent: Friday, December 20, 2002 2:04 PM
> To: [login to unmask email]
> Subject: DB2 "upgrade"
>
>
> I need to bring our DB2 v.7.1 up-to-date on OS/390.
> I initially installed
> our current DB2 v.7.1, but we have fallen behind
> considerably on
> maintenance and I am now back to supporting DB2.
>
> I have the choice of either applying 240+ PTFs or
> installing a new DB2
> ServerPac.
>
> Two questions.
>
> First, which option makes more sense?
>
> Second, having only done the one original install,
> what would be involved
> if I install a newer v.7.1? How do I get the
> current Directory and
> Catalog "migrated" over from current v.7.1 to new
> v.7.1?
>
> Thanks in advance for any advice.
>
>
> To change your subscription options or to cancel
> your subscription visit the
> DB2-L webpage at http://listserv.ylassoc.com. The
> owners of the list can be
>
>
>
------------------------------------------------------------------------------
>
> This email is confidential and may be legally
> privileged.
>
> It is intended solely for the addressee. Access to
> this email by anyone else, unless expressly approved
> by the sender or an authorized addressee, is
> unauthorized.
>
> If you are not the intended recipient, any
> disclosure, copying, distribution or any action
> omitted or taken in reliance on it, is prohibited
> and may be unlawful. If you believe that you have
> received this email in error, please contact the
> sender, delete this e-mail and destroy all copies.
>
>
>
=====
>


=====
Edward Long



Cathy Taddei

Re: DB2 "upgrade"
(in response to Edward Long)
Now I'm curious. I did not know IBM provided for mass maintenance for DB2
in this way. How do they inform you of changes you need to make to your
catalog? For example, looking at the last round of mass maintenance that I
did on DB2 V6: UQ55014 included an ACTION HOLD to remove orphaned rows from
SYSTABAUTH. There were several other PTF's with SPUFI's to detect bad
values in SYSTABLES, SYSROUTINES, and SYSTABLESPACE, and unique methods to
clean up any problems found. UQ47800 instructed me to run job DSNTEJ6W to
create the WLM_REFRESH stored procedure, which was new with that PTF. Would
IBM have created a package of maintenance for me with instructions to do
those things? If so, I would be very interested in that. I would never
have to read holddata again!

On the other hand, I have been in shops where I had to apply several years
worth of maintenance, and there was nothing dangerous or unusual about it.
You can break it up into smaller chunks if you want, but it's basically the
same work and the same result. Plus, you know you've done every HOLD ACTION
and read every HOLD DOC, so you have confidence in the integrity of your
system and are up to speed on the new stuff. I think it's the safest way to
go no matter how far you are behind. Or am I missing out on something? If
IBM offers actual "maintenance only upgrades", I'd be very interested!

Regards,
Cathy Taddei

-----Original Message-----
From: Ed Long [mailto:[login to unmask email]
Sent: Tuesday, December 24, 2002 6:48 AM
To: [login to unmask email]
Subject: Re: DB2 "upgrade"


The judgement part of our job comes into play here.
The key decision points are, how back level is the
starting point? How much maintenance is missing?

I interpreted the initial email as saying that they
were very backlevel but on the same release. In that
instance, an RSU or full replacement, would be easier
and ultimately safer since the new system would have
been tested by IBM before release.

The reason I mentioned SDSNSAMP in my response was to
point out that rerunning ZPARMS and rebuilding the WZP
type SP's is now (v7) a pretty common bit of HoldData.
It perhaps wasn't as clear as it could have been.

The heart of the matter remains testing the upgraded
system before exposing production to it, regardless of
how you get there.

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

This email is confidential and may be legally privileged.

It is intended solely for the addressee. Access to this email by anyone else, unless expressly approved by the sender or an authorized addressee, is unauthorized.

If you are not the intended recipient, any disclosure, copying, distribution or any action omitted or taken in reliance on it, is prohibited and may be unlawful. If you believe that you have received this email in error, please contact the sender, delete this e-mail and destroy all copies.


=====

Cathy Taddei

Re: DB2 "upgrade"
(in response to Cathy Taddei)
P.S. -- If you're concerned about putting on maintenance that has been
tested as a package by IBM, you can do it with an RSU. See
http://www-1.ibm.com/servers/eserver/zseries/zos/servicetst/ for more info.
I don't do it this way, but it's similar to applying PUT maintenance except
that you use the RSU level as sourceid instead of the PUT levels. You still
have to deal with holddata and everything else that goes along with mass
maintenance. When I do maintenance (which is not often enough), I prefer to
be more current than the RSU, which is typically at least 6 months old.
-----Original Message-----
From: Taddei, Cathy [mailto:[login to unmask email]
Sent: Tuesday, December 24, 2002 11:05 AM
To: [login to unmask email]
Subject: Re: DB2 "upgrade"


Now I'm curious. I did not know IBM provided for mass maintenance for DB2
in this way. How do they inform you of changes you need to make to your
catalog? For example, looking at the last round of mass maintenance that I
did on DB2 V6: UQ55014 included an ACTION HOLD to remove orphaned rows from
SYSTABAUTH. There were several other PTF's with SPUFI's to detect bad
values in SYSTABLES, SYSROUTINES, and SYSTABLESPACE, and unique methods to
clean up any problems found. UQ47800 instructed me to run job DSNTEJ6W to
create the WLM REFRESH stored procedure, which was new with that PTF. Would
IBM have created a package of maintenance for me with instructions to do
those things? If so, I would be very interested in that. I would never
have to read holddata again!
On the other hand, I have been in shops where I had to apply several years
worth of maintenance, and there was nothing dangerous or unusual about it.
You can break it up into smaller chunks if you want, but it's basically the
same work and the same result. Plus, you know you've done every HOLD ACTION
and read every HOLD DOC, so you have confidence in the integrity of your
system and are up to speed on the new stuff. I think it's the safest way to
go no matter how far you are behind. Or am I missing out on something? If
IBM offers actual "maintenance only upgrades", I'd be very interested!
Regards,
Cathy Taddei
-----Original Message-----
From: Ed Long [mailto:[login to unmask email]
Sent: Tuesday, December 24, 2002 6:48 AM
To: [login to unmask email]
Subject: Re: DB2 "upgrade"


The judgement part of our job comes into play here.
The key decision points are, how back level is the
starting point? How much maintenance is missing?
I interpreted the initial email as saying that they
were very backlevel but on the same release. In that
instance, an RSU or full replacement, would be easier
and ultimately safer since the new system would have
been tested by IBM before release.
The reason I mentioned SDSNSAMP in my response was to
point out that rerunning ZPARMS and rebuilding the WZP
type SP's is now (v7) a pretty common bit of HoldData.
It perhaps wasn't as clear as it could have been.
The heart of the matter remains testing the upgraded
system before exposing production to it, regardless of
how you get there.

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

This email is confidential and may be legally privileged.

It is intended solely for the addressee. Access to this email by anyone else, unless expressly approved by the sender or an authorized addressee, is unauthorized.

If you are not the intended recipient, any disclosure, copying, distribution or any action omitted or taken in reliance on it, is prohibited and may be unlawful. If you believe that you have received this email in error, please contact the sender, delete this e-mail and destroy all copies.


=====