HSM here includes any archiving product, such as DFSMSHSM, FDRABR, etc. An HSM tool can save you money by migrating unused data off to tape, but with databases, it is essential that you do not compromise performance to save a bit of money. DB2 data can be carved up as follows
System files, like the Catalog , BSDS and Active logs are definitely not HSM candidates as the system will grind to a halt without them.
Archive logs are HSM candidates, but duplex copies need to be kept on different ML2 tapes. Best bet is to assign a management class to the copy2 version, which puts it straight off to tape, while letting the copy1 version live a day or so on disk. That should ensure they don't end up on the same ML2 tape. If you use HSM to expire the logs, make sure the retention period matches the ARCRETN value in DB2.
Image copies are probably going to be created on tape. If your tape is system managed, then make sure the expiration of image copies is consistent with the expiration of archive logs, and the whole lot is recorded in DB2 by the MODIFY utility.
Online Production databases are probably best left alone. There is nothing in principle to stop batch databases from being HSM managed, but they should not be deleted by HSM
Development databases can be successfully managed with HSM. The only caveat is that they should not be scratched by HSM, or any other non-DB2 utility. This is because the user databases and logs are all defined in the DB2 Catalog, and if they are deleted externally, DB2 doesn't know about it. One potential issue with DB2 and HSM, is that if your DB2 databases are maintained by a utility generator, then some generators reset all the access dates, which means the databases never get migrated. Or even worse, you have a lot of migrated databases, and you install a utility generator. On the first run, it recalls all your files. If you use a utility generator, try to get one which is HSM aware.
For DB2 to recognise archived files, you need to set RECALL=Y in the DSNZPARM parameter.
DFHSM can also be used to maintain DB2 databases. z/OS limits any file on a given volume to 119 extents, and DB2 has a 255 extent limit if it is multi-volume. If you have a database that is reaching its extent limit, you can consolidate it with DFHSM using the following process.
In DB2, STOP the tablespace which holds the dataset that is on too many extents.
From TSO 3.4, enter the line command HMIG against the offending file. You need to do this for the CLUSTER name, not the DATA component.
When you get the 'migrate successful' message, enter the HRECALL command against the same cluster name
The file should come back in a single extent
DFHSM has a free space release facility, but it will not work on DB2 databases. FDRCPK can do this, and I've found this very useful when a development DB2 pool is running out of space. If the database is open, FDRCPK will not touch it, but as most development databases are stopped, FDRCPK will free up a lot of space.
