There is a known and somewhat documented restriction where an administrative ID 
which connects to a New (7.1.8 or 8.1.2+) server from a New dsmadmc client, 
cannot connect from an Old administrative client anymore, because 
SESSIONSECURITY has been switched to STRICT.

I have now discovered that this affects Command Routing among servers. It makes 
sense, if you think about it, but it bit me. My test setup has two servers, one 
running 6.3.5 and the other 7.1.8. They both have Admin ID roger with the same 
password. Command routing initially worked fine between the two servers using 
Admin ID roger. But then Admin ID roger used a 7.1.8 client dsmadmc to connect 
to the 7.1.8 server, and all that SSL magic happened and SESSIONSECURITY got 
changed to STRICT. As documented, now Admin ID roger cannot use an older client 
dsmadmc to reach the 7.1.8 server. Although roger can still connect to the 
6.3.5 server using any version client dsmadmc, now command routing no longer 
works. It fails with "ANR0454E Session rejected by server ADSM-3, reason: 7 - 
Down level." It does work when Admin ID roger connects to the 7.1.8 server. UPD 
(ugly) suggestion in mind to issue it every 5 minutes from a schedule if this 
becomes an issue.

I have noticed that, if SESSIONSECURITY=TRANSITIONAL is in effect, and you use 
an Old client to connect to an Old server, and you use command routing to route 
a command to a New server, it does NOT change SESSIONSECURITY to STRICT for 
that Admin ID on the New server. That is good. This feature of automatically 
setting SESSIONSECURITY to STRICT on Admin IDs is turning into one of our worst 
stumbling blocks in this major update. I'm the administrator; don't mess with 
my own ID!

This looks like another reason to upgrade ALL servers to 7.1.8/8.1.2+ before 
upgrading ANY clients. We have several admin IDs that are used by a variety of 
cron processes to monitor and control the backup systems. Some of these 
processes use command routing. I am now inventorying them, because the clients 
they connect from must all be upgraded together at the same time to avoid 
failures of these monitoring and control processes.

Roger Deschner
University of Illinois at Chicago
"I have not lost my mind; it is backed up on tape somewhere."

Reply via email to