Reclaim space of LOB

Ugandhar V

Reclaim space of LOB
HI listers
 
I am trying to release space allocated to an LOB.
 
I did a delete *  <tablename>  but still the space occupied by LOB is X tracks.
 
When i start adding few records  to the LOB the no of tracks are adding up to X+Y tracks. I was expecting DB2 to release the space occupied. Is there some thing i am doing wrong ?
 
Appreciate your help in advance.
 
Thanks and rgds.,
cnu




_____________________________________________________________________

* IDUG 09 Denver, CO, USA * May 11-15, 2009 * http://IDUG.ORG/NA *
_____________________________________________________________________

IDUG DB2-L FAQ and e-mail settings are located on the IDUG.org Listserv page.
If you are not already an IDUG.org member, please register at http://www.idug.org/component/juser/register.html
_____________________________________________________________________

Lance Jackson

Re: Reclaim space of LOB
(in response to Ugandhar V)
You'l have to REORG the LOB tablespace.


-----Original Message-----
From: cnu list [mailto:[login to unmask email]
Sent: Friday, April 3, 2009 03:08 PM
To: [login to unmask email]
Subject: [DB2-L] Reclaim space of LOB

HI listers

I am trying to release space allocated to an LOB.

I did a delete * <tablename> but still the space occupied by LOB is X tracks.

When i start adding few records to the LOB the no of tracks are adding up to X+Y tracks. I was expecting DB2 to release the space occupied. Is there some thing i am doing wrong ?

Appreciate your help in advance.

Thanks and rgds.,
cnu



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

The IDUG DB2-L Listserv is only part of your membership in IDUG. If you are not already an IDUG.org member, please register here.


_____________________________________________________________________

* IDUG 09 Denver, CO, USA * May 11-15, 2009 * http://IDUG.ORG/NA *
_____________________________________________________________________

IDUG DB2-L FAQ and e-mail settings are located on the IDUG.org Listserv page.
If you are not already an IDUG.org member, please register at http://www.idug.org/component/juser/register.html
_____________________________________________________________________

Avram Friedman

Re: Reclaim space of LOB
(in response to Lance Jackson)
Lance,
I am sure the statement I am about to make is subject to version diffrences,
for example may not be true in DB2 for z/os V9.

Historically REORGING a LOB table space is like compressing a PDS.
Space does not get free'ed. It becomes reusable which is very diffrent.
The LOB does not shrink as a result of REORG but its growth is defered for
awhile.

Av Friedman

On Fri, 3 Apr 2009 19:23:20 +0000, Lance D. Jackson
<[login to unmask email]> wrote:

>You'l have to REORG the LOB tablespace.
>
>
>-----Original Message-----
>From: cnu list [mailto:[login to unmask email]
>Sent: Friday, April 3, 2009 03:08 PM
>To: [login to unmask email]
>Subject: [DB2-L] Reclaim space of LOB
>
>HI listers
>
>I am trying to release space allocated to an LOB.
>
>I did a delete * <tablename> but still the space occupied by LOB is X tracks.
>
>When i start adding few records to the LOB the no of tracks are adding up to
X+Y tracks. I was expecting DB2 to release the space occupied. Is there some
thing i am doing wrong ?
>
>Appreciate your help in advance.
>
>Thanks and rgds.,
>cnu
>
>
>
>------------------------------------------------------------
>
>The IDUG DB2-L Listserv is only part of your membership in IDUG. If you are
not already an IDUG.org member, please register here.
>
>
>_________________________________________________________________
____
>
>* IDUG 09 Denver, CO, USA * May 11-15, 2009 * http://IDUG.ORG/NA *
>_________________________________________________________________
____
>
>IDUG DB2-L FAQ and e-mail settings are located on the IDUG.org Listserv
page.
>If you are not already an IDUG.org member, please register at
http://www.idug.org/component/juser/register.html
>_________________________________________________________________
____
>

_____________________________________________________________________

* IDUG 09 Denver, CO, USA * May 11-15, 2009 * http://IDUG.ORG/NA *
_____________________________________________________________________

IDUG DB2-L FAQ and e-mail settings are located on the IDUG.org Listserv page.
If you are not already an IDUG.org member, please register at http://www.idug.org/component/juser/register.html
_____________________________________________________________________

Lance Jackson

Re: Reclaim space of LOB
(in response to Avram Friedman)
Avram,

I assumed that the platform was LUW, not z/OS. You're correct with the z/OS version.

-----Original Message-----
From: Avram Friedman [mailto:[login to unmask email]
Sent: Friday, April 3, 2009 04:32 PM
To: [login to unmask email]
Subject: Re: [DB2-L] Reclaim space of LOB

Lance, I am sure the statement I am about to make is subject to version diffrences, for example may not be true in DB2 for z/os V9. Historically REORGING a LOB table space is like compressing a PDS. Space does not get free'ed. It becomes reusable which is very diffrent. The LOB does not shrink as a result of REORG but its growth is defered for awhile. Av Friedman On Fri, 3 Apr 2009 19:23:20 +0000, Lance D. Jackson wrote: >You'l have to REORG the LOB tablespace. > > >-----Original Message----- >From: cnu list [mailto:[login to unmask email] >Sent: Friday, April 3, 2009 03:08 PM >To: [login to unmask email] >Subject: [DB2-L] Reclaim space of LOB > >HI listers > >I am trying to release space allocated to an LOB. > >I did a delete * but still the space occupied by LOB is X tracks. > >When i start adding few records to the LOB the no of tracks are adding up to X+Y tracks. I was expecting DB2 to release the space occupied. Is there some thing i am doing wrong ? > >Appreciate your help in advance. > >Thanks and rgds., >cnu > > > >------------------------------------------------------------ > >The IDUG DB2-L Listserv is only part of your membership in IDUG. If you are not already an IDUG.org member, please register here. > > >_________________________________________________________________ ____ > >* IDUG 09 Denver, CO, USA * May 11-15, 2009 * http://IDUG.ORG/NA * >_________________________________________________________________ ____ > >IDUG DB2-L FAQ and e-mail settings are located on the IDUG.org Listserv page. >If you are not already an IDUG.org member, please register at http://www.idug.org/component/juser/register.html >_________________________________________________________________ ____ > _____________________________________________________________________ * IDUG 09 Denver, CO, USA * May 11-15, 2009 * http://IDUG.ORG/NA * _____________________________________________________________________ IDUG DB2-L FAQ and e-mail settings are located on the IDUG.org Listserv page. If you are not already an IDUG.org member, please register at http://www.idug.org/component/juser/register.html _____________________________________________________________________

_____________________________________________________________________

* IDUG 09 Denver, CO, USA * May 11-15, 2009 * http://IDUG.ORG/NA *
_____________________________________________________________________

IDUG North America 2008 Attendee Testimonial-
"The round table SIGs I attended were great. The IBM presenters were very helpful and professional."
_____________________________________________________________________

Myron Miller

Re: Reclaim space of LOB
(in response to Lance Jackson)
For V9, it's a little different. With a SHRLEVEL Change or SHRLEVEL REFERENCE REORG, the space is reclaimed. Otherwise not. Remember that with a SHRLEVEL CHANGE or REFERENCE REORG, a new .I or .J dataspace is allocated and the LOBs are written freshly into that space.

And this might even be true in later versions of V8, but I can't swear to that.

Myron




________________________________
From: Avram Friedman <[login to unmask email]>
To: [login to unmask email]
Sent: Friday, April 3, 2009 4:32:11 PM
Subject: Re: [DB2-L] Reclaim space of LOB

Lance,
I am sure the statement I am about to make is subject to version diffrences,
for example may not be true in DB2 for z/os V9.

Historically REORGING a LOB table space is like compressing a PDS.
Space does not get free'ed. It becomes reusable which is very diffrent.
The LOB does not shrink as a result of REORG but its growth is defered for
awhile.

Av Friedman

On Fri, 3 Apr 2009 19:23:20 +0000, Lance D. Jackson
<[login to unmask email]> wrote:

>You'l have to REORG the LOB tablespace.
>
>
>-----Original Message-----
>From: cnu list [mailto:[login to unmask email]
>Sent: Friday, April 3, 2009 03:08 PM
>To: [login to unmask email]
>Subject: [DB2-L] Reclaim space of LOB
>
>HI listers
>
>I am trying to release space allocated to an LOB.
>
>I did a delete * <tablename> but still the space occupied by LOB is X tracks.
>
>When i start adding few records to the LOB the no of tracks are adding up to
X+Y tracks. I was expecting DB2 to release the space occupied. Is there some
thing i am doing wrong ?
>
>Appreciate your help in advance.
>
>Thanks and rgds.,
>cnu
>
>
>
>------------------------------------------------------------
>
>The IDUG DB2-L Listserv is only part of your membership in IDUG. If you are
not already an IDUG.org member, please register here.
>
>
>_________________________________________________________________
____
>
>* IDUG 09 Denver, CO, USA * May 11-15, 2009 * http://IDUG.ORG/NA *
>_________________________________________________________________
____
>
>IDUG DB2-L FAQ and e-mail settings are located on the IDUG.org Listserv
page.
>If you are not already an IDUG.org member, please register at
http://www.idug.org/component/juser/register.html
>_________________________________________________________________
____
>

_____________________________________________________________________

* IDUG 09 Denver, CO, USA * May 11-15, 2009 * http://IDUG.ORG/NA *
_____________________________________________________________________

IDUG DB2-L FAQ and e-mail settings are located on the IDUG.org Listserv page.
If you are not already an IDUG.org member, please register at http://www.idug.org/component/juser/register.html
_____________________________________________________________________

_____________________________________________________________________

* IDUG 09 Denver, CO, USA * May 11-15, 2009 * http://IDUG.ORG/NA *
_____________________________________________________________________

IDUG North America 2008 Attendee Testimonial-
"The round table SIGs I attended were great. The IBM presenters were very helpful and professional."
_____________________________________________________________________

SUBSCRIBE DB2-L Anil Kale

Reclaim Space
(in response to Myron Miller)
Hi All !

Before I ask my question, the env details:
DB2 for z/os; DB2 V8 ; z/os 1.09; DB2 datasets on non-sms volumes

I noticed that lately we get an -904 (00D70014) error even though there was
plenty of space on the volume.

I am told it has to with how db2 manages the extents. It turns out that just
because you have space on a volume doesn't mean that DB2 will use it.
DB2 will use a volume for extents but only if it has not used it before(doesn't
have a dataset on it).
Let me explain a bit more:
Lets say I have a table t1 (tablespace ts1)
Lets say ts1 creates db2 datasets on a volume v1. v1 gets full. so it moves to
the next volume in the storage group, v2. v2 gets full. it then moves to v3..so
on.
Then you the pro-active DBA step in and clean up the junk in v1 and now its
80% free space. however, in the 20% of volume v1, there is still a db2
dataset for ts1.
Volume v3 is filled up. Now you would think that db2 would reuse volume v1
(since you have done such a good job of freeing up 80% of the space).
Guess what ? DB2 refuses to use v1 and instead gives you a 00D70014
error.

So my questions to my fellow DBAs are
- is this somehow a issue related to non-sms volumes ?
- what are the other DBAs doing to handle this situation ?

Thanks.

Anil

_____________________________________________________________________

* IDUG North America * Tampa, Florida, * May 10-14 2010 * http://IDUG.ORG/NA *
_____________________________________________________________________

http://www.idug.org/events/index.html is your DB2 Events calendar! RUG meetings,
Webcasts, Conferences- what is going on next?
RUG leaders- get your events on the calendar today!
_____________________________________________________________________

If you need to change settings, http://www.idug.org/cgi-bin/wa?A0=DB2-L is the home of IDUG's DB2-L

Bala

Re: Reclaim Space
(in response to SUBSCRIBE DB2-L Anil Kale)
Anil,

Volumes and space management is something I do often but, I had not
faced this situation in particular. A reorg would make DB2 to go back
and use the 80% space left in V1, for sure.



On 11/20/09, Anil <[login to unmask email]> wrote:
> Hi All !
>
> Before I ask my question, the env details:
> DB2 for z/os; DB2 V8 ; z/os 1.09; DB2 datasets on non-sms volumes
>
> I noticed that lately we get an -904 (00D70014) error even though there was
> plenty of space on the volume.
>
> I am told it has to with how db2 manages the extents. It turns out that just
> because you have space on a volume doesn't mean that DB2 will use it.
> DB2 will use a volume for extents but only if it has not used it
> before(doesn't
> have a dataset on it).
> Let me explain a bit more:
> Lets say I have a table t1 (tablespace ts1)
> Lets say ts1 creates db2 datasets on a volume v1. v1 gets full. so it moves
> to
> the next volume in the storage group, v2. v2 gets full. it then moves to
> v3..so
> on.
> Then you the pro-active DBA step in and clean up the junk in v1 and now its
> 80% free space. however, in the 20% of volume v1, there is still a db2
> dataset for ts1.
> Volume v3 is filled up. Now you would think that db2 would reuse volume v1
> (since you have done such a good job of freeing up 80% of the space).
> Guess what ? DB2 refuses to use v1 and instead gives you a 00D70014
> error.
>
> So my questions to my fellow DBAs are
> - is this somehow a issue related to non-sms volumes ?
> - what are the other DBAs doing to handle this situation ?
>
> Thanks.
>
> Anil
>
> _____________________________________________________________________
>
> * IDUG North America * Tampa, Florida, * May 10-14 2010 *
> http://IDUG.ORG/NA *
> _____________________________________________________________________
>
> http://www.idug.org/events/index.html is your DB2 Events calendar! RUG
> meetings,
> Webcasts, Conferences- what is going on next?
> RUG leaders- get your events on the calendar today!
> _____________________________________________________________________
>
> If you need to change settings, http://www.idug.org/cgi-bin/wa?A0=DB2-L is
> the home of IDUG's DB2-L
>

_____________________________________________________________________

* IDUG North America * Tampa, Florida, * May 10-14 2010 * http://IDUG.ORG/NA *
_____________________________________________________________________

http://www.idug.org/events/index.html is your DB2 Events calendar! RUG meetings,
Webcasts, Conferences- what is going on next?
RUG leaders- get your events on the calendar today!
_____________________________________________________________________

If you need to change settings, http://www.idug.org/cgi-bin/wa?A0=DB2-L is the home of IDUG's DB2-L

Al Greuter

Re: Reclaim Space
(in response to Bala)
Anil,

I am curious to know what the primary quantity on the tablespace is. If
it is over 2 gig, it will try to allocate another primary quantity. If
the pack involved (after cleanup) does not have the space for another
primary you will get a space error.

The other question that I have is what type of DASD is in the stogroup?
Is it MOD-3 MOD-9 or what?

If you move to SMS you should have sufficient DASD to eliminate this
situation from occurring.


Al Greuter
Senior DB2 Database Administrator / Work Order Manager
Lockheed Martin
Work Phone: 410-496-9522

-----Original Message-----
From: IDUG DB2-L [mailto:[login to unmask email] On Behalf Of Anil
Sent: Friday, November 20, 2009 7:37 AM
To: [login to unmask email]
Subject: [DB2-L] Reclaim Space

Hi All !

Before I ask my question, the env details:
DB2 for z/os; DB2 V8 ; z/os 1.09; DB2 datasets on non-sms volumes

I noticed that lately we get an -904 (00D70014) error even though there
was plenty of space on the volume.

I am told it has to with how db2 manages the extents. It turns out that
just because you have space on a volume doesn't mean that DB2 will use
it.
DB2 will use a volume for extents but only if it has not used it
before(doesn't have a dataset on it).
Let me explain a bit more:
Lets say I have a table t1 (tablespace ts1) Lets say ts1 creates db2
datasets on a volume v1. v1 gets full. so it moves to the next volume in
the storage group, v2. v2 gets full. it then moves to v3..so on.
Then you the pro-active DBA step in and clean up the junk in v1 and now
its 80% free space. however, in the 20% of volume v1, there is still a
db2 dataset for ts1.
Volume v3 is filled up. Now you would think that db2 would reuse volume
v1 (since you have done such a good job of freeing up 80% of the space).
Guess what ? DB2 refuses to use v1 and instead gives you a 00D70014
error.

So my questions to my fellow DBAs are
- is this somehow a issue related to non-sms volumes ?
- what are the other DBAs doing to handle this situation ?

Thanks.

Anil

_____________________________________________________________________

* IDUG North America * Tampa, Florida, * May 10-14 2010 *
http://IDUG.ORG/NA *
_____________________________________________________________________

http://www.idug.org/events/index.html is your DB2 Events calendar! RUG
meetings, Webcasts, Conferences- what is going on next?
RUG leaders- get your events on the calendar today!
_____________________________________________________________________

If you need to change settings, http://www.idug.org/cgi-bin/wa?A0=DB2-L
is the home of IDUG's DB2-L

_____________________________________________________________________

* IDUG North America * Tampa, Florida, * May 10-14 2010 * http://IDUG.ORG/NA *
_____________________________________________________________________

http://www.idug.org/events/index.html is your DB2 Events calendar! RUG meetings,
Webcasts, Conferences- what is going on next?
RUG leaders- get your events on the calendar today!
_____________________________________________________________________

If you need to change settings, http://www.idug.org/cgi-bin/wa?A0=DB2-L is the home of IDUG's DB2-L

Patrick Steurs

Re: Reclaim Space
(in response to Al Greuter)
Anil,

For the last few years, we never had space-problems. We are using SMS,
combined with db2-tablespace- parameters"priqty -1 & secqty - 1" and
monthly scheduled reorgs.

greetings,

Patrick Steurs

-----Original Message-----
From: IDUG DB2-L [mailto:[login to unmask email] On Behalf Of DB2sysprog
Sent: vrijdag 20 november 2009 14:25
To: [login to unmask email]
Subject: Re: [DB2-L] Reclaim Space

Anil,

Volumes and space management is something I do often but, I had not
faced this situation in particular. A reorg would make DB2 to go back
and use the 80% space left in V1, for sure.



On 11/20/09, Anil <[login to unmask email]> wrote:
> Hi All !
>
> Before I ask my question, the env details:
> DB2 for z/os; DB2 V8 ; z/os 1.09; DB2 datasets on non-sms volumes
>
> I noticed that lately we get an -904 (00D70014) error even though
there was
> plenty of space on the volume.
>
> I am told it has to with how db2 manages the extents. It turns out
that just
> because you have space on a volume doesn't mean that DB2 will use it.
> DB2 will use a volume for extents but only if it has not used it
> before(doesn't
> have a dataset on it).
> Let me explain a bit more:
> Lets say I have a table t1 (tablespace ts1)
> Lets say ts1 creates db2 datasets on a volume v1. v1 gets full. so it
moves
> to
> the next volume in the storage group, v2. v2 gets full. it then moves
to
> v3..so
> on.
> Then you the pro-active DBA step in and clean up the junk in v1 and
now its
> 80% free space. however, in the 20% of volume v1, there is still a db2
> dataset for ts1.
> Volume v3 is filled up. Now you would think that db2 would reuse
volume v1
> (since you have done such a good job of freeing up 80% of the space).
> Guess what ? DB2 refuses to use v1 and instead gives you a 00D70014
> error.
>
> So my questions to my fellow DBAs are
> - is this somehow a issue related to non-sms volumes ?
> - what are the other DBAs doing to handle this situation ?
>
> Thanks.
>
> Anil
>
> _____________________________________________________________________
>
> * IDUG North America * Tampa, Florida, * May 10-14 2010 *
> http://IDUG.ORG/NA *
> _____________________________________________________________________
>
> http://www.idug.org/events/index.html is your DB2 Events calendar!
RUG
> meetings,
> Webcasts, Conferences- what is going on next?
> RUG leaders- get your events on the calendar today!
> _____________________________________________________________________
>
> If you need to change settings,
http://www.idug.org/cgi-bin/wa?A0=DB2-L is
> the home of IDUG's DB2-L
>

_____________________________________________________________________

* IDUG North America * Tampa, Florida, * May 10-14 2010 *
http://IDUG.ORG/NA *
_____________________________________________________________________

http://www.idug.org/events/index.html is your DB2 Events calendar! RUG
meetings,
Webcasts, Conferences- what is going on next?
RUG leaders- get your events on the calendar today!
_____________________________________________________________________

If you need to change settings, http://www.idug.org/cgi-bin/wa?A0=DB2-L
is the home of IDUG's DB2-L

-----------------------------------------
Visit our website! http://www.nbb.be

"DISCLAIMER: The content of this e-mail message should not be
construed as binding on the part of the National Bank of Belgium
(NBB) unless otherwise and previously stated. The opinions
expressed in this message are solely those of the author and do not
necessarily reflect NBB viewpoints, particularly when the content
of this message, or part thereof, is private by nature or does not
fall within the professional scope of its author."

_____________________________________________________________________

* IDUG North America * Tampa, Florida, * May 10-14 2010 * http://IDUG.ORG/NA *
_____________________________________________________________________

http://www.idug.org/events/index.html is your DB2 Events calendar! RUG meetings,
Webcasts, Conferences- what is going on next?
RUG leaders- get your events on the calendar today!
_____________________________________________________________________

If you need to change settings, http://www.idug.org/cgi-bin/wa?A0=DB2-L is the home of IDUG's DB2-L

SUBSCRIBE DB2-L Anil Kale

Re: Reclaim Space
(in response to Patrick Steurs)
Hi Al,

I can confirm to you that it doesn't have to do with what is specified as priqty.
However, answering your question, the priqty is some cases was as low as
720.
With the exception of a few, mostly all are MOD-9 DASDs.
I did speak to a couple db2 folks from the labs, and they did say it is
possible (the extents issue with reuse of previously used volume). Since I
didn't get a conclusive and complete response to my question, I am
wondering if it might help to contact folks from the z/os side. What say ? If so,
what would be the most effective to get some clarification from the z/os team.

Thanks

Anil

On Fri, 20 Nov 2009 08:27:35 -0500, Greuter, Al <[login to unmask email]>
wrote:

>Anil,
>
>I am curious to know what the primary quantity on the tablespace is. If
>it is over 2 gig, it will try to allocate another primary quantity. If
>the pack involved (after cleanup) does not have the space for another
>primary you will get a space error.
>
>The other question that I have is what type of DASD is in the stogroup?
>Is it MOD-3 MOD-9 or what?
>
>If you move to SMS you should have sufficient DASD to eliminate this
>situation from occurring.
>
>
>Al Greuter
>Senior DB2 Database Administrator / Work Order Manager
>Lockheed Martin
>Work Phone: 410-496-9522
>
>-----Original Message-----
>From: IDUG DB2-L [mailto:[login to unmask email] On Behalf Of Anil
>Sent: Friday, November 20, 2009 7:37 AM
>To: [login to unmask email]
>Subject: [DB2-L] Reclaim Space
>
>Hi All !
>
>Before I ask my question, the env details:
>DB2 for z/os; DB2 V8 ; z/os 1.09; DB2 datasets on non-sms volumes
>
>I noticed that lately we get an -904 (00D70014) error even though there
>was plenty of space on the volume.
>
>I am told it has to with how db2 manages the extents. It turns out that
>just because you have space on a volume doesn't mean that DB2 will use
>it.
>DB2 will use a volume for extents but only if it has not used it
>before(doesn't have a dataset on it).
>Let me explain a bit more:
>Lets say I have a table t1 (tablespace ts1) Lets say ts1 creates db2
>datasets on a volume v1. v1 gets full. so it moves to the next volume in
>the storage group, v2. v2 gets full. it then moves to v3..so on.
>Then you the pro-active DBA step in and clean up the junk in v1 and now
>its 80% free space. however, in the 20% of volume v1, there is still a
>db2 dataset for ts1.
>Volume v3 is filled up. Now you would think that db2 would reuse volume
>v1 (since you have done such a good job of freeing up 80% of the space).
>Guess what ? DB2 refuses to use v1 and instead gives you a 00D70014
>error.
>
>So my questions to my fellow DBAs are
>- is this somehow a issue related to non-sms volumes ?
>- what are the other DBAs doing to handle this situation ?
>
>Thanks.
>
>Anil
>
>_________________________________________________________
____________
>
>* IDUG North America * Tampa, Florida, * May 10-14 2010 *
>http://IDUG.ORG/NA *
>_________________________________________________________
____________
>
>http://www.idug.org/events/index.html is your DB2 Events calendar! RUG
>meetings, Webcasts, Conferences- what is going on next?
>RUG leaders- get your events on the calendar today!
>_________________________________________________________
____________
>
>If you need to change settings, http://www.idug.org/cgi-bin/wa?A0=DB2-L
>is the home of IDUG's DB2-L
>
>_________________________________________________________
____________
>
>* IDUG North America * Tampa, Florida, * May 10-14 2010 *
http://IDUG.ORG/NA *
>_________________________________________________________
____________
>
>http://www.idug.org/events/index.html is your DB2 Events calendar! RUG
meetings,
>Webcasts, Conferences- what is going on next?
>RUG leaders- get your events on the calendar today!
>_________________________________________________________
____________
>
>If you need to change settings, http://www.idug.org/cgi-bin/wa?A0=DB2-L
is the home of IDUG's DB2-L

_____________________________________________________________________

* IDUG North America * Tampa, Florida, * May 10-14 2010 * http://IDUG.ORG/NA *
_____________________________________________________________________

http://www.idug.org/rug/index.html - with almost 150 IDUG Regional User Groups,
there is probably one near you!
Regional User Groups are your local connection to the Worldwide DB2 User Community
_____________________________________________________________________

If you need to change settings, http://www.idug.org/cgi-bin/wa?A0=DB2-L is the home of IDUG's DB2-L

Sysdba_AHE/CORP/TPG

Re: Reclaim Space
(in response to SUBSCRIBE DB2-L Anil Kale)
Hi Anil,

Unlike your other respondents, we have had this in the past.

Raising a z/OS question is a good idea. I think it's an MVS restriction,
and probably applies equally to SMS.

AFAIK the part of a dataset on a particular volume has to consist of
contiguously-numbered extents because of how VTOC entries chain volumes
together. I think the volume list in the catalog (VVDS) also implies the
sequence of volumes, and I don't believe you can repeat a volume serial
number (apart from '*' for a candidate volume).

So if, say, volume V00001 contains extents 1,2, and 3 of the dataset and
V00002 contains extents 4 and 5, the dataset can't acquire more extents on
V00001, and you can't catalog any dataset with a volume list like
(V00001,V00002,V00001).

I could be way off the mark, but hopefully it will help you ask a suitable
question on the z/OS list.

Regards

Neil Price
TNT Express ICS, UK

---------------------------------------------------------------------------------------------------------------
This message and any attachment are confidential and may be privileged or otherwise protected from disclosure.
If you are not the intended recipient, please telephone or email the sender and delete this message and any attachment from your system.
If you are not the intended recipient you must not copy this message or attachment or disclose the contents to any other person.
Please consider the environmental impact before printing this document and its attachment(s). Print black and white and double-sided where possible.
------------------------------------------------------------------------------

_____________________________________________________________________

* IDUG North America * Tampa, Florida, * May 10-14 2010 * http://IDUG.ORG/NA *
_____________________________________________________________________

http://www.idug.org/rug/index.html - with almost 150 IDUG Regional User Groups,
there is probably one near you!
Regional User Groups are your local connection to the Worldwide DB2 User Community
_____________________________________________________________________

If you need to change settings, http://www.idug.org/cgi-bin/wa?A0=DB2-L is the home of IDUG's DB2-L