cleaning up obsolete packages...

Tonmoy Dasgupta

cleaning up obsolete packages...
Dear List,

I have sizable number of obsolete packages and need to rid my
catalog/directory off them. I have been musing with the following four steps
and wonder if there are any holes in it...

STEP 1) prepare rebind statements for all packages (rows that show up) in
sysibm.syspackage where operative = 'Y' and valid in ('A', 'N')
STEP 2) execute above rebind statements
STEP 3) prepare free package statements for all packages in
sysibm.syspackage where operative = 'N' and valid = 'N'
STEP 4) execute above free statements.

TIA.

Tonmoy Dasgupta
State of Arkansas,
Database Administration
Department of Information Systems.
Ph: (501)-682-5109



Judy Peddycoart

Re: cleaning up obsolete packages...
(in response to Tonmoy Dasgupta)
Tonmoy,

I am in the process of testing a program right now that will do what you are
discussing. I approached it from a little different angle, though. We are
also concerned with controlling the number of packages that are created in
our development environment during testing, as well as the number of "old"
packages that may exist in production. We decided that three versions of
any package should be sufficient to retain in any of our environments (that
allows you to move in a new version, retain the current version for fall
back, and one more for insurance purposes). So, we free any packages where
more than three versions exist, or that have been marked invalid for a
period of time.

My basic logic does a select against SYSIBM.SYSPACKAGES, sorting the data by
collection id, package name, and timestamp in descending order. I do the
checking logic above, and write out the statements to a file. The file is
then used as input to a step that executes DB2 commands in batch.

Anyway, that's our basic process. I'm not sure I understand why you are
doing the rebind at the beginning of your process. Otherwise, yes, your
process will work, provided you are only interested in the invalid packages.
I do not check for the packages where operative = N.

-----Original Message-----
From: Tonmoy Dasgupta [mailto:[login to unmask email]
Sent: Tuesday, December 19, 2000 1:34 PM
To: [login to unmask email]
Subject: cleaning up obsolete packages...


Dear List,

I have sizable number of obsolete packages and need to rid my
catalog/directory off them. I have been musing with the following four steps
and wonder if there are any holes in it...

STEP 1) prepare rebind statements for all packages (rows that show up) in
sysibm.syspackage where operative = 'Y' and valid in ('A', 'N')
STEP 2) execute above rebind statements
STEP 3) prepare free package statements for all packages in
sysibm.syspackage where operative = 'N' and valid = 'N'
STEP 4) execute above free statements.

TIA.

Tonmoy Dasgupta
State of Arkansas,
Database Administration
Department of Information Systems.
Ph: (501)-682-5109








Tonmoy Dasgupta

Re: cleaning up obsolete packages...
(in response to Judy Peddycoart)
Judy,

I am doing the rebind in the begining of the process for a reason. Through
the rebinds, I want to force the packages to get a value of 'N' in the
column "OPERATIVE" of sysibm.syspackage when the SQL statements in the
package does not tally with the existing database. We have our zparms set
for autorebind...and by these rebinds I am targeting those packages which
never was allocated (executed) after being invalidated. I hope I am making
sense...

We have in place what you are planning (we also keep three versions). We
want to beyond that and plan to get rid of those programs that do not match
current database structures. With our present clean-up programs there may
well be keeping three versions of the same obsolete program....


-----Original Message-----
From: Peddycoart, Judy [mailto:[login to unmask email]
Sent: Tuesday, December 19, 2000 1:46 PM
To: [login to unmask email]
Subject: Re: cleaning up obsolete packages...


Tonmoy,

I am in the process of testing a program right now that will do what you are
discussing. I approached it from a little different angle, though. We are
also concerned with controlling the number of packages that are created in
our development environment during testing, as well as the number of "old"
packages that may exist in production. We decided that three versions of
any package should be sufficient to retain in any of our environments (that
allows you to move in a new version, retain the current version for fall
back, and one more for insurance purposes). So, we free any packages where
more than three versions exist, or that have been marked invalid for a
period of time.

My basic logic does a select against SYSIBM.SYSPACKAGES, sorting the data by
collection id, package name, and timestamp in descending order. I do the
checking logic above, and write out the statements to a file. The file is
then used as input to a step that executes DB2 commands in batch.

Anyway, that's our basic process. I'm not sure I understand why you are
doing the rebind at the beginning of your process. Otherwise, yes, your
process will work, provided you are only interested in the invalid packages.
I do not check for the packages where operative = N.

-----Original Message-----
From: Tonmoy Dasgupta [mailto:[login to unmask email]
Sent: Tuesday, December 19, 2000 1:34 PM
To: [login to unmask email]
Subject: cleaning up obsolete packages...


Dear List,

I have sizable number of obsolete packages and need to rid my
catalog/directory off them. I have been musing with the following four steps
and wonder if there are any holes in it...

STEP 1) prepare rebind statements for all packages (rows that show up) in
sysibm.syspackage where operative = 'Y' and valid in ('A', 'N')
STEP 2) execute above rebind statements
STEP 3) prepare free package statements for all packages in
sysibm.syspackage where operative = 'N' and valid = 'N'
STEP 4) execute above free statements.

TIA.

Tonmoy Dasgupta
State of Arkansas,
Database Administration
Department of Information Systems.
Ph: (501)-682-5109













Ashish Mohan

Re: cleaning up obsolete packages...
(in response to Tonmoy Dasgupta)
Tonmoy,

Before doing anything, you might want to check the VALIDATE
option on your existing packages and ensure it is VALIDATE(BIND). If your
packages are bound with VALIDATE(RUN), I suspect that after you do a Rebind,
all your Invalid packages will actually become valid and operative (rather
than becoming invalid and inoperative as you hope them to be) even if the
underlying database objects do not exist. This obviously defeats your entire
purpose of carrying out the exercise.

Though I have not tested this, I would be surprised if it
doesn't behave this way. Let us know what transpires.
Thanks.

Ashish.

-----Original Message-----
From: Tonmoy Dasgupta [SMTP:[login to unmask email]
Sent: Tuesday, December 19, 2000 12:47 PM
To: [login to unmask email]
Subject: Re: cleaning up obsolete packages...

Judy,

I am doing the rebind in the begining of the process for a reason.
Through
the rebinds, I want to force the packages to get a value of 'N' in
the
column "OPERATIVE" of sysibm.syspackage when the SQL statements in
the
package does not tally with the existing database. We have our
zparms set
for autorebind...and by these rebinds I am targeting those packages
which
never was allocated (executed) after being invalidated. I hope I am
making
sense...

We have in place what you are planning (we also keep three
versions). We
want to beyond that and plan to get rid of those programs that do
not match
current database structures. With our present clean-up programs
there may
well be keeping three versions of the same obsolete program....


-----Original Message-----
From: Peddycoart, Judy [mailto:[login to unmask email]
Sent: Tuesday, December 19, 2000 1:46 PM
To: [login to unmask email]
Subject: Re: cleaning up obsolete packages...


Tonmoy,

I am in the process of testing a program right now that will do what
you are
discussing. I approached it from a little different angle, though.
We are
also concerned with controlling the number of packages that are
created in
our development environment during testing, as well as the number of
"old"
packages that may exist in production. We decided that three
versions of
any package should be sufficient to retain in any of our
environments (that
allows you to move in a new version, retain the current version for
fall
back, and one more for insurance purposes). So, we free any
packages where
more than three versions exist, or that have been marked invalid for
a
period of time.

My basic logic does a select against SYSIBM.SYSPACKAGES, sorting the
data by
collection id, package name, and timestamp in descending order. I
do the
checking logic above, and write out the statements to a file. The
file is
then used as input to a step that executes DB2 commands in batch.

Anyway, that's our basic process. I'm not sure I understand why you
are
doing the rebind at the beginning of your process. Otherwise, yes,
your
process will work, provided you are only interested in the invalid
packages.
I do not check for the packages where operative = N.

-----Original Message-----
From: Tonmoy Dasgupta [mailto:[login to unmask email]
Sent: Tuesday, December 19, 2000 1:34 PM
To: [login to unmask email]
Subject: cleaning up obsolete packages...


Dear List,

I have sizable number of obsolete packages and need to rid my
catalog/directory off them. I have been musing with the following
four steps
and wonder if there are any holes in it...

STEP 1) prepare rebind statements for all packages (rows that show
up) in
sysibm.syspackage where operative = 'Y' and valid in ('A', 'N')
STEP 2) execute above rebind statements
STEP 3) prepare free package statements for all packages in
sysibm.syspackage where operative = 'N' and valid = 'N'
STEP 4) execute above free statements.

TIA.

Tonmoy Dasgupta
State of Arkansas,
Database Administration
Department of Information Systems.
Ph: (501)-682-5109



visit the
DB2-L webpage at http://www.ryci.com/db2-l. The owners of the list
can be




visit the
DB2-L webpage at http://www.ryci.com/db2-l. The owners of the list
can be





can



Tonmoy Dasgupta

Re: cleaning up obsolete packages...
(in response to Ashish Mohan)
Ashish,

My FREE statements would not get generated for VALIDATE(RUN) cases you cite
...which would have been OK with me...however I will incorporate your
suggestion into the predicate of by REBIND generating SQL to save on rebind
time (almost 1% of my invalidated packages have VALIDATE = 'R').

Appreciate your input.

-----Original Message-----
From: Mohan, Ashish [mailto:[login to unmask email]
Sent: Tuesday, December 19, 2000 3:07 PM
To: [login to unmask email]
Subject: Re: cleaning up obsolete packages...


Tonmoy,

Before doing anything, you might want to check the VALIDATE
option on your existing packages and ensure it is VALIDATE(BIND). If your
packages are bound with VALIDATE(RUN), I suspect that after you do a Rebind,
all your Invalid packages will actually become valid and operative (rather
than becoming invalid and inoperative as you hope them to be) even if the
underlying database objects do not exist. This obviously defeats your entire
purpose of carrying out the exercise.

Though I have not tested this, I would be surprised if it
doesn't behave this way. Let us know what transpires.
Thanks.

Ashish.

-----Original Message-----
From: Tonmoy Dasgupta [SMTP:[login to unmask email]
Sent: Tuesday, December 19, 2000 12:47 PM
To: [login to unmask email]
Subject: Re: cleaning up obsolete packages...

Judy,

I am doing the rebind in the begining of the process for a reason.
Through
the rebinds, I want to force the packages to get a value of 'N' in
the
column "OPERATIVE" of sysibm.syspackage when the SQL statements in
the
package does not tally with the existing database. We have our
zparms set
for autorebind...and by these rebinds I am targeting those packages
which
never was allocated (executed) after being invalidated. I hope I am
making
sense...

We have in place what you are planning (we also keep three
versions). We
want to beyond that and plan to get rid of those programs that do
not match
current database structures. With our present clean-up programs
there may
well be keeping three versions of the same obsolete program....


-----Original Message-----
From: Peddycoart, Judy [mailto:[login to unmask email]
Sent: Tuesday, December 19, 2000 1:46 PM
To: [login to unmask email]
Subject: Re: cleaning up obsolete packages...


Tonmoy,

I am in the process of testing a program right now that will do what
you are
discussing. I approached it from a little different angle, though.
We are
also concerned with controlling the number of packages that are
created in
our development environment during testing, as well as the number of
"old"
packages that may exist in production. We decided that three
versions of
any package should be sufficient to retain in any of our
environments (that
allows you to move in a new version, retain the current version for
fall
back, and one more for insurance purposes). So, we free any
packages where
more than three versions exist, or that have been marked invalid for
a
period of time.

My basic logic does a select against SYSIBM.SYSPACKAGES, sorting the
data by
collection id, package name, and timestamp in descending order. I
do the
checking logic above, and write out the statements to a file. The
file is
then used as input to a step that executes DB2 commands in batch.

Anyway, that's our basic process. I'm not sure I understand why you
are
doing the rebind at the beginning of your process. Otherwise, yes,
your
process will work, provided you are only interested in the invalid
packages.
I do not check for the packages where operative = N.

-----Original Message-----
From: Tonmoy Dasgupta [mailto:[login to unmask email]
Sent: Tuesday, December 19, 2000 1:34 PM
To: [login to unmask email]
Subject: cleaning up obsolete packages...


Dear List,

I have sizable number of obsolete packages and need to rid my
catalog/directory off them. I have been musing with the following
four steps
and wonder if there are any holes in it...

STEP 1) prepare rebind statements for all packages (rows that show
up) in
sysibm.syspackage where operative = 'Y' and valid in ('A', 'N')
STEP 2) execute above rebind statements
STEP 3) prepare free package statements for all packages in
sysibm.syspackage where operative = 'N' and valid = 'N'
STEP 4) execute above free statements.

TIA.

Tonmoy Dasgupta
State of Arkansas,
Database Administration
Department of Information Systems.
Ph: (501)-682-5109



visit the
DB2-L webpage at http://www.ryci.com/db2-l. The owners of the list
can be




visit the
DB2-L webpage at http://www.ryci.com/db2-l. The owners of the list
can be





can








Raymond Bell

Re: cleaning up obsolete packages...
(in response to Tonmoy Dasgupta)
Hi Tonmoy,

Every now and then I do what you're thinking of. Most of the places I've
worked try to avoid validate(run) so I've always quickly found the packages
that can safely be freed. If it's only 1% at your place you could always
take the position that a validate(run) package that's valid and operative,
even though it might refer to objects that don't exist, is acceptable.
After all, remember the 80/20 rule.

Free away!


Raymond


> -----Original Message-----
> From: Tonmoy Dasgupta [SMTP:[login to unmask email]
> Sent: Wednesday, 20 December 2000 6:34 am
> To: [login to unmask email]
> Subject: cleaning up obsolete packages...
>
> Dear List,
>
> I have sizable number of obsolete packages and need to rid my
> catalog/directory off them. I have been musing with the following four
> steps
> and wonder if there are any holes in it...
>
> STEP 1) prepare rebind statements for all packages (rows that show up) in
> sysibm.syspackage where operative = 'Y' and valid in ('A', 'N')
> STEP 2) execute above rebind statements
> STEP 3) prepare free package statements for all packages in
> sysibm.syspackage where operative = 'N' and valid = 'N'
> STEP 4) execute above free statements.
>
> TIA.
>
> Tonmoy Dasgupta
> State of Arkansas,
> Database Administration
> Department of Information Systems.
> Ph: (501)-682-5109
>
>
>
>
>



Ashish Mohan

Re: cleaning up obsolete packages...
(in response to Raymond Bell)
Probably my response didn't make it so I am sending it again...

One more thing actually.... If the owner of the package 'looses'
authority (ie authority has been revoked by someone) to execute any static
SQL in the package, the package will immediately become invalid and then, if
the package is bound with VALIDATE(BIND), as in your case, a Rebind of the
package will make it inoperative. Probably you would not want to free such
packages as the underlying database object is still there; it is only an
authority problem and I think your rebinds in such cases will fail with
-551. So, you cannot (actually should not) do a 'blanket free' for all the
invalid and inoperative packages before checking the reason why each one
became inoperative.

Unfortunately as VALIDATE option refers both to presence/absence of
database objects as well as presence/absence of authority, I don't think
there is any way to isolate the two.

Thanks.
Ashish.



-----Original Message-----
From: Bell, Raymond W [SMTP:[login to unmask email]
Sent: Tuesday, December 19, 2000 2:35 PM
To: [login to unmask email]
Subject: Re: cleaning up obsolete packages...

Hi Tonmoy,

Every now and then I do what you're thinking of. Most of the places
I've
worked try to avoid validate(run) so I've always quickly found the
packages
that can safely be freed. If it's only 1% at your place you could
always
take the position that a validate(run) package that's valid and
operative,
even though it might refer to objects that don't exist, is
acceptable.
After all, remember the 80/20 rule.

Free away!


Raymond


> -----Original Message-----
> From: Tonmoy Dasgupta [SMTP:[login to unmask email]
> Sent: Wednesday, 20 December 2000 6:34 am
> To: [login to unmask email]
> Subject: cleaning up obsolete packages...
>
> Dear List,
>
> I have sizable number of obsolete packages and need to rid my
> catalog/directory off them. I have been musing with the following
four
> steps
> and wonder if there are any holes in it...
>
> STEP 1) prepare rebind statements for all packages (rows that show
up) in
> sysibm.syspackage where operative = 'Y' and valid in ('A', 'N')
> STEP 2) execute above rebind statements
> STEP 3) prepare free package statements for all packages in
> sysibm.syspackage where operative = 'N' and valid = 'N'
> STEP 4) execute above free statements.
>
> TIA.
>
> Tonmoy Dasgupta
> State of Arkansas,
> Database Administration
> Department of Information Systems.
> Ph: (501)-682-5109
>
>
>
visit
> the DB2-L webpage at http://www.ryci.com/db2-l. The owners of the
list can
>




can



Shaun LOMBARD

Re: cleaning up obsolete packages...
(in response to Ashish Mohan)
At another site we tackled the package cleanup process by looking for the
contoken in the load library. If the contoken can not be found then there is
no way the package can run - so it gets free'd.

Shaun

-----Original Message-----
From: Mohan, Ashish [mailto:[login to unmask email]
Sent: Wednesday, 20 December 2000 9:57
To: [login to unmask email]
Subject: Re: cleaning up obsolete packages...


Probably my response didn't make it so I am sending it again...

One more thing actually.... If the owner of the package 'looses'
authority (ie authority has been revoked by someone) to execute any static
SQL in the package, the package will immediately become invalid and then, if
the package is bound with VALIDATE(BIND), as in your case, a Rebind of the
package will make it inoperative. Probably you would not want to free such
packages as the underlying database object is still there; it is only an
authority problem and I think your rebinds in such cases will fail with
-551. So, you cannot (actually should not) do a 'blanket free' for all the
invalid and inoperative packages before checking the reason why each one
became inoperative.

Unfortunately as VALIDATE option refers both to presence/absence of
database objects as well as presence/absence of authority, I don't think
there is any way to isolate the two.

Thanks.
Ashish.



-----Original Message-----
From: Bell, Raymond W [SMTP:[login to unmask email]
Sent: Tuesday, December 19, 2000 2:35 PM
To: [login to unmask email]
Subject: Re: cleaning up obsolete packages...

Hi Tonmoy,

Every now and then I do what you're thinking of. Most of the places
I've
worked try to avoid validate(run) so I've always quickly found the
packages
that can safely be freed. If it's only 1% at your place you could
always
take the position that a validate(run) package that's valid and
operative,
even though it might refer to objects that don't exist, is
acceptable.
After all, remember the 80/20 rule.

Free away!


Raymond


> -----Original Message-----
> From: Tonmoy Dasgupta [SMTP:[login to unmask email]
> Sent: Wednesday, 20 December 2000 6:34 am
> To: [login to unmask email]
> Subject: cleaning up obsolete packages...
>
> Dear List,
>
> I have sizable number of obsolete packages and need to rid my
> catalog/directory off them. I have been musing with the following
four
> steps
> and wonder if there are any holes in it...
>
> STEP 1) prepare rebind statements for all packages (rows that show
up) in
> sysibm.syspackage where operative = 'Y' and valid in ('A', 'N')
> STEP 2) execute above rebind statements
> STEP 3) prepare free package statements for all packages in
> sysibm.syspackage where operative = 'N' and valid = 'N'
> STEP 4) execute above free statements.
>
> TIA.
>
> Tonmoy Dasgupta
> State of Arkansas,
> Database Administration
> Department of Information Systems.
> Ph: (501)-682-5109
>
>
>
visit
> the DB2-L webpage at http://www.ryci.com/db2-l. The owners of the
list can
>




can








Tonmoy Dasgupta

Re: cleaning up obsolete packages...
(in response to Shaun LOMBARD)
Ashish,

You have a valid point and fortunately I had considered to leave the
packages with -551 alone among several others. After doing the rebinds I
gathered all the sqlcodes received to a file for analysis. I found that
99.95% of 50,000 odd negative sqlcodes were related to obsolosence (-204,
-206). For those packages I got dicey SQLCODES I left alone. My frees last
night got rid of 20% of the total packages. I wish losing weight was this
easy :-) ....

Thanks.

-----Original Message-----
From: Mohan, Ashish [mailto:[login to unmask email]
Sent: Tuesday, December 19, 2000 4:57 PM
To: [login to unmask email]
Subject: Re: cleaning up obsolete packages...


Probably my response didn't make it so I am sending it again...

One more thing actually.... If the owner of the package 'looses'
authority (ie authority has been revoked by someone) to execute any static
SQL in the package, the package will immediately become invalid and then, if
the package is bound with VALIDATE(BIND), as in your case, a Rebind of the
package will make it inoperative. Probably you would not want to free such
packages as the underlying database object is still there; it is only an
authority problem and I think your rebinds in such cases will fail with
-551. So, you cannot (actually should not) do a 'blanket free' for all the
invalid and inoperative packages before checking the reason why each one
became inoperative.

Unfortunately as VALIDATE option refers both to presence/absence of
database objects as well as presence/absence of authority, I don't think
there is any way to isolate the two.

Thanks.
Ashish.



-----Original Message-----
From: Bell, Raymond W [SMTP:[login to unmask email]
Sent: Tuesday, December 19, 2000 2:35 PM
To: [login to unmask email]
Subject: Re: cleaning up obsolete packages...

Hi Tonmoy,

Every now and then I do what you're thinking of. Most of the places
I've
worked try to avoid validate(run) so I've always quickly found the
packages
that can safely be freed. If it's only 1% at your place you could
always
take the position that a validate(run) package that's valid and
operative,
even though it might refer to objects that don't exist, is
acceptable.
After all, remember the 80/20 rule.

Free away!


Raymond


> -----Original Message-----
> From: Tonmoy Dasgupta [SMTP:[login to unmask email]
> Sent: Wednesday, 20 December 2000 6:34 am
> To: [login to unmask email]
> Subject: cleaning up obsolete packages...
>
> Dear List,
>
> I have sizable number of obsolete packages and need to rid my
> catalog/directory off them. I have been musing with the following
four
> steps
> and wonder if there are any holes in it...
>
> STEP 1) prepare rebind statements for all packages (rows that show
up) in
> sysibm.syspackage where operative = 'Y' and valid in ('A', 'N')
> STEP 2) execute above rebind statements
> STEP 3) prepare free package statements for all packages in
> sysibm.syspackage where operative = 'N' and valid = 'N'
> STEP 4) execute above free statements.
>
> TIA.
>
> Tonmoy Dasgupta
> State of Arkansas,
> Database Administration
> Department of Information Systems.
> Ph: (501)-682-5109
>
>
>
visit
> the DB2-L webpage at http://www.ryci.com/db2-l. The owners of the
list can
>




can








John Arbogast

Re: cleaning up obsolete packages...
(in response to Tonmoy Dasgupta)
I have used SAS to generate the rebind statements on our
large development systems. If I rebind all
invalid packages, the ones that fail become inoperative. After the rebind,
all invalid and inoperative packages are freed.
This way there is no need for a version check. In our environment, there
isn't a number of versions we can apply. We have a sysadm do the rebind, so
auth
problems aren't a consideration.

I'd be happy to share the jobs if you would like to see them...

-----Original Message-----
From: [login to unmask email]
[mailto:[login to unmask email]
Sent: Tuesday, December 19, 2000 1:34 PM
To: [login to unmask email]
Subject: cleaning up obsolete packages...


Dear List,

I have sizable number of obsolete packages and need to rid my
catalog/directory off them. I have been musing with the following four steps
and wonder if there are any holes in it...

STEP 1) prepare rebind statements for all packages (rows that show up) in
sysibm.syspackage where operative = 'Y' and valid in ('A', 'N')
STEP 2) execute above rebind statements
STEP 3) prepare free package statements for all packages in
sysibm.syspackage where operative = 'N' and valid = 'N'
STEP 4) execute above free statements.

TIA.

Tonmoy Dasgupta
State of Arkansas,
Database Administration
Department of Information Systems.
Ph: (501)-682-5109





John Arbogast

Re: cleaning up obsolete packages...
(in response to John Arbogast)
I have used SAS to generate the rebind statements on our
large development systems. If I rebind all
invalid packages, the ones that fail become inoperative. After the rebind,
all invalid and inoperative packages are freed.
This way there is no need for a version check. In our environment, there
isn't a number of versions we can apply. We have a sysadm do the rebind, so
auth
problems aren't a consideration.

I'd be happy to share the jobs if you would like to see them...

-----Original Message-----
From: [login to unmask email]
[mailto:[login to unmask email]
Sent: Tuesday, December 19, 2000 1:34 PM
To: [login to unmask email]
Subject: cleaning up obsolete packages...


Dear List,

I have sizable number of obsolete packages and need to rid my
catalog/directory off them. I have been musing with the following four steps
and wonder if there are any holes in it...

STEP 1) prepare rebind statements for all packages (rows that show up) in
sysibm.syspackage where operative = 'Y' and valid in ('A', 'N')
STEP 2) execute above rebind statements
STEP 3) prepare free package statements for all packages in
sysibm.syspackage where operative = 'N' and valid = 'N'
STEP 4) execute above free statements.

TIA.

Tonmoy Dasgupta
State of Arkansas,
Database Administration
Department of Information Systems.
Ph: (501)-682-5109