Content preview:  I believe the incompatibility arises if you set 
SESSIONSECURITY
    to STRICT for your nodes. The default is TRANSITIONAL so you should be fine;
    IIRC the only communication problems we had when upgrading our servers to
    v7.1.8 was with library sharing. [...]

 Content analysis details:   (0.6 points, 5.0 required)

  pts rule name              description
 ---- ---------------------- --------------------------------------------------
  0.7 SPF_NEUTRAL            SPF: sender does not match SPF record (neutral)
 -0.0 T_RP_MATCHES_RCVD      Envelope sender domain matches handover relay
                             domain
X-Barracuda-Connect: mx.gs.washington.edu[128.208.8.134]
X-Barracuda-Start-Time: 1514931575
X-Barracuda-Encrypted: ECDHE-RSA-AES256-GCM-SHA384
X-Barracuda-URL: https://148.100.49.28:443/cgi-mod/mark.cgi
X-Virus-Scanned: by bsmtpd at marist.edu
X-Barracuda-Scan-Msg-Size: 3241
X-Barracuda-BRTS-Status: 1
X-Barracuda-Spam-Score: 0.00
X-Barracuda-Spam-Status: No, SCORE=0.00 using global scores of TAG_LEVEL=3.5 
QUARANTINE_LEVEL=1000.0 KILL_LEVEL=5.5 tests=
X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.46484
        Rule breakdown below
         pts rule name              description
        ---- ---------------------- 
--------------------------------------------------

I believe the incompatibility arises if you set SESSIONSECURITY to STRICT
for your nodes. The default is TRANSITIONAL so you should be fine; IIRC the only
communication problems we had when upgrading our servers to v7.1.8 was with
library sharing.

That said, v7.1.8 was a huge change so I would test it if possible first.

On Tue, Jan 02, 2018 at 05:12:44PM -0500, Tom Alverson wrote:
> Thanks for that link, I am more worried about any "gotcha's" caused by
> upgrading the client to 7.1.8 or 8.1.2 before the storage servers get
> upgraded (and start using the new authentication).   What I had not
> realized until I saw the chart is that the new clients are NOT backward
> compatible with old storage servers (which doesn't really affect me since
> we have those all at 7.1.7.2 now).
>
>
> *IBM SPECTRUM PROTECT CLIENT SUPPORT*
>
> includes the Backup-Archive, API, UNIX HSM, and Web clients
> that are compatible with, and currently supported with,
> IBM Spectrum Protect Servers and Storage Agents.
> *IBM Spectrum Protect*
> *Client Version*
> *Supported IBM Spectrum Protect*
> *Server and Storage Agent Versions*
> 8.1.2
> 8.1, 7.1
> 8.1.0
> 8.1, 7.1, 6.3.x 1
> 7.1.8
> 8.1, 7.1
> 7.1
> 8.1, 7.1, 6.3.x 1
> 6.4 1
> 8.1, 7.1, 6.3.x 1
> 6.3 1, 2
> 8.1, 7.1, 6.3.x 1
>
>
>
>
>
>
>
>
>
>
> On Tue, Jan 2, 2018 at 4:42 PM, Skylar Thompson <skylar2 AT u.washington DOT 
> edu>
> wrote:
>
> > There's pretty wide version compatibility between clients and servers; we
> > didn't go v7 server-side until pretty recently but have been running the v7
> > client for a while. IBM has a matrix published here:
> >
> > http://www-01.ibm.com/support/docview.wss?uid=swg21053218
> >
> > For basic backups and restores I think you can deviate even more, but
> > obviously you won't get support.
> >
> > On Tue, Jan 02, 2018 at 03:14:24PM -0500, Tom Alverson wrote:
> > > Our TSM storage servers were all upgraded last year to 7.1.7.2 (before
> > this
> > > new security update came out).   Now I am wondering if I should start
> > using
> > > the updated client or not?   If the servers stay at 7.1.7.2 for now is
> > > there any harm in using the newer client?  I would have to use 7.1.8.0 on
> > > anything older than 2012.  I saw some email traffic earlier that once you
> > > use the new authentication mode on a node you can't go back?  But it
> > seems
> > > that would not be possible until our storage servers get upgraded.
> > >
> > > Is there any downside in my case (where the storage servers are still at
> > > 7.1.7.2) of using the latest client versions in the interim??  Our
> > current
> > > standard client versions now are 7.1.6.4 for 2008 and older, and 8.1.0.0
> > > (yes the horrible buggy one) on newer servers.
> > >
> > > Tom
> >
> > --
> > -- Skylar Thompson (skylar2 AT u.washington DOT edu)
> > -- Genome Sciences Department, System Administrator
> > -- Foege Building S046, (206)-685-7354
> > -- University of Washington School of Medicine
> >

--
-- Skylar Thompson (skylar2 AT u.washington DOT edu)
-- Genome Sciences Department, System Administrator
-- Foege Building S046, (206)-685-7354
-- University of Washington School of Medicine