A little more than a year ago I predicted, that I would write this tip now. This tip is about a fast way of reorganizing DB2-tablespaces in the sense of gathering many extents into one. It has nothing to do with a real DB2 REORG as pointed out in the tip of week 15/2001. Somehow I find this tip particularly useful, because I feel that the most frequent reason for reorganizing is tablespaces running out of extents/space. The method is exactly the same if it is an index that runs out of space.

Before you can use ADRDSSU to collect all the extents into one you must ensure all of the following:

• You must find out what the name of the VSAM-dataset running out of extents is.
• You (the user running ADRDSSU) must have RACF ALTER access to this VSAM-dataset.
• Depending on the situation it might be nessecary to STOP the tablespace or indexspace involved. If the tablespace or indexspace is being processed by a stopped utility you can skip the STOP and the subsequent START.

When all these conditions are met you can run ADRDSSU in the way I have pointed out in week 15/2001. Remember to start the table- or indexspace if you had to stop it. Now you can continue putting new data into the tablespace or index just like that. Notice that you can use the method on individual parts of tablespaces or indexes or pieces of non-partitioning indexes (NPI's). When you have tried this a couple of times, you will be addicted to this trick, especially in testing environments. That is a promise.

The pitfall is that you don't get your data reorganized like in a real DB2 REORG. And there is another very important detail. If you run the DB2 REORG (or maybe a LOAD REPLACE) later when you have more time (ADRDSSU saves a lot of time) without changing PRIQTY or SECQTY for the tablespace, indexspace, partition or piece involved, then your REORG with a likelihood of 99% will fail because of space problems. Remember that your REORG or LOAD REPLACE starts by DELETING the VSAM-datasets involved and recreates them with the sizes taken from the DB2 catalog.

There are two solutions to this problem. You have to change PRIQTY and/or SECQTY to match the new size of the objects involved or you can use the parameter REUSE on your DB2 REORG or DB2 LOAD REPLACE. This parameter prevents the deletion of the VSAM-datasets. I can strongly recommend using this parameter, though it completely invalidates the PRIQTY parameter. SECQTY is of course still used for the new extents to be taken, so it is a very good idea to tune the SECQTY under all circumstances.