I feel your pain.  The conversion guide says there are changes to the
way SELECT does time calculation, but it is very non-specific (and the
example it gives is incorrect).

The timestampdiff function appears to work consistently.  It's
documented in the DB2 SQL guide.  An example:

select timestampdiff(8,cast( (current_timestamp-last_backup_date) as
char(22))) as DBHRS from db

/* 2  seconds
/* 4  minutes
/* 8  hours
/* 16 days
/* 32 weeks
/* 64 months
/*128 quarters
/*256 years

-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf Of
Gary Bowers
Sent: Monday, June 21, 2010 3:00 PM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: [ADSM-L] Getting backup duration in TSM 6.2 select statement

I must be missing something.  It used to be that we could use the
following select statement to get event durations from the summary
table.

select event, (end_time - start_time) seconds from summary.

I am keeping this simple for illustrative purposes.

I verified that this works as expected in 5.5.  This used to return
the total number of seconds that an event like a backup or migration
ran.  Now it returns just the number of seconds.  For instance.

If the process took 1 hour 20 minutes and 30 seconds, the command
should return 4800 seconds.  Instead it just returns "30".  The number
of seconds in the timestamp field.

If I run the same select statement for minutes I get 20 instead of
80... etc.

This seems to only be  problem with the summary table, as running a
select from the processes table works as expected.  Does anyone else
see this???

I am running TSM 6.2.1.0 on AIX 6.1.  I am having to rewrite all kinds
of scripts in order to accomodate this.  I know that we are supposed
to cast the timestamp as an integer, but I have not had any luck with
that either.  That just helps me do math with it like in calculating
backup speeds.

Any help is appreciated.