Handling the dreaded 00D70014 abend in a pinch:

(Contributed by Paul Schulz of Nationwide Insurance.)

You can save the hassle of altering PRI and SECQTY and doing a reorg for a convenient time if your DB2 data is managed by SMS. A couple of SMS commands can do the work for you in a pinch. Try the following on a test dataset to see how it works:

1. First you have to stop the space (Index or Tablespace).
2. Then bring up the problem cluster dataset on the ISPF 3.4 screen. (Remember the cluster dataset is the one with 'DSNDBC' in the second qualifier of the VSAM name.)
3. Type hmigrate as a line command next to the dataset. (This takes a few minutes in my shop. It will depend on whether SMS puts it to tape or disk and how large the VSAM is.)
4. Once it is migrated (you will have to exit the 3.4 screen and come back in to tell it is done) type hrecall as a line command next to the dataset. (This time you can execute it against the cluster or the data.) The recall will run quicker than the migrate.
5. At this point you are ready to start the space again.
6. Check your allocation from 3.4 and you should be in 1 (or a small few) extents. The number of extents you end up in depends on how much free space is available in your stogroup/pool.
7. If your operations staff has enough authority, you can walk them through the entire process over the phone. And now you can roll over and go back to sleep!

Very important note: If you fix a dataset this way you have to go back and alter PRI and SECQTY then reorg in order to complete your fix. If you don't do the alters, your next reorg may fail with 119 extents. Then you are stuck doing the alters.