Re: tape speeds, TSM and pase -- MIDRANGE-L

Rob

I'm just starting a project to go down this road so it is interesting that you posted the performance figures - I had been wondering whether this was any better these days.

TSM has always been much, much slower in terms of tape speed than native AS/400 tape functions at least in my experience so what you are seeing does not surprise me in the least. One of the arguments to defend this I always used to hear was that it didn't matter because you were always going to be doing incrementals anyway so the data volumes would be much smaller after the first save. This theory really fell apart on a development box where there were new copies of data and new libraries created all the time but I could probably accept that this is not typical. One of the system I was managing also had a monster file that used to change every day and loads of files written to the IFS which were required so even the production incrementals were highly volatile and caused some issues.

Fortunately I will not be running the server on the iSeries (I don't think I ever want to have to do that again) so the PASE limitation is not likely to bite me at least as far as the server API's go, but I am wondering what the performance will be like throwing the data across the network to (I think) a 3583 attached to a pSeries.

Just so I have something to compare against later on, how did you got about measuring the throughput ?

Regards
Evan Harris

3582 runs 131GB/hour native
3582 runs 33GB/hour TSM underneath PASE
PMR with IBM says that it is because PASE API's to talk to tape drive are
limited to size chunks and really kills the speed.  Repeat, it's a PASE
issue and not a TSM issue.
3581-H17 runs 32GB/hour TSM underneath PASE.
Therefore the better hardware of the 3582 gets you little to no speed
improvement when using TSM underneath PASE.  Just higher tape volume.
This was NOT the normal grandfather... stuff of moving stuff from disk to
tape that TSM does.  This was a TSM backup of the entire disk pool to the
tape pool to move it offsite.  Therefore that grandfather logic was not
part of the equation.

TSM command used:
backup stg backuppool lto_3581_week1

IBM says it's a limitation of PASE and have no intention of 'beefing' up
the api's to pipe data to the tape drive any faster.  Workaround:  Dump
OS/400 and try a Linux or Unix partition.

Will running TSM on a Linux partition on my i5 get me any faster response
from LTO2 and/or LTO3 tape drives than running TSM underneath PASE?

TSM 5.2.2
OS/400=V5R3M0

Rob Berendt
--