Incremental Image copy

Burgess Evans

Incremental Image copy
Hi all,

I am working on a back up plan for all user data in a DB2 subsystem. We are using the IBM utilities for DB2 V7 on z/OS 1.4. I need some options for my back-up plan which I am hoping will include conditional incremental image copies.

All our current imagecopy backups are fullimage copies so this is my first venture into incremental copies. In doing so I read about incremental copies and conditional copies in the DB2 Utility and Reference Guide. The guide states that the REPORTONLY parameter will signal a return code and that code could be used in following steps to take the desired action for that code (to copy or not to copy). The guide also states:

"If you specify multiple copy statements in one job step, that job step will report the highest return code from all of
the imbedded statements. Basically, the statement with the highest percentage of changed pages determines the return
code and the recommended action against the entire list of COPY statements contained in the subsequent job step."

The guide also mentions that when you use REPORTONLY you can avoid cataloging a data set by dumming out the SYSCOPY DD card.

My testing has confirmed that all this is true.

My problem is that I want to copy only those tablespaces that have changed by using the CHANGELIMIT parameter and I want to use the LISTDEF function for each database and use a wild card for the tablespace names such as:
LISTDEF DSN8D71A
INCLUDE TABLESPACES
TABLESPACE DSN8D71A.*

If I do that, then any tablespace in DSN8D71A that needs to be copied will set the return code signaling a copy for all DSN8D71A tablespaces not just the one that has changed.

It looks to me as though my options are:
1. Use the CHANGELIMIT and REPORTONLY parameters and send the output to a flat file which I can then read with SAS or REXX and create another input file with the copy statements for just the tablespaces requiring an imagecopy.
2. Use the CHANGELIMIT and REPORTONLY parameters and let DB2 create the imagecopies and catalog all datasets regardless of the fact that they are empty or not.

I have thought about the advantages and disadvantages of each option. I am not completely happy with either solution. What I would like to end up with is a solution that is easy to maintain and fix if problems should arise. I would also like to avoid cataloging empty data sets.

What I am hoping for is that someone might have another alternative I have not mentioned. Please keep in mind that I am restricted to using products we already own such as the IBM Utility Suite, REXX, and SAS.

Thank you,
Burgess Evans, DB2/Oracle Database Administrator

---------------------------------------------------------------------------------
Welcome to the IDUG DB2-L list. To unsubscribe, go to the archives and home page at http://www.idugdb2-l.org/archives/db2-l.html. From that page select "Join or Leave the list". If you will be out of the office, send the SET DB2-L NO MAIL command to [login to unmask email] The IDUG List Admins can be reached at [login to unmask email] Find out the latest on IDUG conferences at http://conferences.idug.org/index.cfm

Aurora Dellanno

Re: Incremental Image copy
(in response to Burgess Evans)
This is probably not going to be very helpful to you, but I was just
wondering if you are only running the IBM utilities or whether instead you
have the help of some vendor tools.

The majority of 3rd party (non-IBM) tools, allow you to be much more
selective and specific in your IC strategy and needs.

ciao!

Aurora Emanuela Dell'Anno
Database Analyst
Data Services Group - Bank of America
tel. 66192
ext. 0208 760 6192
[login to unmask email]

* std. disclaimer * MY OPINIONS ARE MY OWN AND NOT THOSE OF MY EMPLOYER

no trees were killed in sending this message. However, a large number of
electrons were seriously inconvenienced :-)



-----Original Message-----
From: Burgess Evans [mailto:[login to unmask email]
Sent: 12 December 2003 16:34
To: [login to unmask email]
Subject: Incremental Image copy


Hi all,

I am working on a back up plan for all user data in a DB2 subsystem. We are
using the IBM utilities for DB2 V7 on z/OS 1.4. I need some options for my
back-up plan which I am hoping will include conditional incremental image
copies.

All our current imagecopy backups are fullimage copies so this is my first
venture into incremental copies. In doing so I read about incremental copies
and conditional copies in the DB2 Utility and Reference Guide. The guide
states that the REPORTONLY parameter will signal a return code and that code
could be used in following steps to take the desired action for that code
(to copy or not to copy). The guide also states:

"If you specify multiple copy statements in one
job step, that job step will report the highest return code from all of
the imbedded statements. Basically, the
statement with the highest percentage of changed pages determines the return

code and the recommended action against the
entire list of COPY statements contained in the subsequent job step."

The guide also mentions that when you use REPORTONLY you can avoid
cataloging a data set by dumming out the SYSCOPY DD card.

My testing has confirmed that all this is true.

My problem is that I want to copy only those tablespaces that have changed
by using the CHANGELIMIT parameter and I want to use the LISTDEF function
for each database and use a wild card for the tablespace names such as:
LISTDEF DSN8D71A
INCLUDE TABLESPACES
TABLESPACE DSN8D71A.*

If I do that, then any tablespace in DSN8D71A that needs to be copied will
set the return code signaling a copy for all DSN8D71A tablespaces not just
the one that has changed.

It looks to me as though my options are:
1. Use the CHANGELIMIT and REPORTONLY parameters and send the output to a
flat file which I can then read with SAS or REXX and create another input
file with the copy statements for just the tablespaces requiring an
imagecopy.
2. Use the CHANGELIMIT and REPORTONLY parameters and let DB2 create the
imagecopies and catalog all datasets regardless of the fact that they are
empty or not.

I have thought about the advantages and disadvantages of each option. I am
not completely happy with either solution. What I would like to end up with
is a solution that is easy to maintain and fix if problems should arise. I
would also like to avoid cataloging empty data sets.

What I am hoping for is that someone might have another alternative I have
not mentioned. Please keep in mind that I am restricted to using products we
already own such as the IBM Utility Suite, REXX, and SAS.

Thank you,
Burgess Evans, DB2/Oracle Database Administrator

----------------------------------------------------------------------------
-----
Welcome to the IDUG DB2-L list. To unsubscribe, go to the archives and home
page at http://www.idugdb2-l.org/archives/db2-l.html. From that page select
"Join or Leave the list". If you will be out of the office, send the SET
DB2-L NO MAIL command to [login to unmask email] The IDUG List Admins
can be reached at [login to unmask email] Find out the latest on
IDUG conferences at http://conferences.idug.org/index.cfm

Notice to recipient:
The information in this internet e-mail and any attachments is confidential
and may be privileged. It is intended solely for the addressee. If you are
not the intended addressee please notify the sender immediately by
telephone. If you are not the intended recipient, any disclosure, copying,
distribution or any action taken or omitted to be taken in reliance on it,
is prohibited and may be unlawful.
When addressed to external clients any opinions or advice contained in this
internet e-mail are subject to the terms and conditions expressed in any
applicable governing terms of business or client engagement letter issued by
the pertinent Bank of America group entity.
If this email originates from the U.K. please note that Bank of America,
N.A., London Branch, Banc of America Securities Limited and Banc of America
Futures Incorporated are regulated by the Financial Services Authority.

---------------------------------------------------------------------------------
Welcome to the IDUG DB2-L list. To unsubscribe, go to the archives and home page at http://www.idugdb2-l.org/archives/db2-l.html. From that page select "Join or Leave the list". If you will be out of the office, send the SET DB2-L NO MAIL command to [login to unmask email] The IDUG List Admins can be reached at [login to unmask email] Find out the latest on IDUG conferences at http://conferences.idug.org/index.cfm

Burgess Evans

Re: Incremental Image copy
(in response to Aurora Dellanno)
Hi Aurora,

You are correct, we are only running the IBM utilities. I have a bad feeling that I am going to have to code a REXX or SAS program.

Thank you,
Burgess

>>> [login to unmask email] 12/16/03 07:33AM >>>
This is probably not going to be very helpful to you, but I was just
wondering if you are only running the IBM utilities or whether instead you
have the help of some vendor tools.

The majority of 3rd party (non-IBM) tools, allow you to be much more
selective and specific in your IC strategy and needs.

ciao!

Aurora Emanuela Dell'Anno
Database Analyst
Data Services Group - Bank of America
tel. 66192
ext. 0208 760 6192
[login to unmask email]

* std. disclaimer * MY OPINIONS ARE MY OWN AND NOT THOSE OF MY EMPLOYER

no trees were killed in sending this message. However, a large number of
electrons were seriously inconvenienced :-)



-----Original Message-----
From: Burgess Evans [mailto:[login to unmask email]
Sent: 12 December 2003 16:34
To: [login to unmask email]
Subject: Incremental Image copy


Hi all,

I am working on a back up plan for all user data in a DB2 subsystem. We are
using the IBM utilities for DB2 V7 on z/OS 1.4. I need some options for my
back-up plan which I am hoping will include conditional incremental image
copies.

All our current imagecopy backups are fullimage copies so this is my first
venture into incremental copies. In doing so I read about incremental copies
and conditional copies in the DB2 Utility and Reference Guide. The guide
states that the REPORTONLY parameter will signal a return code and that code
could be used in following steps to take the desired action for that code
(to copy or not to copy). The guide also states:

"If you specify multiple copy statements in one
job step, that job step will report the highest return code from all of
the imbedded statements. Basically, the
statement with the highest percentage of changed pages determines the return

code and the recommended action against the
entire list of COPY statements contained in the subsequent job step."

The guide also mentions that when you use REPORTONLY you can avoid
cataloging a data set by dumming out the SYSCOPY DD card.

My testing has confirmed that all this is true.

My problem is that I want to copy only those tablespaces that have changed
by using the CHANGELIMIT parameter and I want to use the LISTDEF function
for each database and use a wild card for the tablespace names such as:
LISTDEF DSN8D71A
INCLUDE TABLESPACES
TABLESPACE DSN8D71A.*

If I do that, then any tablespace in DSN8D71A that needs to be copied will
set the return code signaling a copy for all DSN8D71A tablespaces not just
the one that has changed.

It looks to me as though my options are:
1. Use the CHANGELIMIT and REPORTONLY parameters and send the output to a
flat file which I can then read with SAS or REXX and create another input
file with the copy statements for just the tablespaces requiring an
imagecopy.
2. Use the CHANGELIMIT and REPORTONLY parameters and let DB2 create the
imagecopies and catalog all datasets regardless of the fact that they are
empty or not.

I have thought about the advantages and disadvantages of each option. I am
not completely happy with either solution. What I would like to end up with
is a solution that is easy to maintain and fix if problems should arise. I
would also like to avoid cataloging empty data sets.

What I am hoping for is that someone might have another alternative I have
not mentioned. Please keep in mind that I am restricted to using products we
already own such as the IBM Utility Suite, REXX, and SAS.

Thank you,
Burgess Evans, DB2/Oracle Database Administrator

----------------------------------------------------------------------------
-----
Welcome to the IDUG DB2-L list. To unsubscribe, go to the archives and home
page at http://www.idugdb2-l.org/archives/db2-l.html. From that page select
"Join or Leave the list". If you will be out of the office, send the SET
DB2-L NO MAIL command to [login to unmask email] The IDUG List Admins
can be reached at [login to unmask email] Find out the latest on
IDUG conferences at http://conferences.idug.org/index.cfm

Notice to recipient:
The information in this internet e-mail and any attachments is confidential
and may be privileged. It is intended solely for the addressee. If you are
not the intended addressee please notify the sender immediately by
telephone. If you are not the intended recipient, any disclosure, copying,
distribution or any action taken or omitted to be taken in reliance on it,
is prohibited and may be unlawful.
When addressed to external clients any opinions or advice contained in this
internet e-mail are subject to the terms and conditions expressed in any
applicable governing terms of business or client engagement letter issued by
the pertinent Bank of America group entity.
If this email originates from the U.K. please note that Bank of America,
N.A., London Branch, Banc of America Securities Limited and Banc of America
Futures Incorporated are regulated by the Financial Services Authority.

---------------------------------------------------------------------------------
Welcome to the IDUG DB2-L list. To unsubscribe, go to the archives and home page at http://www.idugdb2-l.org/archives/db2-l.html. From that page select "Join or Leave the list". If you will be out of the office, send the SET DB2-L NO MAIL command to [login to unmask email] The IDUG List Admins can be reached at [login to unmask email] Find out the latest on IDUG conferences at http://conferences.idug.org/index.cfm

---------------------------------------------------------------------------------
Welcome to the IDUG DB2-L list. To unsubscribe, go to the archives and home page at http://www.idugdb2-l.org/archives/db2-l.html. From that page select "Join or Leave the list". If you will be out of the office, send the SET DB2-L NO MAIL command to [login to unmask email] The IDUG List Admins can be reached at [login to unmask email] Find out the latest on IDUG conferences at http://conferences.idug.org/index.cfm

Isaac Yassin

Re: Incremental Image copy
(in response to Burgess Evans)
Hi

I would not call it "bad".
Even though LISTDEF & TEMPLATE make life easier, I still find things that
benefit from using REXX.


Isaac Yassin

-----Original Message-----
From: DB2 Data Base Discussion List [mailto:[login to unmask email] On Behalf Of
Burgess Evans
Sent: Tuesday, December 16, 2003 2:54 PM
To: [login to unmask email]
Subject: Re: Incremental Image copy

Hi Aurora,

You are correct, we are only running the IBM utilities. I have a bad feeling
that I am going to have to code a REXX or SAS program.

Thank you,
Burgess

>>> [login to unmask email] 12/16/03 07:33AM >>>
This is probably not going to be very helpful to you, but I was just
wondering if you are only running the IBM utilities or whether instead you
have the help of some vendor tools.

The majority of 3rd party (non-IBM) tools, allow you to be much more
selective and specific in your IC strategy and needs.

ciao!

Aurora Emanuela Dell'Anno
Database Analyst
Data Services Group - Bank of America
tel. 66192
ext. 0208 760 6192
[login to unmask email]

* std. disclaimer * MY OPINIONS ARE MY OWN AND NOT THOSE OF MY EMPLOYER

no trees were killed in sending this message. However, a large number of
electrons were seriously inconvenienced :-)



-----Original Message-----
From: Burgess Evans [mailto:[login to unmask email]
Sent: 12 December 2003 16:34
To: [login to unmask email]
Subject: Incremental Image copy


Hi all,

I am working on a back up plan for all user data in a DB2 subsystem. We are
using the IBM utilities for DB2 V7 on z/OS 1.4. I need some options for my
back-up plan which I am hoping will include conditional incremental image
copies.

All our current imagecopy backups are fullimage copies so this is my first
venture into incremental copies. In doing so I read about incremental copies
and conditional copies in the DB2 Utility and Reference Guide. The guide
states that the REPORTONLY parameter will signal a return code and that code
could be used in following steps to take the desired action for that code
(to copy or not to copy). The guide also states:

"If you specify multiple copy statements in one
job step, that job step will report the highest return code from all of
the imbedded statements. Basically, the
statement with the highest percentage of changed pages determines the return

code and the recommended action against the
entire list of COPY statements contained in the subsequent job step."

The guide also mentions that when you use REPORTONLY you can avoid
cataloging a data set by dumming out the SYSCOPY DD card.

My testing has confirmed that all this is true.

My problem is that I want to copy only those tablespaces that have changed
by using the CHANGELIMIT parameter and I want to use the LISTDEF function
for each database and use a wild card for the tablespace names such as:
LISTDEF DSN8D71A
INCLUDE TABLESPACES
TABLESPACE DSN8D71A.*

If I do that, then any tablespace in DSN8D71A that needs to be copied will
set the return code signaling a copy for all DSN8D71A tablespaces not just
the one that has changed.

It looks to me as though my options are:
1. Use the CHANGELIMIT and REPORTONLY parameters and send the output to a
flat file which I can then read with SAS or REXX and create another input
file with the copy statements for just the tablespaces requiring an
imagecopy.
2. Use the CHANGELIMIT and REPORTONLY parameters and let DB2 create the
imagecopies and catalog all datasets regardless of the fact that they are
empty or not.

I have thought about the advantages and disadvantages of each option. I am
not completely happy with either solution. What I would like to end up with
is a solution that is easy to maintain and fix if problems should arise. I
would also like to avoid cataloging empty data sets.

What I am hoping for is that someone might have another alternative I have
not mentioned. Please keep in mind that I am restricted to using products we
already own such as the IBM Utility Suite, REXX, and SAS.

Thank you,
Burgess Evans, DB2/Oracle Database Administrator

----------------------------------------------------------------------------
-----
Welcome to the IDUG DB2-L list. To unsubscribe, go to the archives and home
page at http://www.idugdb2-l.org/archives/db2-l.html. From that page select
"Join or Leave the list". If you will be out of the office, send the SET
DB2-L NO MAIL command to [login to unmask email] The IDUG List Admins
can be reached at [login to unmask email] Find out the latest on
IDUG conferences at http://conferences.idug.org/index.cfm

Notice to recipient:
The information in this internet e-mail and any attachments is confidential
and may be privileged. It is intended solely for the addressee. If you are
not the intended addressee please notify the sender immediately by
telephone. If you are not the intended recipient, any disclosure, copying,
distribution or any action taken or omitted to be taken in reliance on it,
is prohibited and may be unlawful.
When addressed to external clients any opinions or advice contained in this
internet e-mail are subject to the terms and conditions expressed in any
applicable governing terms of business or client engagement letter issued by
the pertinent Bank of America group entity.
If this email originates from the U.K. please note that Bank of America,
N.A., London Branch, Banc of America Securities Limited and Banc of America
Futures Incorporated are regulated by the Financial Services Authority.

--------------------------------------------------------------------------------
-
Welcome to the IDUG DB2-L list. To unsubscribe, go to the archives and home page
at http://www.idugdb2-l.org/archives/db2-l.html. From that page select "Join or
Leave the list". If you will be out of the office, send the SET DB2-L NO MAIL
command to [login to unmask email] The IDUG List Admins can be reached at
[login to unmask email] Find out the latest on IDUG conferences at
http://conferences.idug.org/index.cfm

--------------------------------------------------------------------------------
-
Welcome to the IDUG DB2-L list. To unsubscribe, go to the archives and home page
at http://www.idugdb2-l.org/archives/db2-l.html. From that page select "Join or
Leave the list". If you will be out of the office, send the SET DB2-L NO MAIL
command to [login to unmask email] The IDUG List Admins can be reached at
[login to unmask email] Find out the latest on IDUG conferences at
http://conferences.idug.org/index.cfm

---------------------------------------------------------------------------------
Welcome to the IDUG DB2-L list. To unsubscribe, go to the archives and home page at http://www.idugdb2-l.org/archives/db2-l.html. From that page select "Join or Leave the list". If you will be out of the office, send the SET DB2-L NO MAIL command to [login to unmask email] The IDUG List Admins can be reached at [login to unmask email] Find out the latest on IDUG conferences at http://conferences.idug.org/index.cfm

Aurora Dellanno

Re: Incremental Image copy
(in response to Isaac Yassin)
Burgess,

Ok so you're stuck with the IBM utils but maybe not all is lost. If you are
running DB2 Recovery Manager I think the parm UPDPRCT=n% is what you are
looking for. This is really the local equivalent of CHANGELIM, being the
percentage threshold value that starts the IC.

/start Cut-and-paste_from_manual

For each selected table space, DRMIIC computes the percentage of pages that
have been modified since the last copy. This percentage is used for the
following reasons:

- To decide whether the incremental image copy needs to be made. A table
space that has not been updated since the last copy is ignored in the final
JCL
- To decide whether a full image copy must be done, instead of the requested
incremental image copy. Swapping to full from incremental image copy occurs
whenever the computed percentage exceeds the threshold specified in UPDPRCT
parameter.
- To calculate the size of the incremental image copy file

/end

Caveats and disabling and defaults are all documented on the manual.

HTH - or I've got the wrong end of the stick, it's one of those days today.

ciao!

Aurora Emanuela Dell'Anno
Database Analyst
Data Services Group - Bank of America
tel. 66192
ext. 0208 760 6192
[login to unmask email]

* std. disclaimer * MY OPINIONS ARE MY OWN AND NOT THOSE OF MY EMPLOYER

no trees were killed in sending this message. However, a large number of
electrons were seriously inconvenienced :-)

-----Original Message-----
From: Burgess Evans [mailto:[login to unmask email]
Sent: 16 December 2003 12:54
To: [login to unmask email]
Subject: Re: Incremental Image copy


Hi Aurora,

You are correct, we are only running the IBM utilities. I have a bad feeling
that I am going to have to code a REXX or SAS program.

Thank you,
Burgess

>>> [login to unmask email] 12/16/03 07:33AM >>>
This is probably not going to be very helpful to you, but I was just
wondering if you are only running the IBM utilities or whether instead you
have the help of some vendor tools.

The majority of 3rd party (non-IBM) tools, allow you to be much more
selective and specific in your IC strategy and needs.

ciao!

Aurora Emanuela Dell'Anno
Database Analyst
Data Services Group - Bank of America
tel. 66192
ext. 0208 760 6192
[login to unmask email]

* std. disclaimer * MY OPINIONS ARE MY OWN AND NOT THOSE OF MY EMPLOYER

no trees were killed in sending this message. However, a large number of
electrons were seriously inconvenienced :-)



-----Original Message-----
From: Burgess Evans [mailto:[login to unmask email]
Sent: 12 December 2003 16:34
To: [login to unmask email]
Subject: Incremental Image copy


Hi all,

I am working on a back up plan for all user data in a DB2 subsystem. We are
using the IBM utilities for DB2 V7 on z/OS 1.4. I need some options for my
back-up plan which I am hoping will include conditional incremental image
copies.

All our current imagecopy backups are fullimage copies so this is my first
venture into incremental copies. In doing so I read about incremental copies
and conditional copies in the DB2 Utility and Reference Guide. The guide
states that the REPORTONLY parameter will signal a return code and that code
could be used in following steps to take the desired action for that code
(to copy or not to copy). The guide also states:

"If you specify multiple copy statements in one
job step, that job step will report the highest return code from all of
the imbedded statements. Basically, the
statement with the highest percentage of changed pages determines the return

code and the recommended action against the
entire list of COPY statements contained in the subsequent job step."

The guide also mentions that when you use REPORTONLY you can avoid
cataloging a data set by dumming out the SYSCOPY DD card.

My testing has confirmed that all this is true.

My problem is that I want to copy only those tablespaces that have changed
by using the CHANGELIMIT parameter and I want to use the LISTDEF function
for each database and use a wild card for the tablespace names such as:
LISTDEF DSN8D71A
INCLUDE TABLESPACES
TABLESPACE DSN8D71A.*

If I do that, then any tablespace in DSN8D71A that needs to be copied will
set the return code signaling a copy for all DSN8D71A tablespaces not just
the one that has changed.

It looks to me as though my options are:
1. Use the CHANGELIMIT and REPORTONLY parameters and send the output to a
flat file which I can then read with SAS or REXX and create another input
file with the copy statements for just the tablespaces requiring an
imagecopy.
2. Use the CHANGELIMIT and REPORTONLY parameters and let DB2 create the
imagecopies and catalog all datasets regardless of the fact that they are
empty or not.

I have thought about the advantages and disadvantages of each option. I am
not completely happy with either solution. What I would like to end up with
is a solution that is easy to maintain and fix if problems should arise. I
would also like to avoid cataloging empty data sets.

What I am hoping for is that someone might have another alternative I have
not mentioned. Please keep in mind that I am restricted to using products we
already own such as the IBM Utility Suite, REXX, and SAS.

Thank you,
Burgess Evans, DB2/Oracle Database Administrator

Notice to recipient:
The information in this internet e-mail and any attachments is confidential
and may be privileged. It is intended solely for the addressee. If you are
not the intended addressee please notify the sender immediately by
telephone. If you are not the intended recipient, any disclosure, copying,
distribution or any action taken or omitted to be taken in reliance on it,
is prohibited and may be unlawful.
When addressed to external clients any opinions or advice contained in this
internet e-mail are subject to the terms and conditions expressed in any
applicable governing terms of business or client engagement letter issued by
the pertinent Bank of America group entity.
If this email originates from the U.K. please note that Bank of America,
N.A., London Branch, Banc of America Securities Limited and Banc of America
Futures Incorporated are regulated by the Financial Services Authority.

---------------------------------------------------------------------------------
Welcome to the IDUG DB2-L list. To unsubscribe, go to the archives and home page at http://www.idugdb2-l.org/archives/db2-l.html. From that page select "Join or Leave the list". If you will be out of the office, send the SET DB2-L NO MAIL command to [login to unmask email] The IDUG List Admins can be reached at [login to unmask email] Find out the latest on IDUG conferences at http://conferences.idug.org/index.cfm

Burgess Evans

Re: Incremental Image copy
(in response to Aurora Dellanno)
Hi Aurora,

Thank you for your suggestion. I did not think of Recovery Manager. I will check into it and see if that will do it.

Thank you again,
Burgess

>>> [login to unmask email] 12/16/03 11:46AM >>>
Burgess,

Ok so you're stuck with the IBM utils but maybe not all is lost. If you are
running DB2 Recovery Manager I think the parm UPDPRCT=n% is what you are
looking for. This is really the local equivalent of CHANGELIM, being the
percentage threshold value that starts the IC.

/start Cut-and-paste_from_manual

For each selected table space, DRMIIC computes the percentage of pages that
have been modified since the last copy. This percentage is used for the
following reasons:

- To decide whether the incremental image copy needs to be made. A table
space that has not been updated since the last copy is ignored in the final
JCL
- To decide whether a full image copy must be done, instead of the requested
incremental image copy. Swapping to full from incremental image copy occurs
whenever the computed percentage exceeds the threshold specified in UPDPRCT
parameter.
- To calculate the size of the incremental image copy file

/end

Caveats and disabling and defaults are all documented on the manual.

HTH - or I've got the wrong end of the stick, it's one of those days today.

ciao!

Aurora Emanuela Dell'Anno
Database Analyst
Data Services Group - Bank of America
tel. 66192
ext. 0208 760 6192
[login to unmask email]

* std. disclaimer * MY OPINIONS ARE MY OWN AND NOT THOSE OF MY EMPLOYER

no trees were killed in sending this message. However, a large number of
electrons were seriously inconvenienced :-)

-----Original Message-----
From: Burgess Evans [mailto:[login to unmask email]
Sent: 16 December 2003 12:54
To: [login to unmask email]
Subject: Re: Incremental Image copy


Hi Aurora,

You are correct, we are only running the IBM utilities. I have a bad feeling
that I am going to have to code a REXX or SAS program.

Thank you,
Burgess

>>> [login to unmask email] 12/16/03 07:33AM >>>
This is probably not going to be very helpful to you, but I was just
wondering if you are only running the IBM utilities or whether instead you
have the help of some vendor tools.

The majority of 3rd party (non-IBM) tools, allow you to be much more
selective and specific in your IC strategy and needs.

ciao!

Aurora Emanuela Dell'Anno
Database Analyst
Data Services Group - Bank of America
tel. 66192
ext. 0208 760 6192
[login to unmask email]

* std. disclaimer * MY OPINIONS ARE MY OWN AND NOT THOSE OF MY EMPLOYER

no trees were killed in sending this message. However, a large number of
electrons were seriously inconvenienced :-)



-----Original Message-----
From: Burgess Evans [mailto:[login to unmask email]
Sent: 12 December 2003 16:34
To: [login to unmask email]
Subject: Incremental Image copy


Hi all,

I am working on a back up plan for all user data in a DB2 subsystem. We are
using the IBM utilities for DB2 V7 on z/OS 1.4. I need some options for my
back-up plan which I am hoping will include conditional incremental image
copies.

All our current imagecopy backups are fullimage copies so this is my first
venture into incremental copies. In doing so I read about incremental copies
and conditional copies in the DB2 Utility and Reference Guide. The guide
states that the REPORTONLY parameter will signal a return code and that code
could be used in following steps to take the desired action for that code
(to copy or not to copy). The guide also states:

"If you specify multiple copy statements in one
job step, that job step will report the highest return code from all of
the imbedded statements. Basically, the
statement with the highest percentage of changed pages determines the return

code and the recommended action against the
entire list of COPY statements contained in the subsequent job step."

The guide also mentions that when you use REPORTONLY you can avoid
cataloging a data set by dumming out the SYSCOPY DD card.

My testing has confirmed that all this is true.

My problem is that I want to copy only those tablespaces that have changed
by using the CHANGELIMIT parameter and I want to use the LISTDEF function
for each database and use a wild card for the tablespace names such as:
LISTDEF DSN8D71A
INCLUDE TABLESPACES
TABLESPACE DSN8D71A.*

If I do that, then any tablespace in DSN8D71A that needs to be copied will
set the return code signaling a copy for all DSN8D71A tablespaces not just
the one that has changed.

It looks to me as though my options are:
1. Use the CHANGELIMIT and REPORTONLY parameters and send the output to a
flat file which I can then read with SAS or REXX and create another input
file with the copy statements for just the tablespaces requiring an
imagecopy.
2. Use the CHANGELIMIT and REPORTONLY parameters and let DB2 create the
imagecopies and catalog all datasets regardless of the fact that they are
empty or not.

I have thought about the advantages and disadvantages of each option. I am
not completely happy with either solution. What I would like to end up with
is a solution that is easy to maintain and fix if problems should arise. I
would also like to avoid cataloging empty data sets.

What I am hoping for is that someone might have another alternative I have
not mentioned. Please keep in mind that I am restricted to using products we
already own such as the IBM Utility Suite, REXX, and SAS.

Thank you,
Burgess Evans, DB2/Oracle Database Administrator

Notice to recipient:
The information in this internet e-mail and any attachments is confidential
and may be privileged. It is intended solely for the addressee. If you are
not the intended addressee please notify the sender immediately by
telephone. If you are not the intended recipient, any disclosure, copying,
distribution or any action taken or omitted to be taken in reliance on it,
is prohibited and may be unlawful.
When addressed to external clients any opinions or advice contained in this
internet e-mail are subject to the terms and conditions expressed in any
applicable governing terms of business or client engagement letter issued by
the pertinent Bank of America group entity.
If this email originates from the U.K. please note that Bank of America,
N.A., London Branch, Banc of America Securities Limited and Banc of America
Futures Incorporated are regulated by the Financial Services Authority.

---------------------------------------------------------------------------------
Welcome to the IDUG DB2-L list. To unsubscribe, go to the archives and home page at http://www.idugdb2-l.org/archives/db2-l.html. From that page select "Join or Leave the list". If you will be out of the office, send the SET DB2-L NO MAIL command to [login to unmask email] The IDUG List Admins can be reached at [login to unmask email] Find out the latest on IDUG conferences at http://conferences.idug.org/index.cfm

---------------------------------------------------------------------------------
Welcome to the IDUG DB2-L list. To unsubscribe, go to the archives and home page at http://www.idugdb2-l.org/archives/db2-l.html. From that page select "Join or Leave the list". If you will be out of the office, send the SET DB2-L NO MAIL command to [login to unmask email] The IDUG List Admins can be reached at [login to unmask email] Find out the latest on IDUG conferences at http://conferences.idug.org/index.cfm

Robert Lawrence

Re: Incremental Image copy
(in response to Burgess Evans)
Burgess,
I have done this with a REXX routine and conditional JCL. It depends on how comfortable
you are with REXX and JCL. I have not completely implemented the process yet due to the
Christmas season(no noncritical changes in retail now) so I do not want to post any
specific code. This is my technique:

Job step 1: Delete work datasets
2: REXX routine to determine day of week and set return code for later
processing(1 through 7)
3: Create listdef dataset
4: Run IC changelimit reportonly listing output to a dataset
5: Process listing dataset with REXX routine that
a) checks message id's and splits into 2 stem variables
Tablespaces which meet IIC criteria
Tablespaces which meet FIC criteria
b) sets return code based on results of the split
RC = 0 -- no image copies to be done
1 -- incremental image copies only to be done
2 -- full image copies only to be done
3 -- both incremental and full image copies to be done
6: if RC = 1 or 3 from step 5 then do incremental image copies for listdef
dataset 5.a
followed by a mergecopy newcopy no for the
same listdef
7: if RC = 2 or 3 from step 5 then do full image copies for listdef dataset
5.b
8: if then RC from step 2 is equal to value in if clause then do a
mergecopy newcopy yes for listdef dataset
from step 3 to create a recent full image copy for any
tablespaces with incremental image copy


Future refinements will check for small tablespaces to do full IC rather than
Incremental IC, Partitioned tablespaces
and check for large tablespaces to split between DASD and CART(VTS).


HTH and does not confuse you





Bob Lawrence
DBA
Boscov's Dept Stores LLc



> -----Original Message-----
> From: DB2 Data Base Discussion List [mailto:[login to unmask email]On
> Behalf Of Burgess Evans
> Sent: Friday, December 12, 2003 11:34 AM
> To: [login to unmask email]
> Subject: Incremental Image copy
>
>
> Hi all,
>
> I am working on a back up plan for all user data in a DB2 subsystem. We are
> using the IBM utilities for DB2 V7 on z/OS 1.4. I need some options for my
> back-up plan which I am hoping will include conditional incremental image copies.
>
> All our current imagecopy backups are fullimage copies so this is my first
> venture into incremental copies. In doing so I read about incremental copies
> and conditional copies in the DB2 Utility and Reference Guide. The guide states
> that the REPORTONLY parameter will signal a return code and that code could be
> used in following steps to take the desired action for that code (to copy or
> not to copy). The guide also states:
>
> "If you specify multiple copy statements in one job
> step, that job step will report the highest return code from all of
> the imbedded statements. Basically, the statement
> with the highest percentage of changed pages determines the return
> code and the recommended action against the entire
> list of COPY statements contained in the subsequent job step."
>
> The guide also mentions that when you use REPORTONLY you can avoid cataloging a
> data set by dumming out the SYSCOPY DD card.
>
> My testing has confirmed that all this is true.
>
> My problem is that I want to copy only those tablespaces that have changed by
> using the CHANGELIMIT parameter and I want to use the LISTDEF function for each
> database and use a wild card for the tablespace names such as:
> LISTDEF DSN8D71A
> INCLUDE TABLESPACES
> TABLESPACE DSN8D71A.*
>
> If I do that, then any tablespace in DSN8D71A that needs to be copied will set
> the return code signaling a copy for all DSN8D71A tablespaces not just the one
> that has changed.
>
> It looks to me as though my options are:
> 1. Use the CHANGELIMIT and REPORTONLY parameters and send the output to a flat
> file which I can then read with SAS or REXX and create another input file with
> the copy statements for just the tablespaces requiring an imagecopy.
> 2. Use the CHANGELIMIT and REPORTONLY parameters and let DB2 create the
> imagecopies and catalog all datasets regardless of the fact that they are empty or not.
>
> I have thought about the advantages and disadvantages of each option. I am not
> completely happy with either solution. What I would like to end up with is a
> solution that is easy to maintain and fix if problems should arise. I would
> also like to avoid cataloging empty data sets.
>
> What I am hoping for is that someone might have another alternative I have not
> mentioned. Please keep in mind that I am restricted to using products we
> already own such as the IBM Utility Suite, REXX, and SAS.
>
> Thank you,
> Burgess Evans, DB2/Oracle Database Administrator
>
> ---------------------------------------------------------------------------------
> Welcome to the IDUG DB2-L list. To unsubscribe, go to the archives and home
> page at http://www.idugdb2-l.org/archives/db2-l.html. From that page select
> "Join or Leave the list". If you will be out of the office, send the SET DB2-L
> NO MAIL command to [login to unmask email] The IDUG List Admins can be
> reached at [login to unmask email] Find out the latest on IDUG
> conferences at http://conferences.idug.org/index.cfm
>

---------------------------------------------------------------------------------
Welcome to the IDUG DB2-L list. To unsubscribe, go to the archives and home page at http://www.idugdb2-l.org/archives/db2-l.html. From that page select "Join or Leave the list". If you will be out of the office, send the SET DB2-L NO MAIL command to [login to unmask email] The IDUG List Admins can be reached at [login to unmask email] Find out the latest on IDUG conferences at http://conferences.idug.org/index.cfm