IEC070I 211(8,306)-221 errors with DB2 table spaces

Products

• Allocate DASD Space and Placement

Issue/Introduction

We are receiving repetitive messages in DB2 subsystems that seem to indicate an ALTER ADDVOL was performed and the DB2 table space was not properly closed and re-opened.

We are deploying Allocate to our production LPARs and some have Allocate and some do not. We are concerned that the LPARs with Allocate are manipulating DB2 table spaces and causing issues with the other systems. We are able to update SMS this past weekend to add a Dynamic Volume Count on the assigned Data class.

Resolution

If SRS and ALLOCATE are running and moving in Allocate one system one at a time.  (SRS didn't exclude DB2 table spaces but must have been doing it)

Need to add a filter in Allocate to exclude the *DBM from allocate processing at EOV

*********

Allocate was correctly adding a volume to the DB2 table space.  On a different image, where Allocate was not running, DB2 did not recognize that a volume had been added to the table space. 

When Allocate is running on both images, DB2 will correctly recognize that a volume has been added, regardless of which image added the volume.

Until the customer is able to have Allocate running on all DB2 images, the following is suggested:

Continue to exclude the *DBM1 address spaces from EOV processing.
When the DB2 table spaces (VSAM linear data sets) are defined, assign them a SMS DATACLASS that has a Dynamic Volume Count (DVC) of 59. You can use the CA Allocate ‘ACS’ environment to assign the DATACLASS. With the DVC of 59, IBM SMS end-of-volume processing will add a volume to the DB2 table space (VSAM linear data set).