ADSM-L

Re: TSM DB Summary table

2003-06-23 13:46:43
Subject: Re: TSM DB Summary table
From: Andrew Raibeck <storman AT US.IBM DOT COM>
To: ADSM-L AT VM.MARIST DOT EDU
Date: Mon, 23 Jun 2003 10:46:01 -0700
Larry, I again refer you to APAR IC34609, which discusses this. You can
view the APAR by going to http://www.ibm.com and doing a search on the
APAR number, which should come right up for you. In particular, look at
the "Comments" section of the APAR. I think that will answer your
questions. If not, then let me know what isn't clear and I will try to
elaborate further, but I'd rather refer you to the existing information
first.

Regards,

Andy

Andy Raibeck
IBM Software Group
Tivoli Storage Manager Client Development
Internal Notes e-mail: Andrew Raibeck/Tucson/IBM@IBMUS
Internet e-mail: storman AT us.ibm DOT com

The only dumb question is the one that goes unasked.
The command line is your friend.
"Good enough" is the enemy of excellence.




Lawrence Clark <Larry_Clark AT THRUWAY.STATE.NY DOT US>
Sent by: "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>
06/23/2003 10:30
Please respond to "ADSM: Dist Stor Manager"


        To:     ADSM-L AT VM.MARIST DOT EDU
        cc:
        Subject:        Re: TSM DB Summary table



If access is returning all the rows when II look at the table, it is
only returning the current date.
Other tables return rows over a thousand, so it isn't a matter of
limits.
So I'm puzzled why, if it contains more than the current date, why the
events table doesn't display it when I open the table or put together a
simply query with no qualifyers.

>>> storman AT US.IBM DOT COM 06/23/03 01:21PM >>>
> I conclude this is much the same as enterint select * from EVENTS

Not sure if you are asking a question, but yes. The important point is
that no WHERE criteria for SCHEDULED_START is present.

Regards,

Andy

Andy Raibeck
IBM Software Group
Tivoli Storage Manager Client Development
Internal Notes e-mail: Andrew Raibeck/Tucson/IBM@IBMUS
Internet e-mail: storman AT us.ibm DOT com

The only dumb question is the one that goes unasked.
The command line is your friend.
"Good enough" is the enemy of excellence.




Lawrence Clark <Larry_Clark AT THRUWAY.STATE.NY DOT US>
Sent by: "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>
06/23/2003 10:08
Please respond to "ADSM: Dist Stor Manager"


        To:     ADSM-L AT VM.MARIST DOT EDU
        cc:
        Subject:        Re: TSM DB Summary table



SELECT [SCHEDULED_START], [ACTUAL_START], [DOMAIN_NAME],
[SCHEDULE_NAME], [NODE_NAME], [STATUS], [RESULT], [REASON]
FROM EVENTS;
I conclude this is much the same as enterint select * from EVENTS

>>> storman AT US.IBM DOT COM 06/23/03 12:40PM >>>
... So you can conclude that Access does not send a query that
contains
a
WHERE clause specifying the date criteria.

An example of how to get Access to work with this is as follows:

1) Create a link to the TSM server EVENTS table (I assume you already
know
how to do this).

2) Select the "View/Database Objects/Queries" menu item.

3) Double-click "Create query in Design view".

4) In the "Show Table" dialog, select the "Tables" tab, select the
EVENTS
table name within that tab's view, then click "Add" then "Close". You
should now see the "Select Query" window. This window has a little
selection dialog titled EVENTS, and below that is a table with rows
titled
Field, Table, Sort, etc.

5) Click in the left-most "Field" column and there should be a little
arrow in that column. Click on that arrow and select SCHEDULED_START.

6) In the "Criteria" row (a few rows below SCHEDULED_START) enter the
following:

   > Date() - 7

(this goes back for a week, specify whatever number you want).

7) Click in the other "Field" columns to the right of SCHEDULED_START
and
select the ACTUAL_START, SCHEDULE_NAME, NODE_NAME, STATUS, and RESULT
columns (one per "Field" column).

8) Select the "View/SQL View" menu item. If you performed the above
actions correctly, you should see a statement like this:

SELECT EVENTS.SCHEDULED_START, EVENTS.ACTUAL_START,
EVENTS.SCHEDULE_NAME,
EVENTS.NODE_NAME, EVENTS.STATUS, EVENTS.RESULT
FROM EVENTS
WHERE (((EVENTS.SCHEDULED_START)>Date()-7));

Select the "View/Datasheet View" menu item and in a few moments you
should
see the desired results.

Regards,

Andy

Andy Raibeck
IBM Software Group
Tivoli Storage Manager Client Development
Internal Notes e-mail: Andrew Raibeck/Tucson/IBM@IBMUS
Internet e-mail: storman AT us.ibm DOT com

The only dumb question is the one that goes unasked.
The command line is your friend.
"Good enough" is the enemy of excellence.




Lawrence Clark <Larry_Clark AT THRUWAY.STATE.NY DOT US>
Sent by: "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>
06/23/2003 09:01
Please respond to "ADSM: Dist Stor Manager"


        To:     ADSM-L AT VM.MARIST DOT EDU
        cc:
        Subject:        Re: TSM DB Summary table



Yes, but when I am looking at the actual EVENTS table via ACCESS and
odbc, it appears to only contain data for the current
day......................

>>> storman AT US.IBM DOT COM 06/23/03 11:28AM >>>
You need to do something like this:

   select * from events where scheduled_start>'06/13/2003'

Regards,

Andy

Andy Raibeck
IBM Software Group
Tivoli Storage Manager Client Development
Internal Notes e-mail: Andrew Raibeck/Tucson/IBM@IBMUS
Internet e-mail: storman AT us.ibm DOT com

The only dumb question is the one that goes unasked.
The command line is your friend.
"Good enough" is the enemy of excellence.




Lawrence Clark <Larry_Clark AT THRUWAY.STATE.NY DOT US>
Sent by: "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>
06/23/2003 07:57
Please respond to "ADSM: Dist Stor Manager"


        To:     ADSM-L AT VM.MARIST DOT EDU
        cc:
        Subject:        Re: TSM DB Summary table



Hi,
I can get prior days info by issuing a:
q event * * type=client begindate=06/13/2003 endd=today   exceptions
            only=y
but looking directly at the EVENTS table it contains no data prior to
the current date. I assume the above command goes against the activity
log, since it returns 'uncertain' for days earlier than the life of
the
events log.

>>> storman AT US.IBM DOT COM 06/23/03 10:50AM >>>
You need to specify values for the SCHEDULED_START and/or ACTUAL_START
columns in order to get older data from the EVENTS table. You could do
this via a script that calculates today's date - n days, and plugs
that
into a SELECT statement. Or just go with QUERY EVENTS.

The difficulties in getting the EVENTS table to work with dates other
than
today have been discussed on ADSM-L in the past. Also see APAR IC34609
for
additional info.

Regards,

Andy

Andy Raibeck
IBM Software Group
Tivoli Storage Manager Client Development
Internal Notes e-mail: Andrew Raibeck/Tucson/IBM@IBMUS
Internet e-mail: storman AT us.ibm DOT com

The only dumb question is the one that goes unasked.
The command line is your friend.
"Good enough" is the enemy of excellence.




Lawrence Clark <Larry_Clark AT THRUWAY.STATE.NY DOT US>
Sent by: "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>
06/23/2003 07:38
Please respond to "ADSM: Dist Stor Manager"


        To:     ADSM-L AT VM.MARIST DOT EDU
        cc:
        Subject:        Re: TSM DB Summary table



OK. Thanks; the EVENTS table seems to only status dor the current day.

>>> storman AT US.IBM DOT COM 06/23/03 10:27AM >>>
For client operations, the SUCCESSFUL column name is a bit of a
misnomer.
as it really just indicates whether the communications between server
and
client terminated successfully (I believe that this maps to the
"normal
server termination indicator" field in the account log records).

For monitoring client status, use QUERY EVENT FORMAT=DETAILED or the
EVENTS table. See the section on client return codes in the
"Automating
tasks" chapter of the client manual for additional info about client
status reporting.

Regards,

Andy

Andy Raibeck
IBM Software Group
Tivoli Storage Manager Client Development
Internal Notes e-mail: Andrew Raibeck/Tucson/IBM@IBMUS
Internet e-mail: storman AT us.ibm DOT com

The only dumb question is the one that goes unasked.
The command line is your friend.
"Good enough" is the enemy of excellence.




Lawrence Clark <Larry_Clark AT THRUWAY.STATE.NY DOT US>
Sent by: "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>
06/23/2003 06:16
Please respond to "ADSM: Dist Stor Manager"


        To:     ADSM-L AT VM.MARIST DOT EDU
        cc:
        Subject:        TSM DB Summary table



Hi:
I'm looking at the contents of the TSM Summary table and the
SUCCESSFUL
column for backups does not seem to relate to failed or missed nodes.
Anyone know how to interpret this column correctly?

<Prev in Thread] Current Thread [Next in Thread>