So in yesterday's post I spoke of a "better Q MOUNT" using a script I wrote. The problem is the Q MOUNT command does not reference a accessible TSM table. It appears to gathers the information on the mount with the associated process or session from various tables (as seen with Q MOUNT F=D). So I became more intrigued with how TSM gathers the info and decided to bypass TSM all together and research on the DB2 side. Well out of 779 tables in the TSM 7.1 DB2 database I did not see any with MOUNT in the name (you can find a list of all the TSM DB 7.1 tables here). There definietle some tables that appear in the list that are hidden from TSM or unused, but I queried a number of tables looking for any that had fields (columns) that correlated to the Q MOUNT command. The closest I came was the MMS_DRIVE table which has the following fields.
$ db2 "select char(COLNAME,24) as COLNAME,char(TYPENAME,24)as DATATYPE,LENGTH,SCALE from syscat.columns where tabname='MMS_DRIVES' and tabschema='TSMDB1'"
COLNAME DATATYPE LENGTH SCALE
------------------------ ------------------------ ----------- ------
ACSDRVID VARCHAR 126 0
CLEANFREQ INTEGER 4 0
DEVICE VARCHAR 65 0
DEVTYPE INTEGER 4 0
DEV_INQ SMALLINT 2 0
DRIVENAME VARCHAR 31 0
ELEMENT INTEGER 4 0
INQUIRY VARCHAR 1025 0
KBYTES_PROC BIGINT 8 0
KBYTES_PROC_HI INTEGER 4 0
LIBNAME VARCHAR 31 0
ONLINE INTEGER 4 0
OWNER VARCHAR 65 0
OWNERVOL VARCHAR 1025 0
RD_FORMAT BIGINT 8 0
SERIAL VARCHAR 65 0
UPDATE_DATE TIMESTAMP 10 6
UPDATOR VARCHAR 65 0
WR_FORMAT BIGINT 8 0
WWN VARCHAR 17 0
There should be a table that would show the drive, what tape is mounted, what process or session it's assigned and who owns it, just like a Q MOUNT F=D. I haven't found it yet.
NOTE: Of the 779 tables I listed a more refined search shows 154 tables that correspond to what we seem to be able to access from the TSM admin command line.
No comments:
Post a Comment