Here's a link to the formal statement of support:

http://www-01.ibm.com/support/docview.wss?rs=663&context=SSGSG7&uid=swg21053218&loc=en_US&cs=utf-8&lang=en

But by "support" IBM means that if you report a problem with this
combination of client/server, they will take the problem report.  Doesn't
mean that older clients that aren't formally supported won't still work.
They will.

W



On Mon, Aug 31, 2009 at 8:04 PM, Mark Scott <MScott AT bunnings.com DOT au> 
wrote:

> Good Morning
>                We have been in the planning stages of moving our
> production backup server to our non prod site and setting up cross site
> vaulting.
>
> The more I think about it, the more it makes sense to build a new server
> and point the clients to the server running TSM6.*.
>
> Our prod server is currently running 5.5.1 and the clients are also
> updated to this level across AIX, Linux, Windows and TDP for RMAN.
>
> Can someone point me to the documentation for supported clients etc as
> in the short term I was hoping to build the server as rev6 and leave the
> clients for the short term?
>
> Any gotchas running TSM6* on AIX would be appreciated.
>
> Look forward to your response
>
> Warm Regards
>
>
> -----Original Message-----
> From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf 
> Of
> Allen S. Rout
> Sent: Monday, 31 August 2009 9:53 PM
> To: ADSM-L AT VM.MARIST DOT EDU
> Subject: Re: [ADSM-L] Seeking wisdom on dedupe..filepool file size
> client compression and reclaims
>
> >> On Sun, 30 Aug 2009 08:34:47 +0200, Stefan Folkerts
> <stefan.folkerts AT ITAA DOT NL> said:
>
>
> > Interesting ideas and a simulator would be fun for this purpose.
> > You could be right and your example does make sense in a way but
> > still..  I do wonder if it works out in the real world.
>
> > Let's say you have normal data that expires (user files etc) and
> > large databases, some you keep for many months and sometimes even
> > years.
>
> I understand the case you're making, and I agree that the size of your
> files has an impact.  I'm suggesting that the impact isn't huge, and
> that it evens out in a reasonably short timeframe.
>
> Eventually, whatever the volume size, you wind up with a library full
> of volumes more or less randomly distributed between 0% and 50%
> reclaimable.  If you're keeping up with reclamation, that means you're
> _in_ a steady state, so you're _doing_ the same amount of work per
> unit time.
>
>
> So when I say "To a first approximation, it's irrelevant", focus on
> the "First appoximation" bit; Yes, there are variations here, but
> don't sweat them too much.
>
> It's certainly possible to back yourself into corners with very large
> or very small volumes.
>
>
>
> - Allen S. Rout
>
> ************************************************************************
> Bunnings Legal Disclaimer:
>
> 1)     This email is confidential and may contain legally privileged
> information.  If you are not the intended recipient, you must not
> disclose or use the information contained in it.  If you have received
> this email in error, please notify us immediately by return email and
> delete the document.
>
> 2)     All emails sent to and sent from Bunnings Group Limited.
> are scanned for content.  Any material deemed to contain inappropriate
> subject matter will be reported to the email administrator of all
> parties concerned.
> ************************************************************************
>