1. Forum Rules (PLEASE CLICK HERE TO READ BEFORE POSTING) Click the link to access ADSM.ORG Acceptable Use Policy and forum rules which should be observed when using this website. Violators may be banned from this website. This message will disappear after you have made at least 12 posts. Thank you for your cooperation.

Paths table in TSM 6.1 database

Discussion in 'TSM Server' started by mjp81, Nov 6, 2009.

  1. mjp81

    mjp81 New Member

    Joined:
    Apr 15, 2008
    Messages:
    9
    Likes Received:
    0
    Hi,

    I see that there now isn't a paths table in the TSM DB in 6.1. Does anyone know where in the DB path information is? I'm looking to create a sql script to look up path online/offline status and can't find where I should be querying!

    Thanks
     
  2.  
  3. MrStormy

    MrStormy New Member

    Joined:
    Apr 27, 2005
    Messages:
    5
    Likes Received:
    0
    Select * from paths still works on TSM 6.1.2.0?
     
  4. mjp81

    mjp81 New Member

    Joined:
    Apr 15, 2008
    Messages:
    9
    Likes Received:
    0
    Yep, it does indeed work within TSM command line, but trying it from DB2 command line returns table unknown:

    db2 => select * from tsmdb1.paths
    SQL0204N "TSMDB1.PATHS" is an undefined name. SQLSTATE=42704

    I can't see it listed as a table or a view anywhere.

    I need to access the DB2 data directly for reports / monitoring, but I can't find where the paths data is stored in the DB.

    Thanks
     
  5. Samuel

    Samuel New Member

    Joined:
    Jul 9, 2008
    Messages:
    286
    Likes Received:
    1
    i don't install tsm 6.1 but this command running without error ?
    select * from paths
     
  6. mjp81

    mjp81 New Member

    Joined:
    Apr 15, 2008
    Messages:
    9
    Likes Received:
    0
    Yep, select * from paths works from the 6.1 command line, and the database table/view does exist in TSM 5.5 and below, so that's all fine.

    I'm looking for how to access this data direct from the TSM 6.1 DB2 database - as far as I can see I don't have a DB2 table or view called paths, which is confusing the life out of me.

    I can query from the TSM command line, so it's obviously being stored somewhere... Even searching syscat.columns for any of the column names referenced in the select * from paths output returns nothing.
     
  7. Samuel

    Samuel New Member

    Joined:
    Jul 9, 2008
    Messages:
    286
    Likes Received:
    1
    i used this command :
    select library_name,destination_name,source_name,device,directory,online,destination_type,source_type from paths
     
  8. mjp81

    mjp81 New Member

    Joined:
    Apr 15, 2008
    Messages:
    9
    Likes Received:
    0
    It's the "from paths" bit that I have trouble with - "paths" is not recognised as a table or view name when querying direct from DB2 command line.

    Works fine from TSM command line, which is the confusing part.


     
  9. kehannigan

    kehannigan New Member

    Joined:
    Apr 3, 2009
    Messages:
    41
    Likes Received:
    1
    Occupation:
    Tivoli Storage Manager server development.
    The SQL schema presented by the TSM SELECT command has always been a virtual schema, completely separate from the underlying database schema. This was true in 5.x and is stil true in 6.1. It's just easier to see what the underlying database schema is in 6.1 now that you can bypass TSM and go directly to DB2.

    The table names presented in the TSM command line typically correspond to the objects you can define in TSM... NODES, ADMINS, DEVCLASSES, PATHS, etc.. The underlying implementation may use similar table names, or completely different names. There are even a few 'tables' available via TSM's SELECT that have no presence in the underlying database at all.... OPTIONS being the typical example of this.

    All of which just goes to explain why there's a difference between what you see on the TSM command line and what is presented to you by DB2. The other thing to keep in mind is that the TSM SQL interface as seen from the TSM command line is a supported external interface. The database schema as seen from DB2 is not. The underlying database schema is the internal implementation used by TSM, and can change without notice. So if you have a dependency on the data you're trying to find, you should use the TSM SQL interface instead of DB2's.

    Now, with all these caveats in mind ... look at the NA_PATH table...
     
    Last edited: Nov 10, 2009

Share This Page