DB2 data is usually very well behaved, in that it grows very slowly, with no real unexpected peaks & troughs. The good news is that this means that you can easily run your main DB2 database pools at 90%+.
In theory, DB2 works best if all the user databases are combined into one big pool. SMS then spreads the data over several disks, and irons out (more or less) DASD hotspots. In practice, this will never work, of course. It is always a good idea to keep production data well segregated from development, and probably also best to keep Acceptance Test data in its own pool too.
On top of that, you will always get an odd file or two which really needs tip top performance, and won't get it if they are contending with all the other DB2 databases. These are best segregated into their own pool.
A very active DB2 tablespace can suffer due to UCB queuing but this should be fixed with the advent of PAV (parallel access volumes see the ESS PAV section ), as it is now possible to have several, highly active data sets on a volume without performance problems. The operating system can then schedule several IO operations to the volume concurrently. HyperPAV is best for this, as it will switch aliases from quiet volumes to busy volumes.
Other problem areas are the BSDS & Active logs, which need to be segregated, preferably on different DASD subsystems. These are best put into a separate DB2 system pool, and placed using GSPACE.

Since the introduction of z/OS 1.7 you can have 123 file extents on each of 123 volumes, giving a total of 7,257 extents. The STOGROUPS must be SMcS managed to take advantage of the extra extents. The tablespaces do not need to be defined as Extended Format files, but they do need a Data Class with EXTENT CONSTRAINT REMOVAL=YES defined.
DB2V8 introduced Sliding Extents which are enabled if MGEXTSZ=YES is set in DNZPARMS. This is set automatically in DB2V9. DB2 starts with a 2 cylinder first extent, then as it allocates new extents, it increments the size by one cylinder, up to a maximum set by the DSSIZE parameter.

So the Storage Pool requirements then are:

system pool (or pools). You may need two pools, one for the recovery logs, and one for the systems datasets. Some people put tables in one pool and indexes in another to boost performance
normal production databases
development databases
possibly, acceptance test databases
high performance, or 'difficult' databases.

Converting DB2 data to SMS

Before conversion, make sure you have the correct management classes in place, have worked out a suitable storage pool plan and your ACS routines are coded to deal with DB2 data. There are two ways to convert DB2 data to SMS. If you can afford it, set up new, empty SMS pools and move the data into it. If you can't afford the space, then you have to convert in place.

Convert by Migration

This is probably the easiest way to convert if you don't have too many databases. You need to have enough spare disks available to allocate empty pools to convert into, and enough system downtime to do the moves. These are two good reasons not to use Convert by Migration for large amounts of data. You can move the data using storage utilities like DFDSS or SAMS, but this is one good opportunity to let your DBAs do the work for you using their own reorg

utilities. DBAs in general are a gregarious bunch, always good for a night out, but they do tend to be a bit suspicious of anyone touching 'their' databases.

There is another advantage of using DBA utilities, they will reorganise the databases internally, and re-optimise the access paths through them. So all the databases are now under SMS, and have just been performance tuned! That makes your SMS systems look good.

Convert in place

This is probably the only practical way to convert hundreds of gigabytes of databases. It is best beforehand, if the DBAs convert the DB2 stogroups to SMS storagegroup equivalents, and make all allocations non specific '*'s. If DBAs want to place data using guaranteed space, suggest they do that later using their reorg facilities.

I'd suggest that you practice this on a small subset of the data. What you want is a discreet application that the DBAs have isolated on a small number of disks, say about 8. That conversion will give everyone the confidence to do the rest. If all your databases are single volume then its easy!, Just use DFSMSDSS CONVERTV or equivalent, volume by volume. If you have multi-volume databases, then all the volumes on which a database exist, have to be converted in the same job. If you have a loads of multi-volume, then you really need to convert all the volumes in one DFDSS statement. This is not as bad as it sounds, I've seen 600GB converted in 90 mins.

DB2 multi-volume allocation

The way DB2 handles multi-volume allocations can be a bit confusing to storage administrators. You cannot define the DB2 files using IDCAMS with a volume(* * *) statement, and you cannot use a dataclass with multi-volume capability. The DB2 file definition is an SQL statement

 CREATE STOGROUP name
        VOLUMES(*)

The files will then be potentially allocated on all the volumes in the SMS storage group, or up to 59 volumes, whichever is smaller. If you look at a VSAM cluster component with an IDCAMS LISTCAT, you will NOT see any candidate volumes. This is because, when DB2 wants to extend a dataset, and the file is full, it issues ALTER ADDVOLUMES to the file until it adds enough candidates for all the volumes in to pool, or up to 59 in total. Once it has successfully allocated another volume, it then issues ALTER REMOVEVOLUMES to delete all the candidates that it has not used.
Do not override this by adding volumes yourself. If the file ends up with more than 59 volumes in total, then the ALTER REMOVEVOLUMES will fail, and DB2 will stop the table. The only way out of this is to use REMOVEVOLUMES yourself to clear out the candidates.

DB2 UDB for Windows, Unix and Linux has two types of tablespaces called SMS (System Managed Space) and DMS (Database Managed Space). SMS in that context is not the same as SMS, or DFSMS discussed here.

VENDOR Showcase